Re: [PATCH v10 3/4] app/dma-perf: validate copied memory

[fengchengwen]

Hi Gowrishankar,

On 2024/2/28 2:35, Amit Prakash Shukla wrote:
> From: Gowrishankar Muthukrishnan 
> 
> Validate copied memory to ensure DMA copy did not fail.
> 
> Signed-off-by: Gowrishankar Muthukrishnan 
> Acked-by: Anoob Joseph 
> Acked-by: Chengwen Feng 
> ---
>  app/test-dma-perf/benchmark.c | 21 -
>  app/test-dma-perf/main.c  | 16 +++-
>  app/test-dma-perf/main.h  |  2 +-
>  3 files changed, 32 insertions(+), 7 deletions(-)
> 
> diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
> index 4370d71134..0047e2f4b8 100644
> --- a/app/test-dma-perf/benchmark.c
> +++ b/app/test-dma-perf/benchmark.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "main.h"
>  
> @@ -407,6 +408,11 @@ setup_memory_env(struct test_configure *cfg, struct 
> rte_mbuf ***srcs,
>   return -1;
>   }
>  
> + for (i = 0; i < nr_buf; i++) {
> + memset(rte_pktmbuf_mtod((*srcs)[i], void *), rte_rand(), 
> buf_size);
> + memset(rte_pktmbuf_mtod((*dsts)[i], void *), 0, buf_size);
> + }
> +
>   if (cfg->transfer_dir == RTE_DMA_DIR_DEV_TO_MEM ||
>   cfg->transfer_dir == RTE_DMA_DIR_MEM_TO_DEV) {
>   ext_buf_info = rte_malloc(NULL, sizeof(struct 
> rte_mbuf_ext_shared_info), 0);
> @@ -443,7 +449,7 @@ setup_memory_env(struct test_configure *cfg, struct 
> rte_mbuf ***srcs,
>   return 0;
>  }
>  
> -void
> +int
>  mem_copy_benchmark(struct test_configure *cfg, bool is_dma)
>  {
>   uint32_t i;
> @@ -461,6 +467,7 @@ mem_copy_benchmark(struct test_configure *cfg, bool 
> is_dma)
>   uint32_t avg_cycles_total;
>   float mops, mops_total;
>   float bandwidth, bandwidth_total;
> + int ret = 0;
>  
>   if (setup_memory_env(cfg, &srcs, &dsts) < 0)
>   goto out;
> @@ -534,6 +541,16 @@ mem_copy_benchmark(struct test_configure *cfg, bool 
> is_dma)
>  
>   rte_eal_mp_wait_lcore();
>  
> + for (i = 0; i < (nr_buf / nb_workers) * nb_workers; i++) {
> + if (memcmp(rte_pktmbuf_mtod(srcs[i], void *),
> +rte_pktmbuf_mtod(dsts[i], void *),
> +cfg->buf_size.cur) != 0) {
> + printf("Copy validation fails for buffer number %d\n", 
> i);

For non-mem2mem DMA, like mem2dev or dev2mem, the device host address may not 
direct accessable by CPU
(if could may need mmap).

So pls restrict it only mem2mem, or drop this commit.

Thanks

> + ret = -1;
> + goto out;
> + }
> + }
> +
>   mops_total = 0;
>   bandwidth_total = 0;
>   avg_cycles_total = 0;
> @@ -599,4 +616,6 @@ mem_copy_benchmark(struct test_configure *cfg, bool 
> is_dma)
>   rte_dma_stop(ldm->dma_ids[i]);
>   }
>   }
> +
> + return ret;
>  }
> diff --git a/app/test-dma-perf/main.c b/app/test-dma-perf/main.c
> index 051f76a6f9..df05bcd7df 100644
> --- a/app/test-dma-perf/main.c
> +++ b/app/test-dma-perf/main.c
> @@ -101,20 +101,24 @@ open_output_csv(const char *rst_path_ptr)
>   return 0;
>  }
>  
> -static void
> +static int
>  run_test_case(struct test_configure *case_cfg)
>  {
> + int ret = 0;
> +
>   switch (case_cfg->test_type) {
>   case TEST_TYPE_DMA_MEM_COPY:
> - mem_copy_benchmark(case_cfg, true);
> + ret = mem_copy_benchmark(case_cfg, true);
>   break;
>   case TEST_TYPE_CPU_MEM_COPY:
> - mem_copy_benchmark(case_cfg, false);
> + ret = mem_copy_benchmark(case_cfg, false);
>   break;
>   default:
>   printf("Unknown test type. %s\n", case_cfg->test_type_str);
>   break;
>   }
> +
> + return ret;
>  }
>  
>  static void
> @@ -159,8 +163,10 @@ run_test(uint32_t case_id, struct test_configure 
> *case_cfg)
>   case_cfg->scenario_id++;
>   printf("\nRunning scenario %d\n", case_cfg->scenario_id);
>  
> - run_test_case(case_cfg);
> - output_csv(false);
> + if (run_test_case(case_cfg) < 0)
> + printf("\nTest fails! skipping this scenario.\n");
> + else
> + output_csv(false);
>  
>   if (var_entry->op == OP_ADD)
>   var_entry->cur += var_entry->incr;
> diff --git a/app/test-dma-perf/main.h b/app/test-dma-perf/main.h
> index 745c24b7fe..1123e7524a 100644
> --- a/app/test-dma-perf/main.h
> +++ b/app/test-dma-perf/main.h
> @@ -66,6 +66,6 @@ struct test_configure {
>   struct test_vchan_dev_config vchan_dev;
>  };
>  
> -void mem_copy_benchmark(struct test_configure *cfg, bool is_dma);
> +int mem_copy_benchmark(struct test_configure *cfg, bool is_dma);
>  
>  #endif /* MAIN_H */
> 

RE: [PATCH v9] net/bnx2x: fix warnings about rte_memcpy lengths

[Raslan Darawsheh]

Hi,
> -Original Message-
> From: Morten Brørup 
> Sent: Tuesday, February 27, 2024 1:28 PM
> To: Jerin Jacob ; Raslan Darawsheh
> 
> Cc: julien_d...@jaube.fr; dev@dpdk.org; step...@networkplumber.org;
> rm...@marvell.com; shsha...@marvell.com; pa...@marvell.com
> Subject: RE: [PATCH v9] net/bnx2x: fix warnings about rte_memcpy lengths
> 
> +To: Raslan, regarding MLX5 patch
> 
> > From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > Sent: Tuesday, 27 February 2024 12.01
> >
> > On Mon, Feb 26, 2024 at 8:17 PM Morten Brørup
> > 
> > wrote:
> > >
> > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > > > Sent: Monday, 26 February 2024 09.34
> > > >
> > > > On Fri, Feb 23, 2024 at 7:30 PM Morten Brørup
> > > > 
> > > > wrote:
> > > > >
> > > > > Bugfix: The vlan in the bulletin does not contain a VLAN header,
> > > > > only
> > > > the
> > > > > VLAN ID, so only copy 2 byte, not 4. The target structure has
> > > > > padding after the field, so copying 2 byte too many is effectively
> harmless.
> > > > > There is no need to backport this patch.
> > > > >
> > > > > Use RTE_PTR_ADD where copying arrays to the offset of a first
> > > > > field in
> > > > a
> > > > > structure holding multiple fields, to avoid compiler warnings
> > > > > with decorated rte_memcpy.
> > > > >
> > > > > Bugzilla ID: 1146
> > > > >
> > > > > Fixes: 540a211084a7695a1c7bc43068934c140d6989be ("bnx2x:
> driver
> > > > > core")
> > > > > Cc: step...@networkplumber.org
> > > > > Cc: rm...@marvell.com
> > > > > Cc: shsha...@marvell.com
> > > > > Cc: pa...@marvell.com
> > > > >
> > > > > Signed-off-by: Morten Brørup 
> > > > > Acked-by: Devendra Singh Rawat 
> > > > > ---
> > > > > v9:
> > > > > * Fix checkpatch warning about spaces.
> > > >
> > > > Fixed the following issues[1] and updated the git commit as
> > > > follows and applied to dpdk-next-net-mrvl/for-main. Thanks
> > >
> > > Thank you, Jerin.
> > >
> > > [...]
> > >
> > > > Is it candidate for Cc: sta...@dpdk.org backport?
> > >
> > > No, I don't think so:
> > > 1. The extra 2 byte copy is effectively harmless due to padding, as
> > mentioned in the commit message.
> > > 2. The decorated rte_memcpy (if work on that patch series is ever
> > > resumed)
> > is an improvement, not a bug fix, and will not be backported. So the
> > memcpy parts of this patch are irrelevant for the stable versions.
> >
> >
> > Shall remove Fixes: tag then?. Since the patch has a Fixes tag, I
> > thought good to merge to stable as it is fixing.
> 
> Although the patch formally fixes a bug, the bug is harmless, so I don't 
> think it
> is worth the effort backporting.
> I don't know the policy for Fixes: tags in such cases. However you proceed 
> with
> it is perfectly fine with me.
> 
> >
> > Also, could you comment on @Stephen Hemminger latest comments,
> Should
> > I wait for new version? or new changes can go as separate patches.
> 
> I'm not providing a new version of this patch.
> 
> This patch was part of a series, where its rte_memcpy changes were required
> for the primary patch in the series [1]. The purpose of the primary patch was
> to tighten rte_memcpy's parameter requirements by adding access-mode
> attributes.
> 
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-
> 4...@smartsharesystems.com/
> 
> It was not really my intention to fix other things in the drivers I submitted
> patches for. That was only a positive side effect. ;-)
> 
> @Raslan: Also, the patch for the mlx5 driver [2] has seen no progress for a
> year, so I'm going to abandon it. I will resume it if I start working on the
> decorated rte_memcpy again. Should I change it's state to Not Applicable or
> something else?
> 
> [2]:
> https://patchwork.dpdk.org/project/dpdk/patch/20230116130724.50277-
> 3...@smartsharesystems.com/
I think I might have forgotten it for some reason, 
I can pick it still as I can see it's still applicable I will take it to 
next-net-mlx directly, 

Kindest regards
Raslan Darawsheh

RE: [PATCH v6 01/23] mbuf: add accessors for rearm and Rx descriptor fields

[Morten Brørup]

+To: Thomas, previously joined the discussion

> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Tuesday, 27 February 2024 18.17
> 
> On Tue, Feb 27, 2024 at 10:10:03AM +0100, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > > Sent: Tuesday, 27 February 2024 06.41
> > >
> > > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Provide
> > > inline functions to access compatible type pointer to rearm_data
> > > and rx_descriptor_fields1 which will allow direct references on the
> > > rte marker fields to be removed.
> > >
> > > Signed-off-by: Tyler Retzlaff 
> > > ---
> > >  lib/mbuf/rte_mbuf.h  | 13 +
> > >  lib/mbuf/rte_mbuf_core.h | 11 ++-
> > >  2 files changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > > index 286b32b..aa7495b 100644
> > > --- a/lib/mbuf/rte_mbuf.h
> > > +++ b/lib/mbuf/rte_mbuf.h
> > > @@ -132,6 +132,19 @@
> > >  #endif
> > >  }
> > >
> > > +static inline
> > > +uint64_t *
> > > +rte_mbuf_rearm_data(struct rte_mbuf *m)
> > > +{
> > > + return (uint64_t *)&m->data_off;
> > > +}
> >
> > Consider returning (void *) instead of (uint64_t *).
> > Just a suggestion; I don't know which is better.
> 
> if you mean just the cast i don't think it matters.

No, I meant the return type.
The type is opaque; only its size is fixed at 8 byte.
Maybe uint64_t * is the best type, after all.

> arguably it could go
> void * first but we're already aliasing through a different type. this
> is one argument in favor of the union.

The zero-size markers (rearm_data and rx_descriptor_fields1) were intended to 
be used like unions, which the drivers effectively do.
Previous C standards didn't allow anonymous structures, so using union+struct 
in pre-C11 DPDK would clutter the code with subfield names. But now that we 
moved on to C11, we don't have this problem anymore.

IMHO, replacing the zero-size markers - which are directly visible in the 
structure's source code - with access functions located in some other header 
file degrades source code readability.

I am in favor of union+struct in the mbuf structure over access functions. I 
think the explicit grouping of the fields improves the readability of the mbuf 
structure, also compared to the zero-size markers.

> 
> >
> > > +
> > > +static inline
> > > +void *
> > > +rte_mbuf_rx_descriptor_fields1(struct rte_mbuf *m)
> > > +{
> > > + return &m->packet_type;
> > > +}
> >
> > The mbuf_rx_descriptor_fields1 field is disappearing in a later patch;
> > consider taking the opportunity to use a better name here.
> 
> oh boy. you're asking for a new name but not suggesting a new name.
> naming is hard (no one is ever happy). for this and rearm_data if you
> or anyone suggests a name i'll make the change ~everywhere including
> comments across all drivers.

As you mention below, keeping the current names is an advantage for familiarity.
Changing the name brings no real benefit, and although the current name is 
somewhat silly (perhaps anticipating a second group of rx descriptor fields), 
we should probably just keep it.

> 
> >
> > >
> > >  static inline uint16_t rte_pktmbuf_priv_size(struct rte_mempool *mp);
> > >
> > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > > index 5688683..7000c04 100644
> > > --- a/lib/mbuf/rte_mbuf_core.h
> > > +++ b/lib/mbuf/rte_mbuf_core.h
> > > @@ -486,7 +486,12 @@ struct rte_mbuf {
> > >   struct rte_mbuf *next;
> > >  #endif
> > >
> > > - /* next 8 bytes are initialised on RX descriptor rearm */
> > > + /**
> > > +  * next 8 bytes are initialised on RX descriptor rearm
> > > +  *
> > > +  * To obtain a pointer to rearm_data use the rte_mbuf_rearm_data()
> >
> > The "rearm_data" field is disappearing in a later patch;
> > don't refer to it by that name in the comments here.
> 
> without having renamed the block of fields cheerfully known as
> "rearm_data" i kept all documentation/comments here and in drivers
> using rearm_data for familiarity. (unless someone suggests a new name for the
> group
> of fields).

OK, you already thought about the use of the names in the documentation. I 
don't object to your conclusion.

> 
> >
> > > +  * accessor instead of directly referencing through the data_off field.
> > > +  */
> > >   RTE_MARKER64 rearm_data;
> > >   uint16_t data_off;
> > >
> > > @@ -522,6 +527,10 @@ struct rte_mbuf {
> > >* mbuf. Example: if vlan stripping is enabled, a received vlan packet
> > >* would have RTE_PTYPE_L2_ETHER and not RTE_PTYPE_L2_VLAN because the
> > >* vlan is stripped from the data.
> > > +  *
> > > +  * To obtain a pointer to rx_descriptor_fields1 use the
> > > +  * rte_mbuf_rx_descriptor_fields1() accessor instead of directly
> >
> > The "rx_descriptor_fields1" field is disappearing in a later patch;
> > don't refer to it by that name in the comments here.
> > And if you update the access function's name, remember to u

Re: [PATCH v9] net/bnx2x: fix warnings about rte_memcpy lengths

[Bruce Richardson]

On Tue, Feb 27, 2024 at 11:06:04AM -0800, Stephen Hemminger wrote:
> On Tue, 27 Feb 2024 12:27:31 +0100
> Morten Brørup  wrote:
> 
> > > > 1. The extra 2 byte copy is effectively harmless due to padding, as  
> > > mentioned in the commit message.  
> > > > 2. The decorated rte_memcpy (if work on that patch series is ever 
> > > > resumed)  
> > > is an improvement, not a bug fix, and will not be backported. So the 
> > > memcpy
> > > parts of this patch are irrelevant for the stable versions.
> 
> The function rte_memcpy only exists because glibc and gcc version of memcpy
> is not optimized enough. Would love to see it go away in future.

Definite +1.

Re: [PATCH 0/2] build eal & ring libraries with MSVC

[Bruce Richardson]

On Tue, Feb 27, 2024 at 11:21:58AM -0800, Tyler Retzlaff wrote:
> Enable build of eal & ring library when building with MSVC.
> 
> This series depends on 2 other series that seem to be near being
> accepted for merge.
> 
>   https://patches.dpdk.org/project/dpdk/list/?series=31229
>   https://patches.dpdk.org/project/dpdk/list/?series=31230
> 
> Since the rc2 deadline is soon this series is being submitted now
> to solicit feedback.  The CI is expected to fail without the above
> series being merged.
> 
> Tyler Retzlaff (2):
>   build: build eal library with MSVC
>   build: build ring library with MSVC
> 
>  config/meson.build   | 10 +-
>  lib/eal/include/rte_common.h |  2 ++
>  lib/meson.build  |  2 ++
>  3 files changed, 13 insertions(+), 1 deletion(-)
> 
Series-acked-by: Bruce Richardson 

RE: [EXT] Re: [PATCH v10 3/4] app/dma-perf: validate copied memory

[Gowrishankar Muthukrishnan]

Hi Fengchengwen,

> > +   for (i = 0; i < (nr_buf / nb_workers) * nb_workers; i++) {
> > +   if (memcmp(rte_pktmbuf_mtod(srcs[i], void *),
> > +  rte_pktmbuf_mtod(dsts[i], void *),
> > +  cfg->buf_size.cur) != 0) {
> > +   printf("Copy validation fails for buffer number %d\n",
> i);
> 
> For non-mem2mem DMA, like mem2dev or dev2mem, the device host
> address may not direct accessable by CPU (if could may need mmap).
> 

This has been checked in 4/4 patch as (cfg->transfer_dir == 
RTE_DMA_DIR_MEM_TO_MEM). Would you still need it in this patch only ?.

Thanks,
Gowrishankar

> So pls restrict it only mem2mem, or drop this commit.
> 
> Thanks

Re: [PATCH v3 3/7] dts: filter test suites in executions

[Juraj Linkeš]

On Tue, Feb 27, 2024 at 10:22 PM Jeremy Spewock  wrote:
>
> 
> > +
> > +lowercase_suite_to_find = (
> > +f"{self._test_suite_class_prefix}{module_name.replace('_', 
> > '')}".lower()
> > +)
> > +for class_name, class_obj in inspect.getmembers(test_suite_module, 
> > is_test_suite):
> > +if (
> > +class_name.startswith(self._test_suite_class_prefix)
>
> Is this line required? When we check later if the
> lowercase_suite_to_find is equal, we know that this variable we made
> starts with the designated prefix because that's just how we made it.
> It seems redundant because they could not be equal if the class name
> didn't start with the prefix. Is the idea behind this a type of
> optimization because this makes us ignore anything that doesn't have
> the proper prefix before going further?
>

There is a slight difference. The
class_name.startswith(self._test_suite_class_prefix) condition checks
uppercase characters as well. I'm not sure it's actually worth it.

Maybe we could change the name check to also check for the CamelCase
convention. I'll look into that.

> >
> > +and lowercase_suite_to_find == class_name.lower()
> > +):
> > +return class_obj
> > +raise ConfigurationError(
> > +f"Couldn't find any valid test suites in 
> > {test_suite_module.__name__}."
> > +)
> 

[PATCH v1] doc: update QAT compression doc IDs

[Sivaramakrishnan Venkat]

Missing GEN2, GEN3 and GEN4 devices updated for the QAT compression.

Signed-off-by: Sivaramakrishnan Venkat 
---
 doc/guides/compressdevs/qat_comp.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/compressdevs/qat_comp.rst 
b/doc/guides/compressdevs/qat_comp.rst
index 475c4a9f9f..7927119611 100644
--- a/doc/guides/compressdevs/qat_comp.rst
+++ b/doc/guides/compressdevs/qat_comp.rst
@@ -7,6 +7,10 @@ Intel(R) QuickAssist (QAT) Compression Poll Mode Driver
 The QAT compression PMD provides poll mode compression & decompression driver
 support for the following hardware accelerator devices:
 
+* ``Intel QuickAssist Technology D15xx``
+* ``Intel QuickAssist Technology 200xx``
+* ``Intel QuickAssist Technology C4xxx``
+* ``Intel QuickAssist Technology 4xxx``
 * ``Intel QuickAssist Technology C62x``
 * ``Intel QuickAssist Technology C3xxx``
 * ``Intel QuickAssist Technology DH895x``
-- 
2.25.1

RE: [PATCH 3/3] rcu: use rte macro instead of GCC attribute

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Wednesday, 28 February 2024 00.08
> 
> Use existing __rte_pure macro from rte_common.h instead of directly

Typo: __rte_pure -> __rte_may_alias

The code is correct, only the description has the typo.

> using __attribute__((__may_alias__)).
> 
> Signed-off-by: Tyler Retzlaff 
> ---

With the typo corrected,
For the series,
Reviewed-by: Morten Brørup 

Re: [PATCH v10 4/4] app/dma-perf: add SG copy support

[fengchengwen]

Hi Gowrishankar,

On 2024/2/28 2:56, Amit Prakash Shukla wrote:
> From: Gowrishankar Muthukrishnan 
> 
> Add SG copy support.
> 
> Signed-off-by: Gowrishankar Muthukrishnan 
> Acked-by: Anoob Joseph 
> Acked-by: Chengwen Feng 
> ---
> v10:
> - SG config variables renamed.
> 
>  app/test-dma-perf/benchmark.c | 278 +-
>  app/test-dma-perf/config.ini  |  25 ++-
>  app/test-dma-perf/main.c  |  34 -
>  app/test-dma-perf/main.h  |   5 +-
>  4 files changed, 300 insertions(+), 42 deletions(-)
> 
> diff --git a/app/test-dma-perf/benchmark.c b/app/test-dma-perf/benchmark.c
> index 0047e2f4b8..25ed6fa6d0 100644
> --- a/app/test-dma-perf/benchmark.c
> +++ b/app/test-dma-perf/benchmark.c
> @@ -46,6 +46,10 @@ struct lcore_params {
>   uint16_t test_secs;
>   struct rte_mbuf **srcs;
>   struct rte_mbuf **dsts;
> + struct rte_dma_sge *src_sges;
> + struct rte_dma_sge *dst_sges;
> + uint8_t src_ptrs;
> + uint8_t dst_ptrs;

1. src/dst_ptrs -> src/dst_nb_sge
2. How about wrap these four fields as a struct?

>   volatile struct worker_info worker_info;
>  };
>  
> @@ -86,21 +90,31 @@ calc_result(uint32_t buf_size, uint32_t nr_buf, uint16_t 
> nb_workers, uint16_t te
>  }
>  
>  static void
> -output_result(uint8_t scenario_id, uint32_t lcore_id, char *dma_name, 
> uint16_t ring_size,
> - uint16_t kick_batch, uint64_t ave_cycle, uint32_t 
> buf_size, uint32_t nr_buf,
> - float memory, float bandwidth, float mops, bool is_dma)
> +output_result(struct test_configure *cfg, struct lcore_params *para,
> + uint16_t kick_batch, uint64_t ave_cycle, uint32_t 
> buf_size,
> + uint32_t nr_buf, float memory, float bandwidth, float 
> mops)
>  {
> - if (is_dma)
> - printf("lcore %u, DMA %s, DMA Ring Size: %u, Kick Batch Size: 
> %u.\n",
> - lcore_id, dma_name, ring_size, kick_batch);
> - else
> + uint16_t ring_size = cfg->ring_size.cur;
> + uint8_t scenario_id = cfg->scenario_id;
> + uint32_t lcore_id = para->lcore_id;
> + char *dma_name = para->dma_name;
> +
> + if (cfg->is_dma) {
> + printf("lcore %u, DMA %s, DMA Ring Size: %u, Kick Batch Size: 
> %u", lcore_id,
> +dma_name, ring_size, kick_batch);
> + if (cfg->is_sg)
> + printf(" DMA src ptrs: %u, dst ptrs: %u",
> +para->src_ptrs, para->dst_ptrs);

DMA src sges: %u DMA dst sges: %u

I think we should add a column which title maybe misc, some like 
sg-src[4]-dst[1],
and later we may add fill test, then this field could be pattern-0x12345678

And in "[PATCH v10 2/4] app/dma-perf: add PCI device support" commit, if the 
DMA was
worked in non-mem2mem direction, we could add simple descriptor of direction 
and pcie.info
in the above misc column.

> + printf(".\n");
> + } else {
>   printf("lcore %u\n", lcore_id);
> + }
>  
>   printf("Average Cycles/op: %" PRIu64 ", Buffer Size: %u B, Buffer 
> Number: %u, Memory: %.2lf MB, Frequency: %.3lf Ghz.\n",
>   ave_cycle, buf_size, nr_buf, memory, 
> rte_get_timer_hz()/10.0);
>   printf("Average Bandwidth: %.3lf Gbps, MOps: %.3lf\n", bandwidth, mops);
>  
> - if (is_dma)
> + if (cfg->is_dma)
>   snprintf(output_str[lcore_id], MAX_OUTPUT_STR_LEN, 
> CSV_LINE_DMA_FMT,
>   scenario_id, lcore_id, dma_name, ring_size, kick_batch, 
> buf_size,
>   nr_buf, memory, ave_cycle, bandwidth, mops);
> @@ -167,7 +181,7 @@ vchan_data_populate(uint32_t dev_id, struct 
> rte_dma_vchan_conf *qconf,
>  
>  /* Configuration of device. */
>  static void
> -configure_dmadev_queue(uint32_t dev_id, struct test_configure *cfg)
> +configure_dmadev_queue(uint32_t dev_id, struct test_configure *cfg, uint8_t 
> ptrs_max)
>  {
>   uint16_t vchan = 0;
>   struct rte_dma_info info;
> @@ -190,6 +204,10 @@ configure_dmadev_queue(uint32_t dev_id, struct 
> test_configure *cfg)
>   rte_exit(EXIT_FAILURE, "Error, no configured queues reported on 
> device id. %u\n",
>   dev_id);
>  
> + if (info.max_sges < ptrs_max)
> + rte_exit(EXIT_FAILURE, "Error, DMA ptrs more than supported by 
> device id %u.\n",

"Error with unsupport max_sges on device id %u.\n"

> + dev_id);
> +
>   if (rte_dma_start(dev_id) != 0)
>   rte_exit(EXIT_FAILURE, "Error with dma start.\n");
>  }
> @@ -202,8 +220,12 @@ config_dmadevs(struct test_configure *cfg)
>   uint32_t i;
>   int dev_id;
>   uint16_t nb_dmadevs = 0;
> + uint8_t ptrs_max = 0;

It hard to understand, how about nb_sge?

>   char *dma_name;
>  
> + if (cfg->is_sg)
> + ptrs_max = RTE_MAX(cfg->src_ptrs, cfg->dst_ptrs);
> +
>   for (i = 0; i < ldm->cnt; i++) {
>  

RE: [EXT] Re: [PATCH v2] app/dma-perf: support bi-directional transfer

[Amit Prakash Shukla]

Hi Chengwen,

Please see my reply in-line.

Thanks
Amit Shukla

> -Original Message-
> From: fengchengwen 
> Sent: Wednesday, February 28, 2024 12:34 PM
> To: Amit Prakash Shukla ; Cheng Jiang
> ; Gowrishankar Muthukrishnan
> 
> Cc: dev@dpdk.org; Jerin Jacob ; Anoob Joseph
> ; Kevin Laatz ; Bruce
> Richardson ; Pavan Nikhilesh Bhagavatula
> 
> Subject: [EXT] Re: [PATCH v2] app/dma-perf: support bi-directional transfer
> 
> External Email
> 
> --
> Hi Amit and Gowrishankar,
> 
> It's nature to support multiple dmadev test in one testcase, and the original
> framework supports it.
> But it seem we both complicated it when adding support for non-mem2mem
> dma test.
> 
> The new added "direction" and "vchan_dev" could treat as the dmadev's
> private configure, some thing like:
> 
> lcore_dma=lcore10@:00:04.2,vchan=0,dir=mem2dev,devtype=pcie,radd
> r=xxx,coreid=1,pfid=2,vfid=3
> 
> then this bi-directional could impl only with config:
> 
> lcore_dma=lcore10@:00:04.2,dir=mem2dev,devtype=pcie,raddr=xxx,cor
> eid=1,pfid=2,vfid=3,
> lcore11@:00:04.3,dir=dev2mem,devtype=pcie,raddr=xxx,coreid=1,pfid=
> 2,vfid=3
> so that the lcore10 will do mem2dev with device :00:04.2, while lcore11
> will do dev2mem with device :00:04.3.

Thanks for the suggestion. I will make the suggested changes and send the next 
version.

[PATCH] net/mlx5: add HWS support for matching ingress metadata

[Michael Baum]

Add support for matching metadata in HWS ingress rules.
It using REG_B matching which is supported for each device supports HWS.

Signed-off-by: Michael Baum 
Reviewed-by: Erez Shitrit 
---
 drivers/net/mlx5/hws/mlx5dr.h |  1 +
 drivers/net/mlx5/hws/mlx5dr_definer.c | 32 ++-
 drivers/net/mlx5/mlx5_flow.h  | 16 --
 drivers/net/mlx5/mlx5_flow_dv.c   | 19 ++--
 drivers/net/mlx5/mlx5_flow_hw.c   | 23 +--
 5 files changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index d612f300c6..a323b29cb4 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -18,6 +18,7 @@ enum mlx5dr_table_type {
MLX5DR_TABLE_TYPE_NIC_TX,
MLX5DR_TABLE_TYPE_FDB,
MLX5DR_TABLE_TYPE_MAX,
+   MLX5DR_TABLE_TYPE_DONTCARE = MLX5DR_TABLE_TYPE_MAX,
 };
 
 enum mlx5dr_matcher_resource_mode {
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index e036aca781..9b3508471b 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -1741,6 +1741,7 @@ mlx5dr_definer_conv_item_tag(struct 
mlx5dr_definer_conv_data *cd,
if (item->type == RTE_FLOW_ITEM_TYPE_TAG)
reg = flow_hw_get_reg_id_from_ctx(cd->ctx,
  RTE_FLOW_ITEM_TYPE_TAG,
+ MLX5DR_TABLE_TYPE_DONTCARE,
  v->index);
else
reg = (int)v->index;
@@ -1801,9 +1802,10 @@ mlx5dr_definer_conv_item_quota(struct 
mlx5dr_definer_conv_data *cd,
   __rte_unused struct rte_flow_item *item,
   int item_idx)
 {
-   int mtr_reg =
-   flow_hw_get_reg_id_from_ctx(cd->ctx, RTE_FLOW_ITEM_TYPE_METER_COLOR,
-   0);
+   int mtr_reg = flow_hw_get_reg_id_from_ctx(cd->ctx,
+ 
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+ MLX5DR_TABLE_TYPE_DONTCARE,
+ 0);
struct mlx5dr_definer_fc *fc;
 
if (mtr_reg < 0) {
@@ -1822,6 +1824,7 @@ mlx5dr_definer_conv_item_quota(struct 
mlx5dr_definer_conv_data *cd,
 
 static int
 mlx5dr_definer_conv_item_metadata(struct mlx5dr_definer_conv_data *cd,
+ enum mlx5dr_table_type table_domain_type,
  struct rte_flow_item *item,
  int item_idx)
 {
@@ -1833,7 +1836,8 @@ mlx5dr_definer_conv_item_metadata(struct 
mlx5dr_definer_conv_data *cd,
if (!m)
return 0;
 
-   reg = flow_hw_get_reg_id_from_ctx(cd->ctx, RTE_FLOW_ITEM_TYPE_META, -1);
+   reg = flow_hw_get_reg_id_from_ctx(cd->ctx, RTE_FLOW_ITEM_TYPE_META,
+ table_domain_type, -1);
if (reg <= 0) {
DR_LOG(ERR, "Invalid register for item metadata");
rte_errno = EINVAL;
@@ -2140,8 +2144,9 @@ mlx5dr_definer_conv_item_conntrack(struct 
mlx5dr_definer_conv_data *cd,
if (!m)
return 0;
 
-   reg = flow_hw_get_reg_id_from_ctx(cd->ctx, RTE_FLOW_ITEM_TYPE_CONNTRACK,
- -1);
+   reg = flow_hw_get_reg_id_from_ctx(cd->ctx,
+ RTE_FLOW_ITEM_TYPE_CONNTRACK,
+ MLX5DR_TABLE_TYPE_DONTCARE, -1);
if (reg <= 0) {
DR_LOG(ERR, "Invalid register for item conntrack");
rte_errno = EINVAL;
@@ -2283,7 +2288,8 @@ mlx5dr_definer_conv_item_meter_color(struct 
mlx5dr_definer_conv_data *cd,
return 0;
 
reg = flow_hw_get_reg_id_from_ctx(cd->ctx,
- RTE_FLOW_ITEM_TYPE_METER_COLOR, 0);
+ RTE_FLOW_ITEM_TYPE_METER_COLOR,
+ MLX5DR_TABLE_TYPE_DONTCARE, 0);
MLX5_ASSERT(reg > 0);
 
fc = mlx5dr_definer_get_register_fc(cd, reg);
@@ -2878,6 +2884,7 @@ mlx5dr_definer_conv_item_compare_field(const struct 
rte_flow_field_data *f,
   const struct rte_flow_field_data 
*other_f,
   struct mlx5dr_definer_conv_data *cd,
   int item_idx,
+  enum mlx5dr_table_type table_domain_type,
   enum mlx5dr_definer_compare_dw_selectors 
dw_offset)
 {
struct mlx5dr_definer_fc *fc = NULL;
@@ -2892,7 +2899,8 @@ mlx5dr_definer_conv_item_compare_field(const struct 
rte_flow_field_data *f,
switch (f->field) {
case RTE_FLOW_FIELD_META:
reg = flow_hw_ge

[PATCH] net/mlx5/hws: enable multiple integrity items

[Michael Baum]

The integrity item uses the DW "oks1" in header layout. It includes the
all supported bits for both inner and outer. When item is integrity
type, the relevant bits are turned on and all DW is submitted.

When user provides more then single integrity item in same pattern, the
last one overrides the values were submitted before. This is problematic
when user wants to match integrity bits for both inner and outer in same
pattern, he cannot merge them into single item since rte_flow API
provides encapsulation level field to match either inner or outer.

This patch avoids the overriding values, when "oks1" is submitted,
operator "or" is used instead of regular set.

Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")
Cc: va...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Michael Baum 
Reviewed-by: Erez Shitrit 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index e036aca781..0e15aafb8a 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -44,6 +44,10 @@
  (bit_off))); \
} while (0)
 
+/* Getter function based on bit offset and mask, for 32bit DW*/
+#define DR_GET_32(p, byte_off, bit_off, mask) \
+   ((rte_be_to_cpu_32(*((const rte_be32_t *)(p) + ((byte_off) / 4))) >> 
(bit_off)) & (mask))
+
 /* Setter function based on bit offset and mask */
 #define DR_SET(p, v, byte_off, bit_off, mask) \
do { \
@@ -509,7 +513,7 @@ mlx5dr_definer_integrity_set(struct mlx5dr_definer_fc *fc,
 {
bool inner = (fc->fname == MLX5DR_DEFINER_FNAME_INTEGRITY_I);
const struct rte_flow_item_integrity *v = item_spec;
-   uint32_t ok1_bits = 0;
+   uint32_t ok1_bits = DR_GET_32(tag, fc->byte_off, fc->bit_off, 
fc->bit_mask);
 
if (v->l3_ok)
ok1_bits |= inner ? BIT(MLX5DR_DEFINER_OKS1_SECOND_L3_OK) :
-- 
2.25.1

Re: [EXT] [PATCH v1] app/test: fix segfault in Tx adapter autotest

[Jerin Jacob]

On Mon, Feb 26, 2024 at 6:30 PM Pavan Nikhilesh Bhagavatula
 wrote:
>
> > Uninitialized mbufs are enqueued to eventdev which causes segfault
> > on freeing the mbuf in tx adapter.
> > Fixed by initializing mbufs before enqueuing to eventdev.
> >
> > Fixes: 46cf97e4bbfa ("eventdev: add test for eth Tx adapter")
> >
> > Signed-off-by: Ganapati Kundapura 
>
> Acked-by: Pavan Nikhilesh 

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


>
> >
> > diff --git a/app/test/test_event_eth_tx_adapter.c
> > b/app/test/test_event_eth_tx_adapter.c
> > index dbd22f6..482b8e6 100644
> > --- a/app/test/test_event_eth_tx_adapter.c
> > +++ b/app/test/test_event_eth_tx_adapter.c
> > @@ -484,6 +484,10 @@ tx_adapter_service(void)
> >   int internal_port;
> >   uint32_t cap;
> >
> > + /* Initialize mbufs */
> > + for (i = 0; i < RING_SIZE; i++)
> > + rte_pktmbuf_reset(&bufs[i]);
> > +
> >   memset(&dev_conf, 0, sizeof(dev_conf));
> >   err = rte_event_eth_tx_adapter_caps_get(TEST_DEV_ID,
> > TEST_ETHDEV_ID,
> >   &cap);
> > --
> > 2.6.4
>

RE: [PATCH v4 1/2] net/mlx5: move meter init functions

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Dariusz Sosnowski 
> Sent: Tuesday, February 27, 2024 3:37 PM
> To: Slava Ovsiienko ; Ori Kam ;
> Suanming Mou ; Matan Azrad
> 
> Cc: dev@dpdk.org
> Subject: [PATCH v4 1/2] net/mlx5: move meter init functions
> 
> Move mlx5_flow_meter_init() and mlx5_flow_meter_uinit() to module for
> meter operations.
> 
> Signed-off-by: Dariusz Sosnowski 
> Acked-by: Ori Kam 

Series applied to next-net-mlx,

Kindest regards
Raslan Darawsheh

RE: [PATCH v3 0/4] net/mlx5: connection tracking changes

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Dariusz Sosnowski 
> Sent: Tuesday, February 27, 2024 3:52 PM
> To: Slava Ovsiienko ; Ori Kam ;
> Suanming Mou ; Matan Azrad
> 
> Cc: dev@dpdk.org
> Subject: [PATCH v3 0/4] net/mlx5: connection tracking changes
> 
> Patches 1 and 2 contain fixes for existing implementation of connection
> tracking flow actions.
> 
> Patch 3 adds support for sharing connection tracking flow actions between
> ports when ports' flow engines are configured with
> RTE_FLOW_PORT_FLAG_SHARE_INDIRECT flag set.
> 
> Patch 4 is based on the previous one and removes the limitation on number of
> ports when connection tracking flow actions are used with HW Steering flow
> engine.
> 
> Depends-on: series-31246 ("net/mlx5: move meter init functions")
> 
> v3:
> - Rebased.
> - Added Depends-on tag.
> 
> v2:
> - Rebased on top of v24.03-rc1
> - Updated mlx5 docs.
> 
> Dariusz Sosnowski (3):
>   net/mlx5: fix conntrack action handle representation
>   net/mlx5: fix connection tracking action validation
>   net/mlx5: remove port from conntrack handle representation
> 
> Suanming Mou (1):
>   net/mlx5: add cross port CT object sharing
> 
>  doc/guides/nics/mlx5.rst   |   4 +-
>  doc/guides/rel_notes/release_24_03.rst |   2 +
>  drivers/net/mlx5/mlx5_flow.h   |  20 ++-
>  drivers/net/mlx5/mlx5_flow_dv.c|   9 ++
>  drivers/net/mlx5/mlx5_flow_hw.c| 180 +
>  5 files changed, 123 insertions(+), 92 deletions(-)
> 
> --
> 2.25.1
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh

[RFC v5 0/6] Lcore variables

[Mattias Rönnblom]

This RFC presents a new API  for static per-lcore id
data allocation.

Please refer to the  API documentation for both a
rationale for this new API, and a comparison to the alternatives
available.

The adoption of this API would affect many different DPDK modules, but
the author updated only a few, mostly to serve as examples in this
RFC, and to iron out some, but surely not all, wrinkles in the API.

The question on how to best allocate static per-lcore memory has been
up several times on the dev mailing list, for example in the thread on
"random: use per lcore state" RFC by Stephen Hemminger.

Lcore variables are surely not the answer to all your per-lcore-data
needs, since it only allows for more-or-less static allocation. In the
author's opinion, it does however provide a reasonably simple and
clean and seemingly very much performant solution to a real problem.

One thing is unclear to the author is how this API relates to a
potential future per-lcore dynamic allocator (e.g., a per-lcore heap).

Contrary to what the version.map edit suggests, this RFC is not meant
for a proposal for DPDK 24.03.

Mattias Rönnblom (6):
  eal: add static per-lcore memory allocation facility
  eal: add lcore variable test suite
  random: keep PRNG state in lcore variable
  power: keep per-lcore state in lcore variable
  service: keep per-lcore state in lcore variable
  eal: keep per-lcore power intrinsics state in lcore variable

 app/test/meson.build  |   1 +
 app/test/test_lcore_var.c | 432 ++
 config/rte_config.h   |   1 +
 doc/api/doxy-api-index.md |   1 +
 lib/eal/common/eal_common_lcore_var.c |  68 
 lib/eal/common/meson.build|   1 +
 lib/eal/common/rte_random.c   |  30 +-
 lib/eal/common/rte_service.c  | 118 ---
 lib/eal/include/meson.build   |   1 +
 lib/eal/include/rte_lcore_var.h   | 368 ++
 lib/eal/version.map   |   4 +
 lib/eal/x86/rte_power_intrinsics.c|  17 +-
 lib/power/rte_power_pmd_mgmt.c|  36 +--
 13 files changed, 990 insertions(+), 88 deletions(-)
 create mode 100644 app/test/test_lcore_var.c
 create mode 100644 lib/eal/common/eal_common_lcore_var.c
 create mode 100644 lib/eal/include/rte_lcore_var.h

-- 
2.34.1

[RFC v5 1/6] eal: add static per-lcore memory allocation facility

[Mattias Rönnblom]

Introduce DPDK per-lcore id variables, or lcore variables for short.

An lcore variable has one value for every current and future lcore
id-equipped thread.

The primary  use case is for statically allocating
small chunks of often-used data, which is related logically, but where
there are performance benefits to reap from having updates being local
to an lcore.

Lcore variables are similar to thread-local storage (TLS, e.g., C11
_Thread_local), but decoupling the values' life time with that of the
threads.

Lcore variables are also similar in terms of functionality provided by
FreeBSD kernel's DPCPU_*() family of macros and the associated
build-time machinery. DPCPU uses linker scripts, which effectively
prevents the reuse of its, otherwise seemingly viable, approach.

The currently-prevailing way to solve the same problem as lcore
variables is to keep a module's per-lcore data as RTE_MAX_LCORE-sized
array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of
lcore variables over this approach is that data related to the same
lcore now is close (spatially, in memory), rather than data used by
the same module, which in turn avoid excessive use of padding,
polluting caches with unused data.

RFC v5:
 * In Doxygen, consistenly use @ (and not \).
 * The RTE_LCORE_VAR_GET() and SET() convience access macros
   covered an uncommon use case, where the lcore value is of a
   primitive type, rather than a struct, and is thus eliminated
   from the API. (Morten Brørup)
 * In the wake up GET()/SET() removeal, rename RTE_LCORE_VAR_PTR()
   RTE_LCORE_VAR_VALUE().
 * The underscores are removed from __rte_lcore_var_lcore_ptr() to
   signal that this function is a part of the public API.
 * Macro arguments are documented.

RFV v4:
 * Replace large static array with libc heap-allocated memory. One
   implication of this change is there no longer exists a fixed upper
   bound for the total amount of memory used by lcore variables.
   RTE_MAX_LCORE_VAR has changed meaning, and now represent the
   maximum size of any individual lcore variable value.
 * Fix issues in example. (Morten Brørup)
 * Improve access macro type checking. (Morten Brørup)
 * Refer to the lcore variable handle as "handle" and not "name" in
   various macros.
 * Document lack of thread safety in rte_lcore_var_alloc().
 * Provide API-level assurance the lcore variable handle is
   always non-NULL, to all applications to use NULL to mean
   "not yet allocated".
 * Note zero-sized allocations are not allowed.
 * Give API-level guarantee the lcore variable values are zeroed.

RFC v3:
 * Replace use of GCC-specific alignof() with alignof().
 * Update example to reflect FOREACH macro name change (in RFC v2).

RFC v2:
 * Use alignof to derive alignment requirements. (Morten Brørup)
 * Change name of FOREACH to make it distinct from 's
   *per-EAL-thread* RTE_LCORE_FOREACH(). (Morten Brørup)
 * Allow user-specified alignment, but limit max to cache line size.

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 config/rte_config.h   |   1 +
 doc/api/doxy-api-index.md |   1 +
 lib/eal/common/eal_common_lcore_var.c |  68 +
 lib/eal/common/meson.build|   1 +
 lib/eal/include/meson.build   |   1 +
 lib/eal/include/rte_lcore_var.h   | 368 ++
 lib/eal/version.map   |   4 +
 7 files changed, 444 insertions(+)
 create mode 100644 lib/eal/common/eal_common_lcore_var.c
 create mode 100644 lib/eal/include/rte_lcore_var.h

diff --git a/config/rte_config.h b/config/rte_config.h
index d743a5c3d3..0dac33d3b9 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -41,6 +41,7 @@
 /* EAL defines */
 #define RTE_CACHE_GUARD_LINES 1
 #define RTE_MAX_HEAPS 32
+#define RTE_MAX_LCORE_VAR 1048576
 #define RTE_MAX_MEMSEG_LISTS 128
 #define RTE_MAX_MEMSEG_PER_LIST 8192
 #define RTE_MAX_MEM_MB_PER_LIST 32768
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 8c1eb8fafa..a3b8391570 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -99,6 +99,7 @@ The public API headers are grouped by topics:
   [interrupts](@ref rte_interrupts.h),
   [launch](@ref rte_launch.h),
   [lcore](@ref rte_lcore.h),
+  [lcore-varible](@ref rte_lcore_var.h),
   [per-lcore](@ref rte_per_lcore.h),
   [service cores](@ref rte_service.h),
   [keepalive](@ref rte_keepalive.h),
diff --git a/lib/eal/common/eal_common_lcore_var.c 
b/lib/eal/common/eal_common_lcore_var.c
new file mode 100644
index 00..5c353ebd46
--- /dev/null
+++ b/lib/eal/common/eal_common_lcore_var.c
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2024 Ericsson AB
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "eal_private.h"
+
+#define LCORE_BUFFER_SIZE (RTE_MAX_LCORE_VAR * RTE_MAX_LCORE)
+
+static void *lcore_buffer;
+static size_t offset = RTE_MAX_LCORE_VAR;
+
+static void *
+lcore_var_alloc(size_t size, size_t align)
+{
+ 

[RFC v5 2/6] eal: add lcore variable test suite

[Mattias Rönnblom]

Add test suite to exercise the  API.

RFC v5:
 * Adapt tests to reflect the removal of the GET() and SET() macros.

RFC v4:
 * Check all lcore id's values for all variables in the many variables
   test case.
 * Introduce test case for max-sized lcore variables.

RFC v2:
 * Improve alignment-related test coverage.

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 app/test/meson.build  |   1 +
 app/test/test_lcore_var.c | 432 ++
 2 files changed, 433 insertions(+)
 create mode 100644 app/test/test_lcore_var.c

diff --git a/app/test/meson.build b/app/test/meson.build
index 7d909039ae..846affa98c 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -103,6 +103,7 @@ source_file_deps = {
 'test_ipsec_sad.c': ['ipsec'],
 'test_kvargs.c': ['kvargs'],
 'test_latencystats.c': ['ethdev', 'latencystats', 'metrics'] + 
sample_packet_forward_deps,
+'test_lcore_var.c': [],
 'test_lcores.c': [],
 'test_link_bonding.c': ['ethdev', 'net_bond',
 'net'] + packet_burst_generator_deps + virtual_pmd_deps,
diff --git a/app/test/test_lcore_var.c b/app/test/test_lcore_var.c
new file mode 100644
index 00..e07d13460f
--- /dev/null
+++ b/app/test/test_lcore_var.c
@@ -0,0 +1,432 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2024 Ericsson AB
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+#define MIN_LCORES 2
+
+RTE_LCORE_VAR_HANDLE(int, test_int);
+RTE_LCORE_VAR_HANDLE(char, test_char);
+RTE_LCORE_VAR_HANDLE(long, test_long_sized);
+RTE_LCORE_VAR_HANDLE(short, test_short);
+RTE_LCORE_VAR_HANDLE(long, test_long_sized_aligned);
+
+struct int_checker_state {
+   int old_value;
+   int new_value;
+   bool success;
+};
+
+static void
+rand_blk(void *blk, size_t size)
+{
+   size_t i;
+
+   for (i = 0; i < size; i++)
+   ((unsigned char *)blk)[i] = (unsigned char)rte_rand();
+}
+
+static bool
+is_ptr_aligned(const void *ptr, size_t align)
+{
+   return ptr != NULL ? (uintptr_t)ptr % align == 0 : false;
+}
+
+static int
+check_int(void *arg)
+{
+   struct int_checker_state *state = arg;
+
+   int *ptr = RTE_LCORE_VAR_VALUE(test_int);
+
+   bool naturally_aligned = is_ptr_aligned(ptr, sizeof(int));
+
+   bool equal = *(RTE_LCORE_VAR_VALUE(test_int)) == state->old_value;
+
+   state->success = equal && naturally_aligned;
+
+   *ptr = state->new_value;
+
+   return 0;
+}
+
+RTE_LCORE_VAR_INIT(test_int);
+RTE_LCORE_VAR_INIT(test_char);
+RTE_LCORE_VAR_INIT_SIZE(test_long_sized, 32);
+RTE_LCORE_VAR_INIT(test_short);
+RTE_LCORE_VAR_INIT_SIZE_ALIGN(test_long_sized_aligned, sizeof(long),
+ RTE_CACHE_LINE_SIZE);
+
+static int
+test_int_lvar(void)
+{
+   unsigned int lcore_id;
+
+   struct int_checker_state states[RTE_MAX_LCORE] = {};
+
+   RTE_LCORE_FOREACH_WORKER(lcore_id) {
+   struct int_checker_state *state = &states[lcore_id];
+
+   state->old_value = (int)rte_rand();
+   state->new_value = (int)rte_rand();
+
+   *RTE_LCORE_VAR_LCORE_VALUE(lcore_id, test_int) =
+   state->old_value;
+   }
+
+   RTE_LCORE_FOREACH_WORKER(lcore_id)
+   rte_eal_remote_launch(check_int, &states[lcore_id], lcore_id);
+
+   rte_eal_mp_wait_lcore();
+
+   RTE_LCORE_FOREACH_WORKER(lcore_id) {
+   struct int_checker_state *state = &states[lcore_id];
+   int value;
+
+   TEST_ASSERT(state->success, "Unexpected value "
+   "encountered on lcore %d", lcore_id);
+
+   value = *RTE_LCORE_VAR_LCORE_VALUE(lcore_id, test_int);
+   TEST_ASSERT_EQUAL(state->new_value, value,
+ "Lcore %d failed to update int", lcore_id);
+   }
+
+   /* take the opportunity to test the foreach macro */
+   int *v;
+   lcore_id = 0;
+   RTE_LCORE_VAR_FOREACH_VALUE(v, test_int) {
+   TEST_ASSERT_EQUAL(states[lcore_id].new_value, *v,
+ "Unexpected value on lcore %d during "
+ "iteration", lcore_id);
+   lcore_id++;
+   }
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_sized_alignment(void)
+{
+   long *v;
+
+   RTE_LCORE_VAR_FOREACH_VALUE(v, test_long_sized) {
+   TEST_ASSERT(is_ptr_aligned(v, alignof(long)),
+   "Type-derived alignment failed");
+   }
+
+   RTE_LCORE_VAR_FOREACH_VALUE(v, test_long_sized_aligned) {
+   TEST_ASSERT(is_ptr_aligned(v, RTE_CACHE_LINE_SIZE),
+   "Explicit alignment failed");
+   }
+
+   return TEST_SUCCESS;
+}
+
+/* private, larger, struct */
+#define TEST_STRUCT_DATA_SIZE 1234
+
+struct test_struct {
+   uint8_t data[TEST_STRUCT_DATA_SIZE];
+};
+
+static RTE_LCORE_VAR_HANDLE(char, b

[RFC v5 3/6] random: keep PRNG state in lcore variable

[Mattias Rönnblom]

Replace keeping PRNG state in a RTE_MAX_LCORE-sized static array of
cache-aligned and RTE_CACHE_GUARDed struct instances with keeping the
same state in a more cache-friendly lcore variable.

RFC v3:
 * Remove cache alignment on unregistered threads' rte_rand_state.
   (Morten Brørup)

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 lib/eal/common/rte_random.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
index 7709b8f2c6..b265660283 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct rte_rand_state {
@@ -19,14 +20,12 @@ struct rte_rand_state {
uint64_t z3;
uint64_t z4;
uint64_t z5;
-   RTE_CACHE_GUARD;
-} __rte_cache_aligned;
+};
 
-/* One instance each for every lcore id-equipped thread, and one
- * additional instance to be shared by all others threads (i.e., all
- * unregistered non-EAL threads).
- */
-static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1];
+RTE_LCORE_VAR_HANDLE(struct rte_rand_state, rand_state);
+
+/* instance to be shared by all unregistered non-EAL threads */
+static struct rte_rand_state unregistered_rand_state;
 
 static uint32_t
 __rte_rand_lcg32(uint32_t *seed)
@@ -85,8 +84,14 @@ rte_srand(uint64_t seed)
unsigned int lcore_id;
 
/* add lcore_id to seed to avoid having the same sequence */
-   for (lcore_id = 0; lcore_id < RTE_DIM(rand_states); lcore_id++)
-   __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
+   for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+   struct rte_rand_state *lcore_state =
+   RTE_LCORE_VAR_LCORE_VALUE(lcore_id, rand_state);
+
+   __rte_srand_lfsr258(seed + lcore_id, lcore_state);
+   }
+
+   __rte_srand_lfsr258(seed + lcore_id, &unregistered_rand_state);
 }
 
 static __rte_always_inline uint64_t
@@ -124,11 +129,10 @@ struct rte_rand_state *__rte_rand_get_state(void)
 
idx = rte_lcore_id();
 
-   /* last instance reserved for unregistered non-EAL threads */
if (unlikely(idx == LCORE_ID_ANY))
-   idx = RTE_MAX_LCORE;
+   return &unregistered_rand_state;
 
-   return &rand_states[idx];
+   return RTE_LCORE_VAR_VALUE(rand_state);
 }
 
 uint64_t
@@ -228,6 +232,8 @@ RTE_INIT(rte_rand_init)
 {
uint64_t seed;
 
+   RTE_LCORE_VAR_ALLOC(rand_state);
+
seed = __rte_random_initial_seed();
 
rte_srand(seed);
-- 
2.34.1

[RFC v5 4/6] power: keep per-lcore state in lcore variable

[Mattias Rönnblom]

Replace static array of cache-aligned structs with an lcore variable,
to slightly benefit code simplicity and performance.

RFC v3:
 * Replace for loop with FOREACH macro.

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 lib/power/rte_power_pmd_mgmt.c | 36 --
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/lib/power/rte_power_pmd_mgmt.c b/lib/power/rte_power_pmd_mgmt.c
index 591fc69f36..595c8091e6 100644
--- a/lib/power/rte_power_pmd_mgmt.c
+++ b/lib/power/rte_power_pmd_mgmt.c
@@ -5,6 +5,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -68,8 +69,8 @@ struct pmd_core_cfg {
/**< Number of queues ready to enter power optimized state */
uint64_t sleep_target;
/**< Prevent a queue from triggering sleep multiple times */
-} __rte_cache_aligned;
-static struct pmd_core_cfg lcore_cfgs[RTE_MAX_LCORE];
+};
+static RTE_LCORE_VAR_HANDLE(struct pmd_core_cfg, lcore_cfgs);
 
 static inline bool
 queue_equal(const union queue *l, const union queue *r)
@@ -252,12 +253,11 @@ clb_multiwait(uint16_t port_id __rte_unused, uint16_t 
qidx __rte_unused,
struct rte_mbuf **pkts __rte_unused, uint16_t nb_rx,
uint16_t max_pkts __rte_unused, void *arg)
 {
-   const unsigned int lcore = rte_lcore_id();
struct queue_list_entry *queue_conf = arg;
struct pmd_core_cfg *lcore_conf;
const bool empty = nb_rx == 0;
 
-   lcore_conf = &lcore_cfgs[lcore];
+   lcore_conf = RTE_LCORE_VAR_VALUE(lcore_cfgs);
 
/* early exit */
if (likely(!empty))
@@ -317,13 +317,12 @@ clb_pause(uint16_t port_id __rte_unused, uint16_t qidx 
__rte_unused,
struct rte_mbuf **pkts __rte_unused, uint16_t nb_rx,
uint16_t max_pkts __rte_unused, void *arg)
 {
-   const unsigned int lcore = rte_lcore_id();
struct queue_list_entry *queue_conf = arg;
struct pmd_core_cfg *lcore_conf;
const bool empty = nb_rx == 0;
uint32_t pause_duration = rte_power_pmd_mgmt_get_pause_duration();
 
-   lcore_conf = &lcore_cfgs[lcore];
+   lcore_conf = RTE_LCORE_VAR_VALUE(lcore_cfgs);
 
if (likely(!empty))
/* early exit */
@@ -358,9 +357,8 @@ clb_scale_freq(uint16_t port_id __rte_unused, uint16_t qidx 
__rte_unused,
struct rte_mbuf **pkts __rte_unused, uint16_t nb_rx,
uint16_t max_pkts __rte_unused, void *arg)
 {
-   const unsigned int lcore = rte_lcore_id();
const bool empty = nb_rx == 0;
-   struct pmd_core_cfg *lcore_conf = &lcore_cfgs[lcore];
+   struct pmd_core_cfg *lcore_conf = RTE_LCORE_VAR_VALUE(lcore_cfgs);
struct queue_list_entry *queue_conf = arg;
 
if (likely(!empty)) {
@@ -518,7 +516,7 @@ rte_power_ethdev_pmgmt_queue_enable(unsigned int lcore_id, 
uint16_t port_id,
goto end;
}
 
-   lcore_cfg = &lcore_cfgs[lcore_id];
+   lcore_cfg = RTE_LCORE_VAR_LCORE_VALUE(lcore_id, lcore_cfgs);
 
/* check if other queues are stopped as well */
ret = cfg_queues_stopped(lcore_cfg);
@@ -619,7 +617,7 @@ rte_power_ethdev_pmgmt_queue_disable(unsigned int lcore_id,
}
 
/* no need to check queue id as wrong queue id would not be enabled */
-   lcore_cfg = &lcore_cfgs[lcore_id];
+   lcore_cfg = RTE_LCORE_VAR_LCORE_VALUE(lcore_id, lcore_cfgs);
 
/* check if other queues are stopped as well */
ret = cfg_queues_stopped(lcore_cfg);
@@ -769,21 +767,21 @@ rte_power_pmd_mgmt_get_scaling_freq_max(unsigned int 
lcore)
 }
 
 RTE_INIT(rte_power_ethdev_pmgmt_init) {
-   size_t i;
-   int j;
+   struct pmd_core_cfg *lcore_cfg;
+   int i;
+
+   RTE_LCORE_VAR_ALLOC(lcore_cfgs);
 
/* initialize all tailqs */
-   for (i = 0; i < RTE_DIM(lcore_cfgs); i++) {
-   struct pmd_core_cfg *cfg = &lcore_cfgs[i];
-   TAILQ_INIT(&cfg->head);
-   }
+   RTE_LCORE_VAR_FOREACH_VALUE(lcore_cfg, lcore_cfgs)
+   TAILQ_INIT(&lcore_cfg->head);
 
/* initialize config defaults */
emptypoll_max = 512;
pause_duration = 1;
/* scaling defaults out of range to ensure not used unless set by user 
or app */
-   for (j = 0; j < RTE_MAX_LCORE; j++) {
-   scale_freq_min[j] = 0;
-   scale_freq_max[j] = UINT32_MAX;
+   for (i = 0; i < RTE_MAX_LCORE; i++) {
+   scale_freq_min[i] = 0;
+   scale_freq_max[i] = UINT32_MAX;
}
 }
-- 
2.34.1

[RFC v5 6/6] eal: keep per-lcore power intrinsics state in lcore variable

[Mattias Rönnblom]

Keep per-lcore power intrinsics state in a lcore variable to reduce
cache working set size and avoid any CPU next-line-prefetching causing
false sharing.

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 lib/eal/x86/rte_power_intrinsics.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index 532a2e646b..23d1761f0a 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -12,10 +13,14 @@
 /*
  * Per-lcore structure holding current status of C0.2 sleeps.
  */
-static struct power_wait_status {
+struct power_wait_status {
rte_spinlock_t lock;
volatile void *monitor_addr; /**< NULL if not currently sleeping */
-} __rte_cache_aligned wait_status[RTE_MAX_LCORE];
+};
+
+RTE_LCORE_VAR_HANDLE(struct power_wait_status, wait_status);
+
+RTE_LCORE_VAR_INIT(wait_status);
 
 /*
  * This function uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
@@ -170,7 +175,7 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
if (pmc->fn == NULL)
return -EINVAL;
 
-   s = &wait_status[lcore_id];
+   s = RTE_LCORE_VAR_LCORE_VALUE(lcore_id, wait_status);
 
/* update sleep address */
rte_spinlock_lock(&s->lock);
@@ -262,7 +267,7 @@ rte_power_monitor_wakeup(const unsigned int lcore_id)
if (lcore_id >= RTE_MAX_LCORE)
return -EINVAL;
 
-   s = &wait_status[lcore_id];
+   s = RTE_LCORE_VAR_LCORE_VALUE(lcore_id, wait_status);
 
/*
 * There is a race condition between sleep, wakeup and locking, but we
@@ -301,8 +306,8 @@ int
 rte_power_monitor_multi(const struct rte_power_monitor_cond pmc[],
const uint32_t num, const uint64_t tsc_timestamp)
 {
-   const unsigned int lcore_id = rte_lcore_id();
-   struct power_wait_status *s = &wait_status[lcore_id];
+   struct power_wait_status *s = RTE_LCORE_VAR_VALUE(wait_status);
+
uint32_t i, rc;
 
/* check if supported */
-- 
2.34.1

[RFC v5 5/6] service: keep per-lcore state in lcore variable

[Mattias Rönnblom]

Replace static array of cache-aligned structs with an lcore variable,
to slightly benefit code simplicity and performance.

RFC v5:
 * Fix lcore value pointer bug introduced by RFC v4.

RFC v4:
 * Remove strange-looking lcore value lookup potentially containing
   invalid lcore id. (Morten Brørup)
 * Replace misplaced tab with space. (Morten Brørup)

Signed-off-by: Mattias Rönnblom 
Acked-by: Morten Brørup 
---
 lib/eal/common/rte_service.c | 118 ---
 1 file changed, 67 insertions(+), 51 deletions(-)

diff --git a/lib/eal/common/rte_service.c b/lib/eal/common/rte_service.c
index d959c91459..5429ddce41 100644
--- a/lib/eal/common/rte_service.c
+++ b/lib/eal/common/rte_service.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,7 +76,7 @@ struct core_state {
 
 static uint32_t rte_service_count;
 static struct rte_service_spec_impl *rte_services;
-static struct core_state *lcore_states;
+static RTE_LCORE_VAR_HANDLE(struct core_state, lcore_states);
 static uint32_t rte_service_library_initialized;
 
 int32_t
@@ -101,11 +102,12 @@ rte_service_init(void)
goto fail_mem;
}
 
-   lcore_states = rte_calloc("rte_service_core_states", RTE_MAX_LCORE,
-   sizeof(struct core_state), RTE_CACHE_LINE_SIZE);
-   if (!lcore_states) {
-   EAL_LOG(ERR, "error allocating core states array");
-   goto fail_mem;
+   if (lcore_states == NULL)
+   RTE_LCORE_VAR_ALLOC(lcore_states);
+   else {
+   struct core_state *cs;
+   RTE_LCORE_VAR_FOREACH_VALUE(cs, lcore_states)
+   memset(cs, 0, sizeof(struct core_state));
}
 
int i;
@@ -122,7 +124,6 @@ rte_service_init(void)
return 0;
 fail_mem:
rte_free(rte_services);
-   rte_free(lcore_states);
return -ENOMEM;
 }
 
@@ -136,7 +137,6 @@ rte_service_finalize(void)
rte_eal_mp_wait_lcore();
 
rte_free(rte_services);
-   rte_free(lcore_states);
 
rte_service_library_initialized = 0;
 }
@@ -286,7 +286,6 @@ rte_service_component_register(const struct 
rte_service_spec *spec,
 int32_t
 rte_service_component_unregister(uint32_t id)
 {
-   uint32_t i;
struct rte_service_spec_impl *s;
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
 
@@ -294,9 +293,10 @@ rte_service_component_unregister(uint32_t id)
 
s->internal_flags &= ~(SERVICE_F_REGISTERED);
 
+   struct core_state *cs;
/* clear the run-bit in all cores */
-   for (i = 0; i < RTE_MAX_LCORE; i++)
-   lcore_states[i].service_mask &= ~(UINT64_C(1) << id);
+   RTE_LCORE_VAR_FOREACH_VALUE(cs, lcore_states)
+   cs->service_mask &= ~(UINT64_C(1) << id);
 
memset(&rte_services[id], 0, sizeof(struct rte_service_spec_impl));
 
@@ -454,7 +454,10 @@ rte_service_may_be_active(uint32_t id)
return -EINVAL;
 
for (i = 0; i < lcore_count; i++) {
-   if (lcore_states[ids[i]].service_active_on_lcore[id])
+   struct core_state *cs =
+   RTE_LCORE_VAR_LCORE_VALUE(ids[i], lcore_states);
+
+   if (cs->service_active_on_lcore[id])
return 1;
}
 
@@ -464,7 +467,7 @@ rte_service_may_be_active(uint32_t id)
 int32_t
 rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t serialize_mt_unsafe)
 {
-   struct core_state *cs = &lcore_states[rte_lcore_id()];
+   struct core_state *cs = RTE_LCORE_VAR_VALUE(lcore_states);
struct rte_service_spec_impl *s;
 
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
@@ -486,8 +489,7 @@ service_runner_func(void *arg)
 {
RTE_SET_USED(arg);
uint8_t i;
-   const int lcore = rte_lcore_id();
-   struct core_state *cs = &lcore_states[lcore];
+   struct core_state *cs = RTE_LCORE_VAR_VALUE(lcore_states);
 
rte_atomic_store_explicit(&cs->thread_active, 1, 
rte_memory_order_seq_cst);
 
@@ -533,13 +535,15 @@ service_runner_func(void *arg)
 int32_t
 rte_service_lcore_may_be_active(uint32_t lcore)
 {
-   if (lcore >= RTE_MAX_LCORE || !lcore_states[lcore].is_service_core)
+   struct core_state *cs = RTE_LCORE_VAR_LCORE_VALUE(lcore, lcore_states);
+
+   if (lcore >= RTE_MAX_LCORE || !cs->is_service_core)
return -EINVAL;
 
/* Load thread_active using ACQUIRE to avoid instructions dependent on
 * the result being re-ordered before this load completes.
 */
-   return rte_atomic_load_explicit(&lcore_states[lcore].thread_active,
+   return rte_atomic_load_explicit(&cs->thread_active,
   rte_memory_order_acquire);
 }
 
@@ -547,9 +551,11 @@ int32_t
 rte_service_lcore_count(void)
 {
int32_t count = 0;
-   uint32_t i;
-   for (i = 0; i < RTE_MAX_LCORE; i++)
-   count += lcore_states[i].is_service_core;
+
+   struct core_sta

[PATCH v2 0/4] net/mlx5: add support for flow table resizing

[Gregory Etelson]

Support template table resize API.

Gregory Etelson (3):
  net/mlx5: fix parameters verification in HWS table create
  net/mlx5: move multi-pattern actions management to table level
  net/mlx5: add support for flow table resizing

Maayan Kashani (1):
  net/mlx5: add resize function to ipool

 drivers/net/mlx5/mlx5.h |   5 +
 drivers/net/mlx5/mlx5_flow.c|  51 +++
 drivers/net/mlx5/mlx5_flow.h| 101 -
 drivers/net/mlx5/mlx5_flow_hw.c | 750 +++-
 drivers/net/mlx5/mlx5_utils.c   |  29 ++
 drivers/net/mlx5/mlx5_utils.h   |  16 +
 6 files changed, 752 insertions(+), 200 deletions(-)

Acked-by: Dariusz Sosnowski 

--
v2: Update PMD after DPDK API changes.
-- 
2.39.2

[PATCH v2 1/4] net/mlx5: add resize function to ipool

[Gregory Etelson]

From: Maayan Kashani 

Before this patch, ipool size could be fixed by
setting max_idx in mlx5_indexed_pool_config upon
ipool creation. Or it can be auto resized to the
maximum limit by setting max_idx to zero upon
ipool creation and the saved value is the maximum
index possible.
This patch adds ipool_resize API that enables to
update the value of max_idx in case it is not set to
maximum, meaning not in auto resize mode. It
enables the allocation of new trunk when using
malloc/zmalloc up to the max_idx limit. Please
notice the resize number of entries should be divisible by trunk_size.

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_utils.c | 29 +
 drivers/net/mlx5/mlx5_utils.h | 16 
 2 files changed, 45 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_utils.c b/drivers/net/mlx5/mlx5_utils.c
index 4db738785f..e28db2ec43 100644
--- a/drivers/net/mlx5/mlx5_utils.c
+++ b/drivers/net/mlx5/mlx5_utils.c
@@ -809,6 +809,35 @@ mlx5_ipool_get_next(struct mlx5_indexed_pool *pool, 
uint32_t *pos)
return NULL;
 }
 
+int
+mlx5_ipool_resize(struct mlx5_indexed_pool *pool, uint32_t num_entries)
+{
+   uint32_t cur_max_idx;
+   uint32_t max_index = mlx5_trunk_idx_offset_get(pool, TRUNK_MAX_IDX + 1);
+
+   if (num_entries % pool->cfg.trunk_size) {
+   DRV_LOG(ERR, "num_entries param should be trunk_size(=%u) 
multiplication\n",
+   pool->cfg.trunk_size);
+   return -EINVAL;
+   }
+
+   mlx5_ipool_lock(pool);
+   cur_max_idx = pool->cfg.max_idx + num_entries;
+   /* If the ipool max idx is above maximum or uint overflow occurred. */
+   if (cur_max_idx > max_index || cur_max_idx < num_entries) {
+   DRV_LOG(ERR, "Ipool resize failed\n");
+   DRV_LOG(ERR, "Adding %u entries to existing %u entries, will 
cross max limit(=%u)\n",
+   num_entries, cur_max_idx, max_index);
+   mlx5_ipool_unlock(pool);
+   return -EINVAL;
+   }
+
+   /* Update maximum entries number. */
+   pool->cfg.max_idx = cur_max_idx;
+   mlx5_ipool_unlock(pool);
+   return 0;
+}
+
 void
 mlx5_ipool_dump(struct mlx5_indexed_pool *pool)
 {
diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
index 82e8298781..f3c0d76a6d 100644
--- a/drivers/net/mlx5/mlx5_utils.h
+++ b/drivers/net/mlx5/mlx5_utils.h
@@ -427,6 +427,22 @@ void mlx5_ipool_flush_cache(struct mlx5_indexed_pool 
*pool);
  */
 void *mlx5_ipool_get_next(struct mlx5_indexed_pool *pool, uint32_t *pos);
 
+/**
+ * This function resize the ipool.
+ *
+ * @param pool
+ *   Pointer to the index memory pool handler.
+ * @param num_entries
+ *   Number of entries to be added to the pool.
+ *   This number should be divisible by trunk_size.
+ *
+ * @return
+ *   - non-zero value on error.
+ *   - 0 on success.
+ *
+ */
+int mlx5_ipool_resize(struct mlx5_indexed_pool *pool, uint32_t num_entries);
+
 /**
  * This function allocates new empty Three-level table.
  *
-- 
2.39.2

[PATCH v2 2/4] net/mlx5: fix parameters verification in HWS table create

[Gregory Etelson]

Modified the conditionals in `flow_hw_table_create()` to use bitwise
AND instead of equality checks when assessing
`table_cfg->attr->specialize` bitmask.
This will allow for greater flexibility as the bitmask may encapsulate
multiple flags.
The patch maintains the previous behavior with single flag values,
while providing support for multiple flags.

Fixes: 592d5367b5e4 ("net/mlx5: enable hint in async flow table")
Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 783ad9e72a..5938d8b90c 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -4390,12 +4390,23 @@ flow_hw_table_create(struct rte_eth_dev *dev,
matcher_attr.rule.num_log = rte_log2_u32(nb_flows);
/* Parse hints information. */
if (attr->specialize) {
-   if (attr->specialize == 
RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG)
-   matcher_attr.optimize_flow_src = 
MLX5DR_MATCHER_FLOW_SRC_WIRE;
-   else if (attr->specialize == 
RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG)
-   matcher_attr.optimize_flow_src = 
MLX5DR_MATCHER_FLOW_SRC_VPORT;
-   else
-   DRV_LOG(INFO, "Unsupported hint value %x", 
attr->specialize);
+   uint32_t val = RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG |
+  RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG;
+
+   if ((attr->specialize & val) == val) {
+   DRV_LOG(INFO, "Invalid hint value %x",
+   attr->specialize);
+   rte_errno = EINVAL;
+   goto it_error;
+   }
+   if (attr->specialize &
+   RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG)
+   matcher_attr.optimize_flow_src =
+   MLX5DR_MATCHER_FLOW_SRC_WIRE;
+   else if (attr->specialize &
+RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG)
+   matcher_attr.optimize_flow_src =
+   MLX5DR_MATCHER_FLOW_SRC_VPORT;
}
/* Build the item template. */
for (i = 0; i < nb_item_templates; i++) {
-- 
2.39.2

[PATCH v2 3/4] net/mlx5: move multi-pattern actions management to table level

[Gregory Etelson]

The multi-pattern actions related structures and management code
have been moved to the table level.
That code refactor is required for the upcoming table resize feature.

Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h|  73 ++-
 drivers/net/mlx5/mlx5_flow_hw.c | 225 +++-
 2 files changed, 173 insertions(+), 125 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index a4d0ff7b13..9cc237c542 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1410,7 +1410,6 @@ struct mlx5_hw_encap_decap_action {
/* Is header_reformat action shared across flows in table. */
uint32_t shared:1;
uint32_t multi_pattern:1;
-   volatile uint32_t *multi_pattern_refcnt;
size_t data_size; /* Action metadata size. */
uint8_t data[]; /* Action data. */
 };
@@ -1433,7 +1432,6 @@ struct mlx5_hw_modify_header_action {
/* Is MODIFY_HEADER action shared across flows in table. */
uint32_t shared:1;
uint32_t multi_pattern:1;
-   volatile uint32_t *multi_pattern_refcnt;
/* Amount of modification commands stored in the precompiled buffer. */
uint32_t mhdr_cmds_num;
/* Precompiled modification commands. */
@@ -1487,6 +1485,76 @@ struct mlx5_flow_group {
 #define MLX5_HW_TBL_MAX_ITEM_TEMPLATE 2
 #define MLX5_HW_TBL_MAX_ACTION_TEMPLATE 32
 
+#define MLX5_MULTIPATTERN_ENCAP_NUM 5
+#define MLX5_MAX_TABLE_RESIZE_NUM 64
+
+struct mlx5_multi_pattern_segment {
+   uint32_t capacity;
+   uint32_t head_index;
+   struct mlx5dr_action *mhdr_action;
+   struct mlx5dr_action *reformat_action[MLX5_MULTIPATTERN_ENCAP_NUM];
+};
+
+struct mlx5_tbl_multi_pattern_ctx {
+   struct {
+   uint32_t elements_num;
+   struct mlx5dr_action_reformat_header 
reformat_hdr[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   /**
+* insert_header structure is larger than reformat_header.
+* Enclosing these structures with union will case a gap between
+* reformat_hdr array elements.
+* mlx5dr_action_create_reformat() expects adjacent array 
elements.
+*/
+   struct mlx5dr_action_insert_header 
insert_hdr[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   } reformat[MLX5_MULTIPATTERN_ENCAP_NUM];
+
+   struct {
+   uint32_t elements_num;
+   struct mlx5dr_action_mh_pattern 
pattern[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   } mh;
+   struct mlx5_multi_pattern_segment segments[MLX5_MAX_TABLE_RESIZE_NUM];
+};
+
+static __rte_always_inline void
+mlx5_multi_pattern_activate(struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   mpctx->segments[0].head_index = 1;
+}
+
+static __rte_always_inline bool
+mlx5_is_multi_pattern_active(const struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   return mpctx->segments[0].head_index == 1;
+}
+
+static __rte_always_inline struct mlx5_multi_pattern_segment *
+mlx5_multi_pattern_segment_get_next(struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   int i;
+
+   for (i = 0; i < MLX5_MAX_TABLE_RESIZE_NUM; i++) {
+   if (!mpctx->segments[i].capacity)
+   return &mpctx->segments[i];
+   }
+   return NULL;
+}
+
+static __rte_always_inline struct mlx5_multi_pattern_segment *
+mlx5_multi_pattern_segment_find(struct mlx5_tbl_multi_pattern_ctx *mpctx,
+   uint32_t flow_resource_ix)
+{
+   int i;
+
+   for (i = 0; i < MLX5_MAX_TABLE_RESIZE_NUM; i++) {
+   uint32_t limit = mpctx->segments[i].head_index +
+mpctx->segments[i].capacity;
+
+   if (flow_resource_ix < limit)
+   return &mpctx->segments[i];
+   }
+   return NULL;
+}
+
 struct mlx5_flow_template_table_cfg {
struct rte_flow_template_table_attr attr; /* Table attributes passed 
through flow API. */
bool external; /* True if created by flow API, false if table is 
internal to PMD. */
@@ -1507,6 +1575,7 @@ struct rte_flow_template_table {
uint8_t nb_item_templates; /* Item template number. */
uint8_t nb_action_templates; /* Action template number. */
uint32_t refcnt; /* Table reference counter. */
+   struct mlx5_tbl_multi_pattern_ctx mpctx;
 };
 
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 5938d8b90c..38aed03970 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -78,41 +78,14 @@ struct mlx5_indlst_legacy {
 #define MLX5_CONST_ENCAP_ITEM(encap_type, ptr) \
 (((const struct encap_type *)(ptr))->definition)
 
-struct mlx5_multi_pattern_ctx {
-   union {
-   struct mlx5dr_action_reformat_header reformat_hdr;
-   struct mlx5dr_action_mh_pattern mh_pattern;
-   };
-   union {
-  

[PATCH v2 4/4] net/mlx5: add support for flow table resizing

[Gregory Etelson]

Support template table API in PMD.
The patch allows to increase existing table capacity.

Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h |   5 +
 drivers/net/mlx5/mlx5_flow.c|  51 
 drivers/net/mlx5/mlx5_flow.h|  84 --
 drivers/net/mlx5/mlx5_flow_hw.c | 518 +++-
 4 files changed, 553 insertions(+), 105 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 99850a58af..bb1853e797 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -380,6 +380,9 @@ enum mlx5_hw_job_type {
MLX5_HW_Q_JOB_TYPE_UPDATE, /* Flow update job type. */
MLX5_HW_Q_JOB_TYPE_QUERY, /* Flow query job type. */
MLX5_HW_Q_JOB_TYPE_UPDATE_QUERY, /* Flow update and query job type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_CREATE, /* Non-optimized flow create job 
type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_DESTROY, /* Non-optimized destroy create 
job type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_MOVE, /* Move flow after table resize. */
 };
 
 enum mlx5_hw_indirect_type {
@@ -422,6 +425,8 @@ struct mlx5_hw_q {
struct mlx5_hw_q_job **job; /* LIFO header. */
struct rte_ring *indir_cq; /* Indirect action SW completion queue. */
struct rte_ring *indir_iq; /* Indirect action SW in progress queue. */
+   struct rte_ring *flow_transfer_pending;
+   struct rte_ring *flow_transfer_completed;
 } __rte_cache_aligned;
 
 
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 3e179110a0..477b13e04d 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -1095,6 +1095,20 @@ mlx5_flow_calc_encap_hash(struct rte_eth_dev *dev,
  uint8_t *hash,
  struct rte_flow_error *error);
 
+static int
+mlx5_template_table_resize(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  uint32_t nb_rules, struct rte_flow_error *error);
+static int
+mlx5_flow_async_update_resized(struct rte_eth_dev *dev, uint32_t queue,
+  const struct rte_flow_op_attr *attr,
+  struct rte_flow *rule, void *user_data,
+  struct rte_flow_error *error);
+static int
+mlx5_table_resize_complete(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  struct rte_flow_error *error);
+
 static const struct rte_flow_ops mlx5_flow_ops = {
.validate = mlx5_flow_validate,
.create = mlx5_flow_create,
@@ -1133,6 +1147,9 @@ static const struct rte_flow_ops mlx5_flow_ops = {
mlx5_flow_action_list_handle_query_update,
.flow_calc_table_hash = mlx5_flow_calc_table_hash,
.flow_calc_encap_hash = mlx5_flow_calc_encap_hash,
+   .flow_template_table_resize = mlx5_template_table_resize,
+   .flow_update_resized = mlx5_flow_async_update_resized,
+   .flow_template_table_resize_complete = mlx5_table_resize_complete,
 };
 
 /* Tunnel information. */
@@ -10548,6 +10565,40 @@ mlx5_flow_calc_encap_hash(struct rte_eth_dev *dev,
return fops->flow_calc_encap_hash(dev, pattern, dest_field, hash, 
error);
 }
 
+static int
+mlx5_template_table_resize(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  uint32_t nb_rules, struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, table_resize, ENOTSUP);
+   return fops->table_resize(dev, table, nb_rules, error);
+}
+
+static int
+mlx5_table_resize_complete(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, table_resize_complete, ENOTSUP);
+   return fops->table_resize_complete(dev, table, error);
+}
+
+static int
+mlx5_flow_async_update_resized(struct rte_eth_dev *dev, uint32_t queue,
+  const struct rte_flow_op_attr *op_attr,
+  struct rte_flow *rule, void *user_data,
+  struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, flow_update_resized, ENOTSUP);
+   return fops->flow_update_resized(dev, queue, op_attr, rule, user_data, 
error);
+}
+
 /**
  * Destroy all indirect actions (shared RSS).
  *
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 9cc237c542..6c2944c21a 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1217,6 +1217,7 @@ struct rte_flow {
uint32_t tunnel:1;
uint32_t meter:24; /**< Holds flow meter id. */
uint32_t indirect_type:2; /**< Indir

[PATCH v1] eventdev/crypto: fix enqueueing invalid ops

[Ganapati Kundapura]

When tail pointer of Circ buffer rollsover as the Circ buffer becomes full,
crypto adapter is enqueueing ops beyond the size of the Circ buffer
leading to segfault due to invalid ops access.

Fixed by enqueueing ops from head pointer to (size-head) number of ops
when Circ buffer becomes full and the remaining ops will be flushed
in next iteration.

Fixes: 6c3c888656fc ("eventdev/crypto: fix circular buffer full case")

Signed-off-by: Ganapati Kundapura 

diff --git a/lib/eventdev/rte_event_crypto_adapter.c 
b/lib/eventdev/rte_event_crypto_adapter.c
index d46595d..9903f96 100644
--- a/lib/eventdev/rte_event_crypto_adapter.c
+++ b/lib/eventdev/rte_event_crypto_adapter.c
@@ -245,20 +245,28 @@ eca_circular_buffer_flush_to_cdev(struct 
crypto_ops_circular_buffer *bufp,
struct rte_crypto_op **ops = bufp->op_buffer;
 
if (*tailp > *headp)
+   /* Flush ops from head pointer to (tail - head) OPs */
n = *tailp - *headp;
else if (*tailp < *headp)
+   /* Circ buffer - Rollover.
+* Flush OPs from head to max size of buffer.
+* Rest of the OPs will be flushed in next iteration.
+*/
n = bufp->size - *headp;
else { /* head == tail case */
/* when head == tail,
 * circ buff is either full(tail pointer roll over) or empty
 */
if (bufp->count != 0) {
-   /* circ buffer is full */
-   n = bufp->count;
+   /* Circ buffer - FULL.
+* Flush OPs from head to max size of buffer.
+* Rest of the OPS will be flushed in next iteration.
+*/
+   n = bufp->size - *headp;
} else {
-   /* circ buffer is empty */
+   /* Circ buffer - Empty */
*nb_ops_flushed = 0;
-   return 0;  /* buffer empty */
+   return 0;
}
}
 
-- 
2.6.4

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[David Marchand]

On Tue, Feb 27, 2024 at 6:23 PM Tyler Retzlaff
 wrote:
>
> On Tue, Feb 27, 2024 at 04:18:10PM +0100, David Marchand wrote:
> > Hello Dodji,
> >
> > On Tue, Feb 27, 2024 at 6:44 AM Tyler Retzlaff
> >  wrote:
> > >
> > > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > > RTE_MARKER fields from rte_mbuf struct.
> > >
> > > Maintain alignment of fields after removed cacheline1 marker by placing
> > > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> > >
> > > Update implementation of rte_mbuf_prefetch_part1() and
> > > rte_mbuf_prefetch_part2() inline functions calculate pointer for
> > > prefetch of cachline0 and cachline1 without using removed markers.
> > >
> > > Update static_assert of rte_mbuf struct fields to reference data_off and
> > > packet_type fields that occupy the original offsets of the marker
> > > fields.
> > >
> > > Signed-off-by: Tyler Retzlaff 
> >
> > This change is reported as a potential ABI change.
> >
> > For the context, this patch
> > https://patchwork.dpdk.org/project/dpdk/patch/1709012499-12813-21-git-send-email-roret...@linux.microsoft.com/
> > removes null-sized markers (those fields were using RTE_MARKER, see
> > https://git.dpdk.org/dpdk/tree/lib/eal/include/rte_common.h#n583) from
> > the rte_mbuf struct.
> > I would argue this change do not impact ABI as the layout of the mbuf
> > object is not impacted.
>
> It isn't a surprise that the change got flagged because the 0 sized
> fields being removed probably not something the checker understands.
> So no ABI change just API break (as was requested).
>
> > As reported by the CI:
> >
> >   [C] 'function const rte_eth_rxtx_callback*
> > rte_eth_add_first_rx_callback(uint16_t, uint16_t, rte_rx_callback_fn,
> > void*)' at rte_ethdev.c:5768:1 has some indirect sub-type changes:
> > parameter 3 of type 'typedef rte_rx_callback_fn' has sub-type changes:
> >   underlying type 'typedef uint16_t (typedef uint16_t, typedef
> > uint16_t, rte_mbuf**, typedef uint16_t, typedef uint16_t, void*)*'
> > changed:
> > in pointed to type 'function type typedef uint16_t (typedef
> > uint16_t, typedef uint16_t, rte_mbuf**, typedef uint16_t, typedef
> > uint16_t, void*)':
> >   parameter 3 of type 'rte_mbuf**' has sub-type changes:
> > in pointed to type 'rte_mbuf*':
> >   in pointed to type 'struct rte_mbuf' at rte_mbuf_core.h:470:1:
> > type size hasn't changed
> > 4 data member deletions:
> >   'RTE_MARKER cacheline0', at offset 0 (in bits) at
> > rte_mbuf_core.h:467:1
> >   'RTE_MARKER64 rearm_data', at offset 128 (in bits)
> > at rte_mbuf_core.h:490:1
> >   'RTE_MARKER rx_descriptor_fields1', at offset 256
> > (in bits) at rte_mbuf_core.h:517:1
> >   'RTE_MARKER cacheline1', at offset 512 (in bits) at
> > rte_mbuf_core.h:598:1
> > no data member change (1 filtered);
> >
> > Error: ABI issue reported for abidiff --suppr
> > /home/runner/work/dpdk/dpdk/devtools/libabigail.abignore
> > --no-added-syms --headers-dir1 reference/usr/local/include
> > --headers-dir2 install/usr/local/include
> > reference/usr/local/lib/librte_ethdev.so.24.0
> > install/usr/local/lib/librte_ethdev.so.24.1
> > ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged
> > this as a potential issue).
> >
> > Opinions?
> >
> > Btw, I see no way to suppress this (except a global [suppress_type]
> > name = rte_mbuf)...
>
> I am unfamiliar with the ABI checker I'm afraid i have no suggestion to
> offer. Maybe we can just ignore the failure for this one series when we
> decide it is ready to be merged and don't suppress the checker?

The ABI check compares a current build with a (cached) reference build.
There is no "let's ignore this specific error" mechanism at the moment.
And I suspect it would be non-trivial to add (parsing abidiff text
output... brrr).

Changing the check so that it compares against origin/main (for
example) every time is doable *on paper*, but it would consume a lot
of cpu for maintainers (like Thomas, Ferruh or me) and the CI.
CI scripts would have to be updated too.


Fow now, one thing we can do is to change the reference to point at
the exact commit that introduces a change we know safe.
This requires a little sync between people (maintainers / users of
test-meson-builds.h) and UNH CI, but this is doable.

On the other hand, by the time we merge this series, libabigail may
have fixed this for us already? ;-)


-- 
David Marchand

RE: [PATCH v5 4/4] hash: add SVE support for bulk key lookup

[Konstantin Ananyev]

> 
> - Implemented SVE code for comparing signatures in bulk lookup.
> - Added Defines in code for SVE code support.
> - Optimise NEON code
> - New SVE code is ~5% slower than optimized NEON for N2 processor.
> 
> Signed-off-by: Yoan Picchi 
> Signed-off-by: Harjot Singh 
> Reviewed-by: Nathan Brown 
> Reviewed-by: Ruifeng Wang 
> ---
>  lib/hash/rte_cuckoo_hash.c | 196 -
>  lib/hash/rte_cuckoo_hash.h |   1 +
>  2 files changed, 151 insertions(+), 46 deletions(-)
> 
> diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
> index a07dd3a28d..231d6d6ded 100644
> --- a/lib/hash/rte_cuckoo_hash.c
> +++ b/lib/hash/rte_cuckoo_hash.c
> @@ -442,8 +442,11 @@ rte_hash_create(const struct rte_hash_parameters *params)
>   h->sig_cmp_fn = RTE_HASH_COMPARE_SSE;
>   else
>  #elif defined(RTE_ARCH_ARM64)
> - if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
> + if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) {
>   h->sig_cmp_fn = RTE_HASH_COMPARE_NEON;
> + if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> + h->sig_cmp_fn = RTE_HASH_COMPARE_SVE;
> + }
>   else
>  #endif
>   h->sig_cmp_fn = RTE_HASH_COMPARE_SCALAR;
> @@ -1860,37 +1863,103 @@ rte_hash_free_key_with_position(const struct 
> rte_hash *h,
>  #if defined(__ARM_NEON)
> 
>  static inline void
> -compare_signatures_dense(uint32_t *prim_hash_matches, uint32_t 
> *sec_hash_matches,
> - const struct rte_hash_bucket *prim_bkt,
> - const struct rte_hash_bucket *sec_bkt,
> +compare_signatures_dense(uint16_t *hitmask_buffer,
> + const uint16_t *prim_bucket_sigs,
> + const uint16_t *sec_bucket_sigs,
>   uint16_t sig,
>   enum rte_hash_sig_compare_function sig_cmp_fn)
>  {
>   unsigned int i;
> 
> + static_assert(sizeof(*hitmask_buffer) >= 2*(RTE_HASH_BUCKET_ENTRIES/8),
> + "The hitmask must be exactly wide enough to accept the whole hitmask if 
> it is dense");
> +
>   /* For match mask every bits indicates the match */
>   switch (sig_cmp_fn) {

Can I ask to move arch specific comparison code into some arch-specific headers 
or so?
It is getting really hard to read and understand the generic code with all 
these ifdefs and arch specific instructions...

> +#if RTE_HASH_BUCKET_ENTRIES <= 8
>   case RTE_HASH_COMPARE_NEON: {
> - uint16x8_t vmat, x;
> + uint16x8_t vmat, hit1, hit2;
>   const uint16x8_t mask = {0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 
> 0x80};
>   const uint16x8_t vsig = vld1q_dup_u16((uint16_t const *)&sig);
> 
>   /* Compare all signatures in the primary bucket */
> - vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
> *)prim_bkt->sig_current));
> - x = vandq_u16(vmat, mask);
> - *prim_hash_matches = (uint32_t)(vaddvq_u16(x));
> + vmat = vceqq_u16(vsig, vld1q_u16(prim_bucket_sigs));
> + hit1 = vandq_u16(vmat, mask);
> +
>   /* Compare all signatures in the secondary bucket */
> - vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
> *)sec_bkt->sig_current));
> - x = vandq_u16(vmat, mask);
> - *sec_hash_matches = (uint32_t)(vaddvq_u16(x));
> + vmat = vceqq_u16(vsig, vld1q_u16(sec_bucket_sigs));
> + hit2 = vandq_u16(vmat, mask);
> +
> + hit2 = vshlq_n_u16(hit2, RTE_HASH_BUCKET_ENTRIES);
> + hit2 = vorrq_u16(hit1, hit2);
> + *hitmask_buffer = vaddvq_u16(hit2);
> + }
> + break;
> +#endif
> +#if defined(RTE_HAS_SVE_ACLE)
> + case RTE_HASH_COMPARE_SVE: {
> + svuint16_t vsign, shift, sv_matches;
> + svbool_t pred, match, bucket_wide_pred;
> + int i = 0;
> + uint64_t vl = svcnth();
> +
> + vsign = svdup_u16(sig);
> + shift = svindex_u16(0, 1);
> +
> + if (vl >= 2 * RTE_HASH_BUCKET_ENTRIES && 
> RTE_HASH_BUCKET_ENTRIES <= 8) {
> + svuint16_t primary_array_vect, secondary_array_vect;
> + bucket_wide_pred = svwhilelt_b16(0, 
> RTE_HASH_BUCKET_ENTRIES);
> + primary_array_vect = svld1_u16(bucket_wide_pred, 
> prim_bucket_sigs);
> + secondary_array_vect = svld1_u16(bucket_wide_pred, 
> sec_bucket_sigs);
> +
> + /* We merged the two vectors so we can do both 
> comparison at once */
> + primary_array_vect = svsplice_u16(bucket_wide_pred,
> + primary_array_vect,
> + secondary_array_vect);
> + pred = svwhilelt_b16(0, 2*RTE_HASH_BUCKET_ENTRIES);
> +
> + /* Compare all signatures in the buckets */
> + match = svcmpeq_u16(pred, vsign, prima

[PATCH v4] crypto/ipsec_mb: unified IPsec MB interface

[Brian Dooley]

Currently IPsec MB provides both the JOB API and direct API.
AESNI_MB PMD is using the JOB API codepath while ZUC, KASUMI, SNOW3G
and CHACHA20_POLY1305 are using the direct API.
Instead of using the direct API for these PMDs, they should now make
use of the JOB API codepath. This would remove all use of the IPsec MB
direct API for these PMDs.

Signed-off-by: Brian Dooley 
---
v2:
- Fix compilation failure
v3:
- Remove session configure pointer for each PMD
v4:
- Keep AES GCM PMD and fix extern issue
---
 doc/guides/rel_notes/release_24_03.rst|   6 +
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c|  10 +-
 drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h   |  15 +-
 drivers/crypto/ipsec_mb/pmd_chacha_poly.c | 338 +--
 .../crypto/ipsec_mb/pmd_chacha_poly_priv.h|  28 -
 drivers/crypto/ipsec_mb/pmd_kasumi.c  | 410 +
 drivers/crypto/ipsec_mb/pmd_kasumi_priv.h |  20 -
 drivers/crypto/ipsec_mb/pmd_snow3g.c  | 543 +-
 drivers/crypto/ipsec_mb/pmd_snow3g_priv.h |  21 -
 drivers/crypto/ipsec_mb/pmd_zuc.c | 347 +--
 drivers/crypto/ipsec_mb/pmd_zuc_priv.h|  20 -
 11 files changed, 48 insertions(+), 1710 deletions(-)

diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 879bb4944c..6c5b76cef5 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -138,6 +138,12 @@ New Features
 to support TLS v1.2, TLS v1.3 and DTLS v1.2.
   * Added PMD API to allow raw submission of instructions to CPT.
 
+* **Updated ipsec_mb crypto driver.**
+
+  * Kasumi, Snow3G, ChaChaPoly and ZUC PMDs now share the job API codepath
+with AESNI_MB PMD. Depending on the architecture, the performance of ZUC
+crypto PMD is approximately 10% less for small fixed packet sizes.
+
 
 Removed Items
 -
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 4de4866cf3..7d4dbc91ef 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -8,6 +8,8 @@
 
 RTE_DEFINE_PER_LCORE(pid_t, pid);
 
+uint8_t pmd_driver_id_aesni_mb;
+
 struct aesni_mb_op_buf_data {
struct rte_mbuf *m;
uint32_t offset;
@@ -761,7 +763,7 @@ aesni_mb_set_session_aead_parameters(const IMB_MGR *mb_mgr,
 }
 
 /** Configure a aesni multi-buffer session from a crypto xform chain */
-static int
+int
 aesni_mb_session_configure(IMB_MGR *mb_mgr,
void *priv_sess,
const struct rte_crypto_sym_xform *xform)
@@ -2131,7 +2133,7 @@ set_job_null_op(IMB_JOB *job, struct rte_crypto_op *op)
 }
 
 #if IMB_VERSION(1, 2, 0) < IMB_VERSION_NUM
-static uint16_t
+uint16_t
 aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
uint16_t nb_ops)
 {
@@ -2321,7 +2323,7 @@ flush_mb_mgr(struct ipsec_mb_qp *qp, IMB_MGR *mb_mgr,
return processed_ops;
 }
 
-static uint16_t
+uint16_t
 aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
uint16_t nb_ops)
 {
@@ -2456,7 +2458,7 @@ verify_sync_dgst(struct rte_crypto_sym_vec *vec,
return k;
 }
 
-static uint32_t
+uint32_t
 aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs sofs,
struct rte_crypto_sym_vec *vec)
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
index 85994fe5a1..2d462a7f68 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb_priv.h
@@ -21,6 +21,19 @@
 #define MAX_NUM_SEGS 16
 #endif
 
+int
+aesni_mb_session_configure(IMB_MGR * m __rte_unused, void *priv_sess,
+   const struct rte_crypto_sym_xform *xform);
+
+uint16_t
+aesni_mb_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
+   uint16_t nb_ops);
+
+uint32_t
+aesni_mb_process_bulk(struct rte_cryptodev *dev __rte_unused,
+   struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs sofs,
+   struct rte_crypto_sym_vec *vec);
+
 static const struct rte_cryptodev_capabilities aesni_mb_capabilities[] = {
{   /* MD5 HMAC */
.op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
@@ -722,8 +735,6 @@ static const struct rte_cryptodev_capabilities 
aesni_mb_capabilities[] = {
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
 };
 
-uint8_t pmd_driver_id_aesni_mb;
-
 struct aesni_mb_qp_data {
uint8_t temp_digests[IMB_MAX_JOBS][DIGEST_LENGTH_MAX];
/* *< Buffers used to store the digest generated
diff --git a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c 
b/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
index 97e7cef233..7436353fc2 100644
--- a/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
+++ b/drivers/crypto/ipsec_mb/pmd_chacha_poly.c
@@ -3,334 +3,7 @@
  */
 
 #include "pmd_chacha_poly_priv.h"
-
-/** Parse crypto xform chain and set private session parameters

Re: [PATCH] lib/hash,lib/rcu: feature hidden key count in hash

[Abdullah Ömer Yamaç]

While I was implementing the new API, I realized one issue, and it would be
good to discuss it here. First of all rte_rcu_qsbr_dq_reclaim function
checks the state of the qsbr values. It means that all threads should
report the quiescent states. It conflicts with my aim.

Let's think about below scenario:
Eight threads use a hash table and periodically report their quiescent
states. One additional thread (main thread) periodically reports the hash
size. I implemented the reclaim function in that thread. I mean, the main
thread calls reclaim before the rte_hash_count.

Here is the exceptional case that I couldn't retrieve the correct hash size:
Assume that 6 of 8 threads reported quiescent states and 2 of them are
still working on some process and haven't reported quiescent states yet.
The main thread calls reclaim functions every time, but elements in dq will
not be freed because 2 of the worker threads haven't reported their states
(especially if they are waiting for some packets). So, my first proposed
method is more suitable for this case. Any idea?

On Thu, Feb 22, 2024 at 7:44 PM Honnappa Nagarahalli <
honnappa.nagaraha...@arm.com> wrote:

>
>
> > On Feb 22, 2024, at 6:39 AM, Abdullah Ömer Yamaç 
> wrote:
> >
> > As a final decision, I will add a new hash API that forces the reclaim.
> Is it ok for everyone?
> Ack from my side
>
> >
> > On Thu, Feb 22, 2024 at 5:37 AM Honnappa Nagarahalli <
> honnappa.nagaraha...@arm.com> wrote:
> >
> >
> > > On Feb 21, 2024, at 3:51 PM, Abdullah Ömer Yamaç 
> wrote:
> > >
> > >
> > >
> > > On Wed, Feb 21, 2024 at 6:24 AM Honnappa Nagarahalli <
> honnappa.nagaraha...@arm.com> wrote:
> > >
> > >
> > > > On Feb 20, 2024, at 12:58 PM, Abdullah Ömer Yamaç <
> aomerya...@gmail.com> wrote:
> > > >
> > > > I appreciate that you gave me suggestions and comments. I will make
> changes according to all your recommendations, but before that, I want to
> make everyone's minds clear. Then, I will apply modifications.
> > > >
> > > > On Tue, Feb 20, 2024 at 2:35 AM Honnappa Nagarahalli <
> honnappa.nagaraha...@arm.com> wrote:
> > > >
> > > >
> > > > > On Feb 19, 2024, at 3:28 PM, Abdullah Ömer Yamaç <
> aomerya...@gmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Let me explain a use case;
> > > > >
> > > > > I have a hash table whose key value is IP addresses, and data
> (let's say the username of the IP) is related to the IP address. The key
> point is matching these data with flows. Flows are dynamic, and this hash
> table is dynamic, as well; both can change anytime. For example, when a
> flow starts, we look up the hash table with the corresponding IP and
> retrieve the username. We need to hold this username until the flow
> terminates, although we removed this IP key from the hash table
> (multithread). That's why we have RCU and defer queue is necessary for high
> performance. In my application, I need to know the number of IP-username
> entries. These numbers can be calculated by rte_hash_count - defer queue
> size.
> > > > The entries in the defer queue are not reclaimed (there is a
> probability that all of them can be reclaimed) and hence they are not
> available for allocation. So, rte_hash_count - defer queue size might not
> give you the correct number you are expecting.
> > > >
> > > > Currently, there is no API in hash library that forces a reclaim.
> Does it makes sense to have an API that just does the reclaim (and returns
> the number of entries pending in the defer queue)? A call to rte_hash_count
> should provide the exact count you are looking for.
> > > > You are right; no API in the hash library forces a reclaim. In my
> application, I periodically call rte_count to retrieve hash size, and this
> data is shown in my GUI. So that means I need to call regularly reclaim. I
> am trying to figure out which is better, calling reclaim or retrieving the
> defer queue size. Any comment about this?
> > > Retrieving the defer queue size will be cheaper. However, calling the
> reclaim API will ensure the entries are freed hence providing an accurate
> number. Calling the reclaim API on an empty defer queue does not consume
> many cycles. If needed we could add a check for empty defer queue in the
> reclaim API and return early.
> > >
> > > I am also wondering if a reclaim API in hash library is needed. Why
> not call rte_rcu_qsbr_dq_reclaim API from the application?
> > > The reason is simple. struct rte_hash *h is an internal structure and
> we cannot access the h->dq. So it is not possible to call reclaim.
> > Ack. This will be just a wrapper around the rte_rcu_qsbr_dq_reclaim.
> >
> > >
> > >
> > > > >
> > > > > I think if you need a non-blocking and multithreaded hash table,
> an RCU-enabled hash table is necessary. Also, this API is necessary if you
> need to get the actual matchable size.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Feb 19, 2024 at 8:36 PM Medvedkin, Vladimir <
> vladimir.medved...@intel.com> wrote:
> > > > >

Re: [PATCH v3 00/16] stop using variadic argument pack extension

[David Marchand]

On Tue, Feb 27, 2024 at 7:15 PM Tyler Retzlaff
 wrote:
>
> On Mon, Feb 26, 2024 at 12:54:36PM -0800, Stephen Hemminger wrote:
> > On Mon, 26 Feb 2024 12:19:30 -0800
> > Tyler Retzlaff  wrote:
> >
> > > RTE_LOG_LINE cannot be augmented with a prefix format and arguments
> > > without the user of RTE_LOG_LINE using the args... and ## args compiler
> > > extension to conditionally remove trailing comma when the macro receives
> > > only a single argument.
> > >
> > > Provide a new/similar macro RTE_LOG_LINE_PREFIX that accepts the prefix
> > > format and arguments as separate parameters allowing them to be expanded
> > > at the correct locations inside of RTE_FMT() allowing the rest of the
> > > non-prefix format string and arguments to be collapsed to the argument
> > > pack which can be directly forwarded with __VA_ARGS__ avoiding the need
> > > for conditional comma removal.
> > >
> > > I've done my best to manually check expansions (preprocessed) and compiled
> > > printf of the logs to validate correct output.
> > >
> > > note: due to drastic change in series i have not carried any series acks
> > >   forward.
> >
> > The changes look good, you might want to add release note, update coding
> > style doc, and/or update checkpatch to discourage re-introduction.
>
> re-introduction should be protected by the CI. i know checkpatch would
> be better but i couldn't think of a good way to match an arbitrarily
> named pack ... reliably where it could potentially cause noise.

What about a simple:

+   # forbid use of variadic argument pack extension in macros
+   awk -v FOLDERS="lib drivers app examples" \
+   -v
EXPRESSIONS='#[[:space:]]*define.*[^(,[:space:]]\\.\\.\\.[[:space:]]*)'
\
+   -v RET_ON_FAIL=1 \
+   -v MESSAGE='Do not use variadic argument pack in macros' \
+   -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+   "$1" || res=1
+


-- 
David Marchand

RE: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface

[Power, Ciara]

> -Original Message-
> From: Brian Dooley 
> Sent: Wednesday, February 28, 2024 11:33 AM
> To: Ji, Kai ; De Lara Guarch, Pablo
> 
> Cc: dev@dpdk.org; gak...@marvell.com; Dooley, Brian
> 
> Subject: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface
> 
> Currently IPsec MB provides both the JOB API and direct API.
> AESNI_MB PMD is using the JOB API codepath while ZUC, KASUMI, SNOW3G
> and CHACHA20_POLY1305 are using the direct API.
> Instead of using the direct API for these PMDs, they should now make
> use of the JOB API codepath. This would remove all use of the IPsec MB
> direct API for these PMDs.
> 
> Signed-off-by: Brian Dooley 
> ---
> v2:
> - Fix compilation failure
> v3:
> - Remove session configure pointer for each PMD
> v4:
> - Keep AES GCM PMD and fix extern issue
> ---


Acked-by: Ciara Power 

Re: [RFC PATCH 1/2] power: refactor core power management library

[Ferruh Yigit]

On 2/20/2024 3:33 PM, Sivaprasad Tummala wrote:
> + ops = rte_power_get_ops(env);
> + if (ops->status == 0) {
> + POWER_LOG(ERR, WER,
> + "Power Management Environment(%d) not"
> + " registered\n", env);

'WER' seems typo, causing build error.
Also CI reports a few other build errors, fyi.

Re: [PATCH] net/hns3: fix Rx packet truncation when KEEP CRC enabled

[Ferruh Yigit]

On 2/28/2024 2:27 AM, huangdengdui wrote:
> 
> 
> On 2024/2/27 0:43, Ferruh Yigit wrote:
>> On 2/26/2024 3:16 AM, Jie Hai wrote:
>>> On 2024/2/23 21:53, Ferruh Yigit wrote:
 On 2/20/2024 3:58 AM, Jie Hai wrote:
> Hi, Ferruh,
>
> Thanks for your review.
>
> On 2024/2/7 22:15, Ferruh Yigit wrote:
>> On 2/6/2024 1:10 AM, Jie Hai wrote:
>>> From: Dengdui Huang 
>>>
>>> When KEEP_CRC offload is enabled, some packets will be truncated and
>>> the CRC is still be stripped in following cases:
>>> 1. For HIP08 hardware, the packet type is TCP and the length
>>>  is less than or equal to 60B.
>>> 2. For other hardwares, the packet type is IP and the length
>>>  is less than or equal to 60B.
>>>
>>
>> If a device doesn't support the offload by some packets, it can be
>> option to disable offload for that device, instead of calculating it in
>> software and append it.
>
> The KEEP CRC feature of hns3 is faulty only in the specific packet
> type and small packet(<60B) case.
> What's more, the small ethernet packet is not common.
>
>> Unless you have a specific usecase, or requirement to support the
>> offload.
>
> Yes, some users of hns3 are already using this feature.
> So we cannot drop this offload
>
>> <...>
>>
>>> @@ -2492,10 +2544,16 @@ hns3_recv_pkts_simple(void *rx_queue,
>>>    goto pkt_err;
>>>      rxm->packet_type = hns3_rx_calc_ptype(rxq, l234_info,
>>> ol_info);
>>> -
>>>    if (rxm->packet_type == RTE_PTYPE_L2_ETHER_TIMESYNC)
>>>    rxm->ol_flags |= RTE_MBUF_F_RX_IEEE1588_PTP;
>>>    +    if (unlikely(rxq->crc_len > 0)) {
>>> +    if (hns3_need_recalculate_crc(rxq, rxm))
>>> +    hns3_recalculate_crc(rxq, rxm);
>>> +    rxm->pkt_len -= rxq->crc_len;
>>> +    rxm->data_len -= rxq->crc_len;
>>>
>>
>> Removing 'crc_len' from 'mbuf->pkt_len' & 'mbuf->data_len' is
>> practically same as stripping CRC.
>>
>> We don't count CRC length in the statistics, but it should be
>> accessible
>> in the payload by the user.
> Our drivers are behaving exactly as you say.
>

 If so I missed why mbuf 'pkt_len' and 'data_len' reduced by
 'rxq->crc_len', can you please explain what above lines does?


>>> @@ -2470,8 +2523,7 @@ hns3_recv_pkts_simple(void *rx_queue,
>>>  rxdp->rx.bd_base_info = 0;
>>>
>>>  rxm->data_off = RTE_PKTMBUF_HEADROOM;
>>> -    rxm->pkt_len = (uint16_t)(rte_le_to_cpu_16(rxd.rx.pkt_len)) -
>>> -    rxq->crc_len;
>>> +    rxm->pkt_len = rte_le_to_cpu_16(rxd.rx.pkt_len);
>>>
>>> In the previous code above, the 'pkt_len' is set to the length obtained
>>> from the BD. the length obtained from the BD already contains CRC length.
>>> But as you said above, the DPDK requires that the length of the mbuf
>>> does not contain CRC length . So we subtract 'rxq->crc_len' from
>>> mbuf'pkt_len' and 'data_len'. This patch doesn't change the logic, it
>>> just moves the code around.
>>>
>>
>> Nope, I am not saying mbuf length shouldn't contain CRC length, indeed
>> it is other way around and this is our confusion.
>>
>> CRC length shouldn't be in the statistics, I mean in received bytes stats.
>> Assume that received packet is 128 bytes and we know it has the CRC,
>> Rx received bytes stat should be 124 (rx_bytes = 128 - CRC = 124)
>>
>> But mbuf->data_len & mbuf->pkt_len should have full frame length,
>> including CRC.
>>
>> As application explicitly requested to KEEP CRC, it will know last 4
>> bytes are CRC.
>> Anything after 'mbuf->data_len' in the mbuf buffer is not valid, so if
>> you reduce 'mbuf->data_len' by CRC size, application can't know if 4
>> bytes after 'mbuf->data_len' is valid CRC or not.
>>
> I agree with you.
> 
> But the implementation of other PMDs supported KEEP_CRC is like this.
> In addition, there are probably many users that are already using it.
> If we modify it, it may cause applications incompatible.
> 
> what do you think?
> 
This is documented in the ethdev [1], better to follow the documentation
for all PMDs, can you please highlight the relevant driver code, we can
discuss it with their maintainers.

Alternatively we can document this additionally in the KEEP_CRC feature
document if it helps for the applications.


[1]
https://git.dpdk.org/dpdk/tree/lib/ethdev/rte_ethdev.h?h=v23.11#n257

Re: [PATCH v3 02/16] bpf: stop using variadic argument pack extension

[David Marchand]

On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
 wrote:
>
> Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
> which allow a prefix and arguments to be inserted into the log line
> without the need to use the ## args variadic argument pack extension.
>
> Signed-off-by: Tyler Retzlaff 
> ---
>  lib/bpf/bpf_impl.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
> index 1a3d97d..680b1e5 100644
> --- a/lib/bpf/bpf_impl.h
> +++ b/lib/bpf/bpf_impl.h
> @@ -29,8 +29,8 @@ struct rte_bpf {
>  extern int rte_bpf_logtype;
>  #define RTE_LOGTYPE_BPF rte_bpf_logtype
>
> -#defineRTE_BPF_LOG_LINE(lvl, fmt, args...) \
> -   RTE_LOG_LINE(lvl, BPF, fmt, ##args)
> +#define RTE_BPF_LOG_LINE(level, ...) \
> +   RTE_LOG_LINE_PREFIX(level, BPF, "%s(): ", __func__, __VA_ARGS__)

The patch $topic seems to be removal of variadic argument extension.
So, I would expect a simple:
+#define RTE_BPF_LOG_LINE(level, ...) \
+   RTE_LOG_LINE(level, BPF, __VA_ARGS__)

Konstantin, just to be sure, are you ok with this (debug from my pov)
prefix addition?


-- 
David Marchand

[PATCH v3 0/4] net/mlx5: add support for flow table resizing

[Gregory Etelson]

Support template table resize API.

Gregory Etelson (3):
  net/mlx5: fix parameters verification in HWS table create
  net/mlx5: move multi-pattern actions management to table level
  net/mlx5: add support for flow table resizing

Maayan Kashani (1):
  net/mlx5: add resize function to ipool

 drivers/net/mlx5/mlx5.h |   5 +
 drivers/net/mlx5/mlx5_flow.c|  51 +++
 drivers/net/mlx5/mlx5_flow.h| 101 -
 drivers/net/mlx5/mlx5_flow_hw.c | 761 +++-
 drivers/net/mlx5/mlx5_utils.c   |  29 ++
 drivers/net/mlx5/mlx5_utils.h   |  16 +
 6 files changed, 763 insertions(+), 200 deletions(-)

Acked-by: Dariusz Sosnowski 

--
v2: Update PMD after DPDK API changes.
v3: Use RTE atomic API.
-- 
2.39.2

[PATCH v3 1/4] net/mlx5: add resize function to ipool

[Gregory Etelson]

From: Maayan Kashani 

Before this patch, ipool size could be fixed by
setting max_idx in mlx5_indexed_pool_config upon
ipool creation. Or it can be auto resized to the
maximum limit by setting max_idx to zero upon
ipool creation and the saved value is the maximum
index possible.
This patch adds ipool_resize API that enables to
update the value of max_idx in case it is not set to
maximum, meaning not in auto resize mode. It
enables the allocation of new trunk when using
malloc/zmalloc up to the max_idx limit. Please
notice the resize number of entries should be divisible by trunk_size.

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_utils.c | 29 +
 drivers/net/mlx5/mlx5_utils.h | 16 
 2 files changed, 45 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_utils.c b/drivers/net/mlx5/mlx5_utils.c
index 4db738785f..e28db2ec43 100644
--- a/drivers/net/mlx5/mlx5_utils.c
+++ b/drivers/net/mlx5/mlx5_utils.c
@@ -809,6 +809,35 @@ mlx5_ipool_get_next(struct mlx5_indexed_pool *pool, 
uint32_t *pos)
return NULL;
 }
 
+int
+mlx5_ipool_resize(struct mlx5_indexed_pool *pool, uint32_t num_entries)
+{
+   uint32_t cur_max_idx;
+   uint32_t max_index = mlx5_trunk_idx_offset_get(pool, TRUNK_MAX_IDX + 1);
+
+   if (num_entries % pool->cfg.trunk_size) {
+   DRV_LOG(ERR, "num_entries param should be trunk_size(=%u) 
multiplication\n",
+   pool->cfg.trunk_size);
+   return -EINVAL;
+   }
+
+   mlx5_ipool_lock(pool);
+   cur_max_idx = pool->cfg.max_idx + num_entries;
+   /* If the ipool max idx is above maximum or uint overflow occurred. */
+   if (cur_max_idx > max_index || cur_max_idx < num_entries) {
+   DRV_LOG(ERR, "Ipool resize failed\n");
+   DRV_LOG(ERR, "Adding %u entries to existing %u entries, will 
cross max limit(=%u)\n",
+   num_entries, cur_max_idx, max_index);
+   mlx5_ipool_unlock(pool);
+   return -EINVAL;
+   }
+
+   /* Update maximum entries number. */
+   pool->cfg.max_idx = cur_max_idx;
+   mlx5_ipool_unlock(pool);
+   return 0;
+}
+
 void
 mlx5_ipool_dump(struct mlx5_indexed_pool *pool)
 {
diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h
index 82e8298781..f3c0d76a6d 100644
--- a/drivers/net/mlx5/mlx5_utils.h
+++ b/drivers/net/mlx5/mlx5_utils.h
@@ -427,6 +427,22 @@ void mlx5_ipool_flush_cache(struct mlx5_indexed_pool 
*pool);
  */
 void *mlx5_ipool_get_next(struct mlx5_indexed_pool *pool, uint32_t *pos);
 
+/**
+ * This function resize the ipool.
+ *
+ * @param pool
+ *   Pointer to the index memory pool handler.
+ * @param num_entries
+ *   Number of entries to be added to the pool.
+ *   This number should be divisible by trunk_size.
+ *
+ * @return
+ *   - non-zero value on error.
+ *   - 0 on success.
+ *
+ */
+int mlx5_ipool_resize(struct mlx5_indexed_pool *pool, uint32_t num_entries);
+
 /**
  * This function allocates new empty Three-level table.
  *
-- 
2.39.2

[PATCH v3 2/4] net/mlx5: fix parameters verification in HWS table create

[Gregory Etelson]

Modified the conditionals in `flow_hw_table_create()` to use bitwise
AND instead of equality checks when assessing
`table_cfg->attr->specialize` bitmask.
This will allow for greater flexibility as the bitmask may encapsulate
multiple flags.
The patch maintains the previous behavior with single flag values,
while providing support for multiple flags.

Fixes: 240b77cfcba5 ("net/mlx5: enable hint in async flow table")

Cc: sta...@dpdk.org

Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 783ad9e72a..5938d8b90c 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -4390,12 +4390,23 @@ flow_hw_table_create(struct rte_eth_dev *dev,
matcher_attr.rule.num_log = rte_log2_u32(nb_flows);
/* Parse hints information. */
if (attr->specialize) {
-   if (attr->specialize == 
RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG)
-   matcher_attr.optimize_flow_src = 
MLX5DR_MATCHER_FLOW_SRC_WIRE;
-   else if (attr->specialize == 
RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG)
-   matcher_attr.optimize_flow_src = 
MLX5DR_MATCHER_FLOW_SRC_VPORT;
-   else
-   DRV_LOG(INFO, "Unsupported hint value %x", 
attr->specialize);
+   uint32_t val = RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG |
+  RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG;
+
+   if ((attr->specialize & val) == val) {
+   DRV_LOG(INFO, "Invalid hint value %x",
+   attr->specialize);
+   rte_errno = EINVAL;
+   goto it_error;
+   }
+   if (attr->specialize &
+   RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG)
+   matcher_attr.optimize_flow_src =
+   MLX5DR_MATCHER_FLOW_SRC_WIRE;
+   else if (attr->specialize &
+RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG)
+   matcher_attr.optimize_flow_src =
+   MLX5DR_MATCHER_FLOW_SRC_VPORT;
}
/* Build the item template. */
for (i = 0; i < nb_item_templates; i++) {
-- 
2.39.2

[PATCH v3 3/4] net/mlx5: move multi-pattern actions management to table level

[Gregory Etelson]

The multi-pattern actions related structures and management code
have been moved to the table level.
That code refactor is required for the upcoming table resize feature.

Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h|  73 ++-
 drivers/net/mlx5/mlx5_flow_hw.c | 226 +++-
 2 files changed, 174 insertions(+), 125 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index a4d0ff7b13..9cc237c542 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1410,7 +1410,6 @@ struct mlx5_hw_encap_decap_action {
/* Is header_reformat action shared across flows in table. */
uint32_t shared:1;
uint32_t multi_pattern:1;
-   volatile uint32_t *multi_pattern_refcnt;
size_t data_size; /* Action metadata size. */
uint8_t data[]; /* Action data. */
 };
@@ -1433,7 +1432,6 @@ struct mlx5_hw_modify_header_action {
/* Is MODIFY_HEADER action shared across flows in table. */
uint32_t shared:1;
uint32_t multi_pattern:1;
-   volatile uint32_t *multi_pattern_refcnt;
/* Amount of modification commands stored in the precompiled buffer. */
uint32_t mhdr_cmds_num;
/* Precompiled modification commands. */
@@ -1487,6 +1485,76 @@ struct mlx5_flow_group {
 #define MLX5_HW_TBL_MAX_ITEM_TEMPLATE 2
 #define MLX5_HW_TBL_MAX_ACTION_TEMPLATE 32
 
+#define MLX5_MULTIPATTERN_ENCAP_NUM 5
+#define MLX5_MAX_TABLE_RESIZE_NUM 64
+
+struct mlx5_multi_pattern_segment {
+   uint32_t capacity;
+   uint32_t head_index;
+   struct mlx5dr_action *mhdr_action;
+   struct mlx5dr_action *reformat_action[MLX5_MULTIPATTERN_ENCAP_NUM];
+};
+
+struct mlx5_tbl_multi_pattern_ctx {
+   struct {
+   uint32_t elements_num;
+   struct mlx5dr_action_reformat_header 
reformat_hdr[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   /**
+* insert_header structure is larger than reformat_header.
+* Enclosing these structures with union will case a gap between
+* reformat_hdr array elements.
+* mlx5dr_action_create_reformat() expects adjacent array 
elements.
+*/
+   struct mlx5dr_action_insert_header 
insert_hdr[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   } reformat[MLX5_MULTIPATTERN_ENCAP_NUM];
+
+   struct {
+   uint32_t elements_num;
+   struct mlx5dr_action_mh_pattern 
pattern[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
+   } mh;
+   struct mlx5_multi_pattern_segment segments[MLX5_MAX_TABLE_RESIZE_NUM];
+};
+
+static __rte_always_inline void
+mlx5_multi_pattern_activate(struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   mpctx->segments[0].head_index = 1;
+}
+
+static __rte_always_inline bool
+mlx5_is_multi_pattern_active(const struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   return mpctx->segments[0].head_index == 1;
+}
+
+static __rte_always_inline struct mlx5_multi_pattern_segment *
+mlx5_multi_pattern_segment_get_next(struct mlx5_tbl_multi_pattern_ctx *mpctx)
+{
+   int i;
+
+   for (i = 0; i < MLX5_MAX_TABLE_RESIZE_NUM; i++) {
+   if (!mpctx->segments[i].capacity)
+   return &mpctx->segments[i];
+   }
+   return NULL;
+}
+
+static __rte_always_inline struct mlx5_multi_pattern_segment *
+mlx5_multi_pattern_segment_find(struct mlx5_tbl_multi_pattern_ctx *mpctx,
+   uint32_t flow_resource_ix)
+{
+   int i;
+
+   for (i = 0; i < MLX5_MAX_TABLE_RESIZE_NUM; i++) {
+   uint32_t limit = mpctx->segments[i].head_index +
+mpctx->segments[i].capacity;
+
+   if (flow_resource_ix < limit)
+   return &mpctx->segments[i];
+   }
+   return NULL;
+}
+
 struct mlx5_flow_template_table_cfg {
struct rte_flow_template_table_attr attr; /* Table attributes passed 
through flow API. */
bool external; /* True if created by flow API, false if table is 
internal to PMD. */
@@ -1507,6 +1575,7 @@ struct rte_flow_template_table {
uint8_t nb_item_templates; /* Item template number. */
uint8_t nb_action_templates; /* Action template number. */
uint32_t refcnt; /* Table reference counter. */
+   struct mlx5_tbl_multi_pattern_ctx mpctx;
 };
 
 #endif
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 5938d8b90c..05442f0bd3 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -78,41 +78,14 @@ struct mlx5_indlst_legacy {
 #define MLX5_CONST_ENCAP_ITEM(encap_type, ptr) \
 (((const struct encap_type *)(ptr))->definition)
 
-struct mlx5_multi_pattern_ctx {
-   union {
-   struct mlx5dr_action_reformat_header reformat_hdr;
-   struct mlx5dr_action_mh_pattern mh_pattern;
-   };
-   union {
-  

[PATCH v3 4/4] net/mlx5: add support for flow table resizing

[Gregory Etelson]

Support template table API in PMD.
The patch allows to increase existing table capacity.

Signed-off-by: Gregory Etelson 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h |   5 +
 drivers/net/mlx5/mlx5_flow.c|  51 +++
 drivers/net/mlx5/mlx5_flow.h|  84 +++--
 drivers/net/mlx5/mlx5_flow_hw.c | 530 +++-
 4 files changed, 564 insertions(+), 106 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 99850a58af..bb1853e797 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -380,6 +380,9 @@ enum mlx5_hw_job_type {
MLX5_HW_Q_JOB_TYPE_UPDATE, /* Flow update job type. */
MLX5_HW_Q_JOB_TYPE_QUERY, /* Flow query job type. */
MLX5_HW_Q_JOB_TYPE_UPDATE_QUERY, /* Flow update and query job type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_CREATE, /* Non-optimized flow create job 
type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_DESTROY, /* Non-optimized destroy create 
job type. */
+   MLX5_HW_Q_JOB_TYPE_RSZTBL_FLOW_MOVE, /* Move flow after table resize. */
 };
 
 enum mlx5_hw_indirect_type {
@@ -422,6 +425,8 @@ struct mlx5_hw_q {
struct mlx5_hw_q_job **job; /* LIFO header. */
struct rte_ring *indir_cq; /* Indirect action SW completion queue. */
struct rte_ring *indir_iq; /* Indirect action SW in progress queue. */
+   struct rte_ring *flow_transfer_pending;
+   struct rte_ring *flow_transfer_completed;
 } __rte_cache_aligned;
 
 
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 3e179110a0..477b13e04d 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -1095,6 +1095,20 @@ mlx5_flow_calc_encap_hash(struct rte_eth_dev *dev,
  uint8_t *hash,
  struct rte_flow_error *error);
 
+static int
+mlx5_template_table_resize(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  uint32_t nb_rules, struct rte_flow_error *error);
+static int
+mlx5_flow_async_update_resized(struct rte_eth_dev *dev, uint32_t queue,
+  const struct rte_flow_op_attr *attr,
+  struct rte_flow *rule, void *user_data,
+  struct rte_flow_error *error);
+static int
+mlx5_table_resize_complete(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  struct rte_flow_error *error);
+
 static const struct rte_flow_ops mlx5_flow_ops = {
.validate = mlx5_flow_validate,
.create = mlx5_flow_create,
@@ -1133,6 +1147,9 @@ static const struct rte_flow_ops mlx5_flow_ops = {
mlx5_flow_action_list_handle_query_update,
.flow_calc_table_hash = mlx5_flow_calc_table_hash,
.flow_calc_encap_hash = mlx5_flow_calc_encap_hash,
+   .flow_template_table_resize = mlx5_template_table_resize,
+   .flow_update_resized = mlx5_flow_async_update_resized,
+   .flow_template_table_resize_complete = mlx5_table_resize_complete,
 };
 
 /* Tunnel information. */
@@ -10548,6 +10565,40 @@ mlx5_flow_calc_encap_hash(struct rte_eth_dev *dev,
return fops->flow_calc_encap_hash(dev, pattern, dest_field, hash, 
error);
 }
 
+static int
+mlx5_template_table_resize(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  uint32_t nb_rules, struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, table_resize, ENOTSUP);
+   return fops->table_resize(dev, table, nb_rules, error);
+}
+
+static int
+mlx5_table_resize_complete(struct rte_eth_dev *dev,
+  struct rte_flow_template_table *table,
+  struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, table_resize_complete, ENOTSUP);
+   return fops->table_resize_complete(dev, table, error);
+}
+
+static int
+mlx5_flow_async_update_resized(struct rte_eth_dev *dev, uint32_t queue,
+  const struct rte_flow_op_attr *op_attr,
+  struct rte_flow *rule, void *user_data,
+  struct rte_flow_error *error)
+{
+   const struct mlx5_flow_driver_ops *fops;
+
+   MLX5_DRV_FOPS_OR_ERR(dev, fops, flow_update_resized, ENOTSUP);
+   return fops->flow_update_resized(dev, queue, op_attr, rule, user_data, 
error);
+}
+
 /**
  * Destroy all indirect actions (shared RSS).
  *
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 9cc237c542..6c2944c21a 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1217,6 +1217,7 @@ struct rte_flow {
uint32_t tunnel:1;
uint32_t meter:24; /**< Holds flow meter id. */
uint32_t indirect_type:2; /**< Indirec

RE: [PATCH v3 02/16] bpf: stop using variadic argument pack extension

[Konstantin Ananyev]

> 
> On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
>  wrote:
> >
> > Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
> > which allow a prefix and arguments to be inserted into the log line
> > without the need to use the ## args variadic argument pack extension.
> >
> > Signed-off-by: Tyler Retzlaff 
> > ---
> >  lib/bpf/bpf_impl.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
> > index 1a3d97d..680b1e5 100644
> > --- a/lib/bpf/bpf_impl.h
> > +++ b/lib/bpf/bpf_impl.h
> > @@ -29,8 +29,8 @@ struct rte_bpf {
> >  extern int rte_bpf_logtype;
> >  #define RTE_LOGTYPE_BPF rte_bpf_logtype
> >
> > -#defineRTE_BPF_LOG_LINE(lvl, fmt, args...) \
> > -   RTE_LOG_LINE(lvl, BPF, fmt, ##args)
> > +#define RTE_BPF_LOG_LINE(level, ...) \
> > +   RTE_LOG_LINE_PREFIX(level, BPF, "%s(): ", __func__, __VA_ARGS__)
> 
> The patch $topic seems to be removal of variadic argument extension.
> So, I would expect a simple:
> +#define RTE_BPF_LOG_LINE(level, ...) \
> +   RTE_LOG_LINE(level, BPF, __VA_ARGS__)
> 
> Konstantin, just to be sure, are you ok with this (debug from my pov)
> prefix addition?
> 

Thanks David for spotting it, yes somehow I missed that.
Actually yes, yours variant looks correct to me.
Konstantin.

RE: [PATCH] net/mlx5: fix the HWS registers initialization

[Raslan Darawsheh]

Hi

> -Original Message-
> From: Bing Zhao 
> Sent: Tuesday, February 27, 2024 5:26 PM
> To: dev@dpdk.org; Suanming Mou ; Raslan
> Darawsheh 
> Cc: Ori Kam ; Slava Ovsiienko ;
> Matan Azrad ; Dariusz Sosnowski
> ; Gregory Etelson ;
> sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix the HWS registers initialization
> 
> The method to initialize tag registers by using capability bits is not 
> supported
> on some old NICs. In the meanwhile, the HWS for flow rule insertion is not
> supported either. There is no need to initialize HWS only resource on the old
> NICs.
> 
> Fixes: 48041ccbaa8d ("net/mlx5: initialize HWS flow registers in shared
> context")
> Cc: getel...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bing Zhao 
> Acked-by: Suanming Mou 
Patch applied to next-net-mlx,
Kindest regards
Raslan Darawsheh

RE: [PATCH] net/mlx5/hws: enable multiple integrity items

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Michael Baum 
> Sent: Wednesday, February 28, 2024 11:51 AM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Dariusz Sosnowski
> ; Raslan Darawsheh ; Slava
> Ovsiienko ; Ori Kam ;
> Suanming Mou ; Alex Vesker ;
> sta...@dpdk.org; Erez Shitrit 
> Subject: [PATCH] net/mlx5/hws: enable multiple integrity items
> 
> The integrity item uses the DW "oks1" in header layout. It includes the all
> supported bits for both inner and outer. When item is integrity type, the
> relevant bits are turned on and all DW is submitted.
> 
> When user provides more then single integrity item in same pattern, the last
> one overrides the values were submitted before. This is problematic when user
> wants to match integrity bits for both inner and outer in same pattern, he
> cannot merge them into single item since rte_flow API provides encapsulation
> level field to match either inner or outer.
> 
> This patch avoids the overriding values, when "oks1" is submitted, operator
> "or" is used instead of regular set.
> 
> Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")
> Cc: va...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Michael Baum 
> Reviewed-by: Erez Shitrit 
> Acked-by: Matan Azrad 
Patch applied to next-net-mlx,

Kindest regards
Raslan Darawsheh

RE: [PATCH v2] net/mlx5: fix VLAN handling in meter split

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Dariusz Sosnowski 
> Sent: Tuesday, February 27, 2024 3:58 PM
> To: Slava Ovsiienko ; Ori Kam ;
> Suanming Mou ; Matan Azrad
> 
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix VLAN handling in meter split
> 
> On the attempt to create a flow rule with:
> 
> - matching on REPRESENTED_PORT,
> - matching on outer VLAN tag,
> - matching on inner VLAN tag,
> - METER action,
> 
> flow splitting mechanism for handling metering flows was causing memory
> corruption. It was assumed that suffix flow will have a single VLAN item (used
> for translation of OF_PUSH_VLAN/OF_SET_VLAN_VID actions), however
> during flow_meter_split_prep() 2 VLAN items were parsed. This caused the
> buffer overflow on allocated suffix flow item buffer.
> 
> This patch fixes this overflow, by account for number of VLAN items in flow
> rule pattern when allocating items for suffix flow.
> 
> Fixes: 50f576d657d7 ("net/mlx5: fix VLAN actions in meter")
> Cc: suanmi...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dariusz Sosnowski 
> Acked-by: Suanming Mou 
> ---
> v2:
> - Rebased.
> 
Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

[PATCH v6 0/4] add QAT GEN LCE device

[Nishikant Nayak]

This patchset adds a new QAT LCE device.
The device currently only supports symmetric crypto,
and only the AES-GCM algorithm.

v6:
  - Added documentation and release note changes.
  - Removed unused device PCI ID.
v5:
  - Fixed compilation issue by replacing __u8 with uint8_t.
v4:
  - Fixed cover letter, v3 included the wrong details relating
to another patchset.
v3:
  - Fixed typos in commit and code comments.
  - Replaced use of linux/kernel.h macro with local macro
to fix ARM compilation in CI.
v2:
   - Renamed device from GEN 5 to GEN LCE.
   - Removed unused code.
   - Updated macro names.

Nishikant Nayak (4):
  common/qat: add files specific to GEN LCE
  common/qat: update common driver to support GEN LCE
  crypto/qat: update headers for GEN LCE support
  test/cryptodev: add tests for GCM with AAD

 .mailmap  |   1 +
 app/test/test_cryptodev.c |  48 ++-
 app/test/test_cryptodev_aead_test_vectors.h   |  62 
 doc/guides/cryptodevs/qat.rst |   1 +
 doc/guides/rel_notes/release_24_03.rst|   4 +
 drivers/common/qat/dev/qat_dev_gen_lce.c  | 306 
 drivers/common/qat/meson.build|   2 +
 .../qat/qat_adf/adf_transport_access_macros.h |   1 +
 .../adf_transport_access_macros_gen_lce.h |  51 +++
 .../adf_transport_access_macros_gen_lcevf.h   |  48 +++
 drivers/common/qat/qat_adf/icp_qat_fw.h   |  34 ++
 drivers/common/qat/qat_adf/icp_qat_fw_la.h|  59 +++-
 drivers/common/qat/qat_common.h   |   1 +
 drivers/common/qat/qat_device.c   |   5 +
 .../crypto/qat/dev/qat_crypto_pmd_gen_lce.c   | 329 ++
 drivers/crypto/qat/qat_sym.c  |  16 +-
 drivers/crypto/qat/qat_sym.h  |  66 +++-
 drivers/crypto/qat/qat_sym_session.c  |  62 +++-
 drivers/crypto/qat/qat_sym_session.h  |  10 +-
 19 files changed, 1090 insertions(+), 16 deletions(-)
 create mode 100644 drivers/common/qat/dev/qat_dev_gen_lce.c
 create mode 100644 
drivers/common/qat/qat_adf/adf_transport_access_macros_gen_lce.h
 create mode 100644 
drivers/common/qat/qat_adf/adf_transport_access_macros_gen_lcevf.h
 create mode 100644 drivers/crypto/qat/dev/qat_crypto_pmd_gen_lce.c

-- 
2.25.1

[PATCH v6 2/4] common/qat: update common driver to support GEN LCE

[Nishikant Nayak]

Adding GEN LCE specific macros which is required for updating
the support for GEN LCE features.
Also this patch adds other macros which is being used by GEN LCE
Specific APIs.

Signed-off-by: Nishikant Nayak 
Acked-by: Ciara Power 
---
v6:
- Removed unused PCI device IDs from the device list.
- Updated documentation and release note.
v2:
- Renamed device from GEN 5 to GEN LCE.
- Removed unused code.
- Updated macro names.
- Fixed code formatting
---
---
 doc/guides/cryptodevs/qat.rst |  1 +
 doc/guides/rel_notes/release_24_03.rst|  4 ++
 .../qat/qat_adf/adf_transport_access_macros.h |  1 +
 drivers/common/qat/qat_adf/icp_qat_fw.h   | 34 ++
 drivers/common/qat/qat_adf/icp_qat_fw_la.h| 45 ++-
 drivers/common/qat/qat_device.c   |  5 +++
 6 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index dc6b95165d..d9adbfc71e 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -26,6 +26,7 @@ poll mode crypto driver support for the following hardware 
accelerator devices:
 * ``Intel QuickAssist Technology D15xx``
 * ``Intel QuickAssist Technology C4xxx``
 * ``Intel QuickAssist Technology 4xxx``
+* ``Intel QuickAssist Technology apfxx``
 
 
 Features
diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 879bb4944c..41dccbb0c1 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -131,6 +131,10 @@ New Features
   * Added support for comparing result between packet fields or value.
   * Added support for accumulating value of field into another one.
 
+* **Updated Intel QuickAssist Technology driver.**
+
+  * Added support for GEN LCE (1454) device, for AES-GCM only.
+
 * **Updated Marvell cnxk crypto driver.**
 
   * Added support for Rx inject in crypto_cn10k.
diff --git a/drivers/common/qat/qat_adf/adf_transport_access_macros.h 
b/drivers/common/qat/qat_adf/adf_transport_access_macros.h
index 12a7258c60..19bd812419 100644
--- a/drivers/common/qat/qat_adf/adf_transport_access_macros.h
+++ b/drivers/common/qat/qat_adf/adf_transport_access_macros.h
@@ -47,6 +47,7 @@
 #define ADF_RING_SIZE_512 0x03
 #define ADF_RING_SIZE_4K 0x06
 #define ADF_RING_SIZE_16K 0x08
+#define ADF_RING_SIZE_64K 0x0A
 #define ADF_RING_SIZE_4M 0x10
 #define ADF_MIN_RING_SIZE ADF_RING_SIZE_128
 #define ADF_MAX_RING_SIZE ADF_RING_SIZE_4M
diff --git a/drivers/common/qat/qat_adf/icp_qat_fw.h 
b/drivers/common/qat/qat_adf/icp_qat_fw.h
index 3aa17ae041..b78158e01d 100644
--- a/drivers/common/qat/qat_adf/icp_qat_fw.h
+++ b/drivers/common/qat/qat_adf/icp_qat_fw.h
@@ -57,6 +57,12 @@ struct icp_qat_fw_comn_req_hdr_cd_pars {
} u;
 };
 
+struct lce_key_buff_desc {
+   uint64_t keybuff;
+   uint32_t keybuff_resrvd1;
+   uint32_t keybuff_resrvd2;
+};
+
 struct icp_qat_fw_comn_req_mid {
uint64_t opaque_data;
uint64_t src_data_addr;
@@ -123,6 +129,12 @@ struct icp_qat_fw_comn_resp {
 #define ICP_QAT_FW_COMN_NULL_VERSION_FLAG_BITPOS 0
 #define ICP_QAT_FW_COMN_NULL_VERSION_FLAG_MASK 0x1
 
+/* GEN_LCE specific Common Header fields */
+#define ICP_QAT_FW_COMN_DESC_LAYOUT_BITPOS 5
+#define ICP_QAT_FW_COMN_DESC_LAYOUT_MASK 0x3
+#define ICP_QAT_FW_COMN_GEN_LCE_DESC_LAYOUT 3
+#define ICP_QAT_FW_COMN_GEN_LCE_STATUS_FLAG_ERROR 0
+
 #define ICP_QAT_FW_COMN_OV_SRV_TYPE_GET(icp_qat_fw_comn_req_hdr_t) \
icp_qat_fw_comn_req_hdr_t.service_type
 
@@ -168,6 +180,12 @@ struct icp_qat_fw_comn_resp {
(((valid) & ICP_QAT_FW_COMN_VALID_FLAG_MASK) << \
 ICP_QAT_FW_COMN_VALID_FLAG_BITPOS)
 
+#define ICP_QAT_FW_COMN_HDR_FLAGS_BUILD_GEN_LCE(valid, desc_layout) \
+   valid) & ICP_QAT_FW_COMN_VALID_FLAG_MASK) << \
+   ICP_QAT_FW_COMN_VALID_FLAG_BITPOS) | \
+   (((desc_layout) & ICP_QAT_FW_COMN_DESC_LAYOUT_MASK) << \
+   ICP_QAT_FW_COMN_DESC_LAYOUT_BITPOS))
+
 #define QAT_COMN_PTR_TYPE_BITPOS 0
 #define QAT_COMN_PTR_TYPE_MASK 0x1
 #define QAT_COMN_CD_FLD_TYPE_BITPOS 1
@@ -180,10 +198,20 @@ struct icp_qat_fw_comn_resp {
 #define QAT_COMN_EXT_FLAGS_MASK 0x1
 #define QAT_COMN_EXT_FLAGS_USED 0x1
 
+/* GEN_LCE specific Common Request Flags fields */
+#define QAT_COMN_KEYBUF_USAGE_BITPOS 1
+#define QAT_COMN_KEYBUF_USAGE_MASK 0x1
+#define QAT_COMN_KEY_BUFFER_USED 1
+
 #define ICP_QAT_FW_COMN_FLAGS_BUILD(cdt, ptr) \
cdt) & QAT_COMN_CD_FLD_TYPE_MASK) << QAT_COMN_CD_FLD_TYPE_BITPOS) \
 | (((ptr) & QAT_COMN_PTR_TYPE_MASK) << QAT_COMN_PTR_TYPE_BITPOS))
 
+#define ICP_QAT_FW_COMN_FLAGS_BUILD_GEN_LCE(ptr, keybuf) \
+   ptr) & QAT_COMN_PTR_TYPE_MASK) << QAT_COMN_PTR_TYPE_BITPOS) | \
+(((keybuf) & QAT_COMN_PTR_TYPE_MASK) << \
+  QAT_COMN_KEYBUF_USAGE_BITPOS))
+
 #define ICP_QAT_FW_COMN_PTR_TYPE_GET(flags) \
QAT_FIELD_GET(flags, QAT_COMN_PTR_TYPE_BITPOS, QAT_COMN_PTR_TYPE_MASK)
 
@@ -249,6 +277,8

[PATCH v6 1/4] common/qat: add files specific to GEN LCE

[Nishikant Nayak]

Adding GEN5 files for handling GEN LCE specific operations.
These files are inherited from the existing files/APIs
which has some changes specific GEN5 requirements
Also updated the mailmap file.

Signed-off-by: Nishikant Nayak 
Acked-by: Ciara Power 
---
v5:
- Replaced usage of __u8 with uint8_t.
v3:
- Removed use of linux/kernel.h macro to fix ARM compilation.
- Fixed typo in commit body and code comment.
v2:
- Renamed device from GEN 5 to GEN LCE.
- Removed unused code.
- Updated macro names.
---
---
 .mailmap  |   1 +
 drivers/common/qat/dev/qat_dev_gen_lce.c  | 306 
 drivers/common/qat/meson.build|   2 +
 .../adf_transport_access_macros_gen_lce.h |  51 +++
 .../adf_transport_access_macros_gen_lcevf.h   |  48 +++
 drivers/common/qat/qat_adf/icp_qat_fw_la.h|  14 +
 drivers/common/qat/qat_common.h   |   1 +
 .../crypto/qat/dev/qat_crypto_pmd_gen_lce.c   | 329 ++
 drivers/crypto/qat/qat_sym.h  |   6 +
 9 files changed, 758 insertions(+)
 create mode 100644 drivers/common/qat/dev/qat_dev_gen_lce.c
 create mode 100644 
drivers/common/qat/qat_adf/adf_transport_access_macros_gen_lce.h
 create mode 100644 
drivers/common/qat/qat_adf/adf_transport_access_macros_gen_lcevf.h
 create mode 100644 drivers/crypto/qat/dev/qat_crypto_pmd_gen_lce.c

diff --git a/.mailmap b/.mailmap
index 58cca13ef6..8008e5a899 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1036,6 +1036,7 @@ Ning Li  
 Nipun Gupta  
 Nir Efrati 
 Nirmoy Das 
+Nishikant Nayak 
 Nithin Dabilpuram  

 Nitin Saxena 
 Nitzan Weller 
diff --git a/drivers/common/qat/dev/qat_dev_gen_lce.c 
b/drivers/common/qat/dev/qat_dev_gen_lce.c
new file mode 100644
index 00..5faaefc2d8
--- /dev/null
+++ b/drivers/common/qat/dev/qat_dev_gen_lce.c
@@ -0,0 +1,306 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2024 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include "qat_device.h"
+#include "qat_qp.h"
+#include "adf_transport_access_macros_gen_lcevf.h"
+#include "adf_pf2vf_msg.h"
+#include "qat_pf2vf.h"
+
+#include 
+#include 
+#include 
+
+#define BITS_PER_ULONG (sizeof(unsigned long) * 8)
+
+#define VFIO_PCI_LCE_DEVICE_CFG_REGION_INDEX   VFIO_PCI_NUM_REGIONS
+#define VFIO_PCI_LCE_CY_CFG_REGION_INDEX   (VFIO_PCI_NUM_REGIONS + 2)
+#define VFIO_PCI_LCE_RING_CFG_REGION_INDEX (VFIO_PCI_NUM_REGIONS + 4)
+#define LCE_DEVICE_NAME_SIZE   64
+#define LCE_DEVICE_MAX_BANKS   2080
+#define LCE_DIV_ROUND_UP(n, d)  (((n) + (d) - 1) / (d))
+#define LCE_DEVICE_BITMAP_SIZE  \
+   LCE_DIV_ROUND_UP(LCE_DEVICE_MAX_BANKS, BITS_PER_ULONG)
+
+/* QAT GEN_LCE specific macros */
+#define QAT_GEN_LCE_BUNDLE_NUM LCE_DEVICE_MAX_BANKS
+#define QAT_GEN4_QPS_PER_BUNDLE_NUM1
+
+/**
+ * struct lce_vfio_dev_cap - LCE device capabilities
+ *
+ * Device level capabilities and service level capabilities
+ */
+struct lce_vfio_dev_cap {
+   uint16_t device_num;
+   uint16_t device_type;
+   uint32_t capability_mask;
+   uint32_t extended_capabilities;
+   uint16_t max_banks;
+   uint16_t max_rings_per_bank;
+   uint16_t arb_mask;
+   uint16_t services;
+   uint16_t pkg_id;
+   uint16_t node_id;
+   uint8_t device_name[LCE_DEVICE_NAME_SIZE];
+};
+
+/* struct lce_vfio_dev_cy_cap - CY capabilities of LCE device */
+struct lce_vfio_dev_cy_cap {
+   uint32_t nr_banks;
+   unsigned long bitmap[LCE_DEVICE_BITMAP_SIZE];
+};
+
+struct lce_qat_domain {
+   uint32_t nid:3;
+   uint32_t fid:7;
+   uint32_t ftype  :2;
+   uint32_t vfid   :13;
+   uint32_t rid:4;
+   uint32_t vld:1;
+   uint32_t desc_over  :1;
+   uint32_t pasid_vld  :1;
+   uint32_t pasid  :20;
+};
+
+struct lce_qat_buf_domain {
+   uint32_t bank_id:   20;
+   uint32_t type:  4;
+   uint32_t resv:  8;
+   struct lce_qat_domain dom;
+};
+
+struct qat_dev_gen_lce_extra {
+   struct qat_qp_hw_data
+   
qp_gen_lce_data[QAT_GEN_LCE_BUNDLE_NUM][QAT_GEN4_QPS_PER_BUNDLE_NUM];
+};
+
+static struct qat_pf2vf_dev qat_pf2vf_gen_lce = {
+   .pf2vf_offset = ADF_4XXXIOV_PF2VM_OFFSET,
+   .vf2pf_offset = ADF_4XXXIOV_VM2PF_OFFSET,
+   .pf2vf_type_shift = ADF_PFVF_2X_MSGTYPE_SHIFT,
+   .pf2vf_type_mask = ADF_PFVF_2X_MSGTYPE_MASK,
+   .pf2vf_data_shift = ADF_PFVF_2X_MSGDATA_SHIFT,
+   .pf2vf_data_mask = ADF_PFVF_2X_MSGDATA_MASK,
+};
+
+static int
+qat_select_valid_queue_gen_lce(struct qat_pci_device *qat_dev, int qp_id,
+   enum qat_service_type service_type)
+{
+   int i = 0, valid_qps = 0;
+   struct qat_dev_gen_lce_extra *dev_extra = qat_dev->dev_private;
+
+   for (; i < QAT_GEN_LCE_BUNDLE_NUM; i++) {
+   if (dev_extra->qp_gen_lce_data[i][0].service_type ==
+   service_type) {
+ 

[PATCH v6 3/4] crypto/qat: update headers for GEN LCE support

[Nishikant Nayak]

This patch handles the changes required for updating the common
header fields specific to GEN LCE, Also added/updated of the response
processing APIs based on GEN LCE requirement.

Signed-off-by: Nishikant Nayak 
Acked-by: Ciara Power 
---
v2:
- Renamed device from GEN 5 to GEN LCE.
- Removed unused code.
- Updated macro names.
- Added GEN LCE specific API for deque burst.
- Fixed code formatting.
---
---
 drivers/crypto/qat/qat_sym.c | 16 ++-
 drivers/crypto/qat/qat_sym.h | 60 ++-
 drivers/crypto/qat/qat_sym_session.c | 62 +++-
 drivers/crypto/qat/qat_sym_session.h | 10 -
 4 files changed, 140 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
index 6e03bde841..439a3fc00b 100644
--- a/drivers/crypto/qat/qat_sym.c
+++ b/drivers/crypto/qat/qat_sym.c
@@ -180,7 +180,15 @@ qat_sym_dequeue_burst(void *qp, struct rte_crypto_op **ops,
uint16_t nb_ops)
 {
return qat_dequeue_op_burst(qp, (void **)ops,
-   qat_sym_process_response, nb_ops);
+   qat_sym_process_response, nb_ops);
+}
+
+uint16_t
+qat_sym_dequeue_burst_gen_lce(void *qp, struct rte_crypto_op **ops,
+   uint16_t nb_ops)
+{
+   return qat_dequeue_op_burst(qp, (void **)ops,
+   qat_sym_process_response_gen_lce, nb_ops);
 }
 
 int
@@ -200,6 +208,7 @@ qat_sym_dev_create(struct qat_pci_device *qat_pci_dev,
char capa_memz_name[RTE_CRYPTODEV_NAME_MAX_LEN];
struct rte_cryptodev *cryptodev;
struct qat_cryptodev_private *internals;
+   enum qat_device_gen qat_dev_gen = qat_pci_dev->qat_dev_gen;
const struct qat_crypto_gen_dev_ops *gen_dev_ops =
&qat_sym_gen_dev_ops[qat_pci_dev->qat_dev_gen];
 
@@ -249,7 +258,10 @@ qat_sym_dev_create(struct qat_pci_device *qat_pci_dev,
cryptodev->dev_ops = gen_dev_ops->cryptodev_ops;
 
cryptodev->enqueue_burst = qat_sym_enqueue_burst;
-   cryptodev->dequeue_burst = qat_sym_dequeue_burst;
+   if (qat_dev_gen == QAT_GEN_LCE)
+   cryptodev->dequeue_burst = qat_sym_dequeue_burst_gen_lce;
+   else
+   cryptodev->dequeue_burst = qat_sym_dequeue_burst;
 
cryptodev->feature_flags = gen_dev_ops->get_feature_flags(qat_pci_dev);
 
diff --git a/drivers/crypto/qat/qat_sym.h b/drivers/crypto/qat/qat_sym.h
index f2f197d050..3461113c13 100644
--- a/drivers/crypto/qat/qat_sym.h
+++ b/drivers/crypto/qat/qat_sym.h
@@ -90,7 +90,7 @@
 /*
  * Maximum number of SGL entries
  */
-#define QAT_SYM_SGL_MAX_NUMBER 16
+#define QAT_SYM_SGL_MAX_NUMBER 16
 
 /* Maximum data length for single pass GMAC: 2^14-1 */
 #define QAT_AES_GMAC_SPC_MAX_SIZE 16383
@@ -142,6 +142,10 @@ uint16_t
 qat_sym_dequeue_burst(void *qp, struct rte_crypto_op **ops,
uint16_t nb_ops);
 
+uint16_t
+qat_sym_dequeue_burst_gen_lce(void *qp, struct rte_crypto_op **ops,
+   uint16_t nb_ops);
+
 #ifdef RTE_QAT_OPENSSL
 /** Encrypt a single partial block
  *  Depends on openssl libcrypto
@@ -390,6 +394,52 @@ qat_sym_process_response(void **op, uint8_t *resp, void 
*op_cookie,
return 1;
 }
 
+static __rte_always_inline int
+qat_sym_process_response_gen_lce(void **op, uint8_t *resp,
+   void *op_cookie __rte_unused,
+   uint64_t *dequeue_err_count __rte_unused)
+{
+   struct icp_qat_fw_comn_resp *resp_msg =
+   (struct icp_qat_fw_comn_resp *)resp;
+   struct rte_crypto_op *rx_op = (struct rte_crypto_op *)(uintptr_t)
+   (resp_msg->opaque_data);
+   struct qat_sym_session *sess;
+
+#if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG
+   QAT_DP_HEXDUMP_LOG(DEBUG, "qat_response:", (uint8_t *)resp_msg,
+   sizeof(struct icp_qat_fw_comn_resp));
+#endif
+
+   sess = CRYPTODEV_GET_SYM_SESS_PRIV(rx_op->sym->session);
+
+   rx_op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
+
+   if (ICP_QAT_FW_COMN_STATUS_FLAG_OK !=
+   ICP_QAT_FW_COMN_RESP_UNSUPPORTED_REQUEST_STAT_GET(
+   resp_msg->comn_hdr.comn_status))
+   rx_op->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
+
+   else if (ICP_QAT_FW_COMN_STATUS_FLAG_OK !=
+   ICP_QAT_FW_COMN_RESP_INVALID_PARAM_STAT_GET(
+   resp_msg->comn_hdr.comn_status))
+   rx_op->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
+
+   if (sess->qat_dir == ICP_QAT_HW_CIPHER_DECRYPT) {
+   if (ICP_QAT_FW_LA_VER_STATUS_FAIL ==
+   ICP_QAT_FW_COMN_RESP_CRYPTO_STAT_GET(
+   resp_msg->comn_hdr.comn_status))
+   rx_op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
+   }
+
+   *op = (void *)rx_op;
+
+   /*
+* return 1 as dequeue op only move on to the next op
+* if one was ready to return to API
+*/
+ 

[PATCH v6 4/4] test/cryptodev: add tests for GCM with AAD

[Nishikant Nayak]

Adding one new unit test code for validating the features
added as part of GCM with 64 byte AAD.
The new test case adds one new test for GCM algo for both
encrypt and decrypt operations.

Signed-off-by: Nishikant Nayak 
Acked-by: Ciara Power 
---
v2:
- Removed unused code.
- Added one new unit test, AAD with GCM for GEN LCE.
---
---
 app/test/test_cryptodev.c   | 48 +---
 app/test/test_cryptodev_aead_test_vectors.h | 62 +
 2 files changed, 103 insertions(+), 7 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 38a65aa88f..edd23731f7 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -12494,6 +12494,18 @@ test_AES_GCM_auth_decryption_test_case_256_7(void)
return test_authenticated_decryption(&gcm_test_case_256_7);
 }
 
+static int
+test_AES_GCM_auth_decryption_test_case_256_8(void)
+{
+   return test_authenticated_decryption(&gcm_test_case_256_8);
+}
+
+static int
+test_AES_GCM_auth_encryption_test_case_256_8(void)
+{
+   return test_authenticated_encryption(&gcm_test_case_256_8);
+}
+
 static int
 test_AES_GCM_auth_decryption_test_case_aad_1(void)
 {
@@ -12613,10 +12625,16 @@ test_authenticated_encryption_oop(const struct 
aead_test_data *tdata)
 
/* Verify the capabilities */
struct rte_cryptodev_sym_capability_idx cap_idx;
+   const struct rte_cryptodev_symmetric_capability *capability;
cap_idx.type = RTE_CRYPTO_SYM_XFORM_AEAD;
cap_idx.algo.aead = tdata->algo;
-   if (rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
-   &cap_idx) == NULL)
+   capability = rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
+   &cap_idx);
+   if (capability == NULL)
+   return TEST_SKIPPED;
+   if (rte_cryptodev_sym_capability_check_aead(
+   capability, tdata->key.len, tdata->auth_tag.len,
+   tdata->aad.len, tdata->iv.len))
return TEST_SKIPPED;
 
rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
@@ -12719,16 +12737,22 @@ test_authenticated_decryption_oop(const struct 
aead_test_data *tdata)
 
/* Verify the capabilities */
struct rte_cryptodev_sym_capability_idx cap_idx;
+   const struct rte_cryptodev_symmetric_capability *capability;
cap_idx.type = RTE_CRYPTO_SYM_XFORM_AEAD;
cap_idx.algo.aead = tdata->algo;
-   if (rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
-   &cap_idx) == NULL)
-   return TEST_SKIPPED;
+   capability = rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
+   &cap_idx);
 
/* not supported with CPU crypto and raw data-path APIs*/
if (gbl_action_type == RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO ||
global_api_test_type == CRYPTODEV_RAW_API_TEST)
return TEST_SKIPPED;
+   if (capability == NULL)
+   return TEST_SKIPPED;
+   if (rte_cryptodev_sym_capability_check_aead(
+   capability, tdata->key.len, tdata->auth_tag.len,
+   tdata->aad.len, tdata->iv.len))
+   return TEST_SKIPPED;
 
if ((global_api_test_type == CRYPTODEV_RAW_API_TEST) &&
(!(feat_flags & RTE_CRYPTODEV_FF_SYM_RAW_DP))) {
@@ -15749,10 +15773,16 @@ test_authenticated_encryption_SGL(const struct 
aead_test_data *tdata,
 
/* Verify the capabilities */
struct rte_cryptodev_sym_capability_idx cap_idx;
+   const struct rte_cryptodev_symmetric_capability *capability;
cap_idx.type = RTE_CRYPTO_SYM_XFORM_AEAD;
cap_idx.algo.aead = tdata->algo;
-   if (rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
-   &cap_idx) == NULL)
+   capability = rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
+   &cap_idx);
+   if (capability == NULL)
+   return TEST_SKIPPED;
+   if (rte_cryptodev_sym_capability_check_aead(
+   capability, tdata->key.len, tdata->auth_tag.len,
+   tdata->aad.len, tdata->iv.len))
return TEST_SKIPPED;
 
/*
@@ -17392,6 +17422,8 @@ static struct unit_test_suite 
cryptodev_aes_gcm_auth_testsuite  = {
test_AES_GCM_auth_encryption_test_case_256_6),
TEST_CASE_ST(ut_setup, ut_teardown,
test_AES_GCM_auth_encryption_test_case_256_7),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_AES_GCM_auth_encryption_test_case_256_8),
 
/** AES GCM Authenticated Decryption 256 bits key */
TEST_CASE_ST(ut_setup, ut_teardown,
@@ -17408,6 +17440,8 @@ static struct unit_test_suite 
cryptodev_aes_gcm_auth_testsuite  = {
test_AES_GCM_auth_decryption_test_case_256_6),
TEST_CASE_ST(ut_setup, ut_teardown,

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[Dodji Seketeli]

Hello,

David Marchand  writes:

> Hello Dodji,

o/

[...]


> This change is reported as a potential ABI change.
>
> For the context, this patch
> https://patchwork.dpdk.org/project/dpdk/patch/1709012499-12813-21-git-send-email-roret...@linux.microsoft.com/
> removes null-sized markers (those fields were using RTE_MARKER, see
> https://git.dpdk.org/dpdk/tree/lib/eal/include/rte_common.h#n583) from
> the rte_mbuf struct.

Thank you for the context.

[...]


> As reported by the CI:

[...]

>   [C] 'function const rte_eth_rxtx_callback*
> rte_eth_add_first_rx_callback(uint16_t, uint16_t, rte_rx_callback_fn,
> void*)' at rte_ethdev.c:5768:1 has some indirect sub-type changes:
> parameter 3 of type 'typedef rte_rx_callback_fn' has sub-type changes:

[...]

>   in pointed to type 'struct rte_mbuf' at rte_mbuf_core.h:470:1:
> type size hasn't changed
> 4 data member deletions:
>   'RTE_MARKER cacheline0', at offset 0 (in bits) at
> rte_mbuf_core.h:467:1
>   'RTE_MARKER64 rearm_data', at offset 128 (in bits)
> at rte_mbuf_core.h:490:1
>   'RTE_MARKER rx_descriptor_fields1', at offset 256
> (in bits) at rte_mbuf_core.h:517:1
>   'RTE_MARKER cacheline1', at offset 512 (in bits) at
> rte_mbuf_core.h:598:1
> no data member change (1 filtered);

[...]

> I would argue this change do not impact ABI as the layout of the mbuf
> object is not impacted.

I agree that on the /particular platform/ that the checker runs on,
there is no incompatible ABI change because no data member offset from
the 'struct rte_mbuf' type got modified and the size of the type hasn't
changed either.


>
> Error: ABI issue reported for abidiff --suppr
> /home/runner/work/dpdk/dpdk/devtools/libabigail.abignore
> --no-added-syms --headers-dir1 reference/usr/local/include
> --headers-dir2 install/usr/local/include
> reference/usr/local/lib/librte_ethdev.so.24.0
> install/usr/local/lib/librte_ethdev.so.24.1
> ABIDIFF_ABI_CHANGE, this change requires a review (abidiff flagged
> this as a potential issue).
>
> Opinions?
>
> Btw, I see no way to suppress this (except a global [suppress_type]
> name = rte_mbuf)...

Right.

To avoid having subsequent changes to that type from being "overly"
suppressed, maybe do something like:

[suppress_type]
 name = rte_mbuf
 has_size_change = no
 has_data_member = {cacheline0, rearm_data, rx_descriptor_fields1, 
cacheline1}

That way, only size-impacting changes to struct rte_mbuf in its form
that predates this patch would be suppressed, hopefully.

[...]

Cheers,

-- 
Dodji

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[David Marchand]

On Tue, Feb 27, 2024 at 6:44 AM Tyler Retzlaff
 wrote:
>
> RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> RTE_MARKER fields from rte_mbuf struct.
>
> Maintain alignment of fields after removed cacheline1 marker by placing
> C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
>
> Update implementation of rte_mbuf_prefetch_part1() and
> rte_mbuf_prefetch_part2() inline functions calculate pointer for
> prefetch of cachline0 and cachline1 without using removed markers.
>
> Update static_assert of rte_mbuf struct fields to reference data_off and
> packet_type fields that occupy the original offsets of the marker
> fields.
>
> Signed-off-by: Tyler Retzlaff 
> ---
>  doc/guides/rel_notes/release_24_03.rst |  9 
>  lib/mbuf/rte_mbuf.h|  4 ++--
>  lib/mbuf/rte_mbuf_core.h   | 39 
> +-
>  3 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_24_03.rst 
> b/doc/guides/rel_notes/release_24_03.rst
> index 879bb49..67750f2 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -156,6 +156,15 @@ Removed Items
>The application reserved statically defined logtypes 
> ``RTE_LOGTYPE_USER1..RTE_LOGTYPE_USER8``
>are still defined.
>
> +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` ``cacheline1``
> +  ``rx_descriptor_fields1`` and ``RTE_MARKER64`` field ``rearm_data``
> +  have been removed from ``struct rte_mbuf``.
> +  Prefetch of ``cacheline0`` and ``cacheline1`` may be achieved through
> +  ``rte_mbuf_prefetch_part1()`` and ``rte_mbuf_prefetch_part2()`` inline
> +  functions respectively.
> +  Access to ``rearm_data`` and ``rx_descriptor_fields1`` should be
> +  through new inline functions ``rte_mbuf_rearm_data()`` and
> +  ``rte_mbuf_rx_descriptor_fields1()`` respectively.
>
>  API Changes
>  ---
> diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> index aa7495b..61cda20 100644
> --- a/lib/mbuf/rte_mbuf.h
> +++ b/lib/mbuf/rte_mbuf.h
> @@ -108,7 +108,7 @@
>  static inline void
>  rte_mbuf_prefetch_part1(struct rte_mbuf *m)
>  {
> -   rte_prefetch0(&m->cacheline0);
> +   rte_prefetch0(m);
>  }
>
>  /**
> @@ -126,7 +126,7 @@
>  rte_mbuf_prefetch_part2(struct rte_mbuf *m)
>  {
>  #if RTE_CACHE_LINE_SIZE == 64
> -   rte_prefetch0(&m->cacheline1);
> +   rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
>  #else
> RTE_SET_USED(m);
>  #endif
> diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> index 36551c2..4e06f15 100644
> --- a/lib/mbuf/rte_mbuf_core.h
> +++ b/lib/mbuf/rte_mbuf_core.h
> @@ -18,6 +18,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -467,8 +468,6 @@ enum {
>   * The generic rte_mbuf, containing a packet mbuf.
>   */
>  struct rte_mbuf {
> -   RTE_MARKER cacheline0;
> -
> void *buf_addr;   /**< Virtual address of segment buffer. */
>  #if RTE_IOVA_IN_MBUF
> /**
> @@ -495,7 +494,6 @@ struct rte_mbuf {
>  * To obtain a pointer to rearm_data use the rte_mbuf_rearm_data()
>  * accessor instead of directly referencing through the data_off 
> field.
>  */
> -   RTE_MARKER64 rearm_data;
> uint16_t data_off;

One subtile change of removing the marker is that fields may not be
aligned as before.

#if RTE_IOVA_IN_MBUF
/**
 * Physical address of segment buffer.
 * This field is undefined if the build is configured to use only
 * virtual address as IOVA (i.e. RTE_IOVA_IN_MBUF is 0).
 * Force alignment to 8-bytes, so as to ensure we have the exact
 * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
 * working on vector drivers easier.
 */
rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
#else
/**
 * Next segment of scattered packet.
 * This field is valid when physical address field is undefined.
 * Otherwise next pointer in the second cache line will be used.
 */
struct rte_mbuf *next;
#endif

When building ! RTE_IOVA_IN_MBUF on a 32 bits arch, the next pointer
is not force aligned to 64bits.
Which has a cascade effect on data_off alignement.

In file included from ../lib/mbuf/rte_mbuf_core.h:19,
 from ../lib/mbuf/rte_mbuf.h:42,
 from ../lib/mbuf/rte_mbuf_dyn.c:18:
../lib/mbuf/rte_mbuf_core.h:676:1: error: static assertion failed: "data_off"
  676 | static_assert(!(offsetof(struct rte_mbuf, data_off) !=
  | ^


I hope reviewers pay attention to the alignment changes when removing
those markers.
This is not trivial to catch in the CI.


-- 
David Marchand

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[David Marchand]

On Wed, Feb 28, 2024 at 3:04 PM Dodji Seketeli  wrote:
> > Btw, I see no way to suppress this (except a global [suppress_type]
> > name = rte_mbuf)...
>
> Right.
>
> To avoid having subsequent changes to that type from being "overly"
> suppressed, maybe do something like:
>
> [suppress_type]
>  name = rte_mbuf
>  has_size_change = no
>  has_data_member = {cacheline0, rearm_data, rx_descriptor_fields1, 
> cacheline1}
>
> That way, only size-impacting changes to struct rte_mbuf in its form
> that predates this patch would be suppressed, hopefully.

Do you mean, only changes *not* size-impacting would be suppressed?

This is slightly better than the suppression on the whole rte_mbuf
object, but it won't catch field reordering iiuc.

On the other hand, now that I try reordering fields (to test this
suggestion of yours), I get build failures all over the DPDK tree
because we have many build checks to ensure those fields are at known
locations...
So maybe we can relax and just go with the full suppression.


-- 
David Marchand

Re: [PATCH v5 4/4] hash: add SVE support for bulk key lookup

[Yoan Picchi]

On 2/28/24 10:56, Konstantin Ananyev wrote:




- Implemented SVE code for comparing signatures in bulk lookup.
- Added Defines in code for SVE code support.
- Optimise NEON code
- New SVE code is ~5% slower than optimized NEON for N2 processor.

Signed-off-by: Yoan Picchi 
Signed-off-by: Harjot Singh 
Reviewed-by: Nathan Brown 
Reviewed-by: Ruifeng Wang 
---
  lib/hash/rte_cuckoo_hash.c | 196 -
  lib/hash/rte_cuckoo_hash.h |   1 +
  2 files changed, 151 insertions(+), 46 deletions(-)

diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index a07dd3a28d..231d6d6ded 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -442,8 +442,11 @@ rte_hash_create(const struct rte_hash_parameters *params)
h->sig_cmp_fn = RTE_HASH_COMPARE_SSE;
else
  #elif defined(RTE_ARCH_ARM64)
-   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON))
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) {
h->sig_cmp_fn = RTE_HASH_COMPARE_NEON;
+   if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
+   h->sig_cmp_fn = RTE_HASH_COMPARE_SVE;
+   }
else
  #endif
h->sig_cmp_fn = RTE_HASH_COMPARE_SCALAR;
@@ -1860,37 +1863,103 @@ rte_hash_free_key_with_position(const struct rte_hash 
*h,
  #if defined(__ARM_NEON)

  static inline void
-compare_signatures_dense(uint32_t *prim_hash_matches, uint32_t 
*sec_hash_matches,
-   const struct rte_hash_bucket *prim_bkt,
-   const struct rte_hash_bucket *sec_bkt,
+compare_signatures_dense(uint16_t *hitmask_buffer,
+   const uint16_t *prim_bucket_sigs,
+   const uint16_t *sec_bucket_sigs,
uint16_t sig,
enum rte_hash_sig_compare_function sig_cmp_fn)
  {
unsigned int i;

+   static_assert(sizeof(*hitmask_buffer) >= 2*(RTE_HASH_BUCKET_ENTRIES/8),
+   "The hitmask must be exactly wide enough to accept the whole hitmask if it 
is dense");
+
/* For match mask every bits indicates the match */
switch (sig_cmp_fn) {


Can I ask to move arch specific comparison code into some arch-specific headers 
or so?
It is getting really hard to read and understand the generic code with all 
these ifdefs and arch specific instructions...



I can easily enough move the compare_signatures into an arm/x86 
directory, and have a default version in the code.
The problem would be for bulk lookup. The function is already duplicated 
 2 times (the l and lf version). If I remove the #ifdefs, I'll need to 
duplicate them again into 4 nearly identical versions (dense and 
sparse). The only third options I see would be some preprocessor macro 
to patch the function, but that looks even dirtier to me.
I think duplicating the code would be bad, but I can do it if you want. 
Unless you have a better solution?



+#if RTE_HASH_BUCKET_ENTRIES <= 8
case RTE_HASH_COMPARE_NEON: {
-   uint16x8_t vmat, x;
+   uint16x8_t vmat, hit1, hit2;
const uint16x8_t mask = {0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 
0x80};
const uint16x8_t vsig = vld1q_dup_u16((uint16_t const *)&sig);

/* Compare all signatures in the primary bucket */
-   vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
*)prim_bkt->sig_current));
-   x = vandq_u16(vmat, mask);
-   *prim_hash_matches = (uint32_t)(vaddvq_u16(x));
+   vmat = vceqq_u16(vsig, vld1q_u16(prim_bucket_sigs));
+   hit1 = vandq_u16(vmat, mask);
+
/* Compare all signatures in the secondary bucket */
-   vmat = vceqq_u16(vsig, vld1q_u16((uint16_t const 
*)sec_bkt->sig_current));
-   x = vandq_u16(vmat, mask);
-   *sec_hash_matches = (uint32_t)(vaddvq_u16(x));
+   vmat = vceqq_u16(vsig, vld1q_u16(sec_bucket_sigs));
+   hit2 = vandq_u16(vmat, mask);
+
+   hit2 = vshlq_n_u16(hit2, RTE_HASH_BUCKET_ENTRIES);
+   hit2 = vorrq_u16(hit1, hit2);
+   *hitmask_buffer = vaddvq_u16(hit2);
+   }
+   break;
+#endif
+#if defined(RTE_HAS_SVE_ACLE)
+   case RTE_HASH_COMPARE_SVE: {
+   svuint16_t vsign, shift, sv_matches;
+   svbool_t pred, match, bucket_wide_pred;
+   int i = 0;
+   uint64_t vl = svcnth();
+
+   vsign = svdup_u16(sig);
+   shift = svindex_u16(0, 1);
+
+   if (vl >= 2 * RTE_HASH_BUCKET_ENTRIES && RTE_HASH_BUCKET_ENTRIES 
<= 8) {
+   svuint16_t primary_array_vect, secondary_array_vect;
+   bucket_wide_pred = svwhilelt_b16(0, 
RTE_HASH_BUCKET_ENTRIES);
+   primary_array_vect = svld1_u16(bucket_wide_pred, 
prim_bucket_sigs);
+   secondary_array_vect = svld1_u16(bu

Re: [PATCH v2] dts: strip whitespaces from stdout and stderr

[Patrick Robb]

Acked-by: Patrick Robb 

Re: [PATCH] lib/hash,lib/rcu: feature hidden key count in hash

[Honnappa Nagarahalli]

> On Feb 28, 2024, at 5:44 AM, Abdullah Ömer Yamaç  wrote:
> 
> While I was implementing the new API, I realized one issue, and it would be 
> good to discuss it here. First of all rte_rcu_qsbr_dq_reclaim function checks 
> the state of the qsbr values. It means that all threads should report the 
> quiescent states. It conflicts with my aim.
> 
> Let's think about below scenario:
> Eight threads use a hash table and periodically report their quiescent 
> states. One additional thread (main thread) periodically reports the hash 
> size. I implemented the reclaim function in that thread. I mean, the main 
> thread calls reclaim before the rte_hash_count.
> 
> Here is the exceptional case that I couldn't retrieve the correct hash size:
> Assume that 6 of 8 threads reported quiescent states and 2 of them are still 
> working on some process and haven't reported quiescent states yet. The main 
> thread calls reclaim functions every time, but elements in dq will not be 
> freed because 2 of the worker threads haven't reported their states 
> (especially if they are waiting for some packets). So, my first proposed 
> method is more suitable for this case. Any idea?
If 2 out of 8 threads have not reported their quiescent state then the elements 
that have not been acknowledged by those 2 threads cannot be reclaimed and 
cannot be allocated for further use. Using this you can calculate the most 
accurate number of entries in the hash table available for allocation.

> 
> On Thu, Feb 22, 2024 at 7:44 PM Honnappa Nagarahalli 
>  wrote:
> 
> 
> > On Feb 22, 2024, at 6:39 AM, Abdullah Ömer Yamaç  
> > wrote:
> > 
> > As a final decision, I will add a new hash API that forces the reclaim. Is 
> > it ok for everyone?
> Ack from my side
> 
> > 
> > On Thu, Feb 22, 2024 at 5:37 AM Honnappa Nagarahalli 
> >  wrote:
> > 
> > 
> > > On Feb 21, 2024, at 3:51 PM, Abdullah Ömer Yamaç  
> > > wrote:
> > > 
> > > 
> > > 
> > > On Wed, Feb 21, 2024 at 6:24 AM Honnappa Nagarahalli 
> > >  wrote:
> > > 
> > > 
> > > > On Feb 20, 2024, at 12:58 PM, Abdullah Ömer Yamaç 
> > > >  wrote:
> > > > 
> > > > I appreciate that you gave me suggestions and comments. I will make 
> > > > changes according to all your recommendations, but before that, I want 
> > > > to make everyone's minds clear. Then, I will apply modifications. 
> > > > 
> > > > On Tue, Feb 20, 2024 at 2:35 AM Honnappa Nagarahalli 
> > > >  wrote:
> > > > 
> > > > 
> > > > > On Feb 19, 2024, at 3:28 PM, Abdullah Ömer Yamaç 
> > > > >  wrote:
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > Let me explain a use case;
> > > > > 
> > > > > I have a hash table whose key value is IP addresses, and data (let's 
> > > > > say the username of the IP) is related to the IP address. The key 
> > > > > point is matching these data with flows. Flows are dynamic, and this 
> > > > > hash table is dynamic, as well; both can change anytime. For example, 
> > > > > when a flow starts, we look up the hash table with the corresponding 
> > > > > IP and retrieve the username. We need to hold this username until the 
> > > > > flow terminates, although we removed this IP key from the hash table 
> > > > > (multithread). That's why we have RCU and defer queue is necessary 
> > > > > for high performance. In my application, I need to know the number of 
> > > > > IP-username entries. These numbers can be calculated by 
> > > > > rte_hash_count - defer queue size.
> > > > The entries in the defer queue are not reclaimed (there is a 
> > > > probability that all of them can be reclaimed) and hence they are not 
> > > > available for allocation. So, rte_hash_count - defer queue size might 
> > > > not give you the correct number you are expecting.
> > > > 
> > > > Currently, there is no API in hash library that forces a reclaim. Does 
> > > > it makes sense to have an API that just does the reclaim (and returns 
> > > > the number of entries pending in the defer queue)? A call to 
> > > > rte_hash_count should provide the exact count you are looking for.
> > > > You are right; no API in the hash library forces a reclaim. In my 
> > > > application, I periodically call rte_count to retrieve hash size, and 
> > > > this data is shown in my GUI. So that means I need to call regularly 
> > > > reclaim. I am trying to figure out which is better, calling reclaim or 
> > > > retrieving the defer queue size. Any comment about this?
> > > Retrieving the defer queue size will be cheaper. However, calling the 
> > > reclaim API will ensure the entries are freed hence providing an accurate 
> > > number. Calling the reclaim API on an empty defer queue does not consume 
> > > many cycles. If needed we could add a check for empty defer queue in the 
> > > reclaim API and return early.
> > > 
> > > I am also wondering if a reclaim API in hash library is needed. Why not 
> > > call rte_rcu_qsbr_dq_reclaim API from the application?
> > > The reason is simple. struct rte_hash *h is an internal structure and we 
> > 

RE: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[Morten Brørup]

> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Wednesday, 28 February 2024 15.19
> 
> On Tue, Feb 27, 2024 at 6:44 AM Tyler Retzlaff
>  wrote:
> >
> > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > RTE_MARKER fields from rte_mbuf struct.
> >
> > Maintain alignment of fields after removed cacheline1 marker by placing
> > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> >
> > Update implementation of rte_mbuf_prefetch_part1() and
> > rte_mbuf_prefetch_part2() inline functions calculate pointer for
> > prefetch of cachline0 and cachline1 without using removed markers.
> >
> > Update static_assert of rte_mbuf struct fields to reference data_off and
> > packet_type fields that occupy the original offsets of the marker
> > fields.
> >
> > Signed-off-by: Tyler Retzlaff 
> > ---
> >  doc/guides/rel_notes/release_24_03.rst |  9 
> >  lib/mbuf/rte_mbuf.h|  4 ++--
> >  lib/mbuf/rte_mbuf_core.h   | 39 +--
> ---
> >  3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> > index 879bb49..67750f2 100644
> > --- a/doc/guides/rel_notes/release_24_03.rst
> > +++ b/doc/guides/rel_notes/release_24_03.rst
> > @@ -156,6 +156,15 @@ Removed Items
> >The application reserved statically defined logtypes
> ``RTE_LOGTYPE_USER1..RTE_LOGTYPE_USER8``
> >are still defined.
> >
> > +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` ``cacheline1``
> > +  ``rx_descriptor_fields1`` and ``RTE_MARKER64`` field ``rearm_data``
> > +  have been removed from ``struct rte_mbuf``.
> > +  Prefetch of ``cacheline0`` and ``cacheline1`` may be achieved through
> > +  ``rte_mbuf_prefetch_part1()`` and ``rte_mbuf_prefetch_part2()`` inline
> > +  functions respectively.
> > +  Access to ``rearm_data`` and ``rx_descriptor_fields1`` should be
> > +  through new inline functions ``rte_mbuf_rearm_data()`` and
> > +  ``rte_mbuf_rx_descriptor_fields1()`` respectively.
> >
> >  API Changes
> >  ---
> > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > index aa7495b..61cda20 100644
> > --- a/lib/mbuf/rte_mbuf.h
> > +++ b/lib/mbuf/rte_mbuf.h
> > @@ -108,7 +108,7 @@
> >  static inline void
> >  rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> >  {
> > -   rte_prefetch0(&m->cacheline0);
> > +   rte_prefetch0(m);
> >  }
> >
> >  /**
> > @@ -126,7 +126,7 @@
> >  rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> >  {
> >  #if RTE_CACHE_LINE_SIZE == 64
> > -   rte_prefetch0(&m->cacheline1);
> > +   rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> >  #else
> > RTE_SET_USED(m);
> >  #endif
> > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > index 36551c2..4e06f15 100644
> > --- a/lib/mbuf/rte_mbuf_core.h
> > +++ b/lib/mbuf/rte_mbuf_core.h
> > @@ -18,6 +18,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -467,8 +468,6 @@ enum {
> >   * The generic rte_mbuf, containing a packet mbuf.
> >   */
> >  struct rte_mbuf {
> > -   RTE_MARKER cacheline0;
> > -
> > void *buf_addr;   /**< Virtual address of segment buffer. */
> >  #if RTE_IOVA_IN_MBUF
> > /**
> > @@ -495,7 +494,6 @@ struct rte_mbuf {
> >  * To obtain a pointer to rearm_data use the rte_mbuf_rearm_data()
> >  * accessor instead of directly referencing through the data_off
> field.
> >  */
> > -   RTE_MARKER64 rearm_data;
> > uint16_t data_off;
> 
> One subtile change of removing the marker is that fields may not be
> aligned as before.
> 
> #if RTE_IOVA_IN_MBUF
> /**
>  * Physical address of segment buffer.
>  * This field is undefined if the build is configured to use only
>  * virtual address as IOVA (i.e. RTE_IOVA_IN_MBUF is 0).
>  * Force alignment to 8-bytes, so as to ensure we have the exact
>  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
>  * working on vector drivers easier.
>  */
> rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> #else
> /**
>  * Next segment of scattered packet.
>  * This field is valid when physical address field is undefined.
>  * Otherwise next pointer in the second cache line will be used.
>  */
> struct rte_mbuf *next;
> #endif
> 
> When building ! RTE_IOVA_IN_MBUF on a 32 bits arch, the next pointer
> is not force aligned to 64bits.
> Which has a cascade effect on data_off alignement.
> 
> In file included from ../lib/mbuf/rte_mbuf_core.h:19,
>  from ../lib/mbuf/rte_mbuf.h:42,
>  from ../lib/mbuf/rte_mbuf_dyn.c:18:
> ../lib/mbuf/rte_mbuf_core.h:676:1: error: static assertion failed: "data_off"
>   676 | static_assert(!(offsetof(struct rte_mbuf, data_off) !=
>   | ^
> 
> 
> I hope reviewers pay attention to the alignment c

[PATCH v4 0/5] NAT64 support in mlx5 PMD

[Bing Zhao]

This patch set contains the mlx5 PMD implementation for NAT64.

Series-acked-by: Ori Kam 

Update in v4:
  1. rebase to solve the conflicts.
  2. fix the old NIC startup issue in a separate patch:
 
https://patches.dpdk.org/project/dpdk/patch/20240227152627.25749-1-bi...@nvidia.com/

Update in v3:
  1. code style and typo.

Update in v2:
  1. separate from the RTE and testpmd common part.
  2. reorder the commits.
  3. bug fix, code polishing and document update.

Bing Zhao (4):
  net/mlx5: fetch the available registers for NAT64
  net/mlx5: create NAT64 actions during configuration
  net/mlx5: add NAT64 action support in rule creation
  net/mlx5: validate the actions combination with NAT64

Erez Shitrit (1):
  net/mlx5/hws: support NAT64 action

 doc/guides/nics/features/mlx5.ini  |   1 +
 doc/guides/nics/mlx5.rst   |  10 +
 doc/guides/rel_notes/release_24_03.rst |   7 +
 drivers/net/mlx5/hws/mlx5dr.h  |  29 ++
 drivers/net/mlx5/hws/mlx5dr_action.c   | 436 -
 drivers/net/mlx5/hws/mlx5dr_action.h   |  35 ++
 drivers/net/mlx5/hws/mlx5dr_debug.c|   1 +
 drivers/net/mlx5/mlx5.c|   9 +
 drivers/net/mlx5/mlx5.h|  11 +
 drivers/net/mlx5/mlx5_flow.h   |  12 +
 drivers/net/mlx5/mlx5_flow_dv.c|   4 +-
 drivers/net/mlx5/mlx5_flow_hw.c| 136 
 12 files changed, 689 insertions(+), 2 deletions(-)

-- 
2.39.3

[PATCH v4 1/5] net/mlx5/hws: support NAT64 action

[Bing Zhao]

From: Erez Shitrit 

Add support of new action mlx5dr_action_create_nat64.
The new action allows to modify IP packets from version to version, IPV6
to IPV4 and vice versa.

Signed-off-by: Erez Shitrit 
Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/hws/mlx5dr.h|  29 ++
 drivers/net/mlx5/hws/mlx5dr_action.c | 436 ++-
 drivers/net/mlx5/hws/mlx5dr_action.h |  35 +++
 drivers/net/mlx5/hws/mlx5dr_debug.c  |   1 +
 4 files changed, 500 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index d612f300c6..8441ae97e9 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -51,6 +51,7 @@ enum mlx5dr_action_type {
MLX5DR_ACTION_TYP_DEST_ARRAY,
MLX5DR_ACTION_TYP_POP_IPV6_ROUTE_EXT,
MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT,
+   MLX5DR_ACTION_TYP_NAT64,
MLX5DR_ACTION_TYP_MAX,
 };
 
@@ -868,6 +869,34 @@ mlx5dr_action_create_reformat_ipv6_ext(struct 
mlx5dr_context *ctx,
   uint32_t log_bulk_size,
   uint32_t flags);
 
+enum mlx5dr_action_nat64_flags {
+   MLX5DR_ACTION_NAT64_V4_TO_V6 = 1 << 0,
+   MLX5DR_ACTION_NAT64_V6_TO_V4 = 1 << 1,
+   /* Indicates if to backup ipv4 addresses in last two registers */
+   MLX5DR_ACTION_NAT64_BACKUP_ADDR = 1 << 2,
+};
+
+struct mlx5dr_action_nat64_attr {
+   uint8_t num_of_registers;
+   uint8_t *registers;
+   enum mlx5dr_action_nat64_flags flags;
+};
+
+/* Create direct rule nat64 action.
+ *
+ * @param[in] ctx
+ * The context in which the new action will be created.
+ * @param[in] attr
+ * The relevant attribute of the NAT action.
+ * @param[in] flags
+ * Action creation flags. (enum mlx5dr_action_flags)
+ * @return pointer to mlx5dr_action on success NULL otherwise.
+ */
+struct mlx5dr_action *
+mlx5dr_action_create_nat64(struct mlx5dr_context *ctx,
+  struct mlx5dr_action_nat64_attr *attr,
+  uint32_t flags);
+
 /* Destroy direct rule action.
  *
  * @param[in] action
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c 
b/drivers/net/mlx5/hws/mlx5dr_action.c
index 631763dee0..96cad553aa 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -31,6 +31,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -52,6 +53,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -75,6 +77,7 @@ static const uint32_t 
action_order_arr[MLX5DR_TABLE_TYPE_MAX][MLX5DR_ACTION_TYP_
BIT(MLX5DR_ACTION_TYP_ASO_CT),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
BIT(MLX5DR_ACTION_TYP_PUSH_VLAN),
+   BIT(MLX5DR_ACTION_TYP_NAT64),
BIT(MLX5DR_ACTION_TYP_MODIFY_HDR),
BIT(MLX5DR_ACTION_TYP_INSERT_HEADER) |
BIT(MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT) |
@@ -246,6 +249,310 @@ static void mlx5dr_action_put_shared_stc(struct 
mlx5dr_action *action,
mlx5dr_action_put_shared_stc_nic(ctx, stc_type, 
MLX5DR_TABLE_TYPE_FDB);
 }
 
+static struct mlx5dr_action *
+mlx5dr_action_create_nat64_copy_state(struct mlx5dr_context *ctx,
+ struct mlx5dr_action_nat64_attr *attr,
+ uint32_t flags)
+{
+   __be64 modify_action_data[MLX5DR_ACTION_NAT64_MAX_MODIFY_ACTIONS];
+   struct mlx5dr_action_mh_pattern pat[2];
+   struct mlx5dr_action *action;
+   uint32_t packet_len_field;
+   uint8_t *action_ptr;
+   uint32_t ttl_field;
+   uint32_t src_addr;
+   uint32_t dst_addr;
+   bool is_v4_to_v6;
+
+   is_v4_to_v6 = attr->flags & MLX5DR_ACTION_NAT64_V4_TO_V6;
+
+   if (is_v4_to_v6) {
+   packet_len_field = MLX5_MODI_OUT_IPV4_TOTAL_LEN;
+   ttl_field = MLX5_MODI_OUT_IPV4_TTL;
+   src_addr = MLX5_MODI_OUT_SIPV4;
+   dst_addr = MLX5_MODI_OUT_DIPV4;
+   } else {
+   packet_len_field = MLX5_MODI_OUT_IPV6_PAYLOAD_LEN;
+   ttl_field = MLX5_MODI_OUT_IPV6_HOPLIMIT;
+   src_addr = MLX5_MODI_OUT_SIPV6_31_0;
+   dst

[PATCH v4 2/5] net/mlx5: fetch the available registers for NAT64

[Bing Zhao]

REG_C_6 is used as the 1st one and since it is reserved internally
by default, there is no impact.

The remaining 2 registers will be fetched from the available TAGs
array from right to left. They will not be masked in the array due
to the fact that not all the rules will use NAT64 action.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5.c | 9 +
 drivers/net/mlx5/mlx5.h | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index f2ca0ae4c2..cc7cd6adf5 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -1644,6 +1644,15 @@ mlx5_init_hws_flow_tags_registers(struct 
mlx5_dev_ctx_shared *sh)
if (!!((1 << i) & masks))
reg->hw_avl_tags[j++] = mlx5_regc_value(i);
}
+   /*
+* Set the registers for NAT64 usage internally. REG_C_6 is always used.
+* The other 2 registers will be fetched from right to left, at least 2
+* tag registers should be available.
+*/
+   MLX5_ASSERT(j >= (MLX5_FLOW_NAT64_REGS_MAX - 1));
+   reg->nat64_regs[0] = REG_C_6;
+   reg->nat64_regs[1] = reg->hw_avl_tags[j - 2];
+   reg->nat64_regs[2] = reg->hw_avl_tags[j - 1];
 }
 
 static void
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 99850a58af..ee17a30454 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1407,10 +1407,12 @@ struct mlx5_hws_cnt_svc_mng {
 };
 
 #define MLX5_FLOW_HW_TAGS_MAX 12
+#define MLX5_FLOW_NAT64_REGS_MAX 3
 
 struct mlx5_dev_registers {
enum modify_reg aso_reg;
enum modify_reg hw_avl_tags[MLX5_FLOW_HW_TAGS_MAX];
+   enum modify_reg nat64_regs[MLX5_FLOW_NAT64_REGS_MAX];
 };
 
 #if defined(HAVE_MLX5DV_DR) && \
-- 
2.39.3

[PATCH v4 3/5] net/mlx5: create NAT64 actions during configuration

[Bing Zhao]

The NAT64 DR actions can be shared among the tables. All these
actions can be created during configuring the flow queues and saved
for the future usage.

Even the actions can be shared now, inside per each flow rule, the
actual hardware resources are unique.

Signed-off-by: Bing Zhao 
---
 doc/guides/nics/features/mlx5.ini  |  1 +
 doc/guides/nics/mlx5.rst   | 10 
 doc/guides/rel_notes/release_24_03.rst |  7 +++
 drivers/net/mlx5/mlx5.h|  9 
 drivers/net/mlx5/mlx5_flow.h   | 11 +
 drivers/net/mlx5/mlx5_flow_dv.c|  4 +-
 drivers/net/mlx5/mlx5_flow_hw.c| 65 ++
 7 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/features/mlx5.ini 
b/doc/guides/nics/features/mlx5.ini
index 30027f2ba1..81a7067cc3 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -117,6 +117,7 @@ mark = Y
 meter= Y
 meter_mark   = Y
 modify_field = Y
+nat64= Y
 nvgre_decap  = Y
 nvgre_encap  = Y
 of_pop_vlan  = Y
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 329b98f68f..c0294f268d 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,6 +168,7 @@ Features
 - Sub-Function.
 - Matching on represented port.
 - Matching on aggregated affinity.
+- NAT64.
 
 
 Limitations
@@ -886,6 +887,15 @@ Limitations
   if preceding active application rules are still present and vice versa.
 
 
+- NAT64 action:
+  - Supported only with HW Steering enabled (``dv_flow_en`` = 2).
+  - FW version: at least ``XX.39.1002``.
+  - Supported only on non-root table.
+  - Actions order limitation should follow the modify fields action.
+  - The last 2 TAG registers will be used implicitly in address backup mode.
+  - Even if the action can be shared, new steering entries will be created per 
flow rule. It is recommended a single rule with NAT64 should be shared to 
reduce the duplication of entries. The default address and other fields 
covertion will be handled with NAT64 action. To support other address, new 
rule(s) with modify fields on the IP addresses should be created.
+  - TOS / Traffic Class is not supported now.
+
 Statistics
 --
 
diff --git a/doc/guides/rel_notes/release_24_03.rst 
b/doc/guides/rel_notes/release_24_03.rst
index 23ac6568ac..744f530ead 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -101,6 +101,11 @@ New Features
   * ``rte_flow_template_table_resize_complete()``.
 Complete table resize.
 
+* **Added a flow action type for NAT64.**
+
+  Added ``RTE_FLOW_ACTION_TYPE_NAT64`` to support offloading of header 
conversion
+  between IPv4 and IPv6.
+
 * **Updated Atomic Rules' Arkville driver.**
 
   * Added support for Atomic Rules' TK242 packet-capture family of devices
@@ -145,6 +150,8 @@ New Features
 to support TLS v1.2, TLS v1.3 and DTLS v1.2.
   * Added PMD API to allow raw submission of instructions to CPT.
 
+  * Added support for ``RTE_FLOW_ACTION_TYPE_NAT64`` flow action in HW 
Steering flow engine.
+
 
 Removed Items
 -
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index ee17a30454..c47712a146 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1997,7 +1997,16 @@ struct mlx5_priv {
struct mlx5_aso_mtr_pool *hws_mpool; /* HW steering's Meter pool. */
struct mlx5_flow_hw_ctrl_rx *hw_ctrl_rx;
/**< HW steering templates used to create control flow rules. */
+
struct rte_flow_actions_template 
*action_template_drop[MLX5DR_TABLE_TYPE_MAX];
+
+   /*
+* The NAT64 action can be shared among matchers per domain.
+* [0]: RTE_FLOW_NAT64_6TO4, [1]: RTE_FLOW_NAT64_4TO6
+* Todo: consider to add *_MAX macro.
+*/
+   struct mlx5dr_action *action_nat64[MLX5DR_TABLE_TYPE_MAX][2];
+
 #endif
struct rte_eth_dev *shared_host; /* Host device for HW steering. */
uint16_t shared_refcnt; /* HW steering host reference counter. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 187f440893..897a283716 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -169,6 +169,17 @@ struct mlx5_rte_flow_item_sq {
uint32_t queue; /* DevX SQ number */
 };
 
+/* Map from registers to modify fields. */
+extern enum mlx5_modification_field reg_to_field[];
+extern const size_t mlx5_mod_reg_size;
+
+static __rte_always_inline enum mlx5_modification_field
+mlx5_convert_reg_to_field(enum modify_reg reg)
+{
+   MLX5_ASSERT((size_t)reg < mlx5_mod_reg_size);
+   return reg_to_field[reg];
+}
+
 /* Feature name to allocate metadata register. */
 enum mlx5_feature_name {
MLX5_HAIRPIN_RX,
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ddf19e9a51..18f09b22be 100644
--- a/drivers/net/mlx5/mlx5_

[PATCH v4 4/5] net/mlx5: add NAT64 action support in rule creation

[Bing Zhao]

The action will handle the IPv4 and IPv6 headers translation. It will
add / remove IPv6 address prefix by default.

To use the user specific address, another rule to modify the
addresses of the IP header is needed.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 77f0aff91e..f32bdff98f 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -2499,6 +2499,19 @@ __flow_hw_actions_translate(struct rte_eth_dev *dev,
}
acts->rule_acts[dr_pos].action = priv->hw_def_miss;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   if (masks->conf &&
+   ((const struct rte_flow_action_nat64 
*)masks->conf)->type) {
+   const struct rte_flow_action_nat64 *nat64_c =
+   (const struct rte_flow_action_nat64 
*)actions->conf;
+
+   acts->rule_acts[dr_pos].action =
+   priv->action_nat64[type][nat64_c->type];
+   } else if (__flow_hw_act_data_general_append(priv, acts,
+
actions->type,
+src_pos, 
dr_pos))
+   goto err;
+   break;
case RTE_FLOW_ACTION_TYPE_END:
actions_end = true;
break;
@@ -2941,6 +2954,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
const struct rte_flow_action_ethdev *port_action = NULL;
const struct rte_flow_action_meter *meter = NULL;
const struct rte_flow_action_age *age = NULL;
+   const struct rte_flow_action_nat64 *nat64_c = NULL;
uint8_t *buf = job->encap_data;
uint8_t *push_buf = job->push_data;
struct rte_flow_attr attr = {
@@ -3208,6 +3222,11 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
if (ret != 0)
return ret;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   nat64_c = action->conf;
+   rule_acts[act_data->action_dst].action =
+   priv->action_nat64[table->type][nat64_c->type];
+   break;
default:
break;
}
@@ -6099,6 +6118,7 @@ static enum mlx5dr_action_type mlx5_hw_dr_action_types[] 
= {
[RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL] = MLX5DR_ACTION_TYP_DEST_ROOT,
[RTE_FLOW_ACTION_TYPE_IPV6_EXT_PUSH] = 
MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT,
[RTE_FLOW_ACTION_TYPE_IPV6_EXT_REMOVE] = 
MLX5DR_ACTION_TYP_POP_IPV6_ROUTE_EXT,
+   [RTE_FLOW_ACTION_TYPE_NAT64] = MLX5DR_ACTION_TYP_NAT64,
 };
 
 static inline void
-- 
2.39.3

[PATCH v4 5/5] net/mlx5: validate the actions combination with NAT64

[Bing Zhao]

NAT64 is treated as a modify header action. The action order and
limitation should be the same as that of modify header in each
domain.

Since the last 2 TAG registers will be used implicitly in the
address backup mode, the values in these registers are no longer
valid after the NAT64 action. The application should not try to
match these TAGs after the rule that contains NAT64 action.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow.h|  1 +
 drivers/net/mlx5/mlx5_flow_hw.c | 51 +
 2 files changed, 52 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 897a283716..ea428a8c21 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -392,6 +392,7 @@ enum mlx5_feature_name {
 #define MLX5_FLOW_ACTION_PORT_REPRESENTOR (1ull << 47)
 #define MLX5_FLOW_ACTION_IPV6_ROUTING_REMOVE (1ull << 48)
 #define MLX5_FLOW_ACTION_IPV6_ROUTING_PUSH (1ull << 49)
+#define MLX5_FLOW_ACTION_NAT64 (1ull << 50)
 
 #define MLX5_FLOW_DROP_INCLUSIVE_ACTIONS \
(MLX5_FLOW_ACTION_COUNT | MLX5_FLOW_ACTION_SAMPLE | 
MLX5_FLOW_ACTION_AGE)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index f32bdff98f..7730bcab6f 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -5866,6 +5866,50 @@ flow_hw_validate_action_default_miss(struct rte_eth_dev 
*dev,
return 0;
 }
 
+static int
+flow_hw_validate_action_nat64(struct rte_eth_dev *dev,
+ const struct rte_flow_actions_template_attr *attr,
+ const struct rte_flow_action *action,
+ const struct rte_flow_action *mask,
+ uint64_t action_flags,
+ struct rte_flow_error *error)
+{
+   struct mlx5_priv *priv = dev->data->dev_private;
+   const struct rte_flow_action_nat64 *nat64_c;
+   enum rte_flow_nat64_type cov_type;
+
+   RTE_SET_USED(action_flags);
+   if (mask->conf && ((const struct rte_flow_action_nat64 
*)mask->conf)->type) {
+   nat64_c = (const struct rte_flow_action_nat64 *)action->conf;
+   cov_type = nat64_c->type;
+   if ((attr->ingress && 
!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_RX][cov_type]) ||
+   (attr->egress && 
!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_TX][cov_type]) ||
+   (attr->transfer && 
!priv->action_nat64[MLX5DR_TABLE_TYPE_FDB][cov_type]))
+   goto err_out;
+   } else {
+   /*
+* Usually, the actions will be used on both directions. For 
non-masked actions,
+* both directions' actions will be checked.
+*/
+   if (attr->ingress)
+   if 
(!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_RX][RTE_FLOW_NAT64_6TO4] ||
+   
!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_RX][RTE_FLOW_NAT64_4TO6])
+   goto err_out;
+   if (attr->egress)
+   if 
(!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_TX][RTE_FLOW_NAT64_6TO4] ||
+   
!priv->action_nat64[MLX5DR_TABLE_TYPE_NIC_TX][RTE_FLOW_NAT64_4TO6])
+   goto err_out;
+   if (attr->transfer)
+   if 
(!priv->action_nat64[MLX5DR_TABLE_TYPE_FDB][RTE_FLOW_NAT64_6TO4] ||
+   
!priv->action_nat64[MLX5DR_TABLE_TYPE_FDB][RTE_FLOW_NAT64_4TO6])
+   goto err_out;
+   }
+   return 0;
+err_out:
+   return rte_flow_error_set(error, EOPNOTSUPP, RTE_FLOW_ERROR_TYPE_ACTION,
+ NULL, "NAT64 action is not supported.");
+}
+
 static int
 mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
  const struct rte_flow_actions_template_attr *attr,
@@ -6066,6 +6110,13 @@ mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
MLX5_HW_VLAN_PUSH_VID_IDX;
action_flags |= MLX5_FLOW_ACTION_OF_PUSH_VLAN;
break;
+   case RTE_FLOW_ACTION_TYPE_NAT64:
+   ret = flow_hw_validate_action_nat64(dev, attr, action, 
mask,
+   action_flags, 
error);
+   if (ret != 0)
+   return ret;
+   action_flags |= MLX5_FLOW_ACTION_NAT64;
+   break;
case RTE_FLOW_ACTION_TYPE_END:
actions_end = true;
break;
-- 
2.39.3

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[David Marchand]

On Wed, Feb 28, 2024 at 4:01 PM Morten Brørup  
wrote:
>
> > From: David Marchand [mailto:david.march...@redhat.com]
> > Sent: Wednesday, 28 February 2024 15.19
> >
> > On Tue, Feb 27, 2024 at 6:44 AM Tyler Retzlaff
> >  wrote:
> > >
> > > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > > RTE_MARKER fields from rte_mbuf struct.
> > >
> > > Maintain alignment of fields after removed cacheline1 marker by placing
> > > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> > >
> > > Update implementation of rte_mbuf_prefetch_part1() and
> > > rte_mbuf_prefetch_part2() inline functions calculate pointer for
> > > prefetch of cachline0 and cachline1 without using removed markers.
> > >
> > > Update static_assert of rte_mbuf struct fields to reference data_off and
> > > packet_type fields that occupy the original offsets of the marker
> > > fields.
> > >
> > > Signed-off-by: Tyler Retzlaff 
> > > ---
> > >  doc/guides/rel_notes/release_24_03.rst |  9 
> > >  lib/mbuf/rte_mbuf.h|  4 ++--
> > >  lib/mbuf/rte_mbuf_core.h   | 39 
> > > +--
> > ---
> > >  3 files changed, 26 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/doc/guides/rel_notes/release_24_03.rst
> > b/doc/guides/rel_notes/release_24_03.rst
> > > index 879bb49..67750f2 100644
> > > --- a/doc/guides/rel_notes/release_24_03.rst
> > > +++ b/doc/guides/rel_notes/release_24_03.rst
> > > @@ -156,6 +156,15 @@ Removed Items
> > >The application reserved statically defined logtypes
> > ``RTE_LOGTYPE_USER1..RTE_LOGTYPE_USER8``
> > >are still defined.
> > >
> > > +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` ``cacheline1``
> > > +  ``rx_descriptor_fields1`` and ``RTE_MARKER64`` field ``rearm_data``
> > > +  have been removed from ``struct rte_mbuf``.
> > > +  Prefetch of ``cacheline0`` and ``cacheline1`` may be achieved through
> > > +  ``rte_mbuf_prefetch_part1()`` and ``rte_mbuf_prefetch_part2()`` inline
> > > +  functions respectively.
> > > +  Access to ``rearm_data`` and ``rx_descriptor_fields1`` should be
> > > +  through new inline functions ``rte_mbuf_rearm_data()`` and
> > > +  ``rte_mbuf_rx_descriptor_fields1()`` respectively.
> > >
> > >  API Changes
> > >  ---
> > > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > > index aa7495b..61cda20 100644
> > > --- a/lib/mbuf/rte_mbuf.h
> > > +++ b/lib/mbuf/rte_mbuf.h
> > > @@ -108,7 +108,7 @@
> > >  static inline void
> > >  rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> > >  {
> > > -   rte_prefetch0(&m->cacheline0);
> > > +   rte_prefetch0(m);
> > >  }
> > >
> > >  /**
> > > @@ -126,7 +126,7 @@
> > >  rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> > >  {
> > >  #if RTE_CACHE_LINE_SIZE == 64
> > > -   rte_prefetch0(&m->cacheline1);
> > > +   rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> > >  #else
> > > RTE_SET_USED(m);
> > >  #endif
> > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > > index 36551c2..4e06f15 100644
> > > --- a/lib/mbuf/rte_mbuf_core.h
> > > +++ b/lib/mbuf/rte_mbuf_core.h
> > > @@ -18,6 +18,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > >  #include 
> > > @@ -467,8 +468,6 @@ enum {
> > >   * The generic rte_mbuf, containing a packet mbuf.
> > >   */
> > >  struct rte_mbuf {
> > > -   RTE_MARKER cacheline0;
> > > -
> > > void *buf_addr;   /**< Virtual address of segment buffer. 
> > > */
> > >  #if RTE_IOVA_IN_MBUF
> > > /**
> > > @@ -495,7 +494,6 @@ struct rte_mbuf {
> > >  * To obtain a pointer to rearm_data use the rte_mbuf_rearm_data()
> > >  * accessor instead of directly referencing through the data_off
> > field.
> > >  */
> > > -   RTE_MARKER64 rearm_data;
> > > uint16_t data_off;
> >
> > One subtile change of removing the marker is that fields may not be
> > aligned as before.
> >
> > #if RTE_IOVA_IN_MBUF
> > /**
> >  * Physical address of segment buffer.
> >  * This field is undefined if the build is configured to use only
> >  * virtual address as IOVA (i.e. RTE_IOVA_IN_MBUF is 0).
> >  * Force alignment to 8-bytes, so as to ensure we have the exact
> >  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
> >  * working on vector drivers easier.
> >  */
> > rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> > #else
> > /**
> >  * Next segment of scattered packet.
> >  * This field is valid when physical address field is undefined.
> >  * Otherwise next pointer in the second cache line will be used.
> >  */
> > struct rte_mbuf *next;
> > #endif
> >
> > When building ! RTE_IOVA_IN_MBUF on a 32 bits arch, the next pointer
> > is not force aligned to 64bits.
> > Which has a cascade effect on data_off alignement.
> >
> > In file included from ../lib/mbuf/rte_mbuf_core.h:19,
> >   

RE: [PATCH v3 0/4] net/mlx5: add support for flow table resizing

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Gregory Etelson 
> Sent: Wednesday, February 28, 2024 3:33 PM
> To: dev@dpdk.org
> Cc: Gregory Etelson ; Maayan Kashani
> ; Raslan Darawsheh ; Dariusz
> Sosnowski 
> Subject: [PATCH v3 0/4] net/mlx5: add support for flow table resizing
> 
> Support template table resize API.
> 
> Gregory Etelson (3):
>   net/mlx5: fix parameters verification in HWS table create
>   net/mlx5: move multi-pattern actions management to table level
>   net/mlx5: add support for flow table resizing
> 
> Maayan Kashani (1):
>   net/mlx5: add resize function to ipool
> 
>  drivers/net/mlx5/mlx5.h |   5 +
>  drivers/net/mlx5/mlx5_flow.c|  51 +++
>  drivers/net/mlx5/mlx5_flow.h| 101 -
>  drivers/net/mlx5/mlx5_flow_hw.c | 761 +++---
> --
>  drivers/net/mlx5/mlx5_utils.c   |  29 ++
>  drivers/net/mlx5/mlx5_utils.h   |  16 +
>  6 files changed, 763 insertions(+), 200 deletions(-)
> 
> Acked-by: Dariusz Sosnowski 
> 
> --
> v2: Update PMD after DPDK API changes.
> v3: Use RTE atomic API.
> --
> 2.39.2
Series applied to next-net-mlx,

Raslan Darawsheh

[DPDK/DTS Bug 1388] Add dependency documentation for TG Node

[bugzilla]

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

Bug ID: 1388
   Summary: Add dependency documentation for TG Node
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: DTS
  Assignee: dev@dpdk.org
  Reporter: pr...@iol.unh.edu
CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu
  Target Milestone: ---

There is a python 3.10+ dependency on the TG node due to the XMLRPC
implementation and associated Marshall Module. 

The XMLRPC implementation may be replaced in the future, at which point this
becomes a moot point.

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

Re: [PATCH v6 01/23] mbuf: add accessors for rearm and Rx descriptor fields

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 09:28:22AM +0100, Morten Brørup wrote:
> +To: Thomas, previously joined the discussion
> 
> > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > Sent: Tuesday, 27 February 2024 18.17
> > 
> > On Tue, Feb 27, 2024 at 10:10:03AM +0100, Morten Brørup wrote:
> > > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > > > Sent: Tuesday, 27 February 2024 06.41
> > > >
> > > > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Provide
> > > > inline functions to access compatible type pointer to rearm_data
> > > > and rx_descriptor_fields1 which will allow direct references on the
> > > > rte marker fields to be removed.
> > > >
> > > > Signed-off-by: Tyler Retzlaff 
> > > > ---
> > > >  lib/mbuf/rte_mbuf.h  | 13 +
> > > >  lib/mbuf/rte_mbuf_core.h | 11 ++-
> > > >  2 files changed, 23 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > > > index 286b32b..aa7495b 100644
> > > > --- a/lib/mbuf/rte_mbuf.h
> > > > +++ b/lib/mbuf/rte_mbuf.h
> > > > @@ -132,6 +132,19 @@
> > > >  #endif
> > > >  }
> > > >
> > > > +static inline
> > > > +uint64_t *
> > > > +rte_mbuf_rearm_data(struct rte_mbuf *m)
> > > > +{
> > > > +   return (uint64_t *)&m->data_off;
> > > > +}
> > >
> > > Consider returning (void *) instead of (uint64_t *).
> > > Just a suggestion; I don't know which is better.
> > 
> > if you mean just the cast i don't think it matters.
> 
> No, I meant the return type.
> The type is opaque; only its size is fixed at 8 byte.
> Maybe uint64_t * is the best type, after all.

ah, in many places the drivers want the uint64_t * keeping it here allows
for some of the casts (and potential for mistakes) to be discarded. if i
recall in some places they do math on the returned pointer.

> 
> > arguably it could go
> > void * first but we're already aliasing through a different type. this
> > is one argument in favor of the union.
> 
> The zero-size markers (rearm_data and rx_descriptor_fields1) were intended to 
> be used like unions, which the drivers effectively do.
> Previous C standards didn't allow anonymous structures, so using union+struct 
> in pre-C11 DPDK would clutter the code with subfield names. But now that we 
> moved on to C11, we don't have this problem anymore.
> 
> IMHO, replacing the zero-size markers - which are directly visible in the 
> structure's source code - with access functions located in some other header 
> file degrades source code readability.
> 
> I am in favor of union+struct in the mbuf structure over access functions. I 
> think the explicit grouping of the fields improves the readability of the 
> mbuf structure, also compared to the zero-size markers.

it's unfortunate the zero-size markers could be accessed slightly
differently than the anonymous unions necessitating code referencing
them to be changed.

Thomas and i discussed rearm_data and rx_descriptor_fields1 at length
and it was understood why i had to add new field names if using the union
approach there was an expressed preference for accessors.

one possibly important detail that came out of our conversation was that
rearm_data rx_descriptor_fields1 are (I think) supposed to be internal
and that being the case means updading the dpdk drivers means i updated
*all* consumers i.e. i can break the api and adapt in the same commit if
they are truly internal because no application should be accessing the
fields.

one approach i've enjoyed some success with is to present semi-opaque
structures where the internal fields are by convention discouraged in
their use but doing this requires duplicating parts of the whole to e.g.
give the drivers the view of the struct they need and is an increased
burden for maintainers. again this relies on the fields actually being
internal only.

both approaches have been put up in this series now, just looking for
folks to look at the two and push for one or the other.

thanks!

[DPDK/DTS Bug 1389] Investigate automatically building config schema documentation

[bugzilla]

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

Bug ID: 1389
   Summary: Investigate automatically building config schema
documentation
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: minor
  Priority: Normal
 Component: DTS
  Assignee: dev@dpdk.org
  Reporter: pr...@iol.unh.edu
CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu
  Target Milestone: ---

Investigate if we can use a tool to automatically build config YAML
documentation based on the schema. Right now the documentation is manually
updated.

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

Re: [PATCH] ethdev: fix coverity issue

[Ferruh Yigit]

On 2/27/2024 7:38 PM, Harman Kalra wrote:
> Fixing uninitialized value access.
> 
> Coverity issue: 414934
> Fixes: 9a9eb104edf6 ("ethdev: parse multiple representor devargs")
> 
> Signed-off-by: Harman Kalra 
> 

Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.

Re: [PATCH 1/3] net/nfp: add the elf module

[Ferruh Yigit]

On 2/27/2024 11:15 AM, Chaoyong He wrote:
> From: Peng Zhang 
> 
> Add the elf module, which can get mip information from the
> firmware ELF file.
>

What is MIP?
Is it in the .note section of the ELF binary?
How it is used?

Source code always refers it as MIP, can you please clarify it in the
commit log?

Re: [PATCH 3/3] net/nfp: add force reload firmware option

[Ferruh Yigit]

On 2/27/2024 11:15 AM, Chaoyong He wrote:
> From: Peng Zhang 
> 
> Add an option to force reload the firmware.
> 
> This option can be ignored in some case, for example:
> When using a 2 port NFP card and both with this reload firmware option,
> only the first one will cause the firmware reload and the second one
> will be ignored.
> 
> Signed-off-by: Peng Zhang 
> Reviewed-by: Chaoyong He 
> ---
>  drivers/net/nfp/nfp_ethdev.c | 104 +++
>  drivers/net/nfp/nfp_net_common.h |   8 +++
>  2 files changed, 100 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
> index 902a62a86b..8c38b4e134 100644
> --- a/drivers/net/nfp/nfp_ethdev.c
> +++ b/drivers/net/nfp/nfp_ethdev.c
> @@ -9,6 +9,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "flower/nfp_flower.h"
>  #include "nfd3/nfp_nfd3.h"
> @@ -31,6 +32,71 @@
>  #define NFP_NET_APP_CAP_SP_INDIFF   RTE_BIT64(0) /* Indifferent to port 
> speed */
>  
>  #define NFP_PF_DRIVER_NAME net_nfp_pf
> +#define NFP_PF_FORCE_RELOAD_FW   "force_reload_fw"
> +
>

Can you please document the new devarg in the driver documentation,
'doc/guides/nics/nfp.rst'?

Also you may want to document FW upgrade process, as it checks FW
version by default and this can be overridden by devarg etc..

[PATCH 00/11] net/mlx5: flow insertion performance improvements

[Dariusz Sosnowski]

Goal of this patchset is to improve the throughput of flow insertion
and deletion in mlx5 PMD when HW Steering flow engine is used.

- Patch 1 - Use preallocated per-queue, per-actions template buffer
  for storing translated flow actions, instead of allocating and
  filling it on demand, on each flow operation.
- Patches 2-4 - Make resource index allocation optional. This allocation
  will be skipped when it is not required by the created template table.
- Patches 5-7 - Reduce memory footprint of the internal flow queue.
- Patch 8 - Remove indirection between flow job and flow itself,
  by using flow as an operation container.
- Patches 9-10 - Reduce memory footpring of flow struct by moving
  rarely used flow fields outside of the main flow struct.
  These fields will accesses only when needed.
  Also remove unneeded `zmalloc` usage.
- Patch 11 - Remove unneeded device status check in flow create.

In general all of these changes result in the following improvements
(all numbers are averaged Kflows/sec):

|  | Insertion) |   +%   | Deletion |   +%  |
|--|:--:|:--:|::|:-:|
| baseline |   6338.7   ||  9739.6  |   |
| improvements |   6978.8   | +10.1% |  10432.4 | +7.1% |

The basic benchmark was run on ConnectX-6 Dx (22.40.1000),
on the system with Intel Xeon Platinum 8380 CPU.

Bing Zhao (2):
  net/mlx5: skip the unneeded resource index allocation
  net/mlx5: remove unneeded device status checking

Dariusz Sosnowski (7):
  net/mlx5: allocate local DR rule action buffers
  net/mlx5: remove action params from job
  net/mlx5: remove flow pattern from job
  net/mlx5: remove updated flow from job
  net/mlx5: use flow as operation container
  net/mlx5: move rarely used flow fields outside
  net/mlx5: reuse flow fields

Erez Shitrit (2):
  net/mlx5/hws: add check for matcher rule update support
  net/mlx5/hws: add check if matcher contains complex rules

 drivers/net/mlx5/hws/mlx5dr.h |  16 +
 drivers/net/mlx5/hws/mlx5dr_action.c  |   6 +
 drivers/net/mlx5/hws/mlx5dr_action.h  |   2 +
 drivers/net/mlx5/hws/mlx5dr_matcher.c |  29 +
 drivers/net/mlx5/mlx5.h   |  29 +-
 drivers/net/mlx5/mlx5_flow.h  | 128 -
 drivers/net/mlx5/mlx5_flow_hw.c   | 794 --
 7 files changed, 666 insertions(+), 338 deletions(-)

--
2.39.2

[PATCH 01/11] net/mlx5: allocate local DR rule action buffers

[Dariusz Sosnowski]

Goal of this is to remove the unnecessary copying of precalculated
mlx5dr_rule_action structures used to create HWS flow rules.

Before this patch, during template table creation an array of these
structures was calculated for each actions template used.
Each of these structures contained either full action definition or
partial (depends on mask configuration).
During flow creation, this array was copied to stack and later passed to
mlx5dr_rule_create().

This patch removes this copy by implementing the following:

- Allocate an array of mlx5dr_rule_action structures for each actions
  template and queue.
- Populate them with precalculated data from relevant actions templates.
- During flow creation, construction of unmasked actions works on an
  array dedicated for the specific queue and actions template.
- Pass this buffer to mlx5dr_rule_create directly.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h| 13 +
 drivers/net/mlx5/mlx5_flow_hw.c | 51 +
 2 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 1530e6962f..11135645ef 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1554,6 +1554,10 @@ struct mlx5_matcher_info {
uint32_t refcnt;
 };
 
+struct mlx5_dr_rule_action_container {
+   struct mlx5dr_rule_action acts[MLX5_HW_MAX_ACTS];
+} __rte_cache_aligned;
+
 struct rte_flow_template_table {
LIST_ENTRY(rte_flow_template_table) next;
struct mlx5_flow_group *grp; /* The group rte_flow_template_table uses. 
*/
@@ -1573,6 +1577,15 @@ struct rte_flow_template_table {
uint32_t refcnt; /* Table reference counter. */
struct mlx5_tbl_multi_pattern_ctx mpctx;
struct mlx5dr_matcher_attr matcher_attr;
+   /**
+* Variable length array of containers containing precalculated 
templates of DR actions
+* arrays. This array is allocated at template table creation time and 
contains
+* one container per each queue, per each actions template.
+* Essentially rule_acts is a 2-dimensional array indexed with (AT 
index, queue) pair.
+* Each container will provide a local "queue buffer" to work on for 
flow creation
+* operations when using a given actions template.
+*/
+   struct mlx5_dr_rule_action_container rule_acts[];
 };
 
 static __rte_always_inline struct mlx5dr_matcher *
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index f778fd0698..442237f2b6 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -2499,6 +2499,34 @@ __flow_hw_actions_translate(struct rte_eth_dev *dev,
  "fail to create rte table");
 }
 
+static __rte_always_inline struct mlx5dr_rule_action *
+flow_hw_get_dr_action_buffer(struct mlx5_priv *priv,
+struct rte_flow_template_table *table,
+uint8_t action_template_index,
+uint32_t queue)
+{
+   uint32_t offset = action_template_index * priv->nb_queue + queue;
+
+   return &table->rule_acts[offset].acts[0];
+}
+
+static void
+flow_hw_populate_rule_acts_caches(struct rte_eth_dev *dev,
+ struct rte_flow_template_table *table,
+ uint8_t at_idx)
+{
+   struct mlx5_priv *priv = dev->data->dev_private;
+   uint32_t q;
+
+   for (q = 0; q < priv->nb_queue; ++q) {
+   struct mlx5dr_rule_action *rule_acts =
+   flow_hw_get_dr_action_buffer(priv, table, 
at_idx, q);
+
+   rte_memcpy(rule_acts, table->ats[at_idx].acts.rule_acts,
+  sizeof(table->ats[at_idx].acts.rule_acts));
+   }
+}
+
 /**
  * Translate rte_flow actions to DR action.
  *
@@ -2526,6 +2554,7 @@ flow_hw_actions_translate(struct rte_eth_dev *dev,
tbl->ats[i].action_template,
&tbl->mpctx, error))
goto err;
+   flow_hw_populate_rule_acts_caches(dev, tbl, i);
}
ret = mlx5_tbl_multi_pattern_process(dev, tbl, &tbl->mpctx.segments[0],
 
rte_log2_u32(tbl->cfg.attr.nb_flows),
@@ -2914,7 +2943,6 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
struct mlx5_aso_mtr *aso_mtr;
struct mlx5_multi_pattern_segment *mp_segment = NULL;
 
-   rte_memcpy(rule_acts, hw_acts->rule_acts, sizeof(*rule_acts) * 
at->dr_actions_num);
attr.group = table->grp->group_id;
ft_flag = mlx5_hw_act_flag[!!table->grp->group_id][table->type];
if (table->type == MLX5DR_TABLE_TYPE_FDB) {
@@ -3316,7 +3344,7 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
.user_data = user_data,
.burst = attr->postpone,
 

[PATCH 03/11] net/mlx5/hws: add check if matcher contains complex rules

[Dariusz Sosnowski]

From: Erez Shitrit 

The function returns true if that matcher can contain complicated rule,
which means rule that needs more than one writing to the HW in order to
have it.

Signed-off-by: Erez Shitrit 
---
 drivers/net/mlx5/hws/mlx5dr.h |  8 
 drivers/net/mlx5/hws/mlx5dr_action.c  |  6 ++
 drivers/net/mlx5/hws/mlx5dr_action.h  |  2 ++
 drivers/net/mlx5/hws/mlx5dr_matcher.c | 17 +
 4 files changed, 33 insertions(+)

diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index 781b11e681..d903decc1b 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -499,6 +499,14 @@ int mlx5dr_matcher_resize_rule_move(struct mlx5dr_matcher 
*src_matcher,
  */
 bool mlx5dr_matcher_is_updatable(struct mlx5dr_matcher *matcher);
 
+/* Check matcher if might contain rules that need complex structure
+ *
+ * @param[in] matcher
+ * that the rule belongs to.
+ * @return true when the matcher is contains such rules, false otherwise.
+ */
+bool mlx5dr_matcher_is_dependent(struct mlx5dr_matcher *matcher);
+
 /* Get the size of the rule handle (mlx5dr_rule) to be used on rule creation.
  *
  * @return size in bytes of rule handle struct.
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.c 
b/drivers/net/mlx5/hws/mlx5dr_action.c
index 631763dee0..494642d25c 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.c
+++ b/drivers/net/mlx5/hws/mlx5dr_action.c
@@ -3265,6 +3265,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->flags |= ASF_SINGLE1 | ASF_REMOVE;
setter->set_single = 
&mlx5dr_action_setter_ipv6_route_ext_pop;
setter->idx_single = i;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_PUSH_IPV6_ROUTE_EXT:
@@ -3291,6 +3292,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->set_double = 
&mlx5dr_action_setter_ipv6_route_ext_mhdr;
setter->idx_double = i;
setter->extra_data = 2;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_MODIFY_HDR:
@@ -3299,6 +3301,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->flags |= ASF_DOUBLE | ASF_MODIFY;
setter->set_double = 
&mlx5dr_action_setter_modify_header;
setter->idx_double = i;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_ASO_METER:
@@ -3326,6 +3329,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->flags |= ASF_DOUBLE | ASF_INSERT;
setter->set_double = &mlx5dr_action_setter_insert_ptr;
setter->idx_double = i;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_REFORMAT_L2_TO_TNL_L3:
@@ -3336,6 +3340,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->idx_double = i;
setter->set_single = &mlx5dr_action_setter_common_decap;
setter->idx_single = i;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_REFORMAT_TNL_L3_TO_L2:
@@ -3344,6 +3349,7 @@ int mlx5dr_action_template_process(struct 
mlx5dr_action_template *at)
setter->flags |= ASF_DOUBLE | ASF_MODIFY | ASF_INSERT;
setter->set_double = &mlx5dr_action_setter_tnl_l3_to_l2;
setter->idx_double = i;
+   at->need_dep_write = true;
break;
 
case MLX5DR_ACTION_TYP_TAG:
diff --git a/drivers/net/mlx5/hws/mlx5dr_action.h 
b/drivers/net/mlx5/hws/mlx5dr_action.h
index 0c8e4bbb5a..68139ca092 100644
--- a/drivers/net/mlx5/hws/mlx5dr_action.h
+++ b/drivers/net/mlx5/hws/mlx5dr_action.h
@@ -119,6 +119,8 @@ struct mlx5dr_action_template {
uint8_t num_of_action_stes;
uint8_t num_actions;
uint8_t only_term;
+   /* indicates rule might require dependent wqe */
+   bool need_dep_write;
uint32_t flags;
 };
 
diff --git a/drivers/net/mlx5/hws/mlx5dr_matcher.c 
b/drivers/net/mlx5/hws/mlx5dr_matcher.c
index 4e4da8e8f6..1c64abfa57 100644
--- a/drivers/net/mlx5/hws/mlx5dr_matcher.c
+++ b/drivers/net/mlx5/hws/mlx5dr_matcher.c
@@ -1542,6 +1542,23 @@ bool mlx5dr_matcher_is_updatable(struct mlx5dr_matcher 
*matcher)
return true;
 }
 
+bool mlx5dr_matcher_is_dependent(struct mlx5dr_matcher *matcher)
+{
+   int i;
+
+   if (matcher->action_ste.max_stes || mlx5dr_matcher_req_fw_wqe(matcher))
+   return true;
+
+   for (i

[PATCH 02/11] net/mlx5/hws: add check for matcher rule update support

[Dariusz Sosnowski]

From: Erez Shitrit 

The user want to know before trying to update a rule if that matcher that
keeps the original rule supports updating.

Signed-off-by: Erez Shitrit 
---
 drivers/net/mlx5/hws/mlx5dr.h |  8 
 drivers/net/mlx5/hws/mlx5dr_matcher.c | 12 
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/mlx5/hws/mlx5dr.h b/drivers/net/mlx5/hws/mlx5dr.h
index d612f300c6..781b11e681 100644
--- a/drivers/net/mlx5/hws/mlx5dr.h
+++ b/drivers/net/mlx5/hws/mlx5dr.h
@@ -491,6 +491,14 @@ int mlx5dr_matcher_resize_rule_move(struct mlx5dr_matcher 
*src_matcher,
struct mlx5dr_rule *rule,
struct mlx5dr_rule_attr *attr);
 
+/* Check matcher ability to update existing rules
+ *
+ * @param[in] matcher
+ * that the rule belongs to.
+ * @return true when the matcher is updatable false otherwise.
+ */
+bool mlx5dr_matcher_is_updatable(struct mlx5dr_matcher *matcher);
+
 /* Get the size of the rule handle (mlx5dr_rule) to be used on rule creation.
  *
  * @return size in bytes of rule handle struct.
diff --git a/drivers/net/mlx5/hws/mlx5dr_matcher.c 
b/drivers/net/mlx5/hws/mlx5dr_matcher.c
index 8a74a1ed7d..4e4da8e8f6 100644
--- a/drivers/net/mlx5/hws/mlx5dr_matcher.c
+++ b/drivers/net/mlx5/hws/mlx5dr_matcher.c
@@ -1530,6 +1530,18 @@ int mlx5dr_match_template_destroy(struct 
mlx5dr_match_template *mt)
return 0;
 }
 
+bool mlx5dr_matcher_is_updatable(struct mlx5dr_matcher *matcher)
+{
+   if (mlx5dr_table_is_root(matcher->tbl) ||
+   mlx5dr_matcher_req_fw_wqe(matcher) ||
+   mlx5dr_matcher_is_resizable(matcher) ||
+   (!matcher->attr.optimize_using_rule_idx &&
+   !mlx5dr_matcher_is_insert_by_idx(matcher)))
+   return false;
+
+   return true;
+}
+
 static int mlx5dr_matcher_resize_precheck(struct mlx5dr_matcher *src_matcher,
  struct mlx5dr_matcher *dst_matcher)
 {
-- 
2.39.2

[PATCH 06/11] net/mlx5: remove flow pattern from job

[Dariusz Sosnowski]

mlx5_hw_q_job struct held a reference to temporary flow rule pattern
and contained temporary REPRESENTED_PORT and TAG items structs.
They are used whenever it is required to prepend a flow rule pattern,
provided by the application with one of such items.
If prepending is required, then flow rule pattern is copied over to
temporary buffer and a new item added internally in PMD.
Such constructed buffer is passed to the HWS layer when flow create
operation is being enqueued.
After operation is enqueued, temporary flow pattern can be safely
discarded, so there is no need to store it during
the whole lifecycle of mlx5_hw_q_job.

This patch removes all references to flow rule pattern and items stored
inside mlx5_hw_q_job and removes relevant allocations to reduce job
memory footprint.
Temporary pattern and items stored per job are replaced with stack
allocated ones, contained in mlx5_flow_hw_pattern_params struct.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h | 17 ---
 drivers/net/mlx5/mlx5_flow.h| 10 +++
 drivers/net/mlx5/mlx5_flow_hw.c | 51 ++---
 3 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index bd0846d6bf..fc3d28e6f2 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -401,17 +401,12 @@ struct mlx5_hw_q_job {
const void *action; /* Indirect action attached to the job. */
};
void *user_data; /* Job user data. */
-   struct rte_flow_item *items;
-   union {
-   struct {
-   /* User memory for query output */
-   void *user;
-   /* Data extracted from hardware */
-   void *hw;
-   } __rte_packed query;
-   struct rte_flow_item_ethdev port_spec;
-   struct rte_flow_item_tag tag_spec;
-   } __rte_packed;
+   struct {
+   /* User memory for query output */
+   void *user;
+   /* Data extracted from hardware */
+   void *hw;
+   } query;
struct rte_flow_hw *upd_flow; /* Flow with updated values. */
 };
 
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index df1c913017..96b43ce61e 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1304,6 +1304,16 @@ struct mlx5_flow_hw_action_params {
uint8_t ipv6_push_data[MLX5_PUSH_MAX_LEN];
 };
 
+/** Container for dynamically generated flow items used during flow rule 
creation. */
+struct mlx5_flow_hw_pattern_params {
+   /** Array of dynamically generated flow items. */
+   struct rte_flow_item items[MLX5_HW_MAX_ITEMS];
+   /** Temporary REPRESENTED_PORT item generated by PMD. */
+   struct rte_flow_item_ethdev port_spec;
+   /** Temporary TAG item generated by PMD. */
+   struct rte_flow_item_tag tag_spec;
+};
+
 /* rte flow action translate to DR action struct. */
 struct mlx5_action_construct_data {
LIST_ENTRY(mlx5_action_construct_data) next;
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 7160477c83..c3d9eef999 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -3253,44 +3253,44 @@ flow_hw_get_rule_items(struct rte_eth_dev *dev,
   const struct rte_flow_template_table *table,
   const struct rte_flow_item items[],
   uint8_t pattern_template_index,
-  struct mlx5_hw_q_job *job)
+  struct mlx5_flow_hw_pattern_params *pp)
 {
struct rte_flow_pattern_template *pt = 
table->its[pattern_template_index];
 
/* Only one implicit item can be added to flow rule pattern. */
MLX5_ASSERT(!pt->implicit_port || !pt->implicit_tag);
-   /* At least one item was allocated in job descriptor for items. */
+   /* At least one item was allocated in pattern params for items. */
MLX5_ASSERT(MLX5_HW_MAX_ITEMS >= 1);
if (pt->implicit_port) {
if (pt->orig_item_nb + 1 > MLX5_HW_MAX_ITEMS) {
rte_errno = ENOMEM;
return NULL;
}
-   /* Set up represented port item in job descriptor. */
-   job->port_spec = (struct rte_flow_item_ethdev){
+   /* Set up represented port item in pattern params. */
+   pp->port_spec = (struct rte_flow_item_ethdev){
.port_id = dev->data->port_id,
};
-   job->items[0] = (struct rte_flow_item){
+   pp->items[0] = (struct rte_flow_item){
.type = RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT,
-   .spec = &job->port_spec,
+   .spec = &pp->port_spec,
};
-   rte_memcpy(&job->items[1], items, sizeof(*items) * 
pt->orig_

[PATCH 04/11] net/mlx5: skip the unneeded resource index allocation

[Dariusz Sosnowski]

From: Bing Zhao 

The resource index was introduced to decouple the flow rule and its
resources used by hardware steering. This is needed only when a rule
update is supported.

In some cases, the update is not supported on a table(matcher). E.g.:
  * Table is resizable
  * FW gets involved
  * Root table
  * Not index based or optimized (not applicable)

Or only one STE entry is required per rule. When doing an update, the
operation is always atomic. There is no need for the extra resource
index either.

If the matcher doesn't support rule update or the maximal entry is
only 1 for this matcher, there is no need to manage the resource
index allocation and free from the pool.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 129 +++-
 1 file changed, 76 insertions(+), 53 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 442237f2b6..fcf493c771 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -3364,9 +3364,6 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
flow = mlx5_ipool_zmalloc(table->flow, &flow_idx);
if (!flow)
goto error;
-   mlx5_ipool_malloc(table->resource, &res_idx);
-   if (!res_idx)
-   goto error;
rule_acts = flow_hw_get_dr_action_buffer(priv, table, 
action_template_index, queue);
/*
 * Set the table here in order to know the destination table
@@ -3375,7 +3372,14 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
flow->table = table;
flow->mt_idx = pattern_template_index;
flow->idx = flow_idx;
-   flow->res_idx = res_idx;
+   if (table->resource) {
+   mlx5_ipool_malloc(table->resource, &res_idx);
+   if (!res_idx)
+   goto error;
+   flow->res_idx = res_idx;
+   } else {
+   flow->res_idx = flow_idx;
+   }
/*
 * Set the job type here in order to know if the flow memory
 * should be freed or not when get the result from dequeue.
@@ -3385,11 +3389,10 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
job->user_data = user_data;
rule_attr.user_data = job;
/*
-* Indexed pool returns 1-based indices, but mlx5dr expects 0-based 
indices for rule
-* insertion hints.
+* Indexed pool returns 1-based indices, but mlx5dr expects 0-based 
indices
+* for rule insertion hints.
 */
-   MLX5_ASSERT(res_idx > 0);
-   flow->rule_idx = res_idx - 1;
+   flow->rule_idx = flow->res_idx - 1;
rule_attr.rule_idx = flow->rule_idx;
/*
 * Construct the flow actions based on the input actions.
@@ -3432,12 +3435,12 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
if (likely(!ret))
return (struct rte_flow *)flow;
 error:
-   if (job)
-   flow_hw_job_put(priv, job, queue);
+   if (table->resource && res_idx)
+   mlx5_ipool_free(table->resource, res_idx);
if (flow_idx)
mlx5_ipool_free(table->flow, flow_idx);
-   if (res_idx)
-   mlx5_ipool_free(table->resource, res_idx);
+   if (job)
+   flow_hw_job_put(priv, job, queue);
rte_flow_error_set(error, rte_errno,
   RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
   "fail to create rte flow");
@@ -3508,9 +3511,6 @@ flow_hw_async_flow_create_by_index(struct rte_eth_dev 
*dev,
flow = mlx5_ipool_zmalloc(table->flow, &flow_idx);
if (!flow)
goto error;
-   mlx5_ipool_malloc(table->resource, &res_idx);
-   if (!res_idx)
-   goto error;
rule_acts = flow_hw_get_dr_action_buffer(priv, table, 
action_template_index, queue);
/*
 * Set the table here in order to know the destination table
@@ -3519,7 +3519,14 @@ flow_hw_async_flow_create_by_index(struct rte_eth_dev 
*dev,
flow->table = table;
flow->mt_idx = 0;
flow->idx = flow_idx;
-   flow->res_idx = res_idx;
+   if (table->resource) {
+   mlx5_ipool_malloc(table->resource, &res_idx);
+   if (!res_idx)
+   goto error;
+   flow->res_idx = res_idx;
+   } else {
+   flow->res_idx = flow_idx;
+   }
/*
 * Set the job type here in order to know if the flow memory
 * should be freed or not when get the result from dequeue.
@@ -3528,9 +3535,7 @@ flow_hw_async_flow_create_by_index(struct rte_eth_dev 
*dev,
job->flow = flow;
job->user_data = user_data;
rule_attr.user_data = job;
-   /*
-* Set the rule index.
-*/
+   /* Set the rule index. */
flow->rule_idx = rule_index;
rule_attr.rule_idx = flow->rule_idx;
/*
@@ -3566,12 +3571,12 @@ flow_hw_async_flow_create_by_index(struct rte

[PATCH 07/11] net/mlx5: remove updated flow from job

[Dariusz Sosnowski]

mlx5_hw_q_job struct held a reference to a temporary flow rule struct,
used during flow rule update operation. It serves as a container for
flow actions data calculated during actions construction.
After flow rule update operation succeeds, data from temporary flow rule
is copied over to original flow rule.

Although access to this temporary flow rule struct is required
during both operation enqueue step and completion polling step,
there can be only one ongoing flow update operation for a given
flow rule. As a result there is no need to store it per job.

This patch removes all references to temporary flow rule struct
stored in mlx5_hw_q_job and removes relevant allocations to reduce
job memory footprint.
Temporary flow rule struct stored per job is replaced with:

- If table is not resizable - An array of rte_flow_hw_aux structs,
  stored in template table. This array holds one entry per each
  flow rule, each containing a single mentioned temporary struct.
- If table is resizable - Additional rte_flow_hw_aux struct,
  allocated alongside rte_flow_hw in resizable ipool.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h |   1 -
 drivers/net/mlx5/mlx5_flow.h|   7 +++
 drivers/net/mlx5/mlx5_flow_hw.c | 100 ++--
 3 files changed, 89 insertions(+), 19 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index fc3d28e6f2..0cc32bf67b 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -407,7 +407,6 @@ struct mlx5_hw_q_job {
/* Data extracted from hardware */
void *hw;
} query;
-   struct rte_flow_hw *upd_flow; /* Flow with updated values. */
 };
 
 /* HW steering job descriptor LIFO pool. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 96b43ce61e..8fd07bdce4 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1281,6 +1281,12 @@ struct rte_flow_hw {
uint8_t rule[]; /* HWS layer data struct. */
 } __rte_packed;
 
+/** Auxiliary data stored per flow which is not required to be stored in main 
flow structure. */
+struct rte_flow_hw_aux {
+   /** Placeholder flow struct used during flow rule update operation. */
+   struct rte_flow_hw upd_flow;
+};
+
 #ifdef PEDANTIC
 #pragma GCC diagnostic error "-Wpedantic"
 #endif
@@ -1589,6 +1595,7 @@ struct rte_flow_template_table {
/* Action templates bind to the table. */
struct mlx5_hw_action_template ats[MLX5_HW_TBL_MAX_ACTION_TEMPLATE];
struct mlx5_indexed_pool *flow; /* The table's flow ipool. */
+   struct rte_flow_hw_aux *flow_aux; /**< Auxiliary data stored per flow. 
*/
struct mlx5_indexed_pool *resource; /* The table's resource ipool. */
struct mlx5_flow_template_table_cfg cfg;
uint32_t type; /* Flow table type RX/TX/FDB. */
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index c3d9eef999..acc56819eb 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -79,6 +79,66 @@ struct mlx5_indlst_legacy {
 #define MLX5_CONST_ENCAP_ITEM(encap_type, ptr) \
 (((const struct encap_type *)(ptr))->definition)
 
+/**
+ * Returns the size of a struct with a following layout:
+ *
+ * @code{.c}
+ * struct rte_flow_hw {
+ * // rte_flow_hw fields
+ * uint8_t rule[mlx5dr_rule_get_handle_size()];
+ * };
+ * @endcode
+ *
+ * Such struct is used as a basic container for HW Steering flow rule.
+ */
+static size_t
+mlx5_flow_hw_entry_size(void)
+{
+   return sizeof(struct rte_flow_hw) + mlx5dr_rule_get_handle_size();
+}
+
+/**
+ * Returns the size of "auxed" rte_flow_hw structure which is assumed to be 
laid out as follows:
+ *
+ * @code{.c}
+ * struct {
+ * struct rte_flow_hw {
+ * // rte_flow_hw fields
+ * uint8_t rule[mlx5dr_rule_get_handle_size()];
+ * } flow;
+ * struct rte_flow_hw_aux aux;
+ * };
+ * @endcode
+ *
+ * Such struct is used whenever rte_flow_hw_aux cannot be allocated separately 
from the rte_flow_hw
+ * e.g., when table is resizable.
+ */
+static size_t
+mlx5_flow_hw_auxed_entry_size(void)
+{
+   size_t rule_size = mlx5dr_rule_get_handle_size();
+
+   return sizeof(struct rte_flow_hw) + rule_size + sizeof(struct 
rte_flow_hw_aux);
+}
+
+/**
+ * Returns a valid pointer to rte_flow_hw_aux associated with given rte_flow_hw
+ * depending on template table configuration.
+ */
+static __rte_always_inline struct rte_flow_hw_aux *
+mlx5_flow_hw_aux(uint16_t port_id, struct rte_flow_hw *flow)
+{
+   struct rte_flow_template_table *table = flow->table;
+
+   if (rte_flow_template_table_resizable(port_id, &table->cfg.attr)) {
+   size_t offset = sizeof(struct rte_flow_hw) + 
mlx5dr_rule_get_handle_size();
+
+   return RTE_PTR_ADD(flow, offset);
+   } else {
+   return &table->flow_aux[flow->idx - 1];
+   }
+}
+
 static int
 mlx5_tbl_multi_pattern_process(stru

[PATCH 05/11] net/mlx5: remove action params from job

[Dariusz Sosnowski]

mlx5_hw_q_job struct held references to buffers which contained:

- modify header commands array,
- encap/decap data buffer,
- IPv6 routing data buffer.

These buffers were passed as parameters to HWS layer during rule
creation. They were needed only during the call to HWS layer
when flow operation is enqueues (i.e. mlx5dr_rule_create()).
After operation is enqueued, data stored there can be safely discarded
and it is not required to store it during the whole lifecycle of a job.

This patch removes references to these buffers from mlx5_hw_q_job
and removes relevant allocations to reduce job memory footprint.
Buffers stored per job are replaced with stack allocated ones,
contained in mlx5_flow_hw_action_params struct.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h |   3 -
 drivers/net/mlx5/mlx5_flow.h|  10 +++
 drivers/net/mlx5/mlx5_flow_hw.c | 120 ++--
 3 files changed, 63 insertions(+), 70 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index bb1853e797..bd0846d6bf 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -401,9 +401,6 @@ struct mlx5_hw_q_job {
const void *action; /* Indirect action attached to the job. */
};
void *user_data; /* Job user data. */
-   uint8_t *encap_data; /* Encap data. */
-   uint8_t *push_data; /* IPv6 routing push data. */
-   struct mlx5_modification_cmd *mhdr_cmd;
struct rte_flow_item *items;
union {
struct {
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 11135645ef..df1c913017 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1294,6 +1294,16 @@ typedef int
 
 #define MLX5_MHDR_MAX_CMD ((MLX5_MAX_MODIFY_NUM) * 2 + 1)
 
+/** Container for flow action data constructed during flow rule creation. */
+struct mlx5_flow_hw_action_params {
+   /** Array of constructed modify header commands. */
+   struct mlx5_modification_cmd mhdr_cmd[MLX5_MHDR_MAX_CMD];
+   /** Constructed encap/decap data buffer. */
+   uint8_t encap_data[MLX5_ENCAP_MAX_LEN];
+   /** Constructed IPv6 routing data buffer. */
+   uint8_t ipv6_push_data[MLX5_PUSH_MAX_LEN];
+};
+
 /* rte flow action translate to DR action struct. */
 struct mlx5_action_construct_data {
LIST_ENTRY(mlx5_action_construct_data) next;
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index fcf493c771..7160477c83 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -158,7 +158,7 @@ static int flow_hw_translate_group(struct rte_eth_dev *dev,
   struct rte_flow_error *error);
 static __rte_always_inline int
 flow_hw_set_vlan_vid_construct(struct rte_eth_dev *dev,
-  struct mlx5_hw_q_job *job,
+  struct mlx5_modification_cmd *mhdr_cmd,
   struct mlx5_action_construct_data *act_data,
   const struct mlx5_hw_actions *hw_acts,
   const struct rte_flow_action *action);
@@ -2799,7 +2799,7 @@ flow_hw_mhdr_cmd_is_nop(const struct 
mlx5_modification_cmd *cmd)
  *0 on success, negative value otherwise and rte_errno is set.
  */
 static __rte_always_inline int
-flow_hw_modify_field_construct(struct mlx5_hw_q_job *job,
+flow_hw_modify_field_construct(struct mlx5_modification_cmd *mhdr_cmd,
   struct mlx5_action_construct_data *act_data,
   const struct mlx5_hw_actions *hw_acts,
   const struct rte_flow_action *action)
@@ -2858,7 +2858,7 @@ flow_hw_modify_field_construct(struct mlx5_hw_q_job *job,
 
if (i >= act_data->modify_header.mhdr_cmds_end)
return -1;
-   if (flow_hw_mhdr_cmd_is_nop(&job->mhdr_cmd[i])) {
+   if (flow_hw_mhdr_cmd_is_nop(&mhdr_cmd[i])) {
++i;
continue;
}
@@ -2878,7 +2878,7 @@ flow_hw_modify_field_construct(struct mlx5_hw_q_job *job,
mhdr_action->dst.field == RTE_FLOW_FIELD_IPV6_DSCP)
data <<= MLX5_IPV6_HDR_DSCP_SHIFT;
data = (data & mask) >> off_b;
-   job->mhdr_cmd[i++].data1 = rte_cpu_to_be_32(data);
+   mhdr_cmd[i++].data1 = rte_cpu_to_be_32(data);
++field;
} while (field->size);
return 0;
@@ -2892,8 +2892,10 @@ flow_hw_modify_field_construct(struct mlx5_hw_q_job *job,
  *
  * @param[in] dev
  *   Pointer to the rte_eth_dev structure.
- * @param[in] job
- *   Pointer to job descriptor.
+ * @param[in] flow
+ *   Pointer to flow structure.
+ * @param[in] ap
+ *   Pointer to container for temporarily constructed actions' parameters.
  * @param[in] hw_acts
  *   Pointer to translated actions from template.
  

[PATCH 11/11] net/mlx5: remove unneeded device status checking

[Dariusz Sosnowski]

From: Bing Zhao 

The flow rule can be inserted even before the device started. The
only exception is for a queue or RSS action.

For the other interfaces of template API, the start status is not
checked. The checking would cause some cache miss or eviction since
the flag locates on some other cache line.

Fixes: f1fecffa88df ("net/mlx5: support Direct Rules action template API")
Cc: sta...@dpdk.org

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 4e4beb4428..8481a9b7f0 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -3501,11 +3501,6 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
uint32_t res_idx = 0;
int ret;
 
-   if (unlikely((!dev->data->dev_started))) {
-   rte_flow_error_set(error, EINVAL, 
RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
-  "Port must be started before enqueueing flow 
operations");
-   return NULL;
-   }
flow = mlx5_ipool_malloc(table->flow, &flow_idx);
if (!flow)
goto error;
-- 
2.39.2

[PATCH 08/11] net/mlx5: use flow as operation container

[Dariusz Sosnowski]

While processing async flow operations in mlx5 PMD,
mlx5_hw_q_job struct is used to hold the following data
related to the ongoing operation.

- operation type,
- user data,
- flow reference.

Job itself is then passed to mlx5dr layer as its "user data".
Other types of data required during flow operation processing
are accessed through the flow itself.

Since most of the accessed fields are in the flow struct itself,
the operation type and user data can be moved to the flow struct.
This removes unnecessary memory indirection and reduces memory
footprint of flow operations processing. It decreases cache stress
and as a result can increase processing throughput.

This patch removes the mlx5_hw_q_job from async flow operations
processing and from now on the flow itself can represent the ongoing
operation. Async operations on indirect actions still use jobs.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h |   8 +-
 drivers/net/mlx5/mlx5_flow.h|  13 ++
 drivers/net/mlx5/mlx5_flow_hw.c | 210 +++-
 3 files changed, 116 insertions(+), 115 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 0cc32bf67b..4362efb02f 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -396,10 +396,7 @@ enum mlx5_hw_indirect_type {
 struct mlx5_hw_q_job {
uint32_t type; /* Job type. */
uint32_t indirect_type;
-   union {
-   struct rte_flow_hw *flow; /* Flow attached to the job. */
-   const void *action; /* Indirect action attached to the job. */
-   };
+   const void *action; /* Indirect action attached to the job. */
void *user_data; /* Job user data. */
struct {
/* User memory for query output */
@@ -412,7 +409,8 @@ struct mlx5_hw_q_job {
 /* HW steering job descriptor LIFO pool. */
 struct mlx5_hw_q {
uint32_t job_idx; /* Free job index. */
-   uint32_t size; /* LIFO size. */
+   uint32_t size; /* Job LIFO queue size. */
+   uint32_t ongoing_flow_ops; /* Number of ongoing flow operations. */
struct mlx5_hw_q_job **job; /* LIFO header. */
struct rte_ring *indir_cq; /* Indirect action SW completion queue. */
struct rte_ring *indir_iq; /* Indirect action SW in progress queue. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8fd07bdce4..2e3e7d0533 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1257,6 +1257,16 @@ typedef uint32_t cnt_id_t;
 
 #if defined(HAVE_IBV_FLOW_DV_SUPPORT) || !defined(HAVE_INFINIBAND_VERBS_H)
 
+enum {
+   MLX5_FLOW_HW_FLOW_OP_TYPE_NONE,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_CREATE,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_DESTROY,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_UPDATE,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_RSZ_TBL_CREATE,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_RSZ_TBL_DESTROY,
+   MLX5_FLOW_HW_FLOW_OP_TYPE_RSZ_TBL_MOVE,
+};
+
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
 #endif
@@ -1278,6 +1288,9 @@ struct rte_flow_hw {
cnt_id_t cnt_id;
uint32_t mtr_id;
uint32_t rule_idx;
+   uint8_t operation_type; /**< Ongoing flow operation type. */
+   void *user_data; /**< Application's private data passed to enqueued 
flow operation. */
+   uint8_t padding[1]; /**< Padding for proper alignment of mlx5dr rule 
struct. */
uint8_t rule[]; /* HWS layer data struct. */
 } __rte_packed;
 
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index acc56819eb..4d39e7bd45 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -312,6 +312,31 @@ static const struct rte_flow_item_eth 
ctrl_rx_eth_bcast_spec = {
.hdr.ether_type = 0,
 };
 
+static inline uint32_t
+flow_hw_q_pending(struct mlx5_priv *priv, uint32_t queue)
+{
+   struct mlx5_hw_q *q = &priv->hw_q[queue];
+
+   MLX5_ASSERT(q->size >= q->job_idx);
+   return (q->size - q->job_idx) + q->ongoing_flow_ops;
+}
+
+static inline void
+flow_hw_q_inc_flow_ops(struct mlx5_priv *priv, uint32_t queue)
+{
+   struct mlx5_hw_q *q = &priv->hw_q[queue];
+
+   q->ongoing_flow_ops++;
+}
+
+static inline void
+flow_hw_q_dec_flow_ops(struct mlx5_priv *priv, uint32_t queue)
+{
+   struct mlx5_hw_q *q = &priv->hw_q[queue];
+
+   q->ongoing_flow_ops--;
+}
+
 static __rte_always_inline struct mlx5_hw_q_job *
 flow_hw_job_get(struct mlx5_priv *priv, uint32_t queue)
 {
@@ -3407,20 +3432,15 @@ flow_hw_async_flow_create(struct rte_eth_dev *dev,
struct mlx5_flow_hw_action_params ap;
struct mlx5_flow_hw_pattern_params pp;
struct rte_flow_hw *flow = NULL;
-   struct mlx5_hw_q_job *job = NULL;
const struct rte_flow_item *rule_items;
uint32_t flow_idx = 0;
uint32_t res_idx = 0;
int ret;
 
if (unlikely((!dev->data->dev_started))) {
-   rte_errno = EINVAL;
-   goto error;
-   

[PATCH 09/11] net/mlx5: move rarely used flow fields outside

[Dariusz Sosnowski]

Some of the flow fields are either not always required
or are used very rarely, e.g.:

- AGE action reference,
- direct METER/METER_MARK action reference,
- matcher selector for resizable tables.

This patch moves these fields to rte_flow_hw_aux struct in order to
reduce the overall size of the flow struct, reducing the total size
of working set for most common use cases.
This results in reduction of the frequency of cache invalidation
during async flow operations processing.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h|  61 +++-
 drivers/net/mlx5/mlx5_flow_hw.c | 121 
 2 files changed, 138 insertions(+), 44 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 2e3e7d0533..1c67d8dd35 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1271,31 +1271,60 @@ enum {
 #pragma GCC diagnostic ignored "-Wpedantic"
 #endif
 
-/* HWS flow struct. */
+/** HWS flow struct. */
 struct rte_flow_hw {
-   uint32_t idx; /* Flow index from indexed pool. */
-   uint32_t res_idx; /* Resource index from indexed pool. */
-   uint32_t fate_type; /* Fate action type. */
+   /** The table flow allcated from. */
+   struct rte_flow_template_table *table;
+   /** Application's private data passed to enqueued flow operation. */
+   void *user_data;
+   /** Flow index from indexed pool. */
+   uint32_t idx;
+   /** Resource index from indexed pool. */
+   uint32_t res_idx;
+   /** HWS flow rule index passed to mlx5dr. */
+   uint32_t rule_idx;
+   /** Fate action type. */
+   uint32_t fate_type;
+   /** Ongoing flow operation type. */
+   uint8_t operation_type;
+   /** Index of pattern template this flow is based on. */
+   uint8_t mt_idx;
+
+   /** COUNT action index. */
+   cnt_id_t cnt_id;
union {
-   /* Jump action. */
+   /** Jump action. */
struct mlx5_hw_jump_action *jump;
-   struct mlx5_hrxq *hrxq; /* TIR action. */
+   /** TIR action. */
+   struct mlx5_hrxq *hrxq;
};
-   struct rte_flow_template_table *table; /* The table flow allcated from. 
*/
-   uint8_t mt_idx;
-   uint8_t matcher_selector:1;
+
+   /**
+* Padding for alignment to 56 bytes.
+* Since mlx5dr rule is 72 bytes, whole flow is contained within 128 B 
(2 cache lines).
+* This space is reserved for future additions to flow struct.
+*/
+   uint8_t padding[10];
+   /** HWS layer data struct. */
+   uint8_t rule[];
+} __rte_packed;
+
+/** Auxiliary data fields that are updatable. */
+struct rte_flow_hw_aux_fields {
+   /** AGE action index. */
uint32_t age_idx;
-   cnt_id_t cnt_id;
+   /** Direct meter (METER or METER_MARK) action index. */
uint32_t mtr_id;
-   uint32_t rule_idx;
-   uint8_t operation_type; /**< Ongoing flow operation type. */
-   void *user_data; /**< Application's private data passed to enqueued 
flow operation. */
-   uint8_t padding[1]; /**< Padding for proper alignment of mlx5dr rule 
struct. */
-   uint8_t rule[]; /* HWS layer data struct. */
-} __rte_packed;
+};
 
 /** Auxiliary data stored per flow which is not required to be stored in main 
flow structure. */
 struct rte_flow_hw_aux {
+   /** Auxiliary fields associated with the original flow. */
+   struct rte_flow_hw_aux_fields orig;
+   /** Auxiliary fields associated with the updated flow. */
+   struct rte_flow_hw_aux_fields upd;
+   /** Index of resizable matcher associated with this flow. */
+   uint8_t matcher_selector;
/** Placeholder flow struct used during flow rule update operation. */
struct rte_flow_hw upd_flow;
 };
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 4d39e7bd45..3252f76e64 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -139,6 +139,50 @@ mlx5_flow_hw_aux(uint16_t port_id, struct rte_flow_hw 
*flow)
}
 }
 
+static __rte_always_inline void
+mlx5_flow_hw_aux_set_age_idx(struct rte_flow_hw *flow,
+struct rte_flow_hw_aux *aux,
+uint32_t age_idx)
+{
+   /*
+* Only when creating a flow rule, the type will be set explicitly.
+* Or else, it should be none in the rule update case.
+*/
+   if (unlikely(flow->operation_type == MLX5_FLOW_HW_FLOW_OP_TYPE_UPDATE))
+   aux->upd.age_idx = age_idx;
+   else
+   aux->orig.age_idx = age_idx;
+}
+
+static __rte_always_inline uint32_t
+mlx5_flow_hw_aux_get_age_idx(struct rte_flow_hw *flow, struct rte_flow_hw_aux 
*aux)
+{
+   if (unlikely(flow->operation_type == MLX5_FLOW_HW_FLOW_OP_TYPE_UPDATE))
+   return aux->upd.age_idx;
+   else
+   return aux->ori

[PATCH 10/11] net/mlx5: reuse flow fields

[Dariusz Sosnowski]

Each time a flow is allocated in mlx5 PMD the whole buffer,
both rte_flow_hw and mlx5dr_rule parts, are zeroed.
This introduces some wasted work because:

- mlx5dr layer does not assume that mlx5dr_rule must be initialized,
- flow action translation in mlx5 PMD does not need most of the fields
  of rte_flow_hw to be zeroed.

To reduce this wasted work, this patch introduces flags field to
flow definition. Each flow field which is not always initialized
during flow creation, will have a correspondent flag set if value is
valid (in other words - it was set during flow creation).
Utilizing this mechanism allows PMD to:

- remove zeroing from flow allocation,
- access some fields (especially from rte_flow_hw_aux) if and only if
  corresponding flag is set.

Signed-off-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow.h| 24 -
 drivers/net/mlx5/mlx5_flow_hw.c | 93 +
 2 files changed, 83 insertions(+), 34 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 1c67d8dd35..a01e970d04 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1267,6 +1267,26 @@ enum {
MLX5_FLOW_HW_FLOW_OP_TYPE_RSZ_TBL_MOVE,
 };
 
+enum {
+   MLX5_FLOW_HW_FLOW_FLAG_CNT_ID = RTE_BIT32(0),
+   MLX5_FLOW_HW_FLOW_FLAG_FATE_JUMP = RTE_BIT32(1),
+   MLX5_FLOW_HW_FLOW_FLAG_FATE_HRXQ = RTE_BIT32(2),
+   MLX5_FLOW_HW_FLOW_FLAG_AGE_IDX = RTE_BIT32(3),
+   MLX5_FLOW_HW_FLOW_FLAG_MTR_ID = RTE_BIT32(4),
+   MLX5_FLOW_HW_FLOW_FLAG_MATCHER_SELECTOR = RTE_BIT32(5),
+   MLX5_FLOW_HW_FLOW_FLAG_UPD_FLOW = RTE_BIT32(6),
+};
+
+#define MLX5_FLOW_HW_FLOW_FLAGS_ALL ( \
+   MLX5_FLOW_HW_FLOW_FLAG_CNT_ID | \
+   MLX5_FLOW_HW_FLOW_FLAG_FATE_JUMP | \
+   MLX5_FLOW_HW_FLOW_FLAG_FATE_HRXQ | \
+   MLX5_FLOW_HW_FLOW_FLAG_AGE_IDX | \
+   MLX5_FLOW_HW_FLOW_FLAG_MTR_ID | \
+   MLX5_FLOW_HW_FLOW_FLAG_MATCHER_SELECTOR | \
+   MLX5_FLOW_HW_FLOW_FLAG_UPD_FLOW \
+   )
+
 #ifdef PEDANTIC
 #pragma GCC diagnostic ignored "-Wpedantic"
 #endif
@@ -1283,8 +1303,8 @@ struct rte_flow_hw {
uint32_t res_idx;
/** HWS flow rule index passed to mlx5dr. */
uint32_t rule_idx;
-   /** Fate action type. */
-   uint32_t fate_type;
+   /** Which flow fields (inline or in auxiliary struct) are used. */
+   uint32_t flags;
/** Ongoing flow operation type. */
uint8_t operation_type;
/** Index of pattern template this flow is based on. */
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 3252f76e64..4e4beb4428 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -2832,6 +2832,7 @@ flow_hw_shared_action_construct(struct rte_eth_dev *dev, 
uint32_t queue,
&rule_act->action,
&rule_act->counter.offset))
return -1;
+   flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_CNT_ID;
flow->cnt_id = act_idx;
break;
case MLX5_INDIRECT_ACTION_TYPE_AGE:
@@ -2841,6 +2842,7 @@ flow_hw_shared_action_construct(struct rte_eth_dev *dev, 
uint32_t queue,
 * it in flow destroy.
 */
mlx5_flow_hw_aux_set_age_idx(flow, aux, act_idx);
+   flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_AGE_IDX;
if (action_flags & MLX5_FLOW_ACTION_INDIRECT_COUNT)
/*
 * The mutual update for idirect AGE & COUNT will be
@@ -2856,6 +2858,7 @@ flow_hw_shared_action_construct(struct rte_eth_dev *dev, 
uint32_t queue,
  ¶m->queue_id, &age_cnt,
  idx) < 0)
return -1;
+   flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_CNT_ID;
flow->cnt_id = age_cnt;
param->nb_cnts++;
} else {
@@ -3160,7 +3163,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
rule_acts[act_data->action_dst].action =
(!!attr.group) ? jump->hws_action : jump->root_action;
flow->jump = jump;
-   flow->fate_type = MLX5_FLOW_FATE_JUMP;
+   flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_FATE_JUMP;
break;
case RTE_FLOW_ACTION_TYPE_RSS:
case RTE_FLOW_ACTION_TYPE_QUEUE:
@@ -3171,7 +3174,7 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
return -1;
rule_acts[act_data->action_dst].action = hrxq->action;
flow->hrxq = hrxq;
-   flow->fate_type = MLX5_FLOW_FATE_QUEUE;
+   flow->flags |= MLX5_FLOW_HW_FLOW_FLAG_FATE_HRX

RE: [PATCH v1] eventdev/crypto: fix enqueueing invalid ops

[Gujjar, Abhinandan S]

> -Original Message-
> From: Kundapura, Ganapati 
> Sent: Wednesday, February 28, 2024 4:09 PM
> To: dev@dpdk.org; jer...@marvell.com; Jayatheerthan, Jay
> 
> Cc: Naga Harish K, S V ; Gujjar, Abhinandan S
> 
> Subject: [PATCH v1] eventdev/crypto: fix enqueueing invalid ops
> 
> When tail pointer of Circ buffer rollsover as the Circ buffer becomes full, 
> crypto
> adapter is enqueueing ops beyond the size of the Circ buffer leading to 
> segfault
> due to invalid ops access.
> 
> Fixed by enqueueing ops from head pointer to (size-head) number of ops when
> Circ buffer becomes full and the remaining ops will be flushed in next 
> iteration.
> 
> Fixes: 6c3c888656fc ("eventdev/crypto: fix circular buffer full case")
> 
> Signed-off-by: Ganapati Kundapura 
> 
Acked-by: Abhinandan Gujjar 

> diff --git a/lib/eventdev/rte_event_crypto_adapter.c
> b/lib/eventdev/rte_event_crypto_adapter.c
> index d46595d..9903f96 100644
> --- a/lib/eventdev/rte_event_crypto_adapter.c
> +++ b/lib/eventdev/rte_event_crypto_adapter.c
> @@ -245,20 +245,28 @@ eca_circular_buffer_flush_to_cdev(struct
> crypto_ops_circular_buffer *bufp,
>   struct rte_crypto_op **ops = bufp->op_buffer;
> 
>   if (*tailp > *headp)
> + /* Flush ops from head pointer to (tail - head) OPs */
>   n = *tailp - *headp;
>   else if (*tailp < *headp)
> + /* Circ buffer - Rollover.
> +  * Flush OPs from head to max size of buffer.
> +  * Rest of the OPs will be flushed in next iteration.
> +  */
>   n = bufp->size - *headp;
>   else { /* head == tail case */
>   /* when head == tail,
>* circ buff is either full(tail pointer roll over) or empty
>*/
>   if (bufp->count != 0) {
> - /* circ buffer is full */
> - n = bufp->count;
> + /* Circ buffer - FULL.
> +  * Flush OPs from head to max size of buffer.
> +  * Rest of the OPS will be flushed in next iteration.
> +  */
> + n = bufp->size - *headp;
>   } else {
> - /* circ buffer is empty */
> + /* Circ buffer - Empty */
>   *nb_ops_flushed = 0;
> - return 0;  /* buffer empty */
> + return 0;
>   }
>   }
> 
> --
> 2.6.4

Re: [PATCH v6 20/23] mbuf: remove and stop using rte marker fields

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 03:18:40PM +0100, David Marchand wrote:
> On Tue, Feb 27, 2024 at 6:44 AM Tyler Retzlaff
>  wrote:
> >
> > RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove
> > RTE_MARKER fields from rte_mbuf struct.
> >
> > Maintain alignment of fields after removed cacheline1 marker by placing
> > C11 alignas(RTE_CACHE_LINE_MIN_SIZE).
> >
> > Update implementation of rte_mbuf_prefetch_part1() and
> > rte_mbuf_prefetch_part2() inline functions calculate pointer for
> > prefetch of cachline0 and cachline1 without using removed markers.
> >
> > Update static_assert of rte_mbuf struct fields to reference data_off and
> > packet_type fields that occupy the original offsets of the marker
> > fields.
> >
> > Signed-off-by: Tyler Retzlaff 
> > ---
> >  doc/guides/rel_notes/release_24_03.rst |  9 
> >  lib/mbuf/rte_mbuf.h|  4 ++--
> >  lib/mbuf/rte_mbuf_core.h   | 39 
> > +-
> >  3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_24_03.rst 
> > b/doc/guides/rel_notes/release_24_03.rst
> > index 879bb49..67750f2 100644
> > --- a/doc/guides/rel_notes/release_24_03.rst
> > +++ b/doc/guides/rel_notes/release_24_03.rst
> > @@ -156,6 +156,15 @@ Removed Items
> >The application reserved statically defined logtypes 
> > ``RTE_LOGTYPE_USER1..RTE_LOGTYPE_USER8``
> >are still defined.
> >
> > +* mbuf: ``RTE_MARKER`` fields ``cacheline0`` ``cacheline1``
> > +  ``rx_descriptor_fields1`` and ``RTE_MARKER64`` field ``rearm_data``
> > +  have been removed from ``struct rte_mbuf``.
> > +  Prefetch of ``cacheline0`` and ``cacheline1`` may be achieved through
> > +  ``rte_mbuf_prefetch_part1()`` and ``rte_mbuf_prefetch_part2()`` inline
> > +  functions respectively.
> > +  Access to ``rearm_data`` and ``rx_descriptor_fields1`` should be
> > +  through new inline functions ``rte_mbuf_rearm_data()`` and
> > +  ``rte_mbuf_rx_descriptor_fields1()`` respectively.
> >
> >  API Changes
> >  ---
> > diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
> > index aa7495b..61cda20 100644
> > --- a/lib/mbuf/rte_mbuf.h
> > +++ b/lib/mbuf/rte_mbuf.h
> > @@ -108,7 +108,7 @@
> >  static inline void
> >  rte_mbuf_prefetch_part1(struct rte_mbuf *m)
> >  {
> > -   rte_prefetch0(&m->cacheline0);
> > +   rte_prefetch0(m);
> >  }
> >
> >  /**
> > @@ -126,7 +126,7 @@
> >  rte_mbuf_prefetch_part2(struct rte_mbuf *m)
> >  {
> >  #if RTE_CACHE_LINE_SIZE == 64
> > -   rte_prefetch0(&m->cacheline1);
> > +   rte_prefetch0(RTE_PTR_ADD(m, RTE_CACHE_LINE_MIN_SIZE));
> >  #else
> > RTE_SET_USED(m);
> >  #endif
> > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
> > index 36551c2..4e06f15 100644
> > --- a/lib/mbuf/rte_mbuf_core.h
> > +++ b/lib/mbuf/rte_mbuf_core.h
> > @@ -18,6 +18,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -467,8 +468,6 @@ enum {
> >   * The generic rte_mbuf, containing a packet mbuf.
> >   */
> >  struct rte_mbuf {
> > -   RTE_MARKER cacheline0;
> > -
> > void *buf_addr;   /**< Virtual address of segment buffer. */
> >  #if RTE_IOVA_IN_MBUF
> > /**
> > @@ -495,7 +494,6 @@ struct rte_mbuf {
> >  * To obtain a pointer to rearm_data use the rte_mbuf_rearm_data()
> >  * accessor instead of directly referencing through the data_off 
> > field.
> >  */
> > -   RTE_MARKER64 rearm_data;
> > uint16_t data_off;
> 
> One subtile change of removing the marker is that fields may not be
> aligned as before.
> 
> #if RTE_IOVA_IN_MBUF
> /**
>  * Physical address of segment buffer.
>  * This field is undefined if the build is configured to use only
>  * virtual address as IOVA (i.e. RTE_IOVA_IN_MBUF is 0).
>  * Force alignment to 8-bytes, so as to ensure we have the exact
>  * same mbuf cacheline0 layout for 32-bit and 64-bit. This makes
>  * working on vector drivers easier.
>  */
> rte_iova_t buf_iova __rte_aligned(sizeof(rte_iova_t));
> #else
> /**
>  * Next segment of scattered packet.
>  * This field is valid when physical address field is undefined.
>  * Otherwise next pointer in the second cache line will be used.
>  */
> struct rte_mbuf *next;
> #endif
> 
> When building ! RTE_IOVA_IN_MBUF on a 32 bits arch, the next pointer
> is not force aligned to 64bits.
> Which has a cascade effect on data_off alignement.
> 
> In file included from ../lib/mbuf/rte_mbuf_core.h:19,
>  from ../lib/mbuf/rte_mbuf.h:42,
>  from ../lib/mbuf/rte_mbuf_dyn.c:18:
> ../lib/mbuf/rte_mbuf_core.h:676:1: error: static assertion failed: "data_off"
>   676 | static_assert(!(offsetof(struct rte_mbuf, data_off) !=
>   | ^
> 

it is the assert that is wrong here not the offset/alignment of the fields,
i fai

Re: [PATCH v3 02/16] bpf: stop using variadic argument pack extension

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 01:34:59PM +, Konstantin Ananyev wrote:
> 
> > 
> > On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
> >  wrote:
> > >
> > > Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
> > > which allow a prefix and arguments to be inserted into the log line
> > > without the need to use the ## args variadic argument pack extension.
> > >
> > > Signed-off-by: Tyler Retzlaff 
> > > ---
> > >  lib/bpf/bpf_impl.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
> > > index 1a3d97d..680b1e5 100644
> > > --- a/lib/bpf/bpf_impl.h
> > > +++ b/lib/bpf/bpf_impl.h
> > > @@ -29,8 +29,8 @@ struct rte_bpf {
> > >  extern int rte_bpf_logtype;
> > >  #define RTE_LOGTYPE_BPF rte_bpf_logtype
> > >
> > > -#defineRTE_BPF_LOG_LINE(lvl, fmt, args...) \
> > > -   RTE_LOG_LINE(lvl, BPF, fmt, ##args)
> > > +#define RTE_BPF_LOG_LINE(level, ...) \
> > > +   RTE_LOG_LINE_PREFIX(level, BPF, "%s(): ", __func__, __VA_ARGS__)
> > 
> > The patch $topic seems to be removal of variadic argument extension.
> > So, I would expect a simple:
> > +#define RTE_BPF_LOG_LINE(level, ...) \
> > +   RTE_LOG_LINE(level, BPF, __VA_ARGS__)
> > 
> > Konstantin, just to be sure, are you ok with this (debug from my pov)
> > prefix addition?
> > 
> 
> Thanks David for spotting it, yes somehow I missed that.
> Actually yes, yours variant looks correct to me.
> Konstantin.

oh, sorry about this. i did not intend to add prefixes where there were
none. would you like me to restore this with David's suggestion or would
you like to keep the prefix with __func__?

let me know i'll make an adjustment to the series if necessary.

> 

Re: [PATCH v3 00/16] stop using variadic argument pack extension

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 12:45:04PM +0100, David Marchand wrote:
> On Tue, Feb 27, 2024 at 7:15 PM Tyler Retzlaff
>  wrote:
> >
> > On Mon, Feb 26, 2024 at 12:54:36PM -0800, Stephen Hemminger wrote:
> > > On Mon, 26 Feb 2024 12:19:30 -0800
> > > Tyler Retzlaff  wrote:
> > >
> > > > RTE_LOG_LINE cannot be augmented with a prefix format and arguments
> > > > without the user of RTE_LOG_LINE using the args... and ## args compiler
> > > > extension to conditionally remove trailing comma when the macro receives
> > > > only a single argument.
> > > >
> > > > Provide a new/similar macro RTE_LOG_LINE_PREFIX that accepts the prefix
> > > > format and arguments as separate parameters allowing them to be expanded
> > > > at the correct locations inside of RTE_FMT() allowing the rest of the
> > > > non-prefix format string and arguments to be collapsed to the argument
> > > > pack which can be directly forwarded with __VA_ARGS__ avoiding the need
> > > > for conditional comma removal.
> > > >
> > > > I've done my best to manually check expansions (preprocessed) and 
> > > > compiled
> > > > printf of the logs to validate correct output.
> > > >
> > > > note: due to drastic change in series i have not carried any series acks
> > > >   forward.
> > >
> > > The changes look good, you might want to add release note, update coding
> > > style doc, and/or update checkpatch to discourage re-introduction.
> >
> > re-introduction should be protected by the CI. i know checkpatch would
> > be better but i couldn't think of a good way to match an arbitrarily
> > named pack ... reliably where it could potentially cause noise.
> 
> What about a simple:
> 
> +   # forbid use of variadic argument pack extension in macros
> +   awk -v FOLDERS="lib drivers app examples" \
> +   -v
> EXPRESSIONS='#[[:space:]]*define.*[^(,[:space:]]\\.\\.\\.[[:space:]]*)'
> \
> +   -v RET_ON_FAIL=1 \
> +   -v MESSAGE='Do not use variadic argument pack in macros' \
> +   -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> +   "$1" || res=1
> +

I have no objection, I suppose worst case scenario if it turns out to
catch things we don't want it to catch we can always ignore or remove
it.

I will add the check and submit a new rev.

> 
> 
> -- 
> David Marchand

Re: [PATCH v4 4/7] net/tap: rewrite the RSS BPF program

[Ferruh Yigit]

On 2/10/2024 2:09 AM, Stephen Hemminger wrote:
> On Sat, 10 Feb 2024 00:54:15 +
> Ferruh Yigit  wrote:
> 
>> On 2/8/2024 7:05 PM, Stephen Hemminger wrote:
>>> Rewrite the BPF program used to do queue based RSS.
>>> Important changes:
>>> - uses newer BPF map format BTF
>>> - accepts key as parameter rather than constant default
>>> - can do L3 or L4 hashing
>>> - supports IPv4 options
>>> - supports IPv6 extension headers
>>> - restructured for readability
>>>
>>> The usage of BPF is different as well:
>>> - the incoming configuration is looked up based on
>>>   class parameters rather than patching the BPF.
>>> - the resulting queue is placed in skb rather
>>>   than requiring a second pass through classifier step.
>>>
>>> Note: This version only works with later patch to enable it on
>>> the DPDK driver side. It is submitted as an incremental patch
>>> to allow for easier review. Bisection still works because
>>> the old instruction are still present for now.
>>>
>>> Signed-off-by: Stephen Hemminger   
>>
>> <...>
>>
>>> diff --git a/drivers/net/tap/bpf/meson.build 
>>> b/drivers/net/tap/bpf/meson.build
>>> new file mode 100644
>>> index ..f2c03a19fd4d
>>> --- /dev/null
>>> +++ b/drivers/net/tap/bpf/meson.build
>>> @@ -0,0 +1,81 @@
>>> +# SPDX-License-Identifier: BSD-3-Clause
>>> +# Copyright 2024 Stephen Hemminger 
>>> +
>>> +enable_tap_rss = false
>>> +
>>> +libbpf = dependency('libbpf', required: false, method: 'pkg-config')
>>> +if not libbpf.found()
>>> +message('net/tap: no RSS support missing libbpf')
>>> +subdir_done()
>>> +endif
>>> +
>>> +# Debian install this in /usr/sbin which is not in $PATH
>>> +bpftool = find_program('bpftool', '/usr/sbin/bpftool', required: false, 
>>> version: '>= 5.6.0')
>>> +if not bpftool.found()
>>> +message('net/tap: no RSS support missing bpftool')
>>> +subdir_done()
>>> +endif
>>>  
>>
>> I am getting following build error:
>> '
>> drivers/net/tap/bpf/meson.build:13:10: ERROR: Command `/usr/sbin/bpftool
>> --version` failed with status 2.
>> '
>>
>> There is a '/usr/sbin/bpftool' file but it is a script and gives
>> following message when run:
>> "WARNING: bpftool not found for kernel 6.5.0-15"
>>
>> This is with "Ubuntu 22.04.3 LTS"
>>
>>
>> Overall thanks for fixing tap BPF support.
> 
> Just set up an equivalent Ubuntu VM 22.04 VM and made sure all packages
> were up to date.
> 
> Looks like Ubuntu borked the packaging of bpftool.
> Maybe Luca has some insight.
> 
> shemminger@ubuntu-22-04:~/dpdk$ sudo apt install libbpf-dev bpftool
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Package bpftool is a virtual package provided by:
>   linux-nvidia-6.2-tools-common 6.2.0-1003.3~22.04.1
>   linux-lowlatency-hwe-6.5-tools-common 6.5.0-17.17.1.1.1~22.04.1
>   linux-hwe-6.5-tools-common 6.5.0-17.17~22.04.1
>   linux-hwe-6.2-tools-common 6.2.0-39.40~22.04.1
> You should explicitly select one to install.
> 

I can make it work but it can hit others too, we need something that
detects this condition and disables tap/bpf.

RE: [PATCH v3 02/16] bpf: stop using variadic argument pack extension

[Konstantin Ananyev]

> On Wed, Feb 28, 2024 at 01:34:59PM +, Konstantin Ananyev wrote:
> >
> > >
> > > On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
> > >  wrote:
> > > >
> > > > Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
> > > > which allow a prefix and arguments to be inserted into the log line
> > > > without the need to use the ## args variadic argument pack extension.
> > > >
> > > > Signed-off-by: Tyler Retzlaff 
> > > > ---
> > > >  lib/bpf/bpf_impl.h | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
> > > > index 1a3d97d..680b1e5 100644
> > > > --- a/lib/bpf/bpf_impl.h
> > > > +++ b/lib/bpf/bpf_impl.h
> > > > @@ -29,8 +29,8 @@ struct rte_bpf {
> > > >  extern int rte_bpf_logtype;
> > > >  #define RTE_LOGTYPE_BPF rte_bpf_logtype
> > > >
> > > > -#defineRTE_BPF_LOG_LINE(lvl, fmt, args...) \
> > > > -   RTE_LOG_LINE(lvl, BPF, fmt, ##args)
> > > > +#define RTE_BPF_LOG_LINE(level, ...) \
> > > > +   RTE_LOG_LINE_PREFIX(level, BPF, "%s(): ", __func__, __VA_ARGS__)
> > >
> > > The patch $topic seems to be removal of variadic argument extension.
> > > So, I would expect a simple:
> > > +#define RTE_BPF_LOG_LINE(level, ...) \
> > > +   RTE_LOG_LINE(level, BPF, __VA_ARGS__)
> > >
> > > Konstantin, just to be sure, are you ok with this (debug from my pov)
> > > prefix addition?
> > >
> >
> > Thanks David for spotting it, yes somehow I missed that.
> > Actually yes, yours variant looks correct to me.
> > Konstantin.
> 
> oh, sorry about this. i did not intend to add prefixes where there were
> none. would you like me to restore this with David's suggestion or would
> you like to keep the prefix with __func__?

Please restore as David suggested.
No worries, after all I didn't spot it myself, all kudos goes to David :) 
 

Re: [PATCH v3 02/16] bpf: stop using variadic argument pack extension

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 05:27:54PM +, Konstantin Ananyev wrote:
> 
> 
> > On Wed, Feb 28, 2024 at 01:34:59PM +, Konstantin Ananyev wrote:
> > >
> > > >
> > > > On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
> > > >  wrote:
> > > > >
> > > > > Use RTE_LOG_LINE_PREFIX instead of RTE_LOG_LINE in macro expansions
> > > > > which allow a prefix and arguments to be inserted into the log line
> > > > > without the need to use the ## args variadic argument pack extension.
> > > > >
> > > > > Signed-off-by: Tyler Retzlaff 
> > > > > ---
> > > > >  lib/bpf/bpf_impl.h | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h
> > > > > index 1a3d97d..680b1e5 100644
> > > > > --- a/lib/bpf/bpf_impl.h
> > > > > +++ b/lib/bpf/bpf_impl.h
> > > > > @@ -29,8 +29,8 @@ struct rte_bpf {
> > > > >  extern int rte_bpf_logtype;
> > > > >  #define RTE_LOGTYPE_BPF rte_bpf_logtype
> > > > >
> > > > > -#defineRTE_BPF_LOG_LINE(lvl, fmt, args...) \
> > > > > -   RTE_LOG_LINE(lvl, BPF, fmt, ##args)
> > > > > +#define RTE_BPF_LOG_LINE(level, ...) \
> > > > > +   RTE_LOG_LINE_PREFIX(level, BPF, "%s(): ", __func__, 
> > > > > __VA_ARGS__)
> > > >
> > > > The patch $topic seems to be removal of variadic argument extension.
> > > > So, I would expect a simple:
> > > > +#define RTE_BPF_LOG_LINE(level, ...) \
> > > > +   RTE_LOG_LINE(level, BPF, __VA_ARGS__)
> > > >
> > > > Konstantin, just to be sure, are you ok with this (debug from my pov)
> > > > prefix addition?
> > > >
> > >
> > > Thanks David for spotting it, yes somehow I missed that.
> > > Actually yes, yours variant looks correct to me.
> > > Konstantin.
> > 
> > oh, sorry about this. i did not intend to add prefixes where there were
> > none. would you like me to restore this with David's suggestion or would
> > you like to keep the prefix with __func__?
> 
> Please restore as David suggested.
> No worries, after all I didn't spot it myself, all kudos goes to David :) 

thanks, i'll submit a new rev!

>  

Re: [PATCH v3 00/16] stop using variadic argument pack extension

[David Marchand]

On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
 wrote:
>
> RTE_LOG_LINE cannot be augmented with a prefix format and arguments
> without the user of RTE_LOG_LINE using the args... and ## args compiler
> extension to conditionally remove trailing comma when the macro receives
> only a single argument.
>
> Provide a new/similar macro RTE_LOG_LINE_PREFIX that accepts the prefix
> format and arguments as separate parameters allowing them to be expanded
> at the correct locations inside of RTE_FMT() allowing the rest of the
> non-prefix format string and arguments to be collapsed to the argument
> pack which can be directly forwarded with __VA_ARGS__ avoiding the need
> for conditional comma removal.
>
> I've done my best to manually check expansions (preprocessed) and compiled
> printf of the logs to validate correct output.
>
> note: due to drastic change in series i have not carried any series acks
>   forward.
>
> v3:
>   * remove leading _ from RTE_LOG_COMMA the macro is not internal
>   * add doxygen comment for existing RTE_LOG{,DP}_LINE function-like
> macros, based on RTE_LOG{,DP} comments.
>   * add doxygen comment for new RTE_LOG{,DP}_LINE_PREFIX function-like
> macros, based on RTE_LOG{,DP} comments.
>   * merge 2 vhost patches into a single patch (mistake in previous
> submission)

I find this new helper less tricky to use and easier to read than the
RTE_FMT_* stuff that gets copy/pasted everywhere.
The changes are quite mechanical, so even though we are past -rc1, +1
for me on the series.

Can we finish the job and convert remaining macros that prefix messages in lib/?


-- 
David Marchand

Re: [PATCH 3/3] rcu: use rte macro instead of GCC attribute

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 10:29:11AM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > Sent: Wednesday, 28 February 2024 00.08
> > 
> > Use existing __rte_pure macro from rte_common.h instead of directly
> 
> Typo: __rte_pure -> __rte_may_alias
> 
> The code is correct, only the description has the typo.
> 
> > using __attribute__((__may_alias__)).
> > 
> > Signed-off-by: Tyler Retzlaff 
> > ---
> 
> With the typo corrected,

bah, i get tired :)

thanks.

> For the series,
> Reviewed-by: Morten Brørup 

Re: [v9 2/3] net/af_xdp: fix multi interface support for K8s

[Ferruh Yigit]

On 2/22/2024 1:46 PM, Loftus, Ciara wrote:
>> Subject: [v9 2/3] net/af_xdp: fix multi interface support for K8s
>>
>> The original 'use_cni' implementation, was added
>> to enable support for the AF_XDP PMD in a K8s env
>> without any escalated privileges.
>> However 'use_cni' used a hardcoded socket rather
>> than a configurable one. If a DPDK pod is requesting
>> multiple net devices and these devices are from
>> different pools, then the AF_XDP PMD attempts to
>> mount all the netdev UDSes in the pod as /tmp/afxdp.sock.
>> Which means that at best only 1 netdev will handshake
>> correctly with the AF_XDP DP. This patch addresses
>> this by making the socket parameter configurable using
>> a new vdev param called 'dp_path' alongside the
>> original 'use_cni' param. If the 'dp_path' parameter
>> is not set alongside the 'use_cni' parameter, then
>> it's configured inside the AF_XDP PMD (transparently
>> to the user). This change has been tested
>> with the AF_XDP DP PR 81[1], with both single and
> [1] does not point to any reference.
> 
>> multiple interfaces.
>>
>> Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Maryam Tahhan 
>> ---
>>  doc/guides/howto/af_xdp_dp.rst | 43 ++--
>>  doc/guides/nics/af_xdp.rst | 14 
>>  doc/guides/rel_notes/release_24_03.rst |  7 ++
>>  drivers/net/af_xdp/rte_eth_af_xdp.c| 94 --
>>  4 files changed, 116 insertions(+), 42 deletions(-)
>>
>> diff --git a/doc/guides/howto/af_xdp_dp.rst
>> b/doc/guides/howto/af_xdp_dp.rst
>> index 657fc8d52c..8a64ec5599 100644
>> --- a/doc/guides/howto/af_xdp_dp.rst
>> +++ b/doc/guides/howto/af_xdp_dp.rst
>> @@ -52,13 +52,18 @@ should be used when creating the socket
>>  to instruct libbpf not to load the default libbpf program on the netdev.
>>  Instead the loading is handled by the AF_XDP Device Plugin.
>>
>> +The EAL vdev argument ``dp_path`` is used alongside the ``use_cni``
>> argument
>> +to explicitly tell the AF_XDP PMD where to find the UDS to interact with the
>> +AF_XDP Device Plugin. If this argument is not passed alongside the 
>> ``use_cni``
>> +argument then the AF_XDP PMD configures it internally.
>> +
>>  Limitations
>>  ---
>>
>>  For DPDK versions <= v23.11 the Unix Domain Socket file path appears in
>>  the pod at "/tmp/afxdp.sock". The handshake implementation in the AF_XDP
>> PMD
>> -is only compatible with the AF_XDP Device Plugin up to commit id `38317c2`_
>> -and the pod is limited to a single netdev.
>> +is only compatible with the `AF_XDP Device Plugin for Kubernetes`_  up to
>> +commit id `38317c2`_ and the pod is limited to a single netdev.
>>
>>  .. note::
>>
>> @@ -75,6 +80,14 @@ in the PMD alongside the `use_cni` parameter.
>>
>>  .. _38317c2: https://github.com/intel/afxdp-plugins-for-
>> kubernetes/commit/38317c256b5c7dfb39e013a0f76010c2ded03669
>>
>> +.. note::
>> +
>> +The introduction of the ``dp_path`` EAL vdev argument fixes the 
>> limitation
>> above. If a
>> +user doesn't explicitly set the ``dp_path``parameter when using 
>> ``use_cni``
>> then that
>> +path is transparently configured in the AF_XDP PMD to the default
>> +`AF_XDP Device Plugin for Kubernetes`_ mount point path. This is
>> compatible with the latest
>> +AF_XDP Device Plugin. For backwards compatibility with versions of the
>> AF_XDP DP <= commit
>> +id `38317c2`_ please explicitly set ``dp_path`` to ``/tmp/afxdp.sock``.
> I think instead of adding a note here we can just simply remove the 
> limitation. When the user has this patch, they most likely will not care 
> about limitations that were previously present.
> Just make sure that the information about the behaviour when dp_path is not 
> set and how to set dp_path to be backwards compatible is still captured in 
> the docs somewhere.
> I just think it's confusing to state a limitation followed by a note that it 
> is resolved.
> 
> The remainder of the changes in this series LGTM.
> 
> Thanks,
> Ciara
>

Hi Maryam,

It would be nice to have the patch for -rc2, otherwise there will be
small time for anyone test the new feature (or existing `use_cni` one),
do you think can the comment be addressed before -rc2?

Re: [PATCH v4] app/testpmd: support updating flow rule actions

[Ferruh Yigit]

On 2/23/2024 4:19 AM, Oleksandr Kolomeiets wrote:
> "flow update" updates a flow rule specified by a rule ID with a
> new action list by making a call to "rte_flow_actions_update()":
> 
> flow update {port_id} {rule_id}
> actions {action} [/ {action} [...]] / end [user_id]
> 
> Creating, updating and destroying a flow rule:
> 
> testpmd> flow create 0 group 1 pattern eth / end actions drop / end
> Flow rule #0 created
> testpmd> flow update 0 0 actions queue index 1 / end
> Flow rule #0 updated with new actions
> testpmd> flow destroy 0 rule 0
> Flow rule #0 destroyed
> 
> Signed-off-by: Oleksandr Kolomeiets 
> Reviewed-by: Mykola Kostenok 
> Reviewed-by: Christian Koue Muf 
>

Patch looks good to me.

@Ori, @Thomas, do you have any comment, if not I will proceed with the
patch?

RE: [PATCH] net/mlx5: link status change for bonding cases

[Slava Ovsiienko]

> -Original Message-
> From: Haifei Luo 
> Sent: Monday, February 26, 2024 2:04 PM
> To: Ori Kam ; Slava Ovsiienko ;
> Matan Azrad ; Shahaf Shuler ;
> Dariusz Sosnowski ; Suanming Mou
> 
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Wisam Jaddo ; Raslan
> Darawsheh ; Roni Bar Yanai 
> Subject: [PATCH] net/mlx5: link status change for bonding cases
> 
> The current implementation of mlx5_dev_interrupt_nl_cb routine first
> compares if event netlink if_index belongs to the same device.
> This is not fully correct for the bonding device since the bonding master and
> slave interface netlink events indicate the bonding link status change as 
> well.
> Add check for if_index is related to the bonding's master/slave.
> 
> The following step is that it compares the device link status before and 
> after the
> netlink event handling. There are also the bonding specifics and it should
> compare the link status of the bonding master to detect the actual status
> change.
> 
> Signed-off-by: Haifei Luo 
Acked-by: Viacheslav Ovsiienko 

[PATCH] crypto/ipsec_mb: update Arm IPsec-MB library tag

[Wathsala Vithanage]

Updates the tag of Arm IPsec-MB library to SECLIB-IPSEC-2023.10.13
in snow3g and zuc documentation. Tag SECLIB-IPSEC-2023.10.13 updates
IPSec-MB library version to 1.4.

Signed-off-by: Wathsala Vithanage 
Reviewed-by: Ruifeng Wang 
Reviewed-by: Honnappa Nagarahalli 
Reviewed-by: Jack Bond-Preston 
---
 doc/guides/cryptodevs/snow3g.rst | 2 +-
 doc/guides/cryptodevs/zuc.rst| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/cryptodevs/snow3g.rst b/doc/guides/cryptodevs/snow3g.rst
index 3392932653..e255b1c2c7 100644
--- a/doc/guides/cryptodevs/snow3g.rst
+++ b/doc/guides/cryptodevs/snow3g.rst
@@ -54,7 +54,7 @@ can be downloaded from 
``_. The
-latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2023.06.20.
+latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2023.10.13.
 
 After downloading the library, the user needs to unpack and compile it
 on their system before building DPDK:
diff --git a/doc/guides/cryptodevs/zuc.rst b/doc/guides/cryptodevs/zuc.rst
index a414b5ad2c..24454b23a5 100644
--- a/doc/guides/cryptodevs/zuc.rst
+++ b/doc/guides/cryptodevs/zuc.rst
@@ -53,7 +53,7 @@ can be downloaded from 
``_. The
-latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2023.06.20.
+latest version of the library supported by this PMD is tagged as 
SECLIB-IPSEC-2023.10.13.
 
 After downloading the library, the user needs to unpack and compile it
 on their system before building DPDK:
-- 
2.25.1

Re: [PATCH v3 00/16] stop using variadic argument pack extension

[Tyler Retzlaff]

On Wed, Feb 28, 2024 at 06:29:14PM +0100, David Marchand wrote:
> On Mon, Feb 26, 2024 at 9:20 PM Tyler Retzlaff
>  wrote:
> >
> > RTE_LOG_LINE cannot be augmented with a prefix format and arguments
> > without the user of RTE_LOG_LINE using the args... and ## args compiler
> > extension to conditionally remove trailing comma when the macro receives
> > only a single argument.
> >
> > Provide a new/similar macro RTE_LOG_LINE_PREFIX that accepts the prefix
> > format and arguments as separate parameters allowing them to be expanded
> > at the correct locations inside of RTE_FMT() allowing the rest of the
> > non-prefix format string and arguments to be collapsed to the argument
> > pack which can be directly forwarded with __VA_ARGS__ avoiding the need
> > for conditional comma removal.
> >
> > I've done my best to manually check expansions (preprocessed) and compiled
> > printf of the logs to validate correct output.
> >
> > note: due to drastic change in series i have not carried any series acks
> >   forward.
> >
> > v3:
> >   * remove leading _ from RTE_LOG_COMMA the macro is not internal
> >   * add doxygen comment for existing RTE_LOG{,DP}_LINE function-like
> > macros, based on RTE_LOG{,DP} comments.
> >   * add doxygen comment for new RTE_LOG{,DP}_LINE_PREFIX function-like
> > macros, based on RTE_LOG{,DP} comments.
> >   * merge 2 vhost patches into a single patch (mistake in previous
> > submission)
> 
> I find this new helper less tricky to use and easier to read than the
> RTE_FMT_* stuff that gets copy/pasted everywhere.
> The changes are quite mechanical, so even though we are past -rc1, +1
> for me on the series.
> 
> Can we finish the job and convert remaining macros that prefix messages in 
> lib/?

I didn't realize I missed any. do you have a list or a regex that points
me at them.  I was just searching for use of args... 

Happy to make the conversion of the others in the next rev.

ty

> 
> 
> -- 
> David Marchand

[PATCH v2 2/3] lpm: use rte macro instead of GCC attribute

[Tyler Retzlaff]

Use newly added __rte_pure macro from rte_common.h instead of directly
using __attribute__((pure)).

Signed-off-by: Tyler Retzlaff 
Reviewed-by: Morten Brørup 
---
 lib/lpm/rte_lpm.c  | 4 ++--
 lib/lpm/rte_lpm6.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/lpm/rte_lpm.c b/lib/lpm/rte_lpm.c
index 9633d63..a5c9e7c 100644
--- a/lib/lpm/rte_lpm.c
+++ b/lib/lpm/rte_lpm.c
@@ -85,7 +85,7 @@ struct __rte_lpm {
  * depth  (IN) : range = 1 - 32
  * mask   (OUT): 32bit mask
  */
-static uint32_t __attribute__((pure))
+static uint32_t __rte_pure
 depth_to_mask(uint8_t depth)
 {
VERIFY_DEPTH(depth);
@@ -99,7 +99,7 @@ static uint32_t __attribute__((pure))
 /*
  * Converts given depth value to its corresponding range value.
  */
-static uint32_t __attribute__((pure))
+static uint32_t __rte_pure
 depth_to_range(uint8_t depth)
 {
VERIFY_DEPTH(depth);
diff --git a/lib/lpm/rte_lpm6.c b/lib/lpm/rte_lpm6.c
index 271bc48..2bdd540 100644
--- a/lib/lpm/rte_lpm6.c
+++ b/lib/lpm/rte_lpm6.c
@@ -1127,7 +1127,7 @@ struct rte_lpm6 *
  * Convert a depth to a one byte long mask
  *   Example: 4 will be converted to 0xF0
  */
-static uint8_t __attribute__((pure))
+static uint8_t __rte_pure
 depth_to_mask_1b(uint8_t depth)
 {
/* To calculate a mask start with a 1 on the left hand side and right
-- 
1.8.3.1