Re: [PATCH] tap: fix build of tap_bpf_program

[Ferruh Yigit]

On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> On Wed, 19 Jul 2023 11:03:36 +0100
> Ferruh Yigit  wrote:
> 
>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
>>> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:  
 The tap_bpf_program.c is not built as part of normal DPDK
 EAL environment. It is intended to be built standalone
 and does not use rte_common.h.

 This reverts the related change from
 commit ef5baf3486e0 ("replace packed attributes")

 Note: this patch will cause expected warnings from checkpatch
 because the code involved is not used directly in DPDK environment.

 Signed-off-by: Stephen Hemminger 
  
>>>
>>> Agree, this seems done by mistake as part of batch update,
>>>
>>> Acked-by: Ferruh Yigit 
>>>
>>>
>>> But I can't update the bpf file at all, if I am not missing something I  
>>
>> * I can't *compile* the bpf file ...
>>
>>> am not sure if we should get just this update or have a patch/patchset
>>> that fixes the build.
>>>
>>> @Ophir, how the bpf file is compiled? And did you test it recently?
>>>
>>> I am using command from the documentation:
>>> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
>>> -filetype=obj -o tap_bpf_program.o`
> 
> It looks like this won't work because it was expecting to be able
> to find header files from older version of iproute2.  These are not
> distributed, and the change to support libbpf in iproute2 makes the
> current versions not work.
> 
> As a stopgap, will look back in history and see what version of header
> files will at least get a working build.
> 
> From there, need to replace how the conversion of .o to array works.
> Would prefer to use dlopen() to read the ELF file rather than expecting
> developers to hack together their own tools.
> 
> Not sure how much effort is really needed here. This is only being
> used for the case of rte_flow with multiq RSS. Probably, no one ever
> used it.
>

Should we remove the file, instead of fixing '__rte_packed'?

Re: [PATCH v2] usertools: add tool to generate balanced rss traffic flows

[Robin Jarry]

Hi Thomas,

Thomas Monjalon, Jul 20, 2023 at 06:50:
> Applied, thanks.

Thanks! I think there's a byte order issue with the i40e rss key. If
I submit a fix today, can it make it for GA?

> You have great skills for user tools in Python,
> and this file as other ones have no official maintainer:
>   usertools/dpdk-devbind.py
>   usertools/dpdk-hugepages.py
>   usertools/dpdk-rss-flows.py
>
> Would like to take care of them?

Thanks for the offer. I'll gladly adopt anything python related in DPDK.

Cheers,

Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle

[Ferruh Yigit]

On 5/18/2023 2:21 PM, jer...@marvell.com wrote:
> From: Jerin Jacob 
> 
> Based on techboard meeting[1] action item, defining the process for a
> new library approval in principle.
> 
> [1]
> https://mails.dpdk.org/archives/dev/2023-January/260035.html
> 
> Signed-off-by: Jerin Jacob 
> ---
> RFC..v1:
> - Fix the review comments by Konstantin, Keven, Thomas at
> http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jer...@marvell.com/
> 
>  doc/guides/contributing/index.rst   |  1 +
>  doc/guides/contributing/new_library.rst | 48 +
>  2 files changed, 49 insertions(+)
>  create mode 100644 doc/guides/contributing/new_library.rst
> 
> diff --git a/doc/guides/contributing/index.rst 
> b/doc/guides/contributing/index.rst
> index 7a9e6b368e..ef627329f1 100644
> --- a/doc/guides/contributing/index.rst
> +++ b/doc/guides/contributing/index.rst
> @@ -18,3 +18,4 @@ Contributor's Guidelines
>  vulnerability
>  stable
>  cheatsheet
> +new_library
> diff --git a/doc/guides/contributing/new_library.rst 
> b/doc/guides/contributing/new_library.rst
> new file mode 100644
> index 00..7dde8cbe64
> --- /dev/null
> +++ b/doc/guides/contributing/new_library.rst
> @@ -0,0 +1,48 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +   Copyright(c) 2023 Marvell.
> +
> +Process for new library approval in principle
> +=
> +
> +Rationale
> +-
> +
> +Adding a new library to DPDK with proper RFC and then full patch-sets is 
> significant work.
> +In order to save effort, developers will get an early approval in principle, 
> or early feedback in
> +case the library is not suitable for various reasons.
> +
> +Process
> +---
> +
> +#. When a contributor would like to add a new library to DPDK code base, the 
> contributor must send
> +   the following items to DPDK mailing list for technical board 
> approval-in-principle.
> +
> +   * Purpose of the library.
> +   * Scope of work: outline the various additional tasks planned for this 
> library, such as
> + developing new test applications, adding new drivers, and updating 
> existing applications.
> +   * Expected usage models of the library.
> +   * Any licensing constraints.
> +   * Justification for adding to DPDK.
> +   * Any other implementations of the same functionality in other 
> libraries/projects and how this
> + version differs.
> +   * Public API specification header file as RFC.
> +
> +   * Optional and good to have.
> +   * Technical board may additionally request this collateral if needed 
> to get more clarity
> + on scope and purpose.
> +   * Any new library dependencies to DPDK.
> +
> +#. Technical board to schedule discussion on this in upcoming technical 
> board meeting along with
> +   author. Based on the technical board schedule and/or author availability, 
> technical board may
> +   need a maximum of **five** technical board meeting slots.
> +
> +#. Based on mailing list and technical board meeting discussions, technical 
> board to vote and share
> +   the decision in the mailing list. The decision outcome can be any of the 
> following.
> +
> +   * Approved in principal
> +   * Not approved
> +   * Further information needed
> +
> +#. Once technical board approves the library in principle, it is safe to 
> start working on the
> +   implementation. However, the patches will need to meet the usual quality 
> criteria in order to be
> +   effectively accepted.


Looks reasonable to me, and it is good to start to document the process
anyway, we can tweak it later if required, hence:

Acked-by: Ferruh Yigit 

[PATCH] usertools/rss: fix byte order of the default i40e key

[Robin Jarry]

The key is represented as uint32 words in the driver source code but it
is actually stored as little endian in the NIC registers. Fix the byte
ordering in the python script.

Fixes: 106a231ae528 ("usertools: add tool to generate balanced rss traffic 
flows")

Reported-by: Abhiram R N 
Signed-off-by: Robin Jarry 
---
 usertools/dpdk-rss-flows.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/usertools/dpdk-rss-flows.py b/usertools/dpdk-rss-flows.py
index 4cdc524ddcb4..73821eb47125 100755
--- a/usertools/dpdk-rss-flows.py
+++ b/usertools/dpdk-rss-flows.py
@@ -179,13 +179,13 @@ def balanced_traffic(
 # i40e is the only driver that takes 52 bytes keys
 RSS_KEY_I40E = bytes(
 (
-0x6b, 0x79, 0x39, 0x44, 0x23, 0x50, 0x4c, 0xb5,
-0x5b, 0xea, 0x75, 0xb6, 0x30, 0x9f, 0x4f, 0x12,
-0x3d, 0xc0, 0xa2, 0xb8, 0x02, 0x4d, 0xdc, 0xdf,
-0x33, 0x9b, 0x8c, 0xa0, 0x4c, 0x4a, 0xf6, 0x4a,
-0x34, 0xfa, 0xc6, 0x05, 0x55, 0xd8, 0x58, 0x39,
-0x3a, 0x58, 0x99, 0x7d, 0x2e, 0xc9, 0x38, 0xe1,
-0x66, 0x03, 0x15, 0x81,
+0x44, 0x39, 0x79, 0x6b, 0xb5, 0x4c, 0x50, 0x23,
+0xb6, 0x75, 0xea, 0x5b, 0x12, 0x4f, 0x9f, 0x30,
+0xb8, 0xa2, 0xc0, 0x3d, 0xdf, 0xdc, 0x4d, 0x02,
+0xa0, 0x8c, 0x9b, 0x33, 0x4a, 0xf6, 0x4a, 0x4c,
+0x05, 0xc6, 0xfa, 0x34, 0x39, 0x58, 0xd8, 0x55,
+0x7d, 0x99, 0x58, 0x3a, 0xe1, 0x38, 0xc9, 0x2e,
+0x81, 0x15, 0x03, 0x66,
 )
 )
 # fmt: on
-- 
2.41.0

Re: [PATCH] doc: postpone deprecation of pipeline legacy API

[Radu Nicolau]

On 19-Jul-23 4:12 PM, Cristian Dumitrescu wrote:

Postpone the deprecation of the legacy pipeline, table and port
library API and gradual stabilization of the new API.

Signed-off-by: Cristian Dumitrescu 
---


Acked-by: Radu Nicolau 

Re: [PATCH v3] build: announce requirement for C11

[Bruce Richardson]

On Wed, May 17, 2023 at 06:34:00PM +0100, Bruce Richardson wrote:
> Add a deprecation notice informing users that we will require a C11
> compiler from 23.11 release onwards. This requirement was agreed by
> technical board to enable use of newer C language features, e.g.
> standard atomics. [1]
> 
> [1] 
> http://inbox.dpdk.org/dev/dbapr08mb58148cec3e1454e8848a938998...@dbapr08mb5814.eurprd08.prod.outlook.com/
> 
> Signed-off-by: Bruce Richardson 
> Acked-by: Tyler Retzlaff 
> 
> ---
> 
> V3:
> - add additional detail following discussion on-list
> 
> V2:
> - add requirement for stdatomics
> - fix sphinx formatting
> ---
>  doc/guides/rel_notes/deprecation.rst | 18 ++
>  1 file changed, 18 insertions(+)
> 
Ping for additional review/acks and merge.

This deprecation notice really needs to go into 23.07 to allow the C11
requirement to be met in 23.11!

Thanks,
/Bruce

[PATCH] net/ngbe: fix RSS offload capability

[Jiawen Wu]

Fix missed RTE_ETH_RX_OFFLOAD_RSS_HASH flag in ngbe_get_rx_port_offloads().

Fixes: 0779d7f61991 ("net/ngbe: support RSS hash")
Cc: sta...@dpdk.org

Signed-off-by: Jiawen Wu 
---
 drivers/net/ngbe/ngbe_rxtx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ngbe/ngbe_rxtx.c b/drivers/net/ngbe/ngbe_rxtx.c
index 0c678e1557..f31906cc2f 100644
--- a/drivers/net/ngbe/ngbe_rxtx.c
+++ b/drivers/net/ngbe/ngbe_rxtx.c
@@ -2191,6 +2191,7 @@ ngbe_get_rx_port_offloads(struct rte_eth_dev *dev)
   RTE_ETH_RX_OFFLOAD_TCP_CKSUM   |
   RTE_ETH_RX_OFFLOAD_KEEP_CRC|
   RTE_ETH_RX_OFFLOAD_VLAN_FILTER |
+  RTE_ETH_RX_OFFLOAD_RSS_HASH|
   RTE_ETH_RX_OFFLOAD_SCATTER;
 
if (hw->is_pf)
-- 
2.27.0

Re: [PATCH] tap: fix build of tap_bpf_program

[Ferruh Yigit]

On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
>> On Wed, 19 Jul 2023 11:03:36 +0100
>> Ferruh Yigit  wrote:
>>
>>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
 On 7/17/2023 8:15 PM, Stephen Hemminger wrote:  
> The tap_bpf_program.c is not built as part of normal DPDK
> EAL environment. It is intended to be built standalone
> and does not use rte_common.h.
>
> This reverts the related change from
> commit ef5baf3486e0 ("replace packed attributes")
>
> Note: this patch will cause expected warnings from checkpatch
> because the code involved is not used directly in DPDK environment.
>
> Signed-off-by: Stephen Hemminger 
>  

 Agree, this seems done by mistake as part of batch update,

 Acked-by: Ferruh Yigit 


 But I can't update the bpf file at all, if I am not missing something I  
>>>
>>> * I can't *compile* the bpf file ...
>>>
 am not sure if we should get just this update or have a patch/patchset
 that fixes the build.

 @Ophir, how the bpf file is compiled? And did you test it recently?

 I am using command from the documentation:
 `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
 -filetype=obj -o tap_bpf_program.o`
>>
>> It looks like this won't work because it was expecting to be able
>> to find header files from older version of iproute2.  These are not
>> distributed, and the change to support libbpf in iproute2 makes the
>> current versions not work.
>>
>> As a stopgap, will look back in history and see what version of header
>> files will at least get a working build.
>>
>> From there, need to replace how the conversion of .o to array works.
>> Would prefer to use dlopen() to read the ELF file rather than expecting
>> developers to hack together their own tools.
>>
>> Not sure how much effort is really needed here. This is only being
>> used for the case of rte_flow with multiq RSS. Probably, no one ever
>> used it.
>>
> 
> Should we remove the file, instead of fixing '__rte_packed'?
> 

+Long, and af_xdp maintainers,

@Long, do you know if this bfp code is still in use somewhere, if so is
the user interested in fixing/maintaining the code?


@Ciara, @Qi, do you see any benefit to keep/extend this kind of bfp file
usage? Do you think is this something to invest more?

Re: [PATCH v11 1/1] dts: add smoke tests

[Juraj Linkeš]

All good now from my side.

Reviewed-by: Juraj Linkeš 

On Wed, Jul 19, 2023 at 10:18 PM  wrote:
>
> From: Jeremy Spewock 
>
> Adds a new test suite for running smoke tests that verify general
> configuration aspects of the system under test. If any of these tests
> fail, the DTS execution terminates as part of a "fail-fast" model.
>
> Signed-off-by: Jeremy Spewock 

[PATCH v19 5/6] memarea: support dump API

[Chengwen Feng]

This patch supports rte_memarea_dump() API which could be used for
debug.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
Acked-by: Anatoly Burakov 
---
 doc/guides/prog_guide/memarea_lib.rst |   3 +
 lib/memarea/rte_memarea.c | 100 ++
 lib/memarea/rte_memarea.h |  21 ++
 lib/memarea/version.map   |   1 +
 4 files changed, 125 insertions(+)

diff --git a/doc/guides/prog_guide/memarea_lib.rst 
b/doc/guides/prog_guide/memarea_lib.rst
index 157baf3c7e..ef22294664 100644
--- a/doc/guides/prog_guide/memarea_lib.rst
+++ b/doc/guides/prog_guide/memarea_lib.rst
@@ -39,6 +39,9 @@ the memarea.
 The ``rte_memarea_free()`` function is used to free one memory object which
 allocated by ``rte_memarea_alloc()``.
 
++The ``rte_memarea_dump()`` function is used to dump the internal information
++of a memarea.
+
 Debug Mode
 --
 
diff --git a/lib/memarea/rte_memarea.c b/lib/memarea/rte_memarea.c
index 7a35c875a7..d5d9a46736 100644
--- a/lib/memarea/rte_memarea.c
+++ b/lib/memarea/rte_memarea.c
@@ -361,3 +361,103 @@ rte_memarea_free(struct rte_memarea *ma, void *ptr)
 
memarea_unlock(ma);
 }
+
+static const char *
+memarea_source_name(enum rte_memarea_source source)
+{
+   if (source == RTE_MEMAREA_SOURCE_HEAP)
+   return "heap";
+   else if (source == RTE_MEMAREA_SOURCE_LIBC)
+   return "libc";
+   else if (source == RTE_MEMAREA_SOURCE_MEMAREA)
+   return "memarea";
+   else
+   return "unknown";
+}
+
+static const char *
+memarea_alg_name(enum rte_memarea_algorithm alg)
+{
+   if (alg == RTE_MEMAREA_ALGORITHM_NEXTFIT)
+   return "nextfit";
+   else
+   return "unknown";
+}
+
+static void
+memarea_dump_objects_brief(struct rte_memarea *ma, FILE *f)
+{
+   uint32_t total_objs = 0, total_avail_objs = 0;
+   struct memarea_objhdr *hdr;
+   size_t total_avail_sz = 0;
+
+   TAILQ_FOREACH(hdr, &ma->obj_list, obj_next) {
+   if (hdr == ma->guard_hdr)
+   break;
+   memarea_check_cookie(ma, hdr, COOKIE_EXPECT_STATUS_VALID);
+   total_objs++;
+   if (!MEMAREA_OBJECT_IS_ALLOCATED(hdr)) {
+   total_avail_objs++;
+   total_avail_sz += MEMAREA_OBJECT_GET_SIZE(hdr);
+   }
+   }
+   fprintf(f, "  total-objects: %u\n", total_objs);
+   fprintf(f, "  total-avail-objects: %u\n", total_avail_objs);
+   fprintf(f, "  total-avail-objects-size: 0x%zx\n", total_avail_sz);
+}
+
+static void
+memarea_dump_objects_detail(struct rte_memarea *ma, FILE *f)
+{
+   struct memarea_objhdr *hdr;
+   size_t offset;
+   void *ptr;
+
+   fprintf(f, "  objects:\n");
+   TAILQ_FOREACH(hdr, &ma->obj_list, obj_next) {
+   if (hdr == ma->guard_hdr)
+   break;
+   memarea_check_cookie(ma, hdr, COOKIE_EXPECT_STATUS_VALID);
+   ptr = RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr));
+   offset = RTE_PTR_DIFF(ptr, ma->area_base);
+#ifdef RTE_LIBRTE_MEMAREA_DEBUG
+   fprintf(f, "%p off: 0x%zx size: 0x%zx %s\n",
+   ptr, offset, MEMAREA_OBJECT_GET_SIZE(hdr),
+   MEMAREA_OBJECT_IS_ALLOCATED(hdr) ? "allocated" : "");
+#else
+   fprintf(f, "off: 0x%zx size: 0x%zx %s\n",
+   offset, MEMAREA_OBJECT_GET_SIZE(hdr),
+   MEMAREA_OBJECT_IS_ALLOCATED(hdr) ? "allocated" : "");
+#endif
+   }
+}
+
+int
+rte_memarea_dump(struct rte_memarea *ma, FILE *f, bool dump_all)
+{
+   if (ma == NULL || f == NULL) {
+   rte_errno = EINVAL;
+   return -1;
+   }
+
+   memarea_lock(ma);
+   fprintf(f, "memarea name: %s\n", ma->init.name);
+   fprintf(f, "  source: %s\n", memarea_source_name(ma->init.source));
+   if (ma->init.source == RTE_MEMAREA_SOURCE_HEAP)
+   fprintf(f, "  heap-numa-socket: %d\n", ma->init.heap.socket_id);
+   else if (ma->init.source == RTE_MEMAREA_SOURCE_MEMAREA)
+   fprintf(f, "  source-memarea: %s\n", 
ma->init.ma.src->init.name);
+   fprintf(f, "  algorithm: %s\n", memarea_alg_name(ma->init.alg));
+   fprintf(f, "  total-size: 0x%zx\n", ma->init.total_sz);
+   fprintf(f, "  mt-safe: %s\n", ma->init.mt_safe ? "yes" : "no");
+#ifdef RTE_LIBRTE_MEMAREA_DEBUG
+   fprintf(f, "  area-base: %p\n", ma->area_base);
+   fprintf(f, "  guard-header: %p\n", ma->guard_hdr);
+#endif
+   memarea_dump_objects_brief(ma, f);
+   if (dump_all)
+   memarea_dump_objects_detail(ma, f);
+   memarea_unlock(ma);
+
+   return 0;
+}
diff --git a/lib/memarea/rte_memarea.h b/lib/memarea/rte_memarea.h
index bb1bd5bae5..fa57f6c455 100644
--- a/lib/memarea/rte_memarea.h
+++ b/lib/memarea/rte_memarea.h
@@ -180,6 +180,27 @@ void *

[PATCH v19 3/6] memarea: support alloc and free API

[Chengwen Feng]

This patch supports rte_memarea_alloc() and rte_memarea_free() API.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
Acked-by: Anatoly Burakov 
---
 doc/guides/prog_guide/memarea_lib.rst |   6 +
 lib/memarea/memarea_private.h |  10 ++
 lib/memarea/rte_memarea.c | 159 ++
 lib/memarea/rte_memarea.h |  46 
 lib/memarea/version.map   |   2 +
 5 files changed, 223 insertions(+)

diff --git a/doc/guides/prog_guide/memarea_lib.rst 
b/doc/guides/prog_guide/memarea_lib.rst
index bf19090294..157baf3c7e 100644
--- a/doc/guides/prog_guide/memarea_lib.rst
+++ b/doc/guides/prog_guide/memarea_lib.rst
@@ -33,6 +33,12 @@ returns the pointer to the created memarea or ``NULL`` if 
the creation failed.
 
 The ``rte_memarea_destroy()`` function is used to destroy a memarea.
 
+The ``rte_memarea_alloc()`` function is used to alloc one memory object from
+the memarea.
+
+The ``rte_memarea_free()`` function is used to free one memory object which
+allocated by ``rte_memarea_alloc()``.
+
 Debug Mode
 --
 
diff --git a/lib/memarea/memarea_private.h b/lib/memarea/memarea_private.h
index fd485bb7e7..ab6253294e 100644
--- a/lib/memarea/memarea_private.h
+++ b/lib/memarea/memarea_private.h
@@ -52,10 +52,20 @@ enum {
 #define MEMAREA_OBJECT_GET_SIZE(hdr) \
((uintptr_t)TAILQ_NEXT((hdr), obj_next) - (uintptr_t)(hdr) - \
 sizeof(struct memarea_objhdr) - sizeof(struct memarea_objtlr))
+#define MEMAREA_SPLIT_OBJECT_MIN_SIZE \
+   (sizeof(struct memarea_objhdr) + MEMAREA_OBJECT_SIZE_ALIGN + \
+sizeof(struct memarea_objtlr))
+#define MEMAREA_SPLIT_OBJECT_GET_HEADER(hdr, alloc_sz) \
+   RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr) + alloc_sz + \
+   sizeof(struct memarea_objtlr))
 #else
 #define MEMAREA_OBJECT_GET_SIZE(hdr) \
((uintptr_t)TAILQ_NEXT((hdr), obj_next) - (uintptr_t)(hdr) - \
 sizeof(struct memarea_objhdr))
+#define MEMAREA_SPLIT_OBJECT_MIN_SIZE \
+   (sizeof(struct memarea_objhdr) + MEMAREA_OBJECT_SIZE_ALIGN)
+#define MEMAREA_SPLIT_OBJECT_GET_HEADER(hdr, alloc_sz) \
+   RTE_PTR_ADD(hdr, sizeof(struct memarea_objhdr) + alloc_sz)
 #endif
 
 struct memarea_objhdr {
diff --git a/lib/memarea/rte_memarea.c b/lib/memarea/rte_memarea.c
index 5d806ca363..7a35c875a7 100644
--- a/lib/memarea/rte_memarea.c
+++ b/lib/memarea/rte_memarea.c
@@ -2,8 +2,10 @@
  * Copyright(c) 2023 HiSilicon Limited
  */
 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -90,6 +92,8 @@ memarea_alloc_area(const struct rte_memarea_param *init)
init->heap.socket_id);
else if (init->source == RTE_MEMAREA_SOURCE_LIBC)
ptr = memarea_alloc_from_libc(init->total_sz);
+   else if (init->source == RTE_MEMAREA_SOURCE_MEMAREA)
+   ptr = rte_memarea_alloc(init->ma.src, init->total_sz);
 
return ptr;
 }
@@ -101,6 +105,8 @@ memarea_free_area(const struct rte_memarea_param *init, 
void *ptr)
rte_free(ptr);
else if (init->source == RTE_MEMAREA_SOURCE_LIBC)
free(ptr);
+   else if (init->source == RTE_MEMAREA_SOURCE_MEMAREA)
+   rte_memarea_free(init->ma.src, ptr);
 }
 
 static inline void
@@ -202,3 +208,156 @@ rte_memarea_destroy(struct rte_memarea *ma)
memarea_free_area(&ma->init, ma->area_base);
rte_free(ma);
 }
+
+static inline void
+memarea_lock(struct rte_memarea *ma)
+{
+   if (ma->init.mt_safe)
+   rte_spinlock_lock(&ma->lock);
+}
+
+static inline void
+memarea_unlock(struct rte_memarea *ma)
+{
+   if (ma->init.mt_safe)
+   rte_spinlock_unlock(&ma->lock);
+}
+
+static inline void
+memarea_check_cookie(const struct rte_memarea *ma, const struct memarea_objhdr 
*hdr, int status)
+{
+#ifdef RTE_LIBRTE_MEMAREA_DEBUG
+   static const char *const str[] = { "PASS", "FAILED" };
+   struct memarea_objtlr *tlr;
+   bool hdr_fail, tlr_fail;
+
+   if (hdr == ma->guard_hdr)
+   return;
+
+   tlr = RTE_PTR_SUB(TAILQ_NEXT(hdr, obj_next), sizeof(struct 
memarea_objtlr));
+   hdr_fail = (status == COOKIE_EXPECT_STATUS_AVAILABLE &&
+   hdr->cookie != MEMAREA_OBJECT_HEADER_AVAILABLE_COOKIE) ||
+  (status == COOKIE_EXPECT_STATUS_ALLOCATED &&
+   hdr->cookie != MEMAREA_OBJECT_HEADER_ALLOCATED_COOKIE) ||
+  (status == COOKIE_EXPECT_STATUS_VALID &&
+   (hdr->cookie != MEMAREA_OBJECT_HEADER_AVAILABLE_COOKIE &&
+hdr->cookie != MEMAREA_OBJECT_HEADER_ALLOCATED_COOKIE));
+   tlr_fail = (tlr->cookie != MEMAREA_OBJECT_TRAILER_COOKIE);
+   if (!hdr_fail && !tlr_fail)
+   return;
+
+   rte_panic("MEMAREA: %s check cookies failed! addr-%p header-cookie<0x%" 
PRIx64 " %s> trai

[PATCH v19 2/6] test/memarea: support memarea test

[Chengwen Feng]

This patch supports memarea test of rte_memarea_create() and
rte_memarea_destroy() API.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
Acked-by: Anatoly Burakov 
---
 MAINTAINERS |   1 +
 app/test/meson.build|   2 +
 app/test/test_memarea.c | 166 
 3 files changed, 169 insertions(+)
 create mode 100644 app/test/test_memarea.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bd9cad7ee3..4ee43a9964 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1617,6 +1617,7 @@ Memarea - EXPERIMENTAL
 M: Chengwen Feng 
 F: lib/memarea
 F: doc/guides/prog_guide/memarea_lib.rst
+F: app/test/test_memarea*
 
 Membership - EXPERIMENTAL
 M: Yipeng Wang 
diff --git a/app/test/meson.build b/app/test/meson.build
index b89cf0368f..0d9701d8c6 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -83,6 +83,7 @@ test_sources = files(
 'test_malloc.c',
 'test_malloc_perf.c',
 'test_mbuf.c',
+'test_memarea.c',
 'test_member.c',
 'test_member_perf.c',
 'test_memcpy.c',
@@ -201,6 +202,7 @@ fast_tests = [
 ['malloc_autotest', false, true],
 ['mbuf_autotest', false, true],
 ['mcslock_autotest', false, true],
+['memarea_autotest', true, true],
 ['memcpy_autotest', true, true],
 ['memory_autotest', false, true],
 ['mempool_autotest', false, true],
diff --git a/app/test/test_memarea.c b/app/test/test_memarea.c
new file mode 100644
index 00..6078c93a16
--- /dev/null
+++ b/app/test/test_memarea.c
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 HiSilicon Limited
+ */
+
+#ifdef RTE_EXEC_ENV_WINDOWS
+
+#include 
+
+#include "test.h"
+
+static int
+test_memarea(void)
+{
+   printf("memarea not supported on Windows, skipping test\n");
+   return TEST_SKIPPED;
+}
+
+#else
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+#define MEMAREA_TEST_DEFAULT_SIZE  0x1000
+
+static void
+test_memarea_init_param(struct rte_memarea_param *init)
+{
+   memset(init, 0, sizeof(struct rte_memarea_param));
+   sprintf(init->name, "%s", "autotest");
+   init->source = RTE_MEMAREA_SOURCE_LIBC;
+   init->total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+   init->mt_safe = 1;
+}
+
+static int
+test_memarea_create_bad_param(void)
+{
+   struct rte_memarea_param init;
+   struct rte_memarea *ma;
+
+   /* test for NULL */
+   rte_errno = 0;
+   ma = rte_memarea_create(NULL);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for invalid name */
+   rte_errno = 0;
+   memset(&init, 0, sizeof(init));
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+   rte_errno = 0;
+   memset(&init.name, 1, sizeof(init.name));
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for invalid source */
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_MEMAREA + 1;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for total_sz */
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.total_sz = 0;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for memarea NULL */
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_MEMAREA;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for algorithm invalid */
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.alg = RTE_MEMAREA_ALGORITHM_NEXTFIT + 1;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for reserved field */
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.reserved_bits = 1;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+   rte_errno = 0;
+   test_memarea_init_param(&init);
+   init.reserved_64s[0] = 1;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma == NULL, "Memarea creation expect fail");
+   TEST_ASSERT(rte_errno == EINV

[PATCH v19 1/6] memarea: introduce memarea library

[Chengwen Feng]

The memarea library is an allocator of variable-size object which based
on a memory region.

This patch provides rte_memarea_create() and rte_memarea_destroy() API.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
Acked-by: Anatoly Burakov 
---
 MAINTAINERS|   5 +
 doc/api/doxy-api-index.md  |   3 +-
 doc/api/doxy-api.conf.in   |   1 +
 doc/guides/prog_guide/index.rst|   1 +
 doc/guides/prog_guide/memarea_lib.rst  |  48 ++
 doc/guides/rel_notes/release_23_07.rst |   6 +
 lib/memarea/memarea_private.h  | 116 ++
 lib/memarea/meson.build|  18 +++
 lib/memarea/rte_memarea.c  | 204 +
 lib/memarea/rte_memarea.h  | 141 +
 lib/memarea/version.map|  12 ++
 lib/meson.build|   1 +
 12 files changed, 555 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/memarea_lib.rst
 create mode 100644 lib/memarea/memarea_private.h
 create mode 100644 lib/memarea/meson.build
 create mode 100644 lib/memarea/rte_memarea.c
 create mode 100644 lib/memarea/rte_memarea.h
 create mode 100644 lib/memarea/version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 18bc05fccd..bd9cad7ee3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1613,6 +1613,11 @@ F: app/test/test_lpm*
 F: app/test/test_func_reentrancy.c
 F: app/test/test_xmmt_ops.h
 
+Memarea - EXPERIMENTAL
+M: Chengwen Feng 
+F: lib/memarea
+F: doc/guides/prog_guide/memarea_lib.rst
+
 Membership - EXPERIMENTAL
 M: Yipeng Wang 
 M: Sameh Gobriel 
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 3bc8778981..5c32913f92 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -65,7 +65,8 @@ The public API headers are grouped by topics:
   [memzone](@ref rte_memzone.h),
   [mempool](@ref rte_mempool.h),
   [malloc](@ref rte_malloc.h),
-  [memcpy](@ref rte_memcpy.h)
+  [memcpy](@ref rte_memcpy.h),
+  [memarea](@ref rte_memarea.h)
 
 - **timers**:
   [cycles](@ref rte_cycles.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 1a4210b948..1f35d8483e 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -54,6 +54,7 @@ INPUT   = @TOPDIR@/doc/api/doxy-api-index.md \
   @TOPDIR@/lib/latencystats \
   @TOPDIR@/lib/lpm \
   @TOPDIR@/lib/mbuf \
+  @TOPDIR@/lib/memarea \
   @TOPDIR@/lib/member \
   @TOPDIR@/lib/mempool \
   @TOPDIR@/lib/meter \
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index d89cd3edb6..aa8eebe256 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -38,6 +38,7 @@ Programmer's Guide
 hash_lib
 toeplitz_hash_lib
 efd_lib
+memarea_lib
 member_lib
 lpm_lib
 lpm6_lib
diff --git a/doc/guides/prog_guide/memarea_lib.rst 
b/doc/guides/prog_guide/memarea_lib.rst
new file mode 100644
index 00..bf19090294
--- /dev/null
+++ b/doc/guides/prog_guide/memarea_lib.rst
@@ -0,0 +1,48 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 HiSilicon Limited
+
+Memarea Library
+===
+
+Introduction
+
+
+The memarea library provides an allocator of variable-size objects, it is
+oriented towards the application layer, providing 'region-based memory
+management' function [1].
+
+The main features are as follows:
+
+* The memory region can be initialized from the following memory sources:
+
+  - HEAP: e.g. invoke ``rte_malloc_socket``.
+
+  - LIBC: e.g. invoke posix_memalign.
+
+  - Another memarea: it can be allocated from another memarea.
+
+* It supports MT-safe as long as it's specified at creation time.
+
+* The address returned by the allocator is align to 8B.
+
+Library API Overview
+
+
+The ``rte_memarea_create()`` function is used to create a memarea, the function
+returns the pointer to the created memarea or ``NULL`` if the creation failed.
+
+The ``rte_memarea_destroy()`` function is used to destroy a memarea.
+
+Debug Mode
+--
+
+In debug mode, cookies are added at the beginning and end of objects, it will
+help debugging buffer overflows.
+
+Debug mode is disabled by default, but can be enabled by setting
+``RTE_LIBRTE_MEMAREA_DEBUG`` in ``config/rte_config.h``.
+
+Reference
+-
+
+[1] https://en.wikipedia.org/wiki/Region-based_memory_management
diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index 6a1c45162b..2751d70740 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -222,6 +222,12 @@ New Features
 
   See the :doc:`../tools/dmaperf` for more details.
 
+* **Added memarea library.**
+
+  The memarea library is 

[PATCH v19 6/6] test/memarea: support dump API test

[Chengwen Feng]

This patch supports rte_memarea_dump() API test.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
---
 app/test/test_memarea.c | 52 +
 1 file changed, 52 insertions(+)

diff --git a/app/test/test_memarea.c b/app/test/test_memarea.c
index 805fb82d08..e793022aa2 100644
--- a/app/test/test_memarea.c
+++ b/app/test/test_memarea.c
@@ -353,6 +353,57 @@ test_memarea_alloc_free(void)
 
TEST_ASSERT(rte_errno == 0, "Expected Zero");
 
+   fprintf(stderr, "There should have no allocated object.\n");
+   rte_memarea_dump(ma, stderr, true);
+
+   rte_memarea_destroy(ma);
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_memarea_dump(void)
+{
+   struct rte_memarea_param init;
+   uint32_t alloced_num = 0;
+   struct rte_memarea *ma;
+   void *ptr;
+   int ret;
+
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_LIBC;
+   init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma != NULL, "Memarea creation failed");
+
+   /* test for invalid parameters */
+   rte_errno = 0;
+   ret = rte_memarea_dump(NULL, stderr, false);
+   TEST_ASSERT(ret == -1, "Expected -1");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+   rte_errno = 0;
+   ret = rte_memarea_dump(ma, NULL, false);
+   TEST_ASSERT(ret == -1, "Expected -1");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for dump */
+   ptr = rte_memarea_alloc(ma, 1);
+   TEST_ASSERT(ptr != NULL, "Memarea allocation failed");
+   alloced_num++;
+   ptr = rte_memarea_alloc(ma, 1);
+   TEST_ASSERT(ptr != NULL, "Memarea allocation failed");
+   alloced_num++;
+   ptr = rte_memarea_alloc(ma, 1);
+   TEST_ASSERT(ptr != NULL, "Memarea allocation failed");
+   alloced_num++;
+   ptr = rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
+   TEST_ASSERT(ptr == NULL, "Memarea allocation expect fail");
+   ptr = rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
+   TEST_ASSERT(ptr == NULL, "Memarea allocation expect fail");
+   fprintf(stderr, "There should have %u allocated object.\n", 
alloced_num);
+   ret = rte_memarea_dump(ma, stderr, true);
+   TEST_ASSERT(ret == 0, "Memarea dump failed");
+
rte_memarea_destroy(ma);
 
return TEST_SUCCESS;
@@ -370,6 +421,7 @@ static struct unit_test_suite memarea_test_suite  = {
TEST_CASE(test_memarea_alloc_fail),
TEST_CASE(test_memarea_free_fail),
TEST_CASE(test_memarea_alloc_free),
+   TEST_CASE(test_memarea_dump),
 
TEST_CASES_END() /**< NULL terminate unit test array */
}
-- 
2.17.1

[PATCH v19 0/6] introduce memarea library

[Chengwen Feng]

The memarea library is an allocator of variable-size object which based
on a memory region. The main features are as follows:

- The memory region can be initialized from the following memory
  sources:
  1. HEAP: e.g. invoke rte_malloc_socket.
  2. LIBC: e.g. invoke posix_memalign.
  3. Another memarea: it can be from another memarea.

- It supports MT-safe as long as it's specified at creation time.

- The address returned by the allocator is align to 8B.

Note:
a) The memarea is oriented towards the application layer, which could
provides 'region-based memory management' [1] function.
b) The eal library also provide memory zone/heap management, but these
are tied to huge pages management.

[1] https://en.wikipedia.org/wiki/Region-based_memory_management

Chengwen Feng (6):
  memarea: introduce memarea library
  test/memarea: support memarea test
  memarea: support alloc and free API
  test/memarea: support alloc and free API test
  memarea: support dump API
  test/memarea: support dump API test

---
v19:
* address Anatoly's comments about test_memarea: more meaningful error
  tips, and display really allocated num of dump memarea.
* in that test_memarea, explicitly set rte_errno to zero if test that
  rte_errno is a non-zero value.
* don't support windows platform because CI unit-test always failed with:
  MALLOC_PERTURB_=169 DPDK_TEST=memarea_autotest
v18:
* v17 reports DPDK CI apply failed, but it maybe the CI self problem
  because I apply the serial to main and next-net, both are successful,
  so this version just resend v17.
v17:
* address Anatoly's comments: add note and enum for cookie and typo.
v16:
* fix compile failed when clang with thread-safety-analysis
  (by disable annotate_locks in lib/memarea/meson.build).
* add reserved field for 'struct rte_memarea_param' which address
  Stephen's comments.
* fix typo.
v15:
* rebase 23.07
* address Anatoly's mostly comments: use rte_errno, abstract cookie
  helper, more comment about critical function, rename add with split,
  doc limitation.
v14:
* address Stephen's comments: RTE_MEMAREA_LOG use easy impl and add
  __func__ print.
v13:
* address Morten's comments: make debug cookies optional, controlled
  by RTE_LIBRTE_MEMAREA_DEBUG; disabled by default.
* reduce management data overhead.
v12:
* remove rte_memarea_refcnt_update() API which address Dongdong's
  comments.
* refine the variable naming.
* fix some bugs.
v11:
* rebase 23.03
* remove "app/test: add memarea to malloc-perf-autotest" because the
  two algorithm are not comparable which also address previous
  comments.
v10:
* support windows platform.
* add rte_memarea.libc perftest to malloc-perf-autotest.
v9:
* address Dmitry's comments.
* drop features of SOURCE_USER and backup memarea mechanism.
* rename rte_memarea_update_refcnt to rte_memarea_refcnt_update
  to keep with rte_mbuf_refcnt_update name style.
* fix memarea perftest compile failed at windows platform.
* fix spell warning.
v8:
* address Mattias's comments (rename ALG_DEFAULT with ALG_NEXTFIT).
* small feature patches are combined.
* enhanced backup memory mechanism.
* add memarea to malloc-perf-autotest.
* other tiny naming optimize.
v7:
* repost patches as there are spread over different series in patchwork.
v6:
* address Mattias's comments.
v5:
* fix 09/10 patch spell warning.
v4:
* repost patches as there are spread over different series in patchwork.
v3:
* add memory source of RTE memory.
* add algorithm field to facilitate the introduction of new algorithms.
* fix memarea log don't output problem.
v2:
* fix compile issues reported by dpdk-test-report.
* address Dimitry and Jerin's comments.
* add no MT-safe test.

 MAINTAINERS|   6 +
 app/test/meson.build   |   2 +
 app/test/test_memarea.c| 438 +++
 doc/api/doxy-api-index.md  |   3 +-
 doc/api/doxy-api.conf.in   |   1 +
 doc/guides/prog_guide/index.rst|   1 +
 doc/guides/prog_guide/memarea_lib.rst  |  57 +++
 doc/guides/rel_notes/release_23_07.rst |   6 +
 lib/memarea/memarea_private.h  | 126 +++
 lib/memarea/meson.build|  18 +
 lib/memarea/rte_memarea.c  | 463 +
 lib/memarea/rte_memarea.h  | 208 +++
 lib/memarea/version.map|  15 +
 lib/meson.build|   1 +
 14 files changed, 1344 insertions(+), 1 deletion(-)
 create mode 100644 app/test/test_memarea.c
 create mode 100644 doc/guides/prog_guide/memarea_lib.rst
 create mode 100644 lib/memarea/memarea_private.h
 create mode 100644 lib/memarea/meson.build
 create mode 100644 lib/memarea/rte_memarea.c
 create mode 100644 lib/memarea/rte_memarea.h
 create mode 100644 lib/memarea/version.map

-- 
2.17.1

[PATCH v19 4/6] test/memarea: support alloc and free API test

[Chengwen Feng]

This patch supports rte_memarea_alloc() and rte_memarea_free() API
test.

Signed-off-by: Chengwen Feng 
Reviewed-by: Dongdong Liu 
Acked-by: Morten Brørup 
Acked-by: Anatoly Burakov 
---
 app/test/test_memarea.c | 222 +++-
 1 file changed, 221 insertions(+), 1 deletion(-)

diff --git a/app/test/test_memarea.c b/app/test/test_memarea.c
index 6078c93a16..805fb82d08 100644
--- a/app/test/test_memarea.c
+++ b/app/test/test_memarea.c
@@ -38,6 +38,12 @@ test_memarea_init_param(struct rte_memarea_param *init)
init->mt_safe = 1;
 }
 
+static void
+test_memarea_fill_region(void *ptr, size_t size)
+{
+   memset(ptr, 0xff, size);
+}
+
 static int
 test_memarea_create_bad_param(void)
 {
@@ -120,7 +126,7 @@ test_memarea_create_bad_param(void)
 static int
 test_memarea_create_destroy(void)
 {
-   struct rte_memarea *ma;
+   struct rte_memarea *ma, *src_ma;
struct rte_memarea_param init;
 
rte_errno = 0;
@@ -140,6 +146,215 @@ test_memarea_create_destroy(void)
TEST_ASSERT(ma != NULL, "Memarea creation failed");
rte_memarea_destroy(ma);
 
+   /* test for create with another memarea */
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_LIBC;
+   src_ma = rte_memarea_create(&init);
+   TEST_ASSERT(src_ma != NULL, "Memarea creation failed");
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_MEMAREA;
+   init.total_sz = init.total_sz >> 1;
+   init.ma.src = src_ma;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma != NULL, "Memarea creation failed");
+   rte_memarea_destroy(ma);
+   rte_memarea_destroy(src_ma);
+
+   TEST_ASSERT(rte_errno == 0, "Expected ZERO");
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_memarea_alloc_bad_param(void)
+{
+   struct rte_memarea_param init;
+   struct rte_memarea *ma;
+   size_t size;
+   void *ptr;
+
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_LIBC;
+   init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma != NULL, "Memarea creation failed");
+
+   /* test for invalid ma */
+   rte_errno = 0;
+   ptr = rte_memarea_alloc(NULL, 1);
+   TEST_ASSERT(ptr == NULL, "Memarea allocation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for invalid size (size = 0) */
+   rte_errno = 0;
+   ptr = rte_memarea_alloc(ma, 0);
+   TEST_ASSERT(ptr == NULL, "Memarea allocation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for invalid size (size rewind) */
+   rte_errno = 0;
+   memset(&size, 0xff, sizeof(size));
+   ptr = rte_memarea_alloc(ma, size);
+   TEST_ASSERT(ptr == NULL, "Memarea allocation expect fail");
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   rte_memarea_destroy(ma);
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_memarea_free_bad_param(void)
+{
+   struct rte_memarea_param init;
+   struct rte_memarea *ma;
+   void *ptr;
+
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_LIBC;
+   init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma != NULL, "Memarea creation failed");
+   ptr = rte_memarea_alloc(ma, 1);
+   TEST_ASSERT(ptr != NULL, "Memarea allocation failed");
+   test_memarea_fill_region(ptr, 1);
+
+   /* test for invalid ma */
+   rte_errno = 0;
+   rte_memarea_free(NULL, ptr);
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   /* test for invalid ptr */
+   rte_errno = 0;
+   rte_memarea_free(ma, NULL);
+   TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
+
+   rte_memarea_destroy(ma);
+
+   return TEST_SUCCESS;
+}
+
+static int
+test_memarea_alloc_fail(void)
+{
+   struct rte_memarea_param init;
+   struct rte_memarea *ma;
+   void *ptr[2];
+
+   test_memarea_init_param(&init);
+   init.source = RTE_MEMAREA_SOURCE_LIBC;
+   init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
+   ma = rte_memarea_create(&init);
+   TEST_ASSERT(ma != NULL, "Memarea creation failed");
+
+   /* test alloc fail with big size */
+   rte_errno = 0;
+   ptr[0] = rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
+   TEST_ASSERT(ptr[0] == NULL, "Memarea allocation expect fail");
+   TEST_ASSERT(rte_errno == ENOMEM, "Expected ENOMEM");
+
+   /* test alloc fail because no memory */
+   ptr[0] = rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE >> 1);
+   TEST_ASSERT(ptr[0] != NULL, "Memarea allocation failed");
+   test_memarea_fill_region(ptr[0], MEMAREA_TEST_DEFAULT_SIZE >> 1);
+   rte_errno = 0;
+   ptr[1] = rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE >> 1);
+   TEST_ASSERT(ptr[1] == NULL, "Memarea allocati

Re: [PATCH v16 6/6] test/memarea: support dump API test

[fengchengwen]

Hi Anatoly,

On 2023/7/19 20:09, Burakov, Anatoly wrote:
> On 7/10/2023 7:49 AM, Chengwen Feng wrote:
>> This patch supports rte_memarea_dump() API test.
>>
>> Signed-off-by: Chengwen Feng 
>> Reviewed-by: Dongdong Liu 
>> Acked-by: Morten Brørup 
>> ---
>>   app/test/test_memarea.c | 40 
>>   1 file changed, 40 insertions(+)
>>
>> diff --git a/app/test/test_memarea.c b/app/test/test_memarea.c
>> index 4053cdcac9..6511a86699 100644
>> --- a/app/test/test_memarea.c
>> +++ b/app/test/test_memarea.c
>> @@ -320,6 +320,45 @@ test_memarea_alloc_free(void)
>>     TEST_ASSERT(rte_errno == 0, "Expected Zero");
>>   +    fprintf(stderr, "There should have no allocated object.\n");
>> +    rte_memarea_dump(ma, stderr, true);
>> +
>> +    rte_memarea_destroy(ma);
>> +
>> +    return 0;
>> +}
>> +
>> +static int
>> +test_memarea_dump(void)
>> +{
>> +    struct rte_memarea_param init;
>> +    struct rte_memarea *ma;
>> +    int ret;
>> +
>> +    test_memarea_init_param(&init);
>> +    init.source = RTE_MEMAREA_SOURCE_LIBC;
>> +    init.total_sz = MEMAREA_TEST_DEFAULT_SIZE;
>> +    ma = rte_memarea_create(&init);
>> +    TEST_ASSERT(ma != NULL, "Expected Non-NULL");
> 
> Here and in other places: I feel it's better to say *why* we expect non-NULL, 
> or make the error message otherwise more meaningful, such as "Memarea 
> creation failed".

It already fix in v19.

> 
>> +
>> +    /* test for invalid parameters */
>> +    ret = rte_memarea_dump(NULL, stderr, false);
>> +    TEST_ASSERT(ret == -1, "Expected -1");
>> +    TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
>> +    ret = rte_memarea_dump(ma, NULL, false);
>> +    TEST_ASSERT(ret == -1, "Expected -1");
>> +    TEST_ASSERT(rte_errno == EINVAL, "Expected EINVAL");
>> +
>> +    /* test for dump */
>> +    (void)rte_memarea_alloc(ma, 1);
>> +    (void)rte_memarea_alloc(ma, 1);
>> +    (void)rte_memarea_alloc(ma, 1);
>> +    (void)rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
>> +    (void)rte_memarea_alloc(ma, MEMAREA_TEST_DEFAULT_SIZE);
>> +    fprintf(stderr, "There should have three allocated object.\n");
> 
> I question the value of this printout.

I have change the implemention (in v19): so it will depend on the 
rte_memarea_alloc result.

> 
>> +    ret = rte_memarea_dump(ma, stderr, true);
>> +    TEST_ASSERT(ret == 0, "Expected ZERO");
>> +
>>   rte_memarea_destroy(ma);
>>     return 0;
>> @@ -337,6 +376,7 @@ static struct unit_test_suite memarea_test_suite  = {
>>   TEST_CASE(test_memarea_alloc_fail),
>>   TEST_CASE(test_memarea_free_fail),
>>   TEST_CASE(test_memarea_alloc_free),
>> +    TEST_CASE(test_memarea_dump),
>>     TEST_CASES_END() /**< NULL terminate unit test array */
>>   }
> 

Thanks.

[PATCH v1] examples/l3fwd: relax the RSS/Offload requirement

[Trevor Tao]

Now the port Rx mq_mode had been set to RTE_ETH_MQ_RX_RSS, and offload
mode set to RTE_ETH_RX_OFFLOAD_CHECKSUM by default, but some hardware
and/or virtual interface does not support the RSS and offload mode
presupposed, e.g., some virtio interfaces in the cloud don't support
RSS and may only partly support RTE_ETH_RX_OFFLOAD_UDP_CKSUM/
RTE_ETH_RX_OFFLOAD_TCP_CKSUM,
but not RTE_ETH_RX_OFFLOAD_IPV4_CKSUM, and the error msg here:

virtio_dev_configure(): RSS support requested but not supported by
the device
Port0 dev_configure = -95

and:
Ethdev port_id=0 requested Rx offloads 0xe does not match Rx offloads
capabilities 0x201d in rte_eth_dev_configure()

So to enable the l3fwd running in that environment, the Rx mode requirement
can be relaxed to reflect the hardware feature reality here, and the l3fwd
can run smoothly then.
A warning msg would be provided to user in case it happens here.

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Trevor Tao 
Reviewed-by: Ruifeng Wang 
Reviewed-by: Feifei Wang 
---
 .mailmap  |  1 +
 examples/l3fwd/main.c | 19 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/.mailmap b/.mailmap
index 8e3940a253..602d8cbc6b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1403,6 +1403,7 @@ Tom Rix 
 Tone Zhang 
 Tonghao Zhang  
 Tony Nguyen 
+Trevor Tao 
 Tsotne Chakhvadze 
 Tudor Brindus 
 Tudor Cornea  
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index a4f061537e..cec87d95d1 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -1233,8 +1233,12 @@ l3fwd_poll_resource_setup(void)
local_port_conf.rx_adv_conf.rss_conf.rss_hf &=
dev_info.flow_type_rss_offloads;
 
-   if (dev_info.max_rx_queues == 1)
+   /* relax the rx rss requirement */
+   if (dev_info.max_rx_queues == 1 || 
!local_port_conf.rx_adv_conf.rss_conf.rss_hf) {
+   printf("warning: modified the rx mq_mode to 
RTE_ETH_MQ_RX_NONE base on"
+   " device capability\n");
local_port_conf.rxmode.mq_mode = RTE_ETH_MQ_RX_NONE;
+   }
 
if (local_port_conf.rx_adv_conf.rss_conf.rss_hf !=
port_conf.rx_adv_conf.rss_conf.rss_hf) {
@@ -1245,6 +1249,19 @@ l3fwd_poll_resource_setup(void)
local_port_conf.rx_adv_conf.rss_conf.rss_hf);
}
 
+   /* relax the rx offload requirement */
+   if ((local_port_conf.rxmode.offloads & 
dev_info.rx_offload_capa) !=
+   local_port_conf.rxmode.offloads) {
+   printf("Port %u requested Rx offloads 0x%"PRIx64" does 
not"
+   " match Rx offloads capabilities 0x%"PRIx64"\n",
+   portid, local_port_conf.rxmode.offloads,
+   dev_info.rx_offload_capa);
+   local_port_conf.rxmode.offloads &= 
dev_info.rx_offload_capa;
+   port_conf.rxmode.offloads = 
local_port_conf.rxmode.offloads;
+   printf("warning: modified the rx offload to 0x%"PRIx64" 
based on device"
+   " capability\n", 
local_port_conf.rxmode.offloads);
+   }
+
ret = rte_eth_dev_configure(portid, nb_rx_queue,
(uint16_t)n_tx_queue, &local_port_conf);
if (ret < 0)
-- 
2.41.0

[POC v2] net/iavf: support no data path polling mode

[Mingjin Ye]

Introduces a devargs "no-poll-on-link-down" in iavf PMD. When this
flag is set, the PMD switches to no-poll mode when the link state is
down (rx/tx burst returns to 0 immediately). When the link state
returns to normal, PMD switches to normal rx/tx burst state.

Signed-off-by: Mingjin Ye 
---
V2: Add IAVF_NO_POLL_ON_LINK_DOWN_ARG macro to iavf_valid_args.
---
 drivers/net/iavf/iavf.h |  2 ++
 drivers/net/iavf/iavf_ethdev.c  | 11 +++
 drivers/net/iavf/iavf_rxtx.c| 29 +++--
 drivers/net/iavf/iavf_rxtx.h|  1 +
 drivers/net/iavf/iavf_rxtx_vec_avx2.c   | 29 ++---
 drivers/net/iavf/iavf_rxtx_vec_avx512.c | 42 ++---
 drivers/net/iavf/iavf_rxtx_vec_sse.c| 21 -
 drivers/net/iavf/iavf_vchnl.c   | 19 +++
 8 files changed, 142 insertions(+), 12 deletions(-)

diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 98861e4242..30b05d25b6 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -305,6 +305,7 @@ struct iavf_devargs {
uint8_t proto_xtr[IAVF_MAX_QUEUE_NUM];
uint16_t quanta_size;
uint32_t watchdog_period;
+   uint16_t no_poll_on_link_down;
 };
 
 struct iavf_security_ctx;
@@ -323,6 +324,7 @@ struct iavf_adapter {
uint32_t ptype_tbl[IAVF_MAX_PKT_TYPE] __rte_cache_min_aligned;
bool stopped;
bool closed;
+   bool no_poll;
uint16_t fdir_ref_cnt;
struct iavf_devargs devargs;
 };
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index ac7154d720..c922c64838 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -37,6 +37,7 @@
 #define IAVF_PROTO_XTR_ARG "proto_xtr"
 #define IAVF_QUANTA_SIZE_ARG   "quanta_size"
 #define IAVF_RESET_WATCHDOG_ARG"watchdog_period"
+#define IAVF_NO_POLL_ON_LINK_DOWN_ARG   "no-poll-on-link-down"
 
 uint64_t iavf_timestamp_dynflag;
 int iavf_timestamp_dynfield_offset = -1;
@@ -45,6 +46,7 @@ static const char * const iavf_valid_args[] = {
IAVF_PROTO_XTR_ARG,
IAVF_QUANTA_SIZE_ARG,
IAVF_RESET_WATCHDOG_ARG,
+   IAVF_NO_POLL_ON_LINK_DOWN_ARG,
NULL
 };
 
@@ -2237,6 +2239,7 @@ static int iavf_parse_devargs(struct rte_eth_dev *dev)
struct rte_kvargs *kvlist;
int ret;
int watchdog_period = -1;
+   uint16_t no_poll_on_link_down;
 
if (!devargs)
return 0;
@@ -2270,6 +2273,14 @@ static int iavf_parse_devargs(struct rte_eth_dev *dev)
else
ad->devargs.watchdog_period = watchdog_period;
 
+   no_poll_on_link_down = rte_kvargs_count(kvlist,
+   IAVF_NO_POLL_ON_LINK_DOWN_ARG);
+
+   if (no_poll_on_link_down == 0)
+   ad->devargs.no_poll_on_link_down = 0;
+   else
+   ad->devargs.no_poll_on_link_down = 1;
+
if (ad->devargs.quanta_size != 0 &&
(ad->devargs.quanta_size < 256 || ad->devargs.quanta_size > 4096 ||
 ad->devargs.quanta_size & 0x40)) {
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index f7df4665d1..447e306fee 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -770,6 +770,7 @@ iavf_dev_tx_queue_setup(struct rte_eth_dev *dev,
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf =
IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+   struct iavf_vsi *vsi = &vf->vsi;
struct iavf_tx_queue *txq;
const struct rte_memzone *mz;
uint32_t ring_size;
@@ -843,6 +844,7 @@ iavf_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->port_id = dev->data->port_id;
txq->offloads = offloads;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
+   txq->vsi = vsi;
 
if (iavf_ipsec_crypto_supported(adapter))
txq->ipsec_crypto_pkt_md_offset =
@@ -1406,9 +1408,12 @@ iavf_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts, uint16_t nb_pkts)
uint64_t pkt_flags;
const uint32_t *ptype_tbl;
 
+   rxq = rx_queue;
+   if (!rxq->vsi || rxq->vsi->adapter->no_poll)
+   return 0;
+
nb_rx = 0;
nb_hold = 0;
-   rxq = rx_queue;
rx_id = rxq->rx_tail;
rx_ring = rxq->rx_ring;
ptype_tbl = rxq->vsi->adapter->ptype_tbl;
@@ -1515,9 +1520,12 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
const uint32_t *ptype_tbl;
uint64_t ts_ns;
 
+   rxq = rx_queue;
+   if (!rxq->vsi || rxq->vsi->adapter->no_poll)
+   return 0;
+
nb_rx = 0;
nb_hold = 0;
-   rxq = rx_queue;
rx_id = rxq->rx_tail;
rx_ring = rxq->rx_ring;
ptype_tbl = rxq->vsi->adapter->ptype_tbl;
@@ -1641,6 +1649,9 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct 
rte_mbuf **rx_pkts,
volatile union iavf_rx_flex_desc *rxdp;
const uint32_t *ptyp

[PATCH] app/dma-perf: fix dma mapping access overruns

[Mingjin Ye]

The dma map supports a maximum of `MAX_WORKER_NB=128`. Initializing
the dma map allows a maximum support of `MAX_WORKER_NB=256`. This results
in memory access out-of-bounds when the actual dma entries exceed
MAX_WORKER_NB.

This patch talks about MAX_WORKER_NB and MAX_WORKER_NB size set to 256 to
fix this.

Signed-off-by: Mingjin Ye 
---
 app/test-dma-perf/main.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/app/test-dma-perf/main.h b/app/test-dma-perf/main.h
index f65e264378..602ecac858 100644
--- a/app/test-dma-perf/main.h
+++ b/app/test-dma-perf/main.h
@@ -10,11 +10,12 @@
 #include 
 #include 
 
-#define MAX_WORKER_NB 128
+#define MAX_WORKER_NB 256
 #define MAX_OUTPUT_STR_LEN 512
 
 #define MAX_DMA_NB 128
-#define MAX_LCORE_NB 256
+/* Note that MAX_LCORE_NB <= MAX_WORKER_NB */
+#define MAX_LCORE_NB MAX_WORKER_NB
 
 extern char output_str[MAX_WORKER_NB + 1][MAX_OUTPUT_STR_LEN];
 
-- 
2.25.1

RE: [PATCH] doc: postpone deprecation of pipeline legacy API

[Dumitrescu, Cristian]

> -Original Message-
> From: Richardson, Bruce 
> Sent: Wednesday, July 19, 2023 5:09 PM
> To: Dumitrescu, Cristian 
> Cc: dev@dpdk.org; Nicolau, Radu ; R,
> Kamalakannan ; Suresh Narayane, Harshad
> 
> Subject: Re: [PATCH] doc: postpone deprecation of pipeline legacy API
> 
> On Wed, Jul 19, 2023 at 03:12:25PM +, Cristian Dumitrescu wrote:
> > Postpone the deprecation of the legacy pipeline, table and port
> > library API and gradual stabilization of the new API.
> >
> > Signed-off-by: Cristian Dumitrescu 
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 21 +
> >  1 file changed, 9 insertions(+), 12 deletions(-)
> >
> 
> No objection to this, though it would be really good to get the new
> functions stabilized in 23.11 when we lock down the 24 ABI.
> 

Yes, fully agree, let's see if we can make this happen for 23.11

> Acked-by: Bruce Richardson 
> 
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > index fb771a0305..56ef906cdb 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -145,19 +145,16 @@ Deprecation Notices
> >In the absence of such interest, this library will be removed in DPDK 
> > 23.11.
> >
> >  * pipeline: The pipeline library legacy API (functions rte_pipeline_*)
> > -  will be deprecated in DPDK 23.07 release and removed in DPDK 23.11
> release.
> > -  The new pipeline library API (functions rte_swx_pipeline_*)
> > -  will gradually transition from experimental to stable status
> > -  starting with DPDK 23.07 release.
> > +  will be deprecated and subsequently removed in DPDK 24.11 release.
> > +  Before this, the new pipeline library API (functions rte_swx_pipeline_*)
> > +  will gradually transition from experimental to stable status.
> >
> >  * table: The table library legacy API (functions rte_table_*)
> > -  will be deprecated in DPDK 23.07 release and removed in DPDK 23.11
> release.
> > -  The new table library API (functions rte_swx_table_*)
> > -  will gradually transition from experimental to stable status
> > -  starting with DPDK 23.07 release.
> > +  will be deprecated and subsequently removed in DPDK 24.11 release.
> > +  Before this, the new table library API (functions rte_swx_table_*)
> > +  will gradually transition from experimental to stable status.
> >
> >  * port: The port library legacy API (functions rte_port_*)
> > -  will be deprecated in DPDK 23.07 release and removed in DPDK 23.11
> release.
> > -  The new port library API (functions rte_swx_port_*)
> > -  will gradually transition from experimental to stable status
> > -  starting with DPDK 23.07 release.
> > +  will be deprecated and subsequently removed in DPDK 24.11 release.
> > +  Before this, the new port library API (functions rte_swx_port_*)
> > +  will gradually transition from experimental to stable status.
> > --
> > 2.34.1
> >

[PATCH v1] crypto/ipsec_mb: add digest encrypted feature

[Brian Dooley]

AESNI_MB PMD does not support Digest Encrypted. This patch adds support
for this feature.

Signed-off-by: Brian Dooley 
---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 107 +++--
 1 file changed, 102 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c 
b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index 9e298023d7..48b0e66f24 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1438,6 +1438,54 @@ set_gcm_job(IMB_MGR *mb_mgr, IMB_JOB *job, const uint8_t 
sgl,
return 0;
 }
 
+/** Check if conditions are met for digest-appended operations */
+static uint8_t *
+aesni_mb_digest_appended_in_src(struct rte_crypto_op *op, IMB_JOB *job,
+   uint32_t oop)
+{
+   unsigned int auth_size, cipher_size;
+   uint8_t *end_cipher;
+   uint8_t *start_cipher;
+
+   if (job->cipher_mode == IMB_CIPHER_NULL)
+   return NULL;
+
+   if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3 ||
+   job->cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN ||
+   job->cipher_mode == IMB_CIPHER_KASUMI_UEA1_BITLEN) {
+   cipher_size = (op->sym->cipher.data.offset >> 3) +
+   (op->sym->cipher.data.length >> 3);
+   } else {
+   cipher_size = (op->sym->cipher.data.offset) +
+   (op->sym->cipher.data.length);
+   }
+   if (job->hash_alg == IMB_AUTH_ZUC_EIA3_BITLEN ||
+   job->hash_alg == IMB_AUTH_SNOW3G_UIA2_BITLEN ||
+   job->hash_alg == IMB_AUTH_KASUMI_UIA1 ||
+   job->hash_alg == IMB_AUTH_ZUC256_EIA3_BITLEN) {
+   auth_size = (op->sym->auth.data.offset >> 3) +
+   (op->sym->auth.data.length >> 3);
+   } else {
+   auth_size = (op->sym->auth.data.offset) +
+   (op->sym->auth.data.length);
+   }
+
+   if (!oop) {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_src, uint8_t *);
+   } else {
+   end_cipher = rte_pktmbuf_mtod_offset(op->sym->m_dst, uint8_t *, 
cipher_size);
+   start_cipher = rte_pktmbuf_mtod(op->sym->m_dst, uint8_t *);
+   }
+
+   if (start_cipher < op->sym->auth.digest.data &&
+   op->sym->auth.digest.data < end_cipher) {
+   return rte_pktmbuf_mtod_offset(op->sym->m_src, uint8_t *, 
auth_size);
+   } else {
+   return NULL;
+   }
+}
+
 /**
  * Process a crypto operation and complete a IMB_JOB job structure for
  * submission to the multi buffer library for processing.
@@ -1580,9 +1628,12 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp,
} else {
if (aead)
job->auth_tag_output = op->sym->aead.digest.data;
-   else
-   job->auth_tag_output = op->sym->auth.digest.data;
-
+   else {
+   job->auth_tag_output = 
aesni_mb_digest_appended_in_src(op, job, oop);
+   if (job->auth_tag_output == NULL) {
+   job->auth_tag_output = 
op->sym->auth.digest.data;
+   }
+   }
if (session->auth.req_digest_len !=
job->auth_tag_output_len_in_bytes) {
job->auth_tag_output =
@@ -1917,6 +1968,7 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
struct aesni_mb_session *sess = NULL;
uint8_t *linear_buf = NULL;
int sgl = 0;
+   uint8_t oop = 0;
uint8_t is_docsis_sec = 0;
 
if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
@@ -1962,8 +2014,52 @@ post_process_mb_job(struct ipsec_mb_qp *qp, IMB_JOB *job)
op->sym->auth.digest.data,
sess->auth.req_digest_len,
&op->status);
-   } else
+   } else {
+   if (!op->sym->m_dst || op->sym->m_dst == 
op->sym->m_src) {
+   /* in-place operation */
+   oop = 0;
+   } else { /* out-of-place operation */
+   oop = 1;
+   }
+
+   if (op->sym->m_src->nb_segs == 1 && 
op->sym->m_dst != NULL
+   && !is_aead_algo(job->hash_alg, 
sess->template_job.cipher_mode) &&
+   aesni_mb_digest_appended_in_src(op, job, oop) 
!= NULL) {
+   unsigned int auth_size, cipher_size;
+   int unencrypted_bytes = 0;
+   if (job->cipher_mode == 
IMB_C

Re: [PATCH v3] build: announce requirement for C11

[Jerin Jacob]

On Thu, Jul 20, 2023 at 1:52 PM Bruce Richardson
 wrote:
>
> On Wed, May 17, 2023 at 06:34:00PM +0100, Bruce Richardson wrote:
> > Add a deprecation notice informing users that we will require a C11
> > compiler from 23.11 release onwards. This requirement was agreed by
> > technical board to enable use of newer C language features, e.g.
> > standard atomics. [1]
> >
> > [1] 
> > http://inbox.dpdk.org/dev/dbapr08mb58148cec3e1454e8848a938998...@dbapr08mb5814.eurprd08.prod.outlook.com/
> >
> > Signed-off-by: Bruce Richardson 
> > Acked-by: Tyler Retzlaff 
> >
> > ---
> >
> > V3:
> > - add additional detail following discussion on-list
> >
> > V2:
> > - add requirement for stdatomics
> > - fix sphinx formatting
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> Ping for additional review/acks and merge.


Acked-by: Jerin Jacob 


>
> This deprecation notice really needs to go into 23.07 to allow the C11
> requirement to be met in 23.11!
>
> Thanks,
> /Bruce

Re: [PATCH v3 2/2] doc/contributing: guidelines for logging, tracing and telemetry

[Jerin Jacob]

On Wed, Jul 19, 2023 at 6:38 AM lihuisong (C)  wrote:
>
>
> 在 2023/7/19 0:48, Bruce Richardson 写道:
> > As discussed by DPDK technical board [1], our contributor guide should
> > include some details as to when to use logging vs tracing vs telemetry
> > to provide the end user with information about the running process and
> > the DPDK libraries it uses.
> >
> > [1] https://mails.dpdk.org/archives/dev/2023-March/265204.html
> >
> > Signed-off-by: Bruce Richardson 
> > Acked-by: Morten Brørup 
> > Reviewed-by: David Marchand 

Acked-by: Jerin Jacob 

[PATCH v4 0/2] Improve docs on getting info on running process

[Bruce Richardson]

Add details to our documentation on how to register logging for a
component. Also provide guidelines on when to use logs vs tracing
vs telemetry.

V4: Added note to patch 1 saying not to use the old static logging method

V3: Moved new doc section on runtime info, and other minor changes flagged
by David on review.

V2: extended second patch based on the feedback provided.

Bruce Richardson (2):
  doc/contributing: provide coding details for dynamic logging
  doc/contributing: guidelines for logging, tracing and telemetry

 doc/guides/contributing/coding_style.rst | 24 
 doc/guides/contributing/design.rst   | 49 
 doc/guides/prog_guide/telemetry_lib.rst  |  2 +
 doc/guides/prog_guide/trace_lib.rst  |  2 +
 lib/cfgfile/rte_cfgfile.c|  2 +
 5 files changed, 79 insertions(+)

--
2.39.2

[PATCH v4 1/2] doc/contributing: provide coding details for dynamic logging

[Bruce Richardson]

While the section on dynamic logging in the contributors guide covered
the details of the logging naming scheme, it failed to cover exactly how
the component developer, i.e. the contributor, could actually use
dynamic logging in their component.

Fix this by splitting the details of the naming scheme into a separate
subsection, and adding to the introduction on logging, a recommendation
(and example) to use RTE_LOG_REGISTER_DEFAULT.

Similarly, when discussing specialization, include a reference to the
RTE_LOG_REGISTER_SUFFIX macro.

Signed-off-by: Bruce Richardson 
Acked-by: Chengwen Feng 
Reviewed-by: David Marchand 
---
 doc/guides/contributing/coding_style.rst | 22 ++
 lib/cfgfile/rte_cfgfile.c|  2 ++
 2 files changed, 24 insertions(+)

diff --git a/doc/guides/contributing/coding_style.rst 
b/doc/guides/contributing/coding_style.rst
index 00d6270624..383942a601 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -803,6 +803,26 @@ logging of a particular topic, the ``--log-level`` 
parameter can be provided
 to EAL, which will change the log level. DPDK code can register topics,
 which allows the user to adjust the log verbosity for that specific topic.
 
+To register a library or driver for dynamic logging, using the standardized 
naming scheme described below,
+use ``RTE_LOG_REGISTER_DEFAULT`` macro to define a log-type variable inside 
your component's main C file.
+Thereafter, it is usual to define a macro or macros inside your component to 
make logging more convenient.
+
+For example, the ``rte_cfgfile`` library defines:
+
+.. literalinclude:: ../../../lib/cfgfile/rte_cfgfile.c
+:language: c
+:start-after: Setting up dynamic logging 8<
+:end-before: >8 End of setting up dynamic logging
+
+.. note::
+
+   The statically-defined log types defined in ``rte_log.h`` are for legacy 
components,
+   and they will likely be removed in a future release.
+   Do not add new entries to this file.
+
+Dynamic Logging Naming Scheme
+~~
+
 In general, the naming scheme is as follows: ``type.section.name``
 
  * Type is the type of component, where ``lib``, ``pmd``, ``bus`` and ``user``
@@ -837,6 +857,8 @@ A specialization looks like this:
  * Initialization output: ``type.section.name.init``
  * PF/VF mailbox output: ``type.section.name.mbox``
 
+These specializations are created using the ``RTE_LOG_REGISTER_SUFFIX`` macro.
+
 A real world example is the i40e poll mode driver which exposes two
 specializations, one for initialization ``pmd.net.i40e.init`` and the other for
 the remaining driver logs ``pmd.net.i40e.driver``.
diff --git a/lib/cfgfile/rte_cfgfile.c b/lib/cfgfile/rte_cfgfile.c
index 9fa7d010ef..eefba6e408 100644
--- a/lib/cfgfile/rte_cfgfile.c
+++ b/lib/cfgfile/rte_cfgfile.c
@@ -27,11 +27,13 @@ struct rte_cfgfile {
struct rte_cfgfile_section *sections;
 };
 
+/* Setting up dynamic logging 8< */
 RTE_LOG_REGISTER_DEFAULT(cfgfile_logtype, INFO);
 
 #define CFG_LOG(level, fmt, args...)   \
rte_log(RTE_LOG_ ## level, cfgfile_logtype, "%s(): " fmt "\n",  \
__func__, ## args)
+/* >8 End of setting up dynamic logging */
 
 /** when we resize a file structure, how many extra entries
  * for new sections do we add in */
-- 
2.39.2

[PATCH v4 2/2] doc/contributing: guidelines for logging, tracing and telemetry

[Bruce Richardson]

As discussed by DPDK technical board [1], our contributor guide should
include some details as to when to use logging vs tracing vs telemetry
to provide the end user with information about the running process and
the DPDK libraries it uses.

[1] https://mails.dpdk.org/archives/dev/2023-March/265204.html

Signed-off-by: Bruce Richardson 
Acked-by: Morten Brørup 
Acked-by: Jerin Jacob 
Reviewed-by: David Marchand 
---
 doc/guides/contributing/coding_style.rst |  2 +
 doc/guides/contributing/design.rst   | 49 
 doc/guides/prog_guide/telemetry_lib.rst  |  2 +
 doc/guides/prog_guide/trace_lib.rst  |  2 +
 4 files changed, 55 insertions(+)

diff --git a/doc/guides/contributing/coding_style.rst 
b/doc/guides/contributing/coding_style.rst
index 383942a601..37e2cc5efb 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -794,6 +794,8 @@ Control Statements
  /* NOTREACHED */
  }
 
+.. _dynamic_logging:
+
 Dynamic Logging
 ---
 
diff --git a/doc/guides/contributing/design.rst 
b/doc/guides/contributing/design.rst
index d24a7ff6a0..5a4c4b7ed1 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -4,6 +4,7 @@
 Design
 ==
 
+
 Environment or Architecture-specific Sources
 
 
@@ -68,6 +69,54 @@ Adding a new static field or flag must be an exception 
matching many criteria
 like (non exhaustive): wide usage, performance, size.
 
 
+Runtime Information - Logging, Tracing and Telemetry
+---
+
+It is often desirable to provide information to the end-user as to what is 
happening to the application at runtime.
+DPDK provides a number of built-in mechanisms to provide this introspection:
+
+* :ref:`Logging`
+* :ref:`Tracing`
+* :ref:`Telemetry`
+
+Each of these has its own strengths and suitabilities for use within DPDK 
components.
+
+Below are some guidelines for when each should be used:
+
+* For reporting error conditions, or other abnormal runtime issues, *logging* 
should be used.
+  Depending on the severity of the issue, the appropriate log level, for 
example,
+  ``ERROR``, ``WARNING`` or ``NOTICE``, should be used.
+
+.. note::
+
+Drivers of all classes, including both bus and device drivers,
+should not output any log information if the hardware they support is not 
present.
+This is to avoid any changes in output for existing users when a new 
driver is added to DPDK.
+
+* For component initialization, or other cases where a path through the code 
is only likely to be taken once,
+  either *logging* at ``DEBUG`` level or *tracing* may be used, or potentially 
both.
+  In the latter case, tracing can provide basic information as to the code 
path taken,
+  with debug-level logging providing additional details on internal state,
+  not possible to emit via tracing.
+
+* For a component's data-path, where a path is to be taken multiple times 
within a short timeframe,
+  *tracing* should be used.
+  Since DPDK tracing uses `Common Trace Format `_ for 
its tracing logs,
+  post-analysis can be done using a range of external tools.
+
+* For numerical or statistical data generated by a component, for example, 
per-packet statistics,
+  *telemetry* should be used.
+
+* For any data where the data may need to be gathered at any point in the 
execution to help assess the state of the application component,
+  for example, core configuration, device information, *telemetry* should be 
used.
+  Telemetry callbacks should not modify any program state, but be "read-only".
+
+Many libraries also include a ``rte__dump()`` function as part of 
their API,
+writing verbose internal details to a given file-handle.
+New libraries are encouraged to provide such functions where it makes sense to 
do so,
+as they provide an additional application-controlled mechanism to get details 
of the internals of a DPDK component.
+
+
 Library Statistics
 --
 
diff --git a/doc/guides/prog_guide/telemetry_lib.rst 
b/doc/guides/prog_guide/telemetry_lib.rst
index 32f525a67f..71f8bd735e 100644
--- a/doc/guides/prog_guide/telemetry_lib.rst
+++ b/doc/guides/prog_guide/telemetry_lib.rst
@@ -1,6 +1,8 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2020 Intel Corporation.
 
+.. _telemetry_library:
+
 Telemetry Library
 =
 
diff --git a/doc/guides/prog_guide/trace_lib.rst 
b/doc/guides/prog_guide/trace_lib.rst
index e5718feddc..a3b8a7c2eb 100644
--- a/doc/guides/prog_guide/trace_lib.rst
+++ b/doc/guides/prog_guide/trace_lib.rst
@@ -1,6 +1,8 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(C) 2020 Marvell International Ltd.
 
+.. _trace_library:
+
 Trace Library
 =
 
-- 
2.39.2

Re: [PATCH v4 0/2] Improve docs on getting info on running process

[Ferruh Yigit]

On 7/20/2023 12:05 PM, Bruce Richardson wrote:
> Add details to our documentation on how to register logging for a
> component. Also provide guidelines on when to use logs vs tracing
> vs telemetry.
> 
> V4: Added note to patch 1 saying not to use the old static logging method
> 
> V3: Moved new doc section on runtime info, and other minor changes flagged
> by David on review.
> 
> V2: extended second patch based on the feedback provided.
> 
> Bruce Richardson (2):
>   doc/contributing: provide coding details for dynamic logging
>   doc/contributing: guidelines for logging, tracing and telemetry
> 

For series,
Acked-by: Ferruh Yigit 

[PATCH] test: eal: update base-virtaddr parameter test

[Aaron Conole]

When 97435d7906 ("net/bnxt: update Truflow core") was applied, it introduced
a number of static variables.  These ended up filling the lower address space
enough that on some platforms, the min addr for heap address to start was
not within the range specified by base-virtaddr.  This is dependent on both
build and link time options.

The simplest resolution is to just update the base virtaddr parameter to
move the rte config location.

Reported-by: Patrick Robb 
Suggested-by: Ajit Khaparde 
Signed-off-by: Aaron Conole 
---
 app/test/test_eal_flags.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index d2b91e2075..148e9098e8 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -1017,7 +1017,7 @@ test_misc_flags(void)
 
/* try running with base-virtaddr param */
const char *argv13[] = {prgname, "--file-prefix=virtaddr",
-   "--base-virtaddr=0x12345678"};
+   "--base-virtaddr=0x23456789"};
 
/* try running with --vfio-intr INTx flag */
const char *argv14[] = {prgname, "--file-prefix=intr",
-- 
2.40.1

[PATCH] examples/ipsec-secgw: add security capabilities mapping

[Akhil Goyal]

Currently the cryptodev queue pair mapping was done only
on lookaside crypto capabilities.
But device capabilities for lookaside crypto and
lookaside proto may be different.
Hence, mappings are also added for rte_security_capabilities
of cryptodev.

Signed-off-by: Akhil Goyal 
---
 examples/ipsec-secgw/ipsec-secgw.c | 41 --
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index 72b3bfba9e..3ab7995fd5 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1555,6 +1555,8 @@ add_cdev_mapping(const struct rte_cryptodev_info 
*dev_info, uint16_t cdev_id,
struct lcore_conf *qconf;
struct ipsec_ctx *ipsec_ctx;
const char *str;
+   void *sec_ctx;
+   const struct rte_security_capability *sec_cap;
 
qconf = &lcore_conf[params->lcore_id];
 
@@ -1569,8 +1571,8 @@ add_cdev_mapping(const struct rte_cryptodev_info 
*dev_info, uint16_t cdev_id,
}
 
/* Required cryptodevs with operation chaining */
-   if (!(dev_info->feature_flags &
-   RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING))
+   if (!(dev_info->feature_flags & 
RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING) &&
+   !(dev_info->feature_flags & RTE_CRYPTODEV_FF_SECURITY))
return ret;
 
for (i = dev_info->capabilities;
@@ -1600,6 +1602,41 @@ add_cdev_mapping(const struct rte_cryptodev_info 
*dev_info, uint16_t cdev_id,
}
}
 
+   sec_ctx = rte_cryptodev_get_sec_ctx(cdev_id);
+   if (sec_ctx == NULL)
+   return ret;
+
+   sec_cap = rte_security_capabilities_get(sec_ctx);
+   if (sec_cap == NULL)
+   return ret;
+
+   for (i = sec_cap->crypto_capabilities;
+   i->op != RTE_CRYPTO_OP_TYPE_UNDEFINED; i++) {
+   if (i->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+   continue;
+
+   if (i->sym.xform_type == RTE_CRYPTO_SYM_XFORM_AEAD) {
+   ret |= add_mapping(str, cdev_id, qp, params,
+   ipsec_ctx, NULL, NULL, i);
+   continue;
+   }
+
+   if (i->sym.xform_type != RTE_CRYPTO_SYM_XFORM_CIPHER)
+   continue;
+
+   for (j = sec_cap->crypto_capabilities;
+   j->op != RTE_CRYPTO_OP_TYPE_UNDEFINED; j++) {
+   if (j->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+   continue;
+
+   if (j->sym.xform_type != RTE_CRYPTO_SYM_XFORM_AUTH)
+   continue;
+
+   ret |= add_mapping(str, cdev_id, qp, params,
+   ipsec_ctx, i, j, NULL);
+   }
+   }
+
return ret;
 }
 
-- 
2.25.1

Re: [PATCH] test: eal: update base-virtaddr parameter test

[Ajit Khaparde]

On Thu, Jul 20, 2023 at 6:09 AM Aaron Conole  wrote:
>
> When 97435d7906 ("net/bnxt: update Truflow core") was applied, it introduced
> a number of static variables.  These ended up filling the lower address space
> enough that on some platforms, the min addr for heap address to start was
> not within the range specified by base-virtaddr.  This is dependent on both
> build and link time options.
>
> The simplest resolution is to just update the base virtaddr parameter to
> move the rte config location.
>
> Reported-by: Patrick Robb 
> Suggested-by: Ajit Khaparde 
> Signed-off-by: Aaron Conole 
ACK.
I tested again and the test passed with this change. Thanks.

> ---
>  app/test/test_eal_flags.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
> index d2b91e2075..148e9098e8 100644
> --- a/app/test/test_eal_flags.c
> +++ b/app/test/test_eal_flags.c
> @@ -1017,7 +1017,7 @@ test_misc_flags(void)
>
> /* try running with base-virtaddr param */
> const char *argv13[] = {prgname, "--file-prefix=virtaddr",
> -   "--base-virtaddr=0x12345678"};
> +   "--base-virtaddr=0x23456789"};
>
> /* try running with --vfio-intr INTx flag */
> const char *argv14[] = {prgname, "--file-prefix=intr",
> --
> 2.40.1
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v2] usertools: add tool to generate balanced rss traffic flows

[Thomas Monjalon]

20/07/2023 10:00, Robin Jarry:
> Hi Thomas,
> 
> Thomas Monjalon, Jul 20, 2023 at 06:50:
> > Applied, thanks.
> 
> Thanks! I think there's a byte order issue with the i40e rss key. If
> I submit a fix today, can it make it for GA?

Yes you can.

> > You have great skills for user tools in Python,
> > and this file as other ones have no official maintainer:
> > usertools/dpdk-devbind.py
> > usertools/dpdk-hugepages.py
> > usertools/dpdk-rss-flows.py
> >
> > Would like to take care of them?
> 
> Thanks for the offer. I'll gladly adopt anything python related in DPDK.

OK good, let's discuss this in a techboard meeting.

Re: [PATCH v3 6/6] dts: add basic UDP test case

[Jeremy Spewock]

Acked-by: Jeremy Spewock 

RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application

[Rakesh Kudurumalla]

> -Original Message-
> From: Vamsi Krishna Attunuru 
> Sent: Thursday, June 1, 2023 8:14 AM
> To: Jerin Jacob 
> Cc: Yan, Zhirun ; dev@dpdk.org;
> tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
> Nithin Kumar Dabilpuram ; Liang, Cunming
> ; Wang, Haiyue ; Sunil
> Kumar Kori 
> Subject: RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application
> 
> 
> 
> > -Original Message-
> > From: Jerin Jacob 
> > Sent: Tuesday, May 30, 2023 1:05 PM
> > To: Vamsi Krishna Attunuru 
> > Cc: Yan, Zhirun ; dev@dpdk.org;
> > tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
> > Nithin Kumar Dabilpuram ; Liang, Cunming
> > ; Wang, Haiyue ;
> Sunil
> > Kumar Kori 
> > Subject: [EXT] Re: [PATCH v2 4/4] app: add testgraph application
> >
> > External Email
> >
> > --
> > On Mon, May 22, 2023 at 12:37 PM Vamsi Krishna Attunuru
> >  wrote:
> >
> > > > > +static int
> > > > > +link_graph_nodes(uint64_t valid_nodes, uint32_t lcore_id) {
> > > > > +   int ret = 0;
> > > > > +
> > > > > +   num_patterns = 0;
> > > > > +
> > > > > +   if (valid_nodes == (TEST_GRAPH_ETHDEV_TX_NODE |
> >
> >
> > I think, if we need to extend the C code for adding new use case, then
> > it will not scale.
> > IMO, We should look at more runtime and file based interface.
> > Something like https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_DPDK_dpdk_blob_main_examples_ip-
> >
> 5Fpipeline_examples_l2fwd.cli&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r
> >
> =WllrYaumVkxaWjgKto6E_rtDQshhIhik2jkvzFyRhW8&m=__0iDgw_2lXr0YyyV
> > pN3e1Ma9M5SyYMs1pUKnOgvix6u5jfs6MSprWyUh-
> > sCmTDw&s=janRFWyPd7Ma3bCIvlVW1YqkAS_U9ouMGNfP1x98pmQ&e=
> > In nutshell,
> > 1) File based interface to kick-start the valid use case enablement
> > 2) Less logic in C code and everything should be driven from config
> > file
> > 3) Allow runtime change. examples/ip_pipeline provides telent
> > interface to update . Similar concept can be followed.
> >
> > I think, we should push the app for next release. Not on this release.
> > Sorry for reviewing late.
> Sure, agree with your new proposal. I will drop this patch for this release.

As discussed we are proposing command based interface for running different
usecases with configuration file as input per usecase. Please review and let us 
know your comments meanwhile we have started implementing v1 with below 
specification.

Graph application Interface file
Configure Use cases
=
This section consists of which use cases are needed to be configured and model 
to be used along with number of coremask 
to run graph on that. Following is the exposed syntax to configure given use 
case.

Syntax:

graph  [usecase specific configuration]  [model specific 
configuration]

Where:

usecases: It is comma separated list defining the requested use cases. Example 
values are -
l3fwd
ipsec
usecase specific configuration: It defines following usecase specific 
configuration -
burst size (bsz)
timeout (tmo)
coremask
model: It defines the model for dequeuing packets.  Example models are -
run to completion (rtc)
multi core dispatch (mcd)
Global specific configuration
==
This section consists of device specific configuration which are needed to make 
a DPDK port usable such as number

of Rx/TX queues, MTU, mempool etc. Along with it consists global network table 
configuration required for each use case

such as configure IP address to device, arp entries for given IP etc. Supported 
hardware offloads to be used by 
this use case is also added under this configuration. Graph is created for this 
use case at the end of this configuration.

Syntax:

mempool  size  buffers  cache  

Where:

mempool_name  : Name of the mempool used for further pool operations.
size  : Size of each element in mempool
buffers: Number of elements in mempool
cache : Size of the per-core object cache
  : Socket id


Syntax:

ethdev  rxq  txq   promiscuous 
ethdev  tx_offload 
ethdev  rx_offload 
ethdev  promiscuous 
ethdev  mtu 

Where:

dbdf: PCI id of device in DBDF format or vdev name for 
non-pci devices.
rxq  : Number of Rx queues on device
txq  : Number of Tx queues on device
mempool_name : Mempool to be attached on RQ.
rx_offload   : Supported offloads on ingress. It is bitmask of required 
offloads. Valid offloads are combination of RTE_ETH_RX_OFFLOAD_*
tx_offload   : Supported offloads on egress. It is bitmask of required 
offloads. valid offloads are combination of RTE_ETH_TX_OFFLOAD_*
promiscuous   : Toggle promiscuous mode
mtu  : MTU size


Syntax:

neigh add ipv4  

Where:

ip: IPv4/IPv6 address for which MAC address is to be added.
mac: MAC  address which is to be configured corresponding to given IP. 


Syntax:

ip4 addr add  netmask  

Where:

ip   : IPv4 address which is to assigned to device.
mask : Sub

Re: [PATCH] mailmap: update contributor entry

[Ivan Malov]

PING

On Tue, 13 Jun 2023, Ivan Malov wrote:


Signed-off-by: Ivan Malov 
---
.mailmap | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.mailmap b/.mailmap
index 8e3940a253..d97cdc670c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -105,7 +105,7 @@ Andriy Berestovskyy  


Andrzej Ostruszka  
Andy Gospodarek  
Andy Green 
-Andy Moreton  
+Andy Moreton   solarflare.com>

Andy Pei 
Anirudh Venkataramanan 
Ankur Dwivedi   


--
2.30.2

Community CI Meeting Minutes - July 20, 2023

[Patrick Robb]

July 20, 2023

#
Attendees
1. Patrick Robb
2. Alex Agerholm
3. Christian Muf
4. Juraj Linkeš
5. Danylo Vodopianov
6. Jeremy Spewock
7. M Kostenok
8. Lincoln Lavoie
9. Manit Mahajan
10. Alex Kholodnyi
11. Aaron Conole
12. Thomas Monjalon
13. Ali Alnubani

#
Agenda
1. General Announcements
2. CI Status
3. DTS Improvements & Test Development
4. Any other business

#
Minutes

=
General Announcements
* Napatech is beginning the process of contributing their driver for DPDK,
and intends to stand up a process for CI testing
   * 1. What is the preferable way for community to work with custom HW?
According
   * to the documentation: send hardware to the DPDK Lab in the UNH-IOL is
one possible way? Could we set own lab? Where CI should be located and
which accesses should be provided?
  * Making use of the Community Lab is one way to accomplish CI testing
without having to setup your own CI Testing infrastructure. But, setting up
your own internal lab and reporting your results is also good.
 * Governing board approval might be required about bringing a new
vendor into the community lab
 * Is a specific membership tier required for hardware inclusion in
the lab?
 * Napatech is wondering about any regular fee (per month, per year)
  * [Aaron] For running an internal lab, scripts for polling patchwork
and DPDK CI testing scripts can be found at
https://github.com/ovsrobot/pw-ci and at https://git.dpdk.org/tools/dpdk-ci/
  * For how long should an internal lab be available?
 * As long as possible - the DPDK project will continuously be
changing, so if a driver is contributed, long term testing will be very
helpful in verifying for the community that no functionality breaks months
or years down the road. If testing results can be provided long term, the
community can help keep the driver in a good state long term.
   * 2. Which DTS tests should be executed by NT team to prove that NT DPDK
driver is okay to be upstreamed?
  * There are no specific DTS testsuite requirements for upstreaming,
so it’s best to just extend use of DTS as much as possible according to the
driver’s feature set
   * 3. we have implemented custom DTS tests which are covering the
functionality of the NIC. May these tests be considered as enough for merge
of driver? If so, should they be upstreamed as well?
  * If you are going to report (to patchwork) results from these custom
testsuites, they should be upstreamed to DTS. Lijuan is the maintainer.
https://git.dpdk.org/tools/dts/
  * Ping Lijuan about schedule for development
  * Small-Medium changes are fine halfway through a release cycle, but
the RFCs exist for a reason and major changes cannot come late in the
process
   * 4. Is there documentation for setting up a CI Testing lab with DPDK
Patchwork?
  * There is not much in terms of documentation, but for running an
internal lab, scripts for polling patchwork and DPDK CI testing scripts can
be found at https://github.com/ovsrobot/pw-ci and at
https://git.dpdk.org/tools/dpdk-ci/
   * 5.  In which format should be this test report?
  * [Aaron] Test reports can be as simple as:
https://mails.dpdk.org/archives/test-report/2023-July/420253.html - Note
that we need the subject line, Test-Label, Test-Status, patch url, and
_test text_ to all be present in the form in that email.
   * 6. Which access level to the setup we should to provide for the
community?
  * [Aaron] If you run your own lab, the community generally doesn't
need access - but you will need to support in the case your lab has issues.
   * 7. On which request and how often we have to execute tests and send
report?
  * [Aaron] We run the tests on every patch that comes via patchwork.
  * Ideally, the report will include the necessary output showing the
failure and help the developer start digging on how to fix their patch
  * Currently Napatech has run testing periodically, but not (per
patch/ per series)
   * 8. Do test reports need to be saved locally?
  * Not a requirement, if enough information can be included in the
test report
  * UNH does save some artifacts associated with the testrun, which can
be downloaded from the dashboard. In some cases these logs are much more
extensive than what is provided on the emailed test report.
 * The ideal is to hold these for at least a release cycle
* Napatech has developed a PMD dpdk driver for their smartNIC, which they
aim to upstream to DPDK
   * Has run their custom DTS tests internally
   * Looking for clarity on what is required for upstreaming
  * Is CI testing a requirement for submitting a driver? A: No, code
review is sufficient, but CI which reports upstream will 

[PATCH v3] MAINTAINERS: add status information

[Stephen Hemminger]

Add a new field S: which indicates the status of support for
individual sub-trees. Almost everything is marked as supported
but components without any maintainer are listed as Orphan.

Signed-off-by: Stephen Hemminger 
---
v3 - add back Makefile
 mark vdev_netvsc as Odd Fixes

 MAINTAINERS | 266 
 1 file changed, 266 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 18bc05fccd0d..42cc29e6c475 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17,6 +17,16 @@ Descriptions of section entries:
X: Files and directories exclusion, same rules as F:
K: Keyword regex pattern to match content.
   One regex pattern per line. Multiple K: lines acceptable.
+   S: *Status*, one of the following:
+  Supported:   Someone is actually paid to look after this.
+  Maintained:  Someone actually looks after it.
+  Odd Fixes:   It has a maintainer but they don't have time to do
+   much other than throw the odd patch in. See below..
+  Orphan:  No current maintainer [but maybe you could take the
+   role as you write your new code].
+  Obsolete:Old code. Something tagged obsolete generally means
+   it has been replaced by a better system and you
+   should be using that.
 
 
 General Project Administration
@@ -25,44 +35,54 @@ General Project Administration
 Main Branch
 M: Thomas Monjalon 
 M: David Marchand 
+S: Supported
 T: git://dpdk.org/dpdk
 
 Next-net Tree
 M: Ferruh Yigit 
 M: Andrew Rybchenko 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-net
 
 Next-net-brcm Tree
 M: Ajit Khaparde 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-net-brcm
 
 Next-net-intel Tree
 M: Qi Zhang 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-net-intel
 
 Next-net-mrvl Tree
 M: Jerin Jacob 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-net-mrvl
 
 Next-net-mlx Tree
 M: Raslan Darawsheh 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-net-mlx
 
 Next-virtio Tree
 M: Maxime Coquelin 
 M: Chenbo Xia 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-virtio
 
 Next-crypto Tree
 M: Akhil Goyal 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-crypto
 
 Next-eventdev Tree
 M: Jerin Jacob 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-eventdev
 
 Next-baseband Tree
 M: Maxime Coquelin 
+S: Supported
 T: git://dpdk.org/next/dpdk-next-baseband
 
 Stable Branches
@@ -70,17 +90,21 @@ M: Luca Boccassi 
 M: Kevin Traynor 
 M: Christian Ehrhardt 
 M: Xueming Li 
+S: Supported
 T: git://dpdk.org/dpdk-stable
 
 Security Issues
 M: maintain...@dpdk.org
+S: Supported
 
 Documentation (with overlaps)
 F: README
 F: doc/
+S: Supported
 
 Developers and Maintainers Tools
 M: Thomas Monjalon 
+S: Supported
 F: MAINTAINERS
 F: devtools/build-dict.sh
 F: devtools/check-abi.sh
@@ -110,6 +134,7 @@ F: .mailmap
 
 Build System
 M: Bruce Richardson 
+S: Supported
 F: Makefile
 F: meson.build
 F: meson_options.txt
@@ -130,11 +155,13 @@ F: devtools/check-meson.py
 Public CI
 M: Aaron Conole 
 M: Michael Santana 
+S: Supported
 F: .github/workflows/build.yml
 F: .ci/
 
 Driver information
 M: Dmitry Kozlyuk 
+S: Maintained
 F: buildtools/coff.py
 F: buildtools/gen-pmdinfo-cfile.py
 F: buildtools/pmdinfogen.py
@@ -147,6 +174,7 @@ Environment Abstraction Layer
 T: git://dpdk.org/dpdk
 
 EAL API and common code
+S: Supported
 F: lib/eal/common/
 F: lib/eal/unix/
 F: lib/eal/include/
@@ -180,6 +208,7 @@ F: app/test/test_version.c
 Trace - EXPERIMENTAL
 M: Jerin Jacob 
 M: Sunil Kumar Kori 
+S: Supported
 F: lib/eal/include/rte_trace*.h
 F: lib/eal/common/eal_common_trace*.c
 F: lib/eal/common/eal_trace.h
@@ -188,6 +217,7 @@ F: app/test/test_trace*
 
 Memory Allocation
 M: Anatoly Burakov 
+S: Supported
 F: lib/eal/include/rte_fbarray.h
 F: lib/eal/include/rte_mem*
 F: lib/eal/include/rte_malloc.h
@@ -209,11 +239,13 @@ F: app/test/test_memzone.c
 
 Interrupt Subsystem
 M: Harman Kalra 
+S: Supported
 F: lib/eal/include/rte_epoll.h
 F: lib/eal/*/*interrupts.*
 F: app/test/test_interrupts.c
 
 Keep alive
+S: Orphan
 F: lib/eal/include/rte_keepalive.h
 F: lib/eal/common/rte_keepalive.c
 F: examples/l2fwd-keepalive/
@@ -221,6 +253,7 @@ F: doc/guides/sample_app_ug/keep_alive.rst
 
 Secondary process
 M: Anatoly Burakov 
+S: Maintained
 K: RTE_PROC_
 F: lib/eal/common/eal_common_proc.c
 F: doc/guides/prog_guide/multi_proc_support.rst
@@ -230,6 +263,7 @@ F: doc/guides/sample_app_ug/multi_process.rst
 
 Service Cores
 M: Harry van Haaren 
+S: Supported
 F: lib/eal/include/rte_service.h
 F: lib/eal/include/rte_service_component.h
 F: lib/eal/common/rte_service.c
@@ -240,44 +274,52 @@ F: doc/guides/sample_app_ug/service_cores.rst
 
 Bitops
 M: Joyce Kong 
+S: Supported
 F: lib/eal/include/rte_bitops.h
 F: app/test/test_bitops.c
 
 Bitmap
 M: Cristian Dumitrescu 
+S: Supported
 F: lib/eal/include/rte_bitmap.h
 F: app/test/test_bitmap.c
 
 MCSlock
 M: Honnappa Nagarahall

[PATCH v2 ] tap: fix build of TAP BPF program

[Stephen Hemminger]

The code was depending on old versions of headers from iproute2.
Include those headers here so that build works.

The standalone build was also broken because by
commit ef5baf3486e0 ("replace packed attributes")
which introduced __rte_packed into this code.

This patch does not address several other issues with this
BPF code. It should be using BTF and the conversion into
array is a mess.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/tap/bpf_api.h | 261 ++
 drivers/net/tap/bpf_elf.h |  43 +
 drivers/net/tap/tap_bpf_program.c |  14 +-
 drivers/net/tap/tap_rss.h |   2 +-
 4 files changed, 316 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/tap/bpf_api.h
 create mode 100644 drivers/net/tap/bpf_elf.h

diff --git a/drivers/net/tap/bpf_api.h b/drivers/net/tap/bpf_api.h
new file mode 100644
index ..d13247199c9a
--- /dev/null
+++ b/drivers/net/tap/bpf_api.h
@@ -0,0 +1,261 @@
+#ifndef __BPF_API__
+#define __BPF_API__
+
+/* Note:
+ *
+ * This file can be included into eBPF kernel programs. It contains
+ * a couple of useful helper functions, map/section ABI (bpf_elf.h),
+ * misc macros and some eBPF specific LLVM built-ins.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "bpf_elf.h"
+
+/** Misc macros. */
+
+#ifndef __stringify
+# define __stringify(X)#X
+#endif
+
+#ifndef __maybe_unused
+# define __maybe_unused__attribute__((__unused__))
+#endif
+
+#ifndef offsetof
+# define offsetof(TYPE, MEMBER)__builtin_offsetof(TYPE, MEMBER)
+#endif
+
+#ifndef likely
+# define likely(X) __builtin_expect(!!(X), 1)
+#endif
+
+#ifndef unlikely
+# define unlikely(X)   __builtin_expect(!!(X), 0)
+#endif
+
+#ifndef htons
+# define htons(X)  __constant_htons((X))
+#endif
+
+#ifndef ntohs
+# define ntohs(X)  __constant_ntohs((X))
+#endif
+
+#ifndef htonl
+# define htonl(X)  __constant_htonl((X))
+#endif
+
+#ifndef ntohl
+# define ntohl(X)  __constant_ntohl((X))
+#endif
+
+#ifndef __inline__
+# define __inline____attribute__((always_inline))
+#endif
+
+/** Section helper macros. */
+
+#ifndef __section
+# define __section(NAME)   \
+   __attribute__((section(NAME), used))
+#endif
+
+#ifndef __section_tail
+# define __section_tail(ID, KEY)   \
+   __section(__stringify(ID) "/" __stringify(KEY))
+#endif
+
+#ifndef __section_xdp_entry
+# define __section_xdp_entry   \
+   __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_cls_entry
+# define __section_cls_entry   \
+   __section(ELF_SECTION_CLASSIFIER)
+#endif
+
+#ifndef __section_act_entry
+# define __section_act_entry   \
+   __section(ELF_SECTION_ACTION)
+#endif
+
+#ifndef __section_lwt_entry
+# define __section_lwt_entry   \
+   __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_license
+# define __section_license \
+   __section(ELF_SECTION_LICENSE)
+#endif
+
+#ifndef __section_maps
+# define __section_maps
\
+   __section(ELF_SECTION_MAPS)
+#endif
+
+/** Declaration helper macros. */
+
+#ifndef BPF_LICENSE
+# define BPF_LICENSE(NAME) \
+   char license[] __section_license = NAME
+#endif
+
+/** Classifier helper */
+
+#ifndef BPF_H_DEFAULT
+# define BPF_H_DEFAULT -1
+#endif
+
+/** BPF helper functions for tc. Individual flags are in linux/bpf.h */
+
+#ifndef __BPF_FUNC
+# define __BPF_FUNC(NAME, ...) \
+   (* NAME)(__VA_ARGS__) __maybe_unused
+#endif
+
+#ifndef BPF_FUNC
+# define BPF_FUNC(NAME, ...)   \
+   __BPF_FUNC(NAME, __VA_ARGS__) = (void *) BPF_FUNC_##NAME
+#endif
+
+/* Map access/manipulation */
+static void *BPF_FUNC(map_lookup_elem, void *map, const void *key);
+static int BPF_FUNC(map_update_elem, void *map, const void *key,
+   const void *value, uint32_t flags);
+static int BPF_FUNC(map_delete_elem, void *map, const void *key);
+
+/* Time access */
+static uint64_t BPF_FUNC(ktime_get_ns);
+
+/* Debugging */
+
+/* FIXME: __attribute__ ((format(printf, 1, 3))) not possible unless
+ * llvm bug https://llvm.org/bugs/show_bug.cgi?id=26243 gets resolved.
+ * It would require fmt to be made const, which generates a reloc
+ * entry (non-map).
+ */
+static void BPF_FUNC(trace_printk, const char *fmt, int fmt_size, ...);
+
+#ifndef printt
+# define printt(fmt, ...)  \
+   ({  \
+   char fmt[] 

[PATCH] net/mana: fix stats for txq bytes sent

[longli]

From: Long Li 

Bytes should be calculated using the packet length, not the mbuf segment
data length.

Fixes: 517ed6e2d590 ("net/mana: add basic driver with build environment")
Cc: sta...@dpdk.org
Signed-off-by: Long Li 
---
 drivers/net/mana/tx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mana/tx.c b/drivers/net/mana/tx.c
index 5947efbe8d..11ba2ee1ac 100644
--- a/drivers/net/mana/tx.c
+++ b/drivers/net/mana/tx.c
@@ -201,7 +201,7 @@ mana_tx_burst(void *dpdk_txq, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
if (!desc->pkt) {
DP_LOG(ERR, "mana_txq_desc has a NULL pkt");
} else {
-   txq->stats.bytes += desc->pkt->data_len;
+   txq->stats.bytes += desc->pkt->pkt_len;
rte_pktmbuf_free(desc->pkt);
}
 
-- 
2.34.1

[PATCH v3] tap: fix build of TAP BPF program

[Stephen Hemminger]

Move the BPF program related code into a subdirectory.
And add a Makefile for building it.

The code was depending on old versions of headers from iproute2.
Include those headers here so that build works.

The standalone build was also broken because by
commit ef5baf3486e0 ("replace packed attributes")
which introduced __rte_packed into this code.

Add a python program to extract the resulting BPF into
a format that can be consumed by the TAP driver.

Update the documentation.

Signed-off-by: Stephen Hemminger 
---
 doc/guides/nics/tap.rst |  11 +-
 drivers/net/tap/bpf/.gitignore  |   1 +
 drivers/net/tap/bpf/Makefile|  18 ++
 drivers/net/tap/bpf/bpf_api.h   | 261 
 drivers/net/tap/bpf/bpf_elf.h   |  43 
 drivers/net/tap/bpf/bpf_extract.py  |  80 ++
 drivers/net/tap/{ => bpf}/tap_bpf_program.c |   9 +-
 drivers/net/tap/tap_rss.h   |   2 +-
 8 files changed, 413 insertions(+), 12 deletions(-)
 create mode 100644 drivers/net/tap/bpf/.gitignore
 create mode 100644 drivers/net/tap/bpf/Makefile
 create mode 100644 drivers/net/tap/bpf/bpf_api.h
 create mode 100644 drivers/net/tap/bpf/bpf_elf.h
 create mode 100644 drivers/net/tap/bpf/bpf_extract.py
 rename drivers/net/tap/{ => bpf}/tap_bpf_program.c (97%)

diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 07df0d35a2ec..449e747994bd 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -256,15 +256,12 @@ C functions under different ELF sections.
 
 2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
 
-3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+3. Use make to compile  `tap_bpf_program.c`` via ``LLVM`` into an object file
+   and extract the resulting instructions into ``tap_bpf_insn.h``.
 
-clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
--filetype=obj -o 
+cd bpf; make
 
-
-4. Use a tool that receives two parameters: an eBPF object file and a section
-name, and prints out the section as a C array of eBPF instructions.
-Embed the C array in your TAP PMD tree.
+4. Recompile the TAP PMD.
 
 The C arrays are uploaded to the kernel using BPF system calls.
 
diff --git a/drivers/net/tap/bpf/.gitignore b/drivers/net/tap/bpf/.gitignore
new file mode 100644
index ..30a258f1af3b
--- /dev/null
+++ b/drivers/net/tap/bpf/.gitignore
@@ -0,0 +1 @@
+tap_bpf_program.o
diff --git a/drivers/net/tap/bpf/Makefile b/drivers/net/tap/bpf/Makefile
new file mode 100644
index ..e5ae4e1f5adc
--- /dev/null
+++ b/drivers/net/tap/bpf/Makefile
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# This file is not built as part of normal DPDK build.
+# It is used to generate the eBPF code for TAP RSS.
+CLANG=clang
+CLANG_OPTS=-O2
+TARGET=../tap_bpf_insns.h
+
+all: $(TARGET)
+
+clean:
+   rm tap_bpf_program.o $(TARGET)
+
+tap_bpf_program.o: tap_bpf_program.c
+   $(CLANG) $(CLANG_OPTS) -emit-llvm -c $< -o - | \
+   llc -march=bpf -filetype=obj -o $@
+
+$(TARGET): bpf_extract.py tap_bpf_program.o
+   python3 bpf_extract.py tap_bpf_program.o $@
diff --git a/drivers/net/tap/bpf/bpf_api.h b/drivers/net/tap/bpf/bpf_api.h
new file mode 100644
index ..d13247199c9a
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_api.h
@@ -0,0 +1,261 @@
+#ifndef __BPF_API__
+#define __BPF_API__
+
+/* Note:
+ *
+ * This file can be included into eBPF kernel programs. It contains
+ * a couple of useful helper functions, map/section ABI (bpf_elf.h),
+ * misc macros and some eBPF specific LLVM built-ins.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "bpf_elf.h"
+
+/** Misc macros. */
+
+#ifndef __stringify
+# define __stringify(X)#X
+#endif
+
+#ifndef __maybe_unused
+# define __maybe_unused__attribute__((__unused__))
+#endif
+
+#ifndef offsetof
+# define offsetof(TYPE, MEMBER)__builtin_offsetof(TYPE, MEMBER)
+#endif
+
+#ifndef likely
+# define likely(X) __builtin_expect(!!(X), 1)
+#endif
+
+#ifndef unlikely
+# define unlikely(X)   __builtin_expect(!!(X), 0)
+#endif
+
+#ifndef htons
+# define htons(X)  __constant_htons((X))
+#endif
+
+#ifndef ntohs
+# define ntohs(X)  __constant_ntohs((X))
+#endif
+
+#ifndef htonl
+# define htonl(X)  __constant_htonl((X))
+#endif
+
+#ifndef ntohl
+# define ntohl(X)  __constant_ntohl((X))
+#endif
+
+#ifndef __inline__
+# define __inline____attribute__((always_inline))
+#endif
+
+/** Section helper macros. */
+
+#ifndef __section
+# define __section(NAME)   \
+   __attribute__((section(NAME), used))
+#endif
+
+#ifndef __section_tail
+# define __section_tail(ID, KEY)   \
+   __section(__stringify(ID) "/" __stringify(KEY))
+#endif
+
+#ifndef __section_xdp_entry
+# define __sec

[PATCH v1] test/graph: fix unused return value

[Zhirun Yan]

Return value stored in "ret" but it may be overwritten before use.
Add goto to return when meet an error. Issue reported by coverity scan.

Coverity issue: 395532
Fixes: 15f483feec65 ("graph: fix model check in core binding")

Signed-off-by: Zhirun Yan 
---
 app/test/test_graph.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/app/test/test_graph.c b/app/test/test_graph.c
index af90ac07ec..7995f67757 100644
--- a/app/test/test_graph.c
+++ b/app/test/test_graph.c
@@ -740,13 +740,13 @@ test_graph_model_mcore_dispatch_core_bind_unbind(void)
ret = rte_graph_worker_model_set(RTE_GRAPH_MODEL_MCORE_DISPATCH);
if (ret != 0) {
printf("Set graph mcore dispatch model failed\n");
-   ret = -1;
+   goto fail;
}
 
ret = rte_graph_model_mcore_dispatch_core_bind(cloned_graph_id, 
worker_lcore);
if (ret != 0) {
printf("bind graph %d to lcore %u failed\n", graph_id, 
worker_lcore);
-   ret = -1;
+   goto fail;
}
 
graph = rte_graph_lookup("worker0-cloned-test2");
@@ -755,6 +755,7 @@ test_graph_model_mcore_dispatch_core_bind_unbind(void)
printf("bind graph %s(id:%d) with lcore %u failed\n",
   graph->name, graph->id, worker_lcore);
ret = -1;
+   goto fail;
}
 
rte_graph_model_mcore_dispatch_core_unbind(cloned_graph_id);
@@ -764,6 +765,7 @@ test_graph_model_mcore_dispatch_core_bind_unbind(void)
ret = -1;
}
 
+fail:
rte_graph_destroy(cloned_graph_id);
 
return ret;
@@ -781,7 +783,7 @@ test_graph_worker_model_set_get(void)
ret = rte_graph_worker_model_set(RTE_GRAPH_MODEL_MCORE_DISPATCH);
if (ret != 0) {
printf("Set graph mcore dispatch model failed\n");
-   ret = -1;
+   goto fail;
}
 
graph = rte_graph_lookup("worker0-cloned-test3");
@@ -790,9 +792,10 @@ test_graph_worker_model_set_get(void)
ret = -1;
}
 
+fail:
rte_graph_destroy(cloned_graph_id);
 
-   return 0;
+   return ret;
 }
 
 static int
-- 
2.37.2

[PATCH] bus/dpaa: fix outside array bounds error with GCC v13

[Gagandeep Singh]

when RTE_ENABLE_ASSERT is enable, DPAA driver is doing
wrong NULL check on frame queue which allows the code
to have access to NULL address.
GCC v13 is giving array bounds error if code is
accessing any memory region less than 4KB.
This patch fixes this issue by adding proper NULL checks
on frame queue.

Please refer: https://bugs.dpdk.org/show_bug.cgi?id=1233

Bugzilla ID: 1233
Fixes: c47ff048b99a ("bus/dpaa: add QMAN driver core routines")
Cc: sta...@dpdk.org

Signed-off-by: Gagandeep Singh 
---
 drivers/bus/dpaa/base/qbman/qman.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/dpaa/base/qbman/qman.c 
b/drivers/bus/dpaa/base/qbman/qman.c
index 3949bf8712..83db0a534e 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0)
  *
  * Copyright 2008-2016 Freescale Semiconductor Inc.
- * Copyright 2017,2019 NXP
+ * Copyright 2017,2019-2023 NXP
  *
  */
 
@@ -897,7 +897,7 @@ static u32 __poll_portal_slow(struct qman_portal *p, u32 is)
/* Lookup in the retirement table */
fq = table_find_fq(p,
   be32_to_cpu(msg->fq.fqid));
-   DPAA_BUG_ON(!fq);
+   DPAA_BUG_ON(fq != NULL);
fq_state_change(p, fq, &swapped_msg, verb);
if (fq->cb.fqs)
fq->cb.fqs(p, fq, &swapped_msg);
@@ -909,6 +909,7 @@ static u32 __poll_portal_slow(struct qman_portal *p, u32 is)
 #else
fq = (void *)(uintptr_t)msg->fq.contextB;
 #endif
+   DPAA_BUG_ON(fq != NULL);
fq_state_change(p, fq, msg, verb);
if (fq->cb.fqs)
fq->cb.fqs(p, fq, &swapped_msg);
-- 
2.25.1

[PATCH] net/i40e: fix FDIR Rxq receives broadcast packets

[beilei . xing]

From: Beilei Xing 

FDIR Rxq is excepted to only reveive FDIR programming status, won't
receive broadcast packets.

Fixes: a778a1fa2e4e ("i40e: set up and initialize flow director")
Cc: sta...@dpdk.org

Signed-off-by: Beilei Xing 
---
 drivers/net/i40e/i40e_ethdev.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index cb0070f94b..0ff334745d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6006,14 +6006,16 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
}
 
-   /* MAC/VLAN configuration */
-   rte_memcpy(&filter.mac_addr, &broadcast, RTE_ETHER_ADDR_LEN);
-   filter.filter_type = I40E_MACVLAN_PERFECT_MATCH;
+   if (vsi->type != I40E_VSI_FDIR) {
+   /* MAC/VLAN configuration for non-FDIR VSI*/
+   rte_memcpy(&filter.mac_addr, &broadcast, RTE_ETHER_ADDR_LEN);
+   filter.filter_type = I40E_MACVLAN_PERFECT_MATCH;
 
-   ret = i40e_vsi_add_mac(vsi, &filter);
-   if (ret != I40E_SUCCESS) {
-   PMD_DRV_LOG(ERR, "Failed to add MACVLAN filter");
-   goto fail_msix_alloc;
+   ret = i40e_vsi_add_mac(vsi, &filter);
+   if (ret != I40E_SUCCESS) {
+   PMD_DRV_LOG(ERR, "Failed to add MACVLAN filter");
+   goto fail_msix_alloc;
+   }
}
 
/* Get VSI BW information */
-- 
2.26.2

[PATCH v2] net/i40e: fix FDIR Rxq receives broadcast packets

[beilei . xing]

From: Beilei Xing 

FDIR Rxq is excepted to only receive FDIR programming status, won't
receive broadcast packets.

Fixes: a778a1fa2e4e ("i40e: set up and initialize flow director")
Cc: sta...@dpdk.org

Signed-off-by: Beilei Xing 
---
V2 change:
 - Fix typo in commit log.

 drivers/net/i40e/i40e_ethdev.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 8271bbb394..7b4f33a5cf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6025,14 +6025,16 @@ i40e_vsi_setup(struct i40e_pf *pf,
}
}
 
-   /* MAC/VLAN configuration */
-   rte_memcpy(&filter.mac_addr, &broadcast, RTE_ETHER_ADDR_LEN);
-   filter.filter_type = I40E_MACVLAN_PERFECT_MATCH;
+   if (vsi->type != I40E_VSI_FDIR) {
+   /* MAC/VLAN configuration for non-FDIR VSI*/
+   rte_memcpy(&filter.mac_addr, &broadcast, RTE_ETHER_ADDR_LEN);
+   filter.filter_type = I40E_MACVLAN_PERFECT_MATCH;
 
-   ret = i40e_vsi_add_mac(vsi, &filter);
-   if (ret != I40E_SUCCESS) {
-   PMD_DRV_LOG(ERR, "Failed to add MACVLAN filter");
-   goto fail_msix_alloc;
+   ret = i40e_vsi_add_mac(vsi, &filter);
+   if (ret != I40E_SUCCESS) {
+   PMD_DRV_LOG(ERR, "Failed to add MACVLAN filter");
+   goto fail_msix_alloc;
+   }
}
 
/* Get VSI BW information */
-- 
2.26.2

[PATCH v2] doc: update release notes for Intel IPU

[beilei . xing]

From: Beilei Xing 

Update release notes for Intel IPU new features:
 - Support VF whose device id is 0x145c.
 - Support hairpin queue.

Fixes: 32bcd47e16fe ("net/idpf: support VF")
Fixes: 1ec8064832db ("net/cpfl: add haipin queue group during vport init")

Signed-off-by: Beilei Xing 
Acked-by: Jingjing Wu 
---
v2 change:
 - Rebase 23.07 rc4.

 doc/guides/rel_notes/release_23_07.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/guides/rel_notes/release_23_07.rst 
b/doc/guides/rel_notes/release_23_07.rst
index 6a1c45162b..61a44367a7 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -222,6 +222,13 @@ New Features
 
   See the :doc:`../tools/dmaperf` for more details.
 
+* **Updated Intel idpf PMD.**
+
+  Added support for Intel IPU E2100 VF whose device id is 0x145c.
+
+* **Updated Intel cpfl PMD.**
+
+  Added support for hairpin queue.
 
 Removed Items
 -
-- 
2.34.1

RE: [PATCH v2] net/i40e: fix FDIR Rxq receives broadcast packets

[Wu, Jingjing]

> -Original Message-
> From: Xing, Beilei 
> Sent: Friday, July 21, 2023 1:35 PM
> To: Wu, Jingjing ; Zhang, Yuying 
> 
> Cc: dev@dpdk.org; Xing, Beilei ; sta...@dpdk.org
> Subject: [PATCH v2] net/i40e: fix FDIR Rxq receives broadcast packets
> 
> From: Beilei Xing 
> 
> FDIR Rxq is excepted to only receive FDIR programming status, won't
> receive broadcast packets.
> 
> Fixes: a778a1fa2e4e ("i40e: set up and initialize flow director")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Beilei Xing 

Acked-by: Jingjing Wu 

Re: [EXT] Re: [PATCH v2 4/4] app: add testgraph application

[Jerin Jacob]

On Thu, Jul 20, 2023 at 9:22 PM Rakesh Kudurumalla
 wrote:
>
>
>
> > -Original Message-
> > From: Vamsi Krishna Attunuru 
> > Sent: Thursday, June 1, 2023 8:14 AM
> > To: Jerin Jacob 
> > Cc: Yan, Zhirun ; dev@dpdk.org;
> > tho...@monjalon.net; Jerin Jacob Kollanukkaran ;
> > Nithin Kumar Dabilpuram ; Liang, Cunming
> > ; Wang, Haiyue ; Sunil
> > Kumar Kori 
> > Subject: RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application
> >

>
>
> Example use case: l3fwd
> 
> ;Configure usecase
> graph l3fwd default 0xff
>
> ;global specific configuration
> mempool mempool0 size 2046 buffers 32000 cache 256 cpu 0
> ethdev 0002:02:00.0 rxq 1 txq 1 mempool0 promiscuous off
> ethdev 0002:03:00.0 rxq 1 txq 1 mempool0 promiscuous off
> ip4 addr add 10.0.2.1/24 0002:02:00.0
> ip4 addr add 10.0.3.1/24 0002:03:00.0
> neigh add ipv4 10.0.2.2 52:20:DA:4F:68:70
> neigh add ipv4 10.0.2.5 62:20:DA:4F:68:70
> neigh add ipv4 10.0.3.2 72:20:DA:4F:68:70
> neigh add ipv4 10.0.3.5 82:20:DA:4F:68:70
>
> ;node specific configuration
> route add ipv4 ipv4_lookup 10.0.2.0 netmask 255.255.255.0 via 10.0.2.1
> route add ipv4 ipv4_lookup  10.0.3.0 netmask 255.255.255.0 via 10.0.3.1

I prefer to use node name first.

>
>
> map ethdev_rx  port 0002:02:00.0 queue 0 core 6
> map ethdev_rx  port 0002:03:00.0 queue 1 core 5

I prefer to use node name first.

Rest looks good to me.

>
> ;Run usecase
> graph start