[v6,0/2] Add Tx queue mapping of aggregated ports

  When multiple ports are aggregated into a single DPDK port,
(example: Linux bonding, DPDK bonding, failsafe, etc.),
we want to know which port is used for Rx and Tx.

This patch introduces the new ethdev API
rte_eth_dev_map_aggr_tx_affinity(), it's used to map a Tx queue
with an aggregated port of the DPDK port (specified with port_id),
The affinity is the number of the aggregated port.
Value 0 means no affinity and traffic could be routed to any
aggregated port, this is the default current behavior.

The maximum number of affinity is given by rte_eth_dev_count_aggr_ports().

This patch allows to map a Rx queue with an aggregated port by using
a flow rule. The new item is called RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.

While uses the aggregated affinity as a matching item in the flow rule,
and sets the same affinity value by call
rte_eth_dev_map_aggr_tx_affinity(), then the packet can be sent from
the same port as the receiving one.
The affinity numbering starts from 1, then trying to match on
aggr_affinity 0 will result in an error.

RFC: http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaweiw@nvidia.com/

v6:
* Update the commit titles.
* Return 0 by default if dev_ops.count_aggr_ports is not defined.
* Adds the dev_configure and affinity value checking before call map_aggr_tx_affinity.
* Update the rte_eth_dev_count_aggr_ports description.

v5:
* Adds rte_eth_dev_map_aggr_tx_affinity() to map a Tx queue to an aggregated port.
* Adds rte_eth_dev_count_aggr_ports() to get the number of aggregated ports.
* Updates the flow item RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.

v4:
* Rebase the latest code
* Update new field description
* Update release release note
* Reword the commit log to make clear

v3:
* Update exception rule
* Update the commit log
* Add the description for PHY affinity and numbering definition
* Add the number of physical ports into device info
* Change the patch order 

v2: Update based on the comments

Jiawei Wang (2):
  ethdev: add Tx queue mapping of aggregated ports
  ethdev: add flow matching of aggregated port

 app/test-pmd/cmdline.c                      | 92 +++++++++++++++++++++
 app/test-pmd/cmdline_flow.c                 | 28 +++++++
 doc/guides/prog_guide/rte_flow.rst          |  8 ++
 doc/guides/rel_notes/release_23_03.rst      |  8 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 18 ++++
 lib/ethdev/ethdev_driver.h                  | 39 +++++++++
 lib/ethdev/ethdev_trace.h                   | 17 ++++
 lib/ethdev/ethdev_trace_points.c            |  6 ++
 lib/ethdev/rte_ethdev.c                     | 72 ++++++++++++++++
 lib/ethdev/rte_ethdev.h                     | 50 +++++++++++
 lib/ethdev/rte_flow.c                       |  1 +
 lib/ethdev/rte_flow.h                       | 35 ++++++++
 lib/ethdev/version.map                      |  2 +
 13 files changed, 376 insertions(+)
  

On 2/17/2023 10:50 AM, Jiawei Wang wrote:
> When multiple ports are aggregated into a single DPDK port,
> (example: Linux bonding, DPDK bonding, failsafe, etc.),
> we want to know which port is used for Rx and Tx.
> 
> This patch introduces the new ethdev API
> rte_eth_dev_map_aggr_tx_affinity(), it's used to map a Tx queue
> with an aggregated port of the DPDK port (specified with port_id),
> The affinity is the number of the aggregated port.
> Value 0 means no affinity and traffic could be routed to any
> aggregated port, this is the default current behavior.
> 
> The maximum number of affinity is given by rte_eth_dev_count_aggr_ports().
> 
> This patch allows to map a Rx queue with an aggregated port by using
> a flow rule. The new item is called RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.
> 
> While uses the aggregated affinity as a matching item in the flow rule,
> and sets the same affinity value by call
> rte_eth_dev_map_aggr_tx_affinity(), then the packet can be sent from
> the same port as the receiving one.
> The affinity numbering starts from 1, then trying to match on
> aggr_affinity 0 will result in an error.
> 
> RFC: http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaweiw@nvidia.com/
> 
> v6:
> * Update the commit titles.
> * Return 0 by default if dev_ops.count_aggr_ports is not defined.
> * Adds the dev_configure and affinity value checking before call map_aggr_tx_affinity.
> * Update the rte_eth_dev_count_aggr_ports description.
> 
> v5:
> * Adds rte_eth_dev_map_aggr_tx_affinity() to map a Tx queue to an aggregated port.
> * Adds rte_eth_dev_count_aggr_ports() to get the number of aggregated ports.
> * Updates the flow item RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.
> 
> v4:
> * Rebase the latest code
> * Update new field description
> * Update release release note
> * Reword the commit log to make clear
> 
> v3:
> * Update exception rule
> * Update the commit log
> * Add the description for PHY affinity and numbering definition
> * Add the number of physical ports into device info
> * Change the patch order 
> 
> v2: Update based on the comments
> 
> Jiawei Wang (2):
>   ethdev: add Tx queue mapping of aggregated ports
>   ethdev: add flow matching of aggregated port

It looks like there will be a new version, can you please rebase next
version on top of next-net [1], there are multiple conflicts with this
patch, it is safer if you resolve them yourself.

[1]
https://git.dpdk.org/next/dpdk-next-net/
  

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Friday, February 17, 2023 9:01 PM
> To: Jiawei(Jonny) Wang <jiaweiw@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> andrew.rybchenko@oktetlabs.ru
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [PATCH v6 0/2] Add Tx queue mapping of aggregated ports
> 
> On 2/17/2023 10:50 AM, Jiawei Wang wrote:
> > When multiple ports are aggregated into a single DPDK port,
> > (example: Linux bonding, DPDK bonding, failsafe, etc.), we want to
> > know which port is used for Rx and Tx.
> >
> > This patch introduces the new ethdev API
> > rte_eth_dev_map_aggr_tx_affinity(), it's used to map a Tx queue with
> > an aggregated port of the DPDK port (specified with port_id), The
> > affinity is the number of the aggregated port.
> > Value 0 means no affinity and traffic could be routed to any
> > aggregated port, this is the default current behavior.
> >
> > The maximum number of affinity is given by rte_eth_dev_count_aggr_ports().
> >
> > This patch allows to map a Rx queue with an aggregated port by using a
> > flow rule. The new item is called RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.
> >
> > While uses the aggregated affinity as a matching item in the flow
> > rule, and sets the same affinity value by call
> > rte_eth_dev_map_aggr_tx_affinity(), then the packet can be sent from
> > the same port as the receiving one.
> > The affinity numbering starts from 1, then trying to match on
> > aggr_affinity 0 will result in an error.
> >
> > RFC:
> > http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaw
> > eiw@nvidia.com/
> >
> > v6:
> > * Update the commit titles.
> > * Return 0 by default if dev_ops.count_aggr_ports is not defined.
> > * Adds the dev_configure and affinity value checking before call
> map_aggr_tx_affinity.
> > * Update the rte_eth_dev_count_aggr_ports description.
> >
> > v5:
> > * Adds rte_eth_dev_map_aggr_tx_affinity() to map a Tx queue to an
> aggregated port.
> > * Adds rte_eth_dev_count_aggr_ports() to get the number of aggregated
> ports.
> > * Updates the flow item RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY.
> >
> > v4:
> > * Rebase the latest code
> > * Update new field description
> > * Update release release note
> > * Reword the commit log to make clear
> >
> > v3:
> > * Update exception rule
> > * Update the commit log
> > * Add the description for PHY affinity and numbering definition
> > * Add the number of physical ports into device info
> > * Change the patch order
> >
> > v2: Update based on the comments
> >
> > Jiawei Wang (2):
> >   ethdev: add Tx queue mapping of aggregated ports
> >   ethdev: add flow matching of aggregated port
> 
> It looks like there will be a new version, can you please rebase next version on
> top of next-net [1], there are multiple conflicts with this patch, it is safer if you
> resolve them yourself.
> 
> [1]
> https://git.dpdk.org/next/dpdk-next-net/

Sure, will send the v7 and rebase on it.