The following lines were originally removed from the commit message and should
not have been sent
(please consider it a typo mistake):
* Alarm API: mlx5_os_alarm_cancel() and mlx5_os_alarm_set() are
implemented in Windows to match their Linux counterpart, see [1].
Currently they return -ENOTSUP.
[1]
("net/mlx5/linux: wrap rte alarm API with mlx5")
> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Friday, January 8, 2021 4:55 PM
> To: Ferruh Yigit <ferruh.yi...@intel.com>
> Cc: Tal Shnaiderman <tal...@nvidia.com>; dev@dpdk.org; Matan Azrad
> <ma...@nvidia.com>; Raslan Darawsheh <rasl...@nvidia.com>; Ophir
> Munk <ophi...@nvidia.com>; Dekel Peled <dek...@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH v2 24/35] net/mlx5/windows: introduce flow
> support
>
> 08/01/2021 15:38, Ferruh Yigit:
> > On 12/28/2020 12:32 PM, Tal Shnaiderman wrote:
> > > From: Ophir Munk <ophi...@nvidia.com>
> > >
> > > This patch adds the initial flow framework under Windows OS. It
> > > supports a subset of filters (ETH, IPV4, UDP) and a QUEUE action.
> > > It is based on DevX mechanism to send commands to the NIC through
> > > the kernel. It does not support steering rules (i.e. writing directly to
> > > the
> NIC memory).
> > > The Windows framework uses the existing DV framework where file
> > > mlx5_flow_dv.c remains intact.
> > >
> > > Steps involved in flow creation:
> > > 1. Create a domain (RX, TX, FDB). Since domains are created by
> > > steering rules and not with DevX, Windows does not require a domain
> > > object (this means switch dev mode which requires an FDB domain is not
> supported).
> > > 2. Create a table object. Windows only supports table 0. The call to
> > > mlx5_flow_os_create_flow_tbl() silently returns successfully.
> > > 3. Create a matcher object. A matcher struct is created by calling
> > > mlx5_flow_os_create_flow_matcher(). The matcher validation and
> > > translation are part of the DV implementation. The matcher bits that
> > > were created by DV in standard PRM format are copied into the
> > > matcher struct.
> > > 4. Create an action object. The call to
> > > mlx5_flow_os_create_flow_action_dest_devx_tir() creates an action
> > > struct with the TIR type and id. This struct will be a parameter
> > > later in a call to flow creation. All other action calls (e.g.
> > > packet reformat, header modification, jump to flow table, etc)
> > > return with a non supported error.
> > > 5. Create the flow. The call to mlx5_flow_os_create_flow() receives
> > > the matcher struct, action struct, and copy them into Windows
> > > specific fs_rule struct, then it calls glue API devx_fs_rule_add().
> > >
> > > Details on additional APIs:
> > > * mlx5_flow_os_get_type() is called during flow type selection. In
> > > Windows it constantly returns MLX5_FLOW_TYPE_DV.
> > > * mlx5_flow_os_item_supported() is called before starting DV items
> > > validation or translation. It filters out the OS non supported items
> > > in advance.
> > > * mlx5_flow_os_action_supported() is called before starting DV
> > > actions validation or translation. It filters out the OS non
> > > supported actions in advance.
> > > * mlx5_flow_adjust_priority() is an OS stub for flow priority
> > > adjustment. Windows only supports flow priority 0.
> > > * Alarm API: mlx5_os_alarm_cancel() and mlx5_os_alarm_set() are
> > > implemented in Windows to match their Linux counterpart, see [1].
> > > Currently they return -ENOTSUP.
> > >
> > > [1]
> > > ("net/mlx5/linux: wrap rte alarm API with mlx5")
> >
> > Can you please provide commit hash for this commit, I can amend it
> > later in the next-net?
>
> It looks to be garbage.
> There is no alarm-related function in this patch.
> Please remove these lines from the message.
>
