date:20211010

On Fri, Oct 8, 2021 at 9:00 PM Ferruh Yigit  wrote:
>
> On 10/4/2021 1:54 PM, Pavan Nikhilesh Bhagavatula wrote:
> >> On 10/4/2021 1:01 PM, Pavan Nikhilesh Bhagavatula wrote:
>  On 10/4/2021 12:34 PM, Pavan Nikhilesh Bhagavatula wrote:
> >> On 10/4/2021 11:02 AM, Pavan Nikhilesh Bhagavatula wrote:
>  On 10/4/2021 6:56 AM, pbhagavat...@marvell.com wrote:
> > From: Pavan Nikhilesh 
> >
> > Due to Linux kernel AF(Admin function) driver dependency,
> >> only
>  enable
> > build for 64-bit Linux.
> >
> 
>  Hi Pavan,
> 
>  Isn't it possible to provide a commit log in the kernel side etc,
> >> that
>  let
>  others to verify why only 64 bit is required, or if someone want
> >> to
>  support
>  32bit that may help them to investigate the source of the
>  restriction.
> >>>
> >>> Arch 32 support is not implemented on ThunderX, so 32bit will
> >> not
> >> run.
> >>>
> >>
> >> I see, is following correct:
> >> All thunderx, octeonx & octeontx2 only supports VF in the DPDK,
>  and PF
> >> is
> >> supported by Linux kernel driver. And Linux kernel driver doesn't
> >> support arch32.
> >
> > AF != PF, AF is something that manages all the shared resources
>  between PF/VF.
> >
> 
>  I see, I though AF is part of PF functionality. Are there two different
>  kernel
>  modules for PF and AF?
> 
>  So can DPDK driver drive PF? In a way, PF by DPDK, VF by DPDK, AF
> >> by
>  Linux
>  kernel driver.
> >>>
> >>> Yup that’s correct.
> >>>
> 
> >>
> >> Is something changed in kernel driver side to drop the 32bit
> >> support?
> >> If it was not supported at all, what is the motivation to disable the
>  DPDK
> >> drivers now?
> >>
> >
> > It was never supported to begin with, motivation is that build will
> >> fail if
>  we try to
> > compile with 32b.
> >
> 
>  If there is no plan to support 32bit in the kernel side, that is
> >> reasonable
>  to
>  disable 32bit build, please provide above details in the commit log.
> 
>  And after above said, how much maintenance cost to support 32bit,
> >> if
>  the build
>  error is on the logging format "%lx" etc .. (as we mostly have 32bit
> >> build
>  errors), it is better to fix them using 'PRIx64' which is more proper
> >> way
>  anyway. If there is more logical issue with 32bit pointers, I agree with
>  you to
>  disable it.
>  Can you please provided the build error in the commit log as record?
> 
> >>>
> >>> Apologies, I meant that all the functions that don’t fall under 64b are
> >> stubbed out
> >>> so the driver wouldn’t work.
> >>>
> >>
> >> so is there build error or not?
> >>
> >
> > No build error.
> >
>
> Just trying to clarify,
>
> Linux kernel AF kernel driver only build for 64-bit Linux.
> And mentioned DPDK drivers have a dependency to this kernel module.
>
> But DPDK drivers are userspace application, can't 32-bit application
> run on 64-bit Linux?
>
> Can you please clarify what exactly is not supported?


armv8 specification has two operating modes,

1) AArch32 mode, where a 32 bit application can run on armv8
2) AArch64 mode, where it is native 64bit support.

In Thunderx and Octeon families, AArch32 mode is not implemented to save
the power and RTL cost. So it can never use AArch32 32bit mode.

There was an attempt to emulate 32bit mode in 64 bit like X32_ABI, it
is called IPL32 in arm64, that never became mainstream. So 32bit application
can not run on ThunderX/Octeontx so we would like to remove building this option
to avoid removing the cost of maintaining it.



>
>
> 
> > Signed-off-by: Pavan Nikhilesh 
> > Acked-by: Jerin Jacob 
> > ---
> >   v5 Changes
> >   - s/fuction/function.
> >
> >   v4 Changes:
> >   - Update commit message regarding dependency on AF
> >> driver.
> >
> >   drivers/net/thunderx/meson.build | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/thunderx/meson.build
>  b/drivers/net/thunderx/meson.build
> > index 4bbcea7f93..da665bd76f 100644
> > --- a/drivers/net/thunderx/meson.build
> > +++ b/drivers/net/thunderx/meson.build
> > @@ -1,9 +1,9 @@
> >   # SPDX-License-Identifier: BSD-3-Clause
> >   # Copyright(c) 2017 Cavium, Inc
> >
> > -if is_windows
> > +if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
> >   build = false
> > -reason = 'not supported on Windows'
> > +reason = 'only supported on 64-bit Linux'
> >   subdir_done()
> >   endif
> >
> > --
> > 2.17.1
> >
> >>>
> >
> >>>
> >
>

Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue

On Fri, Oct 8, 2021 at 1:56 PM Xueming(Steven) Li  wrote:
>
> On Wed, 2021-09-29 at 13:35 +0530, Jerin Jacob wrote:
> > On Wed, Sep 29, 2021 at 1:11 PM Xueming(Steven) Li  
> > wrote:
> > >
> > > On Tue, 2021-09-28 at 20:29 +0530, Jerin Jacob wrote:
> > > > On Tue, Sep 28, 2021 at 8:10 PM Xueming(Steven) Li 
> > > >  wrote:
> > > > >
> > > > > On Tue, 2021-09-28 at 13:59 +, Ananyev, Konstantin wrote:
> > > > > > >
> > > > > > > On Tue, Sep 28, 2021 at 6:55 PM Xueming(Steven) Li
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Tue, 2021-09-28 at 18:28 +0530, Jerin Jacob wrote:
> > > > > > > > > On Tue, Sep 28, 2021 at 5:07 PM Xueming(Steven) Li
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, 2021-09-28 at 15:05 +0530, Jerin Jacob wrote:
> > > > > > > > > > > On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit wrote:
> > > > > > > > > > > > > On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > Sent: Wednesday, August 11, 2021 4:03 PM
> > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > ; NBU-Contact-Thomas
> > > > > > > > > > > > > > > Monjalon
> > > > > > > ;
> > > > > > > > > > > > > > > Andrew Rybchenko 
> > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) Li
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > > > Sent: Monday, August 9, 2021 9:51 PM
> > > > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > > > > NBU-Contact-Thomas Monjalon
> > > > > > > > > > > > > > > > > ; Andrew Rybchenko
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 5:18 PM Xueming Li
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > In current DPDK framework, each RX queue is
> > > > > > > > > > > > > > > > > > pre-loaded with mbufs
> > > > > > > > > > > > > > > > > > for incoming packets. When number of
> > > > > > > > > > > > > > > > > > representors scale out in a
> > > > > > > > > > > > > > > > > > switch domain, the memory consumption became
> > > > > > > > > > > > > > > > > > significant. Most
> > > > > > > > > > > > > > > > > > important, polling all ports leads to high
> > > > > > > > > > > > > > > > > > cache miss, high
> > > > > > > > > > > > > > > > > > latency and low throughput.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This patch introduces shared RX queue. Ports
> > > > > > > > > > > > > > > > > > with same
> > > > > > > > > > > > > > > > > > configuration in a switch domain could share
> > > > > > > > > > > > > > > > > > RX queue set by specifying sharing group.
> > > > > > > > > > > > > > > > > > Polling any queue using same shared RX queue
> > > > > > > > > > > > > > > > > > receives packets from
> > > > > > > > > > > > > > > > > > all member ports. Source port is identified
> > > > > > > > > > > > > > > > > > by mbuf->port.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Port queue number in a shared group should 
> > > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > identical. Queue
> > > > > > > > > > > > > > > > > > index is
> > > > > > > > > > > > > > > > > > 1:1 mapped in shared group.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Share RX queue is supposed to be polled on
> > > > > > > > > > > > > > > > > > same thread.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Multiple groups is supported by group ID.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Is this offload specific to the representor? 
> > > > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > > so can this name be changed specifically to
> > > > > > > > > > > > > > > > > representor?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Yes, PF and representor in switch domain could
> > > > > > > > > > > > > > > > take advantage.
> > > > > > >

Re: [dpdk-dev] [PATCH v5 4/6] ethdev: remove jumbo offload flag

2021-10-10 Thread Matan Azrad




From: Ferruh Yigit
> Removing 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag.
> 
> Instead of drivers announce this capability, application can deduct the
> capability by checking reported 'dev_info.max_mtu' or
> 'dev_info.max_rx_pktlen'.
> 
> And instead of application setting this flag explicitly to enable jumbo
> frames, this can be deduced by driver by comparing requested 'mtu' to
> 'RTE_ETHER_MTU'.
> 
> Removing this additional configuration for simplification.
> 
> Suggested-by: Konstantin Ananyev 
> Signed-off-by: Ferruh Yigit 
> Acked-by: Andrew Rybchenko 
> Reviewed-by: Rosen Xu 
> Acked-by: Somnath Kotur 

Acked-by: Matan Azrad 
For mlx4/5 PMDs.

Re: [dpdk-dev] [PATCH v3 0/9] GPU library

On Fri, Oct 8, 2021 at 11:13 PM  wrote:
>
> From: eagostini 
>
> In heterogeneous computing system, processing is not only in the CPU.
> Some tasks can be delegated to devices working in parallel.
>
> The goal of this new library is to enhance the collaboration between
> DPDK, that's primarily a CPU framework, and GPU devices.
>
> When mixing network activity with task processing on a non-CPU device,
> there may be the need to put in communication the CPU with the device
> in order to manage the memory, synchronize operations, exchange info, etc..
>
> This library provides a number of new features:
> - Interoperability with GPU-specific library with generic handlers
> - Possibility to allocate and free memory on the GPU
> - Possibility to allocate and free memory on the CPU but visible from the GPU
> - Communication functions to enhance the dialog between the CPU and the GPU

In the RFC thread, There was one outstanding non technical issues on this,

i.e
The above features are driver specific details. Does the DPDK
_application_ need to be aware of this?
aka DPDK device class has a fixed personality and it has API to deal
with abstracting specific application specific
end user functionality like ethdev, cryptodev, eventdev irrespective
of underlying bus/device properties.

Even similar semantics are required for DPU(Smart NIC)
communitication. I am planning to
send RFC in coming days to address the issue without the application
knowing the Bus/HW/Driver details.

Irrespective of the RFC I am planning to send and since the new
library needs techboard approval, You may
request that the techboard decide approval for this library. Also, As
far as I remember a minimum a SW driver in
additional to HW driver to accept a new driver class.

Just my 2c to save your cycles.

Re: [dpdk-dev] [PATCH v4 1/6] ethdev: fix max Rx packet length

2021-10-10 Thread Matan Azrad



Hi Ferruh

From: Ferruh Yigit
> There is a confusion on setting max Rx packet length, this patch aims to
> clarify it.
> 
> 'rte_eth_dev_configure()' API accepts max Rx packet size via
> 'uint32_t max_rx_pkt_len' field of the config struct 'struct
> rte_eth_conf'.
> 
> Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result
> stored into '(struct rte_eth_dev)->data->mtu'.
> 
> These two APIs are related but they work in a disconnected way, they
> store the set values in different variables which makes hard to figure
> out which one to use, also having two different method for a related
> functionality is confusing for the users.
> 
> Other issues causing confusion is:
> * maximum transmission unit (MTU) is payload of the Ethernet frame. And
>   'max_rx_pkt_len' is the size of the Ethernet frame. Difference is
>   Ethernet frame overhead, and this overhead may be different from
>   device to device based on what device supports, like VLAN and QinQ.
> * 'max_rx_pkt_len' is only valid when application requested jumbo frame,
>   which adds additional confusion and some APIs and PMDs already
>   discards this documented behavior.
> * For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory
>   field, this adds configuration complexity for application.
> 
> As solution, both APIs gets MTU as parameter, and both saves the result
> in same variable '(struct rte_eth_dev)->data->mtu'. For this
> 'max_rx_pkt_len' updated as 'mtu', and it is always valid independent
> from jumbo frame.
> 
> For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user
> request and it should be used only within configure function and result
> should be stored to '(struct rte_eth_dev)->data->mtu'. After that point
> both application and PMD uses MTU from this variable.
> 
> When application doesn't provide an MTU during 'rte_eth_dev_configure()'
> default 'RTE_ETHER_MTU' value is used.
> 
> Additional clarification done on scattered Rx configuration, in
> relation to MTU and Rx buffer size.
> MTU is used to configure the device for physical Rx/Tx size limitation,
> Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer
> size as Rx buffer size.
> PMDs compare MTU against Rx buffer size to decide enabling scattered Rx
> or not. If scattered Rx is not supported by device, MTU bigger than Rx
> buffer size should fail.

Should it be compared also against max_lro_pkt_size for the SCATTER enabling by 
the PMD?

What do you think about enabling SCATTER by the API instead of making the 
comparison in each PMD?

> Signed-off-by: Ferruh Yigit 



Please see more below regarding SCATTER.
 
> diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
> index 978cbb8201ea..4a5cfd22aa71 100644
> --- a/drivers/net/mlx4/mlx4_rxq.c
> +++ b/drivers/net/mlx4/mlx4_rxq.c
> @@ -753,6 +753,7 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev,
> uint16_t idx, uint16_t desc,
> int ret;
> uint32_t crc_present;
> uint64_t offloads;
> +   uint32_t max_rx_pktlen;
> 
> offloads = conf->offloads | dev->data->dev_conf.rxmode.offloads;
> 
> @@ -828,13 +829,11 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev,
> uint16_t idx, uint16_t desc,
> };
> /* Enable scattered packets support for this queue if necessary. */
> MLX4_ASSERT(mb_len >= RTE_PKTMBUF_HEADROOM);
> -   if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
> -   (mb_len - RTE_PKTMBUF_HEADROOM)) {
> +   max_rx_pktlen = dev->data->mtu + RTE_ETHER_HDR_LEN +
> RTE_ETHER_CRC_LEN;
> +   if (max_rx_pktlen <= (mb_len - RTE_PKTMBUF_HEADROOM)) {
> ;
> } else if (offloads & DEV_RX_OFFLOAD_SCATTER) {
> -   uint32_t size =
> -   RTE_PKTMBUF_HEADROOM +
> -   dev->data->dev_conf.rxmode.max_rx_pkt_len;
> +   uint32_t size = RTE_PKTMBUF_HEADROOM + max_rx_pktlen;
> uint32_t sges_n;
> 
> /*
> @@ -846,21 +845,19 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev,
> uint16_t idx, uint16_t desc,
> /* Make sure sges_n did not overflow. */
> size = mb_len * (1 << rxq->sges_n);
> size -= RTE_PKTMBUF_HEADROOM;
> -   if (size < dev->data->dev_conf.rxmode.max_rx_pkt_len) {
> +   if (size < max_rx_pktlen) {
> rte_errno = EOVERFLOW;
> ERROR("%p: too many SGEs (%u) needed to handle"
>   " requested maximum packet size %u",
>   (void *)dev,
> - 1 << sges_n,
> - dev->data->dev_conf.rxmode.max_rx_pkt_len);
> + 1 << sges_n, max_rx_pktlen);
> goto error;
> }
> } else {
> WARN("%p: the requested maximum Rx packet size (%u) is"
>  " larger than a single mbuf (%

Re: [dpdk-dev] [PATCH v3] net/e1000: build on Windows

2021-10-10 Thread Wang, Haiyue

> -Original Message-
> From: Dmitry Kozlyuk 
> Sent: Sunday, October 10, 2021 01:28
> To: William Tu 
> Cc: dev@dpdk.org; Wang, Haiyue ; Kadam, Pallavi 
> 
> Subject: Re: [PATCH v3] net/e1000: build on Windows
> 
> 2021-10-09 09:31 (UTC-0700), William Tu:
> > [...]
> > * @Dmitry: I think it's better keep the doc for
> >   people to reference NetUIO setup.
> 
> I won't insist, especially since Intel is OK with this.
> I've sent a patch to put the link in Windows GSG
> so that we won't need to repeat it for each PMD:
> http://inbox.dpdk.org/dev/20211008211154.349793-1-dmitry.kozl...@gmail.com/T/#u

+1, This is better.

For PMD itself, it just need to set 'Windows = Y' in *ini if it supports 
Windows.

Re: [dpdk-dev] [PATCH v2 01/12] ethdev: add port representor item to flow API


Hi Ori,

Thanks a lot for reviewing this.

On 10/10/2021 14:15, Ori Kam wrote:

Hi Ivan,


From the new patches I saw you choose port_representor and represented_port

Didn't we agree to go with ETHDEV_PORT and SHADOW_PORT?


Yes, in the previous thread I suggested a different option. But
I gave it more thought and decided to go for PORT_REPRESENTOR
and REPRESENTED_PORT instead. In any case, I apologise for it
being such short notice.


The only thing that worries me is that the naming are very easy to get wrong.
port_representor and represented_port.


Is that so? In "port representor", the key word is "representor", a
noun. In "represented port", the key word is "port". Word "represented"
acts like an adjective. More to that, the order of words is chosen on
purpose to prevent someone from accidentally writing "representOR_port"
in their code, for example. That simply won't compile.

Well, at least, these two are harder to get wrong compared to "employer"
and "employee", for example.

The new names are better because they are paired terms. Each one
suggests the existence of the other one. This spares one from the
need to have wordy explanations of the symmetry of the diagram.
The new names speak themselves.

Saying "shadow" is in fact vague. The reader doesn't see clearly
that it's the shadow of the ethdev. And, in turn, "ethdev" is also
not as good as "representor". It's even hard to pronounce because
of being a combination of multiple contractions.

I hope you get the idea.



Also there is an issue with wording if we assume like in previous thread that
DPDK can have both the representor port and also the represented_port.
While if we look at for example ethdev_port and shadow port are better defined
as ethdev_port -> the port that is closest to the DPDK ethdev while shadow port
is defined as the other side of the ethdev port.

What do you think?


The semantics hasn't changed since the previous thread.
Representor coincides with the ethdev, so it's still the closest port.
And represented port is still the other side. It's all the same in fact.

If both VF and its representor are plugged to DPDK, they represent each
other in fact. Mutual representors. You can equally name the first one
a representor and the other one a represented port, - and vice versa.

The new naming doesn't deny both these ports being ethdevs, while
the previous option (ethdev and shadow) may trick the reader into
thinking that only one of the two can be an ethdev. The reader may
think that this use case (when VF and its representor are plugged to
the application) is completely wrong. Let's avoid this mistake.




-Original Message-
From: Ivan Malov 
Sent: Sunday, October 10, 2021 3:05 AM
Subject: [PATCH v2 01/12] ethdev: add port representor item to flow API
?
For use in "transfer" flows. Supposed to match traffic entering the embedded
switch from the given ethdev.



I would also add a comment that says the since we are in transfer it means
that all rules are located in the E-Switch which means that the matching is done
on the source port of the traffic.


Let me put it clear: I don't mind adding more comments. I can do that,
yes. But look. You say "matching is done on the source port". Isn't that
what "entering the embedded switch FROM the given ethdev" already says?



I think this will also help understand the view point that we are looking from 
the point
of the switch, and to add the drawing.


Well, as I said, technically, I don't object adding more comments. But
the above description says: "entering the embedded switch". Doesn't it
indicate the viewpoint clear enough? Should I reword this?

Also, "flow engine" is showed in the diagram. And there are arrows.
Doesn't that explain the viewpoint fully?

I'm ready to discuss / improve.





Must not be combined with direction attributes.

Signed-off-by: Ivan Malov 
---
  app/test-pmd/cmdline_flow.c | 27 ++
  doc/guides/prog_guide/rte_flow.rst  | 59 +
  doc/guides/rel_notes/release_21_11.rst  |  2 +
  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++
  lib/ethdev/rte_flow.c   |  1 +
  lib/ethdev/rte_flow.h   | 27 ++
  6 files changed, 120 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index
bb22294dd3..a912a8d815 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+   ITEM_PORT_REPRESENTOR,
+   ITEM_PORT_REPRESENTOR_PORT_ID,

/* Validate/create actions. */
ACTIONS,
@@ -1000,6 +1002,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+   ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
  };
@@ -1368,6 +1371,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
  };

+static const enum index it

Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue

2021-10-10 Thread Xueming(Steven) Li

On Sun, 2021-10-10 at 15:16 +0530, Jerin Jacob wrote:
> On Fri, Oct 8, 2021 at 1:56 PM Xueming(Steven) Li  wrote:
> > 
> > On Wed, 2021-09-29 at 13:35 +0530, Jerin Jacob wrote:
> > > On Wed, Sep 29, 2021 at 1:11 PM Xueming(Steven) Li  
> > > wrote:
> > > > 
> > > > On Tue, 2021-09-28 at 20:29 +0530, Jerin Jacob wrote:
> > > > > On Tue, Sep 28, 2021 at 8:10 PM Xueming(Steven) Li 
> > > > >  wrote:
> > > > > > 
> > > > > > On Tue, 2021-09-28 at 13:59 +, Ananyev, Konstantin wrote:
> > > > > > > > 
> > > > > > > > On Tue, Sep 28, 2021 at 6:55 PM Xueming(Steven) Li
> > > > > > > >  wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 2021-09-28 at 18:28 +0530, Jerin Jacob wrote:
> > > > > > > > > > On Tue, Sep 28, 2021 at 5:07 PM Xueming(Steven) Li
> > > > > > > > > >  wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, 2021-09-28 at 15:05 +0530, Jerin Jacob wrote:
> > > > > > > > > > > > On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit wrote:
> > > > > > > > > > > > > > On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > > Sent: Wednesday, August 11, 2021 4:03 PM
> > > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > > ; NBU-Contact-Thomas
> > > > > > > > > > > > > > > > Monjalon
> > > > > > > > ;
> > > > > > > > > > > > > > > > Andrew Rybchenko 
> > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 7:46 PM Xueming(Steven) 
> > > > > > > > > > > > > > > > Li
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > > > > Sent: Monday, August 9, 2021 9:51 PM
> > > > > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > > > > > NBU-Contact-Thomas Monjalon
> > > > > > > > > > > > > > > > > > ; Andrew Rybchenko
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 5:18 PM Xueming Li
> > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > In current DPDK framework, each RX queue 
> > > > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > > > pre-loaded with mbufs
> > > > > > > > > > > > > > > > > > > for incoming packets. When number of
> > > > > > > > > > > > > > > > > > > representors scale out in a
> > > > > > > > > > > > > > > > > > > switch domain, the memory consumption 
> > > > > > > > > > > > > > > > > > > became
> > > > > > > > > > > > > > > > > > > significant. Most
> > > > > > > > > > > > > > > > > > > important, polling all ports leads to high
> > > > > > > > > > > > > > > > > > > cache miss, high
> > > > > > > > > > > > > > > > > > > latency and low throughput.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > This patch introduces shared RX queue. 
> > > > > > > > > > > > > > > > > > > Ports
> > > > > > > > > > > > > > > > > > > with same
> > > > > > > > > > > > > > > > > > > configuration in a switch domain could 
> > > > > > > > > > > > > > > > > > > share
> > > > > > > > > > > > > > > > > > > RX queue set by specifying sharing group.
> > > > > > > > > > > > > > > > > > > Polling any queue using same shared RX 
> > > > > > > > > > > > > > > > > > > queue
> > > > > > > > > > > > > > > > > > > receives packets from
> > > > > > > > > > > > > > > > > > > all member ports. Source port is 
> > > > > > > > > > > > > > > > > > > identified
> > > > > > > > > > > > > > > > > > > by mbuf->port.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Port queue number in a shared group 
> > > > > > > > > > > > > > > > > > > should be
> > > > > > > > > > > > > > > > > > > identical. Queue
> > > > > > > > > > > > > > > > > > > index is
> > > > > > > > > > > > > > > > > > > 1:1 mapped in shared group.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Share RX queue is supposed to be polled on
> > > > > > > > > > > > > > > > > > > same thread.
> > > > > > > > > > > > > > > > > > > 
> > > > > > >

[dpdk-dev] [PATCH v3 00/12] ethdev: rework transfer flow API

As per RFC [1], action PORT_ID appears to be ambiguous. Its name suggests
that matching traffic be sent to the ethdev with the specified ID, that
is, to the application. However, in Open vSwitch, the action is used to
send traffic to a remote entity represented by the given port, that is,
in the opposite direction. Its interpretation across PMDs also varies.

RFC [2] attempted to define action PORT_ID semantics in vSwitch sense.
However, this solution would completely abandon the opposite meaning.

One more effort, RFC [3], was meant to declare that the use of direction
attributes in "transfer" flows assumed implicit filtering by the port ID
appearing as the first argument in rte_flow_create(). However, not all
PMDs require such filtering, so the RFC turned out rather disputable.

Since then, all of that has been given more thought:

1. One should not attempt to fix action PORT_ID. Instead, two new actions
should be introduced. The first one should send traffic to the given
ethdev. The second one should send it to the represented entity.

2. Similar to (1), two new items should be defined. The first one should
match traffic going down from the given ethdev. The second one should
match traffic going up from the entity represented by that ethdev.

3. The application always knows which packets come through which ethdevs.
So, as per (2), the application can use the new item to match traffic
arriving from precise entities represented by the relevant ethdev IDs.

4. New items suggested in (2) do not require the use of direction
attributes. These items define precise directions on their own.

5. As a consequence of (3) and (4), the problem of implicit filtering
by rte_flow_create() port ID argument and direction attributes is
no longer a blocker. The new items allow to dispose of it.

The new items appear to be symmetrical to each other. So do the new
actions. This requires that their names reflect the symmetry. Also,
the names should respect the existing concept of port representors.
By the looks of it, terms "PORT_REPRESENTOR" and "REPRESENTED_PORT"
satisfy these requirements. However, currently, ethdevs associated
with network ports are not considered as their representors. Such
understanding is mentioned in the documentation, but it's not
expressed in the code (see enum rte_eth_representor_type).

The short of it, this patch series follows points (1-5) to rework
support for "transfer" flows accordingly. On the way, a string of
ambiguous pattern items (PF, VF, PHY_PORT) is deprecated.

The patch series also updates PMDs which support item and action PORT_ID
to add support for replacements (1-2). However, there're some exceptions:

- Support for traffic source items in the case of net/mlx5 is really
complicated. This series does not rework it. The PMD maintainer
can do the job much better and test the new code accordingly;

- Support for action REPRESENTED_PORT is not added to net/sfc.
This will be done when support for VF representors has been
upstreamed, just for the new code to apply cleanly.

Changes in v2:
* New naming and reworked comments
* New diagrams

Changes in v3:
* Diagram improvements
* Spelling fixes

[1]
https://patches.dpdk.org/project/dpdk/patch/20210907125157.3843-1-ivan.ma...@oktetlabs.ru/
[2]
https://patches.dpdk.org/project/dpdk/patch/20210903074610.313622-1-andrew.rybche...@oktetlabs.ru/
[3]
https://patches.dpdk.org/project/dpdk/patch/20210901151104.3923889-1-andrew.rybche...@oktetlabs.ru/

Andrew Rybchenko (6):
net/bnxt: support meta flow items to match on traffic source
net/bnxt: support meta flow actions to overrule destinations
net/enic: support meta flow actions to overrule destinations
net/mlx5: support represented port flow action
net/octeontx2: support port representor flow action
net/sfc: support port representor flow item

Ivan Malov (6):
ethdev: add port representor item to flow API
ethdev: add represented port item to flow API
ethdev: add port representor action to flow API
ethdev: add represented port action to flow API
ethdev: deprecate hard-to-use or ambiguous items and actions
ethdev: deprecate direction attributes in transfer flows

[dpdk-dev] [PATCH v3 01/12] ethdev: add port representor item to flow API

For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.

Must not be combined with direction attributes.

Signed-off-by: Ivan Malov 
---
 app/test-pmd/cmdline_flow.c | 27 ++
 doc/guides/prog_guide/rte_flow.rst  | 59 +
 doc/guides/rel_notes/release_21_11.rst  |  2 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 27 ++
 6 files changed, 120 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index bb22294dd3..a912a8d815 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+   ITEM_PORT_REPRESENTOR,
+   ITEM_PORT_REPRESENTOR_PORT_ID,
 
/* Validate/create actions. */
ACTIONS,
@@ -1000,6 +1002,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+   ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
 };
@@ -1368,6 +1371,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
 };
 
+static const enum index item_port_representor[] = {
+   ITEM_PORT_REPRESENTOR_PORT_ID,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3608,6 +3617,21 @@ static const struct token token_list[] = {
 item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack, flags)),
},
+   [ITEM_PORT_REPRESENTOR] = {
+   .name = "port_representor",
+   .help = "match traffic entering the embedded switch from the 
given ethdev",
+   .priv = PRIV_ITEM(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_item_ethdev)),
+   .next = NEXT(item_port_representor),
+   .call = parse_vc,
+   },
+   [ITEM_PORT_REPRESENTOR_PORT_ID] = {
+   .name = "port_id",
+   .help = "ethdev port ID",
+   .next = NEXT(item_port_representor, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+   },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8343,6 +8367,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_PFCP:
mask = &rte_flow_item_pfcp_mask;
break;
+   case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+   mask = &rte_flow_item_ethdev_mask;
+   break;
default:
break;
}
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..91d5bdd712 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
 - ``flags``: conntrack packet state flags.
 - Default ``mask`` matches all state bits.
 
+Item: ``PORT_REPRESENTOR``
+^^
+
+Matches traffic entering the embedded switch from the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+..
+|  PORT_REPRESENTOR  |  Ethdev (Application Port Referred to by its ID)
+''
+  ||
+  \/
+  ..
+  |  Logical Port  |
+  ''
+  ||
+  ||
+  ||
+  \/
+ .--.
+ |  Switch  |
+ '--'
+  :
+   :
+  :
+   :
+  ..
+  |  Logical Port  |
+  ''
+  :
+   :
+..
+|  REPRESENTED_PORT  |  Net / Guest / Another Ethdev (Same Application)
+''
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_item_ethdev:
+
+.. table:: ``struct rte_flow_item_ethdev``
+
+   +--+-+---+
+   | Field| Subfield| Value |
+   +==+=+===+
+   | ``spec`` | ``port_id`` | ethdev port ID|
+   +--+-+---+
+   | ``last`` | ``port_id`` | upper range value |
+   +--+-+---+
+   | ``mask`` | ``port_id`` | zeroed for wildcard match |
+   +--+-+---+

[dpdk-dev] [PATCH v3 02/12] ethdev: add represented port item to flow API

For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.

Must not be combined with direction attributes.

Signed-off-by: Ivan Malov 
---
 app/test-pmd/cmdline_flow.c | 25 +++
 doc/guides/prog_guide/rte_flow.rst  | 46 +
 doc/guides/rel_notes/release_21_11.rst  |  2 +-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  5 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 13 +-
 6 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index a912a8d815..68698d805d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -308,6 +308,8 @@ enum index {
ITEM_POL_POLICY,
ITEM_PORT_REPRESENTOR,
ITEM_PORT_REPRESENTOR_PORT_ID,
+   ITEM_REPRESENTED_PORT,
+   ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
 
/* Validate/create actions. */
ACTIONS,
@@ -1003,6 +1005,7 @@ static const enum index next_item[] = {
ITEM_INTEGRITY,
ITEM_CONNTRACK,
ITEM_PORT_REPRESENTOR,
+   ITEM_REPRESENTED_PORT,
END_SET,
ZERO,
 };
@@ -1377,6 +1380,12 @@ static const enum index item_port_representor[] = {
ZERO,
 };
 
+static const enum index item_represented_port[] = {
+   ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3632,6 +3641,21 @@ static const struct token token_list[] = {
 item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
},
+   [ITEM_REPRESENTED_PORT] = {
+   .name = "represented_port",
+   .help = "match traffic entering the embedded switch from the 
entity represented by the given ethdev",
+   .priv = PRIV_ITEM(REPRESENTED_PORT,
+ sizeof(struct rte_flow_item_ethdev)),
+   .next = NEXT(item_represented_port),
+   .call = parse_vc,
+   },
+   [ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+   .name = "ethdev_port_id",
+   .help = "ethdev port ID",
+   .next = NEXT(item_represented_port, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+   },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8368,6 +8392,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
mask = &rte_flow_item_pfcp_mask;
break;
case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+   case RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT:
mask = &rte_flow_item_ethdev_mask;
break;
default:
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 91d5bdd712..12a216c1e3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,52 @@ at the opposite end of the "wire" leading to the ethdev.
 
 - Default ``mask`` provides exact match behaviour.
 
+Item: ``REPRESENTED_PORT``
+^^
+
+Matches traffic entering the embedded switch from
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+..
+|  PORT_REPRESENTOR  |  Ethdev (Application Port Referred to by its ID)
+''
+  :
+   :
+  ..
+  |  Logical Port  |
+  ''
+  :
+   :
+  :
+   :
+ .--.
+ |  Switch  |
+ '--'
+  /\
+  ||
+  ||
+  ||
+  ..
+  |  Logical Port  |
+  ''
+  /\
+  ||
+..
+|  REPRESENTED_PORT  |  Net / Guest / Another Ethdev (Same Application)
+''
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+
 Actions
 ~~~
 
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 1261cb2bf3..39ff16780b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -188,7 +188,7 @@ API Changes
Also, make sure to start the

[dpdk-dev] [PATCH v3 03/12] ethdev: add port representor action to flow API

For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.

Signed-off-by: Ivan Malov 
---
 app/test-pmd/cmdline_flow.c | 26 ++
 doc/guides/prog_guide/rte_flow.rst  | 56 +
 doc/guides/rel_notes/release_21_11.rst  |  2 +-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  5 ++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 18 +++
 6 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 68698d805d..ee6dac411a 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -460,6 +460,8 @@ enum index {
ACTION_POL_G,
ACTION_POL_Y,
ACTION_POL_R,
+   ACTION_PORT_REPRESENTOR,
+   ACTION_PORT_REPRESENTOR_PORT_ID,
 };
 
 /** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1452,6 +1454,7 @@ static const enum index next_action[] = {
ACTION_MODIFY_FIELD,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
+   ACTION_PORT_REPRESENTOR,
ZERO,
 };
 
@@ -1733,6 +1736,12 @@ static const enum index action_update_conntrack[] = {
ZERO,
 };
 
+static const enum index action_port_representor[] = {
+   ACTION_PORT_REPRESENTOR_PORT_ID,
+   ACTION_NEXT,
+   ZERO,
+};
+
 static int parse_set_raw_encap_decap(struct context *, const struct token *,
 const char *, unsigned int,
 void *, unsigned int);
@@ -4820,6 +4829,23 @@ static const struct token token_list[] = {
.next = NEXT(action_update_conntrack),
.call = parse_vc_action_conntrack_update,
},
+   [ACTION_PORT_REPRESENTOR] = {
+   .name = "port_representor",
+   .help = "at embedded switch level, send matching traffic to the 
given ethdev",
+   .priv = PRIV_ACTION(PORT_REPRESENTOR,
+   sizeof(struct rte_flow_action_ethdev)),
+   .next = NEXT(action_port_representor),
+   .call = parse_vc,
+   },
+   [ACTION_PORT_REPRESENTOR_PORT_ID] = {
+   .name = "port_id",
+   .help = "ethdev port ID",
+   .next = NEXT(action_port_representor,
+NEXT_ENTRY(COMMON_UNSIGNED)),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+   port_id)),
+   .call = parse_vc_conf,
+   },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 12a216c1e3..a6401fb5df 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,8 @@ at the opposite end of the "wire" leading to the ethdev.
 
 - Default ``mask`` provides exact match behaviour.
 
+See also `Action: PORT_REPRESENTOR`_.
+
 Item: ``REPRESENTED_PORT``
 ^^
 
@@ -3104,6 +3106,60 @@ which is set in the packet meta-data (i.e. struct 
``rte_mbuf::sched::color``)
| ``meter_color`` | Packet color |
+-+--+
 
+Action: ``PORT_REPRESENTOR``
+
+
+At embedded switch level, send matching traffic to the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+..
+|  PORT_REPRESENTOR  |  Ethdev (Application Port Referred to by its ID)
+''
+  /\
+  ||
+  ..
+  |  Logical Port  |
+  ''
+  /\
+  ||
+  ||
+  ||
+ .--.   ..
+ |  Switch  |  <==  |  Matching Traffic  |
+ '--'   ''
+  :
+   :
+  :
+   :
+  ..
+  |  Logical Port  |
+  ''
+  :
+   :
+..
+|  REPRESENTED_PORT  |  Net / Guest / Another Ethdev (Same Application)
+''
+
+
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_action_ethdev:
+
+.. table:: ``struct rte_flow_action_ethdev``
+
+   +-++
+   | Field   | Value  |
+   +=++
+   | ``port_id`` | ethdev port ID |
+   +-++
+
+See also `Item: PORT_REPRESENTOR`_.
+
 Negative types
 ~~
 
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 3

[dpdk-dev] [PATCH v3 04/12] ethdev: add represented port action to flow API

For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.

Signed-off-by: Ivan Malov 
---
 app/test-pmd/cmdline_flow.c | 26 +++
 doc/guides/prog_guide/rte_flow.rst  | 49 +
 doc/guides/rel_notes/release_21_11.rst  |  2 +-
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  5 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 11 -
 6 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index ee6dac411a..c704bbaead 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -462,6 +462,8 @@ enum index {
ACTION_POL_R,
ACTION_PORT_REPRESENTOR,
ACTION_PORT_REPRESENTOR_PORT_ID,
+   ACTION_REPRESENTED_PORT,
+   ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
 };
 
 /** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1455,6 +1457,7 @@ static const enum index next_action[] = {
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
ACTION_PORT_REPRESENTOR,
+   ACTION_REPRESENTED_PORT,
ZERO,
 };
 
@@ -1742,6 +1745,12 @@ static const enum index action_port_representor[] = {
ZERO,
 };
 
+static const enum index action_represented_port[] = {
+   ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
+   ACTION_NEXT,
+   ZERO,
+};
+
 static int parse_set_raw_encap_decap(struct context *, const struct token *,
 const char *, unsigned int,
 void *, unsigned int);
@@ -4846,6 +4855,23 @@ static const struct token token_list[] = {
port_id)),
.call = parse_vc_conf,
},
+   [ACTION_REPRESENTED_PORT] = {
+   .name = "represented_port",
+   .help = "at embedded switch level, send matching traffic to the 
entity represented by the given ethdev",
+   .priv = PRIV_ACTION(REPRESENTED_PORT,
+   sizeof(struct rte_flow_action_ethdev)),
+   .next = NEXT(action_represented_port),
+   .call = parse_vc,
+   },
+   [ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+   .name = "ethdev_port_id",
+   .help = "ethdev port ID",
+   .next = NEXT(action_represented_port,
+NEXT_ENTRY(COMMON_UNSIGNED)),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+   port_id)),
+   .call = parse_vc_conf,
+   },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index a6401fb5df..2bc437e5cd 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1532,6 +1532,8 @@ at the opposite end of the "wire" leading to the ethdev.
 
 This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
 
+See also `Action: REPRESENTED_PORT`_.
+
 Actions
 ~~~
 
@@ -3160,6 +3162,53 @@ at the opposite end of the "wire" leading to the ethdev.
 
 See also `Item: PORT_REPRESENTOR`_.
 
+Action: ``REPRESENTED_PORT``
+
+
+At embedded switch level, send matching traffic to
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+..
+|  PORT_REPRESENTOR  |  Ethdev (Application Port Referred to by its ID)
+''
+  :
+   :
+  ..
+  |  Logical Port  |
+  ''
+  :
+   :
+  :
+   :
+ .--.   ..
+ |  Switch  |  <==  |  Matching Traffic  |
+ '--'   ''
+  ||
+  ||
+  ||
+  \/
+  ..
+  |  Logical Port  |
+  ''
+  ||
+  \/
+..
+|  REPRESENTED_PORT  |  Net / Guest / Another Ethdev (Same Application)
+''
+
+
+- Requires `Attribute: Transfer`_.
+
+This action is meant to use the same structure as `Action: PORT_REPRESENTOR`_.
+
+See also `Item: REPRESENTED_PORT`_.
+
 Negative types
 ~~
 
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index bf46329e52..f689a10e63 100644
--- a/doc/guides/re

[dpdk-dev] [PATCH v3 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions

PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.

The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.

Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.

Signed-off-by: Ivan Malov 
---
 doc/guides/prog_guide/rte_flow.rst | 32 +++
 doc/guides/rel_notes/deprecation.rst   |  9 ++---
 doc/guides/rel_notes/release_21_11.rst |  3 ++
 lib/ethdev/rte_flow.h  | 56 ++
 4 files changed, 94 insertions(+), 6 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 2bc437e5cd..1aa24e0633 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -504,6 +504,10 @@ Usage example, matching non-TCPv4 packets only:
 Item: ``PF``
 
 
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
 Matches traffic originating from (ingress) or going to (egress) the physical
 function of the current device.
 
@@ -531,6 +535,10 @@ the application and thus not associated with a DPDK port 
ID.
 Item: ``VF``
 
 
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
 Matches traffic originating from (ingress) or going to (egress) a given
 virtual function of the current device.
 
@@ -562,6 +570,10 @@ separate entities, should be addressed through their own 
DPDK port IDs.
 Item: ``PHY_PORT``
 ^^
 
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
 Matches traffic originating from (ingress) or going to (egress) a physical
 port of the underlying device.
 
@@ -596,6 +608,10 @@ associated with a port_id should be retrieved by other 
means.
 Item: ``PORT_ID``
 ^
 
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
 Matches traffic originating from (ingress) or going to (egress) a given DPDK
 port ID.
 
@@ -1965,6 +1981,10 @@ only matching traffic goes through.
 Action: ``PF``
 ^^
 
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
 Directs matching traffic to the physical function (PF) of the current
 device.
 
@@ -1985,6 +2005,10 @@ See `Item: PF`_.
 Action: ``VF``
 ^^
 
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
 Directs matching traffic to a given virtual function of the current device.
 
 Packets matched by a VF pattern item can be redirected to their original VF
@@ -2009,6 +2033,10 @@ See `Item: VF`_.
 Action: ``PHY_PORT``
 
 
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
 Directs matching traffic to a given physical port index of the underlying
 device.
 
@@ -2028,6 +2056,10 @@ See `Item: PHY_PORT`_.
 
 Action: ``PORT_ID``
 ^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
 Directs matching traffic to a given DPDK port ID.
 
 See `Item: PORT_ID`_.
diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b86147dda1..c91d570099 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -122,12 +122,6 @@ Deprecation Notices
   is deprecated and will be removed in DPDK 21.11. Shared counters should
   be managed using shared actions API (``rte_flow_shared_action_create`` etc).
 
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
-  is ambiguous and needs clarification.
-  Structure ``rte_flow_action_port_id`` will be extended to specify
-  traffic direction to the represented entity or ethdev port itself
-  in DPDK 21.11.
-
 * ethdev: Flow API documentation is unclear if ethdev port used to create
   a flow rule adds any implicit match criteria in the case of transfer rules.
   The semantics will be clarified in DPDK 21.11 and it will require fixes in
@@ -256,3 +250,6 @@ Deprecation Notices
 * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
   content. On Linux and FreeBSD, supported prior to DPDK 20.11,
   original structure will be kept until DPDK 21.11.
+
+* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
+  deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index f689a10e63..63f946ad88 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -190,6 +190,9 @@ API

[dpdk-dev] [PATCH v3 06/12] ethdev: deprecate direction attributes in transfer flows

Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.

Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).

Signed-off-by: Ivan Malov 
---
 doc/guides/prog_guide/rte_flow.rst | 28 --
 doc/guides/rel_notes/deprecation.rst   |  9 +++---
 doc/guides/rel_notes/release_21_11.rst |  3 ++
 lib/ethdev/rte_flow.h  | 41 --
 4 files changed, 52 insertions(+), 29 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 1aa24e0633..f82b20c7b1 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -9,8 +9,8 @@ Overview
 
 
 This API provides a generic means to configure hardware to match specific
-ingress or egress traffic, alter its fate and query related counters
-according to any number of user-defined rules.
+traffic, alter its fate and query related counters according to any
+number of user-defined rules.
 
 It is named *rte_flow* after the prefix used for all its symbols, and is
 defined in ``rte_flow.h``.
@@ -146,13 +146,10 @@ Note that support for more than a single priority level 
is not guaranteed.
 Attribute: Traffic direction
 
 
-Flow rule patterns apply to inbound and/or outbound traffic.
-
-In the context of this API, **ingress** and **egress** respectively stand
-for **inbound** and **outbound** based on the standpoint of the application
-creating a flow rule.
-
-There are no exceptions to this definition.
+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply
+to inbound and / or outbound traffic. With this respect, ``ingress``
+and ``egress`` respectively stand for **inbound** and **outbound**
+based on the standpoint of the application creating a flow rule.
 
 Several pattern items and actions are valid and can be used in both
 directions. At least one direction must be specified.
@@ -171,12 +168,13 @@ When supported, this effectively enables an application 
to reroute traffic
 not necessarily intended for it (e.g. coming from or addressed to different
 physical ports, VFs or applications) at the device level.
 
-It complements the behavior of some pattern items such as `Item: PHY_PORT`_
-and is meaningless without them.
-
-When transferring flow rules, **ingress** and **egress** attributes
-(`Attribute: Traffic direction`_) keep their original meaning, as if
-processing traffic emitted or received by the application.
+In "transfer" flows, the use of `Attribute: Traffic direction`_ in the sense of
+implicitly matching packets going to or going from the ethdev used to create
+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to
+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as
+the switch serves many different endpoints. The application should match
+traffic originating from precise locations. To do so, it should
+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.
 
 Pattern item
 
diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index c91d570099..02a5b6eeba 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -122,11 +122,6 @@ Deprecation Notices
   is deprecated and will be removed in DPDK 21.11. Shared counters should
   be managed using shared actions API (``rte_flow_shared_action_create`` etc).
 
-* ethdev: Flow API documentation is unclear if ethdev port used to create
-  a flow rule adds any implicit match criteria in the case of transfer rules.
-  The semantics will be clarified in DPDK 21.11 and it will require fixes in
-  drivers and applications which interpret it in a different way.
-
 * ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
   should start with relevant protocol header.
   Some matching pattern structures implements this by duplicating protocol 
header
@@ -253,3 +248,7 @@ Deprecation Notices
 
 * ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
   deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+
+* ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flows
+  is deprecated as ambiguous with respect to the embedded switch. The use of
+  these attributes will become invalid starting from DPDK 22.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 63f946ad88..d4dadbfcf4 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -193,6 +193,9 @@ API Changes
 * ethdev: Deprecated items

[dpdk-dev] [PATCH v3 07/12] net/bnxt: support meta flow items to match on traffic source

From: Andrew Rybchenko 

Add support for items PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for item PORT_ID.

The use of item PORT_ID depends on the specified direction attribute.
Items PORT_REPRESENTOR and REPRESENTED_PORT, in turn, define traffic
direction themselves. The former matches traffic from the driver's
vNIC. The latter matches packets from either a v-port (network) or
a VF's vNIC (if the driver's port is a VF representor).

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c | 10 ++-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  | 77 ++-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.h  |  6 +-
 3 files changed, 70 insertions(+), 23 deletions(-)

diff --git a/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c 
b/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
index 9b165c12b5..d28dd2e587 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
@@ -266,7 +266,7 @@ struct bnxt_ulp_rte_hdr_info ulp_hdr_info[] = {
},
[RTE_FLOW_ITEM_TYPE_PORT_ID] = {
.hdr_type= BNXT_ULP_HDR_TYPE_SUPPORTED,
-   .proto_hdr_func  = ulp_rte_port_id_hdr_handler
+   .proto_hdr_func  = ulp_rte_port_hdr_handler
},
[RTE_FLOW_ITEM_TYPE_RAW] = {
.hdr_type= BNXT_ULP_HDR_TYPE_NOT_SUPPORTED,
@@ -427,6 +427,14 @@ struct bnxt_ulp_rte_hdr_info ulp_hdr_info[] = {
[RTE_FLOW_ITEM_TYPE_HIGIG2] = {
.hdr_type= BNXT_ULP_HDR_TYPE_NOT_SUPPORTED,
.proto_hdr_func  = NULL
+   },
+   [RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR] = {
+   .hdr_type= BNXT_ULP_HDR_TYPE_SUPPORTED,
+   .proto_hdr_func  = ulp_rte_port_hdr_handler
+   },
+   [RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT] = {
+   .hdr_type= BNXT_ULP_HDR_TYPE_SUPPORTED,
+   .proto_hdr_func  = ulp_rte_port_hdr_handler
}
 };
 
diff --git a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c 
b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
index 3a9c9bba27..e1ea8932b0 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
@@ -400,7 +400,8 @@ bnxt_ulp_rte_parser_direction_compute(struct 
ulp_rte_parser_params *params)
 static int32_t
 ulp_rte_parser_svif_set(struct ulp_rte_parser_params *params,
uint32_t ifindex,
-   uint16_t mask)
+   uint16_t mask,
+   enum bnxt_ulp_direction_type item_dir)
 {
uint16_t svif;
enum bnxt_ulp_direction_type dir;
@@ -429,11 +430,14 @@ ulp_rte_parser_svif_set(struct ulp_rte_parser_params 
*params,
bnxt_ulp_rte_parser_direction_compute(params);
 
/* Get the computed direction */
-   dir = ULP_COMP_FLD_IDX_RD(params, BNXT_ULP_CF_IDX_DIRECTION);
-   if (dir == BNXT_ULP_DIR_INGRESS) {
+   dir = (item_dir != BNXT_ULP_DIR_INVALID) ? item_dir :
+   ULP_COMP_FLD_IDX_RD(params, BNXT_ULP_CF_IDX_DIRECTION);
+   if (dir == BNXT_ULP_DIR_INGRESS &&
+   port_type != BNXT_ULP_INTF_TYPE_VF_REP) {
svif_type = BNXT_ULP_PHY_PORT_SVIF;
} else {
-   if (port_type == BNXT_ULP_INTF_TYPE_VF_REP)
+   if (port_type == BNXT_ULP_INTF_TYPE_VF_REP &&
+   item_dir != BNXT_ULP_DIR_EGRESS)
svif_type = BNXT_ULP_VF_FUNC_SVIF;
else
svif_type = BNXT_ULP_DRV_FUNC_SVIF;
@@ -474,7 +478,8 @@ ulp_rte_parser_implicit_match_port_process(struct 
ulp_rte_parser_params *params)
}
 
/* Update the SVIF details */
-   rc = ulp_rte_parser_svif_set(params, ifindex, svif_mask);
+   rc = ulp_rte_parser_svif_set(params, ifindex, svif_mask,
+BNXT_ULP_DIR_INVALID);
return rc;
 }
 
@@ -522,7 +527,8 @@ ulp_rte_pf_hdr_handler(const struct rte_flow_item *item 
__rte_unused,
}
 
/* Update the SVIF details */
-   return  ulp_rte_parser_svif_set(params, ifindex, svif_mask);
+   return ulp_rte_parser_svif_set(params, ifindex, svif_mask,
+  BNXT_ULP_DIR_INVALID);
 }
 
 /* Function to handle the parsing of RTE Flow item VF Header. */
@@ -555,39 +561,72 @@ ulp_rte_vf_hdr_handler(const struct rte_flow_item *item,
return rc;
}
/* Update the SVIF details */
-   return ulp_rte_parser_svif_set(params, ifindex, mask);
+   return ulp_rte_parser_svif_set(params, ifindex, mask,
+  BNXT_ULP_DIR_INVALID);
 }
 
-/* Function to handle the parsing of RTE Flow item port id  Header. */
+/* Parse items PORT_ID, PORT_REPRESENTOR and REPRESENTED_PORT. */
 int32_t
-ulp_rte_port_id_hdr_handler(const struct rte_flow_item *item,
-   struct ulp_rte_parser_params *params)
+ulp_rte_port_hdr_hand

[dpdk-dev] [PATCH v3 08/12] net/bnxt: support meta flow actions to overrule destinations

From: Andrew Rybchenko 

Add support for actions PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for action PORT_ID.

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c | 12 ++-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  | 84 ++-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.h  |  6 +-
 3 files changed, 77 insertions(+), 25 deletions(-)

diff --git a/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c 
b/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
index d28dd2e587..e9337ecd2c 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c
@@ -67,7 +67,7 @@ struct bnxt_ulp_rte_act_info ulp_act_info[] = {
},
[RTE_FLOW_ACTION_TYPE_PORT_ID] = {
.act_type= BNXT_ULP_ACT_TYPE_SUPPORTED,
-   .proto_act_func  = ulp_rte_port_id_act_handler
+   .proto_act_func  = ulp_rte_port_act_handler
},
[RTE_FLOW_ACTION_TYPE_METER] = {
.act_type= BNXT_ULP_ACT_TYPE_NOT_SUPPORTED,
@@ -212,7 +212,15 @@ struct bnxt_ulp_rte_act_info ulp_act_info[] = {
[RTE_FLOW_ACTION_TYPE_SAMPLE] = {
.act_type= BNXT_ULP_ACT_TYPE_SUPPORTED,
.proto_act_func  = ulp_rte_sample_act_handler
-   }
+   },
+   [RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR] = {
+   .act_type= BNXT_ULP_ACT_TYPE_SUPPORTED,
+   .proto_act_func  = ulp_rte_port_act_handler
+   },
+   [RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT] = {
+   .act_type= BNXT_ULP_ACT_TYPE_SUPPORTED,
+   .proto_act_func  = ulp_rte_port_act_handler
+   },
 };
 
 struct bnxt_ulp_rte_act_info ulp_vendor_act_info[] = {
diff --git a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c 
b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
index e1ea8932b0..f0e218d8ec 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
@@ -496,10 +496,11 @@ ulp_rte_parser_implicit_act_port_process(struct 
ulp_rte_parser_params *params)
return BNXT_TF_RC_SUCCESS;
}
port_id.id = ULP_COMP_FLD_IDX_RD(params, BNXT_ULP_CF_IDX_INCOMING_IF);
+   action_item.type = RTE_FLOW_ACTION_TYPE_PORT_ID;
action_item.conf = &port_id;
 
/* Update the action port based on incoming port */
-   ulp_rte_port_id_act_handler(&action_item, params);
+   ulp_rte_port_act_handler(&action_item, params);
 
/* Reset the action port set bit */
ULP_COMP_FLD_IDX_WR(params, BNXT_ULP_CF_IDX_ACT_PORT_IS_SET, 0);
@@ -2168,7 +2169,8 @@ ulp_rte_count_act_handler(const struct rte_flow_action 
*action_item,
 /* Function to handle the parsing of action ports. */
 static int32_t
 ulp_rte_parser_act_port_set(struct ulp_rte_parser_params *param,
-   uint32_t ifindex)
+   uint32_t ifindex,
+   enum bnxt_ulp_direction_type act_dir)
 {
enum bnxt_ulp_direction_type dir;
uint16_t pid_s;
@@ -2178,8 +2180,13 @@ ulp_rte_parser_act_port_set(struct ulp_rte_parser_params 
*param,
uint32_t vnic_type;
 
/* Get the direction */
-   dir = ULP_COMP_FLD_IDX_RD(param, BNXT_ULP_CF_IDX_DIRECTION);
-   if (dir == BNXT_ULP_DIR_EGRESS) {
+   /* If action implicitly specifies direction, use the specification. */
+   dir = (act_dir == BNXT_ULP_DIR_INVALID) ?
+   ULP_COMP_FLD_IDX_RD(param, BNXT_ULP_CF_IDX_DIRECTION) :
+   act_dir;
+   port_type = ULP_COMP_FLD_IDX_RD(param, BNXT_ULP_CF_IDX_ACT_PORT_TYPE);
+   if (dir == BNXT_ULP_DIR_EGRESS &&
+   port_type != BNXT_ULP_INTF_TYPE_VF_REP) {
/* For egress direction, fill vport */
if (ulp_port_db_vport_get(param->ulp_ctx, ifindex, &pid_s))
return BNXT_TF_RC_ERROR;
@@ -2190,9 +2197,17 @@ ulp_rte_parser_act_port_set(struct ulp_rte_parser_params 
*param,
   &pid, BNXT_ULP_ACT_PROP_SZ_VPORT);
} else {
/* For ingress direction, fill vnic */
-   port_type = ULP_COMP_FLD_IDX_RD(param,
-   BNXT_ULP_CF_IDX_ACT_PORT_TYPE);
-   if (port_type == BNXT_ULP_INTF_TYPE_VF_REP)
+   /*
+* Action   Destination
+* 
+* PORT_REPRESENTOR Driver Function
+* 
+* REPRESENTED_PORT VF
+* 
+* PORT_ID  VF
+*/
+   if (act_dir != BNXT_ULP_DIR_INGRESS &&
+   port_type == BNXT_ULP_INTF_TYPE_VF_REP)
vnic_type = BNXT_ULP_VF_FUNC_VNIC;
else
vnic_type = BNXT_ULP_DRV_FUNC_VNIC

[dpdk-dev] [PATCH v3 09/12] net/enic: support meta flow actions to overrule destinations

From: Andrew Rybchenko 

Add support for actions PORT_REPRESENTOR and REPRESENTED_PORT
based on the existing support for action PORT_ID.

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/enic/enic_fm_flow.c | 93 ++---
 1 file changed, 75 insertions(+), 18 deletions(-)

diff --git a/drivers/net/enic/enic_fm_flow.c b/drivers/net/enic/enic_fm_flow.c
index cd364ee16b..4092ff1f61 100644
--- a/drivers/net/enic/enic_fm_flow.c
+++ b/drivers/net/enic/enic_fm_flow.c
@@ -1242,6 +1242,35 @@ vf_egress_port_id_action(struct enic_flowman *fm,
return 0;
 }
 
+static int
+enic_fm_check_transfer_dst(struct enic *enic, uint16_t dst_port_id,
+  struct rte_eth_dev **dst_dev,
+  struct rte_flow_error *error)
+{
+   struct rte_eth_dev *dev;
+
+   ENICPMD_LOG(DEBUG, "port id %u", dst_port_id);
+   if (!rte_eth_dev_is_valid_port(dst_port_id)) {
+   return rte_flow_error_set(error, EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION,
+   NULL, "invalid port_id");
+   }
+   dev = &rte_eth_devices[dst_port_id];
+   if (!dev_is_enic(dev)) {
+   return rte_flow_error_set(error, EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION,
+   NULL, "port_id is not enic");
+   }
+   if (enic->switch_domain_id != pmd_priv(dev)->switch_domain_id) {
+   return rte_flow_error_set(error, EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION,
+   NULL, "destination and source ports are not in the same 
switch domain");
+   }
+
+   *dst_dev = dev;
+   return 0;
+}
+
 /* Translate flow actions to flowman TCAM entry actions */
 static int
 enic_fm_copy_action(struct enic_flowman *fm,
@@ -1446,24 +1475,10 @@ enic_fm_copy_action(struct enic_flowman *fm,
vnic_h = enic->fm_vnic_handle; /* This port */
break;
}
-   ENICPMD_LOG(DEBUG, "port id %u", port->id);
-   if (!rte_eth_dev_is_valid_port(port->id)) {
-   return rte_flow_error_set(error, EINVAL,
-   RTE_FLOW_ERROR_TYPE_ACTION,
-   NULL, "invalid port_id");
-   }
-   dev = &rte_eth_devices[port->id];
-   if (!dev_is_enic(dev)) {
-   return rte_flow_error_set(error, EINVAL,
-   RTE_FLOW_ERROR_TYPE_ACTION,
-   NULL, "port_id is not enic");
-   }
-   if (enic->switch_domain_id !=
-   pmd_priv(dev)->switch_domain_id) {
-   return rte_flow_error_set(error, EINVAL,
-   RTE_FLOW_ERROR_TYPE_ACTION,
-   NULL, "destination and source ports are 
not in the same switch domain");
-   }
+   ret = enic_fm_check_transfer_dst(enic, port->id, &dev,
+error);
+   if (ret)
+   return ret;
vnic_h = pmd_priv(dev)->fm_vnic_handle;
overlap |= PORT_ID;
/*
@@ -1560,6 +1575,48 @@ enic_fm_copy_action(struct enic_flowman *fm,
ovlan |= rte_be_to_cpu_16(vid->vlan_vid);
break;
}
+   case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR: {
+   const struct rte_flow_action_ethdev *ethdev;
+   struct rte_eth_dev *dev;
+
+   ethdev = actions->conf;
+   ret = enic_fm_check_transfer_dst(enic, ethdev->port_id,
+&dev, error);
+   if (ret)
+   return ret;
+   vnic_h = pmd_priv(dev)->fm_vnic_handle;
+   overlap |= PORT_ID;
+   /*
+* Action PORT_REPRESENTOR implies ingress destination.
+* Noting to do. We add an implicit stree at the
+* end if needed.
+*/
+   ingress = 1;
+   break;
+   }
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT: {
+   const struct rte_flow_action_ethdev *ethdev;
+   struct rte_eth_dev *dev;
+
+   if (overlap & PORT_ID) {
+   ENICPMD_LOG(DEBUG, "cannot have multiple egress 
PORT_ID actions");
+   goto unsupported;
+   }
+

[dpdk-dev] [PATCH v3 10/12] net/mlx5: support represented port flow action

From: Andrew Rybchenko 

Semantics of the existing support for action PORT_ID suggests
that support for equal action REPRESENTED_PORT be implemented.

Helper functions keep port_id suffix since action
MLX5_FLOW_ACTION_PORT_ID is still used internally.

Signed-off-by: Andrew Rybchenko 
---
 doc/guides/nics/mlx5.rst|  4 +--
 drivers/net/mlx5/mlx5_flow_dv.c | 62 ++---
 2 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index bae73f42d8..b76e979f47 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -431,8 +431,8 @@ Limitations
  - yellow: NULL or END.
  - RED: DROP / END.
   - The only supported meter policy actions:
- - green: QUEUE, RSS, PORT_ID, JUMP, DROP, MARK and SET_TAG.
- - yellow: QUEUE, RSS, PORT_ID, JUMP, DROP, MARK and SET_TAG.
+ - green: QUEUE, RSS, PORT_ID, REPRESENTED_PORT, JUMP, DROP, MARK and 
SET_TAG.
+ - yellow: QUEUE, RSS, PORT_ID, REPRESENTED_PORT, JUMP, DROP, MARK and 
SET_TAG.
  - RED: must be DROP.
   - Policy actions of RSS for green and yellow should have the same 
configuration except queues.
   - meter profile packet mode is supported.
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index c6370cd1d6..835cc5018c 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5048,14 +5048,14 @@ flow_dv_validate_action_jump(struct rte_eth_dev *dev,
 }
 
 /*
- * Validate the port_id action.
+ * Validate action PORT_ID / REPRESENTED_PORT.
  *
  * @param[in] dev
  *   Pointer to rte_eth_dev structure.
  * @param[in] action_flags
  *   Bit-fields that holds the actions detected until now.
  * @param[in] action
- *   Port_id RTE action structure.
+ *   PORT_ID / REPRESENTED_PORT action structure.
  * @param[in] attr
  *   Attributes of flow that includes this action.
  * @param[out] error
@@ -5072,6 +5072,7 @@ flow_dv_validate_action_port_id(struct rte_eth_dev *dev,
struct rte_flow_error *error)
 {
const struct rte_flow_action_port_id *port_id;
+   const struct rte_flow_action_ethdev *ethdev;
struct mlx5_priv *act_priv;
struct mlx5_priv *dev_priv;
uint16_t port;
@@ -5080,13 +5081,13 @@ flow_dv_validate_action_port_id(struct rte_eth_dev *dev,
return rte_flow_error_set(error, ENOTSUP,
  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
  NULL,
- "port id action is valid in transfer"
+ "port action is valid in transfer"
  " mode only");
if (!action || !action->conf)
return rte_flow_error_set(error, ENOTSUP,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF,
  NULL,
- "port id action parameters must be"
+ "port action parameters must be"
  " specified");
if (action_flags & (MLX5_FLOW_FATE_ACTIONS |
MLX5_FLOW_FATE_ESWITCH_ACTIONS))
@@ -5100,13 +5101,26 @@ flow_dv_validate_action_port_id(struct rte_eth_dev *dev,
  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
  NULL,
  "failed to obtain E-Switch info");
-   port_id = action->conf;
-   port = port_id->original ? dev->data->port_id : port_id->id;
+   switch (action->type) {
+   case RTE_FLOW_ACTION_TYPE_PORT_ID:
+   port_id = action->conf;
+   port = port_id->original ? dev->data->port_id : port_id->id;
+   break;
+   case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
+   ethdev = action->conf;
+   port = ethdev->port_id;
+   break;
+   default:
+   return rte_flow_error_set
+   (error, EINVAL,
+RTE_FLOW_ERROR_TYPE_ACTION, action,
+"unknown E-Switch action");
+   }
act_priv = mlx5_port_to_eswitch_info(port, false);
if (!act_priv)
return rte_flow_error_set
(error, rte_errno,
-RTE_FLOW_ERROR_TYPE_ACTION_CONF, port_id,
+RTE_FLOW_ERROR_TYPE_ACTION_CONF, action->conf,
 "failed to obtain E-Switch port id for port");
if (act_priv->domain_id != dev_priv->domain_id)
return rte_flow_error_set
@@ -5669,6 +5683,7 @@ flow_dv_validate_action_sample(uint64_t *action_flags,
++actions_n;
break;
case RTE_FLOW_ACTION_TYPE_

[dpdk-dev] [PATCH v3 11/12] net/octeontx2: support port representor flow action

From: Andrew Rybchenko 

Action PORT_ID implementation assumes ingress only. Its semantics
suggests that support for equal action PORT_REPRESENTOR be added.

Signed-off-by: Andrew Rybchenko 
---
 doc/guides/nics/octeontx2.rst   |  5 -
 drivers/net/octeontx2/otx2_flow_parse.c | 16 
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index e35c8116f7..eae32f0afe 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -403,10 +403,13 @@ Actions:
++-+
| 12 | RTE_FLOW_ACTION_TYPE_PORT_ID|
++-+
+   | 13 | RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR   |
+   ++-+
 
 .. note::
 
-   ``RTE_FLOW_ACTION_TYPE_PORT_ID`` is only supported between PF and its VFs.
+   ``RTE_FLOW_ACTION_TYPE_PORT_ID``, ``RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR``
+   are only supported between PF and its VFs.
 
 .. _table_octeontx2_supported_egress_action_types:
 
diff --git a/drivers/net/octeontx2/otx2_flow_parse.c 
b/drivers/net/octeontx2/otx2_flow_parse.c
index 63a33142a5..890c6d0719 100644
--- a/drivers/net/octeontx2/otx2_flow_parse.c
+++ b/drivers/net/octeontx2/otx2_flow_parse.c
@@ -900,7 +900,6 @@ otx2_flow_parse_actions(struct rte_eth_dev *dev,
 {
struct otx2_eth_dev *hw = dev->data->dev_private;
struct otx2_npc_flow_info *npc = &hw->npc_flow;
-   const struct rte_flow_action_port_id *port_act;
const struct rte_flow_action_count *act_count;
const struct rte_flow_action_mark *act_mark;
const struct rte_flow_action_queue *act_q;
@@ -987,9 +986,18 @@ otx2_flow_parse_actions(struct rte_eth_dev *dev,
break;
 
case RTE_FLOW_ACTION_TYPE_PORT_ID:
-   port_act = (const struct rte_flow_action_port_id *)
-   actions->conf;
-   port_id = port_act->id;
+   case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
+   if (actions->type == RTE_FLOW_ACTION_TYPE_PORT_ID) {
+   const struct rte_flow_action_port_id *port_act;
+
+   port_act = actions->conf;
+   port_id = port_act->id;
+   } else {
+   const struct rte_flow_action_ethdev *ethdev_act;
+
+   ethdev_act = actions->conf;
+   port_id = ethdev_act->port_id;
+   }
if (rte_eth_dev_get_name_by_port(port_id, if_name)) {
errmsg = "Name not found for output port id";
errcode = EINVAL;
-- 
2.20.1

[dpdk-dev] [PATCH v3 12/12] net/sfc: support port representor flow item

From: Andrew Rybchenko 

Add support for item PORT_REPRESENTOR which should
be used instead of ambiguous item PORT_ID.

Signed-off-by: Andrew Rybchenko 
---
 doc/guides/nics/sfc_efx.rst |  2 ++
 drivers/net/sfc/sfc_mae.c   | 72 +
 2 files changed, 74 insertions(+)

diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index 163bc2533f..9a9710325f 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -190,6 +190,8 @@ Supported actions (***non-transfer*** rules):
 
 Supported pattern items (***transfer*** rules):
 
+- PORT_REPRESENTOR (cannot repeat; conflicts with other traffic source items)
+
 - PORT_ID (cannot repeat; conflicts with other traffic source items)
 
 - PHY_PORT (cannot repeat; conflicts with other traffic source items)
diff --git a/drivers/net/sfc/sfc_mae.c b/drivers/net/sfc/sfc_mae.c
index 4b520bc619..392f6ec098 100644
--- a/drivers/net/sfc/sfc_mae.c
+++ b/drivers/net/sfc/sfc_mae.c
@@ -1100,6 +1100,66 @@ sfc_mae_rule_parse_item_port_id(const struct 
rte_flow_item *item,
return 0;
 }
 
+static int
+sfc_mae_rule_parse_item_port_representor(const struct rte_flow_item *item,
+struct sfc_flow_parse_ctx *ctx,
+struct rte_flow_error *error)
+{
+   struct sfc_mae_parse_ctx *ctx_mae = ctx->mae;
+   const struct rte_flow_item_ethdev supp_mask = {
+   .port_id = 0x,
+   };
+   const void *def_mask = &rte_flow_item_ethdev_mask;
+   const struct rte_flow_item_ethdev *spec = NULL;
+   const struct rte_flow_item_ethdev *mask = NULL;
+   efx_mport_sel_t mport_sel;
+   int rc;
+
+   if (ctx_mae->match_mport_set) {
+   return rte_flow_error_set(error, ENOTSUP,
+   RTE_FLOW_ERROR_TYPE_ITEM, item,
+   "Can't handle multiple traffic source items");
+   }
+
+   rc = sfc_flow_parse_init(item,
+(const void **)&spec, (const void **)&mask,
+(const void *)&supp_mask, def_mask,
+sizeof(struct rte_flow_item_ethdev), error);
+   if (rc != 0)
+   return rc;
+
+   if (mask->port_id != supp_mask.port_id) {
+   return rte_flow_error_set(error, EINVAL,
+   RTE_FLOW_ERROR_TYPE_ITEM, item,
+   "Bad mask in the PORT_REPRESENTOR pattern 
item");
+   }
+
+   /* If "spec" is not set, could be any port ID */
+   if (spec == NULL)
+   return 0;
+
+   rc = sfc_mae_switch_port_by_ethdev(
+   ctx_mae->sa->mae.switch_domain_id,
+   spec->port_id, &mport_sel);
+   if (rc != 0) {
+   return rte_flow_error_set(error, rc,
+   RTE_FLOW_ERROR_TYPE_ITEM, item,
+   "Can't find RTE ethdev by the port ID");
+   }
+
+   rc = efx_mae_match_spec_mport_set(ctx_mae->match_spec,
+ &mport_sel, NULL);
+   if (rc != 0) {
+   return rte_flow_error_set(error, rc,
+   RTE_FLOW_ERROR_TYPE_ITEM, item,
+   "Failed to set MPORT for the port ID");
+   }
+
+   ctx_mae->match_mport_set = B_TRUE;
+
+   return 0;
+}
+
 static int
 sfc_mae_rule_parse_item_phy_port(const struct rte_flow_item *item,
 struct sfc_flow_parse_ctx *ctx,
@@ -1995,6 +2055,18 @@ static const struct sfc_flow_item sfc_flow_items[] = {
.ctx_type = SFC_FLOW_PARSE_CTX_MAE,
.parse = sfc_mae_rule_parse_item_port_id,
},
+   {
+   .type = RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+   .name = "PORT_REPRESENTOR",
+   /*
+* In terms of RTE flow, this item is a META one,
+* and its position in the pattern is don't care.
+*/
+   .prev_layer = SFC_FLOW_ITEM_ANY_LAYER,
+   .layer = SFC_FLOW_ITEM_ANY_LAYER,
+   .ctx_type = SFC_FLOW_PARSE_CTX_MAE,
+   .parse = sfc_mae_rule_parse_item_port_representor,
+   },
{
.type = RTE_FLOW_ITEM_TYPE_PHY_PORT,
.name = "PHY_PORT",
-- 
2.20.1

Re: [dpdk-dev] [PATCH v2 01/12] ethdev: add port representor item to flow API


Hi Ori,

On 10/10/2021 17:04, Ori Kam wrote:

Hi Ivan.


-Original Message-
From: Ivan Malov 
Sent: Sunday, October 10, 2021 4:30 PM
Subject: Re: [PATCH v2 01/12] ethdev: add port representor item to flow API

Hi Ori,

Thanks a lot for reviewing this.

On 10/10/2021 14:15, Ori Kam wrote:

Hi Ivan,

>From the new patches I saw you choose port_representor and

represented_port

Didn't we agree to go with ETHDEV_PORT and SHADOW_PORT?


Yes, in the previous thread I suggested a different option. But I gave it more 
thought and decided to go for
PORT_REPRESENTOR and REPRESENTED_PORT instead. In any case, I apologise for it 
being such short
notice.


The only thing that worries me is that the naming are very easy to get wrong.
port_representor and represented_port.


Is that so? In "port representor", the key word is "representor", a noun. In 
"represented port", the key
word is "port". Word "represented"
acts like an adjective. More to that, the order of words is chosen on purpose 
to prevent someone from
accidentally writing "representOR_port"
in their code, for example. That simply won't compile.

Well, at least, these two are harder to get wrong compared to "employer"
and "employee", for example.

The new names are better because they are paired terms. Each one suggests the 
existence of the other
one. This spares one from the need to have wordy explanations of the symmetry 
of the diagram.
The new names speak themselves.

Saying "shadow" is in fact vague. The reader doesn't see clearly that it's the 
shadow of the ethdev. And, in
turn, "ethdev" is also not as good as "representor". It's even hard to 
pronounce because of being a
combination of multiple contractions.

I hope you get the idea.



I get the idea, since my English is not perfect from my view point those are a 
bit more confusing and easy
to get wrong but I have no objection to keep them.


Please don't think me forward: my English is not any better. But I just
think that if English is the lingua franca in DPDK and in the community,
then the corresponding rules of the language are supposed to apply.


Lets see what others will think about it.



Also there is an issue with wording if we assume like in previous
thread that DPDK can have both the representor port and also the 
represented_port.
While if we look at for example ethdev_port and shadow port are better
defined as ethdev_port -> the port that is closest to the DPDK ethdev
while shadow port is defined as the other side of the ethdev port.

What do you think?


The semantics hasn't changed since the previous thread.
Representor coincides with the ethdev, so it's still the closest port.
And represented port is still the other side. It's all the same in fact.

If both VF and its representor are plugged to DPDK, they represent each other 
in fact. Mutual
representors. You can equally name the first one a representor and the other 
one a represented port, -
and vice versa.

The new naming doesn't deny both these ports being ethdevs, while the previous 
option (ethdev and
shadow) may trick the reader into thinking that only one of the two can be an 
ethdev. The reader may
think that this use case (when VF and its representor are plugged to the 
application) is completely wrong.
Let's avoid this mistake.



I agree those are semantics and there is no perfect world.
I accept your case.


Thank you.






-Original Message-
From: Ivan Malov 
Sent: Sunday, October 10, 2021 3:05 AM
Subject: [PATCH v2 01/12] ethdev: add port representor item to flow
API ?
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the given ethdev.



I would also add a comment that says the since we are in transfer it
means that all rules are located in the E-Switch which means that the
matching is done on the source port of the traffic.


Let me put it clear: I don't mind adding more comments. I can do that, yes. But 
look. You say "matching is
done on the source port". Isn't that what "entering the embedded switch FROM the 
given ethdev" already
says?


Yes,  the idea of this series is to clear everything.
Do you think that someone who just read this commit log can without prior 
knowledge of RTE flow
and transfer can fully understand the idea?


Well, the commit log is just an introduction to the diff itself. And,
in the diff, there is more commentary, diagrams, etc. Yes, of course,
I could have added some brief introduction to the commit log on what
RTE flow is and what "transfer" flows stand for, but I believe it's
already described in the existing documentation. However, I have no
strong opinion.



If so I'm, O.K. with leaving the comment as is.


I don't object changing it and probably I should do that in the next 
version should more reviewers indicate the same issue.




In most related comment about pharsing I'm giving my view point with all
the comments I got about how much hard it is to create rules and understand the
documentation.


I see.



Unless ther

Re: [dpdk-dev] [PATCH v2 01/12] ethdev: add port representor item to flow API

2021-10-10 Thread Ori Kam

Hi Ivan,

>From the new patches I saw you choose port_representor and represented_port
Didn't we agree to go with ETHDEV_PORT and SHADOW_PORT?
The only thing that worries me is that the naming are very easy to get wrong.
port_representor and represented_port.

Also there is an issue with wording if we assume like in previous thread that
DPDK can have both the representor port and also the represented_port.
While if we look at for example ethdev_port and shadow port are better defined
as ethdev_port -> the port that is closest to the DPDK ethdev while shadow port
is defined as the other side of the ethdev port.

What do you think?

> -Original Message-
> From: Ivan Malov 
> Sent: Sunday, October 10, 2021 3:05 AM
> Subject: [PATCH v2 01/12] ethdev: add port representor item to flow API
> ?
> For use in "transfer" flows. Supposed to match traffic entering the embedded
> switch from the given ethdev.


I would also add a comment that says the since we are in transfer it means
that all rules are located in the E-Switch which means that the matching is done
on the source port of the traffic. 

I think this will also help understand the view point that we are looking from 
the point
of the switch, and to add the drawing.

> 
> Must not be combined with direction attributes.
> 
> Signed-off-by: Ivan Malov 
> ---
>  app/test-pmd/cmdline_flow.c | 27 ++
>  doc/guides/prog_guide/rte_flow.rst  | 59 +
>  doc/guides/rel_notes/release_21_11.rst  |  2 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 ++
>  lib/ethdev/rte_flow.c   |  1 +
>  lib/ethdev/rte_flow.h   | 27 ++
>  6 files changed, 120 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index
> bb22294dd3..a912a8d815 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -306,6 +306,8 @@ enum index {
>   ITEM_POL_PORT,
>   ITEM_POL_METER,
>   ITEM_POL_POLICY,
> + ITEM_PORT_REPRESENTOR,
> + ITEM_PORT_REPRESENTOR_PORT_ID,
> 
>   /* Validate/create actions. */
>   ACTIONS,
> @@ -1000,6 +1002,7 @@ static const enum index next_item[] = {
>   ITEM_GENEVE_OPT,
>   ITEM_INTEGRITY,
>   ITEM_CONNTRACK,
> + ITEM_PORT_REPRESENTOR,
>   END_SET,
>   ZERO,
>  };
> @@ -1368,6 +1371,12 @@ static const enum index item_integrity_lv[] = {
>   ZERO,
>  };
> 
> +static const enum index item_port_representor[] = {
> + ITEM_PORT_REPRESENTOR_PORT_ID,
> + ITEM_NEXT,
> + ZERO,
> +};
> +
>  static const enum index next_action[] = {
>   ACTION_END,
>   ACTION_VOID,
> @@ -3608,6 +3617,21 @@ static const struct token token_list[] = {
>item_param),
>   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack,
> flags)),
>   },
> + [ITEM_PORT_REPRESENTOR] = {
> + .name = "port_representor",
> + .help = "match traffic entering the embedded switch from the
> given ethdev",
> + .priv = PRIV_ITEM(PORT_REPRESENTOR,
> +   sizeof(struct rte_flow_item_ethdev)),
> + .next = NEXT(item_port_representor),
> + .call = parse_vc,
> + },
> + [ITEM_PORT_REPRESENTOR_PORT_ID] = {
> + .name = "port_id",
> + .help = "ethdev port ID",
> + .next = NEXT(item_port_representor,
> NEXT_ENTRY(COMMON_UNSIGNED),
> +  item_param),
> + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev,
> port_id)),
> + },
>   /* Validate/create actions. */
>   [ACTIONS] = {
>   .name = "actions",
> @@ -8343,6 +8367,9 @@ flow_item_default_mask(const struct rte_flow_item
> *item)
>   case RTE_FLOW_ITEM_TYPE_PFCP:
>   mask = &rte_flow_item_pfcp_mask;
>   break;
> + case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
> + mask = &rte_flow_item_ethdev_mask;
> + break;
>   default:
>   break;
>   }
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 2b42d5ec8c..2e0f590777 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
>  - ``flags``: conntrack packet state flags.
>  - Default ``mask`` matches all state bits.
> 
> +Item: ``PORT_REPRESENTOR``
> +^^
> +
> +Matches traffic entering the embedded switch from the given ethdev.
> +
> +Term **ethdev** and the concept of **port representor** are synonymous.
> +The **represented port** is an *entity* plugged to the embedded switch
> +at the opposite end of the "wire" leading to the ethdev.
> +
> +::
> +
> +..
> +|PORT_REPRESENTOR|  Ethdev (Application Port Referred to by its 
> ID)
> +''
> +

Re: [dpdk-dev] [PATCH v2 01/12] ethdev: add port representor item to flow API

2021-10-10 Thread Ori Kam

Hi Ivan.

> -Original Message-
> From: Ivan Malov 
> Sent: Sunday, October 10, 2021 4:30 PM
> Subject: Re: [PATCH v2 01/12] ethdev: add port representor item to flow API
> 
> Hi Ori,
> 
> Thanks a lot for reviewing this.
> 
> On 10/10/2021 14:15, Ori Kam wrote:
> > Hi Ivan,
> >
> >>From the new patches I saw you choose port_representor and
> >>represented_port
> > Didn't we agree to go with ETHDEV_PORT and SHADOW_PORT?
> 
> Yes, in the previous thread I suggested a different option. But I gave it 
> more thought and decided to go for
> PORT_REPRESENTOR and REPRESENTED_PORT instead. In any case, I apologise for 
> it being such short
> notice.
> 
> > The only thing that worries me is that the naming are very easy to get 
> > wrong.
> > port_representor and represented_port.
> 
> Is that so? In "port representor", the key word is "representor", a noun. In 
> "represented port", the key
> word is "port". Word "represented"
> acts like an adjective. More to that, the order of words is chosen on purpose 
> to prevent someone from
> accidentally writing "representOR_port"
> in their code, for example. That simply won't compile.
> 
> Well, at least, these two are harder to get wrong compared to "employer"
> and "employee", for example.
> 
> The new names are better because they are paired terms. Each one suggests the 
> existence of the other
> one. This spares one from the need to have wordy explanations of the symmetry 
> of the diagram.
> The new names speak themselves.
> 
> Saying "shadow" is in fact vague. The reader doesn't see clearly that it's 
> the shadow of the ethdev. And, in
> turn, "ethdev" is also not as good as "representor". It's even hard to 
> pronounce because of being a
> combination of multiple contractions.
> 
> I hope you get the idea.
> 

I get the idea, since my English is not perfect from my view point those are a 
bit more confusing and easy
to get wrong but I have no objection to keep them.
Lets see what others will think about it.

> >
> > Also there is an issue with wording if we assume like in previous
> > thread that DPDK can have both the representor port and also the 
> > represented_port.
> > While if we look at for example ethdev_port and shadow port are better
> > defined as ethdev_port -> the port that is closest to the DPDK ethdev
> > while shadow port is defined as the other side of the ethdev port.
> >
> > What do you think?
> 
> The semantics hasn't changed since the previous thread.
> Representor coincides with the ethdev, so it's still the closest port.
> And represented port is still the other side. It's all the same in fact.
> 
> If both VF and its representor are plugged to DPDK, they represent each other 
> in fact. Mutual
> representors. You can equally name the first one a representor and the other 
> one a represented port, -
> and vice versa.
> 
> The new naming doesn't deny both these ports being ethdevs, while the 
> previous option (ethdev and
> shadow) may trick the reader into thinking that only one of the two can be an 
> ethdev. The reader may
> think that this use case (when VF and its representor are plugged to the 
> application) is completely wrong.
> Let's avoid this mistake.
> 

I agree those are semantics and there is no perfect world.
I accept your case.

> >
> >> -Original Message-
> >> From: Ivan Malov 
> >> Sent: Sunday, October 10, 2021 3:05 AM
> >> Subject: [PATCH v2 01/12] ethdev: add port representor item to flow
> >> API ?
> >> For use in "transfer" flows. Supposed to match traffic entering the
> >> embedded switch from the given ethdev.
> >
> >
> > I would also add a comment that says the since we are in transfer it
> > means that all rules are located in the E-Switch which means that the
> > matching is done on the source port of the traffic.
> 
> Let me put it clear: I don't mind adding more comments. I can do that, yes. 
> But look. You say "matching is
> done on the source port". Isn't that what "entering the embedded switch FROM 
> the given ethdev" already
> says?
> 
Yes,  the idea of this series is to clear everything.
Do you think that someone who just read this commit log can without prior 
knowledge of RTE flow
and transfer can fully understand the idea?

If so I'm, O.K. with leaving the comment as is.

In most related comment about pharsing I'm giving my view point with all
the comments I got about how much hard it is to create rules and understand the
documentation.

Unless there is something wrong or misleading I can except most answers and 
comments,
but I steel think that sometime it is worth saying them even if it is just for 
the developer to think
again if something can be improved.

> >
> > I think this will also help understand the view point that we are
> > looking from the point of the switch, and to add the drawing.
> 
> Well, as I said, technically, I don't object adding more comments. But the 
> above description says: "entering
> the embedded switch". Doesn't it indicate the viewpoint clear enoug

Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure

2021-10-10 Thread fengchengwen

Sorry to self-reply.

I think it's better the 'struct rte_eth_dev *dev' hold a pointer to the
'struct rte_eth_fp_ops', e.g.

struct rte_eth_dev {
struct rte_eth_fp_ops *fp_ops;
...  // other field
}

The eth framework set the pointer in the rte_eth_dev_pci_allocate(), and driver 
fill
corresponding callback:
dev->fp_ops->rx_pkt_burst = xxx_recv_pkts;
dev->fp_ops->tx_pkt_burst = xxx_xmit_pkts;
...

In this way, the behavior of the primary and secondary processes can be 
unified, which
is basically the same as that of the original process.


On 2021/10/9 20:05, fengchengwen wrote:
> On 2021/10/7 19:27, Konstantin Ananyev wrote:
>> Copy public function pointers (rx_pkt_burst(), etc.) and related
>> pointers to internal data from rte_eth_dev structure into a
>> separate flat array. That array will remain in a public header.
>> The intention here is to make rte_eth_dev and related structures internal.
>> That should allow future possible changes to core eth_dev structures
>> to be transparent to the user and help to avoid ABI/API breakages.
>> The plan is to keep minimal part of data from rte_eth_dev public,
>> so we still can use inline functions for fast-path calls
>> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
>> The whole idea beyond this new schema:
>> 1. PMDs keep to setup fast-path function pointers and related data
>>inside rte_eth_dev struct in the same way they did it before.
>> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
>>(for secondary process) we call eth_dev_fp_ops_setup, which
>>copies these function and data pointers into rte_eth_fp_ops[port_id].
>> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
>>we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
>>into some dummy values.
>> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
>>flat array to call PMD specific functions.
>> That approach should allow us to make rte_eth_devices[] private
>> without introducing regression and help to avoid changes in drivers code.
>>
>> Signed-off-by: Konstantin Ananyev 
>> ---
>>  lib/ethdev/ethdev_private.c  | 52 ++
>>  lib/ethdev/ethdev_private.h  |  7 +
>>  lib/ethdev/rte_ethdev.c  | 27 ++
>>  lib/ethdev/rte_ethdev_core.h | 55 
>>  4 files changed, 141 insertions(+)
>>
>> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
>> index 012cf73ca2..3eeda6e9f9 100644
>> --- a/lib/ethdev/ethdev_private.c
>> +++ b/lib/ethdev/ethdev_private.c
>> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void 
>> *data)
>>  RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
>>  return str == NULL ? -1 : 0;
>>  }
>> +
>> +static uint16_t
>> +dummy_eth_rx_burst(__rte_unused void *rxq,
>> +__rte_unused struct rte_mbuf **rx_pkts,
>> +__rte_unused uint16_t nb_pkts)
>> +{
>> +RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
>> +rte_errno = ENOTSUP;
>> +return 0;
>> +}
>> +
>> +static uint16_t
>> +dummy_eth_tx_burst(__rte_unused void *txq,
>> +__rte_unused struct rte_mbuf **tx_pkts,
>> +__rte_unused uint16_t nb_pkts)
>> +{
>> +RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
>> +rte_errno = ENOTSUP;
>> +return 0;
>> +}
>> +
>> +void
>> +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> 
> The port_id parameter is preferable, this will hide rte_eth_fp_ops as much as 
> possible.
> 
>> +{
>> +static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
>> +static const struct rte_eth_fp_ops dummy_ops = {
>> +.rx_pkt_burst = dummy_eth_rx_burst,
>> +.tx_pkt_burst = dummy_eth_tx_burst,
>> +.rxq = {.data = dummy_data, .clbk = dummy_data,},
>> +.txq = {.data = dummy_data, .clbk = dummy_data,},
>> +};
>> +
>> +*fpo = dummy_ops;
>> +}
>> +
>> +void
>> +eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
>> +const struct rte_eth_dev *dev)
> 
> Because fp_ops and eth_dev is a one-to-one correspondence. It's better only 
> use
> port_id parameter.
> 
>> +{
>> +fpo->rx_pkt_burst = dev->rx_pkt_burst;
>> +fpo->tx_pkt_burst = dev->tx_pkt_burst;
>> +fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
>> +fpo->rx_queue_count = dev->rx_queue_count;
>> +fpo->rx_descriptor_status = dev->rx_descriptor_status;
>> +fpo->tx_descriptor_status = dev->tx_descriptor_status;
>> +
>> +fpo->rxq.data = dev->data->rx_queues;
>> +fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
>> +
>> +fpo->txq.data = dev->data->tx_queues;
>> +fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
>> +}
>> diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
>> index 3724429577..5721be7bdc 100644
>> --- a/lib/ethdev/ethdev_

[dpdk-dev] [PATCH v3] net/iavf: fix multi-process shared data

2021-10-10 Thread dapengx . yu

From: Dapeng Yu 

When the iavf_adapter instance is not initialized completedly in the
primary process, the secondary process accesses its "rte_eth_dev"
member, it causes secondary process crash.

This patch replaces eth_dev with eth_dev_data in iavf_adapter.

Fixes: f978c1c9b3b5 ("net/iavf: add RSS hash parsing in AVX path")
Fixes: 9c9aa0040344 ("net/iavf: add offload path for Rx AVX512 flex descriptor")
Fixes: 63660ea3ee0b ("net/iavf: add RSS hash parsing in SSE path")
Cc: sta...@dpdk.org

Signed-off-by: Dapeng Yu 
---
V2:
* Remove access to rte_eth_devices
V3:
* Simplify parameters of iavf_request_queues
---
 drivers/net/iavf/iavf.h |  8 +++---
 drivers/net/iavf/iavf_ethdev.c  | 12 
 drivers/net/iavf/iavf_fdir.c|  4 +--
 drivers/net/iavf/iavf_hash.c|  2 +-
 drivers/net/iavf/iavf_rxtx.h|  4 +--
 drivers/net/iavf/iavf_rxtx_vec_avx2.c   | 13 +
 drivers/net/iavf/iavf_rxtx_vec_avx512.c | 12 
 drivers/net/iavf/iavf_rxtx_vec_sse.c|  7 +++--
 drivers/net/iavf/iavf_vchnl.c   | 38 -
 9 files changed, 53 insertions(+), 47 deletions(-)

diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 940d4f79ec..34bfa9af47 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -228,6 +228,8 @@ struct iavf_info {
struct virtchnl_qos_cap_list *qos_cap;
struct iavf_qtc_map *qtc_map;
struct iavf_tm_conf tm_conf;
+
+   struct rte_eth_dev *eth_dev;
 };
 
 #define IAVF_MAX_PKT_TYPE 1024
@@ -256,7 +258,7 @@ struct iavf_devargs {
 /* Structure to store private data for each VF instance. */
 struct iavf_adapter {
struct iavf_hw hw;
-   struct rte_eth_dev *eth_dev;
+   struct rte_eth_dev_data *dev_data;
struct iavf_info vf;
 
bool rx_bulk_alloc_allowed;
@@ -282,8 +284,6 @@ struct iavf_adapter {
(&(((struct iavf_vsi *)vsi)->adapter->hw))
 #define IAVF_VSI_TO_VF(vsi) \
(&(((struct iavf_vsi *)vsi)->adapter->vf))
-#define IAVF_VSI_TO_ETH_DEV(vsi) \
-   (((struct iavf_vsi *)vsi)->adapter->eth_dev)
 
 static inline void
 iavf_init_adminq_parameter(struct iavf_hw *hw)
@@ -397,7 +397,7 @@ int iavf_rss_hash_set(struct iavf_adapter *ad, uint64_t 
rss_hf, bool add);
 int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
struct rte_ether_addr *mc_addrs,
uint32_t mc_addrs_num, bool add);
-int iavf_request_queues(struct iavf_adapter *adapter, uint16_t num);
+int iavf_request_queues(struct rte_eth_dev *dev, uint16_t num);
 int iavf_get_max_rss_queue_region(struct iavf_adapter *adapter);
 int iavf_get_qos_cap(struct iavf_adapter *adapter);
 int iavf_set_q_tc_map(struct rte_eth_dev *dev,
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 5a5a7f59e1..7e4d256122 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -383,8 +383,8 @@ iavf_init_rss(struct iavf_adapter *adapter)
uint16_t i, j, nb_q;
int ret;
 
-   rss_conf = &adapter->eth_dev->data->dev_conf.rx_adv_conf.rss_conf;
-   nb_q = RTE_MIN(adapter->eth_dev->data->nb_rx_queues,
+   rss_conf = &adapter->dev_data->dev_conf.rx_adv_conf.rss_conf;
+   nb_q = RTE_MIN(adapter->dev_data->nb_rx_queues,
   vf->max_rss_qregion);
 
if (!(vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_RSS_PF)) {
@@ -438,7 +438,7 @@ iavf_queues_req_reset(struct rte_eth_dev *dev, uint16_t num)
struct iavf_info *vf =  IAVF_DEV_PRIVATE_TO_VF(ad);
int ret;
 
-   ret = iavf_request_queues(ad, num);
+   ret = iavf_request_queues(dev, num);
if (ret) {
PMD_DRV_LOG(ERR, "request queues from PF failed");
return ret;
@@ -1388,7 +1388,7 @@ iavf_dev_rss_hash_update(struct rte_eth_dev *dev,
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
int ret;
 
-   adapter->eth_dev->data->dev_conf.rx_adv_conf.rss_conf = *rss_conf;
+   adapter->dev_data->dev_conf.rx_adv_conf.rss_conf = *rss_conf;
 
if (!(vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_RSS_PF))
return -ENOTSUP;
@@ -2087,6 +2087,8 @@ iavf_init_vf(struct rte_eth_dev *dev)
struct iavf_hw *hw = IAVF_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
 
+   vf->eth_dev = dev;
+
err = iavf_parse_devargs(dev);
if (err) {
PMD_INIT_LOG(ERR, "Failed to parse devargs");
@@ -2352,7 +2354,7 @@ iavf_dev_init(struct rte_eth_dev *eth_dev)
hw->bus.func = pci_dev->addr.function;
hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
hw->back = IAVF_DEV_PRIVATE_TO_ADAPTER(eth_dev->data->dev_private);
-   adapter->eth_dev = eth_dev;
+   adapter->dev_data = eth_dev->data;
adapter->stopped = 1;
 
if (iavf_init_vf(eth_dev) != 0) {
diff --git a/

Re: [dpdk-dev] [PATCH v2] net/virtio: fix check scatter on all Rx queues

2021-10-10 Thread Peng, ZhihongX

> -Original Message-
> From: Peng, ZhihongX 
> Sent: Friday, October 8, 2021 1:50 PM
> To: Xia, Chenbo ; maxime.coque...@redhat.com
> Cc: dev@dpdk.org; ivan.ilche...@oktetlabs.ru; Peng, ZhihongX
> ; sta...@dpdk.org
> Subject: [PATCH v2] net/virtio: fix check scatter on all Rx queues
> 
> From: Zhihong Peng 
> 
> This patch fixes the wrong way to obtain virtqueue.
> The end of virtqueue cannot be judged based on whether the array is NULL.
> 
> Fixes: 4e8169eb0d2d (net/virtio: fix Rx scatter offload)
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Zhihong Peng 
> ---
>  drivers/net/virtio/virtio_ethdev.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index b60eeb24ab..213110cff4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -888,8 +888,11 @@ virtio_check_scatter_on_all_rx_queues(struct
> rte_eth_dev *dev,
>   if (hw->vqs == NULL)
>   return true;
> 
> - for (qidx = 0; (vq = hw->vqs[2 * qidx +
> VTNET_SQ_RQ_QUEUE_IDX]) != NULL;
> -  qidx++) {
> + for (qidx = 0; qidx < hw->max_queue_pairs; qidx++) {
> + vq = hw->vqs[2 * qidx + VTNET_SQ_RQ_QUEUE_IDX];
> + if (vq == NULL)
> + continue;
> +
>   rxvq = &vq->rxq;
>   if (rxvq->mpool == NULL)
>   continue;
> --
> 2.25.1

Hi Maxime,
Can you give me an ack?

Re: [dpdk-dev] [PATCH v2] net/virtio: fix check scatter on all Rx queues

2021-10-10 Thread Peng, ZhihongX

> -Original Message-
> From: Peng, ZhihongX 
> Sent: Friday, October 8, 2021 1:50 PM
> To: Xia, Chenbo ; maxime.coque...@redhat.com
> Cc: dev@dpdk.org; ivan.ilche...@oktetlabs.ru; Peng, ZhihongX
> ; sta...@dpdk.org
> Subject: [PATCH v2] net/virtio: fix check scatter on all Rx queues
> 
> From: Zhihong Peng 
> 
> This patch fixes the wrong way to obtain virtqueue.
> The end of virtqueue cannot be judged based on whether the array is NULL.
> 
> Fixes: 4e8169eb0d2d (net/virtio: fix Rx scatter offload)
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Zhihong Peng 
> ---
>  drivers/net/virtio/virtio_ethdev.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index b60eeb24ab..213110cff4 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -888,8 +888,11 @@ virtio_check_scatter_on_all_rx_queues(struct
> rte_eth_dev *dev,
>   if (hw->vqs == NULL)
>   return true;
> 
> - for (qidx = 0; (vq = hw->vqs[2 * qidx +
> VTNET_SQ_RQ_QUEUE_IDX]) != NULL;
> -  qidx++) {
> + for (qidx = 0; qidx < hw->max_queue_pairs; qidx++) {
> + vq = hw->vqs[2 * qidx + VTNET_SQ_RQ_QUEUE_IDX];
> + if (vq == NULL)
> + continue;
> +
>   rxvq = &vq->rxq;
>   if (rxvq->mpool == NULL)
>   continue;
> --
> 2.25.1

Tested-by: Zhihong Peng

Re: [dpdk-dev] [PATCH v3] net/iavf: fix multi-process shared data

2021-10-10 Thread Zhang, Qi Z




> -Original Message-
> From: Yu, DapengX 
> Sent: Monday, October 11, 2021 10:02 AM
> To: Wu, Jingjing ; Xing, Beilei 
> ;
> Richardson, Bruce ; Ananyev, Konstantin
> 
> Cc: dev@dpdk.org; Zhang, Qi Z ; Yigit, Ferruh
> ; Yu, DapengX ;
> sta...@dpdk.org
> Subject: [PATCH v3] net/iavf: fix multi-process shared data
> 
> From: Dapeng Yu 
> 
> When the iavf_adapter instance is not initialized completedly in the primary
> process, the secondary process accesses its "rte_eth_dev"
> member, it causes secondary process crash.
> 
> This patch replaces eth_dev with eth_dev_data in iavf_adapter.
> 
> Fixes: f978c1c9b3b5 ("net/iavf: add RSS hash parsing in AVX path")
> Fixes: 9c9aa0040344 ("net/iavf: add offload path for Rx AVX512 flex
> descriptor")
> Fixes: 63660ea3ee0b ("net/iavf: add RSS hash parsing in SSE path")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dapeng Yu 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

[dpdk-dev] [PATCH v2 1/5] ethdev: update modify field flow action

The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:

  - immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.

  - the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.

  - how the bit offset is applied to the immediate source
field was not defined and documented.

  - 64-bit integer size is not enough to provide IPv6
addresses.

In order to cover the issues and exclude any ambiguities
the following is done:

  - introduce the explicit pointer field
in rte_flow_action_modify_data structure

  - replace the 64-bit unsigned integer with 16-byte array

  - update the modify field flow action documentation

[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")

Signed-off-by: Viacheslav Ovsiienko 
---
 doc/guides/prog_guide/rte_flow.rst | 16 
 doc/guides/rel_notes/release_21_11.rst |  9 +
 lib/ethdev/rte_flow.h  | 17 ++---
 3 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..1ceecb399f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
 ``value`` sets an immediate value to be used as a source or points to a
 location of the value in memory. It is used instead of ``level`` and ``offset``
 for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+RTE_FLOW_FIELD_MAC_DST should follow the conventions of dst field
+in rte_flow_item_eth structure, with type RTE_FLOW_FIELD_IPV6_SRC -
+rte_flow_item_ipv6 conventions, and so on. If the field size is large than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit 
offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination width as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
 
 .. _table_rte_flow_action_modify_field:
 
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..41a087d7c1 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
   the crypto/security operation. This field will be used to communicate
   events such as soft expiry with IPsec in lookaside mode.
 
+* ethdev: ``rte_flow_action_modify_data`` structure udpdated, immediate data
+  array is extended, data pointer field is explicitly added to union, the
+  action behavior is defined in more strict fashion and documentation updated.
+  The immediate value behavior has been changed, the entire immediate field
+  should be provided, and offset for immediate source bitfield is assigned
+  from destination one.
+
 
 ABI Changes
 ---
@@ -222,6 +229,8 @@ ABI Changes
   ``rte_security_ipsec_xform`` to allow applications to configure SA soft
   and hard expiry limits. Limits can be either in number of packets or bytes.
 
+* ethdev: ``rte_flow_action_modify_data`` structure udpdated.
+
 
 Known Issues
 
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..953924d42b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3204,6 +3204,9 @@ enum rte_flow_field_id {
 };
 
 /**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
  * Field description for MODIFY_FIELD action.
  */
 struct rte_flow_action_modify_data {
@@ -3217,10 +3220,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
-* Immediate value for RTE_FLOW_FIELD_VALUE or
-* memory address for RTE_FLOW_FIELD_POINTER.
+* Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+* same byte order and length as in relevant rte_flow_item_xxx.
+* The immediate source bitfield offset is inherited from
+* the destination's one.
 */
-   uint64_t value;
+   uint8_t value[16];
+   /*
+

[dpdk-dev] [PATCH v2 4/5] net/mlx5: update modify field action

Update immediate value/pointer source operand support
for modify field RTE Flow action:

  - source operand data can be presented by byte buffer
(instead of former uint64_t) or by pointer
  - no host byte ordering is assumed anymore for immediate
data buffer (not uint64_t anymore)
  - no immediate value offset is expected

Signed-off-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_dv.c | 50 +++--
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index c6370cd1d6..867f587960 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1391,7 +1391,7 @@ flow_dv_convert_action_modify_ipv6_dscp
 
 static int
 mlx5_flow_item_field_width(struct mlx5_priv *priv,
-  enum rte_flow_field_id field)
+  enum rte_flow_field_id field, int inherit)
 {
switch (field) {
case RTE_FLOW_FIELD_START:
@@ -1442,7 +1442,8 @@ mlx5_flow_item_field_width(struct mlx5_priv *priv,
return __builtin_popcount(priv->sh->dv_meta_mask);
case RTE_FLOW_FIELD_POINTER:
case RTE_FLOW_FIELD_VALUE:
-   return 64;
+   MLX5_ASSERT(inherit >= 0);
+   return inherit < 0 ? 0 : inherit;
default:
MLX5_ASSERT(false);
}
@@ -1462,7 +1463,8 @@ mlx5_flow_field_id_to_modify_info
struct mlx5_priv *priv = dev->data->dev_private;
uint32_t idx = 0;
uint32_t off = 0;
-   uint64_t val = 0;
+   uint8_t *pval;
+
switch (data->field) {
case RTE_FLOW_FIELD_START:
/* not supported yet */
@@ -1838,32 +1840,37 @@ mlx5_flow_field_id_to_modify_info
break;
case RTE_FLOW_FIELD_POINTER:
case RTE_FLOW_FIELD_VALUE:
-   if (data->field == RTE_FLOW_FIELD_POINTER)
-   memcpy(&val, (void *)(uintptr_t)data->value,
-  sizeof(uint64_t));
-   else
-   val = data->value;
+   pval = data->field == RTE_FLOW_FIELD_POINTER ?
+  (uint8_t *)(uintptr_t)data->pvalue :
+  (uint8_t *)(uintptr_t)&data->value;
for (idx = 0; idx < MLX5_ACT_MAX_MOD_FIELDS; idx++) {
+   if (!dst_width)
+   break;
if (mask[idx]) {
if (dst_width == 48) {
/*special case for MAC addresses */
-   value[idx] = rte_cpu_to_be_16(val);
-   val >>= 16;
+   value[idx] = rte_cpu_to_be_16
+   (*(unaligned_uint16_t *)pval);
+   pval += sizeof(uint16_t);
dst_width -= 16;
} else if (dst_width > 16) {
-   value[idx] = rte_cpu_to_be_32(val);
-   val >>= 32;
+   value[idx] = rte_cpu_to_be_32
+   (*(unaligned_uint32_t *)pval);
+   pval += sizeof(uint32_t);
+   dst_width -= RTE_MIN(32u, dst_width);
} else if (dst_width > 8) {
-   value[idx] = rte_cpu_to_be_16(val);
-   val >>= 16;
+   value[idx] = rte_cpu_to_be_16
+   (*(unaligned_uint16_t *)pval);
+   pval += sizeof(uint16_t);
+   dst_width -= RTE_MIN(16u, dst_width);
} else {
-   value[idx] = (uint8_t)val;
-   val >>= 8;
+   value[idx] = *pval++;
+   dst_width -= RTE_MIN(8u, dst_width);
}
if (*shift)
value[idx] <<= *shift;
-   if (!val)
-   break;
+   } else {
+   pval += sizeof(uint32_t);
}
}
break;
@@ -1910,8 +1917,9 @@ flow_dv_convert_action_modify_field
uint32_t value[MLX5_ACT_MAX_MOD_FIELDS] = {0, 0, 0, 0, 0};
uint32_t type;
uint32_t shift = 0;
-   uint32_t dst_width = mlx5_flow_item_field_width(priv, conf->dst.field);
+   uint32_t dst_width;
 
+   dst_width = mlx5_flow_item_field_w

[dpdk-dev] [PATCH v2 2/5] app/testpmd: update modify field flow action support

The testpmd flow create command updates provided:

  - modify field action supports the updated actions
  - pointer type added for action source field
  - pointer and value source field takes hex string
instead of unsigned int in host endianness

There are some examples of flow with update modified
field action:

1. IPv6 destination address bytes 4-7 assignment:
   :: - > ::4455:6677::

   flow create 0 egress group 1
 pattern eth / ipv6 dst is :: / udp / end
 actions modify_field op set
 dst_type ipv6_dst
 dst_offset 32
 src_type value
 src_value 0011223344556677
 width 32 / end

2. Copy second byte of IPv4 destination address to the
   third byte of source address:
 10.0.118.4 -> 192.168.100.1
 10.0.168.4 -> 192.168.100.1

   flow create 0 egress group 1
 pattern eth / ipv4 / udp / end
 actions modify_field op set
 dst_type ipv4_src
 dst_offset 16
 src_type ipv4_dst
 src_offset 8
 width 8 / end

3. Assign METADATA value with 11223344 value from the
   hex string in the linear buffer. Please note, the value
   definition should follow host-endian, example is given
   for x86 (little-endian):

   flow create 0 egress group 1
 pattern eth / ipv4 / end
 actions modify_field op set
 dst_type meta
 src_type pointer
 src_ptr 44332211
 width 32 / end

4. Assign destination MAC with EA:11:0B:AD:0B:ED value:

   flow create 0 egress group 1
 pattern eth / end
 actions modify_field op set
 dst_type mac_dst
 src_type value
 src_value EA110BAD0BED
 width 48 / end

Signed-off-by: Viacheslav Ovsiienko 
---
 app/test-pmd/cmdline_flow.c | 55 +
 1 file changed, 38 insertions(+), 17 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index bb22294dd3..736029c4fd 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -448,6 +448,7 @@ enum index {
ACTION_MODIFY_FIELD_SRC_LEVEL,
ACTION_MODIFY_FIELD_SRC_OFFSET,
ACTION_MODIFY_FIELD_SRC_VALUE,
+   ACTION_MODIFY_FIELD_SRC_POINTER,
ACTION_MODIFY_FIELD_WIDTH,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
@@ -468,6 +469,14 @@ enum index {
 #define ITEM_RAW_SIZE \
(sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
 
+/** Maximum size for external pattern in struct rte_flow_action_modify_data. */
+#define ACTION_MODIFY_PATTERN_SIZE 32
+
+/** Storage size for struct rte_flow_action_modify_field including pattern. */
+#define ACTION_MODIFY_SIZE \
+   (sizeof(struct rte_flow_action_modify_field) + \
+   ACTION_MODIFY_PATTERN_SIZE)
+
 /** Maximum number of queue indices in struct rte_flow_action_rss. */
 #define ACTION_RSS_QUEUE_NUM 128
 
@@ -1704,6 +1713,7 @@ static const enum index action_modify_field_src[] = {
ACTION_MODIFY_FIELD_SRC_LEVEL,
ACTION_MODIFY_FIELD_SRC_OFFSET,
ACTION_MODIFY_FIELD_SRC_VALUE,
+   ACTION_MODIFY_FIELD_SRC_POINTER,
ACTION_MODIFY_FIELD_WIDTH,
ZERO,
 };
@@ -4455,8 +4465,7 @@ static const struct token token_list[] = {
[ACTION_MODIFY_FIELD] = {
.name = "modify_field",
.help = "modify destination field with data from source field",
-   .priv = PRIV_ACTION(MODIFY_FIELD,
-   sizeof(struct rte_flow_action_modify_field)),
+   .priv = PRIV_ACTION(MODIFY_FIELD, ACTION_MODIFY_SIZE),
.next = NEXT(NEXT_ENTRY(ACTION_MODIFY_FIELD_OP)),
.call = parse_vc,
},
@@ -4539,11 +4548,26 @@ static const struct token token_list[] = {
.name = "src_value",
.help = "source immediate value",
.next = NEXT(NEXT_ENTRY(ACTION_MODIFY_FIELD_WIDTH),
-   NEXT_ENTRY(COMMON_UNSIGNED)),
-   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_modify_field,
+NEXT_ENTRY(COMMON_HEX)),
+   .args = ARGS(ARGS_ENTRY_ARB(0, 0),
+ARGS_ENTRY_ARB(0, 0),
+ARGS_ENTRY(struct rte_flow_action_modify_field,
src.value)),
.call = parse_vc_conf,
},
+   [ACTION_MODIFY_FIELD_SRC_POINTER] = {
+   .name = "src_ptr",
+   .help = "pointer to source immediate value",
+   .next = NEXT(NEXT_ENTRY(ACTION_MODIFY_FIELD_WIDTH),
+NEXT_ENTRY(COMMON_HEX)),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_modify_field,
+   src.pvalue),
+ARGS_ENTRY_ARB(0, 0),
+ARGS_ENTRY_ARB
+   (sizeof(struct rte_flow_ac

[dpdk-dev] [PATCH v2 0/5] ethdev: update modify field flow action

The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:

  - immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union

  - the byte ordering for 64-bit integer was not specified.
Many fields have lesser lengths and byte ordering
is crucial.

  - how the bit offset is applied to the immediate source
field was not defined and documented

  - 64-bit integer size is not enough to provide MAC and
IPv6 addresses

In order to cover the issues and exclude any ambiguities
the following is done:

  - introduce the explicit pointer field
in rte_flow_action_modify_data structure

  - replace the 64-bit unsigned integer with 16-byte array

  - update the modify field flow action documentation

[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
[2] RFC: 
http://patches.dpdk.org/project/dpdk/patch/20210910141609.8410-1-viachesl...@nvidia.com/
[3] Deprecation notice: 
http://patches.dpdk.org/project/dpdk/patch/20210803085754.643180-1-or...@nvidia.com/
[4] v1 - 
http://patches.dpdk.org/project/dpdk/cover/20211001195223.31909-1-viachesl...@nvidia.com/

v2: - comments addressed
- documentation updated
- typos fixed
- mlx5 PMD updated

Signed-off-by: Viacheslav Ovsiienko 

Viacheslav Ovsiienko (5):
  ethdev: update modify field flow action
  app/testpmd: update modify field flow action support
  app/testpmd: fix hex string parser in flow commands
  net/mlx5: update modify field action
  doc: remove modify field action data deprecation notice

 app/test-pmd/cmdline_flow.c| 60 ++
 doc/guides/prog_guide/rte_flow.rst | 16 +++
 doc/guides/rel_notes/deprecation.rst   |  4 --
 doc/guides/rel_notes/release_21_11.rst |  9 
 drivers/net/mlx5/mlx5_flow_dv.c| 50 -
 lib/ethdev/rte_flow.h  | 17 ++--
 6 files changed, 110 insertions(+), 46 deletions(-)

-- 
2.18.1

[dpdk-dev] [PATCH v2 3/5] app/testpmd: fix hex string parser in flow commands

The hexadecimal string parser does not check the target
field buffer size, buffer overflow happens and might
cause the application failure (segmentation fault
is observed usually).

Fixes: 169a9fed1f4c ("app/testpmd: fix hex string parser support for flow API")
Cc: sta...@dpdk.org

Signed-off-by: Viacheslav Ovsiienko 
---
 app/test-pmd/cmdline_flow.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 736029c4fd..6827d9228f 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -7291,10 +7291,13 @@ parse_hex(struct context *ctx, const struct token 
*token,
hexlen -= 2;
}
if (hexlen > length)
-   return -1;
+   goto error;
ret = parse_hex_string(str, hex_tmp, &hexlen);
if (ret < 0)
goto error;
+   /* Check the converted binary fits into data buffer. */
+   if (hexlen > size)
+   goto error;
/* Let parse_int() fill length information first. */
ret = snprintf(tmp, sizeof(tmp), "%u", hexlen);
if (ret < 0)
-- 
2.18.1

[dpdk-dev] [PATCH v2 5/5] doc: remove modify field action data deprecation notice

The generic modify field flow action introduced
is updated, deprecation notice should be removed.

Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")

Signed-off-by: Viacheslav Ovsiienko 
---
 doc/guides/rel_notes/deprecation.rst | 4 
 1 file changed, 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..dee14077a5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,10 +120,6 @@ Deprecation Notices
 * ethdev: Announce moving from dedicated modify function for each field,
   to using the general ``rte_flow_modify_field`` action.
 
-* ethdev: The struct ``rte_flow_action_modify_data`` will be modified
-  to support modifying fields larger than 64 bits.
-  In addition, documentation will be updated to clarify byte order.
-
 * ethdev: Attribute ``shared`` of the ``struct rte_flow_action_count``
   is deprecated and will be removed in DPDK 21.11. Shared counters should
   be managed using shared actions API (``rte_flow_shared_action_create`` etc).
-- 
2.18.1

Re: [dpdk-dev] [PATCH v1] ethdev: introduce shared Rx queue

On Sun, Oct 10, 2021 at 7:10 PM Xueming(Steven) Li  wrote:
>
> On Sun, 2021-10-10 at 15:16 +0530, Jerin Jacob wrote:
> > On Fri, Oct 8, 2021 at 1:56 PM Xueming(Steven) Li  
> > wrote:
> > >
> > > On Wed, 2021-09-29 at 13:35 +0530, Jerin Jacob wrote:
> > > > On Wed, Sep 29, 2021 at 1:11 PM Xueming(Steven) Li 
> > > >  wrote:
> > > > >
> > > > > On Tue, 2021-09-28 at 20:29 +0530, Jerin Jacob wrote:
> > > > > > On Tue, Sep 28, 2021 at 8:10 PM Xueming(Steven) Li 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 2021-09-28 at 13:59 +, Ananyev, Konstantin wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Sep 28, 2021 at 6:55 PM Xueming(Steven) Li
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, 2021-09-28 at 18:28 +0530, Jerin Jacob wrote:
> > > > > > > > > > > On Tue, Sep 28, 2021 at 5:07 PM Xueming(Steven) Li
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2021-09-28 at 15:05 +0530, Jerin Jacob wrote:
> > > > > > > > > > > > > On Sun, Sep 26, 2021 at 11:06 AM Xueming(Steven) Li
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 2021-08-11 at 13:04 +0100, Ferruh Yigit 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On 8/11/2021 9:28 AM, Xueming(Steven) Li wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > > > Sent: Wednesday, August 11, 2021 4:03 PM
> > > > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > > > ; NBU-Contact-Thomas
> > > > > > > > > > > > > > > > > Monjalon
> > > > > > > > > ;
> > > > > > > > > > > > > > > > > Andrew Rybchenko 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 7:46 PM 
> > > > > > > > > > > > > > > > > Xueming(Steven) Li
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > > > > > From: Jerin Jacob 
> > > > > > > > > > > > > > > > > > > Sent: Monday, August 9, 2021 9:51 PM
> > > > > > > > > > > > > > > > > > > To: Xueming(Steven) Li 
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Cc: dpdk-dev ; Ferruh Yigit
> > > > > > > > > > > > > > > > > > > ;
> > > > > > > > > > > > > > > > > > > NBU-Contact-Thomas Monjalon
> > > > > > > > > > > > > > > > > > > ; Andrew Rybchenko
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v1] ethdev:
> > > > > > > > > > > > > > > > > > > introduce shared Rx queue
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, Aug 9, 2021 at 5:18 PM Xueming Li
> > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > In current DPDK framework, each RX 
> > > > > > > > > > > > > > > > > > > > queue is
> > > > > > > > > > > > > > > > > > > > pre-loaded with mbufs
> > > > > > > > > > > > > > > > > > > > for incoming packets. When number of
> > > > > > > > > > > > > > > > > > > > representors scale out in a
> > > > > > > > > > > > > > > > > > > > switch domain, the memory consumption 
> > > > > > > > > > > > > > > > > > > > became
> > > > > > > > > > > > > > > > > > > > significant. Most
> > > > > > > > > > > > > > > > > > > > important, polling all ports leads to 
> > > > > > > > > > > > > > > > > > > > high
> > > > > > > > > > > > > > > > > > > > cache miss, high
> > > > > > > > > > > > > > > > > > > > latency and low throughput.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This patch introduces shared RX queue. 
> > > > > > > > > > > > > > > > > > > > Ports
> > > > > > > > > > > > > > > > > > > > with same
> > > > > > > > > > > > > > > > > > > > configuration in a switch domain could 
> > > > > > > > > > > > > > > > > > > > share
> > > > > > > > > > > > > > > > > > > > RX queue set by specifying sharing 
> > > > > > > > > > > > > > > > > > > > group.
> > > > > > > > > > > > > > > > > > > > Polling any queue using same shared RX 
> > > > > > > > > > > > > > > > > > > > queue
> > > > > > > > > > > > > > > > > > > > receives packets from
> > > > > > > > > > > > > > > > > > > > all member ports. Source port is 
> > > > > > > > > > > > > > > > > > > > identified
> > > > > > > > > > > > > > > > > > > > by mbuf->port.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Port queue number in a shared group 
> > > > > > > > > > > > > > > >

[dpdk-dev] [PATCH v10 0/8] baseband: add NXP LA12xx driver

From: Nipun Gupta 

This series introduces the BBDEV LA12xx poll mode driver (PMD) to support
an implementation for offloading High Phy processing functions like
LDPC Encode / Decode 5GNR wireless acceleration function, using PCI based
LA12xx Software defined radio.

Please check the documentation patch for more info.

The driver currently implements basic feature to offload only the 5G LDPC
encode/decode.

A new capability has been added to check if the driver can support the
input data in little/big endian byte order.

v2: add test case changes
v3: fix 32 bit compilation
v4: capability for network byte order, doc patch merged inline.
v5: add llr_size and llr_decimals, removed LLR compression flag,
update testbbdev to handle endianness, rebased on top of 20.08
v6: added BE as device info instead of capability, updated test
to have 2 codeblocks
v7: fixed checkpatch errors
v8: remove additional test vectors, update reverse_op function name,
make be_support param as bool, other minor changes in la12xx driver
v9: add little endianness capability as well (patch by Nicolas Chautru),
fix 32 bit (i386) compilation, fix get of nb_segs, add endianness
info in testbbdev doc.
v10: use default RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN defined, add
 data_endianness info for BBDEV null device

Hemant Agrawal (6):
  baseband: introduce NXP LA12xx driver
  baseband/la12xx: add devargs for max queues
  baseband/la12xx: add support for multiple modems
  baseband/la12xx: add queue and modem config support
  baseband/la12xx: add enqueue and dequeue support
  app/bbdev: enable la12xx for bbdev

Nicolas Chautru (1):
  bbdev: add device info related to data endianness

Nipun Gupta (1):
  app/bbdev: handle endianness of test data

 MAINTAINERS   |   10 +
 app/test-bbdev/meson.build|3 +
 app/test-bbdev/test_bbdev_perf.c  |   43 +
 doc/guides/bbdevs/features/la12xx.ini |   13 +
 doc/guides/bbdevs/index.rst   |1 +
 doc/guides/bbdevs/la12xx.rst  |  124 ++
 doc/guides/rel_notes/release_21_11.rst|6 +
 doc/guides/tools/testbbdev.rst|3 +
 drivers/baseband/acc100/rte_acc100_pmd.c  |1 +
 .../fpga_5gnr_fec/rte_fpga_5gnr_fec.c |1 +
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c  |1 +
 drivers/baseband/la12xx/bbdev_la12xx.c| 1101 +
 drivers/baseband/la12xx/bbdev_la12xx.h|   51 +
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h|  244 
 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |   28 +
 drivers/baseband/la12xx/meson.build   |6 +
 drivers/baseband/la12xx/version.map   |3 +
 drivers/baseband/meson.build  |1 +
 drivers/baseband/null/bbdev_null.c|6 +
 .../baseband/turbo_sw/bbdev_turbo_software.c  |1 +
 lib/bbdev/rte_bbdev.h |4 +
 21 files changed, 1651 insertions(+)
 create mode 100644 doc/guides/bbdevs/features/la12xx.ini
 create mode 100644 doc/guides/bbdevs/la12xx.rst
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.c
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_ipc.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
 create mode 100644 drivers/baseband/la12xx/meson.build
 create mode 100644 drivers/baseband/la12xx/version.map

-- 
2.17.1

[dpdk-dev] [PATCH v10 1/8] bbdev: add device info related to data endianness

From: Nicolas Chautru 

Adding device information to capture explicitly the assumption
of the input/output data byte endianness being processed.

Signed-off-by: Nicolas Chautru 
Signed-off-by: Nipun Gupta 
---
 doc/guides/rel_notes/release_21_11.rst | 1 +
 drivers/baseband/acc100/rte_acc100_pmd.c   | 1 +
 drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c   | 1 +
 drivers/baseband/null/bbdev_null.c | 6 ++
 drivers/baseband/turbo_sw/bbdev_turbo_software.c   | 1 +
 lib/bbdev/rte_bbdev.h  | 4 
 7 files changed, 15 insertions(+)

diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index c0a7f75518..135aa467f2 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -194,6 +194,7 @@ API Changes
   the crypto/security operation. This field will be used to communicate
   events such as soft expiry with IPsec in lookaside mode.
 
+* bbdev: Added device info related to data byte endianness processing.
 
 ABI Changes
 ---
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c 
b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523ea9..361e06cf94 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1088,6 +1088,7 @@ acc100_dev_info_get(struct rte_bbdev *dev,
 #else
dev_info->harq_buffer_size = 0;
 #endif
+   dev_info->data_endianness = RTE_LITTLE_ENDIAN;
acc100_check_ir(d);
 }
 
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c 
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 6485cc824a..ee457f3071 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -372,6 +372,7 @@ fpga_dev_info_get(struct rte_bbdev *dev,
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+   dev_info->data_endianness = RTE_LITTLE_ENDIAN;
 
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c 
b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 350c4248eb..703bb611a0 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -644,6 +644,7 @@ fpga_dev_info_get(struct rte_bbdev *dev,
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+   dev_info->data_endianness = RTE_LITTLE_ENDIAN;
 
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/null/bbdev_null.c 
b/drivers/baseband/null/bbdev_null.c
index 53c538ba44..753d920e18 100644
--- a/drivers/baseband/null/bbdev_null.c
+++ b/drivers/baseband/null/bbdev_null.c
@@ -77,6 +77,12 @@ info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info 
*dev_info)
dev_info->cpu_flag_reqs = NULL;
dev_info->min_alignment = 0;
 
+   /* BBDEV null device does not process the data, so
+* endianness setting is not relevant, but setting it
+* here for code completeness.
+*/
+   dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
 }
 
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c 
b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 77e9a2ecbc..7dfeec665a 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -251,6 +251,7 @@ info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
dev_info->capabilities = bbdev_capabilities;
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
+   dev_info->data_endianness = RTE_LITTLE_ENDIAN;
 
rte_bbdev_log_debug("got device info from %u\n", dev->data->dev_id);
 }
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index 3ebf62e697..e863bd913f 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -309,6 +309,10 @@ struct rte_bbdev_driver_info {
uint16_t min_alignment;
/** HARQ memory available in kB */
uint32_t harq_buffer_size;
+   /** Byte endianness (RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN) supported
+*  for input/output data
+*/
+   uint8_t data_endianness;
/** Default queue configuration used if none is supplied  */
struct rte_bbdev_queue_conf default_queue_conf;
/** Device operation capabilities */
-- 
2.17.1

[dpdk-dev] [PATCH v10 2/8] baseband: introduce NXP LA12xx driver

From: Hemant Agrawal 

This patch introduce the baseband device drivers for NXP's
LA1200 series software defined baseband modem.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 MAINTAINERS   |   9 ++
 drivers/baseband/la12xx/bbdev_la12xx.c| 108 ++
 .../baseband/la12xx/bbdev_la12xx_pmd_logs.h   |  28 +
 drivers/baseband/la12xx/meson.build   |   6 +
 drivers/baseband/la12xx/version.map   |   3 +
 drivers/baseband/meson.build  |   1 +
 6 files changed, 155 insertions(+)
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.c
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
 create mode 100644 drivers/baseband/la12xx/meson.build
 create mode 100644 drivers/baseband/la12xx/version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 278e5b3226..25eec751bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1289,6 +1289,15 @@ F: drivers/event/opdl/
 F: doc/guides/eventdevs/opdl.rst
 
 
+Baseband Drivers
+
+
+NXP LA12xx driver
+M: Nipun Gupta 
+M: Hemant Agrawal 
+F: drivers/baseband/la12xx/
+
+
 Rawdev Drivers
 --
 
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
new file mode 100644
index 00..d3d7a4df37
--- /dev/null
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -0,0 +1,108 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020-2021 NXP
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME baseband_la12xx
+
+/* private data structure */
+struct bbdev_la12xx_private {
+   unsigned int max_nb_queues;  /**< Max number of queues */
+};
+/* Create device */
+static int
+la12xx_bbdev_create(struct rte_vdev_device *vdev)
+{
+   struct rte_bbdev *bbdev;
+   const char *name = rte_vdev_device_name(vdev);
+
+   PMD_INIT_FUNC_TRACE();
+
+   bbdev = rte_bbdev_allocate(name);
+   if (bbdev == NULL)
+   return -ENODEV;
+
+   bbdev->data->dev_private = rte_zmalloc(name,
+   sizeof(struct bbdev_la12xx_private),
+   RTE_CACHE_LINE_SIZE);
+   if (bbdev->data->dev_private == NULL) {
+   rte_bbdev_release(bbdev);
+   return -ENOMEM;
+   }
+
+   bbdev->dev_ops = NULL;
+   bbdev->device = &vdev->device;
+   bbdev->data->socket_id = 0;
+   bbdev->intr_handle = NULL;
+
+   /* register rx/tx burst functions for data path */
+   bbdev->dequeue_enc_ops = NULL;
+   bbdev->dequeue_dec_ops = NULL;
+   bbdev->enqueue_enc_ops = NULL;
+   bbdev->enqueue_dec_ops = NULL;
+
+   return 0;
+}
+
+/* Initialise device */
+static int
+la12xx_bbdev_probe(struct rte_vdev_device *vdev)
+{
+   const char *name;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (vdev == NULL)
+   return -EINVAL;
+
+   name = rte_vdev_device_name(vdev);
+   if (name == NULL)
+   return -EINVAL;
+
+   return la12xx_bbdev_create(vdev);
+}
+
+/* Uninitialise device */
+static int
+la12xx_bbdev_remove(struct rte_vdev_device *vdev)
+{
+   struct rte_bbdev *bbdev;
+   const char *name;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (vdev == NULL)
+   return -EINVAL;
+
+   name = rte_vdev_device_name(vdev);
+   if (name == NULL)
+   return -EINVAL;
+
+   bbdev = rte_bbdev_get_named_dev(name);
+   if (bbdev == NULL)
+   return -EINVAL;
+
+   rte_free(bbdev->data->dev_private);
+
+   return rte_bbdev_release(bbdev);
+}
+
+static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
+   .probe = la12xx_bbdev_probe,
+   .remove = la12xx_bbdev_remove
+};
+
+RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
+RTE_LOG_REGISTER_DEFAULT(bbdev_la12xx_logtype, NOTICE);
diff --git a/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h 
b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
new file mode 100644
index 00..452435ccb9
--- /dev/null
+++ b/drivers/baseband/la12xx/bbdev_la12xx_pmd_logs.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 NXP
+ */
+
+#ifndef _BBDEV_LA12XX_PMD_LOGS_H_
+#define _BBDEV_LA12XX_PMD_LOGS_H_
+
+extern int bbdev_la12xx_logtype;
+
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, bbdev_la12xx_logtype, fmt "\n", \
+   ##__VA_ARGS__)
+
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, "la12xx_pmd: " fmt, \
+   ##__VA_ARGS__)
+#else
+#define rte_bbdev_log_debug(fmt, ...)
+#endif
+
+#define PMD_INIT_FUNC_TRACE() rte_bbdev_log_debug(">>")
+
+/* DP Logs, toggled out at compile time if level lower than current level */
+#define rte_bbdev_dp_log(level, fmt, args...) \
+   RTE_LOG_DP(level, PMD, fmt, ## args)
+
+#endif /* _BBDEV_LA12XX_PMD_LOGS_H_ */
diff --git a/drivers/baseband/l

[dpdk-dev] [PATCH v10 3/8] baseband/la12xx: add devargs for max queues

From: Hemant Agrawal 

This patch adds dev args to take  max queues as input

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 drivers/baseband/la12xx/bbdev_la12xx.c | 73 +-
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index d3d7a4df37..f5c835eeb8 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -17,13 +17,73 @@
 
 #define DRIVER_NAME baseband_la12xx
 
+/*  Initialisation params structure that can be used by LA12xx BBDEV driver */
+struct bbdev_la12xx_params {
+   uint8_t queues_num; /*< LA12xx BBDEV queues number */
+};
+
+#define LA12XX_MAX_NB_QUEUES_ARG   "max_nb_queues"
+
+static const char * const bbdev_la12xx_valid_params[] = {
+   LA12XX_MAX_NB_QUEUES_ARG,
+};
+
 /* private data structure */
 struct bbdev_la12xx_private {
unsigned int max_nb_queues;  /**< Max number of queues */
 };
+static inline int
+parse_u16_arg(const char *key, const char *value, void *extra_args)
+{
+   uint16_t *u16 = extra_args;
+
+   uint64_t result;
+   if ((value == NULL) || (extra_args == NULL))
+   return -EINVAL;
+   errno = 0;
+   result = strtoul(value, NULL, 0);
+   if ((result >= (1 << 16)) || (errno != 0)) {
+   rte_bbdev_log(ERR, "Invalid value %" PRIu64 " for %s",
+ result, key);
+   return -ERANGE;
+   }
+   *u16 = (uint16_t)result;
+   return 0;
+}
+
+/* Parse parameters used to create device */
+static int
+parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
+   const char *input_args)
+{
+   struct rte_kvargs *kvlist = NULL;
+   int ret = 0;
+
+   if (params == NULL)
+   return -EINVAL;
+   if (input_args) {
+   kvlist = rte_kvargs_parse(input_args,
+   bbdev_la12xx_valid_params);
+   if (kvlist == NULL)
+   return -EFAULT;
+
+   ret = rte_kvargs_process(kvlist, bbdev_la12xx_valid_params[0],
+   &parse_u16_arg, ¶ms->queues_num);
+   if (ret < 0)
+   goto exit;
+
+   }
+
+exit:
+   if (kvlist)
+   rte_kvargs_free(kvlist);
+   return ret;
+}
+
 /* Create device */
 static int
-la12xx_bbdev_create(struct rte_vdev_device *vdev)
+la12xx_bbdev_create(struct rte_vdev_device *vdev,
+   struct bbdev_la12xx_params *init_params __rte_unused)
 {
struct rte_bbdev *bbdev;
const char *name = rte_vdev_device_name(vdev);
@@ -60,7 +120,11 @@ la12xx_bbdev_create(struct rte_vdev_device *vdev)
 static int
 la12xx_bbdev_probe(struct rte_vdev_device *vdev)
 {
+   struct bbdev_la12xx_params init_params = {
+   8
+   };
const char *name;
+   const char *input_args;
 
PMD_INIT_FUNC_TRACE();
 
@@ -71,7 +135,10 @@ la12xx_bbdev_probe(struct rte_vdev_device *vdev)
if (name == NULL)
return -EINVAL;
 
-   return la12xx_bbdev_create(vdev);
+   input_args = rte_vdev_device_args(vdev);
+   parse_bbdev_la12xx_params(&init_params, input_args);
+
+   return la12xx_bbdev_create(vdev, &init_params);
 }
 
 /* Uninitialise device */
@@ -105,4 +172,6 @@ static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
 };
 
 RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
+RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
+   LA12XX_MAX_NB_QUEUES_ARG"=");
 RTE_LOG_REGISTER_DEFAULT(bbdev_la12xx_logtype, NOTICE);
-- 
2.17.1

[dpdk-dev] [PATCH v10 4/8] baseband/la12xx: add support for multiple modems

From: Hemant Agrawal 

This patch add support for multiple modems by assigning
a modem id as dev args in vdev creation.

Signed-off-by: Hemant Agrawal 
---
 drivers/baseband/la12xx/bbdev_la12xx.c | 64 +++---
 drivers/baseband/la12xx/bbdev_la12xx.h | 56 +++
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h | 20 +++
 3 files changed, 133 insertions(+), 7 deletions(-)
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx.h
 create mode 100644 drivers/baseband/la12xx/bbdev_la12xx_ipc.h

diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index f5c835eeb8..58defa54f0 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -14,24 +14,26 @@
 #include 
 
 #include 
+#include 
+#include 
 
 #define DRIVER_NAME baseband_la12xx
 
 /*  Initialisation params structure that can be used by LA12xx BBDEV driver */
 struct bbdev_la12xx_params {
uint8_t queues_num; /*< LA12xx BBDEV queues number */
+   int8_t modem_id; /*< LA12xx modem instance id */
 };
 
 #define LA12XX_MAX_NB_QUEUES_ARG   "max_nb_queues"
+#define LA12XX_VDEV_MODEM_ID_ARG   "modem"
+#define LA12XX_MAX_MODEM 4
 
 static const char * const bbdev_la12xx_valid_params[] = {
LA12XX_MAX_NB_QUEUES_ARG,
+   LA12XX_VDEV_MODEM_ID_ARG,
 };
 
-/* private data structure */
-struct bbdev_la12xx_private {
-   unsigned int max_nb_queues;  /**< Max number of queues */
-};
 static inline int
 parse_u16_arg(const char *key, const char *value, void *extra_args)
 {
@@ -51,6 +53,28 @@ parse_u16_arg(const char *key, const char *value, void 
*extra_args)
return 0;
 }
 
+/* Parse integer from integer argument */
+static int
+parse_integer_arg(const char *key __rte_unused,
+   const char *value, void *extra_args)
+{
+   int i;
+   char *end;
+
+   errno = 0;
+
+   i = strtol(value, &end, 10);
+   if (*end != 0 || errno != 0 || i < 0 || i > LA12XX_MAX_MODEM) {
+   rte_bbdev_log(ERR, "Supported Port IDS are 0 to %d",
+   LA12XX_MAX_MODEM - 1);
+   return -EINVAL;
+   }
+
+   *((uint32_t *)extra_args) = i;
+
+   return 0;
+}
+
 /* Parse parameters used to create device */
 static int
 parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
@@ -72,6 +96,16 @@ parse_bbdev_la12xx_params(struct bbdev_la12xx_params *params,
if (ret < 0)
goto exit;
 
+   ret = rte_kvargs_process(kvlist,
+   bbdev_la12xx_valid_params[1],
+   &parse_integer_arg,
+   ¶ms->modem_id);
+
+   if (params->modem_id >= LA12XX_MAX_MODEM) {
+   rte_bbdev_log(ERR, "Invalid modem id, must be < %u",
+   LA12XX_MAX_MODEM);
+   goto exit;
+   }
}
 
 exit:
@@ -83,10 +117,11 @@ parse_bbdev_la12xx_params(struct bbdev_la12xx_params 
*params,
 /* Create device */
 static int
 la12xx_bbdev_create(struct rte_vdev_device *vdev,
-   struct bbdev_la12xx_params *init_params __rte_unused)
+   struct bbdev_la12xx_params *init_params)
 {
struct rte_bbdev *bbdev;
const char *name = rte_vdev_device_name(vdev);
+   struct bbdev_la12xx_private *priv;
 
PMD_INIT_FUNC_TRACE();
 
@@ -102,6 +137,20 @@ la12xx_bbdev_create(struct rte_vdev_device *vdev,
return -ENOMEM;
}
 
+   priv = bbdev->data->dev_private;
+   priv->modem_id = init_params->modem_id;
+   /* if modem id is not configured */
+   if (priv->modem_id == -1)
+   priv->modem_id = bbdev->data->dev_id;
+
+   /* Reset Global variables */
+   priv->num_ldpc_enc_queues = 0;
+   priv->num_ldpc_dec_queues = 0;
+   priv->num_valid_queues = 0;
+   priv->max_nb_queues = init_params->queues_num;
+
+   rte_bbdev_log(INFO, "Setting Up %s: DevId=%d, ModemId=%d",
+   name, bbdev->data->dev_id, priv->modem_id);
bbdev->dev_ops = NULL;
bbdev->device = &vdev->device;
bbdev->data->socket_id = 0;
@@ -121,7 +170,7 @@ static int
 la12xx_bbdev_probe(struct rte_vdev_device *vdev)
 {
struct bbdev_la12xx_params init_params = {
-   8
+   8, -1,
};
const char *name;
const char *input_args;
@@ -173,5 +222,6 @@ static struct rte_vdev_driver bbdev_la12xx_pmd_drv = {
 
 RTE_PMD_REGISTER_VDEV(DRIVER_NAME, bbdev_la12xx_pmd_drv);
 RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
-   LA12XX_MAX_NB_QUEUES_ARG"=");
+   LA12XX_MAX_NB_QUEUES_ARG"="
+   LA12XX_VDEV_MODEM_ID_ARG "= ");
 RTE_LOG_REGISTER_DEFAULT(bbdev_la12xx_logtype, NOTICE);
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.h 
b/drivers/baseband/la12xx/bbdev_la12xx.h
new file mode 100644
index 0

[dpdk-dev] [PATCH v10 5/8] baseband/la12xx: add queue and modem config support

From: Hemant Agrawal 

This patch add support for connecting with modem
and creating the ipc channel as queues with modem
for the exchange of data.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 MAINTAINERS|   1 +
 doc/guides/bbdevs/index.rst|   1 +
 doc/guides/bbdevs/la12xx.rst   |  80 +++
 doc/guides/rel_notes/release_21_11.rst |   5 +
 drivers/baseband/la12xx/bbdev_la12xx.c | 556 -
 drivers/baseband/la12xx/bbdev_la12xx.h |  17 +-
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h | 189 ++-
 7 files changed, 836 insertions(+), 13 deletions(-)
 create mode 100644 doc/guides/bbdevs/la12xx.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 25eec751bb..7030147767 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1296,6 +1296,7 @@ NXP LA12xx driver
 M: Nipun Gupta 
 M: Hemant Agrawal 
 F: drivers/baseband/la12xx/
+F: doc/guides/bbdevs/la12xx.rst
 
 
 Rawdev Drivers
diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
index 4445cbd1b0..cedd706fa6 100644
--- a/doc/guides/bbdevs/index.rst
+++ b/doc/guides/bbdevs/index.rst
@@ -14,3 +14,4 @@ Baseband Device Drivers
 fpga_lte_fec
 fpga_5gnr_fec
 acc100
+la12xx
diff --git a/doc/guides/bbdevs/la12xx.rst b/doc/guides/bbdevs/la12xx.rst
new file mode 100644
index 00..1a711ef5e3
--- /dev/null
+++ b/doc/guides/bbdevs/la12xx.rst
@@ -0,0 +1,80 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2021 NXP
+
+NXP LA12xx Poll Mode Driver
+===
+
+The BBDEV LA12xx poll mode driver (PMD) supports an implementation for
+offloading High Phy processing functions like LDPC Encode / Decode 5GNR 
wireless
+acceleration function, using PCI based LA12xx Software defined radio.
+
+More information can be found at `NXP Official Website
+`_.
+
+Features
+
+
+LA12xx PMD supports the following features:
+
+- Maximum of 8 LDPC decode (UL) queues
+- Maximum of 8 LDPC encode (DL) queues
+- PCIe Gen-3 x8 Interface
+
+Installation
+
+
+Section 3 of the DPDK manual provides instructions on installing and compiling 
DPDK.
+
+DPDK requires hugepages to be configured as detailed in section 2 of the DPDK 
manual.
+
+Initialization
+--
+
+The device can be listed on the host console with:
+
+
+Use the following lspci command to get the multiple LA12xx processor ids. The
+device ID of the LA12xx baseband processor is "1c30".
+
+.. code-block:: console
+
+  sudo lspci -nn
+
+...
+0001:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device [1957:1c30] (
+rev 10)
+...
+0002:01:00.0 Power PC [0b20]: Freescale Semiconductor Inc Device [1957:1c30] (
+rev 10)
+
+
+Prerequisites
+-
+
+Currently supported by DPDK:
+
+- NXP LA1224 BSP **1.0+**.
+- NXP LA1224 PCIe Modem card connected to ARM host.
+
+- Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
+
+* Use dev arg option ``modem=0`` to identify the modem instance for a given
+  device. This is required only if more than 1 modem cards are attached to 
host.
+  this is optional and the default value is 0.
+  e.g. ``--vdev=baseband_la12xx,modem=0``
+
+* Use dev arg option ``max_nb_queues=x`` to specify the maximum number of 
queues
+  to be used for communication with offload device i.e. modem. default is 16.
+  e.g. ``--vdev=baseband_la12xx,max_nb_queues=4``
+
+Enabling logs
+-
+
+For enabling logs, use the following EAL parameter:
+
+.. code-block:: console
+
+   ./your_bbdev_application  --log-level=la12xx:
+
+Using ``bb.la12xx`` as log matching criteria, all Baseband PMD logs can be
+enabled which are lower than logging ``level``.
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 135aa467f2..f4cae1b760 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -134,6 +134,11 @@ New Features
   * Added tests to validate packets hard expiry.
   * Added tests to verify tunnel header verification in IPsec inbound.
 
+* **Added NXP LA12xx baseband PMD.**
+
+  * Added a new baseband PMD driver for NXP LA12xx Software defined radio.
+  * See the :doc:`../bbdevs/la12xx` for more details.
+
 
 Removed Items
 -
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 58defa54f0..9fad7462e8 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -3,6 +3,11 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -29,11 +34,553 @@ struct bbdev_la12xx_params {
 #define LA12XX_VDEV_MODEM_ID_ARG   "modem"
 #define LA12XX_MAX_MODEM 4
 
+#define LA12XX_MAX_CORES   4
+#define LA12XX_LDPC_EN

[dpdk-dev] [PATCH v10 6/8] baseband/la12xx: add enqueue and dequeue support

From: Hemant Agrawal 

Add support for enqueue and dequeue the LDPC enc/dec
from the modem device.

Signed-off-by: Nipun Gupta 
Signed-off-by: Hemant Agrawal 
---
 doc/guides/bbdevs/features/la12xx.ini  |  13 +
 doc/guides/bbdevs/la12xx.rst   |  44 +++
 drivers/baseband/la12xx/bbdev_la12xx.c | 320 +
 drivers/baseband/la12xx/bbdev_la12xx_ipc.h |  37 +++
 4 files changed, 414 insertions(+)
 create mode 100644 doc/guides/bbdevs/features/la12xx.ini

diff --git a/doc/guides/bbdevs/features/la12xx.ini 
b/doc/guides/bbdevs/features/la12xx.ini
new file mode 100644
index 00..0aec5eecb6
--- /dev/null
+++ b/doc/guides/bbdevs/features/la12xx.ini
@@ -0,0 +1,13 @@
+;
+; Supported features of the 'la12xx' bbdev driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Turbo Decoder (4G) = N
+Turbo Encoder (4G) = N
+LDPC Decoder (5G)  = Y
+LDPC Encoder (5G)  = Y
+LLR/HARQ Compression   = N
+HW Accelerated = Y
+BBDEV API  = Y
diff --git a/doc/guides/bbdevs/la12xx.rst b/doc/guides/bbdevs/la12xx.rst
index 1a711ef5e3..fe1bca4c5c 100644
--- a/doc/guides/bbdevs/la12xx.rst
+++ b/doc/guides/bbdevs/la12xx.rst
@@ -78,3 +78,47 @@ For enabling logs, use the following EAL parameter:
 
 Using ``bb.la12xx`` as log matching criteria, all Baseband PMD logs can be
 enabled which are lower than logging ``level``.
+
+Test Application
+
+
+BBDEV provides a test application, ``test-bbdev.py`` and range of test data 
for testing
+the functionality of LA12xx for FEC encode and decode, depending on the device
+capabilities. The test application is located under app->test-bbdev folder and 
has the
+following options:
+
+.. code-block:: console
+
+  "-p", "--testapp-path": specifies path to the bbdev test app.
+  "-e", "--eal-params" : EAL arguments which are passed to the test app.
+  "-t", "--timeout": Timeout in seconds (default=300).
+  "-c", "--test-cases" : Defines test cases to run. Run all if not specified.
+  "-v", "--test-vector": Test vector path 
(default=dpdk_path+/app/test-bbdev/test_vectors/bbdev_null.data).
+  "-n", "--num-ops": Number of operations to process on device 
(default=32).
+  "-b", "--burst-size" : Operations enqueue/dequeue burst size (default=32).
+  "-s", "--snr": SNR in dB used when generating LLRs for bler 
tests.
+  "-s", "--iter_max"   : Number of iterations for LDPC decoder.
+  "-l", "--num-lcores" : Number of lcores to run (default=16).
+  "-i", "--init-device" : Initialise PF device with default values.
+
+
+To execute the test application tool using simple decode or encode data,
+type one of the following:
+
+.. code-block:: console
+
+  ./test-bbdev.py -e="--vdev=baseband_la12xx,socket_id=0,max_nb_queues=8" -c 
validation -n 64 -b 1 -v ./ldpc_dec_default.data
+  ./test-bbdev.py -e="--vdev=baseband_la12xx,socket_id=0,max_nb_queues=8" -c 
validation -n 64 -b 1 -v ./ldpc_enc_default.data
+
+The test application ``test-bbdev.py``, supports the ability to configure the 
PF device with
+a default set of values, if the "-i" or "- -init-device" option is included. 
The default values
+are defined in test_bbdev_perf.c.
+
+
+Test Vectors
+
+
+In addition to the simple LDPC decoder and LDPC encoder tests, bbdev also 
provides
+a range of additional tests under the test_vectors folder, which may be 
useful. The results
+of these tests will depend on the LA12xx FEC capabilities which may cause some
+testcases to be skipped, but no failure should be reported.
diff --git a/drivers/baseband/la12xx/bbdev_la12xx.c 
b/drivers/baseband/la12xx/bbdev_la12xx.c
index 9fad7462e8..cce03f75ae 100644
--- a/drivers/baseband/la12xx/bbdev_la12xx.c
+++ b/drivers/baseband/la12xx/bbdev_la12xx.c
@@ -120,6 +120,10 @@ la12xx_queue_release(struct rte_bbdev *dev, uint16_t q_id)
((uint64_t) ((unsigned long) (A) \
- ((uint64_t)ipc_priv->hugepg_start.host_vaddr)))
 
+#define MODEM_P2V(A) \
+   ((uint64_t) ((unsigned long) (A) \
+   + (unsigned long)(ipc_priv->peb_start.host_vaddr)))
+
 static int ipc_queue_configure(uint32_t channel_id,
ipc_t instance, struct bbdev_la12xx_q_priv *q_priv)
 {
@@ -334,6 +338,318 @@ static const struct rte_bbdev_ops pmd_ops = {
.queue_release = la12xx_queue_release,
.start = la12xx_start
 };
+
+static inline int
+is_bd_ring_full(uint32_t ci, uint32_t ci_flag,
+   uint32_t pi, uint32_t pi_flag)
+{
+   if (pi == ci) {
+   if (pi_flag != ci_flag)
+   return 1; /* Ring is Full */
+   }
+   return 0;
+}
+
+static inline int
+prepare_ldpc_enc_op(struct rte_bbdev_enc_op *bbdev_enc_op,
+   struct bbdev_la12xx_q_priv *q_priv __rte_unused,
+   struct rte_bbdev_op_data *in_op_data __rte_unused,
+   struct rte_bbdev_op_data *out_op_data)
+{
+   struct rte_bbdev_op_ldpc_

[dpdk-dev] [PATCH v10 7/8] app/bbdev: enable la12xx for bbdev

From: Hemant Agrawal 

this patch adds la12xx driver in test bbdev

Signed-off-by: Hemant Agrawal 
---
 app/test-bbdev/meson.build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
index edb9deef84..a726a5b3fa 100644
--- a/app/test-bbdev/meson.build
+++ b/app/test-bbdev/meson.build
@@ -23,3 +23,6 @@ endif
 if dpdk_conf.has('RTE_BASEBAND_ACC100')
 deps += ['baseband_acc100']
 endif
+if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_LA12XX')
+   deps += ['baseband_la12xx']
+endif
-- 
2.17.1

[dpdk-dev] [PATCH v10 8/8] app/bbdev: handle endianness of test data