RE: [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API

> -Original Message- > From: Bruce Richardson > Sent: Thursday, June 5, 2025 2:51 AM > To: Wathsala Wathawana Vithanage > Cc: Chenbo Xia ; Nipun Gupta ; > Anatoly Burakov ; Gaetan Rivet ; > dev@dpdk.org; nd ; Honnappa Nagarahalli > ; Dhruv Tripathi > Subj

RE: [PATCH v5 3/4] ethdev: introduce the cache stashing hints API

> On Mon, Jun 02, 2025 at 10:38:03PM +, Wathsala Vithanage wrote: > > Extend the ethdev library to enable the stashing of different data > > objects, such as the ones listed below, into CPU caches directly from > > the NIC. > > > > - Rx/Tx queue descriptors > > - Rx packets > > - Packet headers

RE: [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API

> -Original Message- > From: Bruce Richardson > Sent: Thursday, June 5, 2025 5:19 AM > To: Wathsala Wathawana Vithanage > Cc: Chenbo Xia ; Nipun Gupta ; > Anatoly Burakov ; Gaetan Rivet ; > dev@dpdk.org; nd ; Honnappa Nagarahalli > ; Dhruv Tripathi > Subj

RE: [PATCH v5 2/4] bus/pci: introduce the PCIe TLP Processing Hints API

> > rte_pci_tph_st_{get, set} functions will return an error if processing > > any of the rte_tph_info objects fails. The API does not indicate which > > entry in the rte_tph_info array was executed successfully and which > > caused an error. Therefore, in case of an error, the caller should > > di

RE: [PATCH v5 0/4] An API for Cache Stashing with TPH

> > Today, DPDK applications benefit from Direct Cache Access (DCA) > > features like Intel DDIO and Arm's write-allocate-to-SLC. However, > > those features do not allow fine-grained control of direct cache > > access, such as stashing packets into upper-level caches (L2 caches) > > of a processor

RE: [PATCH v1 3/4] ring: fix potential sync issue between head and tail values

> > > > No. > > In conventional ring we have just two stages: 'prod' and 'cons'. > > So moving prod.head depends on cons.tail and visa-versa: moving cons.head > > depends on prod.tail. > > With soring we have multiple (N) extra stages in between. >

RE: [PATCH v1 3/4] ring: fix potential sync issue between head and tail values

on prod.tail, > stage[1].head depends on stage[0].tail > ... > stage{N-1].head depends on stage[N-2].tail cons.head depends on > stage[N-1].tail > > > If they are > > not, then you will run into the issue you have seen (a.k.a > > "Other-multi-copy atomic"

RE: [PATCH v5 1/4] pci: add non-merged Linux uAPI changes

> Hi Maxim, > > Here is the link to the kernel VFIO patch you have asked earlier (v4). > https://lore.kernel.org/kvm/20250221224638.1836909-1- > wathsala.vithan...@arm.com/T/#me73cf9b9c87da97d7d9461dfb97863b78ca17 > 55b > Sorry, here is the correct link to V2 of the VFIO patch https://lore.ker

RE: [PATCH v5 1/4] pci: add non-merged Linux uAPI changes

> Sent: Monday, June 2, 2025 5:38 PM > To: Chenbo Xia ; Nipun Gupta ; > Maxime Coquelin > Cc: dev@dpdk.org; nd ; Wathsala Wathawana Vithanage > ; Dhruv Tripathi > Subject: [PATCH v5 1/4] pci: add non-merged Linux uAPI changes > > This commit is a hack to prevent build failures

RE: [PATCH v1 3/4] ring: fix potential sync issue between head and tail values

ot, then you will run into the issue you have seen (a.k.a "Other-multi-copy atomic" which is legit in Arm v8 and above). Thanks. --wathsala > > -Original Message- > > From: Konstantin Ananyev > > Sent: Monday, May 26, 2025 6:54 AM > > To: Wathsala Wathaw

RE: [PATCH v1 3/4] ring: fix potential sync issue between head and tail values

PE, to the extent that the PE is required to observe the access coherently." > -Original Message- > From: Konstantin Ananyev > Sent: Monday, May 26, 2025 6:54 AM > To: Wathsala Wathawana Vithanage ; > dev@dpdk.org > Cc: Honnappa Nagarahalli ; > jer...@marvell.com; he

RE: [PATCH v1 3/4] ring: fix potential sync issue between head and tail values

Hi Konstanin, In rte_ring the store-release on tail update guarantees that CAS won't get reordered with the store-released of the tail update. So, the sequence of events would look like this (combined view of head and tail update) Releaxed-load(new_head, N)

RE: [RFC PATCH v4 2/3] bus/pci: introduce the PCIe TLP Processing Hints API

> Hints API > > On Sat, May 17, 2025 at 5:18 PM Wathsala Vithanage > wrote: > > diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c > > index c20d159218..463c06ad64 100644 > > --- a/drivers/bus/pci/linux/pci.c > > +++ b/drivers/bus/pci/linux/pci.c > > @@ -814,3 +814,97 @@ rte_p

RE: [RFC PATCH v4 1/3] pci: add non-merged Linux uAPI changes

Linux uAPI changes > > Hi Wathsala, > > On Sat, May 17, 2025 at 5:18 PM Wathsala Vithanage > wrote: > > > > This commit is a hack to prevent build failures the next commit in > > this patch series causes due to missing vfio uapi definitions. > > This commit should NEVER BE MERGED. > > Next commi

RE: meson error on ARM Grace server 23.11/22.11

> Hi, > > At the DPDK Community Lab we have been running CI tests with a new ARM > Grace server for the past couple of months on main and next-* branches. I am > trying to add LTS runs now, and ran into a snag with 23.11 and 22.11 for this > system. Stable maintainers I'm not sure whether this sho

RE: [RFC PATCH] drivers: add generic build of SVE files

> -Original Message- > From: David Marchand > Sent: Monday, April 7, 2025 10:50 AM > To: Bruce Richardson > Cc: dev@dpdk.org; Jie Hai > Subject: Re: [RFC PATCH] drivers: add generic build of SVE files > > On Mon, Apr 7, 2025 at 5:29 PM Bruce Richardson > wrote: > > > > For SVE, as fo

RE: [PATCH] config/arm: fix march features not being set

Hi Pavan, I think this patch does the right thing. I have a minor comment on the cc.has_argument you have added. > --- > config/arm/meson.build | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/config/arm/meson.build b/config/arm/meson.build index > dea329ceb7

RE: [PATCH] config/arm: fix march features not being set

Hi Jerin, We are looking into this internally. Thanks. > -Original Message- > From: Jerin Jacob > Sent: Monday, March 10, 2025 9:23 AM > To: Pavan Nikhilesh Bhagavatula ; Wathsala > Wathawana Vithanage ; Bruce Richardson > > Cc: dev@dpdk.org; Pavan Nikhiles

RE: [DPDK/meson Bug 1670] DPDK fails to compile using gcc version 8.5.0

> Subject: [DPDK/meson Bug 1670] DPDK fails to compile using gcc version 8.5.0 > > Bug ID 1670 > SummaryDPDK fails to compile using gcc version 8.5.0 > ProductDPDK > Version25.03 > Hardware ARM > OS Linux > Stat

RE: [PATCH] config/arm: update NVIDIA BlueField-3 configuration

> Subject: [PATCH] config/arm: update NVIDIA BlueField-3 configuration > > ARM configuration requires explicit `mcpu` specifications in the implementor > description. > > The patch adds `mcpu` and `flags` description for the NVIDIA > BlueField-3 configuration. > > Signed-off-by: Gregory Etelson

RE: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit ARM

What version of CLANG are you using? > -Original Message- > From: Roger Melton (rmelton) > Sent: Wednesday, December 4, 2024 11:24 AM > To: Ruifeng Wang ; dev@dpdk.org > Cc: Wathsala Wathawana Vithanage ; nd > > Subject: Re: lib/eal/arm/include/rte_vect.h fails to

RE: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit ARM

> > clang14 does appear to support the vcopyq_laneq_u32() intrinsic, s0 we want > to skip the conditional implementation. > > Two approaches I have tested to resolve the error are: > > 1) skip if building with clang: > > > #if !defined(__clang__) && ((defined(RTE_ARCH_ARM) && > defined(R

RE: [PATCH v2 1/2] config/arm: strict use of -mcpu for supported CPUs

> > Hi Thomas, > > > > CI is failing because gcc version 11 does not enable crypto extension > > for thunderx2, with -mcpu=thunderx2t99 unless +crypto feature modifier is > used. > > Goal of this patch is to drop use of such feature modifiers when an > > -mcpu is available for a given platform. > >

RE: [PATCH v2 1/2] config/arm: strict use of -mcpu for supported CPUs

> Subject: Re: [PATCH v2 1/2] config/arm: strict use of -mcpu for supported > CPUs > > Please check the CI results, there are some failures. > Hi Thomas, CI is failing because gcc version 11 does not enable crypto extension for thunderx2, with -mcpu=thunderx2t99 unless +crypto feature modifie

RE: [PATCH v3] crypto/ipsec_mb: bump minimum IPsec MB version

> Subject: [PATCH v3] crypto/ipsec_mb: bump minimum IPsec MB version > > AESNI_MB SW PMDs increment Intel IPsec MB version to 1.4. > A minimum IPsec Multi-buffer version of 1.4 or greater is now required for the > 24.11 LTS release. > > Signed-off-by: Brian Dooley > Acked-by: Kai Ji > Acked-b

RE: [RFC v3 2/2] ethdev: introduce the cache stashing hints API

> -Original Message- > From: Jerin Jacob > Sent: Thursday, October 24, 2024 12:49 AM > To: Wathsala Wathawana Vithanage > Cc: tho...@monjalon.net; Ferruh Yigit ; Andrew > Rybchenko ; dev@dpdk.org; nd > ; Honnappa Nagarahalli ; > Dhruv Tripathi > Subje

RE: [RFC v3 2/2] ethdev: introduce the cache stashing hints API

> -Original Message- > From: Morten Brørup > Sent: Thursday, October 24, 2024 2:00 AM > To: Jerin Jacob ; Wathsala Wathawana Vithanage > > Cc: tho...@monjalon.net; Ferruh Yigit ; Andrew > Rybchenko ; dev@dpdk.org; nd > ; Honnappa Nagarahalli ; > Dhruv Tripath

RE: [RFC v2] ethdev: an API for cache stashing hints

> If we had a hwtopo API in DPDK, we could just use a node id in such a graph > (of CPUs and caches) to describe were the data ideally would land. > In such a case, you could have a node id for DDR as well, and thus you could > drop the notion of "stashing". Just a "drop off the data here, please,

RE: [RFC v3 0/2] An API for Stashing Packets into CPU caches

Hi Stephen, > There is a fundamental conflict with the increasing growth of "nerd knobs" > like this in the DPDK. Users already have problems understanding DPDK and > adding more complexity does not help. > > So any new feature like this should be: > 1. Just work right without any configuration

RE: [RFC v3 0/2] An API for Stashing Packets into CPU caches

> -Original Message- > From: Chenbo Xia > Sent: Monday, October 21, 2024 2:35 AM > To: Wathsala Wathawana Vithanage > Cc: dev@dpdk.org; nd > Subject: Re: [RFC v3 0/2] An API for Stashing Packets into CPU caches > > Hi, > > > On Oct 21, 2024, at 0

RE: DPDK - PCIe Steering Tags Meeting on 10/23/24

Here is the updated RFC https://inbox.dpdk.org/dev/20241021015246.304431-1-wathsala.vithan...@arm.com/#t Thanks --wathsal > > Subject: DPDK - PCIe Steering Tags Meeting on 10/23/24 > > Hi all, > > This is an invitation to discuss adding PCIe steering tags support to DPDK. > We have had brief

Community Call for Adding Support of PCIe Steering Tags Support in DPDK

A DPDK community call on adding support for PCIe steering tags is scheduled for 10/23/24 at 9AM CST. Steering tags allow for the stashing of descriptors and packet data closer to the CPUs, possibly allowing for lower latency and higher throughput. This feature requires contributions from CPU vend

DPDK - PCIe Steering Tags Meeting on 10/23/24

Hi all, This is an invitation to discuss adding PCIe steering tags support to DPDK. We have had brief conversations over the idea at the DPDK summit. Steering tags allows stashing of descriptors and packet data closer to the CPUs, possibly allowing for lower latency and higher throughput. This

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> -Original Message- > From: Konstantin Ananyev > Sent: Friday, October 11, 2024 9:09 AM > To: Wathsala Wathawana Vithanage ; > dev@dpdk.org > Cc: Honnappa Nagarahalli ; > jer...@marvell.com; d...@linux.ibm.com > Subject: RE: rte_ring move head question for

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> -Original Message- > From: Konstantin Ananyev > Sent: Thursday, October 10, 2024 11:54 AM > To: Wathsala Wathawana Vithanage ; > dev@dpdk.org > Cc: Honnappa Nagarahalli ; > jer...@marvell.com; d...@linux.ibm.com; nd ; nd > > Subject: RE: rte_ring move head

RE: [PATCH v3 1/2] power: enable CPPC support in power library

> > fix the name of the CPPC driver name. > > > > Signed-off-by: Wathsala Vithanage > > Reviewed-by: Dhruv Tripathi > > Series applied with a little more details about being a real fix. > > Thanks you Thomas.

RE: [PATCH v9 00/17] Use malloc function attribute to uncover bugs

> Subject: [PATCH v9 00/17] Use malloc function attribute to uncover bugs > > Recent versions of GCC have some additional function attributes that can help > with DPDK performance and stability. > > The alloc_align attribute tells the compiler what the alignment of the > allocation > will be, an

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> > > > > > 1. rte_ring_generic_pvt.h: > > > > = > > > > > > > > pseudo-c-code //related > > > > armv8 instructions > > > > > > > > ---

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> > > 1. rte_ring_generic_pvt.h: > > > = > > > > > > pseudo-c-code //related > > > armv8 instructions > > > > > > -- > > > hea

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> > > > 1. rte_ring_generic_pvt.h: > > > = > > > > > > pseudo-c-code //related > > > armv8 instructions > > > > > > -- > > >

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> > lda can be replaced with ldapr (LDA with release consistency - processor > consistency) which is more performant as lda is allowed to rise above stlr. > Can > be done with -mcpu=+rcpc > Correction: lapr is allowed to rise above stlr. -- wathsala

RE: rte_ring move head question for machines with relaxed MO (arm/ppc)

> 1. rte_ring_generic_pvt.h: > = > > pseudo-c-code //related armv8 > instructions > > -- > head.load()

RE: [PATCH] eal/x86: cache queried CPU flags

> > Hi Bruce, > > Why x86/rte_cpuflags.c is not using rte_getauxval() ? > > I don't see any such DPDK function, unless I'm missing something? I do see a > linux function which includes hw capability flags. I suspect the reasons we > don't use that are: > > 1. Lack of awareness of it (at least on

RE: [PATCH] eal/x86: cache queried CPU flags

> Rather than re-querying the HW each time a CPU flag is requested, we can just > save the return value in the flags array. This should speed up repeated > querying of CPU flags, and provides a workaround for a reported issue where > errors are seen with constant querying of the AVX-512 CPU flag fr

RE: [PATCH] eal/x86: cache queried CPU flags

> On Mon, Oct 7, 2024 at 1:07 PM Bruce Richardson > wrote: > > > > Rather than re-querying the HW each time a CPU flag is requested, we > > can just save the return value in the flags array. This should speed > > up repeated querying of CPU flags, and provides a workaround for a > > reported issue

RE: [RFC v2] ethdev: an API for cache stashing hints

> > >> > > >> And I can see set() has two different APIs, > > >> 'rte_eth_dev_stashing_hints_rx' & 'rte_eth_dev_stashing_hints_tx', > > >> is there a reason to have two separate APIs instead of having one > > >> which gets RX & TX as argument, as done in internal device ops? > > > > > > Some types/

RE: [PATCH v6 17/17] eal: add function attributes for allocation functions

> -Original Message- > Subject: [PATCH v6 17/17] eal: add function attributes for allocation > functions > > The allocation functions take a alignment argument that can be useful to hint > the compiler optimizer. This is supported by GCC and Clang but only useful > with > GCC because

RE: [RFC 1/2] eal: add llc aware functions

> > > > For instance, in Neoverse N1 can disable the use of SLC as LLC (a BIOS > > setting) If SLC is not used as LLC, then your script would report the > > unified L2 > as an LLC. > > Does `disabling SLC as LLC` disable L3? I think not, and what you are > implying is > the ` ls -d /sys/bus/cpu

RE: [RFC 1/2] eal: add llc aware functions

>Some SOCs may only show upper-level caches here, therefore cannot > be use blindly without knowing the SOC. > > Can you please help us understand > For instance, in Neoverse N1 can disable the use of SLC as LLC (a BIOS setting) If SLC is not used as LLC, then your script would report th

RE: [RFC 1/2] eal: add llc aware functions

> -unsigned int rte_get_next_lcore(unsigned int i, int skip_main, int wrap) > +#define LCORE_GET_LLC \ > + "ls -d /sys/bus/cpu/devices/cpu%u/cache/index[0-9] | sort -r > | grep -m1 index[0-9] | awk -F '[x]' '{print $2}' " > This won't work for some SOCs. How to ensure the index yo

RE: [PATCH] net/ena: revert redefining memcpy

> Subject: [PATCH] net/ena: revert redefining memcpy > > Redefining memcpy as rte_memcpy has no performance gain on current > compilers, and introduced bugs like this one where > rte_memcpy() will be detected as referencing past the destination. > > Bugzilla ID: 1510 > Fixes: 142778b3702a ("net

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> > Without a rationale why rte_csrand() functionality is something that should be > in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(), > it doesn't really matter how the patch set looks like. > > I've repeatedly asked for this information, and you've repeatedly ignored i

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> ...to have a non-zero chance of getting accepted. > I see too much uncertainty in that statement with "non-zero chance". As the maintainer of this library and someone with the community's best interest in mind, can you outline the requirements for a rte_csrand implementation with a higher deg

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> > > The answer is to have API's like (rte_csrand) which then call the OS > > > level primitives. The trust is then passed to the OS. I trust Linus, > > > Theo de Raadt, and the rest of the open OS community to evaluate and > > > integrate the best secure random number generator. > > > > Perhaps,

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> > The Linux kernel in arch/arm64/include/asm/archrandom.h has support > already. The support includes lots of checks for capabilities and caveats for > the > limitations of the ARM implementation that are not reflected in this > simplistic > version. No, such checks are unnecessary, because (

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> If your patch are to have non-zero chance of being accepted, it should include > a base implementation based on getrandom() (and the Windows equivalent), > with the proper optimizations (e.g., batching entropy requests to the kernel > on a per-lcore basis). > > You would also need to provide a r

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> -Original Message- > From: Stephen Hemminger > Sent: Saturday, July 27, 2024 10:54 AM > To: Wathsala Wathawana Vithanage > Cc: Mattias Rönnblom ; Shunzhi Wen > ; tho...@monjalon.net; Mattias Rönnblom > ; Ruifeng Wang > ; Bruce Richardson ; > Tyler Re

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

Hi Mattias, > > The primary goal of this patch is to provide a direct interface to HW, > > instead of letting kernel handle it. This is not an API just for Arm > > CPUs, as other vendors also have similar HW features. For instance, > > Intel and AMD has support for x86 RDRAND and RDSEED instructio

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

> > If you decide to rte_csrand() it should fallback to get_random or get_entropy. > > Note: many people don't fully trust RDRAND or ARM CPU instructions. > That is why the Linux entropy calls do not use only the HW instructions. Thanks Stephen. I understand the concern, would it be acceptable f

RE: [RFC v2] ethdev: an API for cache stashing hints

> rte_eth_X_get_capability() > rte_eth_dev_stashing_hints_discover is somewhat similar. > Instead of adding RTE_ETH_DEV_CAPA_ macro and contaminating > 'rte_eth_dev_info' with this edge use case, what do you think follow above > design and have dedicated get capability API? I think it's better

RE: [RFC v2] ethdev: an API for cache stashing hints

> > My initial reaction is negative on this. The DPDK does not need more nerd > knobs for performance. If it is a performance win, it should be automatic and > handled by the driver. > > If you absolutely have to have another flag, then it should be in existing > config > (yes, extend the ABI) r

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> > > > We are using this flag to allow application to choose between WFE > > > > and > > non- > WFE code path. > The non-WFE path performs slightly better. > > > Is it correct if I assume that this flag is not used to indicate the > > availability > > > > > > > > We are using this flag to allow a

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> > We are using this flag to allow application to choose between WFE and non- > WFE code path. > The non-WFE path performs slightly better. > Is it correct if I assume that this flag is not used to indicate the availability of WFE instruction in any of your platforms? If so, then its usage is

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> 03/07/2024 15:27, Wathsala Wathawana Vithanage: > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED #ifdef block. > > > > This patch fixes this issue by moving __RTE_ARM_WFE out of > > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED block. > > > > > > > >

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> > > > +uint8_t wfet_en; > > > > > > It should be made static probably. > > > This variable will be unused in some cases, needs #ifdef. > > > > > > > This variable is used in all cases. It's 1 when WFET is available, 0 when > > it's not. > > It would be 0 if you make it static yes. No need to m

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED #ifdef block. > > This patch fixes this issue by moving __RTE_ARM_WFE out of > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED block. > > > > Perhaps we should change RTE_ARM_USE_WFE to something like > > RTE_ARM_USE_WFE_IN_WAIT_UNTIL_EQUAL ? > > Yes perhaps. RTE_ARM_USE_WF

RE: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

> 19/06/2024 08:45, Wathsala Vithanage: > > --- a/lib/eal/arm/include/rte_cpuflags_64.h > > +++ b/lib/eal/arm/include/rte_cpuflags_64.h > > @@ -36,6 +36,7 @@ enum rte_cpu_flag_t { > > RTE_CPUFLAG_SVEF64MM, > > RTE_CPUFLAG_SVEBF16, > > RTE_CPUFLAG_AARCH64, > > + RTE_CPUFLAG_WFXT, > >

RE: [PATCH v3 0/2] deque: add multithread unsafe deque library

Hi Thomas, Aditya the original author of this patch is no longer at Arm. One of my colleagues will take over this patch, hence we will need some time to address these comments. Thank you > There were many comments on previous versions, and no ack on the v3, so I'm > not sure all comments are ad

RE: [PATCH v1] crypto/ipsec_mb: use new ipad/opad calculation API

Acked-by: Wathsala Vithanage > Subject: [PATCH v1] crypto/ipsec_mb: use new ipad/opad calculation API > > From: Pablo de Lara > > IPSec Multi-buffer library v1.4 added a new API to calculate inner/outer > padding for HMAC-SHAx/MD5. > > Signed-off-by: Pablo de Lara > Signed-off-by: Brian Dool

RE: [PATCH v5 2/9] ethdev: add common counters for statistics

> + packets = rte_counter64_fetch(&counters->packets); > + bytes = rte_counter64_fetch(&counters->bytes); > + errors = rte_counter64_fetch(&counters->errors); > + > + rte_compiler_barrier(); > + > + stats->ipackets += packets; > +

RE: [PATCH v5 1/9] eal: generic 64 bit counter

Hi Stephen, > +__rte_experimental > +static inline uint64_t > +rte_counter64_fetch(const rte_counter64_t *counter) { > + return *counter; > +} What if the address pointed by counter is not aligned and the architecture doesn't support atomic (untorn) loads on non-aligned loads? --wathsala

RE: [PATCH v2] eal/arm: replace RTE_BUILD_BUG on non-constant

> ../lib/eal/arm/include/rte_pause_64.h: In function ‘rte_wait_until_equal_16’: > ../lib/eal/include/rte_common.h:530:56: error: expression in static assertion > is not constant > 530 | #define RTE_BUILD_BUG_ON(condition) do { > static_assert(!(condition), #condition); } while (0) > |

RE: [PATCH] eal/arm: replace RTE_BUILD_BUG on non-constant

> Subject: [PATCH] eal/arm: replace RTE_BUILD_BUG on non-constant > > The ARM implementation of rte_pause uses RTE_BUILD_BUG_ON to check > memorder, which is not constant. This causes compile errors when it is > enabled with RTE_ARM_USE_WFE. eg. Use of wfe based rte_wait_until_equal_ implementati

RE: [PATCH] config/arm: add Ampere AmpereOneX platform

> > > > Signed-off-by: Yutang Jiang > > Signed-off-by: Yutang Jiang > > --- Looks like this patch is signed off by Yutang twice with two different emails. Please remove one and submit again. Thank you.

RE: [PATCH] ARM64: Cross-Compilation Support

> From: Krishna Kanth Reddy > > Modified the Configuration file to use the latest ARM Cross-Compiler. > > Fixed the linker errors for the undefined references to the APIs > isal_deflate_init, isal_deflate, isal_inflate_init, isal_inflate, > isal_inflate_stateless, isal_deflate_stateless, isal_de

RE: [PATCH] config/arm: add Ampere AmpereOneX platform

> -Original Message- > From: Yutang Jiang > Sent: Sunday, April 7, 2024 1:36 AM > To: dev@dpdk.org > Cc: patc...@amperecomputing.com; yutang.ji...@amperecomputing.com; > jiangyut...@os.amperecomputing.com; Ruifeng Wang > ; nd ; juraj.lin...@pantheon.tech > Subject: [PATCH] config/arm: a

RE: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

> > > > If the correct version is being installed and picked up, maybe there > > is something missing for that function definition in arm-ipsec-mb repo. > > Wathsala, can you check that please? > > We are working on reproducing this issue. Will update asap. A stub has been added in the Arm ipsec-

RE: [EXTERNAL] [PATCH v5 1/4] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

> > If the correct version is being installed and picked up, maybe there is > something missing for that function definition in arm-ipsec-mb repo. > Wathsala, can you check that please? We are working on reproducing this issue. Will update asap.

RE: [PATCH v4 2/2] config/arm: use common cpu arch for cross files

> > > > OK > > What will become this second patch? > > > I will suppress patch 2/2. > Thanks. I'm not allowed to suppress it, perhaps someone with admin privileges could do it.

RE: [PATCH v4 2/2] config/arm: use common cpu arch for cross files

> > Joyce is no longer with Arm, and we have not been able to figure out > > this patch. I think the first patch of this series makes sense. > > This second patch to us looks like a nice to have, rather than > > something that fixes an issue. Therefore, we would like to pull this > > patch out of t

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

> Hi Wathsala, > Any update on the updated tag and this patch? Hi Akhil, Tag SECLIB-IPSEC-2024.03.05 has been created.

RE: [EXT] Re: [PATCH v2 8/8] crypto/ipsec_mb: set and use session ID

> A new tag SECLIB-IPSEC-2023.10.13 has been created from the tip of arm > ipsec-mb git repo. > Please use this tag going forward, it has been tested and works as expected. Please use SECLIB-IPSEC-2024.03.05 that fixes issues caused by above tag. We will be updating the documentation soon.

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

> This is being worked on. We are in the process of creating a new tag. We will > update soon. > A new tag SECLIB-IPSEC-2024.03.05 has been created. We will be sending out a patch for the documentation soon.

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

> Subject: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface > > Currently IPsec MB provides both the JOB API and direct API. > AESNI_MB PMD is using the JOB API codepath while ZUC, KASUMI, SNOW3G > and CHACHA20_POLY1305 are using the direct API. > Instead of using the direct API for these PM

RE: [PATCH v2] crypto/ipsec_mb: use new ipad/opad calculation API

> Signed-off-by: Pablo de Lara > Signed-off-by: Brian Dooley > Acked-by: Ciara Power Acked-by: Wathsala Vithanage > > Depends-on: series-30989 ("crypto/ipsec_mb: bump minimum IPsec Multi- > buffer version") > > v2: > - Remove ipsec mb version checks > --- > drivers/crypto/ipsec_mb/pmd_aesn

RE: [PATCH v4 1/2] crypto/ipsec_mb: bump minimum IPsec Multi-buffer version

> Subject: [PATCH v4 1/2] crypto/ipsec_mb: bump minimum IPsec Multi-buffer > version > > SW PMDs increment IPsec Multi-buffer version to 1.4. > A minimum IPsec Multi-buffer version of 1.4 or greater is now required. > > Signed-off-by: Sivaramakrishnan Venkat > > Acked-by: Ciara Power > Acked-by

RE: [PATCH v4 2/2] doc: remove outdated version details

> Subject: [PATCH v4 2/2] doc: remove outdated version details > > SW PMDs documentation is updated to remove details of unsupported IPsec > Multi-buffer versions.DPDK older than 20.11 is end of life. So, older DPDK > versions are removed from the Crypto library version table. > > Signed-off-by:

RE: [EXT] Re: [PATCH v2 8/8] crypto/ipsec_mb: set and use session ID

Hi Patrick, > I tried mainline earlier today it compiles and links fine. However, build > failed on > v1.4. We are working on tagging the mainline, until then please continue > working on mainline. > A new tag SECLIB-IPSEC-2023.10.13 has been created from the tip of arm ipsec-mb git repo. Pleas

RE: [PATCH v4 2/2] config/arm: use common cpu arch for cross files

Hi Thomas, > > [host_machine] > > system = 'linux' > > cpu_family = 'aarch64' > > -cpu = 'armv8-a' > > +cpu = 'aarch64' > > Why aarch64 here and below? Joyce is no longer with Arm, and we have not been able to figure out this patch. I think the first patch of this series makes sense. This sec

RE: [PATCH 8/8] crypto/ipsec_mb: set and use session ID

> From: Pablo de Lara > > When creating a session, get the session ID that defines the fixed session > parameters and store it in the private data. > When retrieving IMB_JOB's, if their internal session ID matches the one in the > private session data, these fixed session parameters do not need t

RE: [EXT] Re: [PATCH v2 8/8] crypto/ipsec_mb: set and use session ID

I tried mainline earlier today it compiles and links fine. However, build failed on v1.4. We are working on tagging the mainline, until then please continue working on mainline. > -Original Message- > From: Patrick Robb > Sent: Tuesday, February 20, 2024 11:01 PM > To: Fangming Fang > C

RE: [PATCH 2/3] net/ionic: remove duplicate barriers

> -Original Message- > From: Wathsala Wathawana Vithanage > Sent: Monday, February 19, 2024 4:17 PM > To: Andrew Boyer ; dev@dpdk.org > Cc: Neel Patel ; nd ; Honnappa > Nagarahalli ; nd > Subject: RE: [PATCH 2/3] net/ionic: remove duplicate barriers > > H

RE: [PATCH 2/3] net/ionic: remove duplicate barriers

Hi Andrew, I think that this barrier may have been added to ensure any writes to q->hw_index and q->head_idx complete before ionic_q_flush computes val. Dependency chains can also prevent reordering if that's the case this barrier is not required. However, I have the following concern. > diff --

Do all major distros build DPDK with -Dplatform set to generic?

Hi all, Is it safe to assume that there is no major Arm Linux distro out there that builds DPDK targeting specific SOCs? In other words, is it safe to assume that Linux distros always build DPDK for Arm using -Dplatform=generic? Thank you. --wathsala

RE: [PATCH v3 3/3] config/arm: allow WFE to be enabled config time

> From: Pavan Nikhilesh > > Allow RTE_ARM_USE_WFE to be enabled at meson configuration time by > passing it via c_args instead of modifying `config/arm/meson.build`. > > Example usage: > meson build -Dc_args='-DRTE_ARM_USE_WFE' \ > --cross-file config/arm/arm64_cn10k_linux_gcc > > Signed

RE: [PATCH v3 2/3] config/arm: add support for fallback march

> > From: Pavan Nikhilesh > > Some ARM CPUs have specific march requirements and are not compatible > with the supported march list. > Add fallback march in case the mcpu and the march advertised in the > part_number_config are not supported by the compiler. > > Example > mcpu = neov

RE: [PATCH v3 1/3] config/arm: avoid mcpu and march conflicts

> > wrote: > > > > > > Hi Pavan, > > > > > >> The compiler options march and mtune are a subset of mcpu and will > > >> lead > > to > > >> conflicts if improper march is chosen for a given mcpu. > > >> To avoid conflicts, force part number march when mcpu is available > > >> and is supported by th

RE: [PATCH v3 1/3] config/arm: avoid mcpu and march conflicts

Hi Pavan, > The compiler options march and mtune are a subset of mcpu and will lead to > conflicts if improper march is chosen for a given mcpu. > To avoid conflicts, force part number march when mcpu is available and is > supported by the compiler. Why would one force the march specified in the

RE: [RFC] ring: further performance improvements with C11

> -Original Message- > From: Konstantin Ananyev > Sent: Wednesday, August 2, 2023 4:43 AM > To: Wathsala Wathawana Vithanage ; > Honnappa Nagarahalli ; > konstantin.v.anan...@yandex.ru; tho...@monjalon.net; Ruifeng Wang > > Cc: dev@dpdk.org; nd ; Justin He &

RE: [RFC] ring: improve ring performance with C11 atomics

, 2023 3:17 PM > To: Honnappa Nagarahalli ; > konstantin.v.anan...@yandex.ru; Feifei Wang > Cc: dev@dpdk.org; nd ; Wathsala Wathawana Vithanage > > Subject: [RFC] ring: improve ring performance with C11 atomics > > Tail load in __rte_ring_move_cons_head and __rte

  1   2   >