[PATCH] doc: announce IPsec support on Arm

[Ruifeng Wang]

Updated release notes about the SNOW-3G and ZUC support on ARM platform.

Signed-off-by: Ruifeng Wang 
---
 doc/guides/rel_notes/release_22_11.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_22_11.rst 
b/doc/guides/rel_notes/release_22_11.rst
index 61f7d4d0aa..e863a3e856 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -243,6 +243,10 @@ New Features
   Added a new crypto driver for the UADK library. See the
   :doc:`../cryptodevs/uadk` guide for more details on this new driver.
 
+* **Updated ipsec_mb crypto driver.**
+
+  Added SNOW-3G and ZUC support for ARM platform.
+
 * **Added bbdev operation for FFT processing.**
 
   Added a new operation type in bbdev for FFT processing with new functions
-- 
2.25.1

RE: [EXT] [PATCH] doc: announce IPsec support on Arm

[Akhil Goyal]

> Updated release notes about the SNOW-3G and ZUC support on ARM platform.
> 
> Signed-off-by: Ruifeng Wang 
> ---
This was missed in the original patch. Can you add a Fixes tag for which this 
support was added?

RE: [EXT] [PATCH] doc: announce IPsec support on Arm

[Ruifeng Wang]

> -Original Message-
> From: Akhil Goyal 
> Sent: Monday, November 7, 2022 4:26 PM
> To: Ruifeng Wang ; roy.fan.zh...@intel.com; 
> tho...@monjalon.net;
> david.march...@redhat.com
> Cc: dev@dpdk.org; Honnappa Nagarahalli ; nd 
> 
> Subject: RE: [EXT] [PATCH] doc: announce IPsec support on Arm
> 
> > Updated release notes about the SNOW-3G and ZUC support on ARM platform.
> >
> > Signed-off-by: Ruifeng Wang 
> > ---
> This was missed in the original patch. Can you add a Fixes tag for which this 
> support was
> added?

Sure, I will send out version 2.
Thanks.

[PATCH v3] app/testpmd: fix protocol header display for Rx buffer split

[Yuan Wang]

The "show config rxhdrs" cmd displays the configured protocol headers
that are used for protocol-based buffer split.
However, it shows inner-ipv6 as inner-ipv4.

This patch fixes that by adjusting the order of condition judgments.
This patch also uses RTE_PTYPE_*_MASK as masks.

Fixes: 52e2e7edcf48 ("app/testpmd: add protocol-based buffer split")

Signed-off-by: Yuan Wang 

---
v3: 
- use RTE_PTYPE_*_MASK as masks.
- refactor to use switch statement.
v2:
- add fixline.

---
 app/test-pmd/config.c | 89 +--
 1 file changed, 44 insertions(+), 45 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index e8a1b77c2a..8638dfed11 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -5070,73 +5070,72 @@ show_rx_pkt_segments(void)
 
 static const char *get_ptype_str(uint32_t ptype)
 {
-   if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
+   switch (ptype & (RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK)) {
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
return "ipv4-tcp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
return "ipv4-udp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) 
==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
return "ipv4-sctp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
return "ipv6-tcp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
return "ipv6-udp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) 
==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
return "ipv6-sctp";
-   else if ((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP)
+   case RTE_PTYPE_L4_TCP:
return "tcp";
-   else if ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP)
+   case RTE_PTYPE_L4_UDP:
return "udp";
-   else if ((ptype & RTE_PTYPE_L4_SCTP) == RTE_PTYPE_L4_SCTP)
+   case RTE_PTYPE_L4_SCTP:
return "sctp";
-   else if ((ptype & RTE_PTYPE_L3_IPV4_EXT_UNKNOWN) == 
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN)
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN:
return "ipv4";
-   else if ((ptype & RTE_PTYPE_L3_IPV6_EXT_UNKNOWN) == 
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN)
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN:
return "ipv6";
-   else if ((ptype & RTE_PTYPE_L2_ETHER) == RTE_PTYPE_L2_ETHER)
+   }
+
+   switch (ptype & RTE_PTYPE_L2_MASK) {
+   case RTE_PTYPE_L2_ETHER:
return "eth";
+   }
 
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_TCP)) ==
-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
-   return "inner-ipv4-tcp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_UDP)) ==
-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP))
-   return "inner-ipv4-udp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_SCTP)) ==
-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP))
-   return "inner-ipv4-sctp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_TCP)) ==
-   (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
+   switch (ptype & (RTE_PTYPE_INNER_L3_MASK | RTE_PTYPE_INNER_L4_MASK)) {
+   case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP:
return "inner-ipv6-tcp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_UDP)) ==
-   (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP))
+   case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP:
return "inner-ipv6-udp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_SCTP)) ==
-   (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP))
+   case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP:
return "inner-ipv6-sctp";
-   else if ((ptype & RTE_PTYPE_INNER_L4_TCP) == RTE_PTYPE_INNE

[PATCH v2] doc: announce IPsec support on Arm

[Ruifeng Wang]

Updated release notes about the SNOW-3G and ZUC support on ARM platform.

Fixes: 0899a87ce7c7 ("crypto/ipsec_mb: enable IPsec on Arm platform")

Signed-off-by: Ruifeng Wang 
---
 doc/guides/rel_notes/release_22_11.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_22_11.rst 
b/doc/guides/rel_notes/release_22_11.rst
index 61f7d4d0aa..e863a3e856 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -243,6 +243,10 @@ New Features
   Added a new crypto driver for the UADK library. See the
   :doc:`../cryptodevs/uadk` guide for more details on this new driver.
 
+* **Updated ipsec_mb crypto driver.**
+
+  Added SNOW-3G and ZUC support for ARM platform.
+
 * **Added bbdev operation for FFT processing.**
 
   Added a new operation type in bbdev for FFT processing with new functions
-- 
2.25.1

RE: [PATCH v2 2/3] mempool: include non-DPDK threads in statistics

[Morten Brørup]

> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: Monday, 7 November 2022 08.27
> 
> On 2022-11-04 11:01, Morten Brørup wrote:
> >> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> >> Sent: Friday, 4 November 2022 09.59
> >>
> >> On 2022-11-03 09:59, Morten Brørup wrote:
>  From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
>  Sent: Wednesday, 2 November 2022 18.53
> 
>  On 2022-11-02 10:09, Morten Brørup wrote:
> >> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> >> Sent: Wednesday, 2 November 2022 08.53
> >>
> >> On 2022-10-31 12:26, Morten Brørup wrote:
> >>> Offset the stats array index by one, and count non-DPDK threads
> >> at
> >> index
> >>> zero.
> >>>
> >>> This patch provides two benefits:
> >>> * Non-DPDK threads are also included in the statistics.
> >>> * A conditional in the fast path is removed. Static branch
>  prediction
> >> was
> >>>   correct, so the performance improvement is negligible.
> >>>
> >>> v2:
> >>> * New. No v1 of this patch in the series.
> >>>
> >>> Suggested-by: Stephen Hemminger 
> >>> Signed-off-by: Morten Brørup 
> >>> ---
> >>>  lib/mempool/rte_mempool.c |  2 +-
> >>>  lib/mempool/rte_mempool.h | 12 ++--
> >>>  2 files changed, 7 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/lib/mempool/rte_mempool.c
> >> b/lib/mempool/rte_mempool.c
> >>> index 62d1ce764e..e6208125e0 100644
> >>> --- a/lib/mempool/rte_mempool.c
> >>> +++ b/lib/mempool/rte_mempool.c
> >>> @@ -1272,7 +1272,7 @@ rte_mempool_dump(FILE *f, struct
> >> rte_mempool
> >> *mp)
> >>>  #ifdef RTE_LIBRTE_MEMPOOL_STATS
> >>>   rte_mempool_ops_get_info(mp, &info);
> >>>   memset(&sum, 0, sizeof(sum));
> >>> - for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> >>> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE + 1;
> >> lcore_id++) {
> >>>   sum.put_bulk += mp->stats[lcore_id].put_bulk;
> >>>   sum.put_objs += mp->stats[lcore_id].put_objs;
> >>>   sum.put_common_pool_bulk += mp-
> >>> stats[lcore_id].put_common_pool_bulk;
> >>> diff --git a/lib/mempool/rte_mempool.h
> >> b/lib/mempool/rte_mempool.h
> >>> index 9c4bf5549f..16e7e62e3c 100644
> >>> --- a/lib/mempool/rte_mempool.h
> >>> +++ b/lib/mempool/rte_mempool.h
> >>> @@ -238,8 +238,11 @@ struct rte_mempool {
> >>>   struct rte_mempool_memhdr_list mem_list; /**< List of
>  memory
> >> chunks */
> >>>
> >>>  #ifdef RTE_LIBRTE_MEMPOOL_STATS
> >>> - /** Per-lcore statistics. */
> >>> - struct rte_mempool_debug_stats stats[RTE_MAX_LCORE];
> >>> + /** Per-lcore statistics.
> >>> +  *
> >>> +  * Offset by one, to include non-DPDK threads.
> >>> +  */
> >>> + struct rte_mempool_debug_stats stats[RTE_MAX_LCORE + 1];
> >>>  #endif
> >>>  }  __rte_cache_aligned;
> >>>
> >>> @@ -304,10 +307,7 @@ struct rte_mempool {
> >>>   */
> >>>  #ifdef RTE_LIBRTE_MEMPOOL_STATS
> >>>  #define RTE_MEMPOOL_STAT_ADD(mp, name, n) do {
>  \
> >>> - unsigned __lcore_id = rte_lcore_id();   \
> >>> - if (__lcore_id < RTE_MAX_LCORE) {   \
> >>> - mp->stats[__lcore_id].name += n;\
> >>> - }   \
> >>> + (mp)->stats[rte_lcore_id() + 1].name += n;  \
> >>
> >> This relies on LCORE_ID_ANY being UINT32_MAX, and a wrap to 0,
> for
>  an
> >> unregistered non-EAL thread? Might be worth a comment, or better
> a
> >> rewrite with an explicit LCORE_ID_ANY comparison.
> >
> > The purpose of this patch is to avoid the comparison here.
> >
> > Yes, it relies on the wrap to zero, and these conditions:
> > 1. LCORE_ID_ANY being UINT32_MAX, and
> > 2. the return type of rte_lcore_id() being unsigned int, and
> > 3. unsigned int being uint32_t.
> >
> > When I wrote this, I considered it safe to assume that
> LCORE_ID_ANY
>  will remain the unsigned equivalent of -1 using the return type of
>  rte_lcore_id(). In other words: If the return type of
> rte_lcore_id()
>  should change from 32 to 64 bit, LCORE_ID_ANY would be updated
>  accordingly to UINT64_MAX.
> >
> > Because of this assumption, I didn't use [(rte_lcore_id() + 1) &
>  UINT32_MAX], but just [rte_lcore_id() + 1].
> >
> > I struggled writing an appropriate comment without making it
>  unacceptably long, but eventually gave up, and settled for the
> one-
> >> line
>  comment in the structure only.
> >
> >>
> >> You anyways need a conditional. An atomic add must be used in
> the
> >> unregistered EAL thread case.
> >
> 

RE: [PATCH v3] app/testpmd: fix protocol header display for Rx buffer split

[Tang, Yaqi]

> -Original Message-
> From: Wang, YuanX 
> Sent: Monday, November 7, 2022 4:45 PM
> To: andrew.rybche...@oktetlabs.ru; Singh, Aman Deep
> ; Zhang, Yuying 
> Cc: Ding, Xuan ; Tang, Yaqi ;
> dev@dpdk.org; Wang, YuanX 
> Subject: [PATCH v3] app/testpmd: fix protocol header display for Rx buffer
> split
> 
> The "show config rxhdrs" cmd displays the configured protocol headers that
> are used for protocol-based buffer split.
> However, it shows inner-ipv6 as inner-ipv4.
> 
> This patch fixes that by adjusting the order of condition judgments.
> This patch also uses RTE_PTYPE_*_MASK as masks.
> 
> Fixes: 52e2e7edcf48 ("app/testpmd: add protocol-based buffer split")
> 
> Signed-off-by: Yuan Wang 
> 
> ---
> v3:
> - use RTE_PTYPE_*_MASK as masks.
> - refactor to use switch statement.
> v2:
> - add fixline.
> 
> ---

Tested-by: Yaqi Tang 

[PATCH v3] vdpa/ifc: fix update_datapath error handling

[Taekyung Kim]

Stop and return the error code when update_datapath fails.
update_datapath prepares resources for the vdpa device.
The driver should not perform any further actions
if update_datapath returns an error.

Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")
Cc: sta...@dpdk.org

Signed-off-by: Taekyung Kim 
---
v3:
* Fix coding style

v2:
* Revert the prepared resources before returning an error
* Rebase to 22.11 rc2
* Add fixes and cc for backport

---
 drivers/vdpa/ifc/ifcvf_vdpa.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
index 8dfd49336e..0396d49122 100644
--- a/drivers/vdpa/ifc/ifcvf_vdpa.c
+++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
@@ -1098,7 +1098,12 @@ ifcvf_dev_config(int vid)
internal = list->internal;
internal->vid = vid;
rte_atomic32_set(&internal->dev_attached, 1);
-   update_datapath(internal);
+   if (update_datapath(internal) < 0) {
+   DRV_LOG(ERR, "failed to update datapath for vDPA device %s",
+   vdev->device->name);
+   rte_atomic32_set(&internal->dev_attached, 0);
+   return -1;
+   }
 
hw = &internal->hw;
for (i = 0; i < hw->nr_vring; i++) {
@@ -1146,7 +1151,12 @@ ifcvf_dev_close(int vid)
internal->sw_fallback_running = false;
} else {
rte_atomic32_set(&internal->dev_attached, 0);
-   update_datapath(internal);
+   if (update_datapath(internal) < 0) {
+   DRV_LOG(ERR, "failed to update datapath for vDPA device 
%s",
+   vdev->device->name);
+   internal->configured = 0;
+   return -1;
+   }
}
 
internal->configured = 0;
@@ -1752,7 +1762,14 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
}
 
rte_atomic32_set(&internal->started, 1);
-   update_datapath(internal);
+   if (update_datapath(internal) < 0) {
+   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
+   rte_atomic32_set(&internal->started, 0);
+   pthread_mutex_lock(&internal_list_lock);
+   TAILQ_REMOVE(&internal_list, list, next);
+   pthread_mutex_unlock(&internal_list_lock);
+   goto error;
+   }
 
rte_kvargs_free(kvlist);
return 0;
@@ -1781,7 +1798,8 @@ ifcvf_pci_remove(struct rte_pci_device *pci_dev)
 
internal = list->internal;
rte_atomic32_set(&internal->started, 0);
-   update_datapath(internal);
+   if (update_datapath(internal) < 0)
+   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
 
rte_pci_unmap_device(internal->pdev);
rte_vfio_container_destroy(internal->vfio_container_fd);
-- 
2.34.1

[PATCH] net/ixgbe: fix error of drop queue index

[kevin-intel]

The drop queue index was not set when adding internal Flow
Director Configuration copy in ixgbe device private data.
Therefore dropped packets would be received by queue 0
which is set to drop queue.

This commit sets drop queue index as IXGBE_FDIR_DROP_QUEUE
to fix this issue.

Fixes: 5007ac13189d ("ethdev: remove deprecated Flow Director configuration")

Signed-off-by: kevin-intel 
---
 drivers/net/ixgbe/ixgbe_flow.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 1250c2dc12..110ff34fcc 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -2759,6 +2759,7 @@ ixgbe_parse_fdir_filter(struct rte_eth_dev *dev,
int ret;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_fdir_conf *fdir_conf = IXGBE_DEV_FDIR_CONF(dev);
+   fdir_conf->drop_queue = IXGBE_FDIR_DROP_QUEUE;
 
if (hw->mac.type != ixgbe_mac_82599EB &&
hw->mac.type != ixgbe_mac_X540 &&
-- 
2.34.1

RE: [PATCH] power: fix double free of opened files

[Pattan, Reshma]

> -Original Message-
> From: Kearney, Tadhg 

> Subject: [PATCH] power: fix double free of opened files
> 
> Fix double free of f_min and f_max by reverting the flcose() for f_min and
> f_max. As f_min and f_max are stored for further use and closed in uncore
> deinitialization.
> 
> Fixes: b127e74 ("power: fix open file descriptors leak")
> 
> Signed-off-by: Tadhg Kearney 
> ---

Acked-by: Reshma Pattan 

Re: [RFC]: mempool: zero-copy cache get bulk

[Bruce Richardson]

On Sat, Nov 05, 2022 at 02:19:13PM +0100, Morten Brørup wrote:
> Zero-copy access to the mempool cache is beneficial for PMD performance, and 
> must be provided by the mempool library to fix [Bug 1052] without a 
> performance regression.
> 
> [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> 
> 
> This RFC offers two conceptual variants of zero-copy get:
> 1. A simple version.
> 2. A version where existing (hot) objects in the cache are moved to the top 
> of the cache before new objects from the backend driver are pulled in.
> 
> I would like some early feedback. Also, which variant do you prefer?
> 
> Notes:
> * Allowing the 'cache' parameter to be NULL, and getting it from the mempool 
> instead, was inspired by rte_mempool_cache_flush().
> * Asserting that the 'mp' parameter is not NULL is not done by other 
> functions, so I omitted it here too.
> 
> NB: Please ignore formatting. Also, this code has not even been compile 
> tested.
> 
> 
> PS: No promises, but I expect to offer an RFC for zero-copy put too. :-)
> 

Thanks for this work, I think it's good to have. The existing functions
could probably be reworked to use this new code too, right, since the copy
at the end would be all that is needed to complete the implementation?

Only real comment I have on this version is that I am not sure about the
naming. I think having "cache_get_bulk" doesn't really make it very clear
what the function does, that is removes items from the cache without
copying them elsewhere. How about:

- rte_mempool_cache_pop?
- rte_mempool_cache_reserve?

I would tend to prefer the former, since the latter implies that there
needs to be a follow-up call to clear the reservation. On the other hand,
reserve does give the correct impression that the elements are still there
in the mempool cache.

Others may have better suggestions, since, as we know, naming things is
hard! :)

Overall, though, I think this is very good to have.
/Bruce

Re: [PATCH] usertools/hugepages: show usage if no action specified

[Robin Jarry]

Thomas Monjalon, Nov 04, 2022 at 12:30:
> Previously, the script was doing nothing if no argument was provided.
>
> If neither show, mount/unmount, clear/reserve are specified,
> it is assumed that the user does not know how to use the script.
> So the usage is printed and an error code is used in exit.
> The user will understand something is wrong,
> and can recall the script with the option -h to get more information.
>
> Signed-off-by: Thomas Monjalon 
> ---
>  usertools/dpdk-hugepages.py | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
> index a22d504d3a..823cfcf185 100755
> --- a/usertools/dpdk-hugepages.py
> +++ b/usertools/dpdk-hugepages.py
> @@ -272,6 +272,10 @@ def main():
>  args.reserve = args.setup
>  args.mount = True
>  
> +if not (args.show or args.mount or args.unmount or args.clear or 
> args.reserve):
> +parser.print_usage()
> +sys.exit(1)

Hi Thomas,

I believe you can do:

   parser.error("at least one of -s/-c/-m/-u/-r/--setup is required")

and omit sys.exit(1).

$ ~/dev/dpdk/usertools/dpdk-hugepages.py
usage: dpdk-hugepages.py [-h] [--show] [--clear] [--mount] [--unmount] [--node 
NODE] [--pagesize SIZE] [--reserve SIZE] [--setup SIZE]
dpdk-hugepages.py: error: at least one of -s/-c/-m/-u/-r/--setup is required

[PATCH 4/4] net/mlx5/hws: fix possible negative return on sq create

[Alex Vesker]

The sysconf call can return a negative value (-1) on failure
this will lead to posix_memalign to fail. This is not a realistic
case which was found by the static checkers.

Coverity issue: 381674
Fixes: 3eb7488 ("net/mlx5/hws: add send layer")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_send.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_send.c 
b/drivers/net/mlx5/hws/mlx5dr_send.c
index 26904a9040..1e9953a38f 100644
--- a/drivers/net/mlx5/hws/mlx5dr_send.c
+++ b/drivers/net/mlx5/hws/mlx5dr_send.c
@@ -524,6 +524,7 @@ static int mlx5dr_send_ring_open_sq(struct mlx5dr_context 
*ctx,
size_t sq_log_buf_sz;
size_t buf_aligned;
size_t sq_buf_sz;
+   size_t page_size;
size_t buf_sz;
int err;
 
@@ -532,8 +533,9 @@ static int mlx5dr_send_ring_open_sq(struct mlx5dr_context 
*ctx,
sq_buf_sz = 1 << (sq_log_buf_sz + log2above(MLX5_SEND_WQE_BB));
sq->reg_addr = queue->uar->reg_addr;
 
-   buf_aligned = align(sq_buf_sz, sysconf(_SC_PAGESIZE));
-   err = posix_memalign((void **)&sq->buf, sysconf(_SC_PAGESIZE), 
buf_aligned);
+   page_size = sysconf(_SC_PAGESIZE);
+   buf_aligned = align(sq_buf_sz, page_size);
+   err = posix_memalign((void **)&sq->buf, page_size, buf_aligned);
if (err) {
rte_errno = ENOMEM;
return err;
-- 
2.18.1

[PATCH] examples/fips_validation: fix typo

[Pablo de Lara]

Digest length is being printed out, not IV length.

Fixes: ac026f4668d0 ("examples/fips_validation: support CMAC parsing")
Fixes: f64adb6714e0 ("examples/fips_validation: support HMAC parsing")
Cc: marko.kovace...@intel.com
Cc: sta...@dpdk.org
---
 examples/fips_validation/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 404a29d7b6..9a9babb53a 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -1210,7 +1210,7 @@ prepare_hmac_xform(struct rte_crypto_sym_xform *xform)
if (rte_cryptodev_sym_capability_check_auth(cap,
auth_xform->key.length,
auth_xform->digest_length, 0) != 0) {
-   RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
+   RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
return -EPERM;
@@ -1339,7 +1339,7 @@ prepare_cmac_xform(struct rte_crypto_sym_xform *xform)
if (rte_cryptodev_sym_capability_check_auth(cap,
auth_xform->key.length,
auth_xform->digest_length, 0) != 0) {
-   RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
+   RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
return -EPERM;
-- 
2.34.1

[PATCH] net/mlx5/hws: fix possible action setter segmenation fault

[Alex Vesker]

When the maximum action combination in RX is used we can get
a segfault due to an incorrecrt max array size define.
This bug can happen on RX/TX or FDB in the most complex
cases.
Current max was set to 7, but actual max is:
Max TX: 8, Max RX: 10, Max FDB: 9

Fixes: f8c8a6d ("net/mlx5/hws: add action object")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_action.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_action.h 
b/drivers/net/mlx5/hws/mlx5dr_action.h
index 3b31ffc90e..9a4827481a 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.h
+++ b/drivers/net/mlx5/hws/mlx5dr_action.h
@@ -6,7 +6,7 @@
 #define MLX5DR_ACTION_H_
 
 /* Max number of STEs needed for a rule (including match) */
-#define MLX5DR_ACTION_MAX_STE 7
+#define MLX5DR_ACTION_MAX_STE 10
 
 enum mlx5dr_action_stc_idx {
MLX5DR_ACTION_STC_IDX_CTRL = 0,
-- 
2.18.1

[PATCH v2] examples/fips_validation: fix typo

[Pablo de Lara]

Digest length is being printed out, not IV length.

Fixes: ac026f4668d0 ("examples/fips_validation: support CMAC parsing")
Fixes: f64adb6714e0 ("examples/fips_validation: support HMAC parsing")
Cc: marko.kovace...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Pablo de Lara 
---
-v2: added missing "Signed-off"
---

 examples/fips_validation/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 404a29d7b6..9a9babb53a 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -1210,7 +1210,7 @@ prepare_hmac_xform(struct rte_crypto_sym_xform *xform)
if (rte_cryptodev_sym_capability_check_auth(cap,
auth_xform->key.length,
auth_xform->digest_length, 0) != 0) {
-   RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
+   RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
return -EPERM;
@@ -1339,7 +1339,7 @@ prepare_cmac_xform(struct rte_crypto_sym_xform *xform)
if (rte_cryptodev_sym_capability_check_auth(cap,
auth_xform->key.length,
auth_xform->digest_length, 0) != 0) {
-   RTE_LOG(ERR, USER1, "PMD %s key length %u IV length %u\n",
+   RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length %u\n",
info.device_name, auth_xform->key.length,
auth_xform->digest_length);
return -EPERM;
-- 
2.34.1

[PATCH] net/mlx5/hws: fix possible negative return on sq create

[Alex Vesker]

The sysconf call can return a negative value (-1) on failure
this will lead to posix_memalign to fail. This is not a realistic
case which was found by the static checkers.

Coverity issue: 381674
Fixes: 3eb7488 ("net/mlx5/hws: add send layer")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_send.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_send.c 
b/drivers/net/mlx5/hws/mlx5dr_send.c
index 26904a9040..1e9953a38f 100644
--- a/drivers/net/mlx5/hws/mlx5dr_send.c
+++ b/drivers/net/mlx5/hws/mlx5dr_send.c
@@ -524,6 +524,7 @@ static int mlx5dr_send_ring_open_sq(struct mlx5dr_context 
*ctx,
size_t sq_log_buf_sz;
size_t buf_aligned;
size_t sq_buf_sz;
+   size_t page_size;
size_t buf_sz;
int err;
 
@@ -532,8 +533,9 @@ static int mlx5dr_send_ring_open_sq(struct mlx5dr_context 
*ctx,
sq_buf_sz = 1 << (sq_log_buf_sz + log2above(MLX5_SEND_WQE_BB));
sq->reg_addr = queue->uar->reg_addr;
 
-   buf_aligned = align(sq_buf_sz, sysconf(_SC_PAGESIZE));
-   err = posix_memalign((void **)&sq->buf, sysconf(_SC_PAGESIZE), 
buf_aligned);
+   page_size = sysconf(_SC_PAGESIZE);
+   buf_aligned = align(sq_buf_sz, page_size);
+   err = posix_memalign((void **)&sq->buf, page_size, buf_aligned);
if (err) {
rte_errno = ENOMEM;
return err;
-- 
2.18.1

[PATCH v2] net/mlx5/hws: fix possible action setter segmenation fault

[Alex Vesker]

When the maximum action combination in RX is used we can get
a segfault due to an incorrecrt max array size define.
This bug can happen on RX/TX or FDB in the most complex
cases.
Current max was set to 7, but actual max is:
Max TX: 8, Max RX: 10, Max FDB: 9

Fixes: f8c8a6d ("net/mlx5/hws: add action object")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_action.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_action.h 
b/drivers/net/mlx5/hws/mlx5dr_action.h
index 3b31ffc90e..9a4827481a 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.h
+++ b/drivers/net/mlx5/hws/mlx5dr_action.h
@@ -6,7 +6,7 @@
 #define MLX5DR_ACTION_H_
 
 /* Max number of STEs needed for a rule (including match) */
-#define MLX5DR_ACTION_MAX_STE 7
+#define MLX5DR_ACTION_MAX_STE 10
 
 enum mlx5dr_action_stc_idx {
MLX5DR_ACTION_STC_IDX_CTRL = 0,
-- 
2.18.1

[PATCH] net/mlx5: fix hairpin split with set VLAN VID action

[Dariusz Sosnowski]

Before this patch any flow rule which works on hairpin queues
and which has OF_SET_VLAN_VID action was split into 2 flow rules:

- one subflow for Rx,
- one subflow for Tx.

OF_SET_VLAN_VID action was always placed in the Tx subflow.

Assuming a flow rule which matches VLAN traffic and has both
OF_SET_VLAN_VID action, and MODIFY_FIELD action on VLAN VID,
but no OF_PUSH_VLAN action, the following happened:

- MODIFY_FIELD action was placed in Rx subflow,
- OF_SET_VLAN_VID action was placed in Tx subflow,
- OF_SET_VLAN_VID action is internally compiled to a header modify
  command.

This caused the following issues:

1. Since OF_SET_VLAN_VID was placed in Tx subflow, 2 header modify
   actions were allocated. One for Rx and one for Tx.
2. If OF_SET_VLAN_VID action was placed before MODIFY_FIELD on VLAN VID,
   the flow rule executed header modifications in reverse order.
   MODIFY_FIELD actions were executed first in the Rx subflow and
   OF_SET_VLAN_VID was executed second in Tx subflow.

This patch fixes this behavior by not splitting hairpin flow rules
if OF_SET_VLAN_VID action is used without OF_PUSH_VLAN.
On top of that, if flow rule is split, the OF_SET_VLAN_VID action
is not moved to Tx subflow (for flow rules mentioned above).

Fixes: 210008309b45 ("net/mlx5: fix VLAN push action on hairpin queue")
Cc: sta...@dpdk.org

Signed-off-by: Dariusz Sosnowski 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 65af1b4dd5..ea2b88 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -4591,6 +4591,7 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
int queue_action = 0;
int action_n = 0;
int split = 0;
+   int push_vlan = 0;
const struct rte_flow_action_queue *queue;
const struct rte_flow_action_rss *rss;
const struct rte_flow_action_raw_encap *raw_encap;
@@ -4599,6 +4600,8 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
if (!attr->ingress)
return 0;
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
+   if (actions->type == RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN)
+   push_vlan = 1;
switch (actions->type) {
case RTE_FLOW_ACTION_TYPE_QUEUE:
queue = actions->conf;
@@ -4623,11 +4626,15 @@ flow_check_hairpin_split(struct rte_eth_dev *dev,
case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
-   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
split++;
action_n++;
break;
+   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+   if (push_vlan)
+   split++;
+   action_n++;
+   break;
case RTE_FLOW_ACTION_TYPE_RAW_ENCAP:
raw_encap = actions->conf;
if (raw_encap->size > MLX5_ENCAPSULATION_DECISION_SIZE)
@@ -5088,19 +5095,32 @@ flow_hairpin_split(struct rte_eth_dev *dev,
struct mlx5_rte_flow_item_tag *tag_item;
struct rte_flow_item *item;
char *addr;
+   int push_vlan = 0;
int encap = 0;
 
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
+   if (actions->type == RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN)
+   push_vlan = 1;
switch (actions->type) {
case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
-   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP:
rte_memcpy(actions_tx, actions,
   sizeof(struct rte_flow_action));
actions_tx++;
break;
+   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+   if (push_vlan) {
+   rte_memcpy(actions_tx, actions,
+  sizeof(struct rte_flow_action));
+   actions_tx++;
+   } else {
+   rte_memcpy(actions_rx, actions,
+  sizeof(struct rte_flow_action));
+   actions_rx++;
+   }
+   break;
case RTE_FLOW_ACTION_TYPE_COUNT:
if (encap) {
rte_memcpy(actions_tx, actions,
-- 
2.25.1

[PATCH] common/qat: fix undefined initial slice

[Arek Kusztal]

This commit fixes undefined initial value of slice capability.
When unset it could lead to undefined read of capability due to
stack frame picked values, is should therefore be set to 0.

Fixes: b3cbbcdffa4f ("common/qat: read HW slice configuration")

Signed-off-by: Arek Kusztal 
---
 drivers/common/qat/qat_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/common/qat/qat_device.c b/drivers/common/qat/qat_device.c
index 057ba60931..8bce2ac073 100644
--- a/drivers/common/qat/qat_device.c
+++ b/drivers/common/qat/qat_device.c
@@ -361,7 +361,7 @@ static int qat_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
 {
int sym_ret = 0, asym_ret = 0, comp_ret = 0;
int num_pmds_created = 0;
-   uint16_t capa;
+   uint16_t capa = 0;
struct qat_pci_device *qat_pci_dev;
struct qat_dev_hw_spec_funcs *ops_hw;
struct qat_dev_cmd_param qat_dev_cmd_param[] = {
-- 
2.13.6

RE: [PATCH] common/qat: fix undefined initial slice

[Ji, Kai]

Acked-by: Kai Ji 

> -Original Message-
> From: Kusztal, ArkadiuszX 
> Sent: Monday, November 7, 2022 9:24 AM
> To: dev@dpdk.org
> Cc: gak...@marvell.com; Ji, Kai ; Kusztal, ArkadiuszX
> 
> Subject: [PATCH] common/qat: fix undefined initial slice
> 
> This commit fixes undefined initial value of slice capability.
> When unset it could lead to undefined read of capability due to stack frame
> picked values, is should therefore be set to 0.
> 
> Fixes: b3cbbcdffa4f ("common/qat: read HW slice configuration")
> 
> Signed-off-by: Arek Kusztal 
> ---
> 2.13.6

RE: [PATCH v2 0/3] app/testseventdev: crypto producer fixes

[Anoob Joseph]

> 
> This patch series address issues with crypto producer - correct setup
> sequence and multi stage handling with time stamp attached.
> 
> v2:
> - Split fixes into individual patches
> 
> Volodymyr Fialko (3):
>   app/testeventdev: setup crypto adapter before sessions
>   app/testeventdev: fix asymmetric last stage handling
>   app/testeventdev: fix timestamp with crypto producer
> 

Series Acked-by: Anoob Joseph 

[PATCH v2] net/mlx5/hws: fix action creation check for HWS support

[Alex Vesker]

Fix segmentation fault when a user will request to allocate
a HWS action while current device doesn't support HWS.

Fixes: f8c8a6d ("net/mlx5/hws: add action object")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_action.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c 
b/drivers/net/mlx5/hws/mlx5dr_action.c
index a9e12aa1f5..b0ae4e7693 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -697,6 +697,13 @@ mlx5dr_action_create_generic(struct mlx5dr_context *ctx,
return NULL;
}
 
+   if (mlx5dr_action_is_hws_flags(flags) &&
+   !(ctx->flags & MLX5DR_CONTEXT_FLAG_HWS_SUPPORT)) {
+   DR_LOG(ERR, "Cannot create HWS action since HWS is not 
supported");
+   rte_errno = ENOTSUP;
+   return NULL;
+   }
+
action = simple_calloc(1, sizeof(*action));
if (!action) {
DR_LOG(ERR, "Failed to allocate memory for action [%d]", 
action_type);
-- 
2.18.1

[PATCH v2] net/mlx5/hws: fix capability check to allow HWS on non esw-mngr

[Alex Vesker]

On context initialization the reparse capability support
for NIC and FDB tables was required for allowing HWS. This
caused a problem for devices that only want to run NIC
steering and are not the esw-manager fow which  FDB reparse
is disabled. Modified the check to require FDB reparse only for
esw-manager.

Fixes: b0290e5 ("net/mlx5/hws: add context object")
Signed-off-by: Alex Vesker 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_context.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_context.c 
b/drivers/net/mlx5/hws/mlx5dr_context.c
index ae86694a51..76ada7bb7f 100644
--- a/drivers/net/mlx5/hws/mlx5dr_context.c
+++ b/drivers/net/mlx5/hws/mlx5dr_context.c
@@ -108,7 +108,8 @@ static void mlx5dr_context_check_hws_supp(struct 
mlx5dr_context *ctx)
}
 
/* Current solution requires all rules to set reparse bit */
-   if ((!caps->nic_ft.reparse || !caps->fdb_ft.reparse) ||
+   if ((!caps->nic_ft.reparse ||
+(!caps->fdb_ft.reparse && caps->eswitch_manager)) ||
!IS_BIT_SET(caps->rtc_reparse_mode, MLX5_IFC_RTC_REPARSE_ALWAYS)) {
DR_LOG(INFO, "Required HWS reparse cap not supported");
return;
-- 
2.18.1

Re: [PATCH v3] app/testpmd: fix protocol header display for Rx buffer split

[Andrew Rybchenko]

On 11/7/22 11:45, Yuan Wang wrote:

The "show config rxhdrs" cmd displays the configured protocol headers
that are used for protocol-based buffer split.
However, it shows inner-ipv6 as inner-ipv4.

This patch fixes that by adjusting the order of condition judgments.
This patch also uses RTE_PTYPE_*_MASK as masks.

Fixes: 52e2e7edcf48 ("app/testpmd: add protocol-based buffer split")

Signed-off-by: Yuan Wang 

---
v3:
- use RTE_PTYPE_*_MASK as masks.
- refactor to use switch statement.
v2:
- add fixline.

---
  app/test-pmd/config.c | 89 +--
  1 file changed, 44 insertions(+), 45 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index e8a1b77c2a..8638dfed11 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -5070,73 +5070,72 @@ show_rx_pkt_segments(void)
  
  static const char *get_ptype_str(uint32_t ptype)

  {
-   if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
+   switch (ptype & (RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK)) {
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
return "ipv4-tcp";


If I map "ipv4-tcp" to packets types, I get:
RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP
but vice versa it is sufficient to have just
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_TCP
I think such asymmetry in mapping is bad.


-   else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
return "ipv4-udp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) 
==
-   (RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
return "ipv4-sctp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP)) ==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_TCP:
return "ipv6-tcp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP)) ==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_UDP:
return "ipv6-udp";
-   else if ((ptype & (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP)) 
==
-   (RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP))
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_L4_SCTP:
return "ipv6-sctp";
-   else if ((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP)
+   case RTE_PTYPE_L4_TCP:
return "tcp";
-   else if ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP)
+   case RTE_PTYPE_L4_UDP:
return "udp";
-   else if ((ptype & RTE_PTYPE_L4_SCTP) == RTE_PTYPE_L4_SCTP)
+   case RTE_PTYPE_L4_SCTP:
return "sctp";
-   else if ((ptype & RTE_PTYPE_L3_IPV4_EXT_UNKNOWN) == 
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN)
+   case RTE_PTYPE_L3_IPV4_EXT_UNKNOWN:
return "ipv4";
-   else if ((ptype & RTE_PTYPE_L3_IPV6_EXT_UNKNOWN) == 
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN)
+   case RTE_PTYPE_L3_IPV6_EXT_UNKNOWN:
return "ipv6";
-   else if ((ptype & RTE_PTYPE_L2_ETHER) == RTE_PTYPE_L2_ETHER)
+   }
+
+   switch (ptype & RTE_PTYPE_L2_MASK) {


Having many switches here looks confusing. Who defines
priorities? IMHO it should be single switch here and
values should be in exactly the same order as get_ptype().
Ideally both function should be close to each other.


+   case RTE_PTYPE_L2_ETHER:
return "eth";
+   }
  
-	else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP)) ==

-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
-   return "inner-ipv4-tcp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_UDP)) ==
-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_UDP))
-   return "inner-ipv4-udp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_SCTP)) ==
-   (RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_SCTP))
-   return "inner-ipv4-sctp";
-   else if ((ptype & (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | 
RTE_PTYPE_INNER_L4_TCP)) ==
-   (RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP))
+   switch (ptype & (RTE_PTYPE_INNER_L3_MASK | RTE_PTYPE_INNER_L4_MASK)) {
+   case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_INNER_L4_TCP:
return "inner-ipv6-tcp";


get_ptype():
inner-ipv6-tcp -> RTE_PTYPE_TUNNEL_GRENAT | RTE_PTYPE_INNER_L2_ETHER | 
RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN | RTE_PTYPE_

Re: [PATCH v2] event/cnxk: fix incorrect mbuf offset calculation

[Jerin Jacob]

On Tue, Oct 25, 2022 at 9:41 PM  wrote:
>
> From: Pavan Nikhilesh 
>
> Fix incorrect mbuf offset calculation when HEADROOM exceeds 128B
> while processing event vectors.
>
> Fixes: 7fbbc981d54f("event/cnxk: support vectorized Rx event fast path")
Cc: sta...@dpdk.org


Applied to dpdk-next-net-eventdev/for-main. Thanks

>
> Signed-off-by: Pavan Nikhilesh 
> ---
>  v2 Changes:
>  - Remove internal Change-Id.
>
>  drivers/net/cnxk/cn10k_rx.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/cnxk/cn10k_rx.h b/drivers/net/cnxk/cn10k_rx.h
> index 46488d442e..f562a75245 100644
> --- a/drivers/net/cnxk/cn10k_rx.h
> +++ b/drivers/net/cnxk/cn10k_rx.h
> @@ -1201,9 +1201,11 @@ cn10k_nix_recv_pkts_vector(void *args, struct rte_mbuf 
> **mbufs, uint16_t pkts,
> mbuf23 = vqsubq_u64(mbuf23, data_off);
> } else {
> mbuf01 =
> -   vsubq_u64(vld1q_u64((uint64_t *)cq0), 
> data_off);
> -   mbuf23 = vsubq_u64(vld1q_u64((uint64_t *)(cq0 + 16)),
> -  data_off);
> +   vsubq_u64(vld1q_u64((uint64_t *)cq0),
> + vdupq_n_u64(sizeof(struct 
> rte_mbuf)));
> +   mbuf23 =
> +   vsubq_u64(vld1q_u64((uint64_t *)(cq0 + 16)),
> + vdupq_n_u64(sizeof(struct 
> rte_mbuf)));
> }
>
> /* Move mbufs to scalar registers for future use */
> --
> 2.25.1
>

[PATCH] test/crypto: add 3DES IPsec test cases

[Aakash Sasidharan]

Add IPsec test cases for cipher algorithm 3DES.

Signed-off-by: Aakash Sasidharan 
Reviewed-by: Anoob Joseph 
---
 app/test/test_cryptodev.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 101a68f..e1122fc 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -15246,11 +15246,27 @@ static struct unit_test_suite ipsec_proto_testsuite  
= {
test_ipsec_proto_known_vec,
&pkt_des_cbc_hmac_sha512),
TEST_CASE_NAMED_WITH_DATA(
+   "Outbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA256 [16B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec, &pkt_3des_cbc_hmac_sha256),
+   TEST_CASE_NAMED_WITH_DATA(
+   "Outbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA384 [24B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec, &pkt_3des_cbc_hmac_sha384),
+   TEST_CASE_NAMED_WITH_DATA(
+   "Outbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA512 [32B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec, &pkt_3des_cbc_hmac_sha512),
+   TEST_CASE_NAMED_WITH_DATA(
"Outbound known vector (ESP tunnel mode IPv6 DES-CBC 
HMAC-SHA256 [16B ICV])",
ut_setup_security, ut_teardown,
test_ipsec_proto_known_vec,
&pkt_des_cbc_hmac_sha256_v6),
TEST_CASE_NAMED_WITH_DATA(
+   "Outbound known vector (ESP tunnel mode IPv6 3DES-CBC 
HMAC-SHA256 [16B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec, 
&pkt_3des_cbc_hmac_sha256_v6),
+   TEST_CASE_NAMED_WITH_DATA(
"Outbound known vector (AH tunnel mode IPv4 
HMAC-SHA256)",
ut_setup_security, ut_teardown,
test_ipsec_proto_known_vec,
@@ -15340,11 +15356,27 @@ static struct unit_test_suite ipsec_proto_testsuite  
= {
test_ipsec_proto_known_vec_inb,
&pkt_des_cbc_hmac_sha512),
TEST_CASE_NAMED_WITH_DATA(
+   "Inbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA256 [16B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec_inb, 
&pkt_3des_cbc_hmac_sha256),
+   TEST_CASE_NAMED_WITH_DATA(
+   "Inbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA384 [24B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec_inb, 
&pkt_3des_cbc_hmac_sha384),
+   TEST_CASE_NAMED_WITH_DATA(
+   "Inbound known vector (ESP tunnel mode IPv4 3DES-CBC 
HMAC-SHA512 [32B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec_inb, 
&pkt_3des_cbc_hmac_sha512),
+   TEST_CASE_NAMED_WITH_DATA(
"Inbound known vector (ESP tunnel mode IPv6 DES-CBC 
HMAC-SHA256 [16B ICV])",
ut_setup_security, ut_teardown,
test_ipsec_proto_known_vec_inb,
&pkt_des_cbc_hmac_sha256_v6),
TEST_CASE_NAMED_WITH_DATA(
+   "Inbound known vector (ESP tunnel mode IPv6 3DES-CBC 
HMAC-SHA256 [16B ICV])",
+   ut_setup_security, ut_teardown,
+   test_ipsec_proto_known_vec_inb, 
&pkt_3des_cbc_hmac_sha256_v6),
+   TEST_CASE_NAMED_WITH_DATA(
"Inbound known vector (AH tunnel mode IPv4 
HMAC-SHA256)",
ut_setup_security, ut_teardown,
test_ipsec_proto_known_vec_inb,
-- 
2.7.4

[PATCH] app/testpmd: fix flow list for async flows

[Alexander Kozyrev]

Flows created with the new asynchronous Flow API lack attributes
(direction, priority, group number). These attributes are part of
a template table for flows created via rte_flow_async_create().

When testpmd tries to list all the flows it accesses flow
attributes via pointer and crashes. Save flow attributes during
the template table creation and use them in the "flow list" output.

Fixes: ecdc927b99 ("app/testpmd: add async flow create/destroy operations")

Signed-off-by: Alexander Kozyrev 
---
 app/test-pmd/config.c  | 5 +++--
 app/test-pmd/testpmd.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index e8a1b77c2a..cc86d9af5f 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2448,6 +2448,8 @@ port_flow_template_table_create(portid_t port_id, 
uint32_t id,
}
pt->nb_pattern_templates = nb_pattern_templates;
pt->nb_actions_templates = nb_actions_templates;
+   rte_memcpy(&pt->flow_attr, &table_attr->flow_attr,
+  sizeof(struct rte_flow_attr));
printf("Template table #%u created\n", pt->id);
return 0;
 }
@@ -2510,7 +2512,6 @@ port_queue_flow_create(portid_t port_id, queueid_t 
queue_id,
   const struct rte_flow_action *actions)
 {
struct rte_flow_op_attr op_attr = { .postpone = postpone };
-   struct rte_flow_attr flow_attr = { 0 };
struct rte_flow *flow;
struct rte_port *port;
struct port_flow *pf;
@@ -2570,7 +2571,7 @@ port_queue_flow_create(portid_t port_id, queueid_t 
queue_id,
}
job->type = QUEUE_JOB_TYPE_FLOW_CREATE;
 
-   pf = port_flow_new(&flow_attr, pattern, actions, &error);
+   pf = port_flow_new(&pt->flow_attr, pattern, actions, &error);
if (!pf) {
free(job);
return port_flow_complain(&error);
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 93fdb9d331..248da710a3 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -204,6 +204,7 @@ struct port_table {
uint32_t id; /**< Table ID. */
uint32_t nb_pattern_templates; /**< Number of pattern templates. */
uint32_t nb_actions_templates; /**< Number of actions templates. */
+   struct rte_flow_attr flow_attr; /**< Flow attributes. */
struct rte_flow_template_table *table; /**< PMD opaque template object 
*/
 };
 
-- 
2.18.2

Re: [PATCH] app/testeventdev: fix limit names in error message

[Jerin Jacob]

On Thu, Nov 3, 2022 at 9:02 PM Pavan Nikhilesh Bhagavatula
 wrote:
>
>
>
> > -Original Message-
> > From: Volodymyr Fialko 
> > Sent: Monday, October 31, 2022 4:09 PM
> > To: dev@dpdk.org
> > Cc: Jerin Jacob Kollanukkaran ; Akhil Goyal
> > ; Anoob Joseph ; Pavan
> > Nikhilesh Bhagavatula ; Volodymyr Fialko
> > 
> > Subject: [PATCH] app/testeventdev: fix limit names in error message
> >
> > Swap min and max values to match their labels.
> >
> > Fixes: 2eaa37b8663 ("app/eventdev: add vector mode in pipeline test")
> >
> > Signed-off-by: Volodymyr Fialko 
>
> Acked-by: Pavan Nikhilesh 


Applied to dpdk-next-net-eventdev/for-main. Thanks


>
> > ---
> >  app/test-eventdev/test_pipeline_common.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-eventdev/test_pipeline_common.c b/app/test-
> > eventdev/test_pipeline_common.c
> > index ab39046ce7..5229d74fe0 100644
> > --- a/app/test-eventdev/test_pipeline_common.c
> > +++ b/app/test-eventdev/test_pipeline_common.c
> > @@ -534,8 +534,8 @@ pipeline_event_rx_adapter_setup(struct evt_options
> > *opt, uint8_t stride,
> >   if (opt->vector_size < limits.min_sz ||
> >   opt->vector_size > limits.max_sz) {
> >   evt_err("Vector size [%d] not within limits
> > max[%d] min[%d]",
> > - opt->vector_size, limits.min_sz,
> > - limits.max_sz);
> > + opt->vector_size, limits.max_sz,
> > + limits.min_sz);
> >   return -EINVAL;
> >   }
> >
> > --
> > 2.25.1
>

Re: [PATCH] event/dlb2: fix meson build

[Jerin Jacob]

On Fri, Nov 4, 2022 at 4:30 PM Jerin Jacob  wrote:
>
> On Thu, Nov 3, 2022 at 9:52 PM Ferruh Yigit  wrote:
> >
> > On 11/3/2022 3:35 PM, Thomas Monjalon wrote:
> > > 03/11/2022 16:22, Ferruh Yigit:
> > >> "meson setup" fails when '-Werror' compiler flag is enabled [1].
> > >> This is not a build error in the driver but a build error in meson
> > >> during "meson setup" stage.
> > >>
> > >> This issue exists for a while but meson takes it as a warning and
> > >> ignores it unless '-Werror' compiler flag is provided.
> > > [...]
> > >> Reproduced via `meson -Dc_args='-Werror' build`
> > >
> > > Is it different of 'meson --werror" as in devtools/test-meson-builds.sh
> > > or 'meson -Dwerror=true' as in .ci/linux-build.sh?
> > >
> >
> > As I checked now, it seems there is a difference.
> >
> > Via "meson --werror" & "meson -Dwerror=true",
> > '-Werror' flag is used to compile dpdk source code, but meson doesn't
> > use the flag for its internal logic, so this seems more proper usage.
> >
> > Via "meson -Dc_args='-Werror'" & "CFLAGS='-Werror' meson" usage,
> > '-Werror' flag is used both to compile dpdk code and meson internal
> > logic, so that is why this usage cause build error.
> >
> >
> > And independent from the above usage difference, event/dlb2 meson file
> > is wrong and this fix is required.
> > I assume 'dlb2_avx512.c' compiled because of the '-mavx512vl' fallback
> > and that is why mentioned error is not detected.
>
> + @abdullah.sevin...@intel.com
>
> Waiting from Ack from Abdullah to merge

No reply. Patch looks reasonable to me.

Applied to dpdk-next-net-eventdev/for-main. Thanks

RE: [RFC]: mempool: zero-copy cache get bulk

[Morten Brørup]

+ Akshitha, apparently working on similar patches

> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Monday, 7 November 2022 10.19
> 
> On Sat, Nov 05, 2022 at 02:19:13PM +0100, Morten Brørup wrote:
> > Zero-copy access to the mempool cache is beneficial for PMD
> performance, and must be provided by the mempool library to fix [Bug
> 1052] without a performance regression.
> >
> > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> >
> >
> > This RFC offers two conceptual variants of zero-copy get:
> > 1. A simple version.
> > 2. A version where existing (hot) objects in the cache are moved to
> the top of the cache before new objects from the backend driver are
> pulled in.
> >
> > I would like some early feedback. Also, which variant do you prefer?
> >
> > Notes:
> > * Allowing the 'cache' parameter to be NULL, and getting it from the
> mempool instead, was inspired by rte_mempool_cache_flush().
> > * Asserting that the 'mp' parameter is not NULL is not done by other
> functions, so I omitted it here too.
> >
> > NB: Please ignore formatting. Also, this code has not even been
> compile tested.
> >
> >
> > PS: No promises, but I expect to offer an RFC for zero-copy put too.
> :-)
> >
> 
> Thanks for this work, I think it's good to have. The existing functions
> could probably be reworked to use this new code too, right, since the
> copy
> at the end would be all that is needed to complete the implementation?

Only for the likely case, where the request can be fulfilled entirely from the 
cache.

Not for the corner case, where only some of the objects are in the cache, so 
the cache needs to be refilled from the backing store.

E.g. requesting 32 objects, and 8 objects are in the cache. (Those 8 object are 
assumed to be hot, as opposed to the cold objects pulled in from the backing 
store, and were given preferential treatment with commit 
[a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0].)

[a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0]: 
http://git.dpdk.org/dpdk/commit/lib/mempool/rte_mempool.h?id=a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0

The existing function copies the 8 existing objects directly to the final 
destination, then refills the cache from the backing store, and then copies the 
remaining 24 objects directly to the final destination.

The "2. variant" in this RFC handles this corner case by moving the 8 objects 
in the cache to the new top of the cache, and then refilling the cache from the 
backing store. And it can only move those 8 objects around in the cache if 
there is room for them. (The 32 returned objects are, ordered from top to 
bottom of the stack: 8 hot and 24 new.)

On other words: If we replaced the existing function with this function plus 
copying at the end, the corner case will perform additional copying (moving the 
objects around in the stack), whereas the existing function only copies each 
object once.

While I usually agree 100 % about avoiding code duplication, I think the 
difference in behavior between the existing and the new functions warrants two 
separate implementations.


Please also note: The cache is a stack, so when accessing the cache directly, 
objects should be retrieved in reverse order. (This should be mentioned in the 
function description!) The existing function reverses the order of the objects 
when returning them, so the application can use them in normal order.

> 
> Only real comment I have on this version is that I am not sure about
> the
> naming. I think having "cache_get_bulk" doesn't really make it very
> clear
> what the function does, that is removes items from the cache without
> copying them elsewhere. How about:
> 
> - rte_mempool_cache_pop?
> - rte_mempool_cache_reserve?
> 
> I would tend to prefer the former, since the latter implies that there
> needs to be a follow-up call to clear the reservation. On the other
> hand,
> reserve does give the correct impression that the elements are still
> there
> in the mempool cache.
> 
> Others may have better suggestions, since, as we know, naming things is
> hard! :)

- rte_mempool_cache_prefetch_bulk?
- rte_mempool_cache_get_bulk_promise?

When I came up with the function name rte_mempool_cache_put_bulk_promise for 
the sister function [1], I thought along the same lines as you, Bruce. It is 
important that the function name doesn't imply that there is a follow-up 
function to indicate that the transaction has been completed. (Before working 
on that, I assumed that a "prepare" and "commit" pair of functions were 
required, but the function turned out to be much simpler than anticipated.)

[1]: 
http://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35d87...@smartserver.smartshare.dk/#t

The mempool library offers single-object functions, so _bulk should be part of 
the function name, to indicate that the function operates on more than one 
object.

> 
> Overall, though, I think this is very good to have.
> /Bruce

RE: [PATCH v2] examples/fips_validation: fix typo

[Dooley, Brian]

Hi Pablo,

> -Original Message-
> From: De Lara Guarch, Pablo 
> Sent: Monday, November 7, 2022 10:04 AM
> To: Dooley, Brian 
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> Kovacevic, Marko ; sta...@dpdk.org
> Subject: [PATCH v2] examples/fips_validation: fix typo
> 
> Digest length is being printed out, not IV length.
> 
> Fixes: ac026f4668d0 ("examples/fips_validation: support CMAC parsing")
> Fixes: f64adb6714e0 ("examples/fips_validation: support HMAC parsing")
> Cc: marko.kovace...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Pablo de Lara 
> ---
> -v2: added missing "Signed-off"
> ---
> 
>  examples/fips_validation/main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/examples/fips_validation/main.c
> b/examples/fips_validation/main.c index 404a29d7b6..9a9babb53a 100644
> --- a/examples/fips_validation/main.c
> +++ b/examples/fips_validation/main.c
> @@ -1210,7 +1210,7 @@ prepare_hmac_xform(struct
> rte_crypto_sym_xform *xform)
>   if (rte_cryptodev_sym_capability_check_auth(cap,
>   auth_xform->key.length,
>   auth_xform->digest_length, 0) != 0) {
> - RTE_LOG(ERR, USER1, "PMD %s key length %u IV length
> %u\n",
> + RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length
> %u\n",
>   info.device_name, auth_xform->key.length,
>   auth_xform->digest_length);
>   return -EPERM;
> @@ -1339,7 +1339,7 @@ prepare_cmac_xform(struct
> rte_crypto_sym_xform *xform)
>   if (rte_cryptodev_sym_capability_check_auth(cap,
>   auth_xform->key.length,
>   auth_xform->digest_length, 0) != 0) {
> - RTE_LOG(ERR, USER1, "PMD %s key length %u IV length
> %u\n",
> + RTE_LOG(ERR, USER1, "PMD %s key length %u Digest length
> %u\n",
>   info.device_name, auth_xform->key.length,
>   auth_xform->digest_length);
>   return -EPERM;
> --
> 2.34.1

Reviewed-by: Brian Dooley 

[PATCH] common/mlx5: use build configuration dictionary

[Thomas Monjalon]

A recent commit added an explicit dependency check on common/mlx5.
For consistency, query dpdk_conf instead of the list of common drivers.
The lists *_drivers should be used only for printing.

Fixes: 3df380f61797 ("common/mlx5: fix disabling build")

Suggested-by: Bruce Richardson 
Signed-off-by: Thomas Monjalon 
---
 drivers/compress/mlx5/meson.build | 2 +-
 drivers/crypto/mlx5/meson.build   | 2 +-
 drivers/net/mlx5/meson.build  | 2 +-
 drivers/regex/mlx5/meson.build| 2 +-
 drivers/vdpa/mlx5/meson.build | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/compress/mlx5/meson.build 
b/drivers/compress/mlx5/meson.build
index 49ce3aff46..df4f79fa7e 100644
--- a/drivers/compress/mlx5/meson.build
+++ b/drivers/compress/mlx5/meson.build
@@ -9,7 +9,7 @@ endif
 
 fmt_name = 'mlx5_compress'
 deps += ['common_mlx5', 'eal', 'compressdev']
-if not ('mlx5' in common_drivers)
+if not dpdk_conf.has('RTE_COMMON_MLX5')
 # avoid referencing undefined variables from common/mlx5
 subdir_done()
 endif
diff --git a/drivers/crypto/mlx5/meson.build b/drivers/crypto/mlx5/meson.build
index 7521c4c671..7e32095695 100644
--- a/drivers/crypto/mlx5/meson.build
+++ b/drivers/crypto/mlx5/meson.build
@@ -9,7 +9,7 @@ endif
 
 fmt_name = 'mlx5_crypto'
 deps += ['common_mlx5', 'eal', 'cryptodev']
-if not ('mlx5' in common_drivers)
+if not dpdk_conf.has('RTE_COMMON_MLX5')
 # avoid referencing undefined variables from common/mlx5
 subdir_done()
 endif
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index f1aab18f82..abd507bd88 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -9,7 +9,7 @@ if not (is_linux or is_windows)
 endif
 
 deps += ['hash', 'common_mlx5']
-if not ('mlx5' in common_drivers)
+if not dpdk_conf.has('RTE_COMMON_MLX5')
 # avoid referencing undefined variables from common/mlx5
 subdir_done()
 endif
diff --git a/drivers/regex/mlx5/meson.build b/drivers/regex/mlx5/meson.build
index 70edc5b6da..87404101b9 100644
--- a/drivers/regex/mlx5/meson.build
+++ b/drivers/regex/mlx5/meson.build
@@ -8,7 +8,7 @@ if not is_linux
 endif
 
 deps += ['common_mlx5', 'eal', 'regexdev']
-if not ('mlx5' in common_drivers)
+if not dpdk_conf.has('RTE_COMMON_MLX5')
 # avoid referencing undefined variables from common/mlx5
 subdir_done()
 endif
diff --git a/drivers/vdpa/mlx5/meson.build b/drivers/vdpa/mlx5/meson.build
index 54a4eac6f4..e224d1bcc9 100644
--- a/drivers/vdpa/mlx5/meson.build
+++ b/drivers/vdpa/mlx5/meson.build
@@ -8,7 +8,7 @@ if not is_linux
 endif
 
 deps += ['hash', 'common_mlx5', 'vhost', 'pci', 'eal', 'sched']
-if not ('mlx5' in common_drivers)
+if not dpdk_conf.has('RTE_COMMON_MLX5')
 # avoid referencing undefined variables from common/mlx5
 subdir_done()
 endif
-- 
2.36.1

Re: [PATCH] common/mlx5: use build configuration dictionary

[Bruce Richardson]

On Mon, Nov 07, 2022 at 05:37:20PM +0100, Thomas Monjalon wrote:
> A recent commit added an explicit dependency check on common/mlx5.
> For consistency, query dpdk_conf instead of the list of common drivers.
> The lists *_drivers should be used only for printing.
> 
> Fixes: 3df380f61797 ("common/mlx5: fix disabling build")
> 
> Suggested-by: Bruce Richardson 
> Signed-off-by: Thomas Monjalon 
> ---
Acked-by: Bruce Richardson 

[PATCH] maintainers: update for pmdinfo tool

[Thomas Monjalon]

The original maintainer of pmdinfo/pmdinfogen
did not send an email for 2 years.

Signed-off-by: Thomas Monjalon 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2ddb7cfa88..fa688516dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -136,7 +136,6 @@ F: .github/workflows/build.yml
 F: .ci/
 
 Driver information
-M: Neil Horman 
 M: Dmitry Kozlyuk 
 F: buildtools/coff.py
 F: buildtools/gen-pmdinfo-cfile.py
-- 
2.36.1

[PATCH] maintainers: group service cores files

[Thomas Monjalon]

Move example with library files, all with the same maintainer.

Signed-off-by: Thomas Monjalon 
---
 MAINTAINERS | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 45582f37f0..f0d13f6572 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -233,6 +233,8 @@ F: lib/eal/include/rte_service_component.h
 F: lib/eal/common/rte_service.c
 F: doc/guides/prog_guide/service_cores.rst
 F: app/test/test_service_cores.c
+F: examples/service_cores/
+F: doc/guides/sample_app_ug/service_cores.rst
 
 Bitops
 M: Joyce Kong 
@@ -1825,11 +1827,6 @@ M: John McNamara 
 F: examples/rxtx_callbacks/
 F: doc/guides/sample_app_ug/rxtx_callbacks.rst
 
-Service cores example
-M: Harry van Haaren 
-F: examples/service_cores/
-F: doc/guides/sample_app_ug/service_cores.rst
-
 Skeleton example
 M: Bruce Richardson 
 M: John McNamara 
-- 
2.36.1

Re: [PATCH] event/cnxk: fix missing mempool cookie marking

[Jerin Jacob]

On Thu, Nov 3, 2022 at 9:46 PM  wrote:
>
> From: Pavan Nikhilesh 
>
> Mark chunks mempool objects as "put" as they are freed to NPA
> automatically when they are parsed by TIM HW.
>
> Fixes: 300b796262a1 ("event/cnxk: add timer arm routine")
>
> Signed-off-by: Pavan Nikhilesh 

Applied to dpdk-next-net-eventdev/for-main. Thanks


> ---
>  drivers/event/cnxk/cnxk_tim_worker.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/event/cnxk/cnxk_tim_worker.h 
> b/drivers/event/cnxk/cnxk_tim_worker.h
> index 8d8ed1d3a1..eda84c6f31 100644
> --- a/drivers/event/cnxk/cnxk_tim_worker.h
> +++ b/drivers/event/cnxk/cnxk_tim_worker.h
> @@ -217,6 +217,7 @@ cnxk_tim_insert_chunk(struct cnxk_tim_bkt *const bkt,
> if (unlikely(rte_mempool_get(tim_ring->chunk_pool, (void **)&chunk)))
> return NULL;
>
> +   RTE_MEMPOOL_CHECK_COOKIES(tim_ring->chunk_pool, (void **)&chunk, 1, 
> 0);
> *(uint64_t *)(chunk + tim_ring->nb_chunk_slots) = 0;
> if (bkt->nb_entry) {
> *(uint64_t *)(((struct cnxk_tim_ent *)(uintptr_t)
> --
> 2.25.1
>

Re: [PATCH v2 0/3] app/testseventdev: crypto producer fixes

[Jerin Jacob]

On Mon, Nov 7, 2022 at 4:31 PM Anoob Joseph  wrote:
>
> >
> > This patch series address issues with crypto producer - correct setup
> > sequence and multi stage handling with time stamp attached.
> >
> > v2:
> > - Split fixes into individual patches
> >
> > Volodymyr Fialko (3):
> >   app/testeventdev: setup crypto adapter before sessions
> >   app/testeventdev: fix asymmetric last stage handling
> >   app/testeventdev: fix timestamp with crypto producer
> >
>
> Series Acked-by: Anoob Joseph 


Series applied to dpdk-next-net-eventdev/for-main. Thanks

>
>

Question about naive XOR hash in DPDK

[Bili Dong]

Dear DPDK devs,

We are using DPDK as the backend target of a P4 pipeline (
https://github.com/p4lang/p4-dpdk-target). A recent issue we are trying to
solve is to support a naive XOR hash (something like this
)
in this pipeline. This requires an XOR hash implementation in DPDK. I have
the following questions:

   1. Is there already an XOR hash implementation in DPDK? I haven't found
   it myself, but I could have missed it.
   2. If it doesn't exist, I'm willing to contribute one, as the
   implementation is quite straightforward. But I might need your help on
   where to put the code, as I'm not that familiar with the code organization.

Any help would be appreciated!

Thanks,
Bili

[RFC] mempool: add API to return pointer to free space on per-core cache

[Kamalakshitha Aligeri]

Expose the pointer to free space in per core cache in PMD, so that the
objects can be directly copied to cache without any temporary storage

Signed-off-by: Kamalakshitha Aligeri 
---
Pending Work:
1. Internal review needs to be done. 
2. Make the changes in i40e_tx_free_bufs_avx512

 app/test/test_mempool.c | 146 
 drivers/net/i40e/i40e_rxtx_vec_common.h |  23 +++-
 lib/mempool/rte_mempool.h   |  34 ++
 3 files changed, 198 insertions(+), 5 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 8e493eda47..889d8f5d5c 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -187,6 +187,148 @@ test_mempool_basic(struct rte_mempool *mp, int 
use_external_cache)
return ret;
 }
 
+/* basic tests (done on one core) */
+static int
+test_mempool_get_cache(struct rte_mempool *mp, int use_external_cache)
+{
+   uint32_t *objnum;
+   void **objtable;
+   void *obj, *obj2;
+   char *obj_data;
+   int ret = 0;
+   unsigned i, j;
+   int offset;
+   struct rte_mempool_cache *cache;
+   void **cache_objs;
+
+   if (use_external_cache) {
+   /* Create a user-owned mempool cache. */
+   cache = rte_mempool_cache_create(RTE_MEMPOOL_CACHE_MAX_SIZE,
+SOCKET_ID_ANY);
+   if (cache == NULL)
+   RET_ERR();
+   } else {
+   /* May be NULL if cache is disabled. */
+   cache = rte_mempool_default_cache(mp, rte_lcore_id());
+   }
+
+   /* dump the mempool status */
+   rte_mempool_dump(stdout, mp);
+
+   printf("get an object\n");
+   if (rte_mempool_generic_get(mp, &obj, 1, cache) < 0)
+   GOTO_ERR(ret, out);
+   rte_mempool_dump(stdout, mp);
+
+   /* tests that improve coverage */
+   printf("get object count\n");
+   /* We have to count the extra caches, one in this case. */
+   offset = use_external_cache ? 1 * cache->len : 0;
+   if (rte_mempool_avail_count(mp) + offset != MEMPOOL_SIZE - 1)
+   GOTO_ERR(ret, out);
+
+   printf("get private data\n");
+   if (rte_mempool_get_priv(mp) != (char *)mp +
+   RTE_MEMPOOL_HEADER_SIZE(mp, mp->cache_size))
+   GOTO_ERR(ret, out);
+
+#ifndef RTE_EXEC_ENV_FREEBSD /* rte_mem_virt2iova() not supported on bsd */
+   printf("get physical address of an object\n");
+   if (rte_mempool_virt2iova(obj) != rte_mem_virt2iova(obj))
+   GOTO_ERR(ret, out);
+#endif
+
+
+   printf("put the object back\n");
+   cache_objs = rte_mempool_get_cache(mp,1);
+   if (cache_objs != NULL) {
+   rte_memcpy(cache_objs, &obj, sizeof(void*));
+   }
+   else {
+   rte_mempool_ops_enqueue_bulk(mp, &obj, 1);
+   }
+
+   rte_mempool_dump(stdout, mp);
+
+   printf("get 2 objects\n");
+   if (rte_mempool_generic_get(mp, &obj, 1, cache) < 0)
+   GOTO_ERR(ret, out);
+   if (rte_mempool_generic_get(mp, &obj2, 1, cache) < 0) {
+   rte_mempool_generic_put(mp, &obj, 1, cache);
+   GOTO_ERR(ret, out);
+   }
+   rte_mempool_dump(stdout, mp);
+
+   printf("put the objects back\n");
+   cache_objs = rte_mempool_get_cache(mp,1);
+   if (cache_objs != NULL) {
+   rte_memcpy(mp, &obj, sizeof(void *));
+   }
+   else {
+   rte_mempool_ops_enqueue_bulk(mp, &obj, 1);
+   }
+   cache_objs = rte_mempool_get_cache(mp,1);
+   if (cache_objs != NULL) {
+   rte_memcpy(mp, &obj2, sizeof(void *));
+   }
+   else {
+   rte_mempool_ops_enqueue_bulk(mp, &obj2, 1);
+   }
+   rte_mempool_dump(stdout, mp);
+
+   /*
+* get many objects: we cannot get them all because the cache
+* on other cores may not be empty.
+*/
+   objtable = malloc(MEMPOOL_SIZE * sizeof(void *));
+   if (objtable == NULL)
+   GOTO_ERR(ret, out);
+
+   for (i = 0; i < MEMPOOL_SIZE; i++) {
+   if (rte_mempool_generic_get(mp, &objtable[i], 1, cache) < 0)
+   break;
+   }
+
+   /*
+* for each object, check that its content was not modified,
+* and put objects back in pool
+*/
+   cache_objs = rte_mempool_get_cache (mp, MEMPOOL_SIZE);
+   if (cache_objs != NULL) {
+   while (i--) {
+   obj = objtable[i];
+   obj_data = obj;
+   objnum = obj;
+   if (*objnum > MEMPOOL_SIZE) {
+   printf("bad object number(%d)\n", *objnum);
+   ret = -1;
+   break;
+   }
+   for (j = sizeof(*objnum); j < mp->elt_size; j++) {
+   if (obj_data[j] !=

[PATCH v1 1/1] baseband/acc100: fix to input error related to padding

[Nicolas Chautru]

Previous commit includes some padding for some cases,
which may cause input warning from the HW
which should be safely ignored to avoid false alarm.

Fixes: 6f3325bbfa ("baseband/acc100: add LDPC encoder padding function")

Signed-off-by: Nicolas Chautru 
---
 drivers/baseband/acc/rte_acc100_pmd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/baseband/acc/rte_acc100_pmd.c 
b/drivers/baseband/acc/rte_acc100_pmd.c
index 96daef87bc..ba8247d47e 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -3779,7 +3779,6 @@ dequeue_enc_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
/* Clearing status, it will be set based on response */
op->status = 0;
 
-   op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
 
@@ -3853,8 +3852,6 @@ dequeue_enc_one_op_tb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
rte_bbdev_log_debug("Resp. desc %p: %x descs %d cbs %d\n",
desc, rsp.val, descs_in_tb, desc->req.numCBs);
 
-   op->status |= ((rsp.input_err)
-   ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
 
-- 
2.37.1

[PATCH v1 0/1] baseband/acc100: fix for RC2

[Nicolas Chautru]

Bug introduced in 22.11. The change to padding can lead to
reporting input size mismatch which is not a problem and
should not be considered as an error.

Nicolas Chautru (1):
  baseband/acc100: fix to input error related to padding

 drivers/baseband/acc/rte_acc100_pmd.c | 3 ---
 1 file changed, 3 deletions(-)

-- 
2.37.1

RE: [PATCH v12 04/16] baseband/acc: introduce PMD for ACC200

[Chautru, Nicolas]

Hi Thomas, 
Reminder : do you mind kindly clarifying/confirming below. Then we can update 
the docs accordingly. Thanks. 

> -Original Message-
> From: Chautru, Nicolas
> Sent: Monday, October 31, 2022 2:41 PM
> To: Thomas Monjalon 
> Cc: dev@dpdk.org; gak...@marvell.com; maxime.coque...@redhat.com;
> t...@redhat.com; Richardson, Bruce ;
> hemant.agra...@nxp.com; david.march...@redhat.com;
> step...@networkplumber.org; Vargas, Hernan 
> Subject: RE: [PATCH v12 04/16] baseband/acc: introduce PMD for ACC200
> 
> Hi Thomas,
> 
> > -Original Message-
> > From: Thomas Monjalon 
> > 31/10/2022 16:43, Chautru, Nicolas:
> > > From: Thomas Monjalon 
> > > > 12/10/2022 19:59, Nicolas Chautru:
> > > > > +Bind PF UIO driver(s)
> > > > > +~
> > > > > +
> > > > > +Install the DPDK igb_uio driver, bind it with the PF PCI device
> > > > > +ID and use ``lspci`` to confirm the PF device is under use by
> > > > > +``igb_uio`` DPDK
> > > > UIO driver.
> > > >
> > > > igb_uio is not recommended.
> > > > Please focus on VFIO first.
> > > >
> > > > > +The igb_uio driver may be bound to the PF PCI device using one
> > > > > +of two methods for ACC200:
> > > > > +
> > > > > +
> > > > > +1. PCI functions (physical or virtual, depending on the use
> > > > > +case) can be bound to the UIO driver by repeating this command
> > > > > +for every
> > function.
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +  cd   insmod ./build/kmod/igb_uio.ko
> > > > > + echo "8086 57c0" > /sys/bus/pci/drivers/igb_uio/new_id
> > > > > +  lspci -vd8086:57c0
> > > > > +
> > > > > +
> > > > > +2. Another way to bind PF with DPDK UIO driver is by using the
> > > > > +``dpdk-devbind.py`` tool
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +  cd   ./usertools/dpdk-devbind.py -b
> > > > > + igb_uio :f7:00.0
> > > > > +
> > > > > +where the PCI device ID (example: :f7:00.0) is obtained
> > > > > +using lspci -vd8086:57c0
> > > >
> > > > This binding is not specific to the driver.
> > > > It would be better to refer to the Linux guide instead of
> > > > duplicating it again and again.
> > > >
> > > > > +In a similar way the PF may be bound with vfio-pci as any PCIe 
> > > > > device.
> > > >
> > > > You could mention igb_uio here.
> > > > Is there any advantage in using igb_uio?
> > > >
> > >
> > > Igb_uio is arguably easier to use to new user tend to start with it
> > > or specific
> > ecosystem. This is typically the entry point (no iommu, no flr below
> > the bonnet, no vfio token...) hence good to have a bit of handholding
> > with a couple of lines capturing how to easily run a few tests. I
> > don't believe this is too redundant to have these few lines compared
> > to the help in bring to the user not having to double guess their steps.
> > > More generally there are a number of module drivers combinations
> > > that are
> > supported based on different deployments. We don't document in too
> > much details for the details since that is not too ACC specific and
> > there is more documentation no pf_bb_config repo for using the PMD from
> the VF..
> > >
> > > Basically Thomas let us know more explicitly what you are suggesting
> > > as
> > documentation update. You just want more emphasis on vfio-pci flow
> > (which is fair, some of it documented on pf_bb_config including the
> > vfio token passing but we can reproduce here as well) or something else?
> >
> > There are 2 things to change:
> > 1/ igb_uio is going to be deprecated, so we must emphasize on VFIO
> 
> Is there a date for deprecation? Do you mean to EOL the dpdk-kmods
> repository itself; or something more specific for DPDK code like removing
> RTE_PCI_KDRV_IGB_UIO; or last to just take out from documentation?
> It tends to be historical but uio has value notably for ease of use.
> 
> 2/ for doc
> > maintenance, it is better to have common steps described in one place.
> > If needed, you can change the common doc and refer to it.
> 
> Do you mean to remove these sections and just add a pointer to
> https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html instead in all these
> bbdev PMDS?
> Please kindly confirm. I see specific steps for binding in many other PMDs 
> docs
> in DPDK, a bit redundant but provides simple steps specific to a PMD in one
> place. I don't mind either way.
> 
> Thanks
> Nic
> 

RE: [PATCH] net/ixgbe: fix error of drop queue index

[Zhang, Qi Z]

> -Original Message-
> From: kevin-intel 
> Sent: Monday, November 7, 2022 4:49 PM
> To: dev@dpdk.org
> Cc: Zhou, YidingX ; Deng, KaiwenX
> ; Yang, Qiming ; Wu,
> Wenjun1 ; Andrew Rybchenko
> ; Dongdong Liu
> 
> Subject: [PATCH] net/ixgbe: fix error of drop queue index
> 
> The drop queue index was not set when adding internal Flow Director
> Configuration copy in ixgbe device private data.
> Therefore dropped packets would be received by queue 0 which is set to
> drop queue.
> 
> This commit sets drop queue index as IXGBE_FDIR_DROP_QUEUE to fix this
> issue.
> 
> Fixes: 5007ac13189d ("ethdev: remove deprecated Flow Director
> configuration")
> 
> Signed-off-by: kevin-intel 

No need to add company name in your signed-off name.
I assume it should be 
Kaiwen Deng 

> ---
>  drivers/net/ixgbe/ixgbe_flow.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
> index 1250c2dc12..110ff34fcc 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -2759,6 +2759,7 @@ ixgbe_parse_fdir_filter(struct rte_eth_dev *dev,
>   int ret;
>   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
>   struct rte_eth_fdir_conf *fdir_conf = IXGBE_DEV_FDIR_CONF(dev);
> + fdir_conf->drop_queue = IXGBE_FDIR_DROP_QUEUE;

The expected drop action is to drop packet, there is NO "drop queue" in the 
generic flow APIs
if you want to steer packet to queue 0, just use rte_flow_action_queue with 
queue 0
What's the gap?

> 
>   if (hw->mac.type != ixgbe_mac_82599EB &&
>   hw->mac.type != ixgbe_mac_X540 &&
> --
> 2.34.1

RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling

[Xia, Chenbo]

> -Original Message-
> From: Taekyung Kim 
> Sent: Monday, November 7, 2022 5:00 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Xia, Chenbo
> ; Wang, Xiao W ;
> kim.tae.ky...@navercorp.com
> Subject: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> 
> Stop and return the error code when update_datapath fails.
> update_datapath prepares resources for the vdpa device.
> The driver should not perform any further actions
> if update_datapath returns an error.
> 
> Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Taekyung Kim 
> ---
> v3:
> * Fix coding style
> 
> v2:
> * Revert the prepared resources before returning an error
> * Rebase to 22.11 rc2
> * Add fixes and cc for backport
> 
> ---
>  drivers/vdpa/ifc/ifcvf_vdpa.c | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
> index 8dfd49336e..0396d49122 100644
> --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> @@ -1098,7 +1098,12 @@ ifcvf_dev_config(int vid)
>   internal = list->internal;
>   internal->vid = vid;
>   rte_atomic32_set(&internal->dev_attached, 1);
> - update_datapath(internal);
> + if (update_datapath(internal) < 0) {
> + DRV_LOG(ERR, "failed to update datapath for vDPA device %s",
> + vdev->device->name);
> + rte_atomic32_set(&internal->dev_attached, 0);
> + return -1;
> + }
> 
>   hw = &internal->hw;
>   for (i = 0; i < hw->nr_vring; i++) {
> @@ -1146,7 +1151,12 @@ ifcvf_dev_close(int vid)
>   internal->sw_fallback_running = false;
>   } else {
>   rte_atomic32_set(&internal->dev_attached, 0);
> - update_datapath(internal);
> + if (update_datapath(internal) < 0) {
> + DRV_LOG(ERR, "failed to update datapath for vDPA
> device %s",
> + vdev->device->name);
> + internal->configured = 0;
> + return -1;
> + }
>   }
> 
>   internal->configured = 0;
> @@ -1752,7 +1762,14 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv
> __rte_unused,
>   }
> 
>   rte_atomic32_set(&internal->started, 1);
> - update_datapath(internal);
> + if (update_datapath(internal) < 0) {
> + DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> + rte_atomic32_set(&internal->started, 0);
> + pthread_mutex_lock(&internal_list_lock);
> + TAILQ_REMOVE(&internal_list, list, next);
> + pthread_mutex_unlock(&internal_list_lock);
> + goto error;
> + }
> 
>   rte_kvargs_free(kvlist);
>   return 0;
> @@ -1781,7 +1798,8 @@ ifcvf_pci_remove(struct rte_pci_device *pci_dev)
> 
>   internal = list->internal;
>   rte_atomic32_set(&internal->started, 0);
> - update_datapath(internal);
> + if (update_datapath(internal) < 0)
> + DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> 
>   rte_pci_unmap_device(internal->pdev);
>   rte_vfio_container_destroy(internal->vfio_container_fd);
> --
> 2.34.1

Reviewed-by: Chenbo Xia 

[PATCH v5 2/2] net/ice: fix vlan offload of rxq

[Mingjin Ye]

After setting "vlan offload" in pmd, the configuration of rxq is not
updated.

This patch is to sync the rxmode offload config with rxq.

Fixes: e0dcf94a0d7f ("net/ice: support VLAN ops")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_dcf_ethdev.c | 15 +++
 drivers/net/ice/ice_ethdev.c |  7 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index dcbf2af5b0..c32bf4ec03 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -1227,6 +1227,8 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_hw *hw = &adapter->real_hw;
bool enable;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
enable = !!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_FILTER);
@@ -1245,6 +1247,11 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
return -EIO;
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
@@ -1287,6 +1294,8 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_adapter *adapter = dev->data->dev_private;
struct ice_dcf_hw *hw = &adapter->real_hw;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (hw->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2)
return dcf_dev_vlan_offload_set_v2(dev, mask);
@@ -1305,6 +1314,12 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
if (err)
return -EIO;
}
+
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = dev_conf->rxmode.offloads;
+   }
+
return 0;
 }
 
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 8618a3e6b7..5562ceb671 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -4501,6 +4501,8 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct ice_vsi *vsi = pf->main_vsi;
struct rte_eth_rxmode *rxmode;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
rxmode = &dev->data->dev_conf.rxmode;
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
@@ -4517,6 +4519,11 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
ice_vsi_config_vlan_stripping(vsi, false);
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
-- 
2.34.1

[PATCH v5 1/2] net/ice: fix vlan offload

[Mingjin Ye]

The vlan tag and flag in Rx descriptor are not processed on vector path,
then the upper application cann't fetch the tci from mbuf.

This patch is to add handling of vlan RX offloading.

Fixes: c68a52b8b38c ("net/ice: support vector SSE in Rx")
Fixes: ece1f8a8f1c8 ("net/ice: switch to flexible descriptor in SSE path")
Fixes: 12443386a0b0 ("net/ice: support flex Rx descriptor RxDID22")
Fixes: 214f452f7d5f ("net/ice: add AVX2 offload Rx")
Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
Fixes: 295968d17407 ("ethdev: add namespace")
Fixes: 808a17b3c1e6 ("net/ice: add Rx AVX512 offload path")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 

v3:
* Fix macros in ice_rxtx_vec_sse.c source file.
v4:
* Fix ice_rx_desc_to_olflags_v define in ice_rxtx_vec_sse.c source file.
---
 drivers/net/ice/ice_rxtx_vec_avx2.c   | 135 +-
 drivers/net/ice/ice_rxtx_vec_avx512.c | 154 +-
 drivers/net/ice/ice_rxtx_vec_sse.c| 132 --
 3 files changed, 332 insertions(+), 89 deletions(-)

diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c 
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index 31d6af42fd..bddfd6cf65 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -474,7 +474,7 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * will cause performance drop to get into this context.
 */
if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
-   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   (RTE_ETH_RX_OFFLOAD_RSS_HASH | 
RTE_ETH_RX_OFFLOAD_VLAN)) {
/* load bottom half of every 32B desc */
const __m128i raw_desc_bh7 =
_mm_load_si128
@@ -529,33 +529,112 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * to shift the 32b RSS hash value to the
 * highest 32b of each 128b before mask
 */
-   __m256i rss_hash6_7 =
-   _mm256_slli_epi64(raw_desc_bh6_7, 32);
-   __m256i rss_hash4_5 =
-   _mm256_slli_epi64(raw_desc_bh4_5, 32);
-   __m256i rss_hash2_3 =
-   _mm256_slli_epi64(raw_desc_bh2_3, 32);
-   __m256i rss_hash0_1 =
-   _mm256_slli_epi64(raw_desc_bh0_1, 32);
-
-   __m256i rss_hash_msk =
-   _mm256_set_epi32(0x, 0, 0, 0,
-0x, 0, 0, 0);
-
-   rss_hash6_7 = _mm256_and_si256
-   (rss_hash6_7, rss_hash_msk);
-   rss_hash4_5 = _mm256_and_si256
-   (rss_hash4_5, rss_hash_msk);
-   rss_hash2_3 = _mm256_and_si256
-   (rss_hash2_3, rss_hash_msk);
-   rss_hash0_1 = _mm256_and_si256
-   (rss_hash0_1, rss_hash_msk);
-
-   mb6_7 = _mm256_or_si256(mb6_7, rss_hash6_7);
-   mb4_5 = _mm256_or_si256(mb4_5, rss_hash4_5);
-   mb2_3 = _mm256_or_si256(mb2_3, rss_hash2_3);
-   mb0_1 = _mm256_or_si256(mb0_1, rss_hash0_1);
-   } /* if() on RSS hash parsing */
+   if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
+   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   __m256i rss_hash6_7 =
+   
_mm256_slli_epi64(raw_desc_bh6_7, 32);
+   __m256i rss_hash4_5 =
+   
_mm256_slli_epi64(raw_desc_bh4_5, 32);
+   __m256i rss_hash2_3 =
+   
_mm256_slli_epi64(raw_desc_bh2_3, 32);
+   __m256i rss_hash0_1 =
+   
_mm256_slli_epi64(raw_desc_bh0_1, 32);
+
+   __m256i rss_hash_msk =
+   _mm256_set_epi32(0x, 0, 
0, 0,
+   0x, 0, 
0, 0);
+
+   rss_hash6_7 = _mm256_and_si256
+   

回复: [PATCH v2 3/3] examples/l3fwd-power: enable PMD power monitor on Arm

[Feifei Wang]

Hi, Stephen

> -邮件原件-
> 发件人: Stephen Hemminger 
> 发送时间: Tuesday, November 8, 2022 12:02 AM
> 收件人: Feifei Wang 
> 抄送: David Hunt ; dev@dpdk.org;
> david.march...@redhat.com; tho...@monjalon.net; nd ;
> Ruifeng Wang 
> 主题: Re: [PATCH v2 3/3] examples/l3fwd-power: enable PMD power
> monitor on Arm
> 
> On Mon,  7 Nov 2022 15:04:49 +0800
> Feifei Wang  wrote:
> 
> > +   /* Ensure the main lcore does not enter the
> power-monitor state,
> > +* so that it can be used to wake up other
> lcores on ARM.
> > +* This is due to WFE instruction has no
> timeout wake-up mechanism,
> > +* and if users want to exit actively, the main
> lcore is needed
> > +* to send SEV instruction to wake up other
> lcores.
> > +*/
> > +   unsigned int main_lcore =
> rte_get_main_lcore();
> 
> This can be done in a simpler an cleaner manner with a continue statement
> earlier in the loop.
> 
> diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
> index fd3ade330f82..115535fd4cd7 100644
> --- a/examples/l3fwd-power/main.c
> +++ b/examples/l3fwd-power/main.c
> @@ -2984,6 +2984,16 @@ main(int argc, char **argv)
>   }
> 
>   if (app_mode == APP_MODE_PMD_MGMT
> && !baseline_enabled) {
> +#ifdef RTE_ARCH_ARM64
> + /* Ensure the main lcore does not enter the
> power-monitor state,
> +  * so that it can be used to wake up other
> lcores on ARM.
> +  * This is due to WFE instruction has no
> timeout wake-up mechanism,
> +  * and if users want to exit actively, the main
> lcore is needed
> +  * to send SEV instruction to wake up other
> lcors.
> +  */
> + if (lcore_id == rte_get_main_lcore())
> + continue;
> +#endif
>   /* Set power_pmd_mgmt configs passed by
> user */
> 
>   rte_power_pmd_mgmt_set_emptypoll_max(max_empty_polls);
>   ret =
> rte_power_pmd_mgmt_set_pause_duration(pause_duration);

Thanks for the comment.
There maybe some problems for this change. This is due to that we just want to 
disable power monitor
feature on the main core when "app_mode == APP_MODE_PMD_MGMT && pmgmt_type == 
RTE_POWER_MGMT_TYPE_MONITOR".
When “pmgmt_type == RTE_POWER_MGMT_TYPE_PAUSE || pmgmt_type == 
RTE_POWER_MGMT_TYPE_SCALE", main core
power management mode can be enabled.

Best Regards
Feifei

[PATCH v5 1/2] net/ice: fix vlan offload

[Mingjin Ye]

The vlan tag and flag in Rx descriptor are not processed on vector path,
then the upper application can't fetch the tci from mbuf.

This patch is to add handling of vlan RX offloading.

Fixes: c68a52b8b38c ("net/ice: support vector SSE in Rx")
Fixes: ece1f8a8f1c8 ("net/ice: switch to flexible descriptor in SSE path")
Fixes: 12443386a0b0 ("net/ice: support flex Rx descriptor RxDID22")
Fixes: 214f452f7d5f ("net/ice: add AVX2 offload Rx")
Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
Fixes: 295968d17407 ("ethdev: add namespace")
Fixes: 808a17b3c1e6 ("net/ice: add Rx AVX512 offload path")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 

v3:
* Fix macros in ice_rxtx_vec_sse.c source file.
v4:
* Fix ice_rx_desc_to_olflags_v define in ice_rxtx_vec_sse.c source file.
---
 drivers/net/ice/ice_rxtx_vec_avx2.c   | 135 +-
 drivers/net/ice/ice_rxtx_vec_avx512.c | 154 +-
 drivers/net/ice/ice_rxtx_vec_sse.c| 132 --
 3 files changed, 332 insertions(+), 89 deletions(-)

diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c 
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index 31d6af42fd..bddfd6cf65 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -474,7 +474,7 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * will cause performance drop to get into this context.
 */
if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
-   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   (RTE_ETH_RX_OFFLOAD_RSS_HASH | 
RTE_ETH_RX_OFFLOAD_VLAN)) {
/* load bottom half of every 32B desc */
const __m128i raw_desc_bh7 =
_mm_load_si128
@@ -529,33 +529,112 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * to shift the 32b RSS hash value to the
 * highest 32b of each 128b before mask
 */
-   __m256i rss_hash6_7 =
-   _mm256_slli_epi64(raw_desc_bh6_7, 32);
-   __m256i rss_hash4_5 =
-   _mm256_slli_epi64(raw_desc_bh4_5, 32);
-   __m256i rss_hash2_3 =
-   _mm256_slli_epi64(raw_desc_bh2_3, 32);
-   __m256i rss_hash0_1 =
-   _mm256_slli_epi64(raw_desc_bh0_1, 32);
-
-   __m256i rss_hash_msk =
-   _mm256_set_epi32(0x, 0, 0, 0,
-0x, 0, 0, 0);
-
-   rss_hash6_7 = _mm256_and_si256
-   (rss_hash6_7, rss_hash_msk);
-   rss_hash4_5 = _mm256_and_si256
-   (rss_hash4_5, rss_hash_msk);
-   rss_hash2_3 = _mm256_and_si256
-   (rss_hash2_3, rss_hash_msk);
-   rss_hash0_1 = _mm256_and_si256
-   (rss_hash0_1, rss_hash_msk);
-
-   mb6_7 = _mm256_or_si256(mb6_7, rss_hash6_7);
-   mb4_5 = _mm256_or_si256(mb4_5, rss_hash4_5);
-   mb2_3 = _mm256_or_si256(mb2_3, rss_hash2_3);
-   mb0_1 = _mm256_or_si256(mb0_1, rss_hash0_1);
-   } /* if() on RSS hash parsing */
+   if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
+   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   __m256i rss_hash6_7 =
+   
_mm256_slli_epi64(raw_desc_bh6_7, 32);
+   __m256i rss_hash4_5 =
+   
_mm256_slli_epi64(raw_desc_bh4_5, 32);
+   __m256i rss_hash2_3 =
+   
_mm256_slli_epi64(raw_desc_bh2_3, 32);
+   __m256i rss_hash0_1 =
+   
_mm256_slli_epi64(raw_desc_bh0_1, 32);
+
+   __m256i rss_hash_msk =
+   _mm256_set_epi32(0x, 0, 
0, 0,
+   0x, 0, 
0, 0);
+
+   rss_hash6_7 = _mm256_and_si256
+

[PATCH v5 2/2] net/ice: fix vlan offload of rxq

[Mingjin Ye]

After setting "vlan offload" in pmd, the configuration of rxq is not
updated.

This patch is to sync the rxmode offload config with rxq.

Fixes: e0dcf94a0d7f ("net/ice: support VLAN ops")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_dcf_ethdev.c | 15 +++
 drivers/net/ice/ice_ethdev.c |  7 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index dcbf2af5b0..c32bf4ec03 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -1227,6 +1227,8 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_hw *hw = &adapter->real_hw;
bool enable;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
enable = !!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_FILTER);
@@ -1245,6 +1247,11 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
return -EIO;
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
@@ -1287,6 +1294,8 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_adapter *adapter = dev->data->dev_private;
struct ice_dcf_hw *hw = &adapter->real_hw;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (hw->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2)
return dcf_dev_vlan_offload_set_v2(dev, mask);
@@ -1305,6 +1314,12 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
if (err)
return -EIO;
}
+
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = dev_conf->rxmode.offloads;
+   }
+
return 0;
 }
 
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 8618a3e6b7..5562ceb671 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -4501,6 +4501,8 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct ice_vsi *vsi = pf->main_vsi;
struct rte_eth_rxmode *rxmode;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
rxmode = &dev->data->dev_conf.rxmode;
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
@@ -4517,6 +4519,11 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
ice_vsi_config_vlan_stripping(vsi, false);
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
-- 
2.34.1

RE: [PATCH] common/qat: fix undefined initial slice

[Akhil Goyal]

> Acked-by: Kai Ji 
> 

You should reply in the bottom.
> > Subject: [PATCH] common/qat: fix undefined initial slice
> >
> > This commit fixes undefined initial value of slice capability.
> > When unset it could lead to undefined read of capability due to stack frame
> > picked values, is should therefore be set to 0.
> >
> > Fixes: b3cbbcdffa4f ("common/qat: read HW slice configuration")
> >
> > Signed-off-by: Arek Kusztal 
Applied to dpdk-next-crypto

Thanks.

RE: [PATCH v2] examples/fips_validation: fix typo

[Akhil Goyal]

> > Subject: [PATCH v2] examples/fips_validation: fix typo
> >
> > Digest length is being printed out, not IV length.
> >
> > Fixes: ac026f4668d0 ("examples/fips_validation: support CMAC parsing")
> > Fixes: f64adb6714e0 ("examples/fips_validation: support HMAC parsing")
> > Cc: marko.kovace...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Pablo de Lara 
> > ---
> Reviewed-by: Brian Dooley 
Applied to dpdk-next-crypto

RE: [PATCH] test/crypto: add 3DES IPsec test cases

[Akhil Goyal]

> Subject: [PATCH] test/crypto: add 3DES IPsec test cases
> 
> Add IPsec test cases for cipher algorithm 3DES.
> 
> Signed-off-by: Aakash Sasidharan 
> Reviewed-by: Anoob Joseph 

Applied to dpdk-next-crypto

RE: [EXT] [PATCH v2] doc: announce IPsec support on Arm

[Akhil Goyal]

> Subject: [EXT] [PATCH v2] doc: announce IPsec support on Arm
> Updated release notes about the SNOW-3G and ZUC support on ARM platform.
> 
> Fixes: 0899a87ce7c7 ("crypto/ipsec_mb: enable IPsec on Arm platform")
> 
> Signed-off-by: Ruifeng Wang 
Applied to dpdk-next-crypto

Thanks.

[PATCH v5 1/2] net/ice: fix vlan offload

[Mingjin Ye]

The vlan tag and flag in Rx descriptor are not processed on vector path,
then the upper application can't fetch the tci from mbuf.

This patch is to add handling of vlan RX offloading.

Fixes: c68a52b8b38c ("net/ice: support vector SSE in Rx")
Fixes: ece1f8a8f1c8 ("net/ice: switch to flexible descriptor in SSE path")
Fixes: 12443386a0b0 ("net/ice: support flex Rx descriptor RxDID22")
Fixes: 214f452f7d5f ("net/ice: add AVX2 offload Rx")
Fixes: 7f85d5ebcfe1 ("net/ice: add AVX512 vector path")
Fixes: 295968d17407 ("ethdev: add namespace")
Fixes: 808a17b3c1e6 ("net/ice: add Rx AVX512 offload path")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 

v3:
* Fix macros in ice_rxtx_vec_sse.c source file.
v4:
* Fix ice_rx_desc_to_olflags_v define in ice_rxtx_vec_sse.c source file.
---
 drivers/net/ice/ice_rxtx_vec_avx2.c   | 135 +-
 drivers/net/ice/ice_rxtx_vec_avx512.c | 154 +-
 drivers/net/ice/ice_rxtx_vec_sse.c| 132 --
 3 files changed, 332 insertions(+), 89 deletions(-)

diff --git a/drivers/net/ice/ice_rxtx_vec_avx2.c 
b/drivers/net/ice/ice_rxtx_vec_avx2.c
index 31d6af42fd..bddfd6cf65 100644
--- a/drivers/net/ice/ice_rxtx_vec_avx2.c
+++ b/drivers/net/ice/ice_rxtx_vec_avx2.c
@@ -474,7 +474,7 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * will cause performance drop to get into this context.
 */
if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
-   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   (RTE_ETH_RX_OFFLOAD_RSS_HASH | 
RTE_ETH_RX_OFFLOAD_VLAN)) {
/* load bottom half of every 32B desc */
const __m128i raw_desc_bh7 =
_mm_load_si128
@@ -529,33 +529,112 @@ _ice_recv_raw_pkts_vec_avx2(struct ice_rx_queue *rxq, 
struct rte_mbuf **rx_pkts,
 * to shift the 32b RSS hash value to the
 * highest 32b of each 128b before mask
 */
-   __m256i rss_hash6_7 =
-   _mm256_slli_epi64(raw_desc_bh6_7, 32);
-   __m256i rss_hash4_5 =
-   _mm256_slli_epi64(raw_desc_bh4_5, 32);
-   __m256i rss_hash2_3 =
-   _mm256_slli_epi64(raw_desc_bh2_3, 32);
-   __m256i rss_hash0_1 =
-   _mm256_slli_epi64(raw_desc_bh0_1, 32);
-
-   __m256i rss_hash_msk =
-   _mm256_set_epi32(0x, 0, 0, 0,
-0x, 0, 0, 0);
-
-   rss_hash6_7 = _mm256_and_si256
-   (rss_hash6_7, rss_hash_msk);
-   rss_hash4_5 = _mm256_and_si256
-   (rss_hash4_5, rss_hash_msk);
-   rss_hash2_3 = _mm256_and_si256
-   (rss_hash2_3, rss_hash_msk);
-   rss_hash0_1 = _mm256_and_si256
-   (rss_hash0_1, rss_hash_msk);
-
-   mb6_7 = _mm256_or_si256(mb6_7, rss_hash6_7);
-   mb4_5 = _mm256_or_si256(mb4_5, rss_hash4_5);
-   mb2_3 = _mm256_or_si256(mb2_3, rss_hash2_3);
-   mb0_1 = _mm256_or_si256(mb0_1, rss_hash0_1);
-   } /* if() on RSS hash parsing */
+   if 
(rxq->vsi->adapter->pf.dev_data->dev_conf.rxmode.offloads &
+   RTE_ETH_RX_OFFLOAD_RSS_HASH) {
+   __m256i rss_hash6_7 =
+   
_mm256_slli_epi64(raw_desc_bh6_7, 32);
+   __m256i rss_hash4_5 =
+   
_mm256_slli_epi64(raw_desc_bh4_5, 32);
+   __m256i rss_hash2_3 =
+   
_mm256_slli_epi64(raw_desc_bh2_3, 32);
+   __m256i rss_hash0_1 =
+   
_mm256_slli_epi64(raw_desc_bh0_1, 32);
+
+   __m256i rss_hash_msk =
+   _mm256_set_epi32(0x, 0, 
0, 0,
+   0x, 0, 
0, 0);
+
+   rss_hash6_7 = _mm256_and_si256
+

[PATCH v5 2/2] net/ice: fix vlan offload of rxq

[Mingjin Ye]

After setting "vlan offload" in pmd, the configuration of rxq is not
updated.

This patch is to sync the rxmode offload config with rxq.

Fixes: e0dcf94a0d7f ("net/ice: support VLAN ops")
Cc: sta...@dpdk.org

Signed-off-by: Mingjin Ye 
---
 drivers/net/ice/ice_dcf_ethdev.c | 15 +++
 drivers/net/ice/ice_ethdev.c |  7 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index dcbf2af5b0..c32bf4ec03 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -1227,6 +1227,8 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_hw *hw = &adapter->real_hw;
bool enable;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
enable = !!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_FILTER);
@@ -1245,6 +1247,11 @@ dcf_dev_vlan_offload_set_v2(struct rte_eth_dev *dev, int 
mask)
return -EIO;
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
@@ -1287,6 +1294,8 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
struct ice_dcf_adapter *adapter = dev->data->dev_private;
struct ice_dcf_hw *hw = &adapter->real_hw;
int err;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
if (hw->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2)
return dcf_dev_vlan_offload_set_v2(dev, mask);
@@ -1305,6 +1314,12 @@ dcf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
if (err)
return -EIO;
}
+
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = dev_conf->rxmode.offloads;
+   }
+
return 0;
 }
 
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 8618a3e6b7..5562ceb671 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -4501,6 +4501,8 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct ice_vsi *vsi = pf->main_vsi;
struct rte_eth_rxmode *rxmode;
+   size_t queue_idx;
+   struct ice_rx_queue *rxq;
 
rxmode = &dev->data->dev_conf.rxmode;
if (mask & RTE_ETH_VLAN_FILTER_MASK) {
@@ -4517,6 +4519,11 @@ ice_vlan_offload_set(struct rte_eth_dev *dev, int mask)
ice_vsi_config_vlan_stripping(vsi, false);
}
 
+   for (queue_idx = 0; queue_idx < dev->data->nb_rx_queues; queue_idx++) {
+   rxq = dev->data->rx_queues[queue_idx];
+   rxq->offloads = rxmode->offloads;
+   }
+
return 0;
 }
 
-- 
2.34.1

RE: [EXT] [PATCH v1 1/1] baseband/acc100: fix to input error related to padding

[Akhil Goyal]

> Previous commit includes some padding for some cases,
> which may cause input warning from the HW
> which should be safely ignored to avoid false alarm.
> 
> Fixes: 6f3325bbfa ("baseband/acc100: add LDPC encoder padding function")
> 
> Signed-off-by: Nicolas Chautru 
Applied to dpdk-next-crypto.

[PATCH v1] mempool/cnxk: destroy NPA pool only if its created

[Ashwin Sekhar T K]

In scenarios where rte_mempool_free() is called immediately
after rte_mempool_create_empty(), the NPA pool will not be
created. In such cases the free path should not call
roc_npa_pool_destroy().

Signed-off-by: Ashwin Sekhar T K 
---
 drivers/mempool/cnxk/cnxk_mempool_ops.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mempool/cnxk/cnxk_mempool_ops.c 
b/drivers/mempool/cnxk/cnxk_mempool_ops.c
index a0b94bb95c..e3026136cf 100644
--- a/drivers/mempool/cnxk/cnxk_mempool_ops.c
+++ b/drivers/mempool/cnxk/cnxk_mempool_ops.c
@@ -126,6 +126,14 @@ cnxk_mempool_free(struct rte_mempool *mp)
int rc = 0;
 
plt_npa_dbg("aura_handle=0x%" PRIx64, mp->pool_id);
+
+   /* It can happen that rte_mempool_free() is called immediately after
+* rte_mempool_create_empty(). In such cases the NPA pool will not be
+* allocated.
+*/
+   if (roc_npa_aura_handle_to_base(mp->pool_id) == NULL)
+   return;
+
rc = roc_npa_pool_destroy(mp->pool_id);
if (rc)
plt_err("Failed to free pool or aura rc=%d", rc);
-- 
2.25.1

RE: [PATCH] net/ice/base: fix duplicate flow rules

[Zhou, YidingX]

Hi, Qi

This  patch has been merged to kernel driver.
Should  it be merged to dpdk now? 

> -Original Message-
> From: Zhou, YidingX 
> Sent: Thursday, October 13, 2022 2:21 PM
> To: dev@dpdk.org
> Cc: Zhou, YidingX ; sta...@dpdk.org
> Subject: [PATCH] net/ice/base: fix duplicate flow rules
> 
> When a vsi that already exists in the created vsi_list subscribes to the same
> filter again, the return value ICE_SUCCESS results in duplicate flow rules to 
> be
> stored, which will cause 'flush' and 'destroy' errors.
> 
> Fixes: fed0c5ca5f19 ("net/ice/base: support programming a new switch recipe")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Yiding Zhou 
> ---
>  drivers/net/ice/base/ice_switch.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ice/base/ice_switch.c
> b/drivers/net/ice/base/ice_switch.c
> index 4b115ce660..a2581f404d 100644
> --- a/drivers/net/ice/base/ice_switch.c
> +++ b/drivers/net/ice/base/ice_switch.c
> @@ -8786,7 +8786,7 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw,
> 
>   /* A rule already exists with the new VSI being added */
>   if (ice_is_bit_set(m_entry->vsi_list_info->vsi_map, vsi_handle))
> - return ICE_SUCCESS;
> + return ICE_ERR_ALREADY_EXISTS;
> 
>   /* Update the previously created VSI list set with
>* the new VSI ID passed in
> --
> 2.34.1

[PATCH v2] mempool/cnxk: destroy NPA pool only if its created

[Ashwin Sekhar T K]

In scenarios where rte_mempool_free() is called immediately
after rte_mempool_create_empty(), the NPA pool will not be
created. In such cases the free path should not call
roc_npa_pool_destroy().

Signed-off-by: Ashwin Sekhar T K 
---
 drivers/mempool/cnxk/cnxk_mempool_ops.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mempool/cnxk/cnxk_mempool_ops.c 
b/drivers/mempool/cnxk/cnxk_mempool_ops.c
index a0b94bb95c..3769afd3d1 100644
--- a/drivers/mempool/cnxk/cnxk_mempool_ops.c
+++ b/drivers/mempool/cnxk/cnxk_mempool_ops.c
@@ -126,6 +126,14 @@ cnxk_mempool_free(struct rte_mempool *mp)
int rc = 0;
 
plt_npa_dbg("aura_handle=0x%" PRIx64, mp->pool_id);
+
+   /* It can happen that rte_mempool_free() is called immediately after
+* rte_mempool_create_empty(). In such cases the NPA pool will not be
+* allocated.
+*/
+   if (roc_npa_aura_handle_to_base(mp->pool_id) == 0)
+   return;
+
rc = roc_npa_pool_destroy(mp->pool_id);
if (rc)
plt_err("Failed to free pool or aura rc=%d", rc);
-- 
2.25.1

[PATCH v3] mempool/cnxk: fix mempool destroy for empty pools

[Ashwin Sekhar T K]

In scenarios where rte_mempool_free() is called immediately
after rte_mempool_create_empty(), the NPA pool will not be
created. In such cases the free path should not call
roc_npa_pool_destroy().

Fixes: bbf19e89b87c ("mempool/cnxk: add generic operations")

Signed-off-by: Ashwin Sekhar T K 
---
 drivers/mempool/cnxk/cnxk_mempool_ops.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mempool/cnxk/cnxk_mempool_ops.c 
b/drivers/mempool/cnxk/cnxk_mempool_ops.c
index a0b94bb95c..3769afd3d1 100644
--- a/drivers/mempool/cnxk/cnxk_mempool_ops.c
+++ b/drivers/mempool/cnxk/cnxk_mempool_ops.c
@@ -126,6 +126,14 @@ cnxk_mempool_free(struct rte_mempool *mp)
int rc = 0;
 
plt_npa_dbg("aura_handle=0x%" PRIx64, mp->pool_id);
+
+   /* It can happen that rte_mempool_free() is called immediately after
+* rte_mempool_create_empty(). In such cases the NPA pool will not be
+* allocated.
+*/
+   if (roc_npa_aura_handle_to_base(mp->pool_id) == 0)
+   return;
+
rc = roc_npa_pool_destroy(mp->pool_id);
if (rc)
plt_err("Failed to free pool or aura rc=%d", rc);
-- 
2.25.1

RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling

[Pei, Andy]

Hi 

See my reply inline.

> -Original Message-
> From: Xia, Chenbo 
> Sent: Tuesday, November 8, 2022 9:47 AM
> To: Taekyung Kim ; dev@dpdk.org
> Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Wang, Xiao W
> 
> Subject: RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> 
> > -Original Message-
> > From: Taekyung Kim 
> > Sent: Monday, November 7, 2022 5:00 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Xia, Chenbo
> > ; Wang, Xiao W ;
> > kim.tae.ky...@navercorp.com
> > Subject: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> >
> > Stop and return the error code when update_datapath fails.
> > update_datapath prepares resources for the vdpa device.
> > The driver should not perform any further actions if update_datapath
> > returns an error.
> >
> > Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Taekyung Kim 
> > ---
> > v3:
> > * Fix coding style
> >
> > v2:
> > * Revert the prepared resources before returning an error
> > * Rebase to 22.11 rc2
> > * Add fixes and cc for backport
> >
> > ---
> >  drivers/vdpa/ifc/ifcvf_vdpa.c | 26 ++
> >  1 file changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > b/drivers/vdpa/ifc/ifcvf_vdpa.c index 8dfd49336e..0396d49122 100644
> > --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> > @@ -1098,7 +1098,12 @@ ifcvf_dev_config(int vid)
> > internal = list->internal;
> > internal->vid = vid;
> > rte_atomic32_set(&internal->dev_attached, 1);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath for vDPA device %s",
> > +   vdev->device->name);
> > +   rte_atomic32_set(&internal->dev_attached, 0);
> > +   return -1;
> > +   }
> >
> > hw = &internal->hw;
> > for (i = 0; i < hw->nr_vring; i++) { @@ -1146,7 +1151,12 @@
> > ifcvf_dev_close(int vid)
> > internal->sw_fallback_running = false;
> > } else {
> > rte_atomic32_set(&internal->dev_attached, 0);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath for vDPA
> > device %s",
> > +   vdev->device->name);
> > +   internal->configured = 0;
> > +   return -1;
> > +   }
> > }
> >
> > internal->configured = 0;
> > @@ -1752,7 +1762,14 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv
> > __rte_unused,
> > }
> >
> > rte_atomic32_set(&internal->started, 1);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> > +   rte_atomic32_set(&internal->started, 0);
> > +   pthread_mutex_lock(&internal_list_lock);
> > +   TAILQ_REMOVE(&internal_list, list, next);
> > +   pthread_mutex_unlock(&internal_list_lock);
> > +   goto error;
> > +   }
> >

Is it necessary to unregister vdpa device?

> > rte_kvargs_free(kvlist);
> > return 0;
> > @@ -1781,7 +1798,8 @@ ifcvf_pci_remove(struct rte_pci_device *pci_dev)
> >
> > internal = list->internal;
> > rte_atomic32_set(&internal->started, 0);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0)
> > +   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> >
> > rte_pci_unmap_device(internal->pdev);
> > rte_vfio_container_destroy(internal->vfio_container_fd);
> > --
> > 2.34.1
> 
> Reviewed-by: Chenbo Xia 

Re: [PATCH] common/mlx5: use build configuration dictionary

[David Marchand]

On Mon, Nov 7, 2022 at 5:37 PM Thomas Monjalon  wrote:
>
> A recent commit added an explicit dependency check on common/mlx5.
> For consistency, query dpdk_conf instead of the list of common drivers.
> The lists *_drivers should be used only for printing.
>
> Fixes: 3df380f61797 ("common/mlx5: fix disabling build")
>
> Suggested-by: Bruce Richardson 
> Signed-off-by: Thomas Monjalon 

Reviewed-by: David Marchand 

-- 
David Marchand

Re: [PATCH v3] vdpa/ifc: fix update_datapath error handling

[Taekyung Kim]

Hi Chenbo,

Thanks for your review.

On Tue, Nov 08, 2022 at 01:46:37AM +, Xia, Chenbo wrote:
> > -Original Message-
> > From: Taekyung Kim 
> > Sent: Monday, November 7, 2022 5:00 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Xia, Chenbo
> > ; Wang, Xiao W ;
> > kim.tae.ky...@navercorp.com
> > Subject: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> > 
> > Stop and return the error code when update_datapath fails.
> > update_datapath prepares resources for the vdpa device.
> > The driver should not perform any further actions
> > if update_datapath returns an error.
> > 
> > Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Taekyung Kim 
> > ---
> > v3:
> > * Fix coding style
> > 
> > v2:
> > * Revert the prepared resources before returning an error
> > * Rebase to 22.11 rc2
> > * Add fixes and cc for backport
> > 
> > ---
> >  drivers/vdpa/ifc/ifcvf_vdpa.c | 26 ++
> >  1 file changed, 22 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
> > index 8dfd49336e..0396d49122 100644
> > --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> > @@ -1098,7 +1098,12 @@ ifcvf_dev_config(int vid)
> > internal = list->internal;
> > internal->vid = vid;
> > rte_atomic32_set(&internal->dev_attached, 1);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath for vDPA device %s",
> > +   vdev->device->name);
> > +   rte_atomic32_set(&internal->dev_attached, 0);
> > +   return -1;
> > +   }
> > 
> > hw = &internal->hw;
> > for (i = 0; i < hw->nr_vring; i++) {
> > @@ -1146,7 +1151,12 @@ ifcvf_dev_close(int vid)
> > internal->sw_fallback_running = false;
> > } else {
> > rte_atomic32_set(&internal->dev_attached, 0);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath for vDPA
> > device %s",
> > +   vdev->device->name);
> > +   internal->configured = 0;
> > +   return -1;
> > +   }
> > }
> > 
> > internal->configured = 0;
> > @@ -1752,7 +1762,14 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv
> > __rte_unused,
> > }
> > 
> > rte_atomic32_set(&internal->started, 1);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0) {
> > +   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> > +   rte_atomic32_set(&internal->started, 0);
> > +   pthread_mutex_lock(&internal_list_lock);
> > +   TAILQ_REMOVE(&internal_list, list, next);
> > +   pthread_mutex_unlock(&internal_list_lock);
> > +   goto error;
> > +   }
> > 
> > rte_kvargs_free(kvlist);
> > return 0;
> > @@ -1781,7 +1798,8 @@ ifcvf_pci_remove(struct rte_pci_device *pci_dev)
> > 
> > internal = list->internal;
> > rte_atomic32_set(&internal->started, 0);
> > -   update_datapath(internal);
> > +   if (update_datapath(internal) < 0)
> > +   DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> > 
> > rte_pci_unmap_device(internal->pdev);
> > rte_vfio_container_destroy(internal->vfio_container_fd);
> > --
> > 2.34.1
> 
> Reviewed-by: Chenbo Xia 

RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling

[Xia, Chenbo]

> -Original Message-
> From: Pei, Andy 
> Sent: Tuesday, November 8, 2022 3:39 PM
> To: Xia, Chenbo ; Taekyung Kim
> ; dev@dpdk.org
> Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Wang, Xiao W
> 
> Subject: RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> 
> Hi
> 
> See my reply inline.
> 
> > -Original Message-
> > From: Xia, Chenbo 
> > Sent: Tuesday, November 8, 2022 9:47 AM
> > To: Taekyung Kim ; dev@dpdk.org
> > Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Wang, Xiao W
> > 
> > Subject: RE: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> >
> > > -Original Message-
> > > From: Taekyung Kim 
> > > Sent: Monday, November 7, 2022 5:00 PM
> > > To: dev@dpdk.org
> > > Cc: sta...@dpdk.org; maxime.coque...@redhat.com; Xia, Chenbo
> > > ; Wang, Xiao W ;
> > > kim.tae.ky...@navercorp.com
> > > Subject: [PATCH v3] vdpa/ifc: fix update_datapath error handling
> > >
> > > Stop and return the error code when update_datapath fails.
> > > update_datapath prepares resources for the vdpa device.
> > > The driver should not perform any further actions if update_datapath
> > > returns an error.
> > >
> > > Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Taekyung Kim 
> > > ---
> > > v3:
> > > * Fix coding style
> > >
> > > v2:
> > > * Revert the prepared resources before returning an error
> > > * Rebase to 22.11 rc2
> > > * Add fixes and cc for backport
> > >
> > > ---
> > >  drivers/vdpa/ifc/ifcvf_vdpa.c | 26 ++
> > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > > b/drivers/vdpa/ifc/ifcvf_vdpa.c index 8dfd49336e..0396d49122 100644
> > > --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > > +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> > > @@ -1098,7 +1098,12 @@ ifcvf_dev_config(int vid)
> > >   internal = list->internal;
> > >   internal->vid = vid;
> > >   rte_atomic32_set(&internal->dev_attached, 1);
> > > - update_datapath(internal);
> > > + if (update_datapath(internal) < 0) {
> > > + DRV_LOG(ERR, "failed to update datapath for vDPA device %s",
> > > + vdev->device->name);
> > > + rte_atomic32_set(&internal->dev_attached, 0);
> > > + return -1;
> > > + }
> > >
> > >   hw = &internal->hw;
> > >   for (i = 0; i < hw->nr_vring; i++) { @@ -1146,7 +1151,12 @@
> > > ifcvf_dev_close(int vid)
> > >   internal->sw_fallback_running = false;
> > >   } else {
> > >   rte_atomic32_set(&internal->dev_attached, 0);
> > > - update_datapath(internal);
> > > + if (update_datapath(internal) < 0) {
> > > + DRV_LOG(ERR, "failed to update datapath for vDPA
> > > device %s",
> > > + vdev->device->name);
> > > + internal->configured = 0;
> > > + return -1;
> > > + }
> > >   }
> > >
> > >   internal->configured = 0;
> > > @@ -1752,7 +1762,14 @@ ifcvf_pci_probe(struct rte_pci_driver *pci_drv
> > > __rte_unused,
> > >   }
> > >
> > >   rte_atomic32_set(&internal->started, 1);
> > > - update_datapath(internal);
> > > + if (update_datapath(internal) < 0) {
> > > + DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> > > + rte_atomic32_set(&internal->started, 0);
> > > + pthread_mutex_lock(&internal_list_lock);
> > > + TAILQ_REMOVE(&internal_list, list, next);
> > > + pthread_mutex_unlock(&internal_list_lock);
> > > + goto error;
> > > + }
> > >
> 
> Is it necessary to unregister vdpa device?

Good catch, yes it's needed.

Kim, please add the unregistration.

Thanks,
Chenbo

> 
> > >   rte_kvargs_free(kvlist);
> > >   return 0;
> > > @@ -1781,7 +1798,8 @@ ifcvf_pci_remove(struct rte_pci_device *pci_dev)
> > >
> > >   internal = list->internal;
> > >   rte_atomic32_set(&internal->started, 0);
> > > - update_datapath(internal);
> > > + if (update_datapath(internal) < 0)
> > > + DRV_LOG(ERR, "failed to update datapath %s", pci_dev->name);
> > >
> > >   rte_pci_unmap_device(internal->pdev);
> > >   rte_vfio_container_destroy(internal->vfio_container_fd);
> > > --
> > > 2.34.1
> >
> > Reviewed-by: Chenbo Xia