[PATCH] eal/linux: clear asan after allocation and before prefaulting

[Alex Michon]

Prefaulting may generate asan error.

Signed-off-by: Alex Michon 
---
 .mailmap | 1 +
 lib/eal/linux/eal_memalloc.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/.mailmap b/.mailmap
index 3f3f0442e5..b1655a4080 100644
--- a/.mailmap
+++ b/.mailmap
@@ -60,6 +60,7 @@ Alexey Kardashevskiy 
 Alex Kiselev  
 Alex Marginean 
 Alex Markuze 
+Alex Michon 
 Alex Porosanu 
 Alex Rosenbaum  
 Alex Vesker 
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index e354efc95d..b9c631ea88 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -38,6 +38,8 @@
 #include "eal_memcfg.h"
 #include "eal_private.h"
 
+#include "malloc_elem.h"
+
 const int anonymous_hugepages_supported =
 #ifdef MAP_HUGE_SHIFT
1;
@@ -636,6 +638,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
goto mapped;
}
 
+   /* Ensure the prefault doesn't trigger ASAN errors */
+   asan_set_zone(addr, alloc_sz, 0);
+
/* we need to trigger a write to the page to enforce page fault and
 * ensure that page is accessible to us, but we can't overwrite value
 * that is already there, so read the old value, and write itback.
-- 
2.17.1

DPDK Release Status Meeting 2024-07-25

[Mcnamara, John]

Release status meeting minutes 2024-07-25
=

Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens

Participants:
* AMD
* ARM
* Debian/Microsoft
* Intel
* Marvell
* Nvidia
* Red Hat


Release Dates
-

The following are the current/updated working dates for 24.07:

- Proposal deadline (RFC/v1 patches): 26 April 2024
- API freeze (-rc1): 14 June 2024
- PMD features freeze (-rc2): 12 July 2024
- Builtin applications features freeze (-rc3): 22 July 2024
- Release: 31 July 2023


https://core.dpdk.org/roadmap/#dates


Subtrees


* next-net
  * RC3 released.

* next-net-intel
  * No post RC3 changes.

* next-net-mlx
  * Crash in virtio with VDBA, under investigation.

* next-net-mvl
  * No post RC3 changes.

* next-eventdev
  * No post RC3 changes. 1 fix will go to next release.

* next-baseband
  * No post RC3 changes.

* next-virtio
  * 1 fix patch under investigation.

* next-crypto
  * Issue reported in ipsec-gw. May need to be reverted.
https://inbox.dpdk.org/dev/7c690dcb-8824-452e-85d5-7f665ff56...@intel.com/

* main
  * RC3 released 23 July.
  * RC4 should be Monday 29 July
  * Release on 30/31 July
  * Please ack these and other deprecation notices:

https://patches.dpdk.org/project/dpdk/patch/20240221161319.7054-1-pbhagavat...@marvell.com/

https://patches.dpdk.org/project/dpdk/patch/20240722145324.1091-1-gmuthukri...@marvell.com/

https://patches.dpdk.org/project/dpdk/patch/20240722145551.1159-1-gmuthukri...@marvell.com/

https://patches.dpdk.org/project/dpdk/patch/20240723133706.2150828-1-asasidha...@marvell.com/




The following are the proposed dates for 24.11:

- Proposal deadline (RFC/v1 patches): 7 September 2024
- API freeze (-rc1): 7 October 2024
- PMD features freeze (-rc2): 28 October 2024
- Builtin applications features freeze (-rc3): 4 November 2024
- Release: 18 November 2023


LTS
---

Status of the current LTSes

* 23.11.2 - In progress.
* 22.11.6 - In progress.
* 21.11.8 - In progress.

* 20.11.10 - Will only be updated with CVE and critical fixes.
* 19.11.15 - Will only be updated with CVE and critical fixes.


* Distros
  * Debian 12 contains DPDK v22.11
  * Ubuntu 24.04 contains DPDK v23.11
  * Ubuntu 23.04 contains DPDK v22.11
  * RHEL 8/9 contains DPDK 23.11

Defects
---

* Bugzilla links, 'Bugs',  added for hosted projects
  * https://www.dpdk.org/hosted-projects/



DPDK Release Status Meetings


The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.

The meeting occurs on every Thursday at 9:30 UTC over Jitsi on 
https://meet.jit.si/DPDK

You don't need an invite to join the meeting but if you want a calendar 
reminder just
send an email to "John McNamara john.mcnam...@intel.com" for the invite.

RE: [EXTERNAL] Re: [PATCH] doc: announce vhost changes to support asymmetric operation

[Gowrishankar Muthukrishnan]

Sure Jerin. I’ll drop this proposal as ABI versioning could help. Thanks.




Looks like in this case adding new arguments to function. Could you

check ABI versing helps here? It seems like it can be easy manged with

ABI versioning.

RE: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO

[Kusztal, ArkadiuszX]

Hi Gowrishankar,

> -Original Message-
> From: Gowrishankar Muthukrishnan 
> Sent: Monday, July 22, 2024 4:56 PM
> To: dev@dpdk.org; Anoob Joseph ; Richardson, Bruce
> ; ciara.po...@intel.com; jer...@marvell.com;
> fanzhang@gmail.com; Kusztal, ArkadiuszX ;
> Ji, Kai ; jack.bond-pres...@foss.arm.com; Marchand, David
> ; hemant.agra...@nxp.com; De Lara Guarch,
> Pablo ; Trahe, Fiona
> ; Doherty, Declan ;
> ma...@nvidia.com; ruifeng.w...@arm.com; Gujjar, Abhinandan S
> ; maxime.coque...@redhat.com;
> chen...@nvidia.com; sunilprakashrao.uttar...@amd.com;
> andrew.bo...@amd.com; ajit.khapa...@broadcom.com;
> raveendra.padasal...@broadcom.com; vikas.gu...@broadcom.com;
> zhangfei@linaro.org; g.si...@nxp.com; jianjay.z...@huawei.com; Daly,
> Lee 
> Cc: Gowrishankar Muthukrishnan 
> Subject: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO
> 
> Announce cryptodev changes to offload RSA asymmetric operation in VirtIO
> PMD.
> 
> Signed-off-by: Gowrishankar Muthukrishnan 
> --
> RFC:
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-2-
> gmuthukri...@marvell.com/
>   https://patches.dpdk.org/project/dpdk/patch/20230928095300.1353-3-
> gmuthukri...@marvell.com/
> ---
>  doc/guides/rel_notes/deprecation.rst | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 6948641ff6..26fec84aba 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -147,3 +147,14 @@ Deprecation Notices
>will be deprecated and subsequently removed in DPDK 24.11 release.
>Before this, the new port library API (functions rte_swx_port_*)
>will gradually transition from experimental to stable status.
> +
> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from
> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,
> +  breaking ABI. The new location is recommended to comply with
> +  virtio-crypto specification. Applications and drivers using
> +  this struct will be updated.
> +

The problem here, I see is that there is one private key but multiple 
combinations of padding.
Therefore, for every padding variation, we need to copy the same private key 
anew, duplicating it in memory.
The only reason for me to keep a session-like struct in asymmetric crypto was 
exactly this.

> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key
> +  in either exponent or quintuple format is changed from union to
> +struct
> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> A.1.2).
> +  This change will not break existing applications.
This one I agree. RFC 8017 obsoletes RFC 3447.
> --
> 2.21.0

Re: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem

[Radu Nicolau]

On 25-Jul-24 5:47 AM, Akhil Goyal wrote:

On 24-Jul-24 2:04 PM, Akhil Goyal wrote:

On 24-Jul-24 12:20 PM, Akhil Goyal wrote:

On 23-Jul-24 5:57 PM, Akhil Goyal wrote:

Hi all,

This patch breaks ipsec tests with ipsec-secgw:


./examples/ipsec-secgw/test/run_test.sh -4 trs_aesctr_sha1
...
ERROR: ./examples/ipsec-secgw/test/linux_test.sh failed for

dst=192.168.31.14,

sz=1
 test IPv4 trs_aesctr_sha1 finished with status 1
ERROR  test trs_aesctr_sha1 FAILED


The patch seems to be correct.
Please check endianness in the PMD you are testing.

In my opinion salt should not be affected by endianness and it should be
used as it is in the key parameter. I think the patch is wrong to make
it CPU endianness dependent before being passed to the PMDs, any PMD
that needs the endianness swapped should do it in the PMD code. Indeed
it's passed around as a 32 bit integer but it's not used as such, and
when it's actually used it should be evaluated as a byte array.


As per the rfc, it should be treated as byte order(i.e. big endian).
But here the problem is we treat it as uint32_t which makes it CPU endian

when stored in ipsec_sa struct.

The keys are stored as an array of uint8_t, so keys are stored in byte

order(Big

endian).

So either we save salt as "uint8_t salt[4]" or do a conversion of cpu_to_be
So that when it is stored in PMD/HW, and we convert it from uint32_t to

uint_8

*, there wont be issue.

RFC treats it as a "four octet value" - there is no endianness until
it's treated like an integer, which it never is. Even if it code it's
being stored and passed as an unsigned 32bit integer it is never
evaluated as such so its endianness doesn't matter.

The endianness matters the moment it is stored as uint32_t in ipsec_sa
It means the value is stored in CPU endianness in that integer unless it is

specified.

What matters is that the four byte value in the key ends up in the
memory in the same order, and that was always the case before the patch,
regardless of the endianness of the CPU because load and store
operations are not affected by endianness. With the patch the same four
bytes from the configuration file will be stored differently in memory
depending on the CPU. There is no need to fix the endianness of the
salt, just as there is no need to fix the byte order of the key itself.


When a uint32 is used, there is no clarity whether it is in BE or LE.
So that is where the confusion comes.
For any new person, uint32 means it is in CPU byte order.
This patch tried to address that but it failed to address all the cases.
So my simple suggestion is instead of fixing the byte order at every place,
Lets just change the ipsec_sa->salt as rte_be32_t from uint32_t and revert this 
patch.
This will make things clear.
I am suggesting to convert this uint32_t to rte_be32_t for library as well for 
salt.
This change is not swapping anything, but making things explicitly clear that 
salt is in BE.


I agree with the suggestion of using rte_be32_t and reverting the patch.

(I still think it would be even better to use uint8_t[4] to reflect that 
it is a four byte value with no endianness but that's just IMHO, the 
important thing is to revert the patch that broke the functionality)






Now looking at the code again, I see the patch is incomplete for the case of

lookaside crypto

Where the salt is copied as cnt_blk in the mbuf priv without conversion.

So, this patch can be reverted and a simple fix can be added to mark ipsec_sa->

salt as rte_be32_t

diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index a83fd2283b..1fe6b97168 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -117,7 +117,7 @@ struct __rte_cache_aligned ipsec_sa {
  uint32_t spi;
  struct cdev_qp *cqp[RTE_MAX_LCORE];
  uint64_t seq;
-   uint32_t salt;
+   rte_be32_t salt;
  uint32_t fallback_sessions;
  enum rte_crypto_cipher_algorithm cipher_algo;
  enum rte_crypto_auth_algorithm auth_algo;

Can you verify and send the patch?
And this may be updated in cryptodev and security lib as well in next release.



I agree that we should have it everywhere as "uint8_t salt[4]" but that
implies API changes and it doesn't change how the bytes are stored, so
the patch will still be wrong.



On 03/07/2024 18:58, Akhil Goyal wrote:





-Original Message-
From: Akhil Goyal 

Sent: Friday, March 15, 2024 12:42 AM
To: Akhil Goyal 
 ; Chaoyong He

 ; dev@dpdk.org



Cc: oss-driv...@corigine.com  ; Shihong Wang 
 ;
sta...@dpdk.org 
Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix
SA salt
endianne

RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem

[Akhil Goyal]

> 
> On 25-Jul-24 5:47 AM, Akhil Goyal wrote:
> >> On 24-Jul-24 2:04 PM, Akhil Goyal wrote:
>  On 24-Jul-24 12:20 PM, Akhil Goyal wrote:
> >> On 23-Jul-24 5:57 PM, Akhil Goyal wrote:
>  Hi all,
> 
>  This patch breaks ipsec tests with ipsec-secgw:
> 
> 
>  ./examples/ipsec-secgw/test/run_test.sh -4 trs_aesctr_sha1
>  ...
>  ERROR: ./examples/ipsec-secgw/test/linux_test.sh failed for
> >> dst=192.168.31.14,
>  sz=1
>   test IPv4 trs_aesctr_sha1 finished with status 1
>  ERROR  test trs_aesctr_sha1 FAILED
> 
> >>> The patch seems to be correct.
> >>> Please check endianness in the PMD you are testing.
> >> In my opinion salt should not be affected by endianness and it should 
> >> be
> >> used as it is in the key parameter. I think the patch is wrong to make
> >> it CPU endianness dependent before being passed to the PMDs, any PMD
> >> that needs the endianness swapped should do it in the PMD code. Indeed
> >> it's passed around as a 32 bit integer but it's not used as such, and
> >> when it's actually used it should be evaluated as a byte array.
> >>
> > As per the rfc, it should be treated as byte order(i.e. big endian).
> > But here the problem is we treat it as uint32_t which makes it CPU 
> > endian
>  when stored in ipsec_sa struct.
> > The keys are stored as an array of uint8_t, so keys are stored in byte
> >> order(Big
>  endian).
> > So either we save salt as "uint8_t salt[4]" or do a conversion of 
> > cpu_to_be
> > So that when it is stored in PMD/HW, and we convert it from uint32_t to
> >> uint_8
>  *, there wont be issue.
> 
>  RFC treats it as a "four octet value" - there is no endianness until
>  it's treated like an integer, which it never is. Even if it code it's
>  being stored and passed as an unsigned 32bit integer it is never
>  evaluated as such so its endianness doesn't matter.
> >>> The endianness matters the moment it is stored as uint32_t in ipsec_sa
> >>> It means the value is stored in CPU endianness in that integer unless it 
> >>> is
> >> specified.
> >>
> >> What matters is that the four byte value in the key ends up in the
> >> memory in the same order, and that was always the case before the patch,
> >> regardless of the endianness of the CPU because load and store
> >> operations are not affected by endianness. With the patch the same four
> >> bytes from the configuration file will be stored differently in memory
> >> depending on the CPU. There is no need to fix the endianness of the
> >> salt, just as there is no need to fix the byte order of the key itself.
> >>
> > When a uint32 is used, there is no clarity whether it is in BE or LE.
> > So that is where the confusion comes.
> > For any new person, uint32 means it is in CPU byte order.
> > This patch tried to address that but it failed to address all the cases.
> > So my simple suggestion is instead of fixing the byte order at every place,
> > Lets just change the ipsec_sa->salt as rte_be32_t from uint32_t and revert 
> > this
> patch.
> > This will make things clear.
> > I am suggesting to convert this uint32_t to rte_be32_t for library as well 
> > for salt.
> > This change is not swapping anything, but making things explicitly clear 
> > that salt
> is in BE.
> 
> I agree with the suggestion of using rte_be32_t and reverting the patch.

Can you send a patch with both the changes?
> 
> (I still think it would be even better to use uint8_t[4] to reflect that
> it is a four byte value with no endianness but that's just IMHO, the
> important thing is to revert the patch that broke the functionality)
> 
That can be for next release in library.

RE: [PATCH v2] doc: announce rte_ipsec API changes

[Aakash Sasidharan]

> -Original Message-
> From: Konstantin Ananyev 
> Sent: Wednesday, July 24, 2024 10:39 PM
> To: Aakash Sasidharan 
> Cc: Akhil Goyal ; Jerin Jacob ;
> Anoob Joseph ; Vidya Sagar Velumuri
> ; dev@dpdk.org; konstantin.v.anan...@yandex.ru;
> vladimir.medved...@intel.com
> Subject: [EXTERNAL] RE: [PATCH v2] doc: announce rte_ipsec API changes
> 
> > > > In case of event mode operations where event device can help in
> > > > atomic sequence number increment across cores, sequence number
> > > > need to be provided by the application instead of being updated in
> > > > rte_ipsec or the PMD. To support this, a new flag
> > > > ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE``
> > > > will be added to disable sequence number update inside IPsec
> > > > library and the API rte_ipsec_pkt_crypto_prepare will be extended
> > > > to include ``sqn`` as an additional parameter to specify sequence
> > > > number to be used for IPsec from the application.
> > >
> > > Could you probably elaborate a bit more:
> > > Why such change is necessary for event-dev mode, what exactly will
> > > be affected in librte_ipsec (would it be for outbound mode, or both), etc.
> > >
> >
> > [Aakash] When using eventdev, it is possible to have multiple cores
> > process packets from the same flow at the same time, but still have ordering
> maintained.
> >
> > Sequence for IPsec would be like below, 1. Ethdev Rx computes flow
> > hash and submits packets to an ORDERED eventdev queue.
> > One flow would always hit one event dev queue.
> > One eventdev queue can be attached to multiple eventdev ports.
> > 2. Lcores receives packets via these eventdev ports.
> > Lcores can now process the packets from the same flow in parallel.
> > 3. Lcores submit the packets to an ATOMIC queue
> > This is needed as IPsec seq no update needs to be done atomically.
> > 4. After seq no update, packets are moved to ORDERED queue.
> > Lcores can now processes the packets in parallel again.
> > 5. During Tx, eventdev ensures packet ordering based on ORDERED queue.
> >
> > Since lib IPsec takes care of sequence number assignment, complete
> > rte_ipsec_pkt_crypto_prepare() routine need to be made as ATOMIC stage.
> > But apart from seq no update, rest of the operations can be done in 
> > parallel.
> 
> Thanks for explanation.
> Basically you are seeking ability to split rte_ipsec_pkt_crypto_prepare() for
> outbound into two stages:
> 1. update sqn
> 2. all other preps
> To be able to do step #2 in parallel, correct?
> My thought always was that step #2 is not that expensive in terms of
> performance, and there probably not much point to make it parallel.
> But I suppose you measured step#2 overhead on your platform and
> concluded that it worth it...
> 
> One concern I have with the way you suggested - now we need to
> store/update sa.sqn by some external entity.
> Another thing - don't really want to pollute crypto_prepare() API with new
> parameters which meaning is a bit obscure and depends on other API calls...
> 
> Wouldn't it be easier and probably more straightforward to just introduce 2
> new functions here that would represent step #1 and step #2?
> Then we can keep crypto_prepare() intact, and user will have a choice:
> - either use  original crypto_prepare() - nothing needs to be changed
> -  or instead call these new functions on his own, if he wants to.
> 

[Aakash] As I understand, your suggestion is to introduce a set of two new APIs 
by splitting the current logic in crypto_prepare(). This should be okay.
For this, I believe we would need change in the structure rte_ipsec_sa_pkt_func 
to hold the function pointers for the new APIs.

Assuming that, introduction of the new flag RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE 
to disable seq no assignment in lib IPsec is fine, shall I send v3 announcing 
changes in ``struct rte_ipsec_sa_pkt_func``?

> > In addition, we are also looking at another use case when a set of
> > packets from a session can be IPsec processed by rte_security device
> > and some packets from the same session would need to be SW processed
> with lib IPsec. Here again the sequence number assignment would need to
> occur at central place so that sequence number is not repeated.
> 
> Interesting, and how SW/HW SQN will be synchronized in that case?
> 

[Aakash] The design is such that HW would assign sequence number for all cases. 
HW would then pass this data as a metadata to SW so that it can do SW 
processing with the assigned sequence number.

> > Initially we are looking at outbound only. But similar kind of use case 
> > would
> be applicable for inbound also.
> >
> > > >
> > > > Signed-off-by: Aakash Sasidharan 
> > > > ---
> > > >  doc/guides/rel_notes/deprecation.rst | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > index 6948641ff6..bc1d93cca7 100644
> > > > --- a/doc/guides/rel_notes/deprecatio

Re: [PATCH] net/gve: Fix TX/RX queue setup and stop

[Ferruh Yigit]

On 7/24/2024 2:35 PM, Tathagat Priyadarshi wrote:
> The PR aims to update the TX/RQ queue setup/stop routines that are
> unique to DQO, so that they may be called for instances that use the
> DQO RDA format during dev start/stop.
> 
> Signed-off-by: Tathagat Priyadarshi 
> Acked-by: Joshua Washington 
>


Is this v3 ?

And I can see Joshua's ack, but I didn't see it explicitly, did you work
together in background for this?

Re: [PATCH] app/testpmd: improve sse based macswap

[Varghese, Vipin]

Hi Bruce,

Thanks for highlighting the variance. We found this was an internal test 
bed configuration issue. We are sharing the next version of the same 
patch with updated numbers.



On 7/23/2024 10:42 PM, Bruce Richardson wrote:

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


On Tue, Jul 23, 2024 at 05:45:57PM +0100, Ferruh Yigit wrote:

On 7/16/2024 7:37 AM, Vipin Varghese wrote:

Goal of the patch is to improve SSE macswap on x86_64 by reducing
the stalls in backend engine. Original implementation of the SSE
macswap makes loop call to multiple load, shuffle & store. Using
SIMD ISA interleaving we can reduce the stalls for
  - load SSE token exhaustion
  - Shuffle and Load dependency

Also other changes which improves packet per second are
  - Filling access to MBUF for offload flags which is separate cacheline,
  - using register keyword

Build test using meson script:
``

build-gcc-static
buildtools
build-gcc-shared
build-mini
build-clang-static
build-clang-shared
build-x86-generic

Test Results:
`

Platform-1: AMD EPYC SIENA 8594P @2.3GHz, no boost


TEST IO 64B: baseline 
  - mellanox CX-7 2*200Gbps : 42.0
  - intel E810 1*100Gbps : 82.0
  - intel E810 2*200Gbps (2CQ-DA2): 82.45

TEST MACSWAP 64B: 
  - mellanox CX-7 2*200Gbps : 31.533 : 31.90
  - intel E810 1*100Gbps : 50.380 : 47.0
  - intel E810 2*200Gbps (2CQ-DA2): 48.840 : 49.827

TEST MACSWAP 128B: 
  - mellanox CX-7 2*200Gbps: 30.946 : 31.770
  - intel E810 1*100Gbps: 49.386 : 46.366
  - intel E810 2*200Gbps (2CQ-DA2): 47.979 : 49.503

TEST MACSWAP 256B: 
  - mellanox CX-7 2*200Gbps: 32.480 : 33.150
  - intel E810 1 * 100Gbps: 45.29 : 44.571
  - intel E810 2 * 200Gbps (2CQ-DA2): 45.033 : 45.117


Platform-2: AMD EPYC 9554 @3.1GHz, no boost


TEST IO 64B: baseline 
  - intel E810 2*200Gbps (2CQ-DA2): 82.49


TEST MACSWAP: 1Q 1C1T
  64B: : 45.0 : 45.54
128B: : 44.48 : 44.43
256B: : 42.0 : 41.99
+
TEST MACSWAP: 2Q 2C2T
  64B: : 59.5 : 60.55
128B: : 56.78 : 58.1
256B: : 41.85 : 41.99


Signed-off-by: Vipin Varghese


Hi Bruce, John,

Can you please help testing macswap performance with this patch on Intel
platforms, to be sure it is not causing regression?


Hi Ferruh,

We can try and get some Intel numbers for you, but I think at this point it
is better deferred to 24.11 due to lack of discussion and analysis of the
numbers. This is because the numbers above already show that it is causing
regressions - in fact many of the regressions are larger than the benefits
shown. This may be acceptable, but it would imply that we shouldn't be too
hasty in applying the patch.

Regards,
/Bruce

Re: [PATCH] net/gve: Fix TX/RX queue setup and stop

[Tathagat Priyadarshi]

Hi Ferruh,

It’s my mistake, there was a coding error in the first email and i did send
out v2, but it somehow didn't go through and i kept getting failure emails,
So i fixed and repushed it only to find out later that v2 was also updated.
So i had to defer the previous PR.

I have added Acked by Joshua, since the diff was originally shared with him
and he was okay with it.

Regards,
TP


On Thu, 25 Jul 2024 at 18:08, Ferruh Yigit  wrote:

> On 7/24/2024 2:35 PM, Tathagat Priyadarshi wrote:
> > The PR aims to update the TX/RQ queue setup/stop routines that are
> > unique to DQO, so that they may be called for instances that use the
> > DQO RDA format during dev start/stop.
> >
> > Signed-off-by: Tathagat Priyadarshi 
> > Acked-by: Joshua Washington 
> >
>
>
> Is this v3 ?
>
> And I can see Joshua's ack, but I didn't see it explicitly, did you work
> together in background for this?
>

Re: [PATCH] app/testpmd: improve sse based macswap

[Bruce Richardson]

On Thu, Jul 25, 2024 at 06:17:35PM +0530, Varghese, Vipin wrote:
>Hi Bruce,
>Thanks for highlighting the variance. We found this was an internal
>test bed configuration issue. We are sharing the next version of the
>same patch with updated numbers.
> 

Great, thanks for the update.

Re: [PATCH] net/gve: Fix TX/RX queue setup and stop

[Ferruh Yigit]

On 7/25/2024 1:51 PM, Tathagat Priyadarshi wrote:
> Hi Ferruh,
> 
> It’s my mistake, there was a coding error in the first email and i did
> send out v2, but it somehow didn't go through and i kept getting failure
> emails, So i fixed and repushed it only to find out later that v2 was
> also updated. So i had to defer the previous PR.
> 

So, this patch and v2 are same, if so lets continue with v2 one, as it
has proper versioning. Can you update patchwork accordingly?


btw, not really matters but PR is "Pull Request" and this is a
terminology mostly related to github based development. In mail list
based development we call it patch, or "patch series"/patchset (if
multiple patches are together).

> I have added Acked by Joshua, since the diff was originally shared with
> him and he was okay with it.
> 

Better to have this publicly, and explicitly so it is recorded.

@Joshua, if you are OK with patch, can you please ack/review?

> Regards,
> TP
> 
> 
> On Thu, 25 Jul 2024 at 18:08, Ferruh Yigit  > wrote:
> 
> On 7/24/2024 2:35 PM, Tathagat Priyadarshi wrote:
> > The PR aims to update the TX/RQ queue setup/stop routines that are
> > unique to DQO, so that they may be called for instances that use the
> > DQO RDA format during dev start/stop.
> >
> > Signed-off-by: Tathagat Priyadarshi  >
> > Acked-by: Joshua Washington  >
> >
> 
> 
> Is this v3 ?
> 
> And I can see Joshua's ack, but I didn't see it explicitly, did you work
> together in background for this?
> 

Re: [PATCH v1] net/ntnic: add missing SPDX tag

[Ferruh Yigit]

On 7/24/2024 2:14 PM, Mykola Kostenok wrote:
> Add missing SPDX tag.
> Remove exception added to './devtools/check-spdx-tag.sh' for this files.
> 
> Signed-off-by: Mykola Kostenok 
>

Hi Mykola,

Thanks for the update.


Acked-by: Ferruh Yigit 

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

[PATCH v2] net/gve: Fix TX/RX queue setup and stop

[Tathagat Priyadarshi]

The PR aims to update the TX/RQ queue setup/stop routines that are
unique to DQO, so that they may be called for instances that use the
DQO RDA format during dev start/stop

Signed-off-by: Tathagat Priyadarshi 
---
 drivers/net/gve/gve_ethdev.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index ca92277..a20092e 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -288,11 +288,16 @@ struct gve_queue_page_list *
PMD_DRV_LOG(ERR, "Failed to create %u tx queues.", num_queues);
return ret;
}
-   for (i = 0; i < num_queues; i++)
-   if (gve_tx_queue_start(dev, i) != 0) {
+   for (i = 0; i < num_queues; i++) {
+   if (gve_is_gqi(priv))
+   ret = gve_tx_queue_start(dev, i);
+   else
+   ret = gve_tx_queue_start_dqo(dev, i);
+   if (ret != 0) {
PMD_DRV_LOG(ERR, "Fail to start Tx queue %d", i);
goto err_tx;
}
+   }
 
num_queues = dev->data->nb_rx_queues;
priv->rxqs = (struct gve_rx_queue **)dev->data->rx_queues;
@@ -315,9 +320,15 @@ struct gve_queue_page_list *
return 0;
 
 err_rx:
-   gve_stop_rx_queues(dev);
+   if (gve_is_gqi(priv))
+   gve_stop_rx_queues(dev);
+   else
+   gve_stop_rx_queues_dqo(dev);
 err_tx:
-   gve_stop_tx_queues(dev);
+   if (gve_is_gqi(priv))
+   gve_stop_tx_queues(dev);
+   else
+   gve_stop_tx_queues_dqo(dev);
return ret;
 }
 
@@ -362,10 +373,16 @@ struct gve_queue_page_list *
 static int
 gve_dev_stop(struct rte_eth_dev *dev)
 {
+   struct gve_priv *priv = dev->data->dev_private;
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
 
-   gve_stop_tx_queues(dev);
-   gve_stop_rx_queues(dev);
+   if (gve_is_gqi(priv)) {
+   gve_stop_tx_queues(dev);
+   gve_stop_rx_queues(dev);
+   } else {
+   gve_stop_tx_queues_dqo(dev);
+   gve_stop_rx_queues_dqo(dev);
+   }
 
dev->data->dev_started = 0;
 
-- 
1.8.3.1

Re: [PATCH v1 2/3] dts: add dual_vlan testing suite

[Jeremy Spewock]

On Mon, Jul 22, 2024 at 1:38 PM Dean Marx  wrote:
>>
>> 
>> +recv = self.send_packet_and_capture(pakt)
>> +self.verify(len(recv) > 0, "Did not receive and packets when 
>> testing VLAN priority.")
>
>
> I'm assuming this should say "any" instead of "and." Other than that, 
> everything looks good to me.
>

Good catch, I'll fix this in the next version.

> Reviewed-by: Dean Marx 

How does CI system get updated?

[Stephen Hemminger]

This warning is due to a very old version of Mingw installed in CI system.

 20 line log output for Windows Server 2019 (dpdk_mingw64_compile): 
In file included from ..\lib\net/rte_ip.h:21,
from ../lib/net/rte_dissect.c:20:
C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: expected 
'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' {aka 'const 
unsigned char *'}
WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR 
pStringBuf, size_t StringBufSize);
~~^
../lib/net/rte_dissect.c:292:29: error: passing argument 2 of 'inet_ntop' 
discards 'const' qualifier from pointer target type 
[-Werror=discarded-qualifiers]
inet_ntop(AF_INET6, ip6_hdr->dst_addr, dbuf, sizeof(dbuf));
~~~^~
In file included from ..\lib\net/rte_ip.h:21,
from ../lib/net/rte_dissect.c:20:
C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: expected 
'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' {aka 'const 
unsigned char *'}
WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR 
pStringBuf, size_t StringBufSize);
~~^

It was fixed upstream in Mingw 4 years ago.

RE: [PATCH] doc: announce cryptodev change to support EDDSA

[Kusztal, ArkadiuszX]

> Announce the additions in cryptodev ABI to support EDDSA algorithm.
> 
> Signed-off-by: Gowrishankar Muthukrishnan 

Acked-by: Arkadiusz Kusztal 

RE: [PATCH v2] doc: announce rte_ipsec API changes

[Konstantin Ananyev]

> > > > > In case of event mode operations where event device can help in
> > > > > atomic sequence number increment across cores, sequence number
> > > > > need to be provided by the application instead of being updated in
> > > > > rte_ipsec or the PMD. To support this, a new flag
> > > > > ``RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE``
> > > > > will be added to disable sequence number update inside IPsec
> > > > > library and the API rte_ipsec_pkt_crypto_prepare will be extended
> > > > > to include ``sqn`` as an additional parameter to specify sequence
> > > > > number to be used for IPsec from the application.
> > > >
> > > > Could you probably elaborate a bit more:
> > > > Why such change is necessary for event-dev mode, what exactly will
> > > > be affected in librte_ipsec (would it be for outbound mode, or both), 
> > > > etc.
> > > >
> > >
> > > [Aakash] When using eventdev, it is possible to have multiple cores
> > > process packets from the same flow at the same time, but still have 
> > > ordering
> > maintained.
> > >
> > > Sequence for IPsec would be like below, 1. Ethdev Rx computes flow
> > > hash and submits packets to an ORDERED eventdev queue.
> > > One flow would always hit one event dev queue.
> > > One eventdev queue can be attached to multiple eventdev ports.
> > > 2. Lcores receives packets via these eventdev ports.
> > > Lcores can now process the packets from the same flow in parallel.
> > > 3. Lcores submit the packets to an ATOMIC queue
> > > This is needed as IPsec seq no update needs to be done atomically.
> > > 4. After seq no update, packets are moved to ORDERED queue.
> > > Lcores can now processes the packets in parallel again.
> > > 5. During Tx, eventdev ensures packet ordering based on ORDERED queue.
> > >
> > > Since lib IPsec takes care of sequence number assignment, complete
> > > rte_ipsec_pkt_crypto_prepare() routine need to be made as ATOMIC stage.
> > > But apart from seq no update, rest of the operations can be done in 
> > > parallel.
> >
> > Thanks for explanation.
> > Basically you are seeking ability to split rte_ipsec_pkt_crypto_prepare() 
> > for
> > outbound into two stages:
> > 1. update sqn
> > 2. all other preps
> > To be able to do step #2 in parallel, correct?
> > My thought always was that step #2 is not that expensive in terms of
> > performance, and there probably not much point to make it parallel.
> > But I suppose you measured step#2 overhead on your platform and
> > concluded that it worth it...
> >
> > One concern I have with the way you suggested - now we need to
> > store/update sa.sqn by some external entity.
> > Another thing - don't really want to pollute crypto_prepare() API with new
> > parameters which meaning is a bit obscure and depends on other API calls...
> >
> > Wouldn't it be easier and probably more straightforward to just introduce 2
> > new functions here that would represent step #1 and step #2?
> > Then we can keep crypto_prepare() intact, and user will have a choice:
> > - either use  original crypto_prepare() - nothing needs to be changed
> > -  or instead call these new functions on his own, if he wants to.
> >
> 
> [Aakash] As I understand, your suggestion is to introduce a set of two new 
> APIs by splitting the current logic in crypto_prepare(). This
> should be okay.
> For this, I believe we would need change in the structure 
> rte_ipsec_sa_pkt_func to hold the function pointers for the new APIs.

Yes, that was my thought.

> 
> Assuming that, introduction of the new flag 
> RTE_IPSEC_SAFLAG_SQN_ASSIGN_DISABLE to disable seq no assignment in lib IPsec 
> is
> fine, shall I send v3 announcing changes in ``struct rte_ipsec_sa_pkt_func``?

I am definitely not against this new flag, but if we'll have 2 new functions 
instead,
do you still need it? 

> > > In addition, we are also looking at another use case when a set of
> > > packets from a session can be IPsec processed by rte_security device
> > > and some packets from the same session would need to be SW processed
> > with lib IPsec. Here again the sequence number assignment would need to
> > occur at central place so that sequence number is not repeated.
> >
> > Interesting, and how SW/HW SQN will be synchronized in that case?
> >
> 
> [Aakash] The design is such that HW would assign sequence number for all 
> cases. HW would then pass this data as a metadata to SW
> so that it can do SW processing with the assigned sequence number.

As I can see there are two options to fulfill that requirement:

1. Introduce a new function that would update sa.sqn value.
Something like rte_ipsec_sa_update_sqn(...).
So when metadata from HW arrives, SW can call it and sync sa.sqn with new HW 
value,
and then continue with conventional rte_ipsec_crypto_prepare(...);

2. Introduce new (extended) variants of ipsec_crypto_prepare/process that would
take SQN (might be something else ?) as extra parameter, something like:

rte_ipcec_xprepare(const struct rte_ipsec_sess

RE: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO

[Gowrishankar Muthukrishnan]

> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

> +  breaking ABI. The new location is recommended to comply with

> +  virtio-crypto specification. Applications and drivers using

> +  this struct will be updated.

> +



The problem here, I see is that there is one private key but multiple 
combinations of padding.

Therefore, for every padding variation, we need to copy the same private key 
anew, duplicating it in memory.

The only reason for me to keep a session-like struct in asymmetric crypto was 
exactly this.



Each padding scheme in RSA has its own pros and cons (in terms of 
implementations as well).

When we share the same private key for Sign (and its public key in case of 
Encryption) between

multiple crypto ops (varying by padding schemes among cops), a vulnerable 
attack against one scheme

could potentially open door to used private key in the session and hence take 
advantage

on other crypto operations.



I think, this could be one reason for why VirtIO spec mandates padding info as 
session parameter.

Hence, more than duplicating in memory, private and public keys are secured and 
in catastrophe,

only that session could be destroyed.



Thanks,

Gowrishankar



Though padding schemes could be same



> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

> +  in either exponent or quintuple format is changed from union to

> +struct

> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> A.1.2).

> +  This change will not break existing applications.

This one I agree. RFC 8017 obsoletes RFC 3447.



Thanks,

Gowrishankar

> --

> 2.21.0

RE: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO

[Gowrishankar Muthukrishnan]

Hi ArkadiuszX,


> +

> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

> +  breaking ABI. The new location is recommended to comply with

> +  virtio-crypto specification. Applications and drivers using

> +  this struct will be updated.

> +



The problem here, I see is that there is one private key but multiple 
combinations of padding.

Therefore, for every padding variation, we need to copy the same private key 
anew, duplicating it in memory.

The only reason for me to keep a session-like struct in asymmetric crypto was 
exactly this.





Each padding scheme in RSA has its own pros and cons (in terms of 
implementations as well).

When we share the same private key for Sign (and its public key in case of 
Encryption) between

multiple crypto ops (varying by padding schemes among cops), a vulnerable 
attack against one scheme

could potentially open door to used private key in the session and hence take 
advantage

on other crypto operations.



I think, this could be one reason for why VirtIO spec mandates padding info as 
session parameter.

Hence, more than duplicating in memory, private and public keys are secured and 
in catastrophe,

only that session could be destroyed.



Please share your thoughts.



> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

> +  in either exponent or quintuple format is changed from union to

> +struct

> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> A.1.2).

> +  This change will not break existing applications.

This one I agree. RFC 8017 obsoletes RFC 3447.



Thanks,

Gowrishankar



> --

> 2.21.0

Question regarding the status of Hotplug on multi-processes

[Brandes, Shai]

Hi all, I hope this email finds you well.

We would like to understand the status of Hotplug on multi-processes:

- 18.11 RN https://doc.dpdk.org/guides-23.11/rel_notes/release_18_11.html 
states that it added support for device multi-process hotplug.
- DTS test plan https://doc.dpdk.org/dts/test_plans/hotplug_mp_test_plan.html 
states that Hotplug on multi-processes is not expected to function.
- When testing both our ENA device and Intel device, the multiprocess does not 
seem to function after hotplug (both fail with the same error in the secondary 
process that it is unable to reach the primary process).

Our understanding is that there is a gap with MP. If this is correct, is there 
any plan to close this gap?

Thanks for your time and consideration,
Shai

[RFC v1 0/3] VXLAN-GPE test suite

[Dean Marx]

This test suite and the supporting testpmd shell changes originate from
an old dts test plan called "vxlan_gpe_support_in_i40e", and the
necessary testpmd commands to run the suite are only fully supported on
the i40e NICs I have tested on (bnxt and mlx5 NICs don't support.)
However, VXLAN-GPE tunnelling is technically supported in the ethdev
API, so I decided to write it anyways.

The suite consists originally consists of two test cases, but I
compressed them into one where the udp_tunnel_port command is used to
add VXLAN-GPE port 4790 to the filter list on testpmd. To my
understanding, A UDP / VXLAN packet with dport 4790 is sent and captured
to verify the VXLAN layer is still in the received packet. 
Then, the port 4790 tunnel is removed from the session and the same
packet is sent, but when received should not have the VXLAN layer. I am
unsure based on the test plan description whether the VXLAN layer is
fully removed, or if the verbose output on testpmd just prints the VXLAN
layer in stdout in the first case and not the second, but I decided to
implement the former for now.


Dean Marx (3):
  dts: add UDP tunnel command to testpmd shell
  dts: VXLAN gpe support test suite
  dts: conf schema VXLAN gpe support

 dts/framework/config/conf_yaml_schema.json|  3 +-
 dts/framework/remote_session/testpmd_shell.py | 51 +++-
 dts/tests/TestSuite_vxlan_gpe_support.py  | 77 +++
 3 files changed, 129 insertions(+), 2 deletions(-)
 create mode 100644 dts/tests/TestSuite_vxlan_gpe_support.py

-- 
2.44.0

[RFC v1 1/3] dts: add UDP tunnel command to testpmd shell

[Dean Marx]

add udp_tunnel_port command to testpmd shell class,
also ports over set verbose method from vlan suite

Signed-off-by: Dean Marx 
---
 dts/framework/remote_session/testpmd_shell.py | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/dts/framework/remote_session/testpmd_shell.py 
b/dts/framework/remote_session/testpmd_shell.py
index eda6eb320f..26114091d6 100644
--- a/dts/framework/remote_session/testpmd_shell.py
+++ b/dts/framework/remote_session/testpmd_shell.py
@@ -804,7 +804,56 @@ def show_port_stats(self, port_id: int) -> 
TestPmdPortStats:
 
 return TestPmdPortStats.parse(output)
 
-def _close(self) -> None:
+def set_verbose(self, level: int, verify: bool = True):
+"""Set debug verbosity level.
+
+Args:
+level: 0 - silent except for error
+1 - fully verbose except for Tx packets
+2 - fully verbose except for Rx packets
+>2 - fully verbose
+verify: If :data:`True` the command output will be scanned to 
verify that verbose level
+is properly set. Defaults to :data:`True`.
+
+Raises:
+InteractiveCommandExecutionError: If `verify` is :data:`True` and 
verbose level
+is not correctly set.
+"""
+verbose_output = self.send_command(f"set verbose {level}")
+if verify:
+if "Change verbose level" not in verbose_output:
+self._logger.debug(f"Failed to set verbose level to {level}: 
\n{verbose_output}")
+raise InteractiveCommandExecutionError(
+f"Testpmd failed to set verbose level to {level}."
+)
+
+def udp_tunnel_port(
+self, port_id: int, add: bool, udp_port: int, protocol: str, verify: 
bool = True
+):
+"""Configures a UDP tunnel on the specified port, for the specified 
protocol.
+
+Args:
+port_id: ID of the port to configure tunnel on.
+add: If :data:`True`, adds tunnel, otherwise removes tunnel.
+udp_port: ID of the UDP port to configure tunnel on.
+protocol: Name of tunnelling protocol to use; options are vxlan, 
geneve, ecpri
+verify: If :data:`True`, checks the output of the command to 
verify that
+no errors were thrown.
+
+Raises:
+InteractiveCommandExecutionError: If verify is :data:`True` and 
command
+output shows an error.
+"""
+action = "add" if add else "rm"
+cmd_output = self.send_command(
+f"port config {port_id} udp_tunnel_port {action} {protocol} 
{udp_port}"
+)
+if verify:
+if "Operation not supported" in cmd_output or "Bad arguments" in 
cmd_output:
+self._logger.debug(f"Failed to set UDP tunnel: \n{cmd_output}")
+raise InteractiveCommandExecutionError(f"Failed to set UDP 
tunnel: \n{cmd_output}")
+
+def close(self) -> None:
 """Overrides :meth:`~.interactive_shell.close`."""
 self.stop()
 self.send_command("quit", "Bye...")
-- 
2.44.0

[RFC v1 2/3] dts: VXLAN gpe support test suite

[Dean Marx]

Test suite for verifying vxlan gpe support on NIC, as well as expected
behavior while sending vxlan packets through tunnel

Signed-off-by: Dean Marx 
---
 dts/tests/TestSuite_vxlan_gpe_support.py | 77 
 1 file changed, 77 insertions(+)
 create mode 100644 dts/tests/TestSuite_vxlan_gpe_support.py

diff --git a/dts/tests/TestSuite_vxlan_gpe_support.py 
b/dts/tests/TestSuite_vxlan_gpe_support.py
new file mode 100644
index 00..981f878a4c
--- /dev/null
+++ b/dts/tests/TestSuite_vxlan_gpe_support.py
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2024 University of New Hampshire
+
+"""VXLAN-GPE support test suite.
+
+This suite verifies virtual extensible local area network packets
+are only received in the same state when a UDP tunnel port for VXLAN tunneling
+protocols is enabled. GPE is the Generic Protocol Extension for VXLAN,
+which is used for configuring fields in the VXLAN header through GPE tunnels.
+
+If a GPE tunnel is configured for the corresponding UDP port within a sent 
packet,
+that packet should be received with its VXLAN layer. If there is no GPE tunnel,
+the packet should be received without its VXLAN layer.
+
+"""
+
+from scapy.layers.inet import IP, UDP  # type: ignore[import-untyped]
+from scapy.layers.l2 import Ether  # type: ignore[import-untyped]
+from scapy.layers.vxlan import VXLAN  # type: ignore[import-untyped]
+from scapy.packet import Raw  # type: ignore[import-untyped]
+
+from framework.params.testpmd import SimpleForwardingModes
+from framework.remote_session.testpmd_shell import TestPmdShell
+from framework.test_suite import TestSuite
+
+
+class TestVxlanGpeSupport(TestSuite):
+"""DPDK VXLAN-GPE test suite.
+
+This suite consists of one test case (Port 4790 is designated for 
VXLAN-GPE streams):
+1. VXLAN-GPE ipv4 packet detect - configures a GPE tunnel on port 4790
+and sends packets with a matching UDP destination port. This packet
+should be received by the traffic generator with its VXLAN layer.
+Then, remove the GPE tunnel, send the same packet, and verify that
+the packet is received without its VXLAN layer.
+"""
+
+def set_up_suite(self) -> None:
+"""Set up the test suite.
+
+Setup:
+Verify that we have at least 2 port links in the current test run.
+"""
+self.verify(
+len(self._port_links) > 1,
+"There must be at least two port links to run the scatter test 
suite",
+)
+
+def send_vxlan_packet_and_verify(self, udp_dport: int, 
should_receive_vxlan: bool) -> None:
+"""Generate a VXLAN GPE packet with the given UDP destination port, 
send and verify.
+
+Args:
+udp_dport: The destination UDP port to generate in the packet.
+should_receive_vxlan: Indicates whether the packet should be
+received by the traffic generator with its VXLAN layer.
+"""
+packet = Ether() / IP() / UDP(dport=udp_dport) / VXLAN(flags=12) / 
IP() / Raw(load="x")
+received = self.send_packet_and_capture(packet)
+print(f"Received packets = {received}")
+has_vxlan = any(
+"VXLAN" in packet.summary() and "x" in str(packet.load) for 
packet in received
+)
+self.verify(
+not (has_vxlan ^ should_receive_vxlan), "Expected packet did not 
match received packet."
+)
+
+def test_gpe_tunneling(self) -> None:
+"""Verifies expected behavior of VXLAN packets through a GPE tunnel."""
+GPE_port = 4790
+with TestPmdShell(node=self.sut_node) as testpmd:
+testpmd.set_forward_mode(SimpleForwardingModes.io)
+testpmd.set_verbose(level=1)
+testpmd.start()
+testpmd.udp_tunnel_port(port_id=0, add=True, udp_port=GPE_port, 
protocol="vxlan")
+self.send_vxlan_packet_and_verify(udp_dport=GPE_port, 
should_receive_vxlan=True)
+testpmd.udp_tunnel_port(port_id=0, add=False, udp_port=GPE_port, 
protocol="vxlan")
+self.send_vxlan_packet_and_verify(udp_dport=GPE_port, 
should_receive_vxlan=False)
-- 
2.44.0

[RFC v1 3/3] dts: conf schema VXLAN gpe support

[Dean Marx]

Configuration schema to run vxlan gpe support test suite

Signed-off-by: Dean Marx 
---
 dts/framework/config/conf_yaml_schema.json | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dts/framework/config/conf_yaml_schema.json 
b/dts/framework/config/conf_yaml_schema.json
index f02a310bb5..06c8978103 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -187,7 +187,8 @@
   "enum": [
 "hello_world",
 "os_udp",
-"pmd_buffer_scatter"
+"pmd_buffer_scatter",
+"vxlan_gpe_support"
   ]
 },
 "test_target": {
-- 
2.44.0

[PATCH] eventdev: do not use zero length arrays

[Stephen Hemminger]

Zero length array's are a GNU C extension and should be replaced
by use of flexible arrayrs. This has been fixed almost everywhere
in DPDK 24.07 but looks like some event code got missed.

Generated by devtools/cocci/zero_length_array.cocci

Signed-off-by: Stephen Hemminger 
---
 drivers/event/opdl/opdl_ring.c   | 2 +-
 drivers/event/sw/event_ring.h| 2 +-
 lib/eventdev/rte_event_dma_adapter.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/event/opdl/opdl_ring.c b/drivers/event/opdl/opdl_ring.c
index 6799ec996b..60991c4b03 100644
--- a/drivers/event/opdl/opdl_ring.c
+++ b/drivers/event/opdl/opdl_ring.c
@@ -119,7 +119,7 @@ struct opdl_ring {
/* Stages indexed by ID */
struct opdl_stage *stages;
/* Memory for storing slot data */
-   alignas(RTE_CACHE_LINE_SIZE) uint8_t slots[0];
+   alignas(RTE_CACHE_LINE_SIZE) uint8_t slots[];
 };
 
 
diff --git a/drivers/event/sw/event_ring.h b/drivers/event/sw/event_ring.h
index 29db267b77..35931888dd 100644
--- a/drivers/event/sw/event_ring.h
+++ b/drivers/event/sw/event_ring.h
@@ -27,7 +27,7 @@ struct rob_ring {
uint32_t size;
uint32_t write_idx;
uint32_t read_idx;
-   alignas(RTE_CACHE_LINE_SIZE) void *ring[0];
+   alignas(RTE_CACHE_LINE_SIZE) void *ring[];
 };
 
 static inline struct rob_ring *
diff --git a/lib/eventdev/rte_event_dma_adapter.h 
b/lib/eventdev/rte_event_dma_adapter.h
index 768390cd30..5c480b82ff 100644
--- a/lib/eventdev/rte_event_dma_adapter.h
+++ b/lib/eventdev/rte_event_dma_adapter.h
@@ -204,7 +204,7 @@ struct rte_event_dma_adapter_op {
/**< Number of source segments. */
uint16_t nb_dst;
/**< Number of destination segments. */
-   struct rte_dma_sge src_dst_seg[0];
+   struct rte_dma_sge src_dst_seg[];
/**< Source and destination segments. */
 };
 
-- 
2.43.0

[PATCH] baseband/fpga_5gnr_fec: remove useless cast

[Stephen Hemminger]

The rte_pktmbuf_mtod_offset macro already includes a type cast
so casting the result just adds extra cast.
Found by cocci/mtod-offset.cocci

Signed-off-by: Stephen Hemminger 
---
 drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c 
b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 9b253cde28..e2ed047836 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -2042,7 +2042,7 @@ fpga_5gnr_harq_write_loopback(struct fpga_5gnr_queue *q,
}
}
 
-   input = (uint64_t *)rte_pktmbuf_mtod_offset(harq_input, uint8_t *, 
in_offset);
+   input = rte_pktmbuf_mtod_offset(harq_input, uint64_t *, in_offset);
 
while (left_length > 0) {
if (fpga_5gnr_reg_read_8(q->d->mmio_base, 
FPGA_5GNR_FEC_DDR4_ADDR_RDY_REGS) ==  1) {
@@ -2125,7 +2125,7 @@ fpga_5gnr_harq_read_loopback(struct fpga_5gnr_queue *q,
}
left_length = harq_in_length;
 
-   input = (uint64_t *)rte_pktmbuf_mtod_offset(harq_output, uint8_t *, 
harq_out_offset);
+   input = rte_pktmbuf_mtod_offset(harq_output, uint64_t *, 
harq_out_offset);
 
while (left_length > 0) {
if (d->fpga_variant == AGX100_FPGA_VARIANT) {
-- 
2.43.0

Re: fib{,6}: questions and proposals

[Medvedkin, Vladimir]

Hi Robin,

Apologies for the delayed response

On 19/03/2024 20:38, Robin Jarry wrote:

Hi Vladimir,

Medvedkin, Vladimir, Mar 19, 2024 at 18:16:
> 2) Is it OK/safe to modify a fib from a control thread (read/write) 
>    while it is used by data path threads (read only)?


This part is a bit more complicated. In practice, I would say yes, 
however, there is a possibility that if the lookup thread is 
preempted in the middle of the lookup process, and at the same time 
the control thread deletes the corresponding route, then the lookup 
result may return outdated data. This problem is solved in LPM with 
RCU enabled. I have plans to implement it in the near future in the FIB.


OK that's good to know, thanks.

> 3) There is no public API to list/walk all configured routes in 
>    a fib. Would that be possible/easy to implement?


Yes, it already there. FIB under the hood uses rte_rib to hold 
existing routes. So walking through can be implemented like:


I had tried it and got confusing results out of this. This must have 
been before I had realized that all addresses needed to be in host 
order...


I tried again and it works as advertised with a small missing detail: 
after configuring a default route, e.g.:


   rte_fib_add(fib, RTE_IPV4(2, 2, 0, 0), 16, RTE_IPV4(1, 2, 3, 4));
   rte_fib_add(fib, RTE_IPV4(3, 3, 3, 0), 24, RTE_IPV4(4, 3, 2, 1));
   rte_fib_add(fib, RTE_IPV4(0, 0, 0, 0), 0, RTE_IPV4(9, 9, 9, 9));

It is not returned by rte_rib_get_nxt() successive calls. I only see 
the other two routes:


   2.2.0.0/16 via 1.2.3.4
   3.3.3.0/24 via 4.3.2.1

Is this expected?


Yes, it is expected. It is also reflected in API: "Retrieve next more 
specific prefix ...". So, in your case you should explicitly lookup 0/0 
route.


IfindthismoreconvenientfordataplanestructureslikeDIR24-8,whereIneedto 
findgaps forsomegivensuperprefix.




> 4) In rte_fib, every IPv4 address (route *and* next hop) needs to 
be >    in host order. This is not consistent with fib6 where 
addresses >    are stored in network order. It took me quite a while 
to figure >    out what was wrong with my code.

This API behavior was created in such a way that it is the same as LPM.

As for LPM, I think it was done this way for performance reasons 
because in some scenarios you only working with the host order ipv4 
addresses.


This should really be advertised in strong capital letters in the API 
docs. Or (preferably) hidden to the user. I don't see any valid 
scenario where you would work with host order IPv4 addresses.
I just implemented lookup the same way as LPM. As for valid scenario, 
years ago I used an LPM/FIB lookup on a huge text log file(it was nginx 
logs if I remember correctly) with hundreds of million lines with IP 
addresses to resolve corresponding AS numbers for some statistics. The 
macro I used converted substrings with IPv4 into unsigned integers in 
host byte order. So, it is not always true that IPv4 are in network byte 
order.


Do you think we could change that API or at least add a flag at 
FIB/RIB creation to make it transparent to the user and consistent 
between IPv4 and IPv6?


Yes, I will add FIB configuration option to allow BE IPv4 as an input 
for lookup function.




Thanks!


--
Regards,
Vladimir

Re: [PATCH dpdk v2] rel_notes: announce 24.11 ipv6 api breakage

[Medvedkin, Vladimir]

Acked-by: Vladimir Medvedkin 

On 23/07/2024 09:27, Robin Jarry wrote:

In 24.11, all IPv6 public APIs will be modified to use a structure
instead of fixed size arrays.

Signed-off-by: Robin Jarry 
Acked-by: Morten Brørup 
---

Notes:
 v2: updated with the exhaustive list of symbols

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

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 6948641ff69b..bb17b78d193a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -147,3 +147,45 @@ Deprecation Notices
will be deprecated and subsequently removed in DPDK 24.11 release.
Before this, the new port library API (functions rte_swx_port_*)
will gradually transition from experimental to stable status.
+
+* net: A new IPv6 address structure will be introduced in DPDK 24.11.
+  It will replace all ad-hoc ``uint8_t[16]`` arrays in all public APIs and 
structures.
+  The following libraries and symbols are expected to be affected:
+
+  ethdev
+- ``struct rte_flow_item_icmp6_nd_ns``
+- ``struct rte_flow_item_icmp6_nd_na``
+- ``struct rte_flow_action_set_ipv6``
+- ``struct rte_flow_tunnel``
+  fib
+- ``rte_fib6_add()``
+- ``rte_fib6_delete()``
+- ``rte_fib6_lookup_bulk()``
+  gro
+- ``struct tcp6_flow_key``
+  hash
+- ``struct rte_ipv6_tuple``
+  ipsec
+- ``struct rte_ipsec_sadv6_key``
+  lpm
+- ``rte_lpm6_add()``
+- ``rte_lpm6_is_rule_present()``
+- ``rte_lpm6_delete()``
+- ``rte_lpm6_delete_bulk_func()``
+- ``rte_lpm6_lookup()``
+- ``rte_lpm6_lookup_bulk_func()``
+  net
+- ``struct rte_ipv6_hdr``
+  node
+- ``rte_node_ip6_route_add()``
+  pipeline
+- ``struct rte_table_action_ipv6_header``
+  rib
+- ``rte_rib6_lookup()``
+- ``rte_rib6_lookup_exact()``
+- ``rte_rib6_get_nxt()``
+- ``rte_rib6_insert()``
+- ``rte_rib6_remove()``
+- ``rte_rib6_get_ip()``
+  table
+- ``struct rte_table_lpm_ipv6_key``


--
Regards,
Vladimir

Community CI Meeting Minutes - July 25, 2024

[Patrick Robb]

#
July 25, 2024
Attendees
1. Patrick Robb
2. Jeremy Spewock
3. Juraj Linkeš
4. Aaron Conole
5. Adam Hassick
6. Dean Marx
7. Luca Vizzarro
8. Manit Mahajan
9. Paul Szczepanek
10. Tomas Durovec

#
Minutes

=
General Announcements
* Retests v2:
   * When passing in a branch name, make sure it aligns with what
would be output by pw_maintainers_cli.py (i.e. “next-net” instead of
“next-net-for-main”)
* Depends-on:
   * Reminder: UNH folks are working on adding depends-on to the
patchwork project itself, with a v1 submission up so far.
   * Integer based series IDs vs series urls vs message IDs: will
either be patch urls or message ids to indicate the dependency.
  * Aaron: Message ids are better for folks who are working from
their email clients and don’t want to have to load up patchwork.
* DPDK Summit Presentations:
   * CFP deadline is Jul 31, 2024
   * Luca has made a submission for: How to run DTS testsuites, how to
write a testsuite from scratch. Going to do an overview of the APIs
available for test writers.
   * Patrick will do a submission for UNH Lab updates, including new
ci tools for the community, testing for projects which consume dpdk
(ovs, spdk), how (new) DTS will be used in the lab going forward.

=
CI Status

-
UNH-IOL Community Lab
* Retest Framework now supports the “rebase={branch}” parameter, which
will re-apply the series on a given branch before triggering retests
   * The needed updates to create_series_artifact.py have been
submitted from Adam, and applied on the dpdk-ci repo by Aaron.
   * Patrick Robbto work with other labs on making use of these updates
* The new AMD & Intel x86 servers are mounted, cabled etc. in the new
DPDK server rack. We’re moving over some of the NICs from the old
servers now, setting up the DTS configurations, etc.
   * Running from Ubuntu 24.04
* AMD has reached out for donation agreement for donating 3 additional
servers to the lab.

-
Intel Lab
* None

-
Github Actions
* Upcoming work: Cirrus CI

-
Loongarch Lab
* Patrick needs to reach out to Min Zhou and start up the process for
adding recheck support

=
DTS Improvements & Test Development
* next-dts branch has been approved by tech board, with Juraj as maintainer.
* Testpmd context manager is merged to main
* Alex had a bugfix for the git revision flag merged:
https://patchwork.dpdk.org/project/dpdk/patch/20240719153445.277851-1-alex.chap...@arm.com/
* Jeremy has rebased the improvements for interactive shell output
gathering, and this should be applied.
* Scatter capability:
   * Show rxq info: shows scatter on if MTU will not fit in a message
buf, shows off otherwise.
   * Show rx_offload capability: This shows the offload capability,
regardless of any runtime configuration
   * Mellanox appears to require that the –enable-scatter flag be
passed, others do not have this requirement

=
Any other business
* Patrick Robbneeds to add Tomas Durovec to the DTS call (he is only
invited to the CI call)

[PATCH] doc: fix dma perf typo

[Amit Prakash Shukla]

Fixing typo in command line arguments for dma perf application.

Fixes: 623dc9364dc6 ("app/dma-perf: introduce DMA performance test")
Cc: sta...@dpdk.org

Signed-off-by: Amit Prakash Shukla 
---
 doc/guides/tools/dmaperf.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/tools/dmaperf.rst b/doc/guides/tools/dmaperf.rst
index 6f85fceb8a..f68353b920 100644
--- a/doc/guides/tools/dmaperf.rst
+++ b/doc/guides/tools/dmaperf.rst
@@ -119,7 +119,7 @@ Typical command-line invocation to execute the application:
 
 .. code-block:: console
 
-   dpdk-test-dma-perf --config=./config_dma.ini --result=./res_dma.csv
+   dpdk-test-dma-perf --config ./config_dma.ini --result ./res_dma.csv
 
 Where ``config_dma.ini`` is the configuration file,
 and ``res_dma.csv`` will be the generated result file.
-- 
2.34.1

[DPDK/DTS Bug 1500] Create process for adding VFs

[bugzilla]

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

Bug ID: 1500
   Summary: Create process for adding VFs
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: DTS
  Assignee: dev@dpdk.org
  Reporter: jspew...@iol.unh.edu
CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu
  Target Milestone: ---

VFs are used in multiple of the ethdev test suites that we were planning to
port over into new DTS, but we don't have a method of creating them currently.
Judging by the process that is laid out in multiple test_plans (like
stats_check for example:
https://git.dpdk.org/tools/dts/tree/test_plans/stats_checks_test_plan.rst) it
seems like actually creating the VF and binding it to vfio-pci is pretty
simple. However, because the VFs are on top of the PF that exist on the NIC's
ports, it raises a few questions about where VFs should live in the framework
and how they should be managed, since they get their own PCI addresses.

It might be enough to just add VFs as a list of objects under a port and manage
them that way, but they almost look like ports themselves to testpmd and
devbind. Also, since we currently start testpmd by explicitly allowing the PCI
addresses for the ports in the current testrun, do we also include all VFs
configured on the ports? Do we always want testpmd to see them if they are
configured? There are a few things to discuss regarding how to implement them
properly.

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

Re: How does CI system get updated?

[Patrick Robb]

Hi Stephen,

This is a UNH Lab system.

We review our systems for updates once every 4 months. The idea is we
do it early in each DPDK release's development cycle. So, we update
Dockerfiles (for container environments), we apply updates where
needed to persistent systems (for VMs, or baremetal servers).
Obviously the Mingw version for the windows system was a check we have
not been doing. Thank you for spotting this and letting us know.

We will apply the update and let you know when it's ready.


On Thu, Jul 25, 2024 at 11:03 AM Stephen Hemminger
 wrote:
>
>
>
> This warning is due to a very old version of Mingw installed in CI system.
>
>  20 line log output for Windows Server 2019 (dpdk_mingw64_compile): 
> In file included from ..\lib\net/rte_ip.h:21,
> from ../lib/net/rte_dissect.c:20:
> C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: 
> expected 'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' 
> {aka 'const unsigned char *'}
> WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR 
> pStringBuf, size_t StringBufSize);
> ~~^
> ../lib/net/rte_dissect.c:292:29: error: passing argument 2 of 'inet_ntop' 
> discards 'const' qualifier from pointer target type 
> [-Werror=discarded-qualifiers]
> inet_ntop(AF_INET6, ip6_hdr->dst_addr, dbuf, sizeof(dbuf));
> ~~~^~
> In file included from ..\lib\net/rte_ip.h:21,
> from ../lib/net/rte_dissect.c:20:
> C:/mingw64/mingw64/x86_64-w64-mingw32/include/ws2tcpip.h:447:63: note: 
> expected 'PVOID' {aka 'void *'} but argument is of type 'const uint8_t *' 
> {aka 'const unsigned char *'}
> WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr, LPSTR 
> pStringBuf, size_t StringBufSize);
> ~~^
>
> It was fixed upstream in Mingw 4 years ago.

[PATCH] net/mlx5: fix NVGRE item validation for template API

[Jiawei Wang]

The template API NVGRE item can support full mask.
This patch updates default NVGRE item mask for the template API.

Fixes: 80c676259a04 ("net/mlx5: validate HWS template items")
Cc: sta...@dpdk.org

Signed-off-by: Jiawei Wang 
Acked-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 72fb3a55ba..14720f54ab 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -3867,6 +3867,15 @@ mlx5_flow_validate_item_nvgre(const struct rte_eth_dev 
*dev,
const struct rte_flow_item_nvgre *mask = item->mask;
int ret;
 
+   const struct rte_flow_item_nvgre hws_nic_mask = {
+   .c_k_s_rsvd0_ver = RTE_BE16(0xB000),
+   .protocol = RTE_BE16(UINT16_MAX),
+   .tni = {0xff, 0xff, 0xff},
+   .flow_id = 0xff
+   };
+   const struct rte_flow_item_nvgre *nic_mask = !mlx5_hws_active(dev) ?
+   &rte_flow_item_nvgre_mask : &hws_nic_mask;
+
if (target_protocol != 0xff && target_protocol != IPPROTO_GRE)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ITEM, item,
@@ -3884,10 +3893,10 @@ mlx5_flow_validate_item_nvgre(const struct rte_eth_dev 
*dev,
  item, "L3 Layer is missing");
}
if (!mask)
-   mask = &rte_flow_item_nvgre_mask;
+   mask = nic_mask;
ret = mlx5_flow_item_acceptable
(dev, item, (const uint8_t *)mask,
-(const uint8_t *)&rte_flow_item_nvgre_mask,
+(const uint8_t *)nic_mask,
 sizeof(struct rte_flow_item_nvgre),
 MLX5_ITEM_RANGE_NOT_ACCEPTED, error);
if (ret < 0)
-- 
2.18.1

[PATCH 1/1] examples/l2fwd-jobstats: add delay to show stats

[Rakesh Kudurumalla]

In main_loop function only one lock is acquired
before fwd jobs has started and finished and then lock is released.
Due to this most of the time lock is not available for
show_lcore_stats() as a result stats are not updated periodically.
This patch fixes the same by adding delay before accquring lock
in loop

Signed-off-by: Rakesh Kudurumalla 
---
 examples/l2fwd-jobstats/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
index 308b8edd20..7bb38b290f 100644
--- a/examples/l2fwd-jobstats/main.c
+++ b/examples/l2fwd-jobstats/main.c
@@ -542,7 +542,7 @@ l2fwd_main_loop(void)
} while (likely(stats_read_pending == 0));
 
rte_spinlock_unlock(&qconf->lock);
-   rte_pause();
+   rte_delay_us(10);
}
/* >8 End of minimize impact of stats reading. */
 }
-- 
2.25.1