RE: [PATCH] test/crypto: fix authentication IV for zuc SGL

[De Lara Guarch, Pablo]

Hi Ciara,

> -Original Message-
> From: Power, Ciara 
> Sent: Thursday, June 23, 2022 4:32 PM
> To: Akhil Goyal ; Zhang, Roy Fan
> 
> Cc: dev@dpdk.org; Ji, Kai ; De Lara Guarch, Pablo
> ; Power, Ciara ;
> sta...@dpdk.org
> Subject: [PATCH] test/crypto: fix authentication IV for zuc SGL
> 
> The wireless operation for ZUC SGL tests was being passed NULL instead of a
> pointer to the test data authentication IV, and IV length 0.
> This is now corrected to use the IV from the test data.
> 
> Fixes: 11c5485bb276 ("test/crypto: add scatter-gather tests for IP and OOP")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ciara Power 

Acked-by: Pablo de Lara 

RE: [PATCH 0/2] fix wireless algorithm IVs

[De Lara Guarch, Pablo]

> -Original Message-
> From: Power, Ciara 
> Sent: Thursday, June 23, 2022 4:43 PM
> Cc: dev@dpdk.org; Ji, Kai ; Zhang, Roy Fan
> ; De Lara Guarch, Pablo
> ; ktejas...@marvell.com;
> gak...@marvell.com; Power, Ciara 
> Subject: [PATCH 0/2] fix wireless algorithm IVs
> 
> Some of the ZUC and Snow3G test vectors did not follow the specification for
> the cipher and authentication IVs.
> 
> These are now updated to follow the spec documents:
> ZUC 128 spec: https://www.gsma.com/security/wp-
> content/uploads/2019/05/EEA3_EIA3_specification_v1_8.pdf
> Snow3G spec: https://www.gsma.com/aboutus/wp-
> content/uploads/2014/12/uea2uia2d1v21.pdf
> 
> Ciara Power (2):
>   test/crypto: fix zuc test vector IV format
>   test/crypto: fix snow3g test vector IV format
> 
>  app/test/test_cryptodev_snow3g_test_vectors.h | 142 +-
>  app/test/test_cryptodev_zuc_test_vectors.h|  54 +++
>  2 files changed, 98 insertions(+), 98 deletions(-)
> 
> --
> 2.25.1

CC'ing maintainers of the PMDs that support these algorithms, to verify they 
work for them.

Apart from that:
Series-acked-by: Pablo de Lara 

dev@dpdk.org

[bugzilla]

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

gaodaxue (daxuex@intel.com) changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from gaodaxue (daxuex@intel.com) ---
Verified based on 261d96b29e PASSED.

OS: (Ubuntu22.04/ 5.15.0-25-generic)/ (RHEL8.6/4.18.0-372.9.1.el8.x86_64)

GCC: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0/8.5.0 20210514

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

[Bug 1023] [dpdk-22.07][meson test] perf-tests/ipsec_perf_autotest: Failed to test

[bugzilla]

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

jiang,yu (yux.ji...@intel.com) changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from jiang,yu (yux.ji...@intel.com) ---
Patch has been merged into main branch(dpdk22.07), and test passed. 

3ab95f3d1c test/ipsec: fix performance test

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

dev@dpdk.org

[bugzilla]

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

gaodaxue (daxuex@intel.com) changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from gaodaxue (daxuex@intel.com) ---
Verified based on 261d96b29e PASSED.

OS: (Ubuntu22.04/ 5.15.0-25-generic)/ (RHEL8.6/4.18.0-372.9.1.el8.x86_64)

GCC: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0/8.5.0 20210514

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

RE: [PATCH] vhost: fix sync dequeue offload

[Ling, WeiX]

> -Original Message-
> From: Ding, Xuan 
> Sent: Friday, June 24, 2022 1:38 PM
> To: maxime.coque...@redhat.com; Xia, Chenbo 
> Cc: dev@dpdk.org; Hu, Jiayu ; Ling, WeiX
> ; Ding, Xuan 
> Subject: [PATCH] vhost: fix sync dequeue offload
> 
> From: Xuan Ding 
> 
> This patch fixes the missing virtio net header copy in sync dequeue path
> caused by refactoring, which affects dequeue offloading.
> 
> Fixes: 6d823bb302c7("vhost: prepare sync for descriptor to mbuf refactoring")
> 
> Signed-off-by: Xuan Ding 
> ---
>  lib/vhost/virtio_net.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
Tested-by: Wei Ling 

Re: [PATCH v4] lib/eal: fix segfaults due to thread exit order

[David Marchand]

On Fri, Jun 24, 2022 at 3:42 AM Zeng, ZhichaoX  wrote:
>
> Hi David, Harman
> Please review this patch at your convenience, it's been about a month 
> since the v1 version.
> Thanks!

Yes, it's been a month.
Feel free to help on reviewing patches from others so that reviews can
be quicker for everyone.

Thanks.

-- 
David Marchand

RE: [PATCH v2] doc/prog_guide: fix readability in lib vhost prog guide

[Xia, Chenbo]

> -Original Message-
> From: Lipiec, Herakliusz 
> Sent: Thursday, June 23, 2022 9:57 PM
> To: maxime.coque...@redhat.com; Xia, Chenbo 
> Cc: dev@dpdk.org; Lipiec, Herakliusz ;
> sta...@dpdk.org
> Subject: [PATCH v2] doc/prog_guide: fix readability in lib vhost prog
> guide
> 
> fix grammar issues and readbility in vhost library programmer guide
> 
> Fixes: 768274ebbd5e ("vhost: avoid populate guest memory")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Herakliusz Lipiec 
> ---
>  doc/guides/prog_guide/vhost_lib.rst | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/vhost_lib.rst
> b/doc/guides/prog_guide/vhost_lib.rst
> index 606edee940..4675347ee5 100644
> --- a/doc/guides/prog_guide/vhost_lib.rst
> +++ b/doc/guides/prog_guide/vhost_lib.rst
> @@ -351,7 +351,7 @@ vhost-user implementation has two options:
> 
>   * The vhost supported features must be exactly the same before and
> after the restart. For example, if TSO is disabled and then
> enabled,
> -   nothing will work and issues undefined might happen.
> +   nothing will work and undefined issues might happen.
> 
>  No matter which mode is used, once a connection is established, DPDK
>  vhost-user will start receiving and processing vhost messages from QEMU.
> @@ -382,12 +382,12 @@ Guest memory requirement
> 
>  * Memory pre-allocation
> 
> -  For non-async data path, guest memory pre-allocation is not a
> -  must. This can help save of memory. If users really want the guest
> memory
> -  to be pre-allocated (e.g., for performance reason), we can add option
> -  ``-mem-prealloc`` when starting QEMU. Or, we can lock all memory at
> vhost
> -  side which will force memory to be allocated when mmap at vhost side;
> -  option --mlockall in ovs-dpdk is an example in hand.
> +  For non-async data path guest memory pre-allocation is not a
> +  must but can help save memory. To do this we can add option
> +  ``-mem-prealloc`` when starting QEMU, or we can lock all memory at
> vhost
> +  side which will force memory to be allocated when it calls mmap
> +  (option --mlockall in ovs-dpdk is an example in hand).
> +
> 
>For async data path, we force the VM memory to be pre-allocated at
> vhost
>lib when mapping the guest memory; and also we need to lock the memory
> to
> @@ -395,8 +395,8 @@ Guest memory requirement
> 
>  * Memory sharing
> 
> -  Make sure ``share=on`` QEMU option is given. vhost-user will not work
> with
> -  a QEMU version without shared memory mapping.
> +  Make sure ``share=on`` QEMU option is given. The vhost-user will not
> work with
> +  a QEMU instance without shared memory mapping.
> 
>  Vhost supported vSwitch reference
>  -
> --
> 2.36.1

Reviewed-by: Chenbo Xia 

Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Bruce Richardson]

On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Thursday, 23 June 2022 20.40
> > 
> > On Thu, 23 Jun 2022 20:34:07 +0200
> > Morten Brørup  wrote:
> > 
> > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > Sent: Thursday, 23 June 2022 18.43
> > > >
> > > > For string values returned from telemetry, escape any values that
> > > > cannot
> > > > normally appear in a json string. According to the json spec[1],
> > the
> > > > characters than need to be handled are control chars (char value <
> > > > 0x20)
> > > > and '"' and '\' characters.
> > >
> > > Correct. Other chars are optional to escape.
> > 
> > For json_writer (which I wrote for iproute2 and could have been used
> > here).
> > The switch handles: \t \n \r \f \b \\ " ' as special cases.
> 
> RFC 8259 chapter 7 says:
> 
>All Unicode characters may be placed within the
>quotation marks, except for the characters that MUST be escaped:
>quotation mark, reverse solidus, and the control characters (U+
>through U+001F).
> 
> I have no preference for either, as long as '/' and other non-control 
> characters are not (unnecessarily) escaped.
> 
> Using tested and maintained code like json_writer could be beneficial. If you 
> hold the copyright, there should be no license issues.
> 

I will take a look at json_writer.

Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Bruce Richardson]

On Thu, Jun 23, 2022 at 08:34:07PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Thursday, 23 June 2022 18.43
> > 
> > For string values returned from telemetry, escape any values that
> > cannot
> > normally appear in a json string. According to the json spec[1], the
> > characters than need to be handled are control chars (char value <
> > 0x20)
> > and '"' and '\' characters.
> 
> Correct. Other chars are optional to escape.
> 
> > 
> > To handle this, we replace the snprintf call with a separate string
> > copying and encapsulation routine which checks each character as it
> > copies it to the final array.
> > 
> > [1] https://www.rfc-editor.org/rfc/rfc8259.txt
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> >  lib/telemetry/telemetry_json.h | 48 +-
> >  1 file changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/telemetry/telemetry_json.h
> > b/lib/telemetry/telemetry_json.h
> > index db70690274..13df5d07e3 100644
> > --- a/lib/telemetry/telemetry_json.h
> > +++ b/lib/telemetry/telemetry_json.h
> > @@ -44,6 +44,52 @@ __json_snprintf(char *buf, const int len, const char
> > *format, ...)
> > return 0; /* nothing written or modified */
> >  }
> > 
> > +static const char control_chars[0x20] = {
> > +   ['\n'] = 'n',
> > +   ['\r'] = 'r',
> > +   ['\t'] = 't',
> > +};
> > +
> > +/**
> > + * @internal
> > + * Does the same as __json_snprintf(buf, len, "\"%s\"", str)
> > + * except that it does proper escaping as necessary.
> > + * Drops any invalid characters we don't support
> > + */
> > +static inline int
> > +__json_format_str(char *buf, const int len, const char *str)
> > +{
> > +   char tmp[len];
> > +   int tmpidx = 0;
> > +
> > +   tmp[tmpidx++] = '"';
> > +   while (*str != '\0') {
> > +   if (*str < (int)RTE_DIM(control_chars)) {
> 
> I would prefer the more explicit 0x20, directly copied from the RFC. 
> RTE_DIM(control_chars) hints that it could change.
>
Sure. Just trying to avoid magic constants, but in this case it does make
sense. Alternatively, I considered using space char as the sentinel value,
as first non-control-char allowed.
 
> > +   int idx = *str;  /* compilers don't like char type as
> > index */
> > +   if (control_chars[idx] != 0) {
> > +   tmp[tmpidx++] = '\\';
> > +   tmp[tmpidx++] = control_chars[idx];
> > +   }
> 
> Consider support for other control characters:
> + else {
> + tmp[tmpidx++] = '\\';
> + tmp[tmpidx++] = 'u';
> + tmp[tmpidx++] = '0';
> + tmp[tmpidx++] = '0';
> + tmp[tmpidx++] = hexchar(idx >> 4);
> + tmp[tmpidx++] = hexchar(idx & 0xf);
> + }
> 
> Or just drop them, as you mention in the function's description.
> 

Yeah, I'd appreciate general feedback on that. Adding support is nice, but
just not sure if we really need it or not.

> > +   } else if (*str == '"' || *str == '\\') {
> > +   tmp[tmpidx++] = '\\';
> > +   tmp[tmpidx++] = *str;
> > +   } else
> > +   tmp[tmpidx++] = *str;
> > +   /* we always need space for closing quote and null
> > character.
> > +* Ensuring at least two free characters also means we can
> > always take an
> > +* escaped character like "\n" without overflowing
> > +*/
> > +   if (tmpidx > len - 2)
> 
> If supporting the \u00XX encoding, you need to reserve more than 2 characters 
> here and in related code.
> 
Yep. I avoided supporting it for simplicity for now.

> > +   return 0;
> > +   str++;
> > +   }
> > +   tmp[tmpidx++] = '"';
> > +   tmp[tmpidx] = '\0';
> > +
> > +   strcpy(buf, tmp);
> > +   return tmpidx;
> > +}
> > +
> >  /* Copies an empty array into the provided buffer. */
> >  static inline int
> >  rte_tel_json_empty_array(char *buf, const int len, const int used)
> > @@ -62,7 +108,7 @@ rte_tel_json_empty_obj(char *buf, const int len,
> > const int used)
> >  static inline int
> >  rte_tel_json_str(char *buf, const int len, const int used, const char
> > *str)
> >  {
> > -   return used + __json_snprintf(buf + used, len - used, "\"%s\"",
> > str);
> > +   return used + __json_format_str(buf + used, len - used, str);
> >  }
> > 
> >  /* Appends a string into the JSON array in the provided buffer. */
> > --
> > 2.34.1
> > 
> 

Re: [RFC PATCH 0/6] add json string escaping to telemetry

[Bruce Richardson]

On Thu, Jun 23, 2022 at 09:04:31PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Thursday, 23 June 2022 18.43
> > 
> > This RFC shows one possible approach for escaping strings for the json
> > output of telemetry library. For now this RFC supports escaping strings
> > for the cases of returning a single string, or returning an array of
> > strings. Not done is escaping of strings in objs/dicts [see more below
> > on TODO]
> 
> Very good initiative.
> 
> > 
> > As well as telemetry lib changes, this patchset includes unit tests for
> > the above and also little bit of cleanup to the json tests.
> > 
> > TODO:
> > Beyond what is here in this RFC:
> > 
> > 1. we need to decide what to do about name/value pairs. Personally, I
> >think we should add the restriction to the "rte_tel_data_add_obj_*"
> > APIs
> >to only allow a defined subset of characters in names: e.g.
> > alphanumeric
> >chars, underscore and dash. That means that we only need to escape
> >the data part in the case of string returns.
> 
> I agree about only allowing a subset of characters in names, so JSON (and 
> other) encoding is not required.
> 
> However, I think we should be less restrictive, and also allow characters 
> commonly used for separation, indexing and wildcard, such as '/', '[', ']', 
> and '*', '?' or '%'.
> 
> Obviously, we should disallow characters requiring escaping in not just JSON, 
> but also other foreseeable encodings and protocols. So please bring your 
> crystal ball to the discussion. ;-)
> 
Exactly why I am looking for feedback - and why I'm looking to have an
explicit allowed list of characters rather than trying to just block the
known-bad in json ones.

For your suggestions: +1 to separators and indexing, i.e. '[', ']' and '/',
though I would probably also add ',' and maybe '.' (unless it's likely to
cause issues with some protocol we are likely to want to use).
For the wildcarding, I find it hard to see why we would want those?

The other advantage of using an allowlist of characters is that it makes it
possible to expand over time, compared to a blocklist which always runs the
risk of breaking something if you expand it. Therefore I suggest we keep
the list as small as we need right now, and expand it only as we need.

> > 2. once agreed, need to implement a patch to escape strings in
> >dicts/objs
> 
> Yes.
> 
> > 
> > 3. need to add a patch to escape the input command if it contains
> >invalid chars
> 
> What do you mean here? You mean unescape JSON encoded input (arriving on the 
> JSON telemetry socket) to a proper binary string?
> 

The thing with the telemetry socket interface right now is that the input
requests are not-json. The reasons for that is that they be kept as simple
as possible, and to avoid needing a full json parser inside DPDK.
Therefore, the input sent by the user could contain invalid characters for
json output so we need to:
1. Guarantee that no command registered with the telemetry library contains
   invalid json characters (though why someone would do so, I don't know!)
2. When we return the command back in the reply, properly escape any
   invalid characters in the error case.

#1 is very important for sanity checking, but now that I think about it #2
is probably optional, since if any user does start sending invalid garbage
input that breaks their json parser on return, they are only hurting
themselves and not affecting anything else on the system.

> > 4. some small refactoring of the main telemetry.c json-encoding
> > function may be possible.
> 
> Perhaps.
> 
I saw some options for cleanup when I was working on the code, so including
this as a note-to-self as much as anything else for feedback. :-)

/Bruce

RE: [PATCH 3/3] dma/idxd: fix non-AVX builds with older compilers

[Jiang, YuX]

> -Original Message-
> From: Bruce Richardson 
> Sent: Thursday, June 23, 2022 9:50 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce 
> Subject: [PATCH 3/3] dma/idxd: fix non-AVX builds with older compilers
> 
> When building without AVX2 support using an older compiler e.g. gcc 4.8 on
> Centos/RHEL 7, we get build errors due to the use of AVX2 intrinsics.
> This is because the compiler does not support
> "__attribute__((target(AVX2)))" function attribute. Disable build of this
> driver such edge cases.
> 
> Generic builds using recent compilers, and all builds with a minimum baseline
> of AVX2 are unaffected by this change.
> 
> Fixes: aa802b10237c ("dma/idxd: fix AVX2 in non-datapath functions")
> 
> Signed-off-by: Bruce Richardson 
> ---
Tested-by: Yu Jiang 

Tested env as below:
OS: CentOS7.9/kernel: 3.10.0-1160.62.1.el7.x86_64
Compiler: gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

Best regards,
Yu Jiang

[Bug 800] rte_malloc fails to allocate memory block, but succeeds allocating bigger block

[bugzilla]

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

David Marchand (david.march...@redhat.com) changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||david.march...@redhat.com
 Resolution|--- |FIXED

--- Comment #7 from David Marchand (david.march...@redhat.com) ---
Fixed in commit ce2f7d472e80 ("malloc: fix allocation of almost hugepage
size").

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

[Bug 929] rte_dump_stack() is not safe to call from signal handler

[bugzilla]

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

David Marchand (david.march...@redhat.com) changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||david.march...@redhat.com

--- Comment #1 from David Marchand (david.march...@redhat.com) ---
Fixed in commit 0efcd352e257 ("eal/unix: make stack dump signal safe").

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

[Bug 848] gcc12 build error, app/test

[bugzilla]

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

David Marchand (david.march...@redhat.com) changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||david.march...@redhat.com
 Resolution|--- |FIXED

--- Comment #1 from David Marchand (david.march...@redhat.com) ---
Fixed in commit 6e108b6a7c0c ("test/ipsec: fix build with GCC 12").

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

[Bug 861] gcc12 build error, common/cpt

[bugzilla]

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

David Marchand (david.march...@redhat.com) changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||david.march...@redhat.com
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from David Marchand (david.march...@redhat.com) ---
Fixed in commit 3aa16821ab3e ("common/cpt: fix build with GCC 12").

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

Re: [PATCH] net/af_xdp: limit libbpf version to <= v0.7.0

[Thomas Monjalon]

24/06/2022 08:06, Ciara Loftus:
> Linking with libbpf v0.8.0 causes deprication warnings. As a temporary
> measure, prevent linking with libbpf versions v0.8.0 and greater. This
> limitation should be removed in the future when appropriate
> compatibility measures are introduced.
> 
> Signed-off-by: Ciara Loftus 
> ---
> -bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
> -if not bpf_dep.found()
> -bpf_dep = cc.find_library('bpf', required: false)
> -endif
> +bpf_dep = dependency('libbpf', version : '<=0.7.0', required: false, method: 
> 'pkg-config')

It is also removing the find_library() method.
Any reason it was there?

RE: [PATCH] net: fix checksum with unaligned buffer

[Emil Berg]

> -Original Message-
> From: Morten Brørup 
> Sent: den 23 juni 2022 09:01
> To: Emil Berg ; Bruce Richardson
> 
> Cc: Stephen Hemminger ;
> sta...@dpdk.org; bugzi...@dpdk.org; hof...@lysator.liu.se;
> olivier.m...@6wind.com; dev@dpdk.org
> Subject: RE: [PATCH] net: fix checksum with unaligned buffer
> 
> > From: Emil Berg [mailto:emil.b...@ericsson.com]
> > Sent: Thursday, 23 June 2022 07.22
> >
> > > From: Morten Brørup 
> > > Sent: den 22 juni 2022 16:02
> > >
> > > > From: Emil Berg [mailto:emil.b...@ericsson.com]
> > > > Sent: Wednesday, 22 June 2022 14.25
> > > >
> > > > > From: Morten Brørup 
> > > > > Sent: den 22 juni 2022 13:26
> > > > >
> > > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > > > Sent: Wednesday, 22 June 2022 11.18
> > > > > >
> > > > > > On Wed, Jun 22, 2022 at 06:26:07AM +, Emil Berg wrote:
> > > > > > >
> > > > > > > > From: Morten Brørup 
> > > > > > > > Sent: den 21 juni 2022 11:35
> > > > > > > >
> > > > > > > > > From: Bruce Richardson
> > [mailto:bruce.richard...@intel.com]
> > > > > > > > > Sent: Tuesday, 21 June 2022 10.23
> > > > > > > > >
> > > > > > > > > On Tue, Jun 21, 2022 at 10:05:15AM +0200, Morten Brørup
> > > > wrote:
> > > > > > > > > > +TO: @Bruce and @Stephen: You signed off on the 16 bit
> > > > > > alignment
> > > > > > > > > requirement. We need background info on this.
> > > > > > > > > >
> > > > > > > > > > > From: Emil Berg [mailto:emil.b...@ericsson.com]
> > > > > > > > > > > Sent: Tuesday, 21 June 2022 09.17
> > > > > > > > > > >
> > > > > > > > > > > > From: Morten Brørup 
> > > > > > > > > > > > Sent: den 20 juni 2022 12:58
> > > > > > > > > > > >
> > > > > > > > > > > > > From: Emil Berg [mailto:emil.b...@ericsson.com]
> > > > > > > > > > > > > Sent: Monday, 20 June 2022 12.38
> > > > > > > > > > > > >
> > > > > > > > > > > > > > From: Morten Brørup
> 
> > > > > > > > > > > > > > Sent: den 17 juni 2022 11:07
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > From: Morten Brørup
> > > > > > > > > > > > > > > [mailto:m...@smartsharesystems.com]
> > > > > > > > > > > > > > > Sent: Friday, 17 June 2022 10.45
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > With this patch, the checksum can be
> > calculated
> > > > on
> > > > > > > > > > > > > > > an
> > > > > > > > > unligned
> > > > > > > > > > > > > > > part
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > a packet buffer.
> > > > > > > > > > > > > > > I.e. the buf parameter is no longer required
> > to
> > > > be
> > > > > > > > > > > > > > > 16
> > > > > > bit
> > > > > > > > > > > aligned.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The DPDK invariant that packet buffers must
> > be
> > > > > > > > > > > > > > > 16 bit
> > > > > > > > > aligned
> > > > > > > > > > > > > remains
> > > > > > > > > > > > > > > unchanged.
> > > > > > > > > > > > > > > This invariant also defines how to calculate
> > the
> > > > 16
> > > > > > bit
> > > > > > > > > > > checksum
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > an
> > > > > > > > > > > > > > > unaligned part of a packet buffer.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Bugzilla ID: 1035
> > > > > > > > > > > > > > > Cc: sta...@dpdk.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Signed-off-by: Morten Brørup
> > > > > > 
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > >  lib/net/rte_ip.h | 17 +++--
> > > > > > > > > > > > > > >  1 file changed, 15 insertions(+), 2
> > > > > > > > > > > > > > > deletions(-)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > diff --git a/lib/net/rte_ip.h
> > b/lib/net/rte_ip.h
> > > > > > index
> > > > > > > > > > > > > > > b502481670..8e301d9c26 100644
> > > > > > > > > > > > > > > --- a/lib/net/rte_ip.h
> > > > > > > > > > > > > > > +++ b/lib/net/rte_ip.h
> > > > > > > > > > > > > > > @@ -162,9 +162,22 @@ __rte_raw_cksum(const
> > void
> > > > > > > > > > > > > > > *buf,
> > > > > > > > > size_t
> > > > > > > > > > > len,
> > > > > > > > > > > > > > > uint32_t sum)  {
> > > > > > > > > > > > > > >   /* extend strict-aliasing rules */
> > > > > > > > > > > > > > >   typedef uint16_t
> > > > > __attribute__((__may_alias__))
> > > > > > > > > u16_p;
> > > > > > > > > > > > > > > - const u16_p *u16_buf = (const u16_p
> > *)buf;
> > > > > > > > > > > > > > > - const u16_p *end = u16_buf + len /
> > > > > > sizeof(*u16_buf);
> > > > > > > > > > > > > > > + const u16_p *u16_buf;
> > > > > > > > > > > > > > > + const u16_p *end;
> > > > > > > > > > > > > > > +
> > > > > > > > > > > > > > > + /* if buffer is unaligned, keeping it
> > byte
> > > > > > order
> > > > > > > > > > > independent */
> > > > > > > > > > > > > > > + if (unlikely((uintptr_t)buf & 1)) {
> > > > > > > > > > > > > > > + uint16_t first = 0;
> > > > > > > > > > > > > > > + if (unlikely(len == 0))
> > > > > > > > > > > > > > > + return 0;
> > > > > > > > > > > > > > > + 

RE: [PATCH] net/af_xdp: limit libbpf version to <= v0.7.0

[Loftus, Ciara]

> 
> 24/06/2022 08:06, Ciara Loftus:
> > Linking with libbpf v0.8.0 causes deprication warnings. As a temporary
> > measure, prevent linking with libbpf versions v0.8.0 and greater. This
> > limitation should be removed in the future when appropriate
> > compatibility measures are introduced.
> >
> > Signed-off-by: Ciara Loftus 
> > ---
> > -bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
> > -if not bpf_dep.found()
> > -bpf_dep = cc.find_library('bpf', required: false)
> > -endif
> > +bpf_dep = dependency('libbpf', version : '<=0.7.0', required: false,
> method: 'pkg-config')
> 
> It is also removing the find_library() method.
> Any reason it was there?
> 

My understanding is that one can't check the library version using that method.
So it was a valid method of picking up the library until now where we always 
need to check the version before linking.

Re: DPDK compile problem

[David Marchand]

On Fri, Jun 24, 2022 at 10:34 AM  wrote:
>
> hello，
>we are seeing DPDK compile issue when we execute ninja at the "build" 
> directory,there exists the following problem:
> but I can not find rxp-compiler.h online.please help me ，thanks a lot!

Cc: maintainer.

This driver is not in the main repo, so I suppose you are testing with
an older release, please provide detail.

My two cents, afaiu, you have the rxp_compiler library installed.
Not sure how you got it on your system but you are probably missing a
devel package for this library.


-- 
David Marchand

[PATCH v3 1/5] usertools: add option to select hugetlbfs directory

[Dmitry Kozlyuk]

dpdk-hugepages.py had /dev/hugepages hardcoded as the mount point.
It may be desirable to setup hugepage directory at another path,
for example, when using hugepages of multiple sizes in different
directories or when granting different permissions to mount points.
Add --directory/-d option to the script.

Signed-off-by: Dmitry Kozlyuk 
---
 usertools/dpdk-hugepages.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
index 4fdb199744..8bab086a2f 100755
--- a/usertools/dpdk-hugepages.py
+++ b/usertools/dpdk-hugepages.py
@@ -228,6 +228,12 @@ def main():
 '-u',
 action='store_true',
 help='unmount the system huge page directory')
+parser.add_argument(
+'--directory',
+'-d',
+metavar='DIR',
+default=HUGE_MOUNT,
+help='mount point')
 parser.add_argument(
 '--node', '-n', help='select numa node to reserve pages on')
 parser.add_argument(
@@ -262,7 +268,7 @@ def main():
 if args.clear:
 clear_pages()
 if args.unmount:
-umount_huge(HUGE_MOUNT)
+umount_huge(args.directory)
 
 if args.reserve:
 reserve_kb = get_memsize(args.reserve)
@@ -273,7 +279,7 @@ def main():
 reserve_pages(
 int(reserve_kb / pagesize_kb), pagesize_kb, node=args.node)
 if args.mount:
-mount_huge(pagesize_kb, HUGE_MOUNT)
+mount_huge(pagesize_kb, args.directory)
 if args.show:
 show_pages()
 print()
-- 
2.25.1

[PATCH v3 0/5] Improve documentation for running as non-root

[Dmitry Kozlyuk]

v3: Address comments by Bruce Richardson:
- Remove the section for using UIO with older kernels.
- Move the note about legacy virtio to virtio doc.
- Advertise vfio-pci usage to avoid physical addresses
  (still unclear whether and when it requires IPC_LOCK).
- Fix typo.

v2: Address comments by Stephen Hemminger:
- Use hugetlbfs options instead of chown.
- Suggest using OS or container runtime where possible.
- Improve wording.
Add SYS_RAWIO requirement for legacy virtio.
Explain SYS_RAWIO requirement for MLX5 PMD.

Dmitry Kozlyuk (5):
  usertools: add option to select hugetlbfs directory
  usertools: add option to change mount point owner
  doc: give specific instructions for running as non-root
  doc: update instructions for running as non-root for MLX5
  doc: add note about running virtio-legacy as non-root

 doc/guides/linux_gsg/enable_func.rst  | 89 +--
 doc/guides/nics/virtio.rst|  3 +
 doc/guides/platform/mlx5.rst  | 31 ---
 .../prog_guide/env_abstraction_layer.rst  |  2 +
 usertools/dpdk-hugepages.py   | 20 -
 5 files changed, 102 insertions(+), 43 deletions(-)

-- 
2.25.1

[PATCH v3 2/5] usertools: add option to change mount point owner

[Dmitry Kozlyuk]

Per mount(8), the previous owner and mode of the mount point
become invisible as long as this filesystem remains mounted.
Because dpdk-hugepages.py must be run as root,
the new owner would be root.
This is undesirable if the hugepage directory is being set up
by the administrator for an unprivileged user.
HugeTLB filesystem has options to set the mount point owner.
Add --owner/-o option to apply this option when mounting.
The benefit of performing this in dpdk-hugepages.py
is that the user does not need to care about this detail
of mount command operation.

Signed-off-by: Dmitry Kozlyuk 
---
 usertools/dpdk-hugepages.py | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
index 8bab086a2f..5120518bcb 100755
--- a/usertools/dpdk-hugepages.py
+++ b/usertools/dpdk-hugepages.py
@@ -170,7 +170,7 @@ def get_mountpoints():
 return mounted
 
 
-def mount_huge(pagesize, mountpoint):
+def mount_huge(pagesize, mountpoint, owner):
 '''Mount the huge TLB file system'''
 if mountpoint in get_mountpoints():
 print(mountpoint, "already mounted")
@@ -178,6 +178,9 @@ def mount_huge(pagesize, mountpoint):
 cmd = "mount -t hugetlbfs"
 if pagesize:
 cmd += ' -o pagesize={}'.format(pagesize * 1024)
+if owner:
+uid, gid = owner.split(':', maxsplit=1)
+cmd += ' -o uid={},gid={}'.format(uid, gid)
 cmd += ' nodev ' + mountpoint
 os.system(cmd)
 
@@ -234,6 +237,11 @@ def main():
 metavar='DIR',
 default=HUGE_MOUNT,
 help='mount point')
+parser.add_argument(
+'--owner',
+'-o',
+metavar='USER:GROUP',
+help='change the mounted directory owner')
 parser.add_argument(
 '--node', '-n', help='select numa node to reserve pages on')
 parser.add_argument(
@@ -279,7 +287,7 @@ def main():
 reserve_pages(
 int(reserve_kb / pagesize_kb), pagesize_kb, node=args.node)
 if args.mount:
-mount_huge(pagesize_kb, args.directory)
+mount_huge(pagesize_kb, args.directory, args.owner)
 if args.show:
 show_pages()
 print()
-- 
2.25.1

[PATCH v3 3/5] doc: give specific instructions for running as non-root

[Dmitry Kozlyuk]

The guide to run DPDK applications as non-root in Linux
did not provide specific instructions to configure the required access
and did not explain why each bit is needed.
The latter is important because running as non-root
is one of the ways to tighten security and grant minimal permissions.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/linux_gsg/enable_func.rst  | 89 +--
 .../prog_guide/env_abstraction_layer.rst  |  2 +
 2 files changed, 64 insertions(+), 27 deletions(-)

diff --git a/doc/guides/linux_gsg/enable_func.rst 
b/doc/guides/linux_gsg/enable_func.rst
index 1df3ab0255..0b57417c94 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -13,13 +13,63 @@ Enabling Additional Functionality
 Running DPDK Applications Without Root Privileges
 -
 
-In order to run DPDK as non-root, the following Linux filesystem objects'
-permissions should be adjusted to ensure that the Linux account being used to
-run the DPDK application has access to them:
+The following sections describe generic requirements and configuration
+for running DPDK applications as non-root.
+There may be additional requirements documented for some drivers.
 
-*   All directories which serve as hugepage mount points, for example, 
``/dev/hugepages``
+Hugepages
+~
 
-*   If the HPET is to be used,  ``/dev/hpet``
+Hugepages must be reserved as root before running the application as non-root,
+for example::
+
+  sudo dpdk-hugepages.py --reserve 1G
+
+If multi-process is not required, running with ``--in-memory``
+bypasses the need to access hugepage mount point and files within it.
+Otherwise, hugepage directory must be made accessible
+for writing to the unprivileged user.
+A good way for managing multiple applications using hugepages
+is to mount the filesystem with group permissions
+and add a supplementary group to each application or container.
+
+One option is to use the script provided by this project::
+
+  export HUGEDIR=$HOME/huge-1G
+  mkdir -p $HUGEDIR
+  sudo dpdk-hugepages.py --mount --directory $HUGEDIR --owner `id -u`:`id -g`
+
+In production environment, the OS can manage mount points
+(`systemd example 
`_).
+
+The ``hugetlb`` filesystem has additional options to guarantee or limit
+the amount of memory that is possible to allocate using the mount point.
+Refer to the `documentation 
`_.
+
+If the driver requires using physical addresses (PA),
+the executable file must be granted additional capabilities:
+
+* ``SYS_ADMIN`` to read ``/proc/self/pagemaps``
+* ``IPC_LOCK`` to lock hugepages in memory
+
+.. code-block:: console
+
+   setcap cap_ipc_lock,cap_sys_admin+ep 
+
+If physical addresses are not accessible,
+the following message will appear during EAL initialization::
+
+  EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Permission denied
+
+It is harmless in case PA are not needed.
+
+.. note::
+
+   Using ``vfio-pci`` kernel driver, if applicable, can eliminate the need
+   for physical addresses and therefore reduce the permission requirements.
+
+Resource Limits
+~~~
 
 When running as non-root user, there may be some additional resource limits
 that are imposed by the system. Specifically, the following resource limits may
@@ -34,8 +84,13 @@ need to be adjusted in order to ensure normal DPDK operation:
 The above limits can usually be adjusted by editing
 ``/etc/security/limits.conf`` file, and rebooting.
 
-Additionally, depending on which kernel driver is in use, the relevant
-resources also should be accessible by the user running the DPDK application.
+See `Hugepage Mapping `_
+section to learn how these limits affect EAL.
+
+Device Control
+~~
+
+If the HPET is to be used, ``/dev/hpet`` permissions must be adjusted.
 
 For ``vfio-pci`` kernel driver, the following Linux file system objects'
 permissions should be adjusted:
@@ -45,26 +100,6 @@ permissions should be adjusted:
 * The directories under ``/dev/vfio`` that correspond to IOMMU group numbers of
   devices intended to be used by DPDK, for example, ``/dev/vfio/50``
 
-.. note::
-
-The instructions below will allow running DPDK with ``igb_uio`` or
-``uio_pci_generic`` drivers as non-root with older Linux kernel versions.
-However, since version 4.0, the kernel does not allow unprivileged 
processes
-to read the physical address information from the pagemaps file, making it
-impossible for those processes to be used by non-privileged users. In such
-cases, using the VFIO driver is recommended.
-
-For ``igb_uio`` or ``uio_pci_generic`` kernel drivers, the following Linux file
-system objects' permissions should be adjusted:
-
-*   The userspace-io device files in  ``/dev``, for example,  ``/dev/uio0``, 
``/dev/uio1``, and so 

[PATCH v3 4/5] doc: update instructions for running as non-root for MLX5

[Dmitry Kozlyuk]

Reference the common guide for generic setup.
Remove excessive capabilities from the recommended list.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/platform/mlx5.rst | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/doc/guides/platform/mlx5.rst b/doc/guides/platform/mlx5.rst
index 64a4c5e76e..18d38f3488 100644
--- a/doc/guides/platform/mlx5.rst
+++ b/doc/guides/platform/mlx5.rst
@@ -404,25 +404,30 @@ The device can be bound again at this point.
 Run as Non-Root
 ^^^
 
-In order to run as a non-root user,
-some capabilities must be granted to the application::
+Hugepage and resource limit setup are documented
+in the :ref:`common Linux guide `.
+This PMD can operate without access to physical addresses,
+therefore it does not require ``SYS_ADMIN`` to access ``/proc/self/pagemaps``.
+Note that this requirement may still come from other drivers.
 
-   setcap cap_sys_admin,cap_net_admin,cap_net_raw,cap_ipc_lock+ep 
+Below are additional capabilities that must be granted to the application
+with the reasons for the need of each capability:
 
-Below are the reasons for the need of each capability:
+``NET_RAW``
+   For raw Ethernet queue allocation through the kernel driver.
 
-``cap_sys_admin``
-   When using physical addresses (PA mode), with Linux >= 4.0,
-   for access to ``/proc/self/pagemap``.
+``NET_ADMIN``
+   For device configuration, like setting link status or MTU.
 
-``cap_net_admin``
-   For device configuration.
+``SYS_RAWIO``
+   For using group 1 and above (software steering) in Flow API.
 
-``cap_net_raw``
-   For raw ethernet queue allocation through kernel driver.
+They can be manually granted for a specific executable file::
 
-``cap_ipc_lock``
-   For DMA memory pinning.
+   setcap cap_net_raw,cap_net_admin,cap_sys_rawio+ep 
+
+Alternatively, a service manager or a container runtime
+may configure the capabilities for a process.
 
 
 Windows Environment
-- 
2.25.1

[PATCH v3 5/5] doc: add note about running virtio-legacy as non-root

[Dmitry Kozlyuk]

The requirement of SYS_ADMIN capability in legacy virtio mode
was missing. Add it to the driver-specific page.

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/nics/virtio.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 7c0ae2b3af..0e552b2701 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -86,6 +86,9 @@ The following prerequisites apply:
 *   Linux kernel with KVM module; vhost module loaded and ioeventfd supported.
 Qemu standard backend without vhost support isn't tested, and probably 
isn't supported.
 
+*   When using legacy interface, ``SYS_RAWIO`` capability is required
+for ``iopl()`` call to enable access to PCI IO ports.
+
 Virtio with kni vhost Back End
 --
 
-- 
2.25.1

RE: [PATCH v2 3/4] doc: give specific instructions for running as non-root

[Dmitry Kozlyuk]

> From: Bruce Richardson 
> Sent: Monday, June 20, 2022 11:38 AM
> [...]
> > > > +For ``virtio`` PMD in legacy mode, ``SYS_RAWIO`` capability is
> > > required
> > > > +for ``iopl()`` call to enable access to PCI IO ports.
> > > >
> > >
> > > How "legacy" is legacy-mode? Is it still likely in widespread use
> that
> > > we need this?
> >
> > I don't really know.
> > The spec says that legacy support is optional
> > (2.2.3 Legacy Interface: A Note on Feature Bits) and it aims
> > to reduce the chance of a legacy driver attempting to drive the
> device
> > (4.1.2.1 Device Requirements: PCI Device Discovery).
> > OTOH, DPDK supports it and requirements must be documented.
> > I can add a line suggesting to use modern virtio,
> > but also don't mind removing this.
> >
> 
> I suppose the main question for this legacy virtio bit
> is where it should be documented, more than if it should be.
> Given this is a GSG, we should try and avoid getting too deep
> into driver-specific issues, so I think we should omit legacy virtio here,
> but have it docuemented in the relevant virtio-specific doc.
> Does that seem reasonable?

Yes, moved to the virtio doc (it looks like it could use an update BTW).

I also chose to keep HPET line because there's an entire section on HPET
below in the document.

Re: [PATCH V5 0/7] app/testpmd: fix RSS and flow type

[David Marchand]

On Fri, Jun 24, 2022 at 10:55 AM lihuisong (C)  wrote:
>
> Hi Ferruh,
>
> This patchset has been sent. However, a merge conflict is displayed on
> the CI.
> In fact, I'm do it based on the latest mainline, and there are nothing
> conflict.
>
> Can you help me re-trigger the build?

There may be different reasons why (likely on your side), but
patchwork does not see the patches you sent as a single series.
For example, patch 4 is seen as part of the v2 series.

The CI tools rely on patchwork.
So the various CI won't be able to apply them.

Please resend.

-- 
David Marchand

Re: [PATCH v3 1/5] usertools: add option to select hugetlbfs directory

[Bruce Richardson]

On Fri, Jun 24, 2022 at 11:48:13AM +0300, Dmitry Kozlyuk wrote:
> dpdk-hugepages.py had /dev/hugepages hardcoded as the mount point.
> It may be desirable to setup hugepage directory at another path,
> for example, when using hugepages of multiple sizes in different
> directories or when granting different permissions to mount points.
> Add --directory/-d option to the script.
> 
> Signed-off-by: Dmitry Kozlyuk 
> ---

Acked-by: Bruce Richardson 

Re: [PATCH v3 2/5] usertools: add option to change mount point owner

[Bruce Richardson]

On Fri, Jun 24, 2022 at 11:48:14AM +0300, Dmitry Kozlyuk wrote:
> Per mount(8), the previous owner and mode of the mount point
> become invisible as long as this filesystem remains mounted.
> Because dpdk-hugepages.py must be run as root,
> the new owner would be root.
> This is undesirable if the hugepage directory is being set up
> by the administrator for an unprivileged user.
> HugeTLB filesystem has options to set the mount point owner.
> Add --owner/-o option to apply this option when mounting.
> The benefit of performing this in dpdk-hugepages.py
> is that the user does not need to care about this detail
> of mount command operation.
> 
> Signed-off-by: Dmitry Kozlyuk 
> ---
>  usertools/dpdk-hugepages.py | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
> index 8bab086a2f..5120518bcb 100755
> --- a/usertools/dpdk-hugepages.py
> +++ b/usertools/dpdk-hugepages.py
> @@ -170,7 +170,7 @@ def get_mountpoints():
>  return mounted
>  
>  
> -def mount_huge(pagesize, mountpoint):
> +def mount_huge(pagesize, mountpoint, owner):
>  '''Mount the huge TLB file system'''
>  if mountpoint in get_mountpoints():
>  print(mountpoint, "already mounted")
> @@ -178,6 +178,9 @@ def mount_huge(pagesize, mountpoint):
>  cmd = "mount -t hugetlbfs"
>  if pagesize:
>  cmd += ' -o pagesize={}'.format(pagesize * 1024)
> +if owner:
> +uid, gid = owner.split(':', maxsplit=1)
> +cmd += ' -o uid={},gid={}'.format(uid, gid)

Still don't like this syntax and always setting both together. Can we
change the "owner" flag to separate "uid" and "gid" flags so they can be
set independently (and explicitly).

/Bruce

Re: [PATCH v3 3/5] doc: give specific instructions for running as non-root

[Bruce Richardson]

On Fri, Jun 24, 2022 at 11:48:15AM +0300, Dmitry Kozlyuk wrote:
> The guide to run DPDK applications as non-root in Linux
> did not provide specific instructions to configure the required access
> and did not explain why each bit is needed.
> The latter is important because running as non-root
> is one of the ways to tighten security and grant minimal permissions.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dmitry Kozlyuk 

Good improvements. One small suggestion below, otherwise:

Acked-by: Bruce Richardson 

> ---
>  doc/guides/linux_gsg/enable_func.rst  | 89 +--
>  .../prog_guide/env_abstraction_layer.rst  |  2 +
>  2 files changed, 64 insertions(+), 27 deletions(-)
> 
> diff --git a/doc/guides/linux_gsg/enable_func.rst 
> b/doc/guides/linux_gsg/enable_func.rst
> index 1df3ab0255..0b57417c94 100644
> --- a/doc/guides/linux_gsg/enable_func.rst
> +++ b/doc/guides/linux_gsg/enable_func.rst
> @@ -13,13 +13,63 @@ Enabling Additional Functionality
>  Running DPDK Applications Without Root Privileges
>  -
>  
> -In order to run DPDK as non-root, the following Linux filesystem objects'
> -permissions should be adjusted to ensure that the Linux account being used to
> -run the DPDK application has access to them:
> +The following sections describe generic requirements and configuration
> +for running DPDK applications as non-root.
> +There may be additional requirements documented for some drivers.
>  
> -*   All directories which serve as hugepage mount points, for example, 
> ``/dev/hugepages``
> +Hugepages
> +~
>  
> -*   If the HPET is to be used,  ``/dev/hpet``
> +Hugepages must be reserved as root before running the application as 
> non-root,
> +for example::
> +
> +  sudo dpdk-hugepages.py --reserve 1G
> +
> +If multi-process is not required, running with ``--in-memory``
> +bypasses the need to access hugepage mount point and files within it.
> +Otherwise, hugepage directory must be made accessible
> +for writing to the unprivileged user.
> +A good way for managing multiple applications using hugepages
> +is to mount the filesystem with group permissions
> +and add a supplementary group to each application or container.
> +
> +One option is to use the script provided by this project::
> +
> +  export HUGEDIR=$HOME/huge-1G
> +  mkdir -p $HUGEDIR
> +  sudo dpdk-hugepages.py --mount --directory $HUGEDIR --owner `id -u`:`id -g`
> +
> +In production environment, the OS can manage mount points
> +(`systemd example 
> `_).
> +
> +The ``hugetlb`` filesystem has additional options to guarantee or limit
> +the amount of memory that is possible to allocate using the mount point.
> +Refer to the `documentation 
> `_.
> +
> +If the driver requires using physical addresses (PA),
> +the executable file must be granted additional capabilities:
> +
> +* ``SYS_ADMIN`` to read ``/proc/self/pagemaps``
> +* ``IPC_LOCK`` to lock hugepages in memory
> +
> +.. code-block:: console
> +
> +   setcap cap_ipc_lock,cap_sys_admin+ep 
> +
> +If physical addresses are not accessible,
> +the following message will appear during EAL initialization::
> +
> +  EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Permission denied
> +
> +It is harmless in case PA are not needed.
> +
> +.. note::
> +
> +   Using ``vfio-pci`` kernel driver, if applicable, can eliminate the need
> +   for physical addresses and therefore reduce the permission requirements.
> +

Can we move this note up a bit, to immediately after the paragraph about
requiring physical addresses. It's better to inform the user immediately if
a section is not relevant to them, than only telling them at the end once
they have already read it.

/Bruce

[PATCH] doc: announce name change of stop flush callback

[pbhagavatula]

From: Pavan Nikhilesh 

Stop flush callback is missing `rte_` prefix and might conflict with
application declarations.

Signed-off-by: Pavan Nikhilesh 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c53d..a3c4f4ac09 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -125,3 +125,6 @@ Deprecation Notices
   applications should be updated to use the ``dmadev`` library instead,
   with the underlying HW-functionality being provided by the ``ioat`` or
   ``idxd`` dma drivers
+
+* eventdev: The function pointer declaration ``eventdev_stop_flush_t`` will be
+  renamed to ``rte_eventdev_stop_flush_t`` in DPDK 22.11.
-- 
2.25.1

[PATCH] doc: announce change in event vector structure

[pbhagavatula]

From: Pavan Nikhilesh 

The field `*u64s` in the structure `rte_event_vector` will
be replaced with `u64s`.

Signed-off-by: Pavan Nikhilesh 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a3c4f4ac09..6b50ec4865 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -128,3 +128,6 @@ Deprecation Notices
 
 * eventdev: The function pointer declaration ``eventdev_stop_flush_t`` will be
   renamed to ``rte_eventdev_stop_flush_t`` in DPDK 22.11.
+
+* eventdev: The element ``*u64s`` in the structure ``rte_event_vector`` is
+  deprecated and will be replaced with ``u64s`` in DPDK 22.11.
-- 
2.25.1

RE: [RFC PATCH 0/6] add json string escaping to telemetry

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 24 June 2022 10.14
> 
> On Thu, Jun 23, 2022 at 09:04:31PM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Thursday, 23 June 2022 18.43
> > >
> > > This RFC shows one possible approach for escaping strings for the
> json
> > > output of telemetry library. For now this RFC supports escaping
> strings
> > > for the cases of returning a single string, or returning an array
> of
> > > strings. Not done is escaping of strings in objs/dicts [see more
> below
> > > on TODO]
> >
> > Very good initiative.
> >
> > >
> > > As well as telemetry lib changes, this patchset includes unit tests
> for
> > > the above and also little bit of cleanup to the json tests.
> > >
> > > TODO:
> > > Beyond what is here in this RFC:
> > >
> > > 1. we need to decide what to do about name/value pairs. Personally,
> I
> > >think we should add the restriction to the
> "rte_tel_data_add_obj_*"
> > > APIs
> > >to only allow a defined subset of characters in names: e.g.
> > > alphanumeric
> > >chars, underscore and dash. That means that we only need to
> escape
> > >the data part in the case of string returns.
> >
> > I agree about only allowing a subset of characters in names, so JSON
> (and other) encoding is not required.
> >
> > However, I think we should be less restrictive, and also allow
> characters commonly used for separation, indexing and wildcard, such as
> '/', '[', ']', and '*', '?' or '%'.
> >
> > Obviously, we should disallow characters requiring escaping in not
> just JSON, but also other foreseeable encodings and protocols. So
> please bring your crystal ball to the discussion. ;-)
> >
> Exactly why I am looking for feedback - and why I'm looking to have an
> explicit allowed list of characters rather than trying to just block
> the
> known-bad in json ones.
> 
> For your suggestions: +1 to separators and indexing, i.e. '[', ']' and
> '/',
> though I would probably also add ',' and maybe '.' (unless it's likely
> to
> cause issues with some protocol we are likely to want to use).

After having slept on it, I think we should also allow characters that could 
appear in IP and MAC addresses, i.e. '.' and ':' (and '/' for subnetting).

> For the wildcarding, I find it hard to see why we would want those?

Initially, I thought a wildcard might be useful as a placeholder in templates.

But it might also be useful for partial IP or MAC addresses. E.g.:
- The SmartShare Systems OUI could be represented by the MAC address 
"00:1F:B4:??:??:??".
- A default gateway address in a template configuration could be "192.168.*.1".

On the other hand, wildcard characters could be disallowed or require escaping 
in other (non-JSON) protocols.

So I'm just being a bit creative here, throwing out ideas in our search for the 
right balance in the restrictions.

> 
> The other advantage of using an allowlist of characters is that it
> makes it
> possible to expand over time, compared to a blocklist which always runs
> the
> risk of breaking something if you expand it. Therefore I suggest we
> keep
> the list as small as we need right now, and expand it only as we need.

+1

> 
> > > 2. once agreed, need to implement a patch to escape strings in
> > >dicts/objs
> >
> > Yes.
> >
> > >
> > > 3. need to add a patch to escape the input command if it contains
> > >invalid chars
> >
> > What do you mean here? You mean unescape JSON encoded input (arriving
> on the JSON telemetry socket) to a proper binary string?
> >
> 
> The thing with the telemetry socket interface right now is that the
> input
> requests are not-json. The reasons for that is that they be kept as
> simple
> as possible, and to avoid needing a full json parser inside DPDK.
> Therefore, the input sent by the user could contain invalid characters
> for
> json output so we need to:
> 1. Guarantee that no command registered with the telemetry library
> contains
>invalid json characters (though why someone would do so, I don't
> know!)
> 2. When we return the command back in the reply, properly escape any
>invalid characters in the error case.
> 
> #1 is very important for sanity checking, but now that I think about it
> #2
> is probably optional, since if any user does start sending invalid
> garbage
> input that breaks their json parser on return, they are only hurting
> themselves and not affecting anything else on the system.
> 
> > > 4. some small refactoring of the main telemetry.c json-encoding
> > > function may be possible.
> >
> > Perhaps.
> >
> I saw some options for cleanup when I was working on the code, so
> including
> this as a note-to-self as much as anything else for feedback. :-)
> 
> /Bruce

Re: [RFC PATCH 0/6] add json string escaping to telemetry

[Bruce Richardson]

On Fri, Jun 24, 2022 at 11:12:05AM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Friday, 24 June 2022 10.14
> > 
> > On Thu, Jun 23, 2022 at 09:04:31PM +0200, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > Sent: Thursday, 23 June 2022 18.43
> > > >
> > > > This RFC shows one possible approach for escaping strings for the
> > json
> > > > output of telemetry library. For now this RFC supports escaping
> > strings
> > > > for the cases of returning a single string, or returning an array
> > of
> > > > strings. Not done is escaping of strings in objs/dicts [see more
> > below
> > > > on TODO]
> > >
> > > Very good initiative.
> > >
> > > >
> > > > As well as telemetry lib changes, this patchset includes unit tests
> > for
> > > > the above and also little bit of cleanup to the json tests.
> > > >
> > > > TODO:
> > > > Beyond what is here in this RFC:
> > > >
> > > > 1. we need to decide what to do about name/value pairs. Personally,
> > I
> > > >think we should add the restriction to the
> > "rte_tel_data_add_obj_*"
> > > > APIs
> > > >to only allow a defined subset of characters in names: e.g.
> > > > alphanumeric
> > > >chars, underscore and dash. That means that we only need to
> > escape
> > > >the data part in the case of string returns.
> > >
> > > I agree about only allowing a subset of characters in names, so JSON
> > (and other) encoding is not required.
> > >
> > > However, I think we should be less restrictive, and also allow
> > characters commonly used for separation, indexing and wildcard, such as
> > '/', '[', ']', and '*', '?' or '%'.
> > >
> > > Obviously, we should disallow characters requiring escaping in not
> > just JSON, but also other foreseeable encodings and protocols. So
> > please bring your crystal ball to the discussion. ;-)
> > >
> > Exactly why I am looking for feedback - and why I'm looking to have an
> > explicit allowed list of characters rather than trying to just block
> > the
> > known-bad in json ones.
> > 
> > For your suggestions: +1 to separators and indexing, i.e. '[', ']' and
> > '/',
> > though I would probably also add ',' and maybe '.' (unless it's likely
> > to
> > cause issues with some protocol we are likely to want to use).
> 
> After having slept on it, I think we should also allow characters that could 
> appear in IP and MAC addresses, i.e. '.' and ':' (and '/' for subnetting).
> 
> > For the wildcarding, I find it hard to see why we would want those?
> 
> Initially, I thought a wildcard might be useful as a placeholder in templates.
> 
> But it might also be useful for partial IP or MAC addresses. E.g.:
> - The SmartShare Systems OUI could be represented by the MAC address 
> "00:1F:B4:??:??:??".
> - A default gateway address in a template configuration could be 
> "192.168.*.1".
> 
> On the other hand, wildcard characters could be disallowed or require 
> escaping in other (non-JSON) protocols.
> 
> So I'm just being a bit creative here, throwing out ideas in our search for 
> the right balance in the restrictions.
> 

I could see those characters certainly being needed in data values, but do
you foresee them being required in the names of fields?

> > 
> > The other advantage of using an allowlist of characters is that it
> > makes it
> > possible to expand over time, compared to a blocklist which always runs
> > the
> > risk of breaking something if you expand it. Therefore I suggest we
> > keep
> > the list as small as we need right now, and expand it only as we need.
> 
> +1
>

>From previous on-list discussion, I take it that SNMP is a possible target
protocol you might have in mind. Any other protocols you can think of and
what restrictions (if any) would SNMP or those other protocols add?

/Bruce 

Re: [PATCH] net/af_xdp: limit libbpf version to <= v0.7.0

[Thomas Monjalon]

24/06/2022 10:37, Loftus, Ciara:
> > 
> > 24/06/2022 08:06, Ciara Loftus:
> > > Linking with libbpf v0.8.0 causes deprication warnings. As a temporary
> > > measure, prevent linking with libbpf versions v0.8.0 and greater. This
> > > limitation should be removed in the future when appropriate
> > > compatibility measures are introduced.
> > >
> > > Signed-off-by: Ciara Loftus 
> > > ---
> > > -bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
> > > -if not bpf_dep.found()
> > > -bpf_dep = cc.find_library('bpf', required: false)
> > > -endif
> > > +bpf_dep = dependency('libbpf', version : '<=0.7.0', required: false,
> > method: 'pkg-config')
> > 
> > It is also removing the find_library() method.
> > Any reason it was there?
> > 
> 
> My understanding is that one can't check the library version using that 
> method.
> So it was a valid method of picking up the library until now where we always 
> need to check the version before linking.

OK I see

RE: [RFC PATCH 0/6] add json string escaping to telemetry

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 24 June 2022 11.17
> 
> On Fri, Jun 24, 2022 at 11:12:05AM +0200, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > Sent: Friday, 24 June 2022 10.14
> > >
> > > On Thu, Jun 23, 2022 at 09:04:31PM +0200, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > > Sent: Thursday, 23 June 2022 18.43
> > > > >
> > > > > This RFC shows one possible approach for escaping strings for
> the
> > > json
> > > > > output of telemetry library. For now this RFC supports escaping
> > > strings
> > > > > for the cases of returning a single string, or returning an
> array
> > > of
> > > > > strings. Not done is escaping of strings in objs/dicts [see
> more
> > > below
> > > > > on TODO]
> > > >
> > > > Very good initiative.
> > > >
> > > > >
> > > > > As well as telemetry lib changes, this patchset includes unit
> tests
> > > for
> > > > > the above and also little bit of cleanup to the json tests.
> > > > >
> > > > > TODO:
> > > > > Beyond what is here in this RFC:
> > > > >
> > > > > 1. we need to decide what to do about name/value pairs.
> Personally,
> > > I
> > > > >think we should add the restriction to the
> > > "rte_tel_data_add_obj_*"
> > > > > APIs
> > > > >to only allow a defined subset of characters in names: e.g.
> > > > > alphanumeric
> > > > >chars, underscore and dash. That means that we only need to
> > > escape
> > > > >the data part in the case of string returns.
> > > >
> > > > I agree about only allowing a subset of characters in names, so
> JSON
> > > (and other) encoding is not required.
> > > >
> > > > However, I think we should be less restrictive, and also allow
> > > characters commonly used for separation, indexing and wildcard,
> such as
> > > '/', '[', ']', and '*', '?' or '%'.
> > > >
> > > > Obviously, we should disallow characters requiring escaping in
> not
> > > just JSON, but also other foreseeable encodings and protocols. So
> > > please bring your crystal ball to the discussion. ;-)
> > > >
> > > Exactly why I am looking for feedback - and why I'm looking to have
> an
> > > explicit allowed list of characters rather than trying to just
> block
> > > the
> > > known-bad in json ones.
> > >
> > > For your suggestions: +1 to separators and indexing, i.e. '[', ']'
> and
> > > '/',
> > > though I would probably also add ',' and maybe '.' (unless it's
> likely
> > > to
> > > cause issues with some protocol we are likely to want to use).
> >
> > After having slept on it, I think we should also allow characters
> that could appear in IP and MAC addresses, i.e. '.' and ':' (and '/'
> for subnetting).
> >
> > > For the wildcarding, I find it hard to see why we would want those?
> >
> > Initially, I thought a wildcard might be useful as a placeholder in
> templates.
> >
> > But it might also be useful for partial IP or MAC addresses. E.g.:
> > - The SmartShare Systems OUI could be represented by the MAC address
> "00:1F:B4:??:??:??".
> > - A default gateway address in a template configuration could be
> "192.168.*.1".
> >
> > On the other hand, wildcard characters could be disallowed or require
> escaping in other (non-JSON) protocols.
> >
> > So I'm just being a bit creative here, throwing out ideas in our
> search for the right balance in the restrictions.
> >
> 
> I could see those characters certainly being needed in data values, but
> do
> you foresee them being required in the names of fields?

We don't use the Telemetry library, because we have our own libraries for 
similar and related purposes. So I'm mostly speculating, trying to transform 
our experience into how I would expect the Telemetry library to work, while 
also trying to look farther into the future.

Answering your question:

Yes, if you consider the names as keys in a key/value store, there might be 
single entries that look like a template. Although the names of such entries 
might as well be "00:1F:B4:xx:xx:xx" or "192.168.z.1", using 'x' and 'z' as the 
wildcard characters.

Perhaps we should start with the low risk choice, and not allow the special 
wild card characters, such as '*', '?', '%', since 'x' is just as good in those 
cases.

> 
> > >
> > > The other advantage of using an allowlist of characters is that it
> > > makes it
> > > possible to expand over time, compared to a blocklist which always
> runs
> > > the
> > > risk of breaking something if you expand it. Therefore I suggest we
> > > keep
> > > the list as small as we need right now, and expand it only as we
> need.
> >
> > +1
> >
> 
> From previous on-list discussion, I take it that SNMP is a possible
> target
> protocol you might have in mind. Any other protocols you can think of
> and
> what restrictions (if any) would SNMP or those other protocols add?

JSON and UTF-8 seems to have taken over the world entirely.

SNMP support is usually required for legacy reasons. The SNMP looku

[PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Ciara Loftus]

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 
---
 doc/guides/nics/af_xdp.rst  |  3 ++-
 drivers/net/af_xdp/compat.h | 36 -
 drivers/net/af_xdp/meson.build  |  7 ++
 drivers/net/af_xdp/rte_eth_af_xdp.c | 19 +++
 4 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index 56681c8365..9edb48df67 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -43,7 +43,8 @@ Prerequisites
 This is a Linux-specific PMD, thus the following prerequisites apply:
 
 *  A Linux Kernel (version > v4.18) with XDP sockets configuration enabled;
-*  Both libxdp >=v1.2.2 and libbpf libraries installed, or, libbpf <=v0.6.0
+*  Both libxdp >=v1.2.2 and libbpf <=v0.8.0 libraries installed, or, libbpf
+   <=v0.6.0.
 *  If using libxdp, it requires an environment variable called
LIBXDP_OBJECT_PATH to be set to the location of where libxdp placed its bpf
object files. This is usually in /usr/local/lib/bpf or /usr/local/lib64/bpf.
diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h
index 28ea64aeaa..8f4ac8b5ea 100644
--- a/drivers/net/af_xdp/compat.h
+++ b/drivers/net/af_xdp/compat.h
@@ -60,7 +60,7 @@ tx_syscall_needed(struct xsk_ring_prod *q __rte_unused)
 }
 #endif
 
-#ifdef RTE_NET_AF_XDP_LIBBPF_OBJ_OPEN
+#ifdef RTE_NET_AF_XDP_LIBBPF_V070
 static int load_program(const char *prog_path, struct bpf_object **obj)
 {
struct bpf_program *prog;
@@ -85,6 +85,23 @@ static int load_program(const char *prog_path, struct 
bpf_object **obj)
bpf_object__close(*obj);
return -1;
 }
+
+static int
+remove_xdp_program(int ifindex)
+{
+   uint32_t curr_prog_id = 0;
+
+   if (bpf_xdp_query_id(ifindex, XDP_FLAGS_UPDATE_IF_NOEXIST,
+   &curr_prog_id))
+   return -1;
+
+   return bpf_xdp_detach(ifindex, XDP_FLAGS_UPDATE_IF_NOEXIST, NULL);
+}
+
+static int link_xdp_prog_with_dev(int ifindex, int fd, __u32 flags)
+{
+   return bpf_xdp_attach(ifindex, fd, flags, NULL);
+}
 #else
 static int load_program(const char *prog_path, struct bpf_object **obj)
 {
@@ -96,4 +113,21 @@ static int load_program(const char *prog_path, struct 
bpf_object **obj)
 
return prog_fd;
 }
+
+static int
+remove_xdp_program(int ifindex)
+{
+   uint32_t curr_prog_id = 0;
+
+   if (bpf_get_link_xdp_id(ifindex, &curr_prog_id,
+   XDP_FLAGS_UPDATE_IF_NOEXIST))
+   return -1;
+
+   return bpf_set_link_xdp_fd(ifindex, -1, XDP_FLAGS_UPDATE_IF_NOEXIST);
+}
+
+static int link_xdp_prog_with_dev(int ifindex, int fd, __u32 flags)
+{
+   return bpf_set_link_xdp_fd(ifindex, fd, flags);
+}
 #endif
diff --git a/drivers/net/af_xdp/meson.build b/drivers/net/af_xdp/meson.build
index 1e0de23705..349f8e7c12 100644
--- a/drivers/net/af_xdp/meson.build
+++ b/drivers/net/af_xdp/meson.build
@@ -10,10 +10,7 @@ endif
 sources = files('rte_eth_af_xdp.c')
 
 xdp_dep = dependency('libxdp', version : '>=1.2.2', required: false, method: 
'pkg-config')
-bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
-if not bpf_dep.found()
-bpf_dep = cc.find_library('bpf', required: false)
-endif
+bpf_dep = dependency('libbpf', version : '<=0.8.0', required: false, method: 
'pkg-config')
 
 if cc.has_header('linux/if_xdp.h')
 if xdp_dep.found() and cc.has_header('xdp/xsk.h')
@@ -25,7 +22,7 @@ if cc.has_header('linux/if_xdp.h')
 bpf_ver_dep = dependency('libbpf', version : '>=0.7.0',
  required: false, method: 'pkg-config')
 if bpf_ver_dep.found()
-cflags += ['-DRTE_NET_AF_XDP_LIBBPF_OBJ_OPEN']
+cflags += ['-DRTE_NET_AF_XDP_LIBBPF_V070']
 endif
 else
 build = false
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c 
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 1e37da6e84..943d5c9838 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -863,20 +863,6 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
 }
 
-static void
-remove_xdp_program(struct pmd_internals *internals)
-{
-   uint32_t curr_prog_id = 0;
-
-   if (bpf_get_link_xdp_id(internals->if_index, &curr_prog_id,
-   XDP_FLAGS_UPDATE_IF_NOEXIST)) {
-   AF_XDP_LOG(ERR, "bpf_get_link_xdp_id failed\n");
-   return;
-   }
-   bpf_set_link_xdp_fd(internals->if_index, -1,
-   XDP_FLAGS_UPDATE_IF_NOEXIST);
-}
-
 static void
 xdp_umem_destroy(struct xsk_umem_info *umem)
 

Re: [PATCH V5 0/7] app/testpmd: fix RSS and flow type

[Ferruh Yigit]

On 6/24/2022 10:54 AM, lihuisong (C) wrote:
CAUTION: This message has originated from an External Source. Please use 
proper judgment and caution when opening attachments, clicking links, or 
responding to this email.



Hi David,

在 2022/6/24 16:59, David Marchand 写道:
On Fri, Jun 24, 2022 at 10:55 AM lihuisong (C)  
wrote:

Hi Ferruh,

This patchset has been sent. However, a merge conflict is displayed on
the CI.
In fact, I'm do it based on the latest mainline, and there are nothing
conflict.

Can you help me re-trigger the build?

There may be different reasons why (likely on your side), but
patchwork does not see the patches you sent as a single series.
For example, patch 4 is seen as part of the v2 series.

The CI tools rely on patchwork.
So the various CI won't be able to apply them.

Please resend.

Thanks. It's the patchwork problem. This patchset are assigned to two
series.
As shown in the link below:
http://patches.dpdk.org/project/dpdk/list/?series=&submitter=2085&state=&q=&archive=&delegate= 



If I resend, but this patchset hasn't changed.
Do I need to change the version number of this patchset?


Hi Huisong,

I think both are OK, but just to clarify which one is latest, I think 
there is no harm to increase the version.

Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Bruce Richardson]

On Fri, Jun 24, 2022 at 09:00:38AM +0100, Bruce Richardson wrote:
> On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Brørup wrote:
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Thursday, 23 June 2022 20.40
> > > 
> > > On Thu, 23 Jun 2022 20:34:07 +0200
> > > Morten Brørup  wrote:
> > > 
> > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > > Sent: Thursday, 23 June 2022 18.43
> > > > >
> > > > > For string values returned from telemetry, escape any values that
> > > > > cannot
> > > > > normally appear in a json string. According to the json spec[1],
> > > the
> > > > > characters than need to be handled are control chars (char value <
> > > > > 0x20)
> > > > > and '"' and '\' characters.
> > > >
> > > > Correct. Other chars are optional to escape.
> > > 
> > > For json_writer (which I wrote for iproute2 and could have been used
> > > here).
> > > The switch handles: \t \n \r \f \b \\ " ' as special cases.
> > 
> > RFC 8259 chapter 7 says:
> > 
> >All Unicode characters may be placed within the
> >quotation marks, except for the characters that MUST be escaped:
> >quotation mark, reverse solidus, and the control characters (U+
> >through U+001F).
> > 
> > I have no preference for either, as long as '/' and other non-control 
> > characters are not (unnecessarily) escaped.
> > 
> > Using tested and maintained code like json_writer could be beneficial. If 
> > you hold the copyright, there should be no license issues.
> > 
> 
> I will take a look at json_writer.

Took a quick look at json_writer, and it's certainly an option. The main
gap compared to what we have in our current implementation is that
json_writer is designed around a stream for output rather than an output
buffer. Now while we can use fmemopen to make our buffer act as a stream
for writing, and the write apis should prevent it overflowing, we still hit
the issue of the result of truncation not being valid json. The current
implementation tries to handle truncation more gracefully in that any
fields which don't fit just don't get added.

I'll think about it a bit more, and see if there is a way that it can be
made to work more cleanly.

/Bruce

PS: just changing the output from a string to a stream on the output socket
I don't believe is an option either, as the socket type used for telemetry
is a SOCK_SEQPACKET where message boundaries are preserved, and a single
read will return the entire telemetry reply.

RE: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 24 June 2022 13.17
> 
> On Fri, Jun 24, 2022 at 09:00:38AM +0100, Bruce Richardson wrote:
> > On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Brørup wrote:
> > > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > > Sent: Thursday, 23 June 2022 20.40
> > > >
> > > > On Thu, 23 Jun 2022 20:34:07 +0200
> > > > Morten Brørup  wrote:
> > > >
> > > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > > > Sent: Thursday, 23 June 2022 18.43
> > > > > >
> > > > > > For string values returned from telemetry, escape any values
> that
> > > > > > cannot
> > > > > > normally appear in a json string. According to the json
> spec[1],
> > > > the
> > > > > > characters than need to be handled are control chars (char
> value <
> > > > > > 0x20)
> > > > > > and '"' and '\' characters.
> > > > >
> > > > > Correct. Other chars are optional to escape.
> > > >
> > > > For json_writer (which I wrote for iproute2 and could have been
> used
> > > > here).
> > > > The switch handles: \t \n \r \f \b \\ " ' as special cases.
> > >
> > > RFC 8259 chapter 7 says:
> > >
> > >All Unicode characters may be placed within the
> > >quotation marks, except for the characters that MUST be escaped:
> > >quotation mark, reverse solidus, and the control characters
> (U+
> > >through U+001F).
> > >
> > > I have no preference for either, as long as '/' and other non-
> control characters are not (unnecessarily) escaped.
> > >
> > > Using tested and maintained code like json_writer could be
> beneficial. If you hold the copyright, there should be no license
> issues.
> > >
> >
> > I will take a look at json_writer.
> 
> Took a quick look at json_writer, and it's certainly an option. The
> main
> gap compared to what we have in our current implementation is that
> json_writer is designed around a stream for output rather than an
> output
> buffer. Now while we can use fmemopen to make our buffer act as a
> stream
> for writing, and the write apis should prevent it overflowing, we still
> hit
> the issue of the result of truncation not being valid json. The current
> implementation tries to handle truncation more gracefully in that any
> fields which don't fit just don't get added.
> 
> I'll think about it a bit more, and see if there is a way that it can
> be
> made to work more cleanly.

It sounds like json_writer provides a more advanced API, adding a lot of 
overhead for wrapping it into the Telemetry library. Since we only need a very 
simple encoder, perhaps copy-paste-modify is more viable. Or just proceed with 
your RFC code.

Regardless, the API and underlying code probably needs extra scrutiny, so it 
doesn't become an attack vector into the control plane of a DPDK application.

> 
> /Bruce
> 
> PS: just changing the output from a string to a stream on the output
> socket
> I don't believe is an option either, as the socket type used for
> telemetry
> is a SOCK_SEQPACKET where message boundaries are preserved, and a
> single
> read will return the entire telemetry reply.

[PATCH] doc: add list of environment variables used by cnxk

[Nithin Dabilpuram]

Add list of environment variables used by cnxk drivers.

Signed-off-by: Nithin Dabilpuram 
---
 doc/guides/platform/cnxk.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/guides/platform/cnxk.rst b/doc/guides/platform/cnxk.rst
index 423b3d7..97b2be5 100644
--- a/doc/guides/platform/cnxk.rst
+++ b/doc/guides/platform/cnxk.rst
@@ -620,3 +620,18 @@ CN10K:
if Marvell toolchain is available then it can be used by overriding the
c, cpp, ar, strip ``binaries`` attributes to respective Marvell
toolchain binaries in ``config/arm/arm64_cn10k_linux_gcc`` file.
+
+Environment Variables
+~
+
+* ``BPHY_INTR_MLOCK_DISABLE``
+   When defined disables memory locking in
+   BPHY environment.
+
+* ``ROC_CN10K_MBOX_TIMEOUT``, ``ROC_MBOX_TIMEOUT``
+   When set, overrides MBOX timeout by value in milli seconds.
+
+* ``ETH_SEC_IV_OVR``
+   When set, overrides outbound inline SA IV. By default IV is generated
+   by HW. Format of variable is string of comma separated one byte values as
+   for ex: "0x0, 0x10, 0x20, ..."
-- 
2.8.4

Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0

[Andrew Rybchenko]

On 6/24/22 13:23, Ciara Loftus wrote:

libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.

Also prevent linking with libbpf versions > v0.8.0.

Signed-off-by: Ciara Loftus 
---
  doc/guides/nics/af_xdp.rst  |  3 ++-
  drivers/net/af_xdp/compat.h | 36 -
  drivers/net/af_xdp/meson.build  |  7 ++
  drivers/net/af_xdp/rte_eth_af_xdp.c | 19 +++
  4 files changed, 42 insertions(+), 23 deletions(-)


Don't we need to mention these changes in release notes?



diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index 56681c8365..9edb48df67 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -43,7 +43,8 @@ Prerequisites
  This is a Linux-specific PMD, thus the following prerequisites apply:
  
  *  A Linux Kernel (version > v4.18) with XDP sockets configuration enabled;

-*  Both libxdp >=v1.2.2 and libbpf libraries installed, or, libbpf <=v0.6.0
+*  Both libxdp >=v1.2.2 and libbpf <=v0.8.0 libraries installed, or, libbpf
+   <=v0.6.0.
  *  If using libxdp, it requires an environment variable called
 LIBXDP_OBJECT_PATH to be set to the location of where libxdp placed its bpf
 object files. This is usually in /usr/local/lib/bpf or 
/usr/local/lib64/bpf.
diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h
index 28ea64aeaa..8f4ac8b5ea 100644
--- a/drivers/net/af_xdp/compat.h
+++ b/drivers/net/af_xdp/compat.h
@@ -60,7 +60,7 @@ tx_syscall_needed(struct xsk_ring_prod *q __rte_unused)
  }
  #endif
  
-#ifdef RTE_NET_AF_XDP_LIBBPF_OBJ_OPEN

+#ifdef RTE_NET_AF_XDP_LIBBPF_V070


Typically version-based checks are considered as bad. Isn't it
better use feature-based checks/defines?

Re: [PATCH] net/af_xdp: limit libbpf version to <= v0.7.0

[Andrew Rybchenko]

On 6/24/22 13:10, Thomas Monjalon wrote:

24/06/2022 10:37, Loftus, Ciara:


24/06/2022 08:06, Ciara Loftus:

Linking with libbpf v0.8.0 causes deprication warnings. As a temporary
measure, prevent linking with libbpf versions v0.8.0 and greater. This
limitation should be removed in the future when appropriate
compatibility measures are introduced.

Signed-off-by: Ciara Loftus 
---
-bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
-if not bpf_dep.found()
-bpf_dep = cc.find_library('bpf', required: false)
-endif
+bpf_dep = dependency('libbpf', version : '<=0.7.0', required: false,

method: 'pkg-config')

It is also removing the find_library() method.
Any reason it was there?



My understanding is that one can't check the library version using that method.
So it was a valid method of picking up the library until now where we always 
need to check the version before linking.


OK I see


IMHO checking library version is a bad approach. We should file
the library of whatever version and check for symbols etc in it
and provide corresponding HAVE_ defines to handle it in code.

Re: [PATCH] rte_rib6: fix references to rte_rib

[Medvedkin, Vladimir]

Acked-by: Vladimir Medvedkin 

On 22/06/2022 21:41, Stephen Hemminger wrote:

The comments in rte_rib6 were cut-and-pasted from rte_rib
and because of that some references to rte_rib_node were
not updated.

Signed-off-by: Stephen Hemminger 
---
  lib/rib/rte_rib6.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/rib/rte_rib6.h b/lib/rib/rte_rib6.h
index fa8e9bf7327b..36a79ae2accb 100644
--- a/lib/rib/rte_rib6.h
+++ b/lib/rib/rte_rib6.h
@@ -39,12 +39,12 @@ struct rte_rib6_node;
  /** RIB configuration structure */
  struct rte_rib6_conf {
/**
-* Size of extension block inside rte_rib_node.
+* Size of extension block inside rte_rib6_node.
 * This space could be used to store additional user
 * defined data.
 */
size_t  ext_sz;
-   /* size of rte_rib_node's pool */
+   /* size of rte_rib6_node's pool */
int max_nodes;
  };
  
@@ -306,7 +306,7 @@ rte_rib6_create(const char *name, int socket_id,

   * Find an existing RIB object and return a pointer to it.
   *
   * @param name
- *  Name of the rib object as passed to rte_rib_create()
+ *  Name of the rib object as passed to rte_rib6_create()
   * @return
   *  Pointer to RIB object on success
   *  NULL otherwise with rte_errno indicating reason for failure.


--
Regards,
Vladimir

Re: [PATCH] maintainers: update for hns3 pmd

[Ferruh Yigit]

On 6/24/2022 7:52 AM, Yisen Zhuang wrote:


On 2022/6/22 18:49, Dongdong Liu wrote:

Lijun Ou and Min Hu current do not work for the hns3 pmd.
I will do the work, so update the hns3 maintainers.

Signed-off-by: Dongdong Liu 


Acked-by: Yisen Zhuang 


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

Re: [PATCH 1/2] net/hns3: fix fail to obtain VF LSC capability

[Ferruh Yigit]

On 6/11/2022 8:42 AM, Dongdong Liu wrote:

From: Huisong Li 

Currently, the VF LSC capability is obtained from PF driver in
the interrupt mailbox interrupt thread, it is asynchronous.
The VF driver waits for 500ms to get this capability in probe
process.

The primary process will receive a message and do probe in the
interrupt thread context when attach a device in the secondary
process. At this case, VF driver never obtains this capability
from PF.

The root cause is that 'vf->pf_push_lsc_cap' is not updated by
the handling mailbox thread until finishing probe. The reason
this update wouldn't be done is that the handling mailbox interrupt
thread and the probe alarm thread are both in epool thread, and
the probe alarm thread is before the mailbox interrupt thread.

Fixes: 9bc2289fe5ea ("net/hns3: refactor VF LSC event report")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 


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

Re: [PATCH V3 2/2] net/hns3: support backplane media type

[Ferruh Yigit]

On 6/22/2022 11:59 AM, Dongdong Liu wrote:

From: Chengwen Feng 

The 802.11 physical PMA sub-layer defines three media: copper, fiber and
backplane. For PMD, the backplane is similar to the fiber, the main
differences are that backplane doesn't have optical module.

Because the interface of firmware fiber is also applicable to the
backplane, this patch supports the backplane only through simple
extension.

Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
Signed-off-by: Dongdong Liu 


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

Re: [PATCH 0/2] remove unnecessary words in function documention

[David Marchand]

On Wed, Jun 22, 2022 at 10:27 PM Stephen Hemminger
 wrote:
>
> The phrase "This API is used to" is unnecessary and changes the
> documentation into passive voice.
>
> Stephen Hemminger (2):
>   rawdev, dmadev: remove passive voice in function doc
>   eal: remove passive voice from interrupt function documentation
>
>  drivers/raw/ioat/rte_ioat_rawdev.h |  2 +-
>  lib/dmadev/rte_dmadev.h|  2 +-
>  lib/eal/include/rte_interrupts.h   | 23 +++
>  3 files changed, 13 insertions(+), 14 deletions(-)

Applied, thanks.


-- 
David Marchand

[RFC PATCH] cryptodev: add return parameter to callback process API

[Srujana Challa]

Adds a return parameter "uint16_t qp_id" to the functions
rte_cryptodev_pmd_callback_process and rte_cryptodev_cb_fn.
The new parameter is used to return queue pair ID to
the application when it gets error interrupt, so that
application can disable and enable the queue pair, to bring
the queue back to normal state.

Signed-off-by: Srujana Challa 
Change-Id: I423c4fd6b8c3d910c60e3a6d4f17534756299213
---
 lib/cryptodev/cryptodev_pmd.h | 3 ++-
 lib/cryptodev/rte_cryptodev.c | 8 
 lib/cryptodev/rte_cryptodev.h | 9 ++---
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 3dcc3cb7ed..f087b58161 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -560,6 +560,7 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev *cryptodev);
  * device.
  *  *
  * @param  dev Pointer to cryptodev struct
+ * @param  qp_id   To pass qp_id, which got interrupt, to user application.
  * @param  event   Crypto device interrupt event type.
  *
  * @return
@@ -567,7 +568,7 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev *cryptodev);
  */
 __rte_internal
 void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
-   enum rte_cryptodev_event_type event);
+   uint16_t qp_id, enum rte_cryptodev_event_type event);
 
 /**
  * @internal
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 42f3221052..eee208ce2d 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -1689,8 +1689,8 @@ rte_cryptodev_callback_unregister(uint8_t dev_id,
 }
 
 void
-rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
-   enum rte_cryptodev_event_type event)
+rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev, uint16_t qp_id,
+  enum rte_cryptodev_event_type event)
 {
struct rte_cryptodev_callback *cb_lst;
struct rte_cryptodev_callback dev_cb;
@@ -1702,8 +1702,8 @@ rte_cryptodev_pmd_callback_process(struct rte_cryptodev 
*dev,
dev_cb = *cb_lst;
cb_lst->active = 1;
rte_spinlock_unlock(&rte_cryptodev_cb_lock);
-   dev_cb.cb_fn(dev->data->dev_id, dev_cb.event,
-   dev_cb.cb_arg);
+   dev_cb.cb_fn(dev->data->dev_id, qp_id, dev_cb.event,
+dev_cb.cb_arg);
rte_spinlock_lock(&rte_cryptodev_cb_lock);
cb_lst->active = 0;
}
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 56f459c6a0..6b41262735 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -577,13 +577,16 @@ typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t 
dev_id, uint16_t qp_id,
  * software for notification of device events
  *
  * @param  dev_id  Crypto device identifier
+ * @param  qp_id   Return parameter from driver to the application. Driver
+ * returns queue pair ID when it gets HW error interrupt.
+ * The application can release and setup the queue
+ * again, to bring the HW queue back to normal state.
  * @param  event   Crypto device event to register for notification of.
  * @param  cb_arg  User specified parameter to be passed as to passed to
  * users callback function.
  */
-typedef void (*rte_cryptodev_cb_fn)(uint8_t dev_id,
-   enum rte_cryptodev_event_type event, void *cb_arg);
-
+typedef void (*rte_cryptodev_cb_fn)(uint8_t dev_id, uint16_t qp_id,
+   enum rte_cryptodev_event_type event, void *cb_arg);
 
 /** Crypto Device statistics */
 struct rte_cryptodev_stats {
-- 
2.25.1

[RFC PATCH] cryptodev: add return parameter to callback process API

[Srujana Challa]

Adds a return parameter "uint16_t qp_id" to the functions
rte_cryptodev_pmd_callback_process and rte_cryptodev_cb_fn.
The new parameter is used to return queue pair ID to
the application when it gets error interrupt, so that
application can disable and enable the queue pair, to bring
the queue back to normal state.

Signed-off-by: Srujana Challa 
---
 lib/cryptodev/cryptodev_pmd.h | 3 ++-
 lib/cryptodev/rte_cryptodev.c | 8 
 lib/cryptodev/rte_cryptodev.h | 9 ++---
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 3dcc3cb7ed..f087b58161 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -560,6 +560,7 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev *cryptodev);
  * device.
  *  *
  * @param  dev Pointer to cryptodev struct
+ * @param  qp_id   To pass qp_id, which got interrupt, to user application.
  * @param  event   Crypto device interrupt event type.
  *
  * @return
@@ -567,7 +568,7 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev *cryptodev);
  */
 __rte_internal
 void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
-   enum rte_cryptodev_event_type event);
+   uint16_t qp_id, enum rte_cryptodev_event_type event);
 
 /**
  * @internal
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 42f3221052..eee208ce2d 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -1689,8 +1689,8 @@ rte_cryptodev_callback_unregister(uint8_t dev_id,
 }
 
 void
-rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
-   enum rte_cryptodev_event_type event)
+rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev, uint16_t qp_id,
+  enum rte_cryptodev_event_type event)
 {
struct rte_cryptodev_callback *cb_lst;
struct rte_cryptodev_callback dev_cb;
@@ -1702,8 +1702,8 @@ rte_cryptodev_pmd_callback_process(struct rte_cryptodev 
*dev,
dev_cb = *cb_lst;
cb_lst->active = 1;
rte_spinlock_unlock(&rte_cryptodev_cb_lock);
-   dev_cb.cb_fn(dev->data->dev_id, dev_cb.event,
-   dev_cb.cb_arg);
+   dev_cb.cb_fn(dev->data->dev_id, qp_id, dev_cb.event,
+dev_cb.cb_arg);
rte_spinlock_lock(&rte_cryptodev_cb_lock);
cb_lst->active = 0;
}
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 56f459c6a0..6b41262735 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -577,13 +577,16 @@ typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t 
dev_id, uint16_t qp_id,
  * software for notification of device events
  *
  * @param  dev_id  Crypto device identifier
+ * @param  qp_id   Return parameter from driver to the application. Driver
+ * returns queue pair ID when it gets HW error interrupt.
+ * The application can release and setup the queue
+ * again, to bring the HW queue back to normal state.
  * @param  event   Crypto device event to register for notification of.
  * @param  cb_arg  User specified parameter to be passed as to passed to
  * users callback function.
  */
-typedef void (*rte_cryptodev_cb_fn)(uint8_t dev_id,
-   enum rte_cryptodev_event_type event, void *cb_arg);
-
+typedef void (*rte_cryptodev_cb_fn)(uint8_t dev_id, uint16_t qp_id,
+   enum rte_cryptodev_event_type event, void *cb_arg);
 
 /** Crypto Device statistics */
 struct rte_cryptodev_stats {
-- 
2.25.1

Re: [PATCH v4] lib: document existing free functions

[David Marchand]

On Wed, Jun 22, 2022 at 10:53 PM Stephen Hemminger
 wrote:
>
> Make sure all functions which use the convention that XXX_free(NULL)
> is a nop are all documented.
>
> The wording is chosen to match the documentation of free(3).
> "If ptr is NULL, no operation is performed."
>
> Signed-off-by: Stephen Hemminger 

Squashed similar updates for acl, lpm and pipeline API that were in
https://patchwork.dpdk.org/project/dpdk/list/?series=21752&state=*
series, and applied.
Thanks.

-- 
David Marchand

Re: [PATCH 0/6] some bugfixes for hns3

[Andrew Rybchenko]

On 6/24/22 11:59, Dongdong Liu wrote:

The patchset include some bugfixes and clean code for hns3.

The patchset depend on the below patchset to avoid confilict.
[PATCH 0/2] net/hns3: support backplane media type
https://lore.kernel.org/all/8689c6e8-935b-e2dc-3276-d2970a8bd...@xilinx.com/T/

Chengwen Feng (1):
   net/hns3: fix nb-desc not verified when using SVE

Dongdong Liu (2):
   net/hns3: make code more clean
   net/hns3: delete the unused code

Huisong Li (3):
   net/hns3: cancel heartbeat alarm when VF reset
   net/hns3: fix received unknown event print when PTP enable
   net/hns3: fix statistic lock

  drivers/net/hns3/hns3_cmd.c   | 33 ---
  drivers/net/hns3/hns3_ethdev.c| 13 +++-
  drivers/net/hns3/hns3_ethdev_vf.c |  6 ++
  drivers/net/hns3/hns3_rxtx.c  | 13 +---
  drivers/net/hns3/hns3_stats.c | 22 +
  5 files changed, 23 insertions(+), 64 deletions(-)

--
2.22.0



With submitted Signed-off-by added to the first patch

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

Re: [PATCH 0/3] more null pointer check removal

[David Marchand]

On Wed, Jun 22, 2022 at 8:52 PM Stephen Hemminger
 wrote:
>
> Reran the Cocci script to check for unnecessary null
> pointer comparisons before free related functions.

Applied with series
https://patchwork.dpdk.org/project/dpdk/list/?series=21752&state=*

-- 
David Marchand

Re: [PATCH v3 0/8] yet more unnecessary NULL checks

[David Marchand]

On Sun, Feb 20, 2022 at 7:22 PM Stephen Hemminger
 wrote:
>
> Thomas suggested there are some other functions that could
> use the nullfree cleanup; this covers the rest of the story.
>
> Note: this does not change existing API/ABI, there are still
> some outliers that don't use the convention but fixing these
> will have to wait until next LTS.
>
> v3 - fix another typo and add more functions
>
> v2 - fix spelling typo and add functions
>
> Stephen Hemminger (8):
>   cocci/nullfree: add more functions
>   acl: remove unnecessary null checks
>   lpm: remove unnecessary NULL checks
>   lib: document existing free functions
>   test: remove unnecessary NULL checks before free
>   fips_validation: remove unnecessary NULL check
>   event/sw: remove unnecessary NULL check
>   pipeline: remove unnecessary checks for NULL pointer before free

Series applied.
I reran the script and fixed two more instances.

Thanks for the cleanup Stephen.


-- 
David Marchand

Re: [PATCH v5 1/1] app/testpmd: support different input color method

[Andrew Rybchenko]

On 6/23/22 15:57, sk...@marvell.com wrote:

From: Sunil Kumar Kori 

To enable input coloring, based on VLAN or DSCP, patch adds
command line interface to configure the following:

  - configuring input coloring using VLAN or DSCP while creating
meter i.e. during rte_mtr_create()

  - Update VLAN input coloring table at runtime.

  - configures protocol priorities.

  - retrieve protocol and priority information

Depends-on: patch-22751 ("ethdev: mtr: support protocol based input color 
selection")

Signed-off-by: Sunil Kumar Kori 
Acked-by: Cristian Dumitrescu 
---
v4..v5:
  - Update testpmd user guide.

v3..v4:
  - Replace strcmp with strcasecmp whereever is needed.
  
v2..v3:

  - Rebased to branch ToT dpdk-next-net/main
  - Fix static keyword for newly added token parsing symbols

v1..v2:
  - Rebased to branch dpdk-next-net
  - add CLIs for input coloring mechanism

  app/test-pmd/cmdline.c  |   4 +
  app/test-pmd/cmdline_mtr.c  | 552 +++-
  app/test-pmd/cmdline_mtr.h  |   4 +
  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  35 +-
  4 files changed, 587 insertions(+), 8 deletions(-)


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

Re: [PATCH V5 1/7] app/testpmd: fix supported RSS offload display

[Ferruh Yigit]

On 6/24/2022 8:23 AM, Huisong Li wrote:


The rte_eth_dev_info.flow_type_rss_offloads is populated in terms of
RTE_ETH_RSS_* bits. If PMD sets RTE_ETH_RSS_L3_SRC_ONLY to
dev_info->flow_type_rss_offloads. testpmd will display "user defined 63"
when run 'show port info 0'. Because testpmd use flowtype_to_str()
to display the supported RSS offload of PMD. In fact, the function is
used to display flow type in FDIR commands for i40e or ixgbe. This patch
uses the RTE_ETH_RSS_* bits to display supported RSS offload of PMD.

In addition, offloads that are not in rss_type_table[] should be displayed
as "unknown offload xxx", instead of "user defined 63". So this patch fixes
it.



There is something as "user defined" RSS type, so please keep it as it is.
For more details please check:
Commit 8b94c81e3341 ("app/testpmd: port info prints dynamically mapped 
flow types")

Commit 5a4806d304e0 ("app/testpmd: support updating pctype mapping")

Simply this is to allow doing RSS on user defined protocols, supported 
by plugging like Intel DDP.



Fixes: b12964f621dc ("ethdev: unification of RSS offload types")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Ferruh Yigit 
---
  app/test-pmd/config.c  | 40 ++--
  app/test-pmd/testpmd.h |  2 ++
  2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 62833fe97c..36a828307c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -66,8 +66,6 @@

  #define NS_PER_SEC 1E9

-static char *flowtype_to_str(uint16_t flow_type);
-
  static const struct {
 enum tx_pkt_split split;
 const char *name;
@@ -675,6 +673,19 @@ print_dev_capabilities(uint64_t capabilities)
 }
  }

+const char *
+rsstypes_to_str(uint64_t rss_type)
+{
+   uint16_t i;
+
+   for (i = 0; rss_type_table[i].str != NULL; i++) {
+   if (rss_type_table[i].rss_type == rss_type)
+   return rss_type_table[i].str;
+   }
+
+   return NULL;
+}
+
  void
  port_infos_display(portid_t port_id)
  {
@@ -779,19 +790,20 @@ port_infos_display(portid_t port_id)
 if (!dev_info.flow_type_rss_offloads)
 printf("No RSS offload flow type is supported.\n");
 else {
+   uint64_t rss_offload_types = dev_info.flow_type_rss_offloads;
 uint16_t i;
-   char *p;

 printf("Supported RSS offload flow types:\n");
-   for (i = RTE_ETH_FLOW_UNKNOWN + 1;
-i < sizeof(dev_info.flow_type_rss_offloads) * CHAR_BIT; 
i++) {
-   if (!(dev_info.flow_type_rss_offloads & (1ULL << i)))
-   continue;
-   p = flowtype_to_str(i);
-   if (p)
-   printf("  %s\n", p);
-   else
-   printf("  user defined %d\n", i);
+   for (i = 0; i < sizeof(rss_offload_types) * CHAR_BIT; i++) {
+   uint64_t rss_offload = RTE_BIT64(i);


This logic is wrong, as we talked before some RSS types can be multiple 
bit, with about logic you can't catch them.


The logic in the V2 of this set [1] is correct, which walks through 
'rss_type_table[]' array and check if any value in that array exists in 
'flow_type_rss_offloads'.


[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220425092523.52338-2-lihuis...@huawei.com/


+   if ((rss_offload_types & rss_offload) != 0) {
+   const char *p = rsstypes_to_str(rss_offload);
+   if (p)
+   printf("  %s\n", p);
+   else
+   printf("  unknown_offload(BIT(%u))\n",
+  i);
+   }
 }
 }

@@ -5604,6 +5616,8 @@ set_record_burst_stats(uint8_t on_off)
 record_burst_stats = on_off;
  }

+#if defined(RTE_NET_I40E) || defined(RTE_NET_IXGBE)
+
  static char*
  flowtype_to_str(uint16_t flow_type)
  {
@@ -5647,8 +5661,6 @@ flowtype_to_str(uint16_t flow_type)
 return NULL;
  }

-#if defined(RTE_NET_I40E) || defined(RTE_NET_IXGBE)
-
  static inline void
  print_fdir_mask(struct rte_eth_fdir_masks *mask)
  {
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index eeefb5e70f..195488b602 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -1199,6 +1199,8 @@ extern int flow_parse(const char *src, void *result, 
unsigned int size,
   struct rte_flow_item **pattern,
   struct rte_flow_action **actions);

+const char *rsstypes_to_str(uint64_t rss_type);
+
  /* For registering driver specific testpmd commands. */
  struct testpmd_driver_commands {
 TAILQ_ENTRY(testpmd_driver_commands) next;
--
2.33.0

[PATCH v4 0/5] Improve documentation for running as non-root

[Dmitry Kozlyuk]

v4: Same,
- Split dpdk-hugepages.py option --owner/-o
  into --user/-U and --group/-G.
- Move vfio-pci note to the beginning of section.

v3: Address comments by Bruce Richardson:
- Remove the section for using UIO with older kernels.
- Move the note about legacy virtio to virtio doc.
- Advertise vfio-pci usage to avoid physical addresses
  (still unclear whether and when it requires IPC_LOCK).
- Fix typo.

v2: Address comments by Stephen Hemminger:
- Use hugetlbfs options instead of chown.
- Suggest using OS or container runtime where possible.
- Improve wording.
Add SYS_RAWIO requirement for legacy virtio.
Explain SYS_RAWIO requirement for MLX5 PMD.

Dmitry Kozlyuk (5):
  usertools: add option to select hugetlbfs directory
  usertools: add options to change mount point owner
  doc: give specific instructions for running as non-root
  doc: update instructions for running as non-root for MLX5
  doc: add note about running virtio-legacy as non-root

 doc/guides/linux_gsg/enable_func.rst  | 90 +--
 doc/guides/nics/virtio.rst|  3 +
 doc/guides/platform/mlx5.rst  | 31 ---
 .../prog_guide/env_abstraction_layer.rst  |  2 +
 usertools/dpdk-hugepages.py   | 26 +-
 5 files changed, 109 insertions(+), 43 deletions(-)

-- 
2.25.1

[PATCH v4 1/5] usertools: add option to select hugetlbfs directory

[Dmitry Kozlyuk]

dpdk-hugepages.py had /dev/hugepages hardcoded as the mount point.
It may be desirable to setup hugepage directory at another path,
for example, when using hugepages of multiple sizes in different
directories or when granting different permissions to mount points.
Add --directory/-d option to the script.

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Bruce Richardson 
---
 usertools/dpdk-hugepages.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
index 4fdb199744..8bab086a2f 100755
--- a/usertools/dpdk-hugepages.py
+++ b/usertools/dpdk-hugepages.py
@@ -228,6 +228,12 @@ def main():
 '-u',
 action='store_true',
 help='unmount the system huge page directory')
+parser.add_argument(
+'--directory',
+'-d',
+metavar='DIR',
+default=HUGE_MOUNT,
+help='mount point')
 parser.add_argument(
 '--node', '-n', help='select numa node to reserve pages on')
 parser.add_argument(
@@ -262,7 +268,7 @@ def main():
 if args.clear:
 clear_pages()
 if args.unmount:
-umount_huge(HUGE_MOUNT)
+umount_huge(args.directory)
 
 if args.reserve:
 reserve_kb = get_memsize(args.reserve)
@@ -273,7 +279,7 @@ def main():
 reserve_pages(
 int(reserve_kb / pagesize_kb), pagesize_kb, node=args.node)
 if args.mount:
-mount_huge(pagesize_kb, HUGE_MOUNT)
+mount_huge(pagesize_kb, args.directory)
 if args.show:
 show_pages()
 print()
-- 
2.25.1

[PATCH v4 2/5] usertools: add options to change mount point owner

[Dmitry Kozlyuk]

Per mount(8), the previous owner and mode of the mount point
become invisible as long as this filesystem remains mounted.
Because dpdk-hugepages.py must be run as root,
the new owner would be root.
This is undesirable if the hugepage directory is being set up
by the administrator for an unprivileged user.
HugeTLB filesystem has options to set the mount point owner.
Add --user/-U and --group/-G options to apply this when mounting.
The benefit of performing this in dpdk-hugepages.py
is that the user does not need to care about this detail
of mount command operation.

Signed-off-by: Dmitry Kozlyuk 
---
Option --unmount/-u was already taken.

 usertools/dpdk-hugepages.py | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-hugepages.py b/usertools/dpdk-hugepages.py
index 8bab086a2f..a22d504d3a 100755
--- a/usertools/dpdk-hugepages.py
+++ b/usertools/dpdk-hugepages.py
@@ -170,7 +170,7 @@ def get_mountpoints():
 return mounted
 
 
-def mount_huge(pagesize, mountpoint):
+def mount_huge(pagesize, mountpoint, user, group):
 '''Mount the huge TLB file system'''
 if mountpoint in get_mountpoints():
 print(mountpoint, "already mounted")
@@ -178,6 +178,10 @@ def mount_huge(pagesize, mountpoint):
 cmd = "mount -t hugetlbfs"
 if pagesize:
 cmd += ' -o pagesize={}'.format(pagesize * 1024)
+if user:
+cmd += ' -o uid=' + user
+if group:
+cmd += ' -o gid=' + group
 cmd += ' nodev ' + mountpoint
 os.system(cmd)
 
@@ -234,6 +238,16 @@ def main():
 metavar='DIR',
 default=HUGE_MOUNT,
 help='mount point')
+parser.add_argument(
+'--user',
+'-U',
+metavar='UID',
+help='set the mounted directory owner user')
+parser.add_argument(
+'--group',
+'-G',
+metavar='GID',
+help='set the mounted directory owner group')
 parser.add_argument(
 '--node', '-n', help='select numa node to reserve pages on')
 parser.add_argument(
@@ -279,7 +293,7 @@ def main():
 reserve_pages(
 int(reserve_kb / pagesize_kb), pagesize_kb, node=args.node)
 if args.mount:
-mount_huge(pagesize_kb, args.directory)
+mount_huge(pagesize_kb, args.directory, args.user, args.group)
 if args.show:
 show_pages()
 print()
-- 
2.25.1

[PATCH v4 3/5] doc: give specific instructions for running as non-root

[Dmitry Kozlyuk]

The guide to run DPDK applications as non-root in Linux
did not provide specific instructions to configure the required access
and did not explain why each bit is needed.
The latter is important because running as non-root
is one of the ways to tighten security and grant minimal permissions.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Bruce Richardson 
---
 doc/guides/linux_gsg/enable_func.rst  | 90 +--
 .../prog_guide/env_abstraction_layer.rst  |  2 +
 2 files changed, 65 insertions(+), 27 deletions(-)

diff --git a/doc/guides/linux_gsg/enable_func.rst 
b/doc/guides/linux_gsg/enable_func.rst
index 1df3ab0255..b15bfb2f9f 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -13,13 +13,64 @@ Enabling Additional Functionality
 Running DPDK Applications Without Root Privileges
 -
 
-In order to run DPDK as non-root, the following Linux filesystem objects'
-permissions should be adjusted to ensure that the Linux account being used to
-run the DPDK application has access to them:
+The following sections describe generic requirements and configuration
+for running DPDK applications as non-root.
+There may be additional requirements documented for some drivers.
 
-*   All directories which serve as hugepage mount points, for example, 
``/dev/hugepages``
+Hugepages
+~
 
-*   If the HPET is to be used,  ``/dev/hpet``
+Hugepages must be reserved as root before running the application as non-root,
+for example::
+
+  sudo dpdk-hugepages.py --reserve 1G
+
+If multi-process is not required, running with ``--in-memory``
+bypasses the need to access hugepage mount point and files within it.
+Otherwise, hugepage directory must be made accessible
+for writing to the unprivileged user.
+A good way for managing multiple applications using hugepages
+is to mount the filesystem with group permissions
+and add a supplementary group to each application or container.
+
+One option is to use the script provided by this project::
+
+  export HUGEDIR=$HOME/huge-1G
+  mkdir -p $HUGEDIR
+  sudo dpdk-hugepages.py --mount --directory $HUGEDIR --user `id -u` --group 
`id -g`
+
+In production environment, the OS can manage mount points
+(`systemd example 
`_).
+
+The ``hugetlb`` filesystem has additional options to guarantee or limit
+the amount of memory that is possible to allocate using the mount point.
+Refer to the `documentation 
`_.
+
+.. note::
+
+   Using ``vfio-pci`` kernel driver, if applicable, can eliminate the need
+   for physical addresses and therefore eliminate the permission requirements
+   described below.
+
+If the driver requires using physical addresses (PA),
+the executable file must be granted additional capabilities:
+
+* ``SYS_ADMIN`` to read ``/proc/self/pagemaps``
+* ``IPC_LOCK`` to lock hugepages in memory
+
+.. code-block:: console
+
+   setcap cap_ipc_lock,cap_sys_admin+ep 
+
+If physical addresses are not accessible,
+the following message will appear during EAL initialization::
+
+  EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Permission denied
+
+It is harmless in case PA are not needed.
+
+Resource Limits
+~~~
 
 When running as non-root user, there may be some additional resource limits
 that are imposed by the system. Specifically, the following resource limits may
@@ -34,8 +85,13 @@ need to be adjusted in order to ensure normal DPDK operation:
 The above limits can usually be adjusted by editing
 ``/etc/security/limits.conf`` file, and rebooting.
 
-Additionally, depending on which kernel driver is in use, the relevant
-resources also should be accessible by the user running the DPDK application.
+See `Hugepage Mapping `_
+section to learn how these limits affect EAL.
+
+Device Control
+~~
+
+If the HPET is to be used, ``/dev/hpet`` permissions must be adjusted.
 
 For ``vfio-pci`` kernel driver, the following Linux file system objects'
 permissions should be adjusted:
@@ -45,26 +101,6 @@ permissions should be adjusted:
 * The directories under ``/dev/vfio`` that correspond to IOMMU group numbers of
   devices intended to be used by DPDK, for example, ``/dev/vfio/50``
 
-.. note::
-
-The instructions below will allow running DPDK with ``igb_uio`` or
-``uio_pci_generic`` drivers as non-root with older Linux kernel versions.
-However, since version 4.0, the kernel does not allow unprivileged 
processes
-to read the physical address information from the pagemaps file, making it
-impossible for those processes to be used by non-privileged users. In such
-cases, using the VFIO driver is recommended.
-
-For ``igb_uio`` or ``uio_pci_generic`` kernel drivers, the following Linux file
-system objects' permissions should be adjusted:
-
-*   The userspace-io device files in  ``/

[PATCH v4 4/5] doc: update instructions for running as non-root for MLX5

[Dmitry Kozlyuk]

Reference the common guide for generic setup.
Remove excessive capabilities from the recommended list.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/platform/mlx5.rst | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/doc/guides/platform/mlx5.rst b/doc/guides/platform/mlx5.rst
index 64a4c5e76e..18d38f3488 100644
--- a/doc/guides/platform/mlx5.rst
+++ b/doc/guides/platform/mlx5.rst
@@ -404,25 +404,30 @@ The device can be bound again at this point.
 Run as Non-Root
 ^^^
 
-In order to run as a non-root user,
-some capabilities must be granted to the application::
+Hugepage and resource limit setup are documented
+in the :ref:`common Linux guide `.
+This PMD can operate without access to physical addresses,
+therefore it does not require ``SYS_ADMIN`` to access ``/proc/self/pagemaps``.
+Note that this requirement may still come from other drivers.
 
-   setcap cap_sys_admin,cap_net_admin,cap_net_raw,cap_ipc_lock+ep 
+Below are additional capabilities that must be granted to the application
+with the reasons for the need of each capability:
 
-Below are the reasons for the need of each capability:
+``NET_RAW``
+   For raw Ethernet queue allocation through the kernel driver.
 
-``cap_sys_admin``
-   When using physical addresses (PA mode), with Linux >= 4.0,
-   for access to ``/proc/self/pagemap``.
+``NET_ADMIN``
+   For device configuration, like setting link status or MTU.
 
-``cap_net_admin``
-   For device configuration.
+``SYS_RAWIO``
+   For using group 1 and above (software steering) in Flow API.
 
-``cap_net_raw``
-   For raw ethernet queue allocation through kernel driver.
+They can be manually granted for a specific executable file::
 
-``cap_ipc_lock``
-   For DMA memory pinning.
+   setcap cap_net_raw,cap_net_admin,cap_sys_rawio+ep 
+
+Alternatively, a service manager or a container runtime
+may configure the capabilities for a process.
 
 
 Windows Environment
-- 
2.25.1

[PATCH v4 5/5] doc: add note about running virtio-legacy as non-root

[Dmitry Kozlyuk]

The requirement of SYS_ADMIN capability in legacy virtio mode
was missing. Add it to the driver-specific page.

Signed-off-by: Dmitry Kozlyuk 
---
 doc/guides/nics/virtio.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
index 7c0ae2b3af..0e552b2701 100644
--- a/doc/guides/nics/virtio.rst
+++ b/doc/guides/nics/virtio.rst
@@ -86,6 +86,9 @@ The following prerequisites apply:
 *   Linux kernel with KVM module; vhost module loaded and ioeventfd supported.
 Qemu standard backend without vhost support isn't tested, and probably 
isn't supported.
 
+*   When using legacy interface, ``SYS_RAWIO`` capability is required
+for ``iopl()`` call to enable access to PCI IO ports.
+
 Virtio with kni vhost Back End
 --
 
-- 
2.25.1

Re: [PATCH v4 2/5] usertools: add options to change mount point owner

[Bruce Richardson]

On Fri, Jun 24, 2022 at 04:19:53PM +0300, Dmitry Kozlyuk wrote:
> Per mount(8), the previous owner and mode of the mount point
> become invisible as long as this filesystem remains mounted.
> Because dpdk-hugepages.py must be run as root,
> the new owner would be root.
> This is undesirable if the hugepage directory is being set up
> by the administrator for an unprivileged user.
> HugeTLB filesystem has options to set the mount point owner.
> Add --user/-U and --group/-G options to apply this when mounting.
> The benefit of performing this in dpdk-hugepages.py
> is that the user does not need to care about this detail
> of mount command operation.
> 
> Signed-off-by: Dmitry Kozlyuk 
> ---
Acked-by: Bruce Richardson 

[PATCH 1/1] doc: notice to add new ipsec event subtypes

[Vamsi Attunuru]

Based on discussion in below email thread, the new event subtypes can be
added in 22.11 release with fixing any compatability issues mentioned in
the mail thread.

https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-gak...@marvell.com/

Signed-off-by: Vamsi Attunuru 
---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c53d..83da1c62ac 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -107,6 +107,11 @@ Deprecation Notices
   alternative is implemented.
   The legacy actions should be removed in DPDK 22.11.
 
+* ethdev: The enum ``rte_eth_event_ipsec_subtype`` would be extended to add
+  new subtype values ``RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY``,
+  ``RTE_ETH_EVENT_IPSEC_SA_BYTE_HARD_EXPIRY`` and
+  ``RTE_ETH_EVENT_IPSEC_SA_PKT_HARD_EXPIRY`` in DPDK 22.11.
+
 * cryptodev: Hide structures ``rte_cryptodev_sym_session`` and
   ``rte_cryptodev_asym_session`` to remove unnecessary indirection between
   session and the private data of session. An opaque pointer can be exposed
-- 
2.25.1

[PATCH] doc: announce change to cryptodev cb function prototype

[Srujana Challa]

Function rte_cryptodev_cb_fn prototype will be extended to
add new parameter qp_id, to return queue pair ID, which got
error interrupt to the application, so that application can
reset that particular queue pair.

https://mails.dpdk.org/archives/dev/2022-June/245428.html

Signed-off-by: Srujana Challa 
---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4e5b23c53d..d6c94f8ac8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -112,6 +112,11 @@ Deprecation Notices
   session and the private data of session. An opaque pointer can be exposed
   directly to application which can be attached to the ``rte_crypto_op``.
 
+* cryptodev: The function pointer ``rte_cryptodev_cb_fn`` will be updated to
+  have another parameter ``qp_id`` to return the queue_pair ID which got error
+  interrupt to the application so that application can reset that particular
+  queue pair.
+
 * security: Hide structure ``rte_security_session`` and expose an opaque
   pointer for the private data to the application which can be attached
   to the packet while enqueuing.
-- 
2.25.1

Re: [PATCH V5 2/7] app/testpmd: unify the name of L2 payload offload

[Ferruh Yigit]

On 6/24/2022 8:23 AM, Huisong Li wrote:

Currently, the "port config all rss xx" command uses 'ether' name to match
and to set 'RTE_ETH_RSS_L2_PAYLOAD' offload. However, others RSS command,
such as, "port config  rss-hash-key" and "show port 
rss-hash key", use 'l2-payload' to represent this offload. So this patch
unifies the name of 'RTE_ETH_RSS_L2_PAYLOAD' offload.

Signed-off-by: Huisong Li 


ack

But I wonder if we should continue to support 'ether' with an exception 
to not break the interface, at least for a while like to next LTS.



---
  app/test-pmd/cmdline.c  | 6 +++---
  doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9a7fd5fc35..a701bac953 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -694,7 +694,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"receive buffers available.\n\n"
  
  			"port config all rss (all|default|ip|tcp|udp|sctp|"

-   
"ether|port|vxlan|geneve|nvgre|vxlan-gpe|ecpri|mpls|ipv4-chksum|l2tpv2|"
+   
"l2-payload|port|vxlan|geneve|nvgre|vxlan-gpe|ecpri|mpls|ipv4-chksum|l2tpv2|"

"none|level-default|level-outer|level-inner|)\n"
"Set the RSS mode.\n\n"
  
@@ -2080,7 +2080,7 @@ cmd_config_rss_parsed(void *parsed_result,

rss_conf.rss_hf = RTE_ETH_RSS_TCP;
else if (!strcmp(res->value, "sctp"))
rss_conf.rss_hf = RTE_ETH_RSS_SCTP;
-   else if (!strcmp(res->value, "ether"))
+   else if (!strcmp(res->value, "l2_payload"))
rss_conf.rss_hf = RTE_ETH_RSS_L2_PAYLOAD;
else if (!strcmp(res->value, "port"))
rss_conf.rss_hf = RTE_ETH_RSS_PORT;
@@ -2203,7 +2203,7 @@ static cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
.help_str = "port config all rss "
-   "all|default|eth|vlan|ip|tcp|udp|sctp|ether|port|vxlan|geneve|"
+   
"all|default|eth|vlan|ip|tcp|udp|sctp|l2-payload|port|vxlan|geneve|"

"nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|ipv4-chksum|l2tpv2|"
"none|level-default|level-outer|level-inner|",
.tokens = {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 0b7a53fdf1..cc299cff6c 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2144,7 +2144,7 @@ port config - RSS
  
  Set the RSS (Receive Side Scaling) mode on or off::
  
-   testpmd> port config all rss (all|default|eth|vlan|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|l2tpv2|none)

+   testpmd> port config all rss 
(all|default|eth|vlan|ip|tcp|udp|sctp|l2-payload|port|vxlan|geneve|nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|l2tpv2|none)
  
  RSS is on by default.
  

Re: [PATCH V5 3/7] app/testpmd: refactor config all RSS command

[Ferruh Yigit]

On 6/24/2022 8:23 AM, Huisong Li wrote:

CAUTION: This message has originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.


The "port config  rss-hash-key" and "show port  rss-hash
key" commands both use the 'rss_type_table[]' to get 'rss_types' or the RSS
type name. So this patch uses the 'rss_type_table[]' to get the rss types.
In this way, this command naturally supports more individual types.

Suggested-by: Ferruh Yigit 
Signed-off-by: Huisong Li 
---
  app/test-pmd/cmdline.c  | 127 ++--
  app/test-pmd/config.c   |  20 ++-
  app/test-pmd/testpmd.h  |   1 +
  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  11 +-
  4 files changed, 63 insertions(+), 96 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index a701bac953..bea869ce56 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -693,9 +693,14 @@ static void cmd_help_long_parsed(void *parsed_result,
 "Enable or disable packet drop on all RX queues of all 
ports when no "
 "receive buffers available.\n\n"

-   "port config all rss (all|default|ip|tcp|udp|sctp|"
-   
"l2-payload|port|vxlan|geneve|nvgre|vxlan-gpe|ecpri|mpls|ipv4-chksum|l2tpv2|"
-   
"none|level-default|level-outer|level-inner|)\n"
+   "port config all rss 
(all|default|level-default|level-outer|level-inner|"
+   "ip|tcp|udp|sctp|tunnel|vlan|none|"
+   "ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
+   
"ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex|"
+   
"l2_payload|port|vxlan|geneve|nvgre|gtpu|eth|s-vlan|c-vlan|"
+   
"esp|ah|l2tpv3|pfcp|pppoe|ecpri|mpls|ipv4-chksum|l4-chksum|"
+   
"l2tpv2|l3-pre96|l3-pre64|l3-pre56|l3-pre48|l3-pre40|l3-pre32|"
+   
"l2-dst-only|l2-src-only|l4-dst-only|l4-src-only|l3-dst-only|l3-src-only|)\n"
 "Set the RSS mode.\n\n"

 "port config port-id rss reta 
(hash,queue)[,(hash,queue)]\n"
@@ -2062,81 +2067,7 @@ cmd_config_rss_parsed(void *parsed_result,
 uint16_t i;
 int ret;

-   if (!strcmp(res->value, "all"))
-   rss_conf.rss_hf = RTE_ETH_RSS_ETH | RTE_ETH_RSS_VLAN | 
RTE_ETH_RSS_IP |
-   RTE_ETH_RSS_TCP | RTE_ETH_RSS_UDP | RTE_ETH_RSS_SCTP |
-   RTE_ETH_RSS_L2_PAYLOAD | RTE_ETH_RSS_L2TPV3 | 
RTE_ETH_RSS_ESP |
-   RTE_ETH_RSS_AH | RTE_ETH_RSS_PFCP | RTE_ETH_RSS_GTPU |
-   RTE_ETH_RSS_ECPRI | RTE_ETH_RSS_L2TPV2;
-   else if (!strcmp(res->value, "eth"))
-   rss_conf.rss_hf = RTE_ETH_RSS_ETH;
-   else if (!strcmp(res->value, "vlan"))
-   rss_conf.rss_hf = RTE_ETH_RSS_VLAN;
-   else if (!strcmp(res->value, "ip"))
-   rss_conf.rss_hf = RTE_ETH_RSS_IP;
-   else if (!strcmp(res->value, "udp"))
-   rss_conf.rss_hf = RTE_ETH_RSS_UDP;
-   else if (!strcmp(res->value, "tcp"))
-   rss_conf.rss_hf = RTE_ETH_RSS_TCP;
-   else if (!strcmp(res->value, "sctp"))
-   rss_conf.rss_hf = RTE_ETH_RSS_SCTP;
-   else if (!strcmp(res->value, "l2_payload"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L2_PAYLOAD;
-   else if (!strcmp(res->value, "port"))
-   rss_conf.rss_hf = RTE_ETH_RSS_PORT;
-   else if (!strcmp(res->value, "vxlan"))
-   rss_conf.rss_hf = RTE_ETH_RSS_VXLAN;
-   else if (!strcmp(res->value, "geneve"))
-   rss_conf.rss_hf = RTE_ETH_RSS_GENEVE;
-   else if (!strcmp(res->value, "nvgre"))
-   rss_conf.rss_hf = RTE_ETH_RSS_NVGRE;
-   else if (!strcmp(res->value, "l3-pre32"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE32;
-   else if (!strcmp(res->value, "l3-pre40"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE40;
-   else if (!strcmp(res->value, "l3-pre48"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE48;
-   else if (!strcmp(res->value, "l3-pre56"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE56;
-   else if (!strcmp(res->value, "l3-pre64"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE64;
-   else if (!strcmp(res->value, "l3-pre96"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_PRE96;
-   else if (!strcmp(res->value, "l3-src-only"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_SRC_ONLY;
-   else if (!strcmp(res->value, "l3-dst-only"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L3_DST_ONLY;
-   else if (!strcmp(res->value, "l4-src-only"))
-   rss_conf.rss_hf = RTE_ETH_RSS_L4_SRC_ONLY;
-   else if (!strcmp(res->value, "l4-dst-

Re: [PATCH V5 6/7] app/testpmd: reorder elements in RSS type table array

[Ferruh Yigit]

On 6/24/2022 8:24 AM, Huisong Li wrote:

There are group and individual types in rss_type_table[]. However, group
types are very scattered, and individual types are not arranged based on
the bit number order in 'RTE_ETH_RSS_xxx'. For a clear distribution of
types and better maintenance, this patch reorders this table.

Signed-off-by: Huisong Li  > ---
  app/test-pmd/config.c | 51 +++
  1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b3cb68003c..cc97aaa0ce 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -85,17 +85,20 @@ static const struct {
  };
  
  const struct rss_type_info rss_type_table[] = {

+   /* Group types */
{ "all", RTE_ETH_RSS_ETH | RTE_ETH_RSS_VLAN | RTE_ETH_RSS_IP | 
RTE_ETH_RSS_TCP |
RTE_ETH_RSS_UDP | RTE_ETH_RSS_SCTP | RTE_ETH_RSS_L2_PAYLOAD |
RTE_ETH_RSS_L2TPV3 | RTE_ETH_RSS_ESP | RTE_ETH_RSS_AH | 
RTE_ETH_RSS_PFCP |
RTE_ETH_RSS_GTPU | RTE_ETH_RSS_ECPRI | RTE_ETH_RSS_MPLS | 
RTE_ETH_RSS_L2TPV2},
{ "none", 0 },
-   { "eth", RTE_ETH_RSS_ETH },
-   { "l2-src-only", RTE_ETH_RSS_L2_SRC_ONLY },
-   { "l2-dst-only", RTE_ETH_RSS_L2_DST_ONLY },
+   { "ip", RTE_ETH_RSS_IP },
+   { "udp", RTE_ETH_RSS_UDP },
+   { "tcp", RTE_ETH_RSS_TCP },
+   { "sctp", RTE_ETH_RSS_SCTP },
+   { "tunnel", RTE_ETH_RSS_TUNNEL },
{ "vlan", RTE_ETH_RSS_VLAN },
-   { "s-vlan", RTE_ETH_RSS_S_VLAN },
-   { "c-vlan", RTE_ETH_RSS_C_VLAN },
+
+   /* Individual type */
{ "ipv4", RTE_ETH_RSS_IPV4 },
{ "ipv4-frag", RTE_ETH_RSS_FRAG_IPV4 },
{ "ipv4-tcp", RTE_ETH_RSS_NONFRAG_IPV4_TCP },
@@ -108,7 +111,7 @@ const struct rss_type_info rss_type_table[] = {
{ "ipv6-udp", RTE_ETH_RSS_NONFRAG_IPV6_UDP },
{ "ipv6-sctp", RTE_ETH_RSS_NONFRAG_IPV6_SCTP },
{ "ipv6-other", RTE_ETH_RSS_NONFRAG_IPV6_OTHER },
-   { "l2-payload", RTE_ETH_RSS_L2_PAYLOAD },
+   { "l2_payload", RTE_ETH_RSS_L2_PAYLOAD },
{ "ipv6-ex", RTE_ETH_RSS_IPV6_EX },
{ "ipv6-tcp-ex", RTE_ETH_RSS_IPV6_TCP_EX },
{ "ipv6-udp-ex", RTE_ETH_RSS_IPV6_UDP_EX },
@@ -116,33 +119,33 @@ const struct rss_type_info rss_type_table[] = {
{ "vxlan", RTE_ETH_RSS_VXLAN },
{ "geneve", RTE_ETH_RSS_GENEVE },
{ "nvgre", RTE_ETH_RSS_NVGRE },
-   { "ip", RTE_ETH_RSS_IP },
-   { "udp", RTE_ETH_RSS_UDP },
-   { "tcp", RTE_ETH_RSS_TCP },
-   { "sctp", RTE_ETH_RSS_SCTP },
-   { "tunnel", RTE_ETH_RSS_TUNNEL },
-   { "l3-pre32", RTE_ETH_RSS_L3_PRE32 },
-   { "l3-pre40", RTE_ETH_RSS_L3_PRE40 },
-   { "l3-pre48", RTE_ETH_RSS_L3_PRE48 },
-   { "l3-pre56", RTE_ETH_RSS_L3_PRE56 },
-   { "l3-pre64", RTE_ETH_RSS_L3_PRE64 },
-   { "l3-pre96", RTE_ETH_RSS_L3_PRE96 },
-   { "l3-src-only", RTE_ETH_RSS_L3_SRC_ONLY },
-   { "l3-dst-only", RTE_ETH_RSS_L3_DST_ONLY },
-   { "l4-src-only", RTE_ETH_RSS_L4_SRC_ONLY },
-   { "l4-dst-only", RTE_ETH_RSS_L4_DST_ONLY },
+   { "gtpu", RTE_ETH_RSS_GTPU },
+   { "eth", RTE_ETH_RSS_ETH },
+   { "s-vlan", RTE_ETH_RSS_S_VLAN },
+   { "c-vlan", RTE_ETH_RSS_C_VLAN },
{ "esp", RTE_ETH_RSS_ESP },
{ "ah", RTE_ETH_RSS_AH },
{ "l2tpv3", RTE_ETH_RSS_L2TPV3 },
{ "pfcp", RTE_ETH_RSS_PFCP },
{ "pppoe", RTE_ETH_RSS_PPPOE },
-   { "gtpu", RTE_ETH_RSS_GTPU },
-   { "ecpri", RTE_ETH_RSS_ECPRI },
+   {"ecpri", RTE_ETH_RSS_ECPRI },


syntax issue, space needed before "ecpri"


{ "mpls", RTE_ETH_RSS_MPLS },
{ "ipv4-chksum", RTE_ETH_RSS_IPV4_CHKSUM },
{ "l4-chksum", RTE_ETH_RSS_L4_CHKSUM },
{ "l2tpv2", RTE_ETH_RSS_L2TPV2 },
-   { NULL, 0 },
+   { "l3-pre96", RTE_ETH_RSS_L3_PRE96 },
+   { "l3-pre64", RTE_ETH_RSS_L3_PRE64 },
+   { "l3-pre56", RTE_ETH_RSS_L3_PRE56 },
+   { "l3-pre48", RTE_ETH_RSS_L3_PRE48 },
+   { "l3-pre40", RTE_ETH_RSS_L3_PRE40 },
+   { "l3-pre32", RTE_ETH_RSS_L3_PRE32 },
+   { "l2-dst-only", RTE_ETH_RSS_L2_DST_ONLY },
+   { "l2-src-only", RTE_ETH_RSS_L2_SRC_ONLY },
+   { "l4-dst-only", RTE_ETH_RSS_L4_DST_ONLY },
+   { "l4-src-only", RTE_ETH_RSS_L4_SRC_ONLY },
+   { "l3-dst-only", RTE_ETH_RSS_L3_DST_ONLY },
+   { "l3-src-only", RTE_ETH_RSS_L3_SRC_ONLY },
+   { NULL, 0},
  };
  
  static const struct {

Re: [PATCH V5 5/7] app/testpmd: compact RSS types output in some commands

[Ferruh Yigit]

On 6/24/2022 8:23 AM, Huisong Li wrote:

CAUTION: This message has originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.


From: Ferruh Yigit 

In port info command output, 'show port info all', supported RSS offload
types printed one type per line, and although this information is not
most important part of the command it takes big part of the command
output.

In port RSS hash and flow RSS command output, 'show port 0 rss-hash',
and 'flow query 0 0 rss', all enabled RSS types are printed on one line.
If there are many types, the print will be very long.

Compacting these RSS offloads and types output by fixing the length of the
character string printed on each line, instead of one per line or one line.
Output becomes as following:

Supported RSS offload flow types:
   ipv4-frag  ipv4-tcp  ipv4-udp  ipv4-sctp  ipv4-other
   ipv6-frag  ipv6-tcp  ipv6-udp  ipv6-sctp  ipv6-other
   l4-dst-only  l4-src-only  l3-dst-only  l3-src-only

Signed-off-by: Ferruh Yigit 
Signed-off-by: Huisong Li 
---
  app/test-pmd/config.c  | 68 +++---
  app/test-pmd/testpmd.h |  2 ++
  2 files changed, 52 insertions(+), 18 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index a0a5f12c71..b3cb68003c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -699,6 +699,38 @@ rsstypes_to_str(uint64_t rss_type)
 return NULL;
  }

+static void
+rss_offload_types_display(uint64_t offload_types, uint16_t char_num_per_line)
+{
+   uint16_t unknown_offload_str_len;
+   uint16_t total_len = 0;
+   uint16_t str_len = 0;
+   uint64_t rss_offload;
+   uint16_t i;
+
+   for (i = 0; i < sizeof(offload_types) * CHAR_BIT; i++) {
+   rss_offload = RTE_BIT64(i);
+   if ((offload_types & rss_offload) != 0) {
+   const char *p = rsstypes_to_str(rss_offload);
+
+   unknown_offload_str_len =
+   strlen("unknown_offload(BIT())") + (i / 10 + 1);
+   str_len = p ? strlen(p) : unknown_offload_str_len;
+   str_len += 2; /* add two spaces */
+   if (total_len + str_len >= char_num_per_line) {
+   total_len = 0;
+   printf("\n");
+   }
+
+   if (p)
+   printf("  %s", p);
+   else
+   printf("  unknown_offload(BIT(%u))", i);
+   total_len += str_len;
+   }
+   }
+}
+
  void
  port_infos_display(portid_t port_id)
  {
@@ -803,21 +835,10 @@ port_infos_display(portid_t port_id)
 if (!dev_info.flow_type_rss_offloads)
 printf("No RSS offload flow type is supported.\n");
 else {
-   uint64_t rss_offload_types = dev_info.flow_type_rss_offloads;
-   uint16_t i;
-
 printf("Supported RSS offload flow types:\n");
-   for (i = 0; i < sizeof(rss_offload_types) * CHAR_BIT; i++) {
-   uint64_t rss_offload = RTE_BIT64(i);
-   if ((rss_offload_types & rss_offload) != 0) {
-   const char *p = rsstypes_to_str(rss_offload);
-   if (p)
-   printf("  %s\n", p);
-   else
-   printf("  unknown_offload(BIT(%u))\n",
-  i);
-   }
-   }
+   rss_offload_types_display(dev_info.flow_type_rss_offloads,
+   TESTPMD_RSS_TYPES_CHAR_NUM_PER_LINE);
+   printf("\n");


Why 'rss_types_display()' is not reused, but new function 
'rss_offload_types_display()' created?

Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Stephen Hemminger]

On Fri, 24 Jun 2022 13:29:46 +0200
Morten Brørup  wrote:

> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Friday, 24 June 2022 13.17
> > 
> > On Fri, Jun 24, 2022 at 09:00:38AM +0100, Bruce Richardson wrote:  
> > > On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Brørup wrote:  
> > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > > > Sent: Thursday, 23 June 2022 20.40
> > > > >
> > > > > On Thu, 23 Jun 2022 20:34:07 +0200
> > > > > Morten Brørup  wrote:
> > > > >  
> > > > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > > > > > > Sent: Thursday, 23 June 2022 18.43
> > > > > > >
> > > > > > > For string values returned from telemetry, escape any values  
> > that  
> > > > > > > cannot
> > > > > > > normally appear in a json string. According to the json  
> > spec[1],  
> > > > > the  
> > > > > > > characters than need to be handled are control chars (char  
> > value <  
> > > > > > > 0x20)
> > > > > > > and '"' and '\' characters.  
> > > > > >
> > > > > > Correct. Other chars are optional to escape.  
> > > > >
> > > > > For json_writer (which I wrote for iproute2 and could have been  
> > used  
> > > > > here).
> > > > > The switch handles: \t \n \r \f \b \\ " ' as special cases.  
> > > >
> > > > RFC 8259 chapter 7 says:
> > > >
> > > >All Unicode characters may be placed within the
> > > >quotation marks, except for the characters that MUST be escaped:
> > > >quotation mark, reverse solidus, and the control characters  
> > (U+  
> > > >through U+001F).
> > > >
> > > > I have no preference for either, as long as '/' and other non-  
> > control characters are not (unnecessarily) escaped.  
> > > >
> > > > Using tested and maintained code like json_writer could be  
> > beneficial. If you hold the copyright, there should be no license
> > issues.  
> > > >  
> > >
> > > I will take a look at json_writer.  
> > 
> > Took a quick look at json_writer, and it's certainly an option. The
> > main
> > gap compared to what we have in our current implementation is that
> > json_writer is designed around a stream for output rather than an
> > output
> > buffer. Now while we can use fmemopen to make our buffer act as a
> > stream
> > for writing, and the write apis should prevent it overflowing, we still
> > hit
> > the issue of the result of truncation not being valid json. The current
> > implementation tries to handle truncation more gracefully in that any
> > fields which don't fit just don't get added.
> > 
> > I'll think about it a bit more, and see if there is a way that it can
> > be
> > made to work more cleanly.  
> 
> It sounds like json_writer provides a more advanced API, adding a lot of 
> overhead for wrapping it into the Telemetry library. Since we only need a 
> very simple encoder, perhaps copy-paste-modify is more viable. Or just 
> proceed with your RFC code.
> 
> Regardless, the API and underlying code probably needs extra scrutiny, so it 
> doesn't become an attack vector into the control plane of a DPDK application.

I wrote it based on the model used by some Java library.
Other JSON libraries were more concerned with parsing JSON.

Re: [PATCH] ip_frag: replace the rte memcpy with memcpy

[Konstantin Ananyev]

23/06/2022 03:35, Stephen Hemminger пишет:

On Wed, 22 Jun 2022 23:49:39 +0100
Konstantin Ananyev  wrote:


@@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr 
*dst,
const struct rte_ipv4_hdr *src, uint16_t header_len,
uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
   {
-   rte_memcpy(dst, src, header_len);
+   memcpy(dst, src, header_len);



I am fine with replacements in test and inside the lib, for cases
where 'len' parameter is constant value.
Though as I said before, here 'header_len' is not a constant value.
Are you sure it will not introduce any performance regression?


Do you have any performance tests. The ip header options are very small.



From my experience - usually it is not about how big or small amount
we need to copy. It is about can compiler evaluate 'size' parameter
for memcpy() at compilation time or not.
If it can, great - it will most likely replace memcpy()
with some really well optimized code.
If not it has to generate a proper call to actual
memcpy() function. Which again, can be well optimized, but the
overhead of the function call itself can still be noticeable,
specially for small copies.
Anyway, as I can see, David already integrated these changes anyway.
So now, we'll have to wait and see would anyone complain or not.
About performance testing, the only one I am aware about:
examples/ip_fragmentation

Konstantin

RE: [PATCH] doc: announce change to cryptodev cb function prototype

[Akhil Goyal]

> Subject: [PATCH] doc: announce change to cryptodev cb function prototype
> 
> Function rte_cryptodev_cb_fn prototype will be extended to
> add new parameter qp_id, to return queue pair ID, which got
> error interrupt to the application, so that application can
> reset that particular queue pair.
> 
> https://mails.dpdk.org/archives/dev/2022-June/245428.html
> 
> Signed-off-by: Srujana Challa 
Acked-by: Akhil Goyal 

RE: [PATCH 1/1] doc: notice to add new ipsec event subtypes

[Akhil Goyal]

> Subject: [PATCH 1/1] doc: notice to add new ipsec event subtypes

Title should be
doc: announce addition of new IPsec event subtypes
> 
> Based on discussion in below email thread, the new event subtypes can be
> added in 22.11 release with fixing any compatability issues mentioned in
> the mail thread.
> 
> https://patches.dpdk.org/project/dpdk/patch/20220416192530.173895-8-
> gak...@marvell.com/
> 
Description should be 

New event subtypes need to be added for notifying expiry events upon reaching
IPsec SA soft packet expiry and hard packet/byte expiry limits. This would be 
added in DPDK 22.11.

You can give the reference to patch after --- so that it is not visible in git 
log

Adding more people for acks.

> Signed-off-by: Vamsi Attunuru 
Other that this
Acked-by: Akhil Goyal 

[PATCH] common/mlx5: fix non-expandable global MR cache

[Dmitry Kozlyuk]

The number of memory regions (MR) that MLX5 PMD can use
was limited by 512 per IB device, the size of the global MR cache
that was fixed at compile time.
The cache allows to search MR LKey by address efficiently,
therefore it is the last place searched on data path
(skipped is the global MR database which would be slow).
If the application logic caused the PMD to create more than 512 MRs,
which can be the case with external memory,
those MRs would never be found on data path
and later cause a HW failure.

The cache size was fixed because at the time of overflow
the EAL memory hotplug lock may be held,
prohibiting to allocate a larger cache
(it must reside in DPDK memory for multi-process support).
This patch adds logic to release the necessary locks,
extend the cache, and repeat the attempt to insert new entries.

`mlx5_mr_btree` structure had `overflow` field
that was set when a cache (not only the global one)
could not accept new entries.
However, it was only checked for the global cache,
because caches of upper layers were dynamically expandable.
With the global cache size limitation removed, this field is not needed.
Cache size was previously limited by 16-bit indices.
Use the space in the structure previously fileld by `overflow` field
to extend indices to 32 bits.
With this patch, it is the HW and RAM that limit the number of MRs.

Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Matan Azrad 
---
 drivers/common/mlx5/mlx5_common.c|  30 +
 drivers/common/mlx5/mlx5_common_mr.c | 158 ---
 drivers/common/mlx5/mlx5_common_mr.h |   7 +-
 3 files changed, 150 insertions(+), 45 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_common.c 
b/drivers/common/mlx5/mlx5_common.c
index ef1604d223..89fef2b535 100644
--- a/drivers/common/mlx5/mlx5_common.c
+++ b/drivers/common/mlx5/mlx5_common.c
@@ -1082,6 +1082,7 @@ mlx5_common_dev_dma_map(struct rte_device *rte_dev, void 
*addr,
uint64_t iova __rte_unused, size_t len)
 {
struct mlx5_common_device *dev;
+   struct mlx5_mr_btree *bt;
struct mlx5_mr *mr;
 
dev = to_mlx5_device(rte_dev);
@@ -1099,7 +1100,36 @@ mlx5_common_dev_dma_map(struct rte_device *rte_dev, void 
*addr,
rte_errno = EINVAL;
return -1;
}
+try_insert:
rte_rwlock_write_lock(&dev->mr_scache.rwlock);
+   bt = &dev->mr_scache.cache;
+   if (bt->len == bt->size) {
+   uint32_t size;
+   int ret;
+
+   size = bt->size + 1;
+   MLX5_ASSERT(size > bt->size);
+   /*
+* Avoid deadlock (numbers show the sequence of events):
+*mlx5_mr_create_primary():
+*1) take EAL memory lock
+*3) take MR lock
+*this function:
+*2) take MR lock
+*4) take EAL memory lock while allocating the new cache
+* Releasing the MR lock before step 4
+* allows another thread to execute step 3.
+*/
+   rte_rwlock_write_unlock(&dev->mr_scache.rwlock);
+   ret = mlx5_mr_expand_cache(&dev->mr_scache, size,
+  rte_dev->numa_node);
+   if (ret < 0) {
+   mlx5_mr_free(mr, dev->mr_scache.dereg_mr_cb);
+   rte_errno = ret;
+   return -1;
+   }
+   goto try_insert;
+   }
LIST_INSERT_HEAD(&dev->mr_scache.mr_list, mr, mr);
/* Insert to the global cache table. */
mlx5_mr_insert_cache(&dev->mr_scache, mr);
diff --git a/drivers/common/mlx5/mlx5_common_mr.c 
b/drivers/common/mlx5/mlx5_common_mr.c
index 06e4c8f187..0b43564bbb 100644
--- a/drivers/common/mlx5/mlx5_common_mr.c
+++ b/drivers/common/mlx5/mlx5_common_mr.c
@@ -78,7 +78,7 @@ mlx5_mprq_buf_free_cb(void *addr __rte_unused, void *opaque)
  *   0 on success, -1 on failure.
  */
 static int
-mr_btree_expand(struct mlx5_mr_btree *bt, int n)
+mr_btree_expand(struct mlx5_mr_btree *bt, uint32_t n)
 {
void *mem;
int ret = 0;
@@ -123,11 +123,11 @@ mr_btree_expand(struct mlx5_mr_btree *bt, int n)
  *   Searched LKey on success, UINT32_MAX on no match.
  */
 static uint32_t
-mr_btree_lookup(struct mlx5_mr_btree *bt, uint16_t *idx, uintptr_t addr)
+mr_btree_lookup(struct mlx5_mr_btree *bt, uint32_t *idx, uintptr_t addr)
 {
struct mr_cache_entry *lkp_tbl;
-   uint16_t n;
-   uint16_t base = 0;
+   uint32_t n;
+   uint32_t base = 0;
 
MLX5_ASSERT(bt != NULL);
lkp_tbl = *bt->table;
@@ -137,7 +137,7 @@ mr_btree_lookup(struct mlx5_mr_btree *bt, uint16_t *idx, 
uintptr_t addr)
lkp_tbl[0].lkey == UINT32_MAX));
/* Binary search. */
do {
-   regist

Re: [PATCH 01/20] baseband/acc100: fix a memory leak in acc100 queue setup

[David Marchand]

On Tue, Feb 22, 2022 at 7:18 PM Weiguo Li  wrote:
>
> We allocated memory for 'q', we don't free it when null check for 'd' fails
> and it will lead to memory leak.
> We can move null check for 'd' ahead of the memory allocation to fix it.
>
> Fixes: 060e76729302 ("baseband/acc100: add queue configuration")
>
> Signed-off-by: Weiguo Li 
> ---
>  drivers/baseband/acc100/rte_acc100_pmd.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c 
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index f86474f7e0..25e9e6435f 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -824,6 +824,10 @@ acc100_queue_setup(struct rte_bbdev *dev, uint16_t 
> queue_id,
> struct acc100_queue *q;
> int16_t q_idx;
>
> +   if (d == NULL) {
> +   rte_bbdev_log(ERR, "Undefined device");
> +   return -ENODEV;
> +   }

Nicolas,

.queue_setup is a dev_ops, which means it is invoked after the .probe
function was called.
Failing to allocate dev_private shoud have been detected earlier, is
that correct?
If so, this check should simply be dropped, and there is no leak to fix.

Please confirm when you have the time.

Thanks.

-- 
David Marchand

Re: [PATCH 03/20] crypto/dpaa2_sec: fix memory leaks in error handlings

[David Marchand]

On Tue, Feb 22, 2022 at 7:19 PM Weiguo Li  wrote:
>
> When function returned from error handling branches, the memories were
> not freed which caused a memory leak.
>
> Fixes: 8d1f3a5d751b ("crypto/dpaa2_sec: support crypto operation")

This is backport material.
Please add Cc: sta...@dpdk.org in new revision.

>
> Signed-off-by: Weiguo Li 
> ---
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c 
> b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> index e62d04852b..3f8d4d213f 100644
> --- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> +++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
> @@ -2037,12 +2037,15 @@ dpaa2_sec_queue_pair_setup(struct rte_cryptodev *dev, 
> uint16_t qp_id,
> RTE_CACHE_LINE_SIZE);
> if (!qp->rx_vq.q_storage) {
> DPAA2_SEC_ERR("malloc failed for q_storage");
> +   rte_free(qp);
> return -ENOMEM;
> }
> memset(qp->rx_vq.q_storage, 0, sizeof(struct queue_storage_info_t));
>
> if (dpaa2_alloc_dq_storage(qp->rx_vq.q_storage)) {
> DPAA2_SEC_ERR("Unable to allocate dequeue storage");
> +   rte_free(qp->rx_vq.q_storage);
> +   rte_free(qp);
> return -ENOMEM;
> }


Please rebase this fix, there was a new allocation introduced in this
code and I suspect this should be fixed too.
Thanks.


-- 
David Marchand

Re: [PATCH 04/20] crypto/qat: fix a memory leak when set encrypt key fail

[David Marchand]

On Tue, Feb 22, 2022 at 7:19 PM Weiguo Li  wrote:
>
> We allocated memory for 'in', we don't free it when AES_set_encrypt_key()
> fails and it will lead to memory leak.
> We can move set_encrypt_key() ahead of the memory allocation to fix it.

This move seems to fix the leak indeed.
But this change does not follow the pattern used in the rest of this
file and I don't feel confident enough to accept it without the driver
maintainer opinion.


-- 
David Marchand

Re: [PATCH 00/20] fix memory leaks in error handling

[David Marchand]

On Tue, Feb 22, 2022 at 7:18 PM Weiguo Li  wrote:
>
> This series fix some memory leaks in error handling.
>
> I write a coccinelle script to detect these issues, and
> fix them after exclude a small number of false positives.
>
> FYI, the script is as follows:
> //
> // Find possible memory leaks in error handling
> // Reference: coccinellery/alloc9/kmalloc9.cocci
> //
> @memory_leak_in_error_handling @
> local idexpression x;
> expression E;
> statement S;
> identifier dpdk_malloc = { rte_malloc, rte_zmalloc, rte_realloc, 
> rte_malloc_socket,
> rte_zmalloc_socket, rte_realloc_socket, rte_pktmbuf_alloc, opae_malloc,
> strdup, strndup, malloc, realloc, calloc };
> identifier dpdk_free = { rte_free, free, bnx2x_rx_queue_release, 
> bnx2x_tx_queue_release,
> rte_pktmbuf_free, opae_free, ntb_rxq_release, ntb_txq_release, 
> ice_rx_queue_release,
> ice_tx_queue_release };
> type T;
> @@
> (
>   /* skip this pattern to reduce false positives */
>   x = dpdk_malloc(...); ... if (...) { ... \( return x; \| return 0; \) }
> |
> * x = dpdk_malloc(...);
>   ...
>   if (x == NULL) S
>   ... when != E = x
>   when != dpdk_free (..., \( x \| (T)x \| &x \), ...)
>   when forall
>   if (...) {
> <+... when != E = x
>   when != dpdk_free (..., \( x \| (T)x \| &x \), ...)
>   when forall
> *   return ...;
> ...+>
>   }
> )
>
> Weiguo Li (20):
>   baseband/acc100: fix a memory leak in acc100 queue setup
>   common/dpaax: fix a memory leak in iterate dir
>   crypto/dpaa2_sec: fix memory leaks in error handlings
>   crypto/qat: fix a memory leak when set encrypt key fail
>   net/bnxt: fix a memory leak in error handling
>   net/bnxt: fix 'ctx' memory leak when new malloc fail
>   net/bnx2x: add clean up for 'rxq' to avoid a memory leak
>   net/cnxk: free 'node' memory when node add fail
>   net/dpaa: fix a memory leak when validation fail
>   net/failsafe: fix a memory leak in error handling
>   net/iavf: fix a memory leak in error handling
>   net/ice: goto clean up lable to avoid memory leak
>   net/ice: fix memory leaks in error handlings
>   net/ice: avoid fix memory leaks in register parser
>   net/memif: fix some memory leaks in error handlings
>   net/sfc: fix a memory leak in error handling
>   net/vmxnet3: fix memory leaks in error handlings
>   raw/ifpga/base: fix memory leaks in error handlings
>   raw/ntb: fix some memory leaks in error handlings
>   regex/mlx5: fix a memory leak in error handling
>
>  drivers/baseband/acc100/rte_acc100_pmd.c|  8 +++---
>  drivers/common/dpaax/dpaa_of.c  |  4 ++-
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |  3 ++
>  drivers/crypto/qat/qat_sym_session.c|  9 +++---
>  drivers/net/bnx2x/bnx2x_rxtx.c  |  1 +
>  drivers/net/bnxt/bnxt_hwrm.c|  1 +
>  drivers/net/bnxt/tf_ulp/ulp_fc_mgr.c|  1 +
>  drivers/net/cnxk/cnxk_tm.c  |  1 +
>  drivers/net/dpaa/dpaa_rxtx.c|  1 +
>  drivers/net/failsafe/failsafe_ops.c |  1 +
>  drivers/net/iavf/iavf_generic_flow.c|  1 +
>  drivers/net/ice/ice_acl_filter.c|  2 +-
>  drivers/net/ice/ice_generic_flow.c  |  9 +++---
>  drivers/net/ice/ice_hash.c  | 30 ---
>  drivers/net/memif/rte_eth_memif.c   | 32 ++---
>  drivers/net/sfc/sfc.c   |  4 ++-
>  drivers/net/vmxnet3/vmxnet3_rxtx.c  |  8 ++
>  drivers/raw/ifpga/base/ifpga_enumerate.c| 10 +--
>  drivers/raw/ifpga/base/opae_eth_group.c |  1 +
>  drivers/raw/ifpga/base/opae_i2c.c   |  5 +++-
>  drivers/raw/ntb/ntb.c   |  9 +++---
>  drivers/regex/mlx5/mlx5_rxp.c   |  4 ++-
>  22 files changed, 100 insertions(+), 45 deletions(-)

There is some rebase needed: at least one patch on net/ice does not
apply anymore, and I see that the fix on crypto/dpaa2_sec needs a
rebase too to be complete.
I only looked at the first 5 patches, and sent some comments.
I don't think the rest of the patches will be different, I expect more
comments or doubts from me.

It is already late here, I won't take this series for -rc2, sorry.

To make this series progress, I suggest rebasing, and sending per
driver series, so that those series land in the relevant subtrees.


Thanks.


-- 
David Marchand

dpdk-devbind.py ./. bonding interfaces

[qcqx-obaq . 6cba8489]

To whom it may concern.

usertools/dpdk-devbind.py currently does not recognize interfaces 
that are part of a bond as active.
that can be a nuisance if you are using something like libmoon which
proactively rebinds drivers for all "not active" interfaces.

yes, i am aware of the dpdk contribution guideline. 

no, i am not going to jump through linux-kernel level hoops for
a trivial 9-sloc-python driveby-contrib.

yes, that glorious code is all written by me, i promise i didnt
steal it, and whoever takes pity and merges it is free to claim
full credits for it.
(if you feel bad about claiming credits for something you didnt
 write, perhaps find more useful names for "f" and "l" and/or
 add some comment above it...)

yes, i promise i will read and respect the contrib guide if i ever
want to contrib code that took longer to write than it takes to
read the contrib guide.

regards,
   x23


diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 4d9c1be666..d02552de33 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -244,6 +244,16 @@ def get_device_details(devices_type):
 if rt_info[i] == "dev":
 ssh_if.append(rt_info[i + 1])
 
+bdir = "/proc/net/bonding"
+if os.path.exists(bdir):
+for bn in os.listdir(bdir):
+f = open(os.path.join(bdir, bn))
+bs = f.read()
+f.close()
+for l in bs.splitlines():
+if l[:17] == "Slave Interface: ":
+ssh_if.append(l[17:])
+
 # based on the basic info, get extended text details
 for d in devices.keys():
 if not device_type_match(devices[d], devices_type):

[PATCH v1] baseband/acc100: remove file prefix for internal file

[Nicolas Chautru]

File renamed to avoid the rte_ file prefix since rte_acc100_pmd.h
is actually internal only.

Signed-off-by: Nicolas Chautru 
---
 drivers/baseband/acc100/acc100_pmd.h | 624 +++
 drivers/baseband/acc100/rte_acc100_pmd.c |   2 +-
 drivers/baseband/acc100/rte_acc100_pmd.h | 624 ---
 3 files changed, 625 insertions(+), 625 deletions(-)
 create mode 100644 drivers/baseband/acc100/acc100_pmd.h
 delete mode 100644 drivers/baseband/acc100/rte_acc100_pmd.h

diff --git a/drivers/baseband/acc100/acc100_pmd.h 
b/drivers/baseband/acc100/acc100_pmd.h
new file mode 100644
index 000..0c9810c
--- /dev/null
+++ b/drivers/baseband/acc100/acc100_pmd.h
@@ -0,0 +1,624 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Intel Corporation
+ */
+
+#ifndef _RTE_ACC100_PMD_H_
+#define _RTE_ACC100_PMD_H_
+
+#include "acc100_pf_enum.h"
+#include "acc100_vf_enum.h"
+#include "rte_acc100_cfg.h"
+
+/* Helper macro for logging */
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, acc100_logtype, fmt "\n", \
+   ##__VA_ARGS__)
+
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, "acc100_pmd: " fmt, \
+   ##__VA_ARGS__)
+#else
+#define rte_bbdev_log_debug(fmt, ...)
+#endif
+
+#define ACC100_VARIANT 0
+#define ACC101_VARIANT 1
+
+/* ACC100 PF and VF driver names */
+#define ACC100PF_DRIVER_NAME   intel_acc100_pf
+#define ACC100VF_DRIVER_NAME   intel_acc100_vf
+
+/* ACC100 PCI vendor & device IDs */
+#define ACC100_VENDOR_ID   (0x8086)
+#define ACC100_PF_DEVICE_ID(0x0d5c)
+#define ACC100_VF_DEVICE_ID(0x0d5d)
+
+/* Values used in filling in descriptors */
+#define ACC100_DMA_DESC_TYPE   2
+#define ACC100_DMA_CODE_BLK_MODE   0
+#define ACC100_DMA_BLKID_FCW   1
+#define ACC100_DMA_BLKID_IN2
+#define ACC100_DMA_BLKID_OUT_ENC   1
+#define ACC100_DMA_BLKID_OUT_HARD  1
+#define ACC100_DMA_BLKID_OUT_SOFT  2
+#define ACC100_DMA_BLKID_OUT_HARQ  3
+#define ACC100_DMA_BLKID_IN_HARQ   3
+
+/* Values used in filling in decode FCWs */
+#define ACC100_FCW_TD_VER  1
+#define ACC100_FCW_TD_EXT_COLD_REG_EN  1
+#define ACC100_FCW_TD_AUTOMAP  0x0f
+#define ACC100_FCW_TD_RVIDX_0  2
+#define ACC100_FCW_TD_RVIDX_1  26
+#define ACC100_FCW_TD_RVIDX_2  50
+#define ACC100_FCW_TD_RVIDX_3  74
+
+/* Values used in writing to the registers */
+#define ACC100_REG_IRQ_EN_ALL  0x1FF83FF  /* Enable all interrupts */
+
+/* ACC100 Specific Dimensioning */
+#define ACC100_SIZE_64MBYTE(64*1024*1024)
+/* Number of elements in an Info Ring */
+#define ACC100_INFO_RING_NUM_ENTRIES   1024
+/* Number of elements in HARQ layout memory */
+#define ACC100_HARQ_LAYOUT (64*1024*1024)
+/* Assume offset for HARQ in memory */
+#define ACC100_HARQ_OFFSET (32*1024)
+#define ACC100_HARQ_OFFSET_SHIFT   15
+#define ACC100_HARQ_OFFSET_MASK0x7ff
+/* Mask used to calculate an index in an Info Ring array (not a byte offset) */
+#define ACC100_INFO_RING_MASK  (ACC100_INFO_RING_NUM_ENTRIES-1)
+/* Number of Virtual Functions ACC100 supports */
+#define ACC100_NUM_VFS  16
+#define ACC100_NUM_QGRPS8
+#define ACC100_NUM_QGRPS_PER_WORD   8
+#define ACC100_NUM_AQS  16
+#define MAX_ENQ_BATCH_SIZE  255
+/* All ACC100 Registers alignment are 32bits = 4B */
+#define ACC100_BYTES_IN_WORD 4
+#define ACC100_MAX_E_MBUF64000
+
+#define ACC100_GRP_ID_SHIFT10 /* Queue Index Hierarchy */
+#define ACC100_VF_ID_SHIFT 4  /* Queue Index Hierarchy */
+#define ACC100_VF_OFFSET_QOS   16 /* offset in Memory specific to QoS Mon */
+#define ACC100_TMPL_PRI_0  0x03020100
+#define ACC100_TMPL_PRI_1  0x07060504
+#define ACC100_TMPL_PRI_2  0x0b0a0908
+#define ACC100_TMPL_PRI_3  0x0f0e0d0c
+#define ACC100_QUEUE_ENABLE0x8000  /* Bit to mark Queue as Enabled */
+#define ACC100_WORDS_IN_ARAM_SIZE (128 * 1024 / 4)
+#define ACC100_FDONE0x8000
+#define ACC100_SDONE0x4000
+
+#define ACC100_NUM_TMPL   32
+/* Mapping of signals for the available engines */
+#define ACC100_SIG_UL_5G  0
+#define ACC100_SIG_UL_5G_LAST 7
+#define ACC100_SIG_DL_5G  13
+#define ACC100_SIG_DL_5G_LAST 15
+#define ACC100_SIG_UL_4G  16
+#define ACC100_SIG_UL_4G_LAST 21
+#define ACC100_SIG_DL_4G  27
+#define ACC100_SIG_DL_4G_LAST 31
+#define ACC100_NUM_ACCS   5
+#define ACC100_ACCMAP_0   0
+#define ACC100_ACCMAP_1   2
+#define ACC100_ACCMAP_2   1
+#define ACC100_ACCMAP_3   3
+#define ACC100_ACCMAP_4   4
+#define ACC100_PF_VAL 2
+
+/* max number of iterations to allocate memory block for all rings */
+#define ACC100_SW_RING_MEM_ALLOC_ATTEMPTS 5
+#define ACC100_MAX_QUEUE_DEPTH102

[PATCH v1] baseband/turbo_sw: Remove flexran_sdk meson option

[Nicolas Chautru]

Hi Thomas, 
This is change you requested earlier this year. This is targeting 22.11.
Basically we no longer pass a specific option but rely on pkgconfig.
There is small change to generate the .pc files that Intel will make available
by end of year. Still the related change in DPDK is available now.

Thanks
Nic

Nicolas Chautru (1):
  baseband/turbo_sw: remove Flexran SDK meson option

 doc/guides/bbdevs/turbo_sw.rst|  6 --
 drivers/baseband/turbo_sw/meson.build | 36 +--
 meson_options.txt |  2 --
 3 files changed, 17 insertions(+), 27 deletions(-)

-- 
1.8.3.1

[PATCH v1] baseband/turbo_sw: remove Flexran SDK meson option

[Nicolas Chautru]

The related dependency to build the PMD based on the
SDK libraries is now enabled through pkfconfig.

Signed-off-by: Nicolas Chautru 
---
 doc/guides/bbdevs/turbo_sw.rst|  6 --
 drivers/baseband/turbo_sw/meson.build | 36 +--
 meson_options.txt |  2 --
 3 files changed, 17 insertions(+), 27 deletions(-)

diff --git a/doc/guides/bbdevs/turbo_sw.rst b/doc/guides/bbdevs/turbo_sw.rst
index 1e23e37..eb91953 100644
--- a/doc/guides/bbdevs/turbo_sw.rst
+++ b/doc/guides/bbdevs/turbo_sw.rst
@@ -136,7 +136,8 @@ In order to enable this virtual bbdev PMD, the user may:
   FlexRAN SDK libraries were installed. And ``DIR_WIRELESS_SDK`` to the path
   where the libraries were extracted.
 
-* Tune the meson build option pointing the location of the FlexRAN SDK 
libraries ``flexran_sdk``
+* Point pkgconfig towards these libraries so that they can be automatically 
found by meson with the
+right dependency. If not DPDK will still compile but the related functionality 
would be stubbed out.
 
 Example:
 
@@ -144,8 +145,9 @@ Example:
 
 export 
FLEXRAN_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/install
 export 
DIR_WIRELESS_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/
+export PKG_CONFIG_PATH=$DIR_WIRELESS_SDK/pkgcfg:$PKG_CONFIG_PATH
 cd build
-meson configure 
-Dflexran_sdk=/FlexRAN-FEC-SDK-19-04/sdk/build-avx512-icc/install
+meson configure
 
 * For AVX512 machines with SDK libraries installed then both 4G and 5G can be 
enabled for full real time FEC capability.
   For AVX2 machines it is possible to only enable the 4G libraries and the PMD 
capabilities will be limited to 4G FEC.
diff --git a/drivers/baseband/turbo_sw/meson.build 
b/drivers/baseband/turbo_sw/meson.build
index 477b8b3..9e35156 100644
--- a/drivers/baseband/turbo_sw/meson.build
+++ b/drivers/baseband/turbo_sw/meson.build
@@ -1,38 +1,28 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2019 Intel Corporation
 
-path = get_option('flexran_sdk')
+# check for FlexRAN SDK libraries
+dep_turbo = dependency('flexran_sdk_turbo', required: false)
+dep_dec5g = dependency('flexran_sdk_ldpc_decoder_5gnr', required: false)
 
-# check for FlexRAN SDK libraries for AVX2
-lib4g = cc.find_library('libturbo', dirs: [path + '/lib_turbo'], required: 
false)
-if lib4g.found()
-ext_deps += cc.find_library('libturbo', dirs: [path + '/lib_turbo'], 
required: true)
-ext_deps += cc.find_library('libcrc', dirs: [path + '/lib_crc'], required: 
true)
-ext_deps += cc.find_library('librate_matching', dirs: [path + 
'/lib_rate_matching'], required: true)
-ext_deps += cc.find_library('libcommon', dirs: [path + '/lib_common'], 
required: true)
+if dep_turbo.found()
 ext_deps += cc.find_library('libstdc++', required: true)
 ext_deps += cc.find_library('libirc', required: true)
 ext_deps += cc.find_library('libimf', required: true)
 ext_deps += cc.find_library('libipps', required: true)
 ext_deps += cc.find_library('libsvml', required: true)
-includes += include_directories(path + '/lib_turbo')
-includes += include_directories(path + '/lib_crc')
-includes += include_directories(path + '/lib_rate_matching')
-includes += include_directories(path + '/lib_common')
+   ext_deps += dep_turbo
+   ext_deps += dependency('flexran_sdk_crc', required: true)
+   ext_deps += dependency('flexran_sdk_rate_matching', required: true)
+   ext_deps += dependency('flexran_sdk_common', required: true)
 cflags += ['-DRTE_BBDEV_SDK_AVX2']
 endif
 
-# check for FlexRAN SDK libraries for AVX512
-lib5g = cc.find_library('libldpc_decoder_5gnr', dirs: [path + 
'/lib_ldpc_decoder_5gnr'], required: false)
-if lib5g.found()
-ext_deps += cc.find_library('libldpc_encoder_5gnr', dirs: [path + 
'/lib_ldpc_encoder_5gnr'], required: true)
-ext_deps += cc.find_library('libldpc_decoder_5gnr', dirs: [path + 
'/lib_ldpc_decoder_5gnr'], required: true)
-ext_deps += cc.find_library('libLDPC_ratematch_5gnr', dirs: [path + 
'/lib_LDPC_ratematch_5gnr'], required: true)
-ext_deps += cc.find_library('librate_dematching_5gnr', dirs: [path + 
'/lib_rate_dematching_5gnr'], required: true)
-includes += include_directories(path + '/lib_ldpc_encoder_5gnr')
-includes += include_directories(path + '/lib_ldpc_decoder_5gnr')
-includes += include_directories(path + '/lib_LDPC_ratematch_5gnr')
-includes += include_directories(path + '/lib_rate_dematching_5gnr')
+if dep_dec5g.found()
+   ext_deps += dep_dec5g
+   ext_deps += dependency('flexran_sdk_ldpc_encoder_5gnr', required: true)
+   ext_deps += dependency('flexran_sdk_LDPC_ratematch_5gnr', required: 
true)
+   ext_deps += dependency('flexran_sdk_rate_dematching_5gnr', required: 
true)
 cflags += ['-DRTE_BBDEV_SDK_AVX512']
 endif
 
diff --git a/meson_options.txt b/meson_options.txt
index 7c220ad..abaa304 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -22,8 +22,6 @@ o