Re: [PATCH v3] lib/hash: add defer queue reclaim API

Apologies for the late reply. Looks good, few nits inline. Can you please some simple unit tests? > On Apr 4, 2024, at 5:11 AM, Abdullah Ömer Yamaç wrote: > > Hello, > Could you check the last commit? > Thanks > > On Thu, Mar 14, 2024 at 10:04 AM Abdullah Ömer Yamaç > wrote: > Hello, > Is t

RE: [PATCH v7 6/6] baseband/fpga_5gnr_fec: cosmetic comment changes

Maxime, I am unsure I get the meaning. Is there anything to be done for this patch? Thanks Nic > -Original Message- > From: Thomas Monjalon > Sent: Tuesday, April 2, 2024 8:28 AM > To: maxime.coque...@redhat.com; Vargas, Hernan > > Cc: dev@dpdk.org; gak...@marvell.com; Rix, Tom ; > Chau

RE: [PATCH v3 17/30] baseband: replace use of fixed size rte_memcpy

Hi Stephen, Your script is causing some odd line split which are not required I believe. Also doing mix of space and tabs. - rte_memcpy(&desc->req.fcw_ld, &desc_first->req.fcw_ld, ACC_FCW_LD_BLEN); + memcpy(&desc->req.fcw_ld, &desc_first->req.fcw_ld, +

Re: [PATCH] lib: add get/set link settings interface

On Thu, Apr 04, 2024 at 05:55:18PM -0700, Tyler Retzlaff wrote: > On Thu, Apr 04, 2024 at 09:09:40AM +0200, David Marchand wrote: > > Hello Tyler, Marek, > > > > On Wed, Apr 3, 2024 at 6:49 PM Tyler Retzlaff > > wrote: > > > > > > On Wed, Apr 03, 2024 at 06:40:24AM -0700, Marek Pazdan wrote: > >

Re: [PATCH] lib: add get/set link settings interface

On Thu, Apr 04, 2024 at 09:09:40AM +0200, David Marchand wrote: > Hello Tyler, Marek, > > On Wed, Apr 3, 2024 at 6:49 PM Tyler Retzlaff > wrote: > > > > On Wed, Apr 03, 2024 at 06:40:24AM -0700, Marek Pazdan wrote: > > > There are link settings parameters available from PMD drivers level > > >

Re: [PATCH v1 1/3] bbdev: new queue stat for available enqueue depth

On Thu, 4 Apr 2024 14:04:45 -0700 Nicolas Chautru wrote: > Capturing additional queue stats counter for the > depth of enqueue batch still available on the given > queue. This can help application to monitor that depth > at run time. > > Signed-off-by: Nicolas Chautru Adding field is an ABI c

[PATCH v1 2/3] baseband/acc: refactor queue status update

Introducing common function for queue stats update within the acc PMDs. Signed-off-by: Nicolas Chautru --- drivers/baseband/acc/acc_common.h | 18 drivers/baseband/acc/rte_acc100_pmd.c | 45 ++-- drivers/baseband/acc/rte_vrb_pmd.c| 61 +--

[PATCH v1 3/3] test/bbdev: update for queue stats

Update to include in test application the queue stats for the enqueue_depth_avail counter. Signed-off-by: Nicolas Chautru --- app/test-bbdev/test_bbdev_perf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c index dcce00aa0a.

[PATCH v1 0/3] Additional queue stats

These series include introducing a new paramter in the queue stat which can be used to monitor the number of available enqueue still possible. The acc PMD is then refactored to use a set of common function to update several queue status parameters including the new one. The application is also upd

[PATCH v1 1/3] bbdev: new queue stat for available enqueue depth

Capturing additional queue stats counter for the depth of enqueue batch still available on the given queue. This can help application to monitor that depth at run time. Signed-off-by: Nicolas Chautru --- lib/bbdev/rte_bbdev.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/bbdev/rte_bb

Re: [PATCH v2 2/2] buildtools: when building static library use static deps

On Fri, Mar 15, 2024 at 08:28:55AM +, Bruce Richardson wrote: > On Thu, Mar 14, 2024 at 11:30:22PM -0700, Tyler Retzlaff wrote: > > Use static deps when default_library=static and use shared deps when > > using default_library=shared. > > > > Signed-off-by: Tyler Retzlaff > > --- > > buildto

Re: [PATCH] hash: remove return statement from function returning void

Recheck-request: iol-unit-amd64-testing

[PATCH v11 4/4] cryptodev: remove rte marker fields

RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove RTE_MARKER fields from rte_mbuf struct. Maintain alignment of fields after removed cacheline1 marker by placing C11 alignas(RTE_CACHE_LINE_MIN_SIZE). Signed-off-by: Tyler Retzlaff Reviewed-by: Morten Brørup Acked-by: Stephen He

[PATCH v11 2/4] mbuf: remove rte marker fields

RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove RTE_MARKER fields from rte_mbuf struct. Maintain alignment of fields after removed cacheline1 marker by placing C11 alignas(RTE_CACHE_LINE_MIN_SIZE). Provide new rearm_data and rx_descriptor_fields1 fields in anonymous unions as

[PATCH v11 0/4] remove use of RTE_MARKER fields in libraries

As per techboard meeting 2024/03/20 adopt hybrid proposal of adapting descriptor fields and removing cachline fields. RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove RTE_MARKER fields. For cacheline{0,1} fields remove fields entirely and use inline functions to prefetch. Prov

[PATCH v11 3/4] security: remove rte marker fields

RTE_MARKER typedefs are a GCC extension unsupported by MSVC. Remove RTE_MARKER fields from rte_mbuf struct. Maintain alignment of fields after removed cacheline1 marker by placing C11 alignas(RTE_CACHE_LINE_MIN_SIZE). Signed-off-by: Tyler Retzlaff Reviewed-by: Morten Brørup Acked-by: Stephen He

[PATCH v11 1/4] net/i40e: use inline prefetch function

Don't directly access the cacheline1 field in rte_mbuf struct for prefetch instead just use rte_mbuf_prefetch_part2() to prefetch. Signed-off-by: Tyler Retzlaff Reviewed-by: Morten Brørup Acked-by: Stephen Hemminger --- drivers/net/i40e/i40e_rxtx_vec_avx512.c | 2 +- 1 file changed, 1 insertio

[PATCH 4/4] dispatcher: use alloca instead of vla multi dimensional

RFC sample illustrating conversion of multi-dimensional VLA to use alloca(). Signed-off-by: Tyler Retzlaff --- lib/dispatcher/rte_dispatcher.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/dispatcher/rte_dispatcher.c b/lib/dispatcher/rte_dispatcher.c index 7934917

[PATCH 3/4] vhost: use alloca instead of vla sizeof

RFC sample illustrating conversion of VLA to alloca() where sizeof(array) was in use. Signed-off-by: Tyler Retzlaff --- lib/vhost/socket.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c index 96b3ab5..cedcfb2 100644 --- a/lib/vhos

[PATCH 1/4] latencystats: use alloca instead of vla trivial

RFC sample illustrating simple conversion of VLA to alloca(). Signed-off-by: Tyler Retzlaff --- lib/latencystats/rte_latencystats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/latencystats/rte_latencystats.c b/lib/latencystats/rte_latencystats.c index 4ea9b0d..f59a9e

[PATCH 2/4] hash: use alloca instead of vla trivial

RFC sample illustrating simple conversion of VLA to alloca() where dimension multiplier removed. Signed-off-by: Tyler Retzlaff --- lib/hash/rte_thash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/hash/rte_thash.c b/lib/hash/rte_thash.c index 68f653f..633e211 100644 --

[PATCH 0/4] RFC samples converting VLA to alloca

This series is not intended for merge. It insteat provides examples of converting use of VLAs to alloca() would look like. what's the advantages of VLA over alloca()? * sizeof(array) works as expected. * multi-dimensional arrays are still arrays instead of pointers to dynamically allocated sp

Re: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

On Thu, Apr 04, 2024 at 06:10:32PM +0200, Morten Brørup wrote: > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Thursday, 4 April 2024 17.56 > > > > On Thu, 4 Apr 2024 17:37:53 +0200 > > Morten Brørup wrote: > > > > > > I would tend to agree with Stephen that whereever p

Community CI Meeting Minutes - April 4, 2024

April 4, 2024 # Attendees 1. Patrick Robb 2. Juraj Linkeš 3. Paul Szczepanek 4. Luca Vizzarro # Minutes

[PATCH v3 2/2] test: add functional test for uuid

The uuid functions in EAL were not covered by existing functional tests. Signed-off-by: Stephen Hemminger --- app/test/meson.build | 1 + app/test/test_uuid.c | 138 +++ 2 files changed, 139 insertions(+) create mode 100644 app/test/test_uuid.c diff --

[PATCH v3 1/2] eal: add functions to generate uuid values

Useful to be able to generate uuid values for tests or for interaction with other subsystems as magic cookie. Naming and overall algorithm come from libuuid which is used by permission of original author. Signed-off-by: Stephen Hemminger --- lib/eal/common/eal_common_uuid.c | 56

[PATCH v3 0/2] uuid: add generate functions and tests

While looking at using uuid's in some logging cases, discovered that the existing uuid support in EAL was missing some functions add in later versions of libuuid. Add functions to generate Uuid values, and add missing functional tests for uuid's. Stephen Hemminger (2): eal: add functions to gen

Re: [PATCH v2 2/2] test: add functional test for uuid

On Wed, Apr 03, 2024 at 03:11:08PM -0700, Stephen Hemminger wrote: > The uuid functions in EAL were not covered by existing functional > tests. > > Signed-off-by: Stephen Hemminger > --- Acked-by: Tyler Retzlaff

RE: Issues around packet capture when secondary process is doing rx/tx

> -Original Message- > From: Stephen Hemminger > Sent: Tuesday, January 9, 2024 11:07 PM > To: Konstantin Ananyev > Cc: dev@dpdk.org; arshdeep.k...@intel.com; Gowda, Sandesh > ; Reshma Pattan > > Subject: Re: Issues around packet capture when sec

Re: [PATCH v2 1/2] eal: add functions to generate uuid values

On Wed, Apr 03, 2024 at 03:11:07PM -0700, Stephen Hemminger wrote: > Useful to be able to generate uuid values for tests or > for interaction with other subsystems as magic cookie. > Naming and overall algorithm come from libuuid which is used > by permission of original author. > > Signed-off-by:

Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program

On Thu, 4 Apr 2024 at 16:51, Stephen Hemminger wrote: > > On Thu, 4 Apr 2024 01:49:56 +0100 > Luca Boccassi wrote: > > > On Thu, 4 Apr 2024 at 00:41, Stephen Hemminger > > wrote: > > > > > > On Wed, 3 Apr 2024 22:19:20 +0100 > > > Luca Boccassi wrote: > > > > > > > On Wed, 3 Apr 2024 at 16:55,

Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program

On Thu, 4 Apr 2024 at 16:31, Stephen Hemminger wrote: > > On Wed, 3 Apr 2024 22:19:20 +0100 > Luca Boccassi wrote: > > > On Wed, 3 Apr 2024 at 16:55, Stephen Hemminger > > wrote: > > > > > > On Wed, 03 Apr 2024 12:50:35 +0100 > > > Luca Boccassi wrote: > > > > > > > Using bpftool to generate th

Re: [PATCH 1/2] eal: add functions to generate uuid values

On Wed, Apr 03, 2024 at 09:32:29AM -0700, Stephen Hemminger wrote: > Useful to be able to generate uuid values for tests or > for interaction with other subsystems as magic cookie. > Naming and overall algorithm come from libuuid which is used > by permission of original author. > > Signed-off-by:

RE: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Thursday, 4 April 2024 17.56 > > On Thu, 4 Apr 2024 17:37:53 +0200 > Morten Brørup wrote: > > > > I would tend to agree with Stephen that whereever possible we should use > > > the built-in memcpy calls. Hence my suggestion of

Re: [PATCH] net/ixgbe: add param check when tx_queue or rx_queqe is null

On Sat, Mar 23, 2024 at 10:48:42PM +0800, keivinwang wrote: > add param check when tx_queue or rx_queqe is null. > Hi, trying to get some context on this patch. Have you encountered a situation where there are actually NULL parameters getting passed to the functions, or where an rx queue is unex

Re: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

On Thu, 4 Apr 2024 17:37:53 +0200 Morten Brørup wrote: > > I would tend to agree with Stephen that whereever possible we should use > > the built-in memcpy calls. Hence my suggestion of re-introducing the macro. > > > > I agree in principle, but strongly prefer data to back up such changes in

Re: [PATCH v3 00/30] replace rte_memcpy of fixed size with memcpy

On Tue, Apr 02, 2024 at 02:50:16PM -0700, Stephen Hemminger wrote: > The DPDK has a lot of unnecessary usage of rte_memcpy. > This patch set replaces cases where rte_memcpy is used with a fixed > size constant size. > > Typical example is: > rte_memcpy(mac_addrs, mac.addr_bytes, RTE_ETHER_AD

Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program

On Thu, 4 Apr 2024 01:49:56 +0100 Luca Boccassi wrote: > On Thu, 4 Apr 2024 at 00:41, Stephen Hemminger > wrote: > > > > On Wed, 3 Apr 2024 22:19:20 +0100 > > Luca Boccassi wrote: > > > > > On Wed, 3 Apr 2024 at 16:55, Stephen Hemminger > > > wrote: > > > > > > > > On Wed, 03 Apr 2024 12:5

RE: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Thursday, 4 April 2024 15.29 > > On Thu, Apr 04, 2024 at 01:19:54PM +0200, Morten Brørup wrote: > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > > Sent: Thursday, 4 April 2024 12.07 > > > > > > On Sun, Mar 03,

[PATCH] dts: Change hugepage runtime config to 2MB Exclusively

The previous implementation configures and allocates hugepage sizes based on a system default. This can lead to two problems: overallocation of hugepages (which may crash the remote host), and configuration of hugepage sizes that are not recommended during runtime. This new implementation allows on

Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program

On Wed, 3 Apr 2024 22:19:20 +0100 Luca Boccassi wrote: > On Wed, 3 Apr 2024 at 16:55, Stephen Hemminger > wrote: > > > > On Wed, 03 Apr 2024 12:50:35 +0100 > > Luca Boccassi wrote: > > > > > Using bpftool to generate the header at build time is a bit icky, > > > because it will look at sysfs

Re: Issues around packet capture when secondary process is doing rx/tx

> Maybe pdump needs to have its own socket and control thread? > Or MP socket needs to have some multicast fanout to all secondaries? > >>> > >>> Might be we can do something simpler: pass to pdump_enable(), where we > >>> want to enable it: > >>> on primary (remote_ process or secon

Re: [PATCH] net/ixgbe: do not update link status in secondary process

On Wed, Mar 20, 2024 at 10:33:04AM -0700, Stephen Hemminger wrote: > The code to update link status is not safe in secondary process. > If called from secondary it will crash, example from dumpcap: > ixgbe_dev_link_update_share() > ixgbe_dev_link_update() > rte_eth_link_get() >

Re: Issues around packet capture when secondary process is doing rx/tx

On 4/4/2024 2:26 PM, Konstantin Ananyev wrote: > > -Original Message- From: Stephen Hemminger Sent: Tuesday, January 9, 2024 11:07 PM To: Konstantin Ananyev Cc: dev@dpdk.org; arshdeep.k...@intel.com; Gowda, Sandesh ; Reshma Pattan Subject: Re: I

[v13 3/3] net/af_xdp: support AF_XDP DP pinned maps

Enable the AF_XDP PMD to retrieve the xskmap from a pinned eBPF map. This map is expected to be pinned by an external entity like the AF_XDP Device Plugin. This enabled unprivileged pods to create and use AF_XDP sockets. Signed-off-by: Maryam Tahhan --- doc/guides/howto/af_xdp_dp.rst | 3

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

The original 'use_cni' implementation, was added to enable support for the AF_XDP PMD in a K8s env without any escalated privileges. However 'use_cni' used a hardcoded socket rather than a configurable one. If a DPDK pod is requesting multiple net devices and these devices are from different pools,

[v13 1/3] docs: AF_XDP Device Plugin

Fixup the references to the AF_XDP Device Plugin in the documentation (was referred to as CNI previously) and document the single netdev limitation for deploying an AF_XDP based DPDK pod. Also renames af_xdp_cni.rst to af_xdp_dp.rst Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration") Cc: s

[v13 0/3] net/af_xdp: fix multi interface support for K8s

The original `use_cni` implementation was limited to supporting only a single netdev in a DPDK pod. This patchset aims to fix this limitation transparently to the end user. It will also enable compatibility with the latest AF_XDP Device Plugin. Signed-off-by: Maryam Tahhan --- v13: * Fixup check

Re: [PATCH v2 0/6] support setting lanes

On 3/22/2024 7:09 AM, Dengdui Huang wrote: > At the physical layer, multiple lanes are often used to work together > to achieve higher speeds. So a speeds can be achieved with different > number of lanes. For example, the following solutions can be used to > implement 100G: > 1. Combines four 25G l

Re: [PATCH v2 1/6] ethdev: support setting lanes

On 4/2/2024 9:37 AM, huangdengdui wrote: > > > On 2024/4/2 4:07, Thomas Monjalon wrote: >> 30/03/2024 12:38, huangdengdui: >>> But, there are different solutions for the device to report the setting >>> lane capability, as following: >>> 1. Like the current patch, reporting device capabilities in

Re: [PATCH] net/iavf: fix fail to reset vf when using dcf

On Tue, Mar 19, 2024 at 09:51:00AM +, Li, HongboX wrote: > > -Original Message- > > From: Kaiwen Deng > > Sent: Thursday, March 14, 2024 9:01 AM > > To: dev@dpdk.org > > Cc: sta...@dpdk.org; Zhou, YidingX ; Deng, KaiwenX > > ; Wu, Jingjing ; Zeng, > > ZhichaoX ; Zhang, Qi Z > > Subjec

Re: Major Winter Storm in the UNH Lab Area

The DPDK Community Lab at UNH has lost power, so we will have some testing downtime today. I will update here when I know more. Like always, we will put in all needed retests once power is restored. Thanks, Patrick On Tue, Apr 2, 2024 at 12:28 PM Patrick Robb wrote: > > Hello, > > There will be

Re: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

On Thu, Apr 04, 2024 at 01:19:54PM +0200, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Thursday, 4 April 2024 12.07 > > > > On Sun, Mar 03, 2024 at 10:46:21AM +0100, Morten Brørup wrote: > > > When the rte_memcpy() size is 16, the same 16 bytes are

RE: Issues around packet capture when secondary process is doing rx/tx

> >> -Original Message- > >> From: Stephen Hemminger > >> Sent: Tuesday, January 9, 2024 11:07 PM > >> To: Konstantin Ananyev > >> Cc: dev@dpdk.org; arshdeep.k...@intel.com; Gowda, Sandesh > >> ; Reshma Pattan > >> > >> Subject: Re: Issues around packet capture when secondary process

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

The original 'use_cni' implementation, was added to enable support for the AF_XDP PMD in a K8s env without any escalated privileges. However 'use_cni' used a hardcoded socket rather than a configurable one. If a DPDK pod is requesting multiple net devices and these devices are from different pools,

[v12 3/3] net/af_xdp: support AF_XDP DP pinned maps

Enable the AF_XDP PMD to retrieve the xskmap from a pinned eBPF map. This map is expected to be pinned by an external entity like the AF_XDP Device Plugin. This enabled unprivileged pods to create and use AF_XDP sockets. Signed-off-by: Maryam Tahhan --- doc/guides/howto/af_xdp_dp.rst | 3

[v12 1/3] docs: AF_XDP Device Plugin

Fixup the references to the AF_XDP Device Plugin in the documentation (was referred to as CNI previously) and document the single netdev limitation for deploying an AF_XDP based DPDK pod. Also renames af_xdp_cni.rst to af_xdp_dp.rst Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration") Cc: s

[v12 0/3] net/af_xdp: fix multi interface support for K8s

The original `use_cni` implementation was limited to supporting only a single netdev in a DPDK pod. This patchset aims to fix this limitation transparently to the end user. It will also enable compatibility with the latest AF_XDP Device Plugin. Signed-off-by: Maryam Tahhan --- v12: * Ensure back

Re: [PATCH v16 1/8] net/ntnic: initial commit which adds register defines

On 4/3/2024 11:55 AM, Mykola Kostenok wrote: <...> >> >> Hi Christian, Mykola, >> >> What is the status of the 'ntnic'? >> Will there be some upstreaming effort for v24.07? > > Hi, Ferruh. > Yes, we plan to send new 'ntnic' patch series into v24.07 > Right now, we are doing refactoring of 'ntnic

RE: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Thursday, 4 April 2024 12.07 > > On Sun, Mar 03, 2024 at 10:46:21AM +0100, Morten Brørup wrote: > > When the rte_memcpy() size is 16, the same 16 bytes are copied twice. > > In the case where the size is known to be 16 at build t

RE: [PATCH v3 15/30] net: replace use of fixed size rte_memcpy

> -Original Message- > From: Stephen Hemminger > Sent: Wednesday, April 3, 2024 12:51 AM > To: dev@dpdk.org > Cc: Stephen Hemminger ; Ciara Loftus > ; Steven Webster ; > Matt Peters ; Selwin Sebastian > ; Julien Aube ; Ajit > Khaparde ; Somnath Kotur > ; Chas Williams ; Min Hu > (Connor) ;

Re: [PATCH] net/iavf: fix fail to reset vf when using dcf

On Thu, Mar 14, 2024 at 09:00:49AM +0800, Kaiwen Deng wrote: > On the latest ice kernel driver, renegotiating VIRTCHNL_OP_GET_VF_RESOURCES > will fail without hardware reset when using dcf. > > This commit will send VIRTCHNL_OP_RESET_VF to pf before dpdk resets vf. > > Fixes: 7a93cd3575eb ("net/i

Re: [PATCH] net/ice: fix vlan stripping in double VLAN mode

On Wed, Mar 27, 2024 at 06:44:13PM +, Vladimir Medvedkin wrote: > The ICE hardware can operate in two modes - single vlan mode > or double vlan mode. Depending on the operating mode the hardware > handles vlan header with single vlan tag differently. > When double vlan enabled, a packet with a

Re: [PATCH] net/fm10k: fix cleanup during init failure

On Thu, Apr 04, 2024 at 11:18:16AM +0100, Bruce Richardson wrote: > On Wed, Apr 03, 2024 at 01:55:41PM +0200, Julien Meunier wrote: > > Cleanup was not done on this PMD if a error is seen during the init: > > - possible memory leak due to a missing free > > - interrupt handler was not disabled: if

Re: [PATCH] net/fm10k: fix cleanup during init failure

On Wed, Apr 03, 2024 at 01:55:41PM +0200, Julien Meunier wrote: > Cleanup was not done on this PMD if a error is seen during the init: > - possible memory leak due to a missing free > - interrupt handler was not disabled: if an IRQ is received after the > init, a SIGSEGV can be seen (private data

Re: [PATCH 0/2] Tx path check mbuf sub-segment

On Tue, Mar 19, 2024 at 09:39:47AM +, Li, HongboX wrote: > > -Original Message- > > From: Mingjin Ye > > Sent: Friday, March 15, 2024 6:24 PM > > To: dev@dpdk.org > > Cc: Ye, MingjinX > > Subject: [PATCH 0/2] Tx path check mbuf sub-segment > > > > Add check mbuf sub-segment to Tx dia

Re: [PATCH v3] lib/hash: add defer queue reclaim API

Hello, Could you check the last commit? Thanks On Thu, Mar 14, 2024 at 10:04 AM Abdullah Ömer Yamaç wrote: > Hello, > Is there any other comment on this? > > On Wed, Mar 6, 2024 at 1:13 PM Abdullah Ömer Yamaç > wrote: > >> This patch adds a new feature to the hash library to allow the user to >

Re: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

On Sun, Mar 03, 2024 at 10:46:21AM +0100, Morten Brørup wrote: > When the rte_memcpy() size is 16, the same 16 bytes are copied twice. > In the case where the size is known to be 16 at build tine, omit the > duplicate copy. > > Reduced the amount of effectively copy-pasted code by using #ifdef > i

RE: [PATCH v7] mempool: test performance with larger bursts

PING for review. This patch is relatively trivial. > From: Morten Brørup [mailto:m...@smartsharesystems.com] > Sent: Saturday, 2 March 2024 21.04 > > Bursts of up to 64, 128 and 256 packets are not uncommon, so increase the > maximum tested get and put burst sizes from 32 to 256. > For convenienc

Re: [PATCH v2 1/3] dts: rework arguments framework

On Mon, Mar 18, 2024 at 6:17 PM Luca Vizzarro wrote: > > The existing argument handling in the code relies on basic argparse > functionality and a custom argparse action to integrate environment > variables. This commit improves the current handling by augmenting > argparse through a custom implem

RE: [PATCH v2] eal/x86: improve rte_memcpy const size 16 performance

PING Intel x86 maintainers for review. > From: Morten Brørup [mailto:m...@smartsharesystems.com] > Sent: Sunday, 3 March 2024 10.46 > > When the rte_memcpy() size is 16, the same 16 bytes are copied twice. > In the case where the size is known to be 16 at build tine, omit the > duplicate copy. >

Re: [PATCH] dpdk-testpmd: call get/set link settings interface

On 4/3/2024 11:53 PM, Marek Pazdan wrote: > Add cmdline options for utilizing get/set link settings API > added before in patch this patch depends on. Purpose of this > change is to provide mechanism for testing link settings interface > API. > > Signed-off-by: Marek Pazdan > --- > Depends-on: pa

RE: [PATCH v3 00/30] replace rte_memcpy of fixed size with memcpy

> The DPDK has a lot of unnecessary usage of rte_memcpy. > This patch set replaces cases where rte_memcpy is used with a fixed > size constant size. > > Typical example is: > rte_memcpy(mac_addrs, mac.addr_bytes, RTE_ETHER_ADDR_LEN); > which can be replaced with: > memcpy(mac_addrs,

[PATCH] dpdk-testpmd: call get/set link settings interface

Add cmdline options for utilizing get/set link settings API added before in patch this patch depends on. Purpose of this change is to provide mechanism for testing link settings interface API. Signed-off-by: Marek Pazdan --- Depends-on: patch-139082 ("lib: add get/set link settings interface") --

Re: [PATCH] lib: add get/set link settings interface

I can remove this part (rte_eth_config), but the new API provides other link information which is not available from the existing API, like supported/advertising/partner_advertising link modes. Additionally from what I see, rte_eth_confg is available from rte_eth_dev_conf_get API and it's copy of r

Re: [PATCH] lib: add get/set link settings interface

Hello Tyler, Marek, On Wed, Apr 3, 2024 at 6:49 PM Tyler Retzlaff wrote: > > On Wed, Apr 03, 2024 at 06:40:24AM -0700, Marek Pazdan wrote: > > There are link settings parameters available from PMD drivers level > > which are currently not exposed to the user via consistent interface. > > When