[PATCH v1] raw/ifpga: initialize variable to avoid compile error

[Wei Huang]

Compile failed with cflag optimization=1 on Ubuntu20.04 with GCC10.3,
it reported vendor_id and dev_id may be used uninitialized in function
ifpga_rawdev_fill_info().
Actually it's not the truth, the variables are initialized in function
ifpga_get_dev_vendor_id(). To avoid such compile error, the variables
are initialized when they are defined.

Signed-off-by: Wei Huang 
Acked-by: Tianfei Zhang 
Acked-by: Rosen Xu 
---
 drivers/raw/ifpga/ifpga_rawdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/raw/ifpga/ifpga_rawdev.c b/drivers/raw/ifpga/ifpga_rawdev.c
index 26c1366..6d4117c 100644
--- a/drivers/raw/ifpga/ifpga_rawdev.c
+++ b/drivers/raw/ifpga/ifpga_rawdev.c
@@ -225,7 +225,8 @@ static int ifpga_rawdev_fill_info(struct ifpga_rawdev 
*ifpga_dev)
 
unsigned int dom, bus, dev;
int func;
-   uint32_t dev_id, vendor_id;
+   uint32_t dev_id = 0;
+   uint32_t vendor_id = 0;
 
adapter = ifpga_dev ? ifpga_rawdev_get_priv(ifpga_dev->rawdev) : NULL;
if (!adapter)
-- 
1.8.3.1

RE: [PATCH v1] net/iavf: fix select wrong scan hw ring by rxdid

[Xing, Beilei]

> -Original Message-
> From: Yang, SteveX 
> Sent: Monday, March 14, 2022 5:32 PM
> To: dev@dpdk.org
> Cc: Wu, Jingjing ; Xing, Beilei 
> ;
> Zhang, Qi Z ; Yang, SteveX ;
> sta...@dpdk.org
> Subject: [PATCH v1] net/iavf: fix select wrong scan hw ring by rxdid
> 
> When setup RX queue, the rxdid would be changed if it's
> "IAVF_RXDID_LEGACY_0/1", that caused the scan hw ring used the wrong
> function 'iavf_rx_scan_hw_ring_flex_rxd()'.
> 
> Ignore the rxdid changed when equals "IAVF_RXDID_LEGACY_0/1".
> 
> Fixes: 0ed16e01313e ("net/iavf: fix function pointer in multi-process")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Steve Yang 
> ---
>  drivers/net/iavf/iavf_rxtx.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c index
> 16e8d021f9..3b16609f7d 100644
> --- a/drivers/net/iavf/iavf_rxtx.c
> +++ b/drivers/net/iavf/iavf_rxtx.c
> @@ -477,6 +477,8 @@ iavf_rxd_to_pkt_fields_by_comms_aux_v2(struct
> iavf_rx_queue *rxq,
> 
>  static const
>  iavf_rxd_to_pkt_fields_t rxd_to_pkt_fields_ops[IAVF_RXDID_LAST + 1] = {
> + [IAVF_RXDID_LEGACY_0] = iavf_rxd_to_pkt_fields_by_comms_ovs,
> + [IAVF_RXDID_LEGACY_1] = iavf_rxd_to_pkt_fields_by_comms_ovs,
>   [IAVF_RXDID_COMMS_AUX_VLAN] =
> iavf_rxd_to_pkt_fields_by_comms_aux_v1,
>   [IAVF_RXDID_COMMS_AUX_IPV4] =
> iavf_rxd_to_pkt_fields_by_comms_aux_v1,
>   [IAVF_RXDID_COMMS_AUX_IPV6] =
> iavf_rxd_to_pkt_fields_by_comms_aux_v1,
> @@ -521,6 +523,8 @@ iavf_select_rxd_to_pkt_fields_handler(struct
> iavf_rx_queue *rxq, uint32_t rxdid)
> 
>   rte_pmd_ifd_dynflag_proto_xtr_ipsec_crypto_said_mask;
>   break;
>   case IAVF_RXDID_COMMS_OVS_1:
> + case IAVF_RXDID_LEGACY_0:
> + case IAVF_RXDID_LEGACY_1:
>   break;
>   default:
>   /* update this according to the RXDID for FLEX_DESC_NONE
> */
> --
> 2.27.0

Acked-by: Beilei Xing 

[PATCH] test/crypto-perf: extend asymmetric crypto throughput test

[kirankumark]

From: Kiran Kumar K 

Extended support for asymmetric crypto perf throughput test.
Added support for new modulus lengths.
Added new parameter --modex-len.
Supported lengths are 60, 128, 255, 448. Default length is 128.

Signed-off-by: Kiran Kumar K 
---
 app/test-crypto-perf/cperf_ops.c |  18 +-
 app/test-crypto-perf/cperf_options.h |   3 +
 app/test-crypto-perf/cperf_options_parsing.c |  42 +++
 app/test-crypto-perf/cperf_test_vectors.c| 264 ---
 app/test-crypto-perf/cperf_test_vectors.h|  25 +-
 app/test-crypto-perf/main.c  |   2 +-
 6 files changed, 307 insertions(+), 47 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 8baee12e45..7bb7a2611d 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -14,7 +14,7 @@ cperf_set_ops_asym(struct rte_crypto_op **ops,
   uint32_t src_buf_offset __rte_unused,
   uint32_t dst_buf_offset __rte_unused, uint16_t nb_ops,
   struct rte_cryptodev_sym_session *sess,
-  const struct cperf_options *options __rte_unused,
+  const struct cperf_options *options,
   const struct cperf_test_vector *test_vector __rte_unused,
   uint16_t iv_offset __rte_unused,
   uint32_t *imix_idx __rte_unused,
@@ -27,10 +27,10 @@ cperf_set_ops_asym(struct rte_crypto_op **ops,
struct rte_crypto_asym_op *asym_op = ops[i]->asym;
 
ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
-   asym_op->modex.base.data = perf_base;
-   asym_op->modex.base.length = sizeof(perf_base);
-   asym_op->modex.result.data = perf_mod_result;
-   asym_op->modex.result.length = sizeof(perf_mod_result);
+   asym_op->modex.base.data = options->modex_data->base.data;
+   asym_op->modex.base.length = options->modex_data->base.len;
+   asym_op->modex.result.data = options->modex_data->result.data;
+   asym_op->modex.result.length = options->modex_data->result.len;
rte_crypto_op_attach_asym_session(ops[i], asym_sess);
}
return 0;
@@ -787,10 +787,10 @@ cperf_create_session(struct rte_mempool *sess_mp,
if (options->op_type == CPERF_ASYM_MODEX) {
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
-   xform.modex.modulus.data = perf_mod_p;
-   xform.modex.modulus.length = sizeof(perf_mod_p);
-   xform.modex.exponent.data = perf_mod_e;
-   xform.modex.exponent.length = sizeof(perf_mod_e);
+   xform.modex.modulus.data = options->modex_data->modulus.data;
+   xform.modex.modulus.length = options->modex_data->modulus.len;
+   xform.modex.exponent.data = options->modex_data->exponent.data;
+   xform.modex.exponent.length = options->modex_data->exponent.len;
 
ret = rte_cryptodev_asym_session_create(dev_id, &xform,
sess_mp, &asym_sess);
diff --git a/app/test-crypto-perf/cperf_options.h 
b/app/test-crypto-perf/cperf_options.h
index 031b238b20..09caefde22 100644
--- a/app/test-crypto-perf/cperf_options.h
+++ b/app/test-crypto-perf/cperf_options.h
@@ -12,6 +12,7 @@
 #endif
 
 #define CPERF_PTEST_TYPE   ("ptest")
+#define CPERF_MODEX_LEN("modex-len")
 #define CPERF_SILENT   ("silent")
 
 #define CPERF_POOL_SIZE("pool-sz")
@@ -153,6 +154,8 @@ struct cperf_options {
uint32_t pmdcc_delay;
uint32_t imix_distribution_list[MAX_LIST];
uint8_t imix_distribution_count;
+   struct cperf_modex_test_data *modex_data;
+   uint16_t modex_len;
 };
 
 void
diff --git a/app/test-crypto-perf/cperf_options_parsing.c 
b/app/test-crypto-perf/cperf_options_parsing.c
index 59a9dc596a..09c98121c8 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -10,6 +10,7 @@
 #include 
 
 #include "cperf_options.h"
+#include "cperf_test_vectors.h"
 
 #define AES_BLOCK_SIZE 16
 #define DES_BLOCK_SIZE 8
@@ -57,6 +58,8 @@ usage(char *progname)
" --pmd-cyclecount-delay-ms N: set delay between enqueue\n"
"   and dequeue in pmd-cyclecount benchmarking mode\n"
" --csv-friendly: enable test result output CSV friendly\n"
+   " --modex-len N: modex length, supported lengths are "
+   "60, 128, 255, 448. Default: 128\n"
 #ifdef RTE_LIB_SECURITY
" --pdcp-sn-sz N: set PDCP SN size N <5/7/12/15/18>\n"
" --pdcp-domain DOMAIN: set PDCP domain \n"
@@ -313,6 +316,16 @@ parse_pool_sz(struct cperf_options *opts, const char *arg)
return ret;
 }
 
+static int
+parse_modex_len(struct cperf_options *opts, const char *arg)
+{
+

RE: [PATCH v1] raw/ifpga: initialize variable to avoid compile error

[Gao, DaxueX]

> -Original Message-
> From: Wei Huang 
> Sent: 2022年3月16日 15:27
> To: dev@dpdk.org; tho...@monjalon.net; Xu, Rosen ;
> nipun.gu...@nxp.com; hemant.agra...@nxp.com
> Cc: sta...@dpdk.org; Zhang, Tianfei ; Zhang, Qi Z
> ; Yigit, Ferruh ; Huang, Wei
> 
> Subject: [PATCH v1] raw/ifpga: initialize variable to avoid compile error
> 
> Compile failed with cflag optimization=1 on Ubuntu20.04 with GCC10.3, it
> reported vendor_id and dev_id may be used uninitialized in function
> ifpga_rawdev_fill_info().
> Actually it's not the truth, the variables are initialized in function
> ifpga_get_dev_vendor_id(). To avoid such compile error, the variables are
> initialized when they are defined.
> 
> Signed-off-by: Wei Huang 
> Acked-by: Tianfei Zhang 
> Acked-by: Rosen Xu 
> ---

Tested-by: Daxue Gao 

Re: [PATCH v1] raw/ifpga: initialize variable to avoid compile error

[Thomas Monjalon]

16/03/2022 10:27, Gao, DaxueX:
> From: Wei Huang 
> > 
> > Compile failed with cflag optimization=1 on Ubuntu20.04 with GCC10.3, it
> > reported vendor_id and dev_id may be used uninitialized in function
> > ifpga_rawdev_fill_info().
> > Actually it's not the truth, the variables are initialized in function
> > ifpga_get_dev_vendor_id(). To avoid such compile error, the variables are
> > initialized when they are defined.
> > 
> > Signed-off-by: Wei Huang 
> > Acked-by: Tianfei Zhang 
> > Acked-by: Rosen Xu 
> > ---
> 
> Tested-by: Daxue Gao 

We need a "Fixes:" line to help backports, please.

Re: rte_flow API change request: tunnel info restoration is too slow

[Thomas Monjalon]

15/03/2022 23:12, Ilya Maximets:
> Hi, everyone.
> 
> After implementing support for tunnel offloading in OVS we faced a
> significant performance issue caused by the requirement to call
> rte_flow_get_restore_info() function on a per-packet basis.
> 
> The main problem is that once the tunnel offloading is configured,
> there is no way for the application to tell if a particular packet
> was partially processed in the hardware and the tunnel info has to
> be restored.  What we have to do right now is to call the
> rte_flow_get_restore_info() unconditionally for every packet.  The
> result of that call says if we have the tunnel info or not.
> 
> rte_flow_get_restore_info() call itself is very heavy.  It is at
> least a couple of indirect function calls and the device lock
> on the application side (not-really-thread-safety of the rte_flow
> API is a separate topic).  Internal info lookup inside the driver
> also costs a lot (depends on a driver).
> 
> It has been measured that having this call on a per-packet basis can
> reduce application performance (OVS) by a factor of 3 in some cases:
>   https://mail.openvswitch.org/pipermail/ovs-dev/2021-November/389265.html
>   
> https://github.com/openvswitch/ovs/commit/6e50c1651869de0335eb4b7fd0960059c5505f5c
> (Above patch avoid the problem in a hacky way for devices that doesn't
>  support tunnel offloading, but it's not applicable to situation
>  where device actually supports it, since the API has to be called.)
> 
> Another tricky part is that we have to call rte_flow_get_restore_info()
> before checking other parts of the mbuf, because mlx5 driver, for
> example, re-uses the mbuf.hash.fdir value for both tunnel info
> restoration and classification offloading, so the application has
> no way to tell which one is used right now and has to call the
> restoration API first in order to find out.
> 
> 
> What we need:
> 
> A generic and fast (couple of CPU cycles) API that will clearly say
> if the heavy rte_flow_get_restore_info() has to be called for a
> particular packet or not.  Ideally, that should be a static mbuf
> flag that can be easily checked by the application.

A dynamic mbuf flag, defined in the API, looks to be a good idea.

> Calls inside the device driver are way too slow for that purpose,
> especially if they are not fully thread-safe, or require complex
> lookups or calculations.
> 
> I'm assuming here that packets that really need the tunnel info
> restoration should be fairly rare.
> 
> 
> Current state:
> 
> Currently, the get_restore_info() API is implemented only for mlx5
> and sfc drivers, AFAICT.
> SFC driver is already using mbuf flag, but
> it's dynamic and not exposed to the application.

What is this flag?

> MLX5 driver re-uses mbuf.hash.fdir value
> and performs a heavy lookup inside the driver.

We should avoid re-using a field.

> For now OVS doesn't support tunnel offload with DPDK formally, the
> code in OVS is under the experimental API ifdef and not compiled-in
> by default.
> 
> //Let me know if there is more formal way to submit such requests.

That's a well written request, thanks.
If you are looking for something more formal,
it could be a patch in the API.

[PATCH] doc: fix support table for ETH and VLAN flow items

[Ilya Maximets]

'has_vlan' attribute is only supported by sfc, mlx5 and cnxk.
Other drivers doesn't support it.  Most of them (like i40e) just
ignore it silently.  Some drivers (like mlx4) never had a full
support of the eth item even before introduction of 'has_vlan'
(mlx4 allows to match on the destination MAC only).

Same for the 'has_more_vlan' flag of the vlan item.

Changing the support level to 'partial' for all such drivers.
This doesn't solve the issue, but at least marks the problematic
drivers.

Some details are available in:
  https://bugs.dpdk.org/show_bug.cgi?id=958

Fixes: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")
Cc: sta...@dpdk.org

Signed-off-by: Ilya Maximets 
---

I added the stable in CC, but the patch should be extended while
backporting.  For 21.11 the cnxk driver should be also updated,
for 20.11, sfc driver should also be included.

 doc/guides/nics/features/bnxt.ini   | 4 ++--
 doc/guides/nics/features/cxgbe.ini  | 4 ++--
 doc/guides/nics/features/dpaa2.ini  | 4 ++--
 doc/guides/nics/features/e1000.ini  | 2 +-
 doc/guides/nics/features/enic.ini   | 4 ++--
 doc/guides/nics/features/hinic.ini  | 2 +-
 doc/guides/nics/features/hns3.ini   | 4 ++--
 doc/guides/nics/features/i40e.ini   | 4 ++--
 doc/guides/nics/features/iavf.ini   | 4 ++--
 doc/guides/nics/features/ice.ini| 4 ++--
 doc/guides/nics/features/igc.ini| 2 +-
 doc/guides/nics/features/ipn3ke.ini | 4 ++--
 doc/guides/nics/features/ixgbe.ini  | 4 ++--
 doc/guides/nics/features/mlx4.ini   | 4 ++--
 doc/guides/nics/features/mvpp2.ini  | 4 ++--
 doc/guides/nics/features/tap.ini| 4 ++--
 doc/guides/nics/features/txgbe.ini  | 4 ++--
 17 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/doc/guides/nics/features/bnxt.ini 
b/doc/guides/nics/features/bnxt.ini
index afb5414b49..ac682c5779 100644
--- a/doc/guides/nics/features/bnxt.ini
+++ b/doc/guides/nics/features/bnxt.ini
@@ -57,7 +57,7 @@ Perf doc = Y
 
 [rte_flow items]
 any  = Y
-eth  = Y
+eth  = P
 ipv4 = Y
 ipv6 = Y
 gre  = Y
@@ -71,7 +71,7 @@ represented_port = Y
 tcp  = Y
 udp  = Y
 vf   = Y
-vlan = Y
+vlan = P
 vxlan= Y
 
 [rte_flow actions]
diff --git a/doc/guides/nics/features/cxgbe.ini 
b/doc/guides/nics/features/cxgbe.ini
index f674803ec4..f9912390fb 100644
--- a/doc/guides/nics/features/cxgbe.ini
+++ b/doc/guides/nics/features/cxgbe.ini
@@ -36,7 +36,7 @@ x86-64   = Y
 Usage doc= Y
 
 [rte_flow items]
-eth  = Y
+eth  = P
 ipv4 = Y
 ipv6 = Y
 pf   = Y
@@ -44,7 +44,7 @@ phy_port = Y
 tcp  = Y
 udp  = Y
 vf   = Y
-vlan = Y
+vlan = P
 
 [rte_flow actions]
 count= Y
diff --git a/doc/guides/nics/features/dpaa2.ini 
b/doc/guides/nics/features/dpaa2.ini
index 4c06841a87..09ce66c788 100644
--- a/doc/guides/nics/features/dpaa2.ini
+++ b/doc/guides/nics/features/dpaa2.ini
@@ -31,7 +31,7 @@ ARMv8= Y
 Usage doc= Y
 
 [rte_flow items]
-eth  = Y
+eth  = P
 gre  = Y
 icmp = Y
 ipv4 = Y
@@ -41,7 +41,7 @@ raw  = Y
 sctp = Y
 tcp  = Y
 udp  = Y
-vlan = Y
+vlan = P
 
 [rte_flow actions]
 drop = Y
diff --git a/doc/guides/nics/features/e1000.ini 
b/doc/guides/nics/features/e1000.ini
index e4bdef6da9..a9cbed1c3c 100644
--- a/doc/guides/nics/features/e1000.ini
+++ b/doc/guides/nics/features/e1000.ini
@@ -31,7 +31,7 @@ x86-32   = Y
 x86-64   = Y
 
 [rte_flow items]
-eth  = Y
+eth  = P
 ipv4 = Y
 ipv6 = Y
 raw  = Y
diff --git a/doc/guides/nics/features/enic.ini 
b/doc/guides/nics/features/enic.ini
index 61bec4910e..6dbea9f36e 100644
--- a/doc/guides/nics/features/enic.ini
+++ b/doc/guides/nics/features/enic.ini
@@ -40,7 +40,7 @@ Usage doc= Y
 
 [rte_flow items]
 ecpri= Y
-eth  = Y
+eth  = P
 geneve   = Y
 geneve_opt   = Y
 gtp  = Y
@@ -52,7 +52,7 @@ raw  = Y
 sctp = Y
 tcp  = Y
 udp  = Y
-vlan = Y
+vlan = P
 vxlan= Y
 
 [rte_flow actions]
diff --git a/doc/guides/nics/features/hinic.ini 
b/doc/guides/nics/features/hinic.ini
index 9f6f0ebf3a..ada6607fe9 100644
--- a/doc/guides/nics/features/hinic.ini
+++ b/doc/guides/nics/features/hinic.ini
@@ -40,7 +40,7 @@ ARMv8= Y
 
 [rte_flow items]
 any  = Y
-

Re: rte_flow API change request: tunnel info restoration is too slow

[Ilya Maximets]

On 3/16/22 10:41, Thomas Monjalon wrote:
> 15/03/2022 23:12, Ilya Maximets:
>> Hi, everyone.
>>
>> After implementing support for tunnel offloading in OVS we faced a
>> significant performance issue caused by the requirement to call
>> rte_flow_get_restore_info() function on a per-packet basis.
>>
>> The main problem is that once the tunnel offloading is configured,
>> there is no way for the application to tell if a particular packet
>> was partially processed in the hardware and the tunnel info has to
>> be restored.  What we have to do right now is to call the
>> rte_flow_get_restore_info() unconditionally for every packet.  The
>> result of that call says if we have the tunnel info or not.
>>
>> rte_flow_get_restore_info() call itself is very heavy.  It is at
>> least a couple of indirect function calls and the device lock
>> on the application side (not-really-thread-safety of the rte_flow
>> API is a separate topic).  Internal info lookup inside the driver
>> also costs a lot (depends on a driver).
>>
>> It has been measured that having this call on a per-packet basis can
>> reduce application performance (OVS) by a factor of 3 in some cases:
>>   https://mail.openvswitch.org/pipermail/ovs-dev/2021-November/389265.html
>>   
>> https://github.com/openvswitch/ovs/commit/6e50c1651869de0335eb4b7fd0960059c5505f5c
>> (Above patch avoid the problem in a hacky way for devices that doesn't
>>  support tunnel offloading, but it's not applicable to situation
>>  where device actually supports it, since the API has to be called.)
>>
>> Another tricky part is that we have to call rte_flow_get_restore_info()
>> before checking other parts of the mbuf, because mlx5 driver, for
>> example, re-uses the mbuf.hash.fdir value for both tunnel info
>> restoration and classification offloading, so the application has
>> no way to tell which one is used right now and has to call the
>> restoration API first in order to find out.
>>
>>
>> What we need:
>>
>> A generic and fast (couple of CPU cycles) API that will clearly say
>> if the heavy rte_flow_get_restore_info() has to be called for a
>> particular packet or not.  Ideally, that should be a static mbuf
>> flag that can be easily checked by the application.
> 
> A dynamic mbuf flag, defined in the API, looks to be a good idea.

Makes sense.  OTOH, I'm not sure what is the profit of having it
dynamically allocated if it will need to be always defined.
But, well, it doesn't really matter, I guess.

> 
>> Calls inside the device driver are way too slow for that purpose,
>> especially if they are not fully thread-safe, or require complex
>> lookups or calculations.
>>
>> I'm assuming here that packets that really need the tunnel info
>> restoration should be fairly rare.
>>
>>
>> Current state:
>>
>> Currently, the get_restore_info() API is implemented only for mlx5
>> and sfc drivers, AFAICT.
>> SFC driver is already using mbuf flag, but
>> it's dynamic and not exposed to the application.
> 
> What is this flag?

SFC driver defines a dynamic field 'rte_net_sfc_dynfield_ft_id'
and the corresponding flag 'rte_net_sfc_dynflag_ft_id_valid' to
check if the field contains a valid data.

> 
>> MLX5 driver re-uses mbuf.hash.fdir value
>> and performs a heavy lookup inside the driver.
> 
> We should avoid re-using a field.

+1 from me, but I'm not familiar with the mlx5 driver enough
to tell how to change it.

> 
>> For now OVS doesn't support tunnel offload with DPDK formally, the
>> code in OVS is under the experimental API ifdef and not compiled-in
>> by default.
>>
>> //Let me know if there is more formal way to submit such requests.
> 
> That's a well written request, thanks.
> If you are looking for something more formal,
> it could be a patch in the API.

I'm not looking for now. :)
I think we need an agreement from driver maintainers first.  And
I don't think we can introduce such API change without changing
drivers first, because otherwise we'll end up with the 'has_vlan'
situation and the broken offloading support.

Best regards, Ilya Maximets.

Re: [PATCH] net/cnxk: fix error when compiled for x86

[Kevin Traynor]

On 16/03/2022 03:32, Gao, DaxueX wrote:

-Original Message-
From: Jerin Jacob 
Sent: 2022年3月10日 16:49
To: Jiang, YuX 
Cc: Rakesh Kudurumalla ; Nithin Dabilpuram
; Kiran Kumar K ;
Sunil Kumar Kori ; Satha Rao ;
dev@dpdk.org; jer...@marvell.com; sta...@dpdk.org; Yigit, Ferruh

Subject: Re: [PATCH] net/cnxk: fix error when compiled for x86

On Thu, Mar 10, 2022 at 7:06 AM Jiang, YuX  wrote:


Hi maintainers,

Who can give acked-by for this patch?
May I know this patch can be merged into 22.03 or not?



Acked-by: Jerin Jacob  Updated the git commit as follows
and applied to dpdk-next-net-mrvl/for-next-net. Thanks

 net/cnxk: fix build error with optimization

 Fix the following build error seen with --optimization=1 and
 GCC 10.3.0.

 ../drivers/net/cnxk/cnxk_ethdev_mtr.c: In function
 ‘cnxk_nix_mtr_policy_validate’:
 ../lib/ethdev/rte_mtr_driver.h:188:10: error: ‘str’ may be used
 uninitialized in this function [-Werror=maybe-uninitialized]

 ../drivers/net/cnxk/cn10k_rx.h:149:2 error: ‘frag_ptr’ may be
 used uninitialized in this function

 Bugzilla ID: 939
 Fixes: b526599020ef ("net/cnxk: fix build with GCC 12")
 Cc: sta...@dpdk.org

 Reported-by: Ferruh Yigit 
 Signed-off-by: Rakesh Kudurumalla 
 Tested-by: Daxue Gao 
 Acked-by: Jerin Jacob 





-Original Message-
From: Rakesh Kudurumalla 
Sent: 2022年3月4日 22:24
To: Nithin Dabilpuram ; Kiran Kumar K
; Sunil Kumar Kori ;
Satha Rao 
Cc: dev@dpdk.org; jer...@marvell.com; Rakesh Kudurumalla
; sta...@dpdk.org; Yigit, Ferruh

Subject: [PATCH] net/cnxk: fix error when compiled for x86

fix error when compiled for x86 platform when compiled with
optimization flag enabled
error: ‘str’ may be used uninitialized in this function
error: ‘frag_ptr’ may be used uninitialized in this function

Bugzilla ID: 939
Fixes: b526599020ef ("net/cnxk: fix build with GCC 12")
Cc: sta...@dpdk.org

Reported-by: Ferruh Yigit 
Signed-off-by: Rakesh Kudurumalla 
---

[Gao, DaxueX]

Hi Rakesh, Jacob and All,

This patch 
http://patchwork.dpdk.org/project/dpdk/patch/20220304142337.911828-1-rkuduruma...@marvell.com/
 has been merged to DPDK 22.03 latest main branch.
It can resolve old problem, but introduce new problem, please check your code, 
thanks.
Notes: RHEL8.4 passed, Ubuntu20.04 failed.



I am not taking this patch for 21.11 as it seems to cause other issues 
and i don't trust that the fixes tag is correct, but there is so much 
churn in cnxk it is hard to quickly tell. If this series of fixes is 
needed for 21.11 please send a backport with correct 'Fixes' and '[PATCH 
21.11]' subject-prefix to stable branch. Thanks, Kevin.



Bad commit: 
http://git.dpdk.org/dpdk/commit/?id=68f8a52a6b0ad6b2d4564928aebb21c2ca66
OS: Ubuntu20.04/5.8.0-48-generic
Compiler: gcc (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0

Error info:
[2302/3456] Compiling C object 
drivers/libtmp_rte_raw_ifpga.a.p/raw_ifpga_ifpga_rawdev.c.o
FAILED: drivers/libtmp_rte_raw_ifpga.a.p/raw_ifpga_ifpga_rawdev.c.o
gcc -Idrivers/libtmp_rte_raw_ifpga.a.p -Idrivers -I../drivers 
-Idrivers/raw/ifpga -I../drivers/raw/ifpga -Idrivers/raw/ifpga/base 
-I../drivers/raw/ifpga/base -Idrivers/net/ipn3ke -I../drivers/net/ipn3ke 
-Idrivers/net/i40e -I../drivers/net/i40e -Ilib/rawdev -I../lib/rawdev -I. -I.. 
-Iconfig -I../config -Ilib/eal/include -I../lib/eal/include 
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include 
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal 
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics 
-Ilib/telemetry -I../lib/telemetry -Ilib/ethdev -I../lib/ethdev -Ilib/net 
-I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring 
-I../lib/ring -Ilib/meter -I../lib/meter -Ilib/pci -I../lib/pci 
-Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux 
-Idrivers/bus/vdev -I../drivers/bus/vdev -Idrivers/bus/ifpga 
-I../drivers/bus/ifpga -Idrivers/net/i40e/base -I../drivers/net/i40e/base 
-Ilib/hash -I../lib/hash -Ilib/rcu -I../lib/rcu -Ilib/sched -I../lib/sched 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-Wextra -Werror -O1 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat 
-Wformat-nonliteral -Wformat-security -Wmissing-declarations 
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith 
-Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings 
-Wno-address-of-packed-member -Wno-packed-not-aligned 
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC 
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API 
-Wno-format-truncation -DRTE_LOG_DEFAULT_LOGTYPE=pmd.raw.ifpga -MD -MQ 
drivers/libtmp_rte_raw_ifpga.a.p/raw_ifpga_ifpga_rawdev.c.o -MF 
drivers/libtmp_rte_raw_ifpga.a.p/raw_ifpga_ifpga_rawdev.c.o.d -o 
drivers/libtmp_rte_raw_ifpga.a.p/raw_ifpga_ifpga_rawdev.c.o -c 
../drivers/raw/ifpga/ifpga_rawdev.c
../drivers/raw/ifpga/ifpga_rawdev.c: In function ‘

rte flow for arp packet

[Yaron Illouz]

Hi

Is there a way using rte_flow to send arp and ndp packet to specific rx queue 
with dpdk

[Bug 959] tsc hz not matching kernel reported tcs frequency

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=959

Bug ID: 959
   Summary: tsc hz not matching kernel reported tcs frequency
   Product: DPDK
   Version: 21.11
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: maria.lingem...@ericsson.com
  Target Milestone: ---

On some machines the dpdk value of tsc hz does not match the kernel value.

The effect of this can be observed by writing a small test program that
measures elapsed time using two different sources.

The issue has been shown by taking clock_gettime() and rte_get_tsc_cycles(),
sleep, and then fetch the time stamps again with clock_gettime() and
rte_get_tsc_cycles().

When calculating the time from the two sources we notice a difference of ~2.3
ms per second.

Example from a test run with 1 second sleep:

rte_get_tsc_hz=24
clock_gettime=156 us, tsc_time=997708 us, diff=2348 us

Info from dmesg:
tsc: Refined TSC clocksource calibration: 2394.365 MHz

We don't see the time difference on 
Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Linux kernel 4.13.0-16-generic

but we do observe it on 
Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Linux kernel 5.4.0-100-generic

-- 
You are receiving this mail because:
You are the assignee for the bug.

RE: rte flow for arp packet

[Ori Kam]

Hi
You need to create a rule that matches the arp/ndp packets and use the queue 
action.

From: Yaron Illouz 
Sent: Wednesday, March 16, 2022 2:42 PM
To: dev@dpdk.org
Cc: Ori Kam 
Subject: rte flow for arp packet

Hi

Is there a way using rte_flow to send arp and ndp packet to specific rx queue 
with dpdk

RE: release candidate 22.03-rc4

[Jiang, YuX]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Tuesday, March 15, 2022 9:21 AM
> To: annou...@dpdk.org
> Subject: release candidate 22.03-rc4
>
> A new DPDK release candidate is ready for testing:
>   https://git.dpdk.org/dpdk/tag/?id=v22.03-rc4
>
> There are 31 new patches in this snapshot.
>
> Release notes:
>   https://doc.dpdk.org/guides/rel_notes/release_22_03.html
>
> This is the last release candidate.
> Only documentation should be updated before the release.
>
> You may share some release validation results by replying to this message at
> dev@dpdk.org and by adding tested hardware in the release notes.
>
> Please think about sharing your roadmap now for DPDK 22.07.
>
> Thank you everyone
>

Update the test status for Intel part. Till now dpdk22.03-rc4 test is finished. 
No critical issue is found.
# Basic Intel(R) NIC testing
* Build or compile:
 *Build: cover the build test combination with latest GCC/Clang/ICC version and 
the popular OS revision such as Ubuntu20.04, Fedora35, RHEL8.4, RHEL8.5 etc.
  - All test passed.
  - One known issue https://bugs.dpdk.org/show_bug.cgi?id=928, use "meson setup 
-Ddisable_drivers=event/cnxk" to build.
 *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu20.04 
and RHEL8.4.
  - All test done. One known issue https://bugs.dpdk.org/show_bug.cgi?id=939,
> It has fix which has been merged into latest dpdk, but new error 
"raw/ifpga" build failed is found,
> Intel dev has provided patch, and verify passed. 
http://patches.dpdk.org/project/dpdk/patch/20220316072630.1916479-1-wei.hu...@intel.com/

* PF(i40e, ixgbe): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc.
 - All test done. No new issue is found.

* VF(i40e, ixgbe): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum 
offload/VLAN/VXLAN, etc.
 - All test done. No new issue, known issue about 
"stats_checks/test_xstats_check_vf: pkt not recieve when rx_mode=novector", has 
fix but not merged.

* PF/VF(ice): test scenarios including Switch features/Package Management/Flow 
Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
 - All test done. No new issue is found.

* Intel NIC single core/NIC performance: test scenarios including PF/VF single 
core performance test, RFC2544 Zero packet loss performance test, etc.
 - All test done. No big performance drop.

 * Power and IPsec:
 * Power: test scenarios including bi-direction/Telemetry/Empty Poll 
Lib/Priority Base Frequency, etc.
  - All test passed.
 * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - 
QAT&SW/FIB library, etc.
  - All test done. One new issue is found, Intel dev is investigating.

# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such as 
PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE 
ESXI 7.0u3, etc.
 - All test done. Two known bugs, have fix but not merged.

* Cryptodev:
 *Function test: test scenarios including Cryptodev API testing/CompressDev 
ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
  - All test done. Two known issues, Intel dev is investigating.
 *Performance test: test scenarios including Thoughput Performance /Cryptodev 
Latency, etc.
  - All test done.

[PATCH v2 0/9] Improve Linux drivers GSG section

[Bruce Richardson]

This patchset reworks large parts of the linux drivers section of the
Linux Getting Started Guide, so as to make it clearer and easier to
read. The overall flow of the page is adjusted so that more important
information is nearer the top, and so that all information on VFIO is
consolidated into a single section. In terms of the content of the
sections, there are some minor changes to adjust what is a warning vs
just a "note" in the doc, and there are some updates to increase
emphasis on VFIO ovs UIO.

Including stable on CC for the set, as all patches may be candidates for
backport to help improve docs for older releases too.

V2:
* Rebased on top of main, now that other doc patches are applied
* Reworded commit titles to use "doc:" prefix

Bruce Richardson (9):
  doc: replace special characters for (R) symbol in Linux GSG
  doc: fix missing note on UIO module in Linux GSG
  doc: make UIO safety warning more visible in Linux GSG
  doc: move section on binding drivers up the page in GSG
  doc: emphasise VFIO over UIO-based modules in GSG
  doc: split GSG VFIO section into subsections
  doc: move GSG section on UIO to the end of drivers page
  doc: consolidate all VFIO content on GSG driver page
  doc: change informational warnings to notes in Linux GSG

 doc/guides/linux_gsg/enable_func.rst   |   8 +-
 doc/guides/linux_gsg/linux_drivers.rst | 396 +
 doc/guides/linux_gsg/sys_reqs.rst  |   6 +-
 3 files changed, 217 insertions(+), 193 deletions(-)

--
2.32.0

[PATCH v2 1/9] doc: replace special characters for (R) symbol in Linux GSG

[Bruce Richardson]

Some IDEs, such as eclipse, complained on save about the use of special
characters in the (R) symbol in linux GSG doc. We can replace those with
the equivalent "|reg|" text, and including isonum.txt.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/enable_func.rst   | 8 +---
 doc/guides/linux_gsg/linux_drivers.rst | 6 --
 doc/guides/linux_gsg/sys_reqs.rst  | 6 --
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/doc/guides/linux_gsg/enable_func.rst 
b/doc/guides/linux_gsg/enable_func.rst
index 44c3b05130..1df3ab0255 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -1,6 +1,8 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2014 Intel Corporation.

+.. include:: 
+
 .. _Enabling_Additional_Functionality:

 Enabling Additional Functionality
@@ -66,15 +68,15 @@ system objects' permissions should be adjusted:
 Power Management and Power Saving Functionality
 ---

-Enhanced Intel SpeedStep® Technology must be enabled in the platform BIOS if 
the power management feature of DPDK is to be used.
+Enhanced Intel SpeedStep\ |reg| Technology must be enabled in the platform 
BIOS if the power management feature of DPDK is to be used.
 Otherwise, the sys file folder ``/sys/devices/system/cpu/cpu0/cpufreq`` will 
not exist, and the CPU frequency- based power management cannot be used.
 Consult the relevant BIOS documentation to determine how these settings can be 
accessed.

-For example, on some Intel reference platform BIOS variants, the path to 
Enhanced Intel SpeedStep® Technology is::
+For example, on some Intel reference platform BIOS variants, the path to 
Enhanced Intel SpeedStep\ |reg| Technology is::

Advanced
  -> Processor Configuration
- -> Enhanced Intel SpeedStep® Tech
+ -> Enhanced Intel SpeedStep\ |reg| Tech

 In addition, C3 and C6 should be enabled as well for power management. The 
path of C3 and C6 on the same platform BIOS is::

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index 006a9df83e..ef6fec10d7 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -3,6 +3,8 @@
 Copyright 2017 Mellanox Technologies, Ltd
 All rights reserved.

+.. include:: 
+
 .. _linux_gsg_linux_drivers:

 Linux Drivers
@@ -99,7 +101,7 @@ The token will be used for all PF and VF ports within the 
application.

 To make use of full VFIO functionality,
 both kernel and BIOS must support and be configured
-to use IO virtualization (such as Intel® VT-d).
+to use IO virtualization (such as Intel\ |reg| VT-d).

 .. note::

@@ -335,7 +337,7 @@ Please refer to earlier sections on how to configure kernel 
parameters
 correctly for your system.

 If the kernel is configured correctly, one also has to make sure that
-the BIOS configuration has virtualization features (such as Intel® VT-d).
+the BIOS configuration has virtualization features (such as Intel\ |reg| VT-d).
 There is no standard way to check if the platform is configured correctly,
 so please check with your platform documentation to see if it has such 
features,
 and how to enable them.
diff --git a/doc/guides/linux_gsg/sys_reqs.rst 
b/doc/guides/linux_gsg/sys_reqs.rst
index b2eacac6dc..08d45898f0 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -1,6 +1,8 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2014 Intel Corporation.

+.. include:: 
+
 System Requirements
 ===

@@ -68,10 +70,10 @@ Compilation of the DPDK

 **Optional Tools:**

-*   Intel® C++ Compiler (icc). For installation, additional libraries may be 
required.
+*   Intel\ |reg| C++ Compiler (icc). For installation, additional libraries 
may be required.
 See the icc Installation Guide found in the Documentation directory under 
the compiler installation.

-*   IBM® Advance ToolChain for Powerlinux. This is a set of open source 
development tools and runtime libraries
+*   IBM\ |reg| Advance ToolChain for Powerlinux. This is a set of open source 
development tools and runtime libraries
 which allows users to take leading edge advantage of IBM's latest POWER 
hardware features on Linux. To install
 it, see the IBM official installation document.

--
2.32.0

[PATCH v2 2/9] doc: fix missing note on UIO module in Linux GSG

[Bruce Richardson]

The docs on binding drivers was updated as part of the removal of the
igb_uio module from the main DPDK repo. As part of that update, a note
about uio_pci_generic requiring legacy interrupts was removed, but
should have been kept.

Fixes: 56bb5841fd06 ("kernel/linux: remove igb_uio")
Cc: tho...@monjalon.net
Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index ef6fec10d7..bd983b4d81 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -174,6 +174,11 @@ It can be loaded as shown below:
sudo modprobe uio
sudo insmod igb_uio.ko
 
+.. note::
+
+For some devices which lack support for legacy interrupts, e.g. virtual 
function
+(VF) devices, the ``igb_uio`` module may be needed in place of 
``uio_pci_generic``.
+
 .. note::
 
If UEFI secure boot is enabled,
-- 
2.32.0

[PATCH v2 3/9] doc: make UIO safety warning more visible in Linux GSG

[Bruce Richardson]

The GSG has a note warning that use of UIO is inherently unsafe due to
lack of IOMMU protection. However, this was only flagged as a "NOTE",
meaning it could easily be missed. Changing the rst tag from "note" to
"warning" and moving it to the top of the UIO subsection makes this a
lot more visible to users.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index bd983b4d81..f0a274df6a 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -153,6 +153,11 @@ After that, VFIO can be used with hardware devices as 
usual.
 UIO
 ---

+.. warning::
+
+   Using UIO drivers is inherently unsafe due to this method lacking IOMMU 
protection,
+   and can only be done by root user.
+
 In situations where using VFIO is not an option, there are alternative drivers 
one can use.
 In many cases, the standard ``uio_pci_generic`` module included in the Linux 
kernel
 can be used as a substitute for VFIO. This module can be loaded using the 
command:
@@ -195,11 +200,6 @@ It can be loaded as shown below:
in GRUB command line on x86_64 systems,
or add ``iommu.passthrough=1`` on aarch64 systems.

-.. note::
-
-   Using UIO drivers is inherently unsafe due to this method lacking IOMMU 
protection,
-   and can only be done by root user.
-
 .. _bifurcated_driver:

 Bifurcated Driver
--
2.32.0

[PATCH v2 4/9] doc: move section on binding drivers up the page in GSG

[Bruce Richardson]

While the details of VFIO and UIO may be of interest to some, most users
of the doc are likely primarily interested in how to bind their devices
to the kernel driver and then move on to running the app. Therefore, the
most important part of the "Linux Drivers" section of the GSG is the
subsection on "Binding and Unbinding", so put that first.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 179 +
 1 file changed, 90 insertions(+), 89 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index f0a274df6a..b93feae7a1 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -14,6 +14,96 @@ Different PMDs may require different kernel drivers in order 
to work properly.
 Depending on the PMD being used, a corresponding kernel driver should be 
loaded,
 and network ports should be bound to that driver.

+.. _linux_gsg_binding_kernel:
+
+Binding and Unbinding Network Ports to/from the Kernel Modules
+--
+
+.. note::
+
+   PMDs which use the bifurcated driver should not be unbound from their 
kernel drivers.
+   This section is for PMDs which use the UIO or VFIO drivers.
+   See :ref:`bifurcated_driver` section for more details.
+
+As of release 1.4, DPDK applications no longer automatically unbind all 
supported network ports from the kernel driver in use.
+Instead, in case the PMD being used use the VFIO or UIO drivers,
+all ports that are to be used by a DPDK application must be bound to
+the ``vfio-pci``, ``uio_pci_generic``, or ``igb_uio`` module
+before the application is run.
+For such PMDs, any network ports under Linux* control will be ignored and 
cannot be used by the application.
+
+To bind ports to the ``vfio-pci``, ``uio_pci_generic`` or ``igb_uio`` module
+for DPDK use, or to return ports to Linux control,
+a utility script called ``dpdk-devbind.py`` is provided in the ``usertools`` 
subdirectory.
+This utility can be used to provide a view of the current state of the network 
ports on the system,
+and to bind and unbind those ports from the different kernel modules,
+including the VFIO and UIO modules.
+The following are some examples of how the script can be used.
+A full description of the script and its parameters can be obtained
+by calling the script with the ``--help`` or ``--usage`` options.
+Note that the UIO or VFIO kernel modules to be used,
+should be loaded into the kernel before running the ``dpdk-devbind.py`` script.
+
+.. warning::
+
+   Due to the way VFIO works, there are certain limitations
+   to which devices can be used with VFIO.
+   Mainly it comes down to how IOMMU groups work.
+   Any Virtual Function device can usually be used with VFIO on its own,
+   but physical devices may require either all ports bound to VFIO,
+   or some of them bound to VFIO while others not being bound to anything at 
all.
+
+   If your device is behind a PCI-to-PCI bridge,
+   the bridge will then be part of the IOMMU group in which your device is in.
+   Therefore, the bridge driver should also be unbound from the bridge PCI 
device
+   for VFIO to work with devices behind the bridge.
+
+.. warning::
+
+   While any user can run the ``dpdk-devbind.py`` script
+   to view the status of the network ports,
+   binding or unbinding network ports requires root privileges.
+
+To see the status of all network ports on the system:
+
+.. code-block:: console
+
+./usertools/dpdk-devbind.py --status
+
+Network devices using DPDK-compatible driver
+
+:82:00.0 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
+:82:00.1 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
+
+Network devices using kernel driver
+===
+:04:00.0 'I350 1-GbE NIC' if=em0  drv=igb unused=uio_pci_generic 
*Active*
+:04:00.1 'I350 1-GbE NIC' if=eth1 drv=igb unused=uio_pci_generic
+:04:00.2 'I350 1-GbE NIC' if=eth2 drv=igb unused=uio_pci_generic
+:04:00.3 'I350 1-GbE NIC' if=eth3 drv=igb unused=uio_pci_generic
+
+Other network devices
+=
+
+
+To bind device ``eth1``,``04:00.1``, to the ``uio_pci_generic`` driver:
+
+.. code-block:: console
+
+./usertools/dpdk-devbind.py --bind=uio_pci_generic 04:00.1
+
+or, alternatively,
+
+.. code-block:: console
+
+./usertools/dpdk-devbind.py --bind=uio_pci_generic eth1
+
+To restore device ``82:00.0`` to its original kernel binding:
+
+.. code-block:: console
+
+./usertools/dpdk-devbind.py --bind=ixgbe 82:00.0
+
 VFIO
 

@@ -225,95 +315,6 @@ More about the bifurcated driver can be found in
 `Mellanox Bifurcated DPDK PMD
 
`__.

-.. _linux_gsg_binding_kernel:
-
-Binding and Un

[PATCH v2 5/9] doc: emphasise VFIO over UIO-based modules in GSG

[Bruce Richardson]

VFIO is to be strongly preferred over uio-based modules, so update our
text and examples to only refer to vfio, giving an initial reference at
the start to uio as a fallback option.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 47 +++---
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index b93feae7a1..bd649db929 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -25,14 +25,18 @@ Binding and Unbinding Network Ports to/from the Kernel 
Modules
This section is for PMDs which use the UIO or VFIO drivers.
See :ref:`bifurcated_driver` section for more details.

-As of release 1.4, DPDK applications no longer automatically unbind all 
supported network ports from the kernel driver in use.
-Instead, in case the PMD being used use the VFIO or UIO drivers,
-all ports that are to be used by a DPDK application must be bound to
-the ``vfio-pci``, ``uio_pci_generic``, or ``igb_uio`` module
-before the application is run.
-For such PMDs, any network ports under Linux* control will be ignored and 
cannot be used by the application.
-
-To bind ports to the ``vfio-pci``, ``uio_pci_generic`` or ``igb_uio`` module
+.. note::
+
+   It is recommended that ``vfio-pci`` be used as the kernel module for 
DPDK-bound ports in all cases.
+   If an IOMMU is unavailable, the ``vfio-pci`` can be used in 
:ref:`no-iommu` mode.
+   If, for some reason, vfio is unavailable, then UIO-based modules, 
``igb_uio`` and ``uio_pci_generic`` may be used.
+   See section :ref:`uio` for details.
+
+Most devices require that the hardware to be used by DPDK be unbound from the 
kernel driver it uses,
+and instead be bound to the ``vfio-pci`` kernel module before the application 
is run.
+For such PMDs, any network ports or other hardware under Linux* control will 
be ignored and cannot be used by the application.
+
+To bind ports to the ``vfio-pci`` module
 for DPDK use, or to return ports to Linux control,
 a utility script called ``dpdk-devbind.py`` is provided in the ``usertools`` 
subdirectory.
 This utility can be used to provide a view of the current state of the network 
ports on the system,
@@ -72,37 +76,38 @@ To see the status of all network ports on the system:

 Network devices using DPDK-compatible driver
 
-:82:00.0 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
-:82:00.1 '82599EB 10-GbE NIC' drv=uio_pci_generic unused=ixgbe
+:82:00.0 '82599EB 10-GbE NIC' drv=vfio-pci unused=ixgbe
+:82:00.1 '82599EB 10-GbE NIC' drv=vfio-pci unused=ixgbe

 Network devices using kernel driver
 ===
-:04:00.0 'I350 1-GbE NIC' if=em0  drv=igb unused=uio_pci_generic 
*Active*
-:04:00.1 'I350 1-GbE NIC' if=eth1 drv=igb unused=uio_pci_generic
-:04:00.2 'I350 1-GbE NIC' if=eth2 drv=igb unused=uio_pci_generic
-:04:00.3 'I350 1-GbE NIC' if=eth3 drv=igb unused=uio_pci_generic
+:04:00.0 'I350 1-GbE NIC' if=em0  drv=igb unused=vfio-pci *Active*
+:04:00.1 'I350 1-GbE NIC' if=eth1 drv=igb unused=vfio-pci
+:04:00.2 'I350 1-GbE NIC' if=eth2 drv=igb unused=vfio-pci
+:04:00.3 'I350 1-GbE NIC' if=eth3 drv=igb unused=vfio-pci

 Other network devices
 =
 

-To bind device ``eth1``,``04:00.1``, to the ``uio_pci_generic`` driver:
+To bind device ``eth1``,``04:00.1``, to the ``vfio-pci`` driver:

 .. code-block:: console

-./usertools/dpdk-devbind.py --bind=uio_pci_generic 04:00.1
+./usertools/dpdk-devbind.py --bind=vfio-pci 04:00.1

 or, alternatively,

 .. code-block:: console

-./usertools/dpdk-devbind.py --bind=uio_pci_generic eth1
+./usertools/dpdk-devbind.py --bind=vfio-pci eth1

-To restore device ``82:00.0`` to its original kernel binding:
+When specifying device ids, wildcards can be used for the final part of the 
address.
+To restore device ``82:00.0`` and ``82:00.1`` to their original kernel binding:

 .. code-block:: console

-./usertools/dpdk-devbind.py --bind=ixgbe 82:00.0
+./usertools/dpdk-devbind.py --bind=ixgbe 82:00.*

 VFIO
 
@@ -210,6 +215,8 @@ to use IO virtualization (such as Intel\ |reg| VT-d).
 For proper operation of VFIO when running DPDK applications as a 
non-privileged user, correct permissions should also be set up.
 For more information, please refer to :ref:`Running_Without_Root_Privileges`.

+.. _vfio_noiommu:
+
 VFIO no-IOMMU mode
 --

@@ -240,6 +247,8 @@ After that, VFIO can be used with hardware devices as usual.
to keep the degree of device access and programming that VFIO has,
in situations where IOMMU is not available.

+.. _uio:
+
 UIO
 ---

--
2.32.0

[PATCH v2 6/9] doc: split GSG VFIO section into subsections

[Bruce Richardson]

The VFIO section of the page about linux drivers was rather long and
unstructured. This can be improved by splitting it up into subsections,
to cover the specifics of memory limits and creating VFs. When moving
the various text notes into the relevant subsections, we can drop the
note about kernels earlier than 3.6, since DPDK no longer supports
kernels that old.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 35 ++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index bd649db929..f9c24e9456 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -122,6 +122,22 @@ To make use of VFIO, the ``vfio-pci`` module must be 
loaded:
 VFIO kernel is usually present by default in all distributions,
 however please consult your distributions documentation to make sure that is 
the case.

+To make use of full VFIO functionality,
+both kernel and BIOS must support and be configured
+to use IO virtualization (such as Intel\ |reg| VT-d).
+
+.. note::
+
+   In most cases, specifying "iommu=on" as kernel parameter should be enough to
+   configure the Linux kernel to use IOMMU.
+
+For proper operation of VFIO when running DPDK applications as a 
non-privileged user, correct permissions should also be set up.
+For more information, please refer to :ref:`Running_Without_Root_Privileges`.
+
+
+VFIO Memory Mapping Limits
+~~~
+
 For DMA mapping of either external memory or hugepages, VFIO interface is used.
 VFIO does not support partial unmap of once mapped memory. Hence DPDK's memory 
is
 mapped in hugepage granularity or system page granularity. Number of DMA
@@ -132,6 +148,9 @@ VFIO module parameter ``dma_entry_limit`` with a default 
value of 64K.
 When application is out of DMA entries, these limits need to be adjusted to
 increase the allowed limit.

+Creating Virtual Functions using vfio-pci
+~~
+
 Since Linux version 5.7,
 the ``vfio-pci`` module supports the creation of virtual functions.
 After the PF is bound to ``vfio-pci`` module,
@@ -194,27 +213,11 @@ The token will be used for all PF and VF ports within the 
application.
   /app/dpdk-testpmd -l 26-29 -n 4 -a 86:02.0 \
   --vfio-vf-token=14d63f20-8445-11ea-8900-1f9ce7d5650d --file-prefix=vf0 
-- -i

-To make use of full VFIO functionality,
-both kernel and BIOS must support and be configured
-to use IO virtualization (such as Intel\ |reg| VT-d).
-
-.. note::
-
-   Linux versions earlier than version 3.6 do not support VFIO.
-
 .. note::

Linux versions earlier than version 5.7 do not support the creation of
virtual functions within the VFIO framework.

-.. note::
-
-   In most cases, specifying "iommu=on" as kernel parameter should be enough to
-   configure the Linux kernel to use IOMMU.
-
-For proper operation of VFIO when running DPDK applications as a 
non-privileged user, correct permissions should also be set up.
-For more information, please refer to :ref:`Running_Without_Root_Privileges`.
-
 .. _vfio_noiommu:

 VFIO no-IOMMU mode
--
2.32.0

[PATCH v2 8/9] doc: consolidate all VFIO content on GSG driver page

[Bruce Richardson]

Rather than having separate sections for VFIO and VFIO no-iommu mode, as
well as a separate section further down the document on troubleshooting
VFIO, we can consolidate all these as subsections into a primary VFIO
section. This section starts with the basics of VFIO use, then covers
no-iommu mode, before moving on to the more advanced topics such as
creating VFs and ending with the troubleshooting subsection.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 116 -
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index 6ff8586940..8320db44d9 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -135,6 +135,38 @@ For proper operation of VFIO when running DPDK 
applications as a non-privileged
 For more information, please refer to :ref:`Running_Without_Root_Privileges`.


+.. _vfio_noiommu:
+
+VFIO no-IOMMU mode
+~~
+
+If there is no IOMMU available on the system, VFIO can still be used,
+but it has to be loaded with an additional module parameter:
+
+.. code-block:: console
+
+   modprobe vfio enable_unsafe_noiommu_mode=1
+
+Alternatively, one can also enable this option in an already loaded kernel 
module:
+
+.. code-block:: console
+
+   echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
+
+After that, VFIO can be used with hardware devices as usual.
+
+.. note::
+
+   It may be required to unload all VFIO related-modules before probing
+   the module again with ``enable_unsafe_noiommu_mode=1`` parameter.
+
+.. warning::
+
+   Since no-IOMMU mode forgoes IOMMU protection, it is inherently unsafe.
+   That said, it does make it possible for the user
+   to keep the degree of device access and programming that VFIO has,
+   in situations where IOMMU is not available.
+
 VFIO Memory Mapping Limits
 ~~~

@@ -218,65 +250,8 @@ The token will be used for all PF and VF ports within the 
application.
Linux versions earlier than version 5.7 do not support the creation of
virtual functions within the VFIO framework.

-.. _vfio_noiommu:
-
-VFIO no-IOMMU mode
---
-
-If there is no IOMMU available on the system, VFIO can still be used,
-but it has to be loaded with an additional module parameter:
-
-.. code-block:: console
-
-   modprobe vfio enable_unsafe_noiommu_mode=1
-
-Alternatively, one can also enable this option in an already loaded kernel 
module:
-
-.. code-block:: console
-
-   echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
-
-After that, VFIO can be used with hardware devices as usual.
-
-.. note::
-
-   It may be required to unload all VFIO related-modules before probing
-   the module again with ``enable_unsafe_noiommu_mode=1`` parameter.
-
-.. warning::
-
-   Since no-IOMMU mode forgoes IOMMU protection, it is inherently unsafe.
-   That said, it does make it possible for the user
-   to keep the degree of device access and programming that VFIO has,
-   in situations where IOMMU is not available.
-
-.. _bifurcated_driver:
-
-Bifurcated Driver
--
-
-PMDs which use the bifurcated driver co-exists with the device kernel driver.
-On such model the NIC is controlled by the kernel, while the data
-path is performed by the PMD directly on top of the device.
-
-Such model has the following benefits:
-
- - It is secure and robust, as the memory management and isolation
-   is done by the kernel.
- - It enables the user to use legacy linux tools such as ``ethtool`` or
-   ``ifconfig`` while running DPDK application on the same network ports.
- - It enables the DPDK application to filter only part of the traffic,
-   while the rest will be directed and handled by the kernel driver.
-   The flow bifurcation is performed by the NIC hardware.
-   As an example, using :ref:`flow_isolated_mode` allows to choose
-   strictly what is received in DPDK.
-
-More about the bifurcated driver can be found in
-`Mellanox Bifurcated DPDK PMD
-`__.
-
 Troubleshooting VFIO
-
+

 In certain situations, using ``dpdk-devbind.py`` script
 to bind a device to VFIO driver may fail.
@@ -321,6 +296,31 @@ If ``CONFIG_VFIO_NOIOMMU`` is not enabled in the kernel 
configuration,
 VFIO driver will not support the no-IOMMU mode,
 and other alternatives (such as UIO drivers) will have to be used.

+.. _bifurcated_driver:
+
+Bifurcated Driver
+-
+
+PMDs which use the bifurcated driver co-exists with the device kernel driver.
+On such model the NIC is controlled by the kernel, while the data
+path is performed by the PMD directly on top of the device.
+
+Such model has the following benefits:
+
+ - It is secure and robust, as the memory management and isolation
+   is d

[PATCH v2 7/9] doc: move GSG section on UIO to the end of drivers page

[Bruce Richardson]

To further de-emphasise UIO over the alternatives, we can move the UIO
section of the drivers page to the end of the document, giving more
prominence to VFIO and bifurcated drivers.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 104 -
 1 file changed, 52 insertions(+), 52 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index f9c24e9456..6ff8586940 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -250,58 +250,6 @@ After that, VFIO can be used with hardware devices as 
usual.
to keep the degree of device access and programming that VFIO has,
in situations where IOMMU is not available.

-.. _uio:
-
-UIO

-
-.. warning::
-
-   Using UIO drivers is inherently unsafe due to this method lacking IOMMU 
protection,
-   and can only be done by root user.
-
-In situations where using VFIO is not an option, there are alternative drivers 
one can use.
-In many cases, the standard ``uio_pci_generic`` module included in the Linux 
kernel
-can be used as a substitute for VFIO. This module can be loaded using the 
command:
-
-.. code-block:: console
-
-   sudo modprobe uio_pci_generic
-
-.. note::
-
-   ``uio_pci_generic`` module doesn't support the creation of virtual 
functions.
-
-As an alternative to the ``uio_pci_generic``, there is the ``igb_uio`` module
-which can be found in the repository `dpdk-kmods 
`_.
-It can be loaded as shown below:
-
-.. code-block:: console
-
-   sudo modprobe uio
-   sudo insmod igb_uio.ko
-
-.. note::
-
-For some devices which lack support for legacy interrupts, e.g. virtual 
function
-(VF) devices, the ``igb_uio`` module may be needed in place of 
``uio_pci_generic``.
-
-.. note::
-
-   If UEFI secure boot is enabled,
-   the Linux kernel may disallow the use of UIO on the system.
-   Therefore, devices for use by DPDK should be bound to the ``vfio-pci`` 
kernel module
-   rather than any UIO-based module.
-   For more details see :ref:`linux_gsg_binding_kernel` below.
-
-.. note::
-
-   If the devices used for DPDK are bound to a UIO-based kernel module,
-   please make sure that the IOMMU is disabled or is in passthrough mode.
-   One can add ``intel_iommu=off`` or ``amd_iommu=off`` or ``intel_iommu=on 
iommu=pt``
-   in GRUB command line on x86_64 systems,
-   or add ``iommu.passthrough=1`` on aarch64 systems.
-
 .. _bifurcated_driver:

 Bifurcated Driver
@@ -372,3 +320,55 @@ This can be checked in the boot configuration of your 
system:
 If ``CONFIG_VFIO_NOIOMMU`` is not enabled in the kernel configuration,
 VFIO driver will not support the no-IOMMU mode,
 and other alternatives (such as UIO drivers) will have to be used.
+
+.. _uio:
+
+UIO
+---
+
+.. warning::
+
+   Using UIO drivers is inherently unsafe due to this method lacking IOMMU 
protection,
+   and can only be done by root user.
+
+In situations where using VFIO is not an option, there are alternative drivers 
one can use.
+In many cases, the standard ``uio_pci_generic`` module included in the Linux 
kernel
+can be used as a substitute for VFIO. This module can be loaded using the 
command:
+
+.. code-block:: console
+
+   sudo modprobe uio_pci_generic
+
+.. note::
+
+   ``uio_pci_generic`` module doesn't support the creation of virtual 
functions.
+
+As an alternative to the ``uio_pci_generic``, there is the ``igb_uio`` module
+which can be found in the repository `dpdk-kmods 
`_.
+It can be loaded as shown below:
+
+.. code-block:: console
+
+   sudo modprobe uio
+   sudo insmod igb_uio.ko
+
+.. note::
+
+For some devices which lack support for legacy interrupts, e.g. virtual 
function
+(VF) devices, the ``igb_uio`` module may be needed in place of 
``uio_pci_generic``.
+
+.. note::
+
+   If UEFI secure boot is enabled,
+   the Linux kernel may disallow the use of UIO on the system.
+   Therefore, devices for use by DPDK should be bound to the ``vfio-pci`` 
kernel module
+   rather than any UIO-based module.
+   For more details see :ref:`linux_gsg_binding_kernel` below.
+
+.. note::
+
+   If the devices used for DPDK are bound to a UIO-based kernel module,
+   please make sure that the IOMMU is disabled or is in passthrough mode.
+   One can add ``intel_iommu=off`` or ``amd_iommu=off`` or ``intel_iommu=on 
iommu=pt``
+   in GRUB command line on x86_64 systems,
+   or add ``iommu.passthrough=1`` on aarch64 systems.
--
2.32.0

[PATCH v2 9/9] doc: change informational warnings to notes in Linux GSG

[Bruce Richardson]

There are two warnings in the VFIO section about limitations of VFIO and
limitations on who can bind/unbind devices. Since these don't actually
describe any unsafe conditions, and are more informational, we can
change these to notes. This also helps emphasise the other warnings in
the documents which flag genuine security concerns.

Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/linux_drivers.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
b/doc/guides/linux_gsg/linux_drivers.rst
index 8320db44d9..2e4c80ebd3 100644
--- a/doc/guides/linux_gsg/linux_drivers.rst
+++ b/doc/guides/linux_gsg/linux_drivers.rst
@@ -48,7 +48,7 @@ by calling the script with the ``--help`` or ``--usage`` 
options.
 Note that the UIO or VFIO kernel modules to be used,
 should be loaded into the kernel before running the ``dpdk-devbind.py`` script.

-.. warning::
+.. note::

Due to the way VFIO works, there are certain limitations
to which devices can be used with VFIO.
@@ -62,7 +62,7 @@ should be loaded into the kernel before running the 
``dpdk-devbind.py`` script.
Therefore, the bridge driver should also be unbound from the bridge PCI 
device
for VFIO to work with devices behind the bridge.

-.. warning::
+.. note::

While any user can run the ``dpdk-devbind.py`` script
to view the status of the network ports,
--
2.32.0

Re: rte_flow API change request: tunnel info restoration is too slow

[Thomas Monjalon]

16/03/2022 13:25, Ilya Maximets:
> On 3/16/22 10:41, Thomas Monjalon wrote:
> > 15/03/2022 23:12, Ilya Maximets:
> >> Hi, everyone.
> >>
> >> After implementing support for tunnel offloading in OVS we faced a
> >> significant performance issue caused by the requirement to call
> >> rte_flow_get_restore_info() function on a per-packet basis.
> >>
> >> The main problem is that once the tunnel offloading is configured,
> >> there is no way for the application to tell if a particular packet
> >> was partially processed in the hardware and the tunnel info has to
> >> be restored.  What we have to do right now is to call the
> >> rte_flow_get_restore_info() unconditionally for every packet.  The
> >> result of that call says if we have the tunnel info or not.
> >>
> >> rte_flow_get_restore_info() call itself is very heavy.  It is at
> >> least a couple of indirect function calls and the device lock
> >> on the application side (not-really-thread-safety of the rte_flow
> >> API is a separate topic).  Internal info lookup inside the driver
> >> also costs a lot (depends on a driver).
> >>
> >> It has been measured that having this call on a per-packet basis can
> >> reduce application performance (OVS) by a factor of 3 in some cases:
> >>   https://mail.openvswitch.org/pipermail/ovs-dev/2021-November/389265.html
> >>   
> >> https://github.com/openvswitch/ovs/commit/6e50c1651869de0335eb4b7fd0960059c5505f5c
> >> (Above patch avoid the problem in a hacky way for devices that doesn't
> >>  support tunnel offloading, but it's not applicable to situation
> >>  where device actually supports it, since the API has to be called.)
> >>
> >> Another tricky part is that we have to call rte_flow_get_restore_info()
> >> before checking other parts of the mbuf, because mlx5 driver, for
> >> example, re-uses the mbuf.hash.fdir value for both tunnel info
> >> restoration and classification offloading, so the application has
> >> no way to tell which one is used right now and has to call the
> >> restoration API first in order to find out.
> >>
> >>
> >> What we need:
> >>
> >> A generic and fast (couple of CPU cycles) API that will clearly say
> >> if the heavy rte_flow_get_restore_info() has to be called for a
> >> particular packet or not.  Ideally, that should be a static mbuf
> >> flag that can be easily checked by the application.
> > 
> > A dynamic mbuf flag, defined in the API, looks to be a good idea.
> 
> Makes sense.  OTOH, I'm not sure what is the profit of having it
> dynamically allocated if it will need to be always defined.

True.
We need to discuss whether we can have situations where it is not registered
at all. We recently introduced a function for initial config of rte_flow,
it could be the trigger to register such flag or field.

> But, well, it doesn't really matter, I guess.

That's a detail but it should be discussed.

> >> Calls inside the device driver are way too slow for that purpose,
> >> especially if they are not fully thread-safe, or require complex
> >> lookups or calculations.
> >>
> >> I'm assuming here that packets that really need the tunnel info
> >> restoration should be fairly rare.
> >>
> >>
> >> Current state:
> >>
> >> Currently, the get_restore_info() API is implemented only for mlx5
> >> and sfc drivers, AFAICT.
> >> SFC driver is already using mbuf flag, but
> >> it's dynamic and not exposed to the application.
> > 
> > What is this flag?
> 
> SFC driver defines a dynamic field 'rte_net_sfc_dynfield_ft_id'
> and the corresponding flag 'rte_net_sfc_dynflag_ft_id_valid' to
> check if the field contains a valid data.

OK, so we could deprecate this flag.

> >> MLX5 driver re-uses mbuf.hash.fdir value
> >> and performs a heavy lookup inside the driver.
> > 
> > We should avoid re-using a field.
> 
> +1 from me, but I'm not familiar with the mlx5 driver enough
> to tell how to change it.
> 
> > 
> >> For now OVS doesn't support tunnel offload with DPDK formally, the
> >> code in OVS is under the experimental API ifdef and not compiled-in
> >> by default.
> >>
> >> //Let me know if there is more formal way to submit such requests.
> > 
> > That's a well written request, thanks.
> > If you are looking for something more formal,
> > it could be a patch in the API.
> 
> I'm not looking for now. :)
> I think we need an agreement from driver maintainers first.  And
> I don't think we can introduce such API change without changing
> drivers first, because otherwise we'll end up with the 'has_vlan'
> situation and the broken offloading support.

OK

RE: rte flow for arp packet

[Yaron Illouz]

In the rte_flow_item_type I don’t see an entry  for arp or ndp
Is there another way to do it ?
For ipv4 I did the following way

pattern[0].type = 
RTE_FLOW_ITEM_TYPE_ETH;

pattern[0].spec = NULL;



pattern[1].type = 
RTE_FLOW_ITEM_TYPE_IPV4;

pattern[1].spec = NULL;

From: Ori Kam 
Sent: Wednesday, March 16, 2022 3:11 PM
To: Yaron Illouz ; dev@dpdk.org
Subject: RE: rte flow for arp packet

EXTERNAL EMAIL: Do not click links or attachments unless you recognize the 
sender and know the content is safe

Hi
You need to create a rule that matches the arp/ndp packets and use the queue 
action.

From: Yaron Illouz mailto:yar...@radcom.com>>
Sent: Wednesday, March 16, 2022 2:42 PM
To: dev@dpdk.org
Cc: Ori Kam mailto:or...@nvidia.com>>
Subject: rte flow for arp packet

Hi

Is there a way using rte_flow to send arp and ndp packet to specific rx queue 
with dpdk

[Bug 960] PCAP PMD receives packets larger then MTU

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=960

Bug ID: 960
   Summary: PCAP PMD receives packets larger then MTU
   Product: DPDK
   Version: 21.11
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: i...@cgstowernetworks.com
  Target Milestone: ---

Created attachment 197
  --> https://bugs.dpdk.org/attachment.cgi?id=197&action=edit
pcap with 1 packet ~9000B

Here is example of MTU (max-pkt-len) set to ~300B but driver receives packet of
~9000B (the jumbo pcap is attached)


root@u18c_9td3:/home/cgs/workspace/master/jumbo# ./dpdk-testpmd --no-huge
-m1024 -l 0-3 -n 4 --vdev
'net_pcap0,rx_pcap=jumbo_9000.pcap,tx_pcap=file_tx.pcap' -- --no-flush-rx
--total-num-mbufs=2048  --max-pkt-len=300 -i
EAL: Detected CPU lcores: 6
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
TELEMETRY: No legacy callbacks, legacy socket not created
Interactive-mode selected
Warning: NUMA should be configured manually by using --port-numa-config and
--ring-numa-config parameters along with --numa.
testpmd: create a new mbuf pool : n=2048, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will
pair with itself.

Configuring Port 0 (socket 0)
Port 0: 02:70:63:61:70:00
Checking link statuses...
Done
testpmd> show port info 0

* Infos for port 0  *
MAC address: 02:70:63:61:70:00
Device name: net_pcap0
Driver name: net_pcap
Firmware-version: not available
Devargs: rx_pcap=jumbo_9000.pcap,tx_pcap=file_tx.pcap
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 10 Gbps
Link duplex: full-duplex
Autoneg status: Off
MTU: 282
Promiscuous mode: enabled
Allmulticast mode: enabled
Maximum number of MAC addresses: 1
Maximum number of MAC addresses of hash filtering: 0
VLAN offload: 
  strip off, filter off, extend off, qinq strip off
No RSS offload flow type is supported.
Minimum size of RX buffer: 0
Maximum configurable length of RX packet: 4294967295
Maximum configurable size of LRO aggregated packet: 0
Current number of RX queues: 1
Max possible RX queues: 1
Max possible number of RXDs per queue: 65535
Min possible number of RXDs per queue: 0
RXDs number alignment: 1
Current number of TX queues: 1
Max possible TX queues: 1
Max possible number of TXDs per queue: 65535
Min possible number of TXDs per queue: 0
TXDs number alignment: 1
Max segment number per packet: 65535
Max segment number per MTU/TSO: 65535
Device capabilities: 0x0( )
testpmd> set  verbose 3
Change verbose level from 0 to 3
testpmd> start
io packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP
allocation mode: native
Logical Core 1 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  io packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
  RX desc=0 - RX free threshold=0
  RX threshold registers: pthresh=0 hthresh=0  wthresh=0
  RX Offloads=0x0
TX queue: 0
  TX desc=0 - TX free threshold=0
  TX threshold registers: pthresh=0 hthresh=0  wthresh=0
  TX offloads=0x0 - TX RS bit threshold=0
testpmd> port 0/queue 0: received 1 packets
  src=04:F4:BC:3E:E4:25 - dst=00:00:00:00:00:00 - type=0x0800 - length=8996 -
nb_segs=5 - timestamp 1266577613728443  - sw ptype: L2_ETHER L3_IPV4  -
l2_len=14 - l3_len=20 - Receive queue=0x0
  ol_flags: RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN
RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN 
port 0/queue 0: sent 1 packets
  src=04:F4:BC:3E:E4:25 - dst=00:00:00:00:00:00 - type=0x0800 - length=8996 -
nb_segs=5 - timestamp 1266577613728443  - sw ptype: L2_ETHER L3_IPV4  -
l2_len=14 - l3_len=20 - Send queue=0x0
  ol_flags: RTE_MBUF_F_TX_L4_NO_CKSUM 

testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  -- Forward statistics for port 0  --
  RX-packets: 1  RX-dropped: 0 RX-total: 1
  TX-packets: 1  TX-dropped: 0 TX-total: 1
  

  +++ Accumulated forward statistics for all ports+++
  RX-packets: 1  RX-dropped: 0 RX-total: 1
  TX-packets: 1  TX-dropped: 0 TX-total: 1
  

Done.
testpmd> show port stats 0

   NIC statistics for port 0  
  RX-packets: 1  

[Bug 961] PCAP PMD receives packets larger then MTU

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=961

Bug ID: 961
   Summary: PCAP PMD receives packets larger then MTU
   Product: DPDK
   Version: 21.11
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: i...@cgstowernetworks.com
  Target Milestone: ---

Here is example of MTU (max-pkt-len) set to ~300B but driver receives packet of
~9000B (the jumbo pcap is attached)


root@u18c_9td3:/home/cgs/workspace/master/jumbo# ./dpdk-testpmd --no-huge
-m1024 -l 0-3 -n 4 --vdev
'net_pcap0,rx_pcap=jumbo_9000.pcap,tx_pcap=file_tx.pcap' -- --no-flush-rx
--total-num-mbufs=2048  --max-pkt-len=300 -i
EAL: Detected CPU lcores: 6
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
TELEMETRY: No legacy callbacks, legacy socket not created
Interactive-mode selected
Warning: NUMA should be configured manually by using --port-numa-config and
--ring-numa-config parameters along with --numa.
testpmd: create a new mbuf pool : n=2048, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port will
pair with itself.

Configuring Port 0 (socket 0)
Port 0: 02:70:63:61:70:00
Checking link statuses...
Done
testpmd> show port info 0

* Infos for port 0  *
MAC address: 02:70:63:61:70:00
Device name: net_pcap0
Driver name: net_pcap
Firmware-version: not available
Devargs: rx_pcap=jumbo_9000.pcap,tx_pcap=file_tx.pcap
Connect to socket: 0
memory allocation on the socket: 0
Link status: up
Link speed: 10 Gbps
Link duplex: full-duplex
Autoneg status: Off
MTU: 282
Promiscuous mode: enabled
Allmulticast mode: enabled
Maximum number of MAC addresses: 1
Maximum number of MAC addresses of hash filtering: 0
VLAN offload: 
  strip off, filter off, extend off, qinq strip off
No RSS offload flow type is supported.
Minimum size of RX buffer: 0
Maximum configurable length of RX packet: 4294967295
Maximum configurable size of LRO aggregated packet: 0
Current number of RX queues: 1
Max possible RX queues: 1
Max possible number of RXDs per queue: 65535
Min possible number of RXDs per queue: 0
RXDs number alignment: 1
Current number of TX queues: 1
Max possible TX queues: 1
Max possible number of TXDs per queue: 65535
Min possible number of TXDs per queue: 0
TXDs number alignment: 1
Max segment number per packet: 65535
Max segment number per MTU/TSO: 65535
Device capabilities: 0x0( )
testpmd> set  verbose 3
Change verbose level from 0 to 3
testpmd> start
io packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP
allocation mode: native
Logical Core 1 (socket 0) forwards packets on 1 streams:
  RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00

  io packet forwarding packets/burst=32
  nb forwarding cores=1 - nb forwarding ports=1
  port 0: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
  RX desc=0 - RX free threshold=0
  RX threshold registers: pthresh=0 hthresh=0  wthresh=0
  RX Offloads=0x0
TX queue: 0
  TX desc=0 - TX free threshold=0
  TX threshold registers: pthresh=0 hthresh=0  wthresh=0
  TX offloads=0x0 - TX RS bit threshold=0
testpmd> port 0/queue 0: received 1 packets
  src=04:F4:BC:3E:E4:25 - dst=00:00:00:00:00:00 - type=0x0800 - length=8996 -
nb_segs=5 - timestamp 1266577613728443  - sw ptype: L2_ETHER L3_IPV4  -
l2_len=14 - l3_len=20 - Receive queue=0x0
  ol_flags: RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN
RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN 
port 0/queue 0: sent 1 packets
  src=04:F4:BC:3E:E4:25 - dst=00:00:00:00:00:00 - type=0x0800 - length=8996 -
nb_segs=5 - timestamp 1266577613728443  - sw ptype: L2_ETHER L3_IPV4  -
l2_len=14 - l3_len=20 - Send queue=0x0
  ol_flags: RTE_MBUF_F_TX_L4_NO_CKSUM 

testpmd> stop
Telling cores to stop...
Waiting for lcores to finish...

  -- Forward statistics for port 0  --
  RX-packets: 1  RX-dropped: 0 RX-total: 1
  TX-packets: 1  TX-dropped: 0 TX-total: 1
  

  +++ Accumulated forward statistics for all ports+++
  RX-packets: 1  RX-dropped: 0 RX-total: 1
  TX-packets: 1  TX-dropped: 0 TX-total: 1
  

Done.
testpmd> show port stats 0

   NIC statistics for port 0  
  RX-packets: 1  RX-missed: 0  RX-bytes:  8996
  RX-errors: 0
  RX-nombuf:  0 
  TX-packets: 1  T

RE: rte_flow API change request: tunnel info restoration is too slow

[Ori Kam]

Hi

> -Original Message-
> From: Thomas Monjalon 
> Sent: Wednesday, March 16, 2022 3:47 PM
> Subject: Re: rte_flow API change request: tunnel info restoration is too slow
> 
> 16/03/2022 13:25, Ilya Maximets:
> > On 3/16/22 10:41, Thomas Monjalon wrote:
> > > 15/03/2022 23:12, Ilya Maximets:
> > >> Hi, everyone.
> > >>
> > >> After implementing support for tunnel offloading in OVS we faced a
> > >> significant performance issue caused by the requirement to call
> > >> rte_flow_get_restore_info() function on a per-packet basis.
> > >>
> > >> The main problem is that once the tunnel offloading is configured,
> > >> there is no way for the application to tell if a particular packet
> > >> was partially processed in the hardware and the tunnel info has to
> > >> be restored.  What we have to do right now is to call the
> > >> rte_flow_get_restore_info() unconditionally for every packet.  The
> > >> result of that call says if we have the tunnel info or not.
> > >>
> > >> rte_flow_get_restore_info() call itself is very heavy.  It is at
> > >> least a couple of indirect function calls and the device lock
> > >> on the application side (not-really-thread-safety of the rte_flow
> > >> API is a separate topic).  Internal info lookup inside the driver
> > >> also costs a lot (depends on a driver).
> > >>
> > >> It has been measured that having this call on a per-packet basis can
> > >> reduce application performance (OVS) by a factor of 3 in some cases:
> > >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpip
> ermail%2Fovs-dev%2F2021-
> November%2F389265.html&data=04%7C01%7Corika%40nvidia.com%7C16130914f2354dc02cbe08
> da075369f1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63783035249472%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000&sdata=ZciqL%2FK8xhJLhVFJjn%2B6euRk7nt9HVA3Ych4Kqv0%2BY4%3D&reserved=0
> > >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenvswitch
> %2Fovs%2Fcommit%2F6e50c1651869de0335eb4b7fd0960059c5505f5c&data=04%7C01%7Corika%
> 40nvidia.com%7C16130914f2354dc02cbe08da075369f1%7C43083d15727340c1b7db39efd9ccc17a%7C0%
> 7C0%7C63783035249472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5cb6n8PqNIgE49013%2B83%2Buy8shi8x
> YHPoX%2BrHoyt8ig%3D&reserved=0
> > >> (Above patch avoid the problem in a hacky way for devices that doesn't
> > >>  support tunnel offloading, but it's not applicable to situation
> > >>  where device actually supports it, since the API has to be called.)
> > >>
> > >> Another tricky part is that we have to call rte_flow_get_restore_info()
> > >> before checking other parts of the mbuf, because mlx5 driver, for
> > >> example, re-uses the mbuf.hash.fdir value for both tunnel info
> > >> restoration and classification offloading, so the application has
> > >> no way to tell which one is used right now and has to call the
> > >> restoration API first in order to find out.
> > >>
> > >>
> > >> What we need:
> > >>
> > >> A generic and fast (couple of CPU cycles) API that will clearly say
> > >> if the heavy rte_flow_get_restore_info() has to be called for a
> > >> particular packet or not.  Ideally, that should be a static mbuf
> > >> flag that can be easily checked by the application.
> > >
> > > A dynamic mbuf flag, defined in the API, looks to be a good idea.
> >
> > Makes sense.  OTOH, I'm not sure what is the profit of having it
> > dynamically allocated if it will need to be always defined.
> 
> True.
> We need to discuss whether we can have situations where it is not registered
> at all. We recently introduced a function for initial config of rte_flow,
> it could be the trigger to register such flag or field.
> 

Why would it always be defined?
As I can see it this flag is only used if application is planning to use the 
tunnel.
We should also introduce some way to let application know if PMD is taking over
the fdir or metadata.

> > But, well, it doesn't really matter, I guess.
> 
> That's a detail but it should be discussed.
> 
> > >> Calls inside the device driver are way too slow for that purpose,
> > >> especially if they are not fully thread-safe, or require complex
> > >> lookups or calculations.
> > >>
> > >> I'm assuming here that packets that really need the tunnel info
> > >> restoration should be fairly rare.
> > >>
> > >>
> > >> Current state:
> > >>
> > >> Currently, the get_restore_info() API is implemented only for mlx5
> > >> and sfc drivers, AFAICT.
> > >> SFC driver is already using mbuf flag, but
> > >> it's dynamic and not exposed to the application.
> > >
> > > What is this flag?
> >
> > SFC driver defines a dynamic field 'rte_net_sfc_dynfield_ft_id'
> > and the corresponding flag 'rte_net_sfc_dynflag_ft_id_valid' to
> > check if the field contains a valid data.
> 
> OK, so we could deprecate this flag.
> 
> > >> MLX5 driver re-uses mbuf.hash

RE: release candidate 22.03-rc4

[Wael Abualrub]

Hi,

> -Original Message-
> From: Thomas Monjalon 
> Sent: Tuesday, March 15, 2022 3:21 AM
> To: annou...@dpdk.org
> Subject: release candidate 22.03-rc4
> 
> A new DPDK release candidate is ready for testing:
>   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F
> %2Fgit.dpdk.org%2Fdpdk%2Ftag%2F%3Fid%3Dv22.03-
> rc4&data=04%7C01%7Cwaela%40nvidia.com%7C6ab719ece5fc4e91c52b
> 08da065c%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637829
> 040918501360%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FcEZ
> XDQGUzvVCa%2B6N1CB3HOKMATrj7gwuomYodwgebg%3D&reserved=
> 0
> 
> There are 31 new patches in this snapshot.
> 
> Release notes:
>   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F
> %2Fdoc.dpdk.org%2Fguides%2Frel_notes%2Frelease_22_03.html&data
> =04%7C01%7Cwaela%40nvidia.com%7C6ab719ece5fc4e91c52b08da065c
> %7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637829040918501360
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fBkNQMCqVpD2VY
> 5HmUN0jE3wmWxgtGV77lZba1qLAvs%3D&reserved=0
> 
> This is the last release candidate.
> Only documentation should be updated before the release.
> 
> You may share some release validation results by replying to this message at
> dev@dpdk.org and by adding tested hardware in the release notes.
> 
> Please think about sharing your roadmap now for DPDK 22.07.
> 
> Thank you everyone
> 

The following is a list of tests that we ran on NVIDIA hardware this release:

- Basic functionality:
   Send and receive multiple types of traffic.
- testpmd xstats counter test.
- testpmd timestamp test.
- Changing/checking link status through testpmd.
- RTE flow tests:
  Items:
  - conntrack
  - ecpri
  - eth
  - flex
  - geneve
  - geneve_opt
  - gre
  - gre_key
  - gre_option
  - gtp
  - gtp_psc
  - icmp
  - icmp6
  - integrity
  - ipv4
  - ipv6
  - ipv6_frag_ext
  - mark
  - meta
  - mpls
  - nvgre
  - phy_port
  - port_id
  - tag
  - tcp
  - udp
  - vlan
  - vxlan
  - vxlan_gpe

  Actions:
  - age
  - conntrack
  - count
  - dec_tcp_ack
  - dec_tcp_seq
  - dec_ttl
  - drop
  - flag
  - inc_tcp_ack
  - inc_tcp_seq
  - jump
  - mark
  - meter
  - modify_field
  - nvgre_decap
  - nvgre_encap
  - of_pop_vlan
  - of_push_vlan
  - of_set_vlan_pcp
  - of_set_vlan_vid
  - port_id
  - queue
  - raw_decap
  - raw_encap
  - represented_port
  - rss
  - sample
  - set_ipv4_dscp
  - set_ipv4_dst
  - set_ipv4_src
  - set_ipv6_dscp
  - set_ipv6_dst
  - set_ipv6_src
  - set_mac_dst
  - set_mac_src
  - set_meta
  - set_tag
  - set_tp_dst
  - set_tp_src
  - set_ttl
  - vxlan_decap
  - vxlan_encap
- Some RSS tests.
- VLAN filtering, stripping and insertion tests.
- Checksum and TSO tests.
- ptype tests.
- link_status_interrupt example application tests.
- l3fwd-power example application tests.
- Multi-process example applications tests.
- Hardware LRO tests.
- Regex application tests.
- Buffer Split tests.
- Tx scheduling tests.

- One known issue: https://bugs.dpdk.org/show_bug.cgi?id=938 [TAP] testpmd 
crashed after stopping ports

Thanks,
Wael Abualrub

[PATCH 22.07] doc: make doc roadmap common for Linux/BSD GSGs

[Bruce Richardson]

Both the Linux and FreeBSD GSG docs had a "Documentation Roadmap"
section as part of the introduction page, and this contained the same
information, with only the reference to the GSGs themselves being
different. This text can be consolidated into a single text file which
is included by both GSG intro sections - using relative links for the
self reference.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/intro.rst | 56 +-
 doc/guides/linux_gsg/doc_roadmap_inc.rst | 61 
 doc/guides/linux_gsg/intro.rst   | 48 +--
 3 files changed, 63 insertions(+), 102 deletions(-)
 create mode 100644 doc/guides/linux_gsg/doc_roadmap_inc.rst

diff --git a/doc/guides/freebsd_gsg/intro.rst b/doc/guides/freebsd_gsg/intro.rst
index 596d84c8f1..6cdfea4b87 100644
--- a/doc/guides/freebsd_gsg/intro.rst
+++ b/doc/guides/freebsd_gsg/intro.rst
@@ -23,58 +23,4 @@ handbook is available from the FreeBSD Documentation Project:
 Documentation Roadmap
 -
 
-The following is a list of DPDK documents in the suggested reading order:
-
-*   :doc:`../rel_notes/index`: Provides release-specific information, 
including supported
-features, limitations, fixed issues, known issues and so on.  Also, 
provides the
-answers to frequently asked questions in FAQ format.
-
-*   :doc:`../freebsd_gsg/index` (this document): Describes how to install and
-configure the DPDK; designed to get users up and running quickly with the
-software.
-
-*   :doc:`../prog_guide/index`: Describes:
-
-*   The software architecture and how to use it (through examples),
-specifically in a Linux* application (linux) environment
-
-*   The content of the DPDK, the build system (including the commands
-that can be used to build the development kit and an application)
-and guidelines for porting an application
-
-*   Optimizations used in the software and those that should be considered
-for new development
-
-A glossary of terms is also provided.
-
-*   `API Reference <../../../api/html/index.html>`_: Provides detailed 
information about DPDK functions,
-data structures and other programming constructs.
-
-*   :doc:`../sample_app_ug/index`: Describes a set of sample applications.
-Each chapter describes a sample application that showcases specific 
functionality
-and provides instructions on how to compile, run and use the sample 
application.
-
-*   **Driver Reference Guides**: Provides details on each driver inside a 
particular category.
-Separate guides exist for each of:
-
-* :doc:`../bbdevs/index`
-
-* :doc:`../compressdevs/index`
-
-* :doc:`../cryptodevs/index`
-
-* :doc:`../dmadevs/index`
-
-* :doc:`../eventdevs/index`
-
-* :doc:`../gpus/index`
-
-* :doc:`../mempool/index`
-
-* :doc:`../nics/index`
-
-* :doc:`../rawdevs/index`
-
-* :doc:`../regexdevs/index`
-
-* :doc:`../vdpadevs/index`
+.. include:: ../linux_gsg/doc_roadmap_inc.rst
diff --git a/doc/guides/linux_gsg/doc_roadmap_inc.rst 
b/doc/guides/linux_gsg/doc_roadmap_inc.rst
new file mode 100644
index 00..6686975f7b
--- /dev/null
+++ b/doc/guides/linux_gsg/doc_roadmap_inc.rst
@@ -0,0 +1,61 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2010-2022 Intel Corporation.
+
+..
+   NOTE: this file is common between BSD and Linux, so should be kept general
+
+The following is a list of DPDK documents in the suggested reading order:
+
+*   :doc:`../rel_notes/index`: Provides release-specific information, 
including supported
+features, limitations, fixed issues, known issues and so on.  Also, 
provides the
+answers to frequently asked questions in FAQ format.
+
+*   :doc:`./index` (this document): Describes how to install and
+configure the DPDK; designed to get users up and running quickly with the
+software.
+
+*   :doc:`../prog_guide/index`: Describes:
+
+*   The software architecture and how to use it (through examples),
+specifically in a Linux* application (linux) environment
+
+*   The content of the DPDK, the build system (including the commands
+that can be used to build the development kit and an application)
+and guidelines for porting an application
+
+*   Optimizations used in the software and those that should be considered
+for new development
+
+A glossary of terms is also provided.
+
+*   `API Reference <../../../api/html/index.html>`_: Provides detailed 
information about DPDK functions,
+data structures and other programming constructs.
+
+*   :doc:`../sample_app_ug/index`: Describes a set of sample applications.
+Each chapter describes a sample application that showcases specific 
functionality
+and provides instructions on how to compile, run and use the sample 
application.
+
+*   **Driver Reference Guides**: Provides details on each driver inside a 
particular category.
+S

[PATCH v1] doc: update release notes for 22.03

[John McNamara]

Fix grammar, spelling and formatting of DPDK 22.03 release notes.

Signed-off-by: John McNamara 
---

Note: I haven't removed the boilerplate RST comments from
  this file/patch in order to make it easier to merge
  apply. If you want me to do that I can submit a v2.
 


 doc/guides/rel_notes/release_22_03.rst | 108 +
 1 file changed, 56 insertions(+), 52 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_03.rst 
b/doc/guides/rel_notes/release_22_03.rst
index d231e3e8a4..27067dd5c0 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -57,45 +57,47 @@ New Features
 
 * **Added ability to reuse hugepages in Linux.**
 
-  It is possible to reuse files in hugetlbfs to speed up hugepage mapping,
+  It is now possible to reuse files in hugetlbfs to speed up hugepage mapping,
   which may be useful for fast restart and large allocations.
   The new mode is activated with ``--huge-unlink=never``
   and has security implications, refer to the user and programmer guides.
 
 * **Added functions to calculate UDP/TCP checksum in mbuf.**
 
-  * Added the following functions to calculate UDP/TCP checksum of packets
-which can be over multi-segments:
-- ``rte_ipv4_udptcp_cksum_mbuf()``
-- ``rte_ipv4_udptcp_cksum_mbuf_verify()``
-- ``rte_ipv6_udptcp_cksum_mbuf()``
-- ``rte_ipv6_udptcp_cksum_mbuf_verify()``
+  Added the following functions to calculate UDP/TCP checksum of packets
+  which can be over multi-segments:
 
-* **Added functions to configure flow engine.**
+  - ``rte_ipv4_udptcp_cksum_mbuf()``
+  - ``rte_ipv4_udptcp_cksum_mbuf_verify()``
+  - ``rte_ipv6_udptcp_cksum_mbuf()``
+  - ``rte_ipv6_udptcp_cksum_mbuf_verify()``
 
-  * Added ``rte_flow_configure`` API to configure flow management
-engine, allowing to pre-allocate some resources for better performance.
-Added ``rte_flow_info_get`` API to retrieve available resources.
+* **Added functions to configure the flow engine.**
 
-  * Added ``rte_flow_template_table_create`` API to group flow rules
-with the same flow attributes and common matching patterns and actions
-defined by ``rte_flow_pattern_template_create`` and
-``rte_flow_actions_template_create`` respectively.
-Corresponding functions to destroy these entities are:
-``rte_flow_template_table_destroy``, ``rte_flow_pattern_template_destroy``
-and ``rte_flow_actions_template_destroy``.
+  Added the ``rte_flow_configure`` API to configure the flow management
+  engine, allowing preallocation of some resources for better performance.
+  Added ``rte_flow_info_get`` API to retrieve available resources.
 
-* **Added functions for asynchronous flow rules creation/destruction.**
+  Added ``rte_flow_template_table_create`` API to group flow rules
+  with the same flow attributes and common matching patterns and actions
+  defined by ``rte_flow_pattern_template_create`` and
+  ``rte_flow_actions_template_create`` respectively.
+  The corresponding functions to destroy these entities are:
+  ``rte_flow_template_table_destroy``, ``rte_flow_pattern_template_destroy``
+  and ``rte_flow_actions_template_destroy``.
 
-  * Added ``rte_flow_async_create`` and ``rte_flow_async_destroy`` API
-to enqueue flow creaion/destruction operations asynchronously as well as
-``rte_flow_pull`` to poll and retrieve results of these operations and
-``rte_flow_push`` to push all the in-flightoperations to the NIC.
+* **Added functions for asynchronous flow rules creation and destruction.**
 
-  * Added asynchronous API for indirect actions management:
-``rte_flow_async_action_handle_create``,
-``rte_flow_async_action_handle_destroy`` and
-``rte_flow_async_action_handle_update``.
+  Added the ``rte_flow_async_create`` and ``rte_flow_async_destroy`` APIs
+  to enqueue flow creation/destruction operations asynchronously as well as
+  ``rte_flow_pull`` to poll and retrieve results of these operations and
+  ``rte_flow_push`` to push all the in-flight  operations to the NIC.
+
+  Added asynchronous APIs for indirect actions management:
+
+  - ``rte_flow_async_action_handle_create``
+  - ``rte_flow_async_action_handle_destroy``
+  - ``rte_flow_async_action_handle_update``
 
 * **Added rte_flow support for matching GRE optional fields.**
 
@@ -104,35 +106,35 @@ New Features
 
 * **Added new RSS offload types for L2TPv2 in RSS flow.**
 
-  Added macro RTE_ETH_RSS_L2TPV2, now L2TPv2 session ID field can be used as
+  Added ``RTE_ETH_RSS_L2TPV2`` macro so that he L2TPv2 session ID field can be 
used as
   input set for RSS.
 
-* **Added IP reassembly Ethernet offload API, to get and set config.**
+* **Added IP reassembly Ethernet offload APIs to get and set config.**
 
   Added IP reassembly offload APIs which provide functions to query IP
   reassembly capabilities, to set configuration and to get currently set
   reassembly configuration.
 
-* **Added an API to enable queue based 

Re: [PATCH v2 0/9] Improve Linux drivers GSG section

[Thomas Monjalon]

16/03/2022 14:45, Bruce Richardson:
> This patchset reworks large parts of the linux drivers section of the
> Linux Getting Started Guide, so as to make it clearer and easier to
> read. The overall flow of the page is adjusted so that more important
> information is nearer the top, and so that all information on VFIO is
> consolidated into a single section. In terms of the content of the
> sections, there are some minor changes to adjust what is a warning vs
> just a "note" in the doc, and there are some updates to increase
> emphasis on VFIO ovs UIO.
> 
> Including stable on CC for the set, as all patches may be candidates for
> backport to help improve docs for older releases too.
> 
> V2:
> * Rebased on top of main, now that other doc patches are applied
> * Reworded commit titles to use "doc:" prefix
> 
> Bruce Richardson (9):
>   doc: replace special characters for (R) symbol in Linux GSG
>   doc: fix missing note on UIO module in Linux GSG
>   doc: make UIO safety warning more visible in Linux GSG
>   doc: move section on binding drivers up the page in GSG
>   doc: emphasise VFIO over UIO-based modules in GSG
>   doc: split GSG VFIO section into subsections
>   doc: move GSG section on UIO to the end of drivers page
>   doc: consolidate all VFIO content on GSG driver page
>   doc: change informational warnings to notes in Linux GSG

Except for the first 2 patches, I think it is not mandatory to backport,
so I've removed the tag Cc:stable.

Applied, thanks.

Re: [PATCH 0/4] Update doc lists in GSG intros

[Thomas Monjalon]

15/03/2022 23:05, Bruce Richardson:
> This set updates the documentation roadmap section at the start of the
> Linux and FreeBSD GSG docs.  Changes made:
> 
> * Change doc titles to hyperlinks to each doc
> * Add the drivers reference guides to the lists
> 
> Bruce Richardson (4):
>   doc: add hyperlinks to other docs from FreeBSD GSG
>   doc: add driver guides to document list in FreeBSD GSG
>   doc: add hyperlinks to other docs from Linux GSG
>   doc: add driver guides to document list in Linux GSG

Applied, thanks.

[PATCH] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Jeff Daly]

Some SFP link partners exhibit a disinclination to autonegotiate
with X550 configured in SFI mode.  This patch enables a manual AN-37
restart to work around the problem.

Signed-off-by: Jeff Daly 
---
 drivers/net/ixgbe/base/ixgbe_type.h |  1 +
 drivers/net/ixgbe/base/ixgbe_x550.c | 51 +
 2 files changed, 52 insertions(+)

diff --git a/drivers/net/ixgbe/base/ixgbe_type.h 
b/drivers/net/ixgbe/base/ixgbe_type.h
index b7eec45635..9278b1e64c 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -4260,6 +4260,7 @@ struct ixgbe_hw {
 #define IXGBE_KRM_PMD_FLX_MASK_ST20(P) ((P) ? 0x9054 : 0x5054)
 #define IXGBE_KRM_TX_COEFF_CTRL_1(P)   ((P) ? 0x9520 : 0x5520)
 #define IXGBE_KRM_RX_ANA_CTL(P)((P) ? 0x9A00 : 0x5A00)
+#define IXGBE_KRM_FLX_TMRS_CTRL_ST31(P)((P) ? 0x9180 : 0x5180)
 
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_DA ~(0x3 << 20)
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_SR (1u << 20)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c 
b/drivers/net/ixgbe/base/ixgbe_x550.c
index 8810d1658e..649d834715 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2676,6 +2676,57 @@ STATIC s32 ixgbe_setup_sfi_x550a(struct ixgbe_hw *hw, 
ixgbe_link_speed *speed)
IXGBE_KRM_PMD_FLX_MASK_ST20(hw->bus.lan_id),
IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
 
+   /* change mode enforcement rules to hybrid */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x0400;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+   
+   /* manually control the config */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x20002240;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* move the AN base page values */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x1;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* set the AN37 over CB mode */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x2000;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* restart AN manually */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+
/* Toggle port SW reset by AN reset. */
status = ixgbe_restart_an_internal_phy_x550em(hw);
 
-- 
2.25.1

[PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Jeff Daly]

Some SFP link partners exhibit a disinclination to autonegotiate
with X550 configured in SFI mode.  This patch enables a manual AN-37
restart to work around the problem.

--
v2 fixed whitespace

Signed-off-by: Jeff Daly 
---
 drivers/net/ixgbe/base/ixgbe_type.h |  1 +
 drivers/net/ixgbe/base/ixgbe_x550.c | 50 +
 2 files changed, 51 insertions(+)

diff --git a/drivers/net/ixgbe/base/ixgbe_type.h 
b/drivers/net/ixgbe/base/ixgbe_type.h
index b7eec45635..9278b1e64c 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -4260,6 +4260,7 @@ struct ixgbe_hw {
 #define IXGBE_KRM_PMD_FLX_MASK_ST20(P) ((P) ? 0x9054 : 0x5054)
 #define IXGBE_KRM_TX_COEFF_CTRL_1(P)   ((P) ? 0x9520 : 0x5520)
 #define IXGBE_KRM_RX_ANA_CTL(P)((P) ? 0x9A00 : 0x5A00)
+#define IXGBE_KRM_FLX_TMRS_CTRL_ST31(P)((P) ? 0x9180 : 0x5180)
 
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_DA ~(0x3 << 20)
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_SR (1u << 20)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c 
b/drivers/net/ixgbe/base/ixgbe_x550.c
index 8810d1658e..a88546f98f 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2676,6 +2676,56 @@ STATIC s32 ixgbe_setup_sfi_x550a(struct ixgbe_hw *hw, 
ixgbe_link_speed *speed)
IXGBE_KRM_PMD_FLX_MASK_ST20(hw->bus.lan_id),
IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
 
+   /* change mode enforcement rules to hybrid */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x0400;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* manually control the config */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x20002240;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* move the AN base page values */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x1;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* set the AN37 over CB mode */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= 0x2000;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+   /* restart AN manually */
+   status = mac->ops.read_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, ®_val);
+   status |= IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART;
+
+   status = mac->ops.write_iosf_sb_reg(hw,
+   IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+   IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
/* Toggle port SW reset by AN reset. */
status = ixgbe_restart_an_internal_phy_x550em(hw);
 
-- 
2.25.1

Re: [PATCH] doc: nohz_full already implies rcu_nocbs

[Thomas Monjalon]

08/02/2022 04:50, Tudor Brindus:
> From Documentation/admin-guide/kernel-parameters.txt, specifically the
> last sentence:
> 
>  nohz_full=  [KNL,BOOT,SMP,ISOL]
> The argument is a cpu list, as described above.
> In kernels built with CONFIG_NO_HZ_FULL=y, set
> the specified list of CPUs whose tick will be stopped
> whenever possible. The boot CPU will be forced outside
> the range to maintain the timekeeping.  Any CPUs
> in this list will have their RCU callbacks offloaded,
> just as if they had also been called out in the
> rcu_nocbs= boot parameter.
> 
> The kernel or-s the nohz_full cpumask into the rcu_nocbs cpumask at
> startup, and uses that.
> 
> Signed-off-by: Tudor Brindus 

Applied, thanks.

Re: [PATCH v3 0/4] arm64 cross docs improvements/fixes

[Thomas Monjalon]

25/01/2022 14:19, Juraj Linkeš:
> The docs are a bit outdated and in need of updates.
> 
> Using CFLAGS and LDFLAGS is an artefact of the old build system, Meson
> doesn't support those well.
> 
> Numaclt can't be cross compiled with clang.
> 
> The names of downloaded binaried have an extra -none- in them.
> 
> And to make these changes more easily understandable, add an example
> cross file.
> 
> v3: rebase and minor reformat in:
>   doc: arm64 cross build CFLAGS/LDFLAGS alternatives
>   docs: add an example arm64 cross file
> 
> Juraj Linkeš (4):
>   doc: arm64 cross build CFLAGS/LDFLAGS alternatives
>   doc: arm64 cross build binary names update
>   doc: arm64 cross build numactl compilers
>   doc: add an example arm64 cross file

Improved details (like line wrapping and uppercases),
and applied, thanks.

Re: [PATCH v2] doc: fix telemetry example for cryptodev

[Thomas Monjalon]

> >Blank line added to the final telemetry example for the cryptography device
> >library as to fix the example rendering.
> >
> >Fixes: 1c559ee8469 ("cryptodev: add telemetry endpoint for capabilities")
> >Cc: sta...@dpdk.org
> >
> >Signed-off-by: Sean Morrissey 
> 
> 
> Thanks for this.
> 
> Acked-by: Ciara Power 

Applied, thanks.

Re: [PATCH v1] raw/ifpga: initialize variable to avoid compile error

[Thomas Monjalon]

16/03/2022 10:40, Thomas Monjalon:
> 16/03/2022 10:27, Gao, DaxueX:
> > From: Wei Huang 
> > > 
> > > Compile failed with cflag optimization=1 on Ubuntu20.04 with GCC10.3, it
> > > reported vendor_id and dev_id may be used uninitialized in function
> > > ifpga_rawdev_fill_info().
> > > Actually it's not the truth, the variables are initialized in function
> > > ifpga_get_dev_vendor_id(). To avoid such compile error, the variables are
> > > initialized when they are defined.
> > > 
> > > Signed-off-by: Wei Huang 
> > > Acked-by: Tianfei Zhang 
> > > Acked-by: Rosen Xu 
> > 
> > Tested-by: Daxue Gao 
> 
> We need a "Fixes:" line to help backports, please.

Added this:

Fixes: 9c006c45d0c5 ("raw/ifpga: scan PCIe BDF device tree")
Cc: sta...@dpdk.org

Applied in last minute.

Re: [PATCH] lib/power: power pmd errata with RTM and gcc-9

[Thomas Monjalon]

09/03/2022 14:22, David Hunt:
> An errata exists where users may see reduced power savings when using
> PMD Power Management. This issue occurs when compiling DPDK applications
> with gcc-9 on platforms with TSX enabled. In rte_power_monitor_multi(),
> the function may return without successfully starting the RTM
> transaction (the _xbegin() fails).
> 
> Signed-off-by: David Hunt 

Applied, thanks.

Is there a way to fix it or should we keep this errata forever?

[PATCH v1] doc: announce changes in bbdev related to enum extension

[Nicolas Chautru]

Realizing when submitting new bbdev operation in this patch
(https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not
workable in practice to extend this API into 22.07 without fundamental ABI 
breakage
even by using existing versionning framework.
Some existing learnings to be applied here to prevent extension being blocked,
hence accouncing changes in bbdev intended for 22.11 to make this more
future-proof, including dropping max value from enum, as well as deferring 
extension
of the API for FFT operation into DPDK 22.11.

Let me know if any comments or in case this should be captured differently.
Thanks
Nic

Nicolas Chautru (1):
  doc: announce changes in bbdev related to enum extension

 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 8 insertions(+)

-- 
1.8.3.1

[PATCH v1] doc: announce changes in bbdev related to enum extension

[Nicolas Chautru]

Intent to resolve in DPDK 22.11 historical usage which prevents
graceful extension of enum and API without troublesome ABI breakage
as well as extending API RTE_BBDEV_OP_FFT for new operation type
in bbdev.

Signed-off-by: Nicolas Chautru 
---
 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c..238920e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,14 @@ Deprecation Notices
   session and the private data of session. An opaque pointer can be exposed
   directly to application which can be attached to the ``rte_crypto_op``.
 
+* bbdev: Will fix extending some enum breaking the ABI. Notably
+deprecating ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type``
+and use fixed array size when required to allow for future enum extension.
+Will also remove some of the inlining when causing ABI future-proof concerns.
+Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this
+RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111
+This should be updated in DPDK 22.11.
+
 * security: Hide structure ``rte_security_session`` and expose an opaque
   pointer for the private data to the application which can be attached
   to the packet while enqueuing.
-- 
1.8.3.1

[Bug 939] [dpdk 22.03-rc2] drivers/net/cnxk/cnxk_ethdev_mtr meson build failed with cflag parm optimization=1 on Ubuntu20.04 with GCC10.3

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=939

gaodaxue (daxuex@intel.com) changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from gaodaxue (daxuex@intel.com) ---
Verified based on ba7b205a98 PASSED.

OS: Ubuntu 20.04.3 LTS/Linux 5.8.0-48-generic

GCC: gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH 1/2] common/cnxk: fix ROC naming convention issues

[psatheesh]

From: Satheesh Paul 

Fixed some names to follow ROC naming convention in ROC NPC code.

Fixes: 4edf1246a40 ("common/cnxk: support matching VLAN existence in RTE Flow")
Cc: sta...@dpdk.org

Signed-off-by: Satheesh Paul 
---
 drivers/common/cnxk/roc_npc.h  | 6 +++---
 drivers/common/cnxk/roc_npc_mcam.c | 4 ++--
 drivers/common/cnxk/roc_platform.h | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/common/cnxk/roc_npc.h b/drivers/common/cnxk/roc_npc.h
index 6204139396..4c0151e2e7 100644
--- a/drivers/common/cnxk/roc_npc.h
+++ b/drivers/common/cnxk/roc_npc.h
@@ -60,7 +60,7 @@ struct roc_npc_flow_item_raw {
 
 struct roc_ether_addr {
uint8_t addr_bytes[PLT_ETHER_ADDR_LEN]; /**< Addr bytes in tx order */
-} plt_aligned(2);
+} __plt_aligned(2);
 
 struct roc_ether_hdr {
struct roc_ether_addr d_addr; /**< Destination address. */
@@ -72,7 +72,7 @@ struct roc_ether_hdr {
} S_un; /**< Do not use directly; use s_addr instead.*/
};
uint16_t ether_type; /**< Frame type. */
-} plt_aligned(2);
+} __plt_aligned(2);
 
 PLT_STD_C11
 struct roc_npc_flow_item_eth {
@@ -254,7 +254,7 @@ enum roc_npc_rss_hash_function {
 struct roc_npc_action_rss {
enum roc_npc_rss_hash_function func;
uint32_t level;
-   uint64_t types;/**< Specific RSS hash types (see 
RTE_ETH_RSS_*). */
+   uint64_t types;/**< Specific RSS hash types (see ETH_RSS_*). */
uint32_t key_len;  /**< Hash key length in bytes. */
uint32_t queue_num;/**< Number of entries in @p queue. */
const uint8_t *key;/**< Hash key. */
diff --git a/drivers/common/cnxk/roc_npc_mcam.c 
b/drivers/common/cnxk/roc_npc_mcam.c
index 9c5ff5e60a..e592310bde 100644
--- a/drivers/common/cnxk/roc_npc_mcam.c
+++ b/drivers/common/cnxk/roc_npc_mcam.c
@@ -283,8 +283,8 @@ npc_get_kex_capability(struct npc *npc)
/* Custom L3 frame: varied offset and lengths */
kex_cap.bit.custom_l3 =
npc_is_kex_enabled(npc, NPC_LID_LC, NPC_LT_LC_CUSTOM0, 0, 0);
-   kex_cap.bit.custom_l3 |=
-   npc_is_kex_enabled(npc, NPC_LID_LC, NPC_LT_LC_CUSTOM1, 0, 0);
+   kex_cap.bit.custom_l3 |= (uint64_t)npc_is_kex_enabled(
+   npc, NPC_LID_LC, NPC_LT_LC_CUSTOM1, 0, 0);
/* SCTP sport : offset 0B, len 2B */
kex_cap.bit.sctp_sport = npc_is_kex_enabled(
npc, NPC_LID_LD, NPC_LT_LD_SCTP, 0 * 8, 2 * 8);
diff --git a/drivers/common/cnxk/roc_platform.h 
b/drivers/common/cnxk/roc_platform.h
index 28004b1743..dd6514eb10 100644
--- a/drivers/common/cnxk/roc_platform.h
+++ b/drivers/common/cnxk/roc_platform.h
@@ -98,7 +98,7 @@
 #define plt_cpu_to_be_64 rte_cpu_to_be_64
 #define plt_be_to_cpu_64 rte_be_to_cpu_64
 
-#define plt_aligned__rte_aligned
+#define __plt_aligned  __rte_aligned
 #define plt_align32pow2rte_align32pow2
 #define plt_align32prevpow2 rte_align32prevpow2
 
-- 
2.25.4

[dpdk-dev] [PATCH 2/2] common/cnxk: fix QINQ ROC item mismatch issue

[psatheesh]

From: Satheesh Paul 

ROC code is assuming presence of vlan extension headers in
case of QINQ, because of this, there is incompatibility
between the driver and ROC. Fixed this issue.

Fixes: 4edf1246a40 ("common/cnxk: support matching VLAN existence in RTE Flow")
Cc: sta...@dpdk.org

Signed-off-by: Satheesh Paul 
---
 drivers/common/cnxk/roc_npc_parse.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/common/cnxk/roc_npc_parse.c 
b/drivers/common/cnxk/roc_npc_parse.c
index b849326a19..757bff29a7 100644
--- a/drivers/common/cnxk/roc_npc_parse.c
+++ b/drivers/common/cnxk/roc_npc_parse.c
@@ -337,15 +337,10 @@ npc_parse_lb(struct npc_parse_state *pst)
}
info.len = pattern->size;
} else if (pst->pattern->type == ROC_NPC_ITEM_TYPE_QINQ) {
-   vlan_item[0] = pst->pattern->spec;
info.hw_mask = NULL;
-   info.len = sizeof(vlan_item[0]->hdr);
+   info.len = pattern->size;
lt = NPC_LT_LB_STAG_QINQ;
lflags = NPC_F_STAG_CTAG;
-   if (vlan_item[0] && vlan_item[0]->has_more_vlan) {
-   lflags = NPC_F_LB_L_WITH_QINQ_CTAG &
-NPC_F_LB_L_WITH_QINQ_QINQ;
-   }
} else if (pst->pattern->type == ROC_NPC_ITEM_TYPE_RAW) {
raw_spec = pst->pattern->spec;
if (raw_spec->relative)
-- 
2.25.4

[PATCH] multi_proc_support.rst: updated file location for config file in documentation

[Muhammad Jawad Hussain]

previously .rte_config was made at /var/run/.rte_config
for root users and $HOME/.rte_config for non-root users
now the file is renamed to config
 and is created at /var/run/dpdk/rte/config
for root users and /run/user/$EUID/dpdk/rte/config for non-root users
the docmentation of multi_proc_support has been updated
 to reflect this change

Signed-off-by: Muhammad Jawad Hussain 
---
 doc/guides/prog_guide/multi_proc_support.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/prog_guide/multi_proc_support.rst 
b/doc/guides/prog_guide/multi_proc_support.rst
index 815e8bdc43..a409769b9c 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -113,8 +113,8 @@ Support for this usage scenario is provided using the 
``--file-prefix`` paramete
 
 By default, the EAL creates hugepage files on each hugetlbfs filesystem using 
the rtemap_X filename,
 where X is in the range 0 to the maximum number of hugepages -1.
-Similarly, it creates shared configuration files, memory mapped in each 
process, using the /var/run/.rte_config filename,
-when run as root (or $HOME/.rte_config when run as a non-root user;
+Similarly, it creates shared configuration files, memory mapped in each 
process, using the /var/run/dpdk/rte/config filename,
+when run as root (or /run/user/$EUID/dpdk/rte/config when run as a non-root 
user;
 if filesystem and device permissions are set up to allow this).
 The rte part of the filenames of each of the above is configurable using the 
file-prefix parameter.
 
-- 
2.32.0

RE: [PATCH] net/ixgbe: Retry SFP ID read field to handle misbehaving SFPs

[Wang, Haiyue]

> -Original Message-
> From: je...@silicom-usa.com 
> Sent: Tuesday, March 8, 2022 06:34
> To: dev@dpdk.org
> Cc: Stephen Douthit ; Daly, Jeff 
> ; Wang, Haiyue
> 
> Subject: [PATCH] net/ixgbe: Retry SFP ID read field to handle misbehaving SFPs
> 
> From: Stephen Douthit 
> 
> Some XGS-PON SFPs have been observed ACKing I2C reads and returning
> uninitialized garbage while their uC boots.  This can lead to the SFP ID
> code marking an otherwise working SFP module as unsupported if a bogus
> ID value is read while its internal PHY/microcontroller is still
> booting.
> 
> Retry the ID read several times looking not just for NAK, but also for a
> valid ID field.
> 
> Since the device isn't NAKing the trasanction the existing longer retry
> code in ixgbe_read_i2c_byte_generic_int() doesn't apply here.
> 
> Signed-off-by: Stephen Douthit 
> Signed-off-by: Jeff Daly 
> ---
>  drivers/net/ixgbe/base/ixgbe_phy.c | 31 ++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.c 
> b/drivers/net/ixgbe/base/ixgbe_phy.c
> index d8d51d2c3f..27bce066a1 100644
> --- a/drivers/net/ixgbe/base/ixgbe_phy.c
> +++ b/drivers/net/ixgbe/base/ixgbe_phy.c
> @@ -1275,6 +1275,7 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw 
> *hw)
>   u8 cable_tech = 0;
>   u8 cable_spec = 0;
>   u16 enforce_sfp = 0;
> + u8 id_reads;

"u8 retries" is a better name, I think, to match the patch title.

> 
>   DEBUGFUNC("ixgbe_identify_sfp_module_generic");
> 
> @@ -1287,12 +1288,34 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw 
> *hw)
>   /* LAN ID is needed for I2C access */
>   hw->mac.ops.set_lan_id(hw);
> 
> - status = hw->phy.ops.read_i2c_eeprom(hw,
> -  IXGBE_SFF_IDENTIFIER,
> -  &identifier);
> + /* Need to check this a couple of times for a sane value.
> +  *
> +  * SFPs that have a uC slaved to the I2C bus (vs. a dumb EEPROM) can be
> +  * poorly designed such that they will ACK I2C reads and return
> +  * whatever bogus data is in the SRAM (or whatever is backing the target
> +  * device) before things are truly initialized.
> +  *
> +  * In a perfect world devices would NAK I2C requests until they were
> +  * sane, but here we are.
> +  *
> +  * Give such devices a couple tries to get their act together before
> +  * marking the device as unsupported.
> +  */
> + for (id_reads = 0; id_reads < 5; id_reads++) {
> + status = hw->phy.ops.read_i2c_eeprom(hw,
> +  IXGBE_SFF_IDENTIFIER,
> +  &identifier);
> 
> - if (status != IXGBE_SUCCESS)
> + DEBUGOUT("status %d, id %d\n", status, identifier);
> + if (!status &&
> + identifier == IXGBE_SFF_IDENTIFIER_SFP)

Let's not assume the ' IXGBE_SUCCESS' is '0', so change it to:

if (status == IXGBE_SUCCESS &&
identifier == IXGBE_SFF_IDENTIFIER_SFP)

> + break;
> + }
> +
> + if (status != IXGBE_SUCCESS) {
> + DEBUGOUT("Failed SFF ID read (%d attempts)\n", id_reads);
>   goto err_read_i2c_eeprom;
> + }
> 
>   if (identifier != IXGBE_SFF_IDENTIFIER_SFP) {
>   hw->phy.type = ixgbe_phy_sfp_unsupported;
> --
> 2.25.1