date:20241012

On Mon, 19 Aug 2024 07:23:30 +0200
Kamil Vojanec  wrote:

> LRU caches replace records when requested table bucket is full. There
> is, however, no information about this happening in either the return
> value or the statistics. This commit introduces a counter for such
> cases.
> 
> Signed-off-by: Kamil Vojanec 
> ---
>  lib/table/rte_table.h| 1 +
>  lib/table/rte_table_hash_key16.c | 4 
>  lib/table/rte_table_hash_key32.c | 4 
>  lib/table/rte_table_hash_key8.c  | 4 
>  lib/table/rte_table_hash_lru.c   | 4 
>  5 files changed, 17 insertions(+)
> 
> diff --git a/lib/table/rte_table.h b/lib/table/rte_table.h
> index 9a5faf0e32..e097e25868 100644
> --- a/lib/table/rte_table.h
> +++ b/lib/table/rte_table.h
> @@ -33,6 +33,7 @@ struct rte_mbuf;
>  struct rte_table_stats {
>   uint64_t n_pkts_in;
>   uint64_t n_pkts_lookup_miss;
> + uint64_t n_pkts_insert_victims;
>  };
>  

This ABI change so it needs a release note, and has to targeted
at a LTS release, too late for 24.11; so would end up getting deferred
until 25.11..

When you send followup please reply-to the initial RFC message id
with "PATCH v3"

[PATCH] net/mlx5: fix potential memory leak in meter

2024-10-12 Thread Shun Hao

When meter not enabled, avoid allocate memory for meter profile table,
which will not be freed in close process when meter not enabled

Fixes: a295c69a8b24 ("net/mlx5: optimize meter profile lookup")
Cc: sta...@dpdk.org

Signed-off-by: Shun Hao 
Acked-by: Bing Zhao 
---
 drivers/net/mlx5/linux/mlx5_os.c   | 8 +---
 drivers/net/mlx5/mlx5_flow_meter.c | 3 +--
 drivers/net/mlx5/windows/mlx5_os.c | 8 +---
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 0a8de88759..3881daf5cc 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1612,9 +1612,11 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
priv->ctrl_flows = 0;
rte_spinlock_init(&priv->flow_list_lock);
TAILQ_INIT(&priv->flow_meters);
-   priv->mtr_profile_tbl = mlx5_l3t_create(MLX5_L3T_TYPE_PTR);
-   if (!priv->mtr_profile_tbl)
-   goto error;
+   if (priv->mtr_en) {
+   priv->mtr_profile_tbl = mlx5_l3t_create(MLX5_L3T_TYPE_PTR);
+   if (!priv->mtr_profile_tbl)
+   goto error;
+   }
/* Bring Ethernet device up. */
DRV_LOG(DEBUG, "port %u forcing Ethernet interface up",
eth_dev->data->port_id);
diff --git a/drivers/net/mlx5/mlx5_flow_meter.c 
b/drivers/net/mlx5/mlx5_flow_meter.c
index 19d8607070..50587d6cfb 100644
--- a/drivers/net/mlx5/mlx5_flow_meter.c
+++ b/drivers/net/mlx5/mlx5_flow_meter.c
@@ -378,8 +378,7 @@ mlx5_flow_meter_profile_find(struct mlx5_priv *priv, 
uint32_t meter_profile_id)
 
if (priv->mtr_profile_arr)
return &priv->mtr_profile_arr[meter_profile_id];
-   if (mlx5_l3t_get_entry(priv->mtr_profile_tbl,
-  meter_profile_id, &data) || !data.ptr)
+   if (!priv->mtr_profile_tbl || mlx5_l3t_get_entry(priv->mtr_profile_tbl, 
meter_profile_id, &data) || !data.ptr)
return NULL;
fmp = data.ptr;
/* Remove reference taken by the mlx5_l3t_get_entry. */
diff --git a/drivers/net/mlx5/windows/mlx5_os.c 
b/drivers/net/mlx5/windows/mlx5_os.c
index 0ebd233595..61ad06a373 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -521,9 +521,11 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
claim_zero(mlx5_mac_addr_add(eth_dev, &mac, 0, 0));
priv->ctrl_flows = 0;
TAILQ_INIT(&priv->flow_meters);
-   priv->mtr_profile_tbl = mlx5_l3t_create(MLX5_L3T_TYPE_PTR);
-   if (!priv->mtr_profile_tbl)
-   goto error;
+   if (priv->mtr_en) {
+   priv->mtr_profile_tbl = mlx5_l3t_create(MLX5_L3T_TYPE_PTR);
+   if (!priv->mtr_profile_tbl)
+   goto error;
+   }
/* Bring Ethernet device up. */
DRV_LOG(DEBUG, "port %u forcing Ethernet interface up.",
eth_dev->data->port_id);
-- 
2.20.0

RE: [RFC] Define well known packet burst sizes

2024-10-12 Thread Pavan Nikhilesh Bhagavatula

> We should define some "well known" packet burst sizes in rte_config.h.
> 

A while back we had the same idea, except that it should be platform specific
Ex., for CNXK optimal burst size across workloads is 64.

Instead of rte_config.h maybe we should have it as a meson option in 
meson_options.txt with default as 32.

That way platforms can also modify it in config//meson.build

> Especially the default packet burst size is interesting;
> if known at compile time, various drivers and libraries can optimize for it 
> (i.e.
> special handling for nb_pkts == RTE_PKT_BURST_DEFAULT).
> 
> It should also be used in DPDK examples and apps, instead of defining
> MAX_PKT_BURST in each and everyone.
> 
> 
> Specifically:
> 
> /**
>  * Default packet burst size.
>  *
>  * Also intended for optimizing packet processing (e.g. by loop unrolling).
>  */
> #define RTE_PKT_BURST_DEFAULT 32
> 
> /**
>  * Largest packet burst size guaranteed to be supported throughout DPDK.
>  *
>  * Also intended for sizing large temporary arrays of mbufs, e.g. in
> rte_pktmbuf_free_bulk().
>  */
> #define RTE_PKT_BURST_MAX 512
> #define RTE_MEMPOOL_CACHE_MAX_SIZE RTE_PKT_BURST_MAX
> 
> /**
>  * Smallest packet burst size recommended for latency sensitive applications,
> when throughput still matters.
>  *
>  * Also intended for sizing small staging arrays of mbufs, e.g. in drivers.
>  *
>  * Note: Corresponds to one CPU cache line of object pointers.
>  *  - 8 on most 64 bit architectures, 16 on POWER architecture (ppc_64).
>  *  - 16 on all 32 bit architectures.
>  */
> #define RTE_PKT_BURST_SMALL (RTE_CACHE_LINE_SIZE / sizeof(void *))

[RFC] Define well known packet burst sizes

2024-10-12 Thread Morten Brørup

We should define some "well known" packet burst sizes in rte_config.h.

Especially the default packet burst size is interesting;
if known at compile time, various drivers and libraries can optimize for it 
(i.e. special handling for nb_pkts == RTE_PKT_BURST_DEFAULT).

It should also be used in DPDK examples and apps, instead of defining 
MAX_PKT_BURST in each and everyone.


Specifically:

/**
 * Default packet burst size.
 *
 * Also intended for optimizing packet processing (e.g. by loop unrolling).
 */
#define RTE_PKT_BURST_DEFAULT 32

/**
 * Largest packet burst size guaranteed to be supported throughout DPDK.
 *
 * Also intended for sizing large temporary arrays of mbufs, e.g. in 
rte_pktmbuf_free_bulk().
 */
#define RTE_PKT_BURST_MAX 512
#define RTE_MEMPOOL_CACHE_MAX_SIZE RTE_PKT_BURST_MAX

/**
 * Smallest packet burst size recommended for latency sensitive applications, 
when throughput still matters.
 *
 * Also intended for sizing small staging arrays of mbufs, e.g. in drivers.
 *
 * Note: Corresponds to one CPU cache line of object pointers.
 *  - 8 on most 64 bit architectures, 16 on POWER architecture (ppc_64).
 *  - 16 on all 32 bit architectures.
 */
#define RTE_PKT_BURST_SMALL (RTE_CACHE_LINE_SIZE / sizeof(void *))

RE: [PATCH] examples/l3fwd: add option to set RX burst size

2024-10-12 Thread Morten Brørup

> From: Jie Hai [mailto:haij...@huawei.com]
> Sent: Saturday, 12 October 2024 10.41
> 
> Now the Rx burst size is fixed to MAX_PKT_BURST (32). This
> parameter needs to be modified in some performance optimization
> scenarios. So an option '--burst' is added to set the burst size
> explicitly. The default value is DEFAULT_PKT_BURST (32) and maximum
> value is MAX_PKT_BURST (512).

Good idea.

> 
> Signed-off-by: Jie Hai 
> ---
> 
> -#define MAX_PKT_BURST 32
> +#define DEFAULT_PKT_BURST 32
> +#define MAX_PKT_BURST 512
>  #define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
> 
>  #define MEMPOOL_CACHE_SIZE 256

It seems strange to use a burst size larger than the mempool cache size.

You might want to make the cache size configurable too, or simply define 
MEMPOOL_CACHE_SIZE as RTE_MEMPOOL_CACHE_MAX_SIZE (currently 512) instead of 256.

And, as a safety measure, consider adding:
#include 
static_assert(MEMPOOL_CACHE_SIZE >= MAX_PKT_BURST);

Re: [RESEND] net/hns3: verify reset type from firmware

On 10/12/2024 10:14 AM, Jie Hai wrote:
> From: Chengwen Feng 
> 
> Verify reset-type which get from firmware.
> 
> Fixes: 1c1eb759e9d7 ("net/hns3: support RAS process in Kunpeng 930")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Chengwen Feng 
>

Adding implicit ack:
Acked-by: Jie Hai 

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

Re: [PATCH v2 0/3] net/tap: queue limit patches

On Sun, 13 Oct 2024 00:53:54 +0100
Ferruh Yigit  wrote:

> On 10/12/2024 3:17 AM, Stephen Hemminger wrote:
> > Some patches related to recent queue limit changes.
> > 
> > v2 - up the limit to maximum Linux can support
> >  dont use static_assert here
> >  get rid of unreachable checks in configure
> > 
> > Stephen Hemminger (3):
> >   net/tap: handle increase in mp_max_fds
> >   net/tap: increase the maximum allowable queues
> >   net/tap: remove unnecessary checks in configure
> >   
> 
> Hi Stephen,
> 
> Previous version already merged, but I am checking the difference in v2.
> 
> Patch 1/3 is identical.
> Patch 2/3, I prefer the v1 version, that increases the queue limit to
> 64, instead of 253.

Ok, we can bump it later if anyone wants to run on 128 core cpu

> 
> v1 patch 3/3 static assert seems gone, it seems because of the loongarch
> build, but can we please root cause why it failed, and can the failure
> be a test environment issue?

Right, not sure what was wrong there, and not easy to setup a loongarch
build (even with qemu) to repro.


> v2 patch 3/3 looks good, it can be merged separately.

Ok, will add it to later follow up set. The tap device driver needs
lots more cleanups.

Re: [PATCH v10 1/2] power: introduce PM QoS API on CPU wide

On Thu, 12 Sep 2024 10:38:11 +0800
Huisong Li  wrote:

> +
> +PM QoS
> +--
> +
> +The deeper the idle state, the lower the power consumption, but the longer
> +the resume time. Some service are delay sensitive and very except the low
> +resume time, like interrupt packet receiving mode.
> +
> +And the "/sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us" sysfs
> +interface is used to set and get the resume latency limit on the cpuX for
> +userspace. Each cpuidle governor in Linux select which idle state to enter
> +based on this CPU resume latency in their idle task.
> +
> +The per-CPU PM QoS API can be used to set and get the CPU resume latency 
> based
> +on this sysfs.
> +
> +The ``rte_power_qos_set_cpu_resume_latency()`` function can control the CPU's
> +idle state selection in Linux and limit just to enter the shallowest idle 
> state
> +to low the delay of resuming service after sleeping by setting strict resume
> +latency (zero value).
> +
> +The ``rte_power_qos_get_cpu_resume_latency()`` function can get the resume
> +latency on specified CPU.
> +

These paragraphs need some editing help. The wording is awkward,
it uses passive voice, and does not seemed directed at a user audience.
If you need help, a writer or AI might help clarify.

It also ends up in the section associated with Intel UnCore.
It would be better after the Turbo Boost section.



> + ret = open_core_sysfs_file(&f, "w", PM_QOS_SYSFILE_RESUME_LATENCY_US, 
> lcore_id);
> + if (ret != 0) {
> + POWER_LOG(ERR, "Failed to open 
> "PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id);
> + return ret;
> + }

The function open_core_sysfs_file() should have been written to return FILE *
and then it could have same attributes as fopen().

The message should include the error reason.

if (open_core_sysfs_file(&f, "w", PM_QOS_SYSFILE_RESUME_LATENCY_US, 
lcore_id)) {
POWER_LOG(ERR, "Failed to open " 
PM_QOS_SYSFILE_RESUME_LATENCY_US ": %s",
lcore_id, strerror(errno));

Re: [PATCH v2 0/3] net/tap: queue limit patches

On 10/13/2024 1:53 AM, Stephen Hemminger wrote:
> On Sun, 13 Oct 2024 00:53:54 +0100
> Ferruh Yigit  wrote:
> 
>> On 10/12/2024 3:17 AM, Stephen Hemminger wrote:
>>> Some patches related to recent queue limit changes.
>>>
>>> v2 - up the limit to maximum Linux can support
>>>  dont use static_assert here
>>>  get rid of unreachable checks in configure
>>>
>>> Stephen Hemminger (3):
>>>   net/tap: handle increase in mp_max_fds
>>>   net/tap: increase the maximum allowable queues
>>>   net/tap: remove unnecessary checks in configure
>>>   
>>
>> Hi Stephen,
>>
>> Previous version already merged, but I am checking the difference in v2.
>>
>> Patch 1/3 is identical.
>> Patch 2/3, I prefer the v1 version, that increases the queue limit to
>> 64, instead of 253.
> 
> Ok, we can bump it later if anyone wants to run on 128 core cpu
> 

ack

>>
>> v1 patch 3/3 static assert seems gone, it seems because of the loongarch
>> build, but can we please root cause why it failed, and can the failure
>> be a test environment issue?
> 
> Right, not sure what was wrong there, and not easy to setup a loongarch
> build (even with qemu) to repro.
> 

Indeed I was hoping to get some support from loongarch CI maintainers,
instead of we setup an environment to test.

As the patch is already merged in next-net, they should able to test &
debug it.

> 
>> v2 patch 3/3 looks good, it can be merged separately.
> 
> Ok, will add it to later follow up set. The tap device driver needs
> lots more cleanups.
> 

I can merge the patch directly from this set, planning to check it soon.

Re: [PATCH v2 00/10] modify some logic of NFP PMD

On 10/12/2024 3:40 AM, Chaoyong He wrote:
> This patch series refactor some logic of NFP PMD to make it more
> clear, also fix some bugs.
> 
> ---
> v2:
> * Following the reviewer's request, change a little logic of patch 10/10.
> * Add 'Acked-by' tag from reviewer.
> ---
> 
> Chaoyong He (10):
>   net/nfp: use strlcpy for copying string
>   net/nfp: fix malloc name problem in secondary process
>   net/nfp: simplify some function parameters
>   net/nfp: improve the logic readability
>   net/nfp: fix problem caused by configure function
>   net/nfp: add check logic for port up/down function
>   net/nfp: fix problem caused by commit end function
>   net/nfp: fix problem caused by FEC set
>   net/nfp: modify the comment of some control messages
>   net/nfp: fix memory leak in VF initialization logic
>

Except 2/10,
Series applied to dpdk-next-net/main, thanks.


The change in the 2/10 looks harmless, also I can see similar logic
already exist in the driver, but keeping it open to since discussion is
going on. Patch can be merged iteratively later if required.

RE: [RFC] Define well known packet burst sizes

2024-10-12 Thread Morten Brørup

> From: Pavan Nikhilesh Bhagavatula [mailto:pbhagavat...@marvell.com]
> Sent: Saturday, 12 October 2024 15.55
> 
> > We should define some "well known" packet burst sizes in
> rte_config.h.
> >
> 
> A while back we had the same idea, except that it should be platform
> specific
> Ex., for CNXK optimal burst size across workloads is 64.
> 
> Instead of rte_config.h maybe we should have it as a meson option in
> meson_options.txt with default as 32.
> 
> That way platforms can also modify it in config//meson.build

Agree. The default burst size should be platform specific for optimal 
performance. The "generic" platform value can be 32.

And applications with different needs can use a meson option to override the 
platform specific default.

The other two suggested "well known" (intended to be commonly used) burst sizes 
can reside in rte_config.h.

> 
> > Especially the default packet burst size is interesting;
> > if known at compile time, various drivers and libraries can optimize
> for it (i.e.
> > special handling for nb_pkts == RTE_PKT_BURST_DEFAULT).
> >
> > It should also be used in DPDK examples and apps, instead of defining
> > MAX_PKT_BURST in each and everyone.
> >
> >
> > Specifically:
> >
> > /**
> >  * Default packet burst size.
> >  *
> >  * Also intended for optimizing packet processing (e.g. by loop
> unrolling).
> >  */
> > #define RTE_PKT_BURST_DEFAULT 32
> >
> > /**
> >  * Largest packet burst size guaranteed to be supported throughout
> DPDK.
> >  *
> >  * Also intended for sizing large temporary arrays of mbufs, e.g. in
> > rte_pktmbuf_free_bulk().
> >  */
> > #define RTE_PKT_BURST_MAX 512
> > #define RTE_MEMPOOL_CACHE_MAX_SIZE RTE_PKT_BURST_MAX
> >
> > /**
> >  * Smallest packet burst size recommended for latency sensitive
> applications,
> > when throughput still matters.
> >  *
> >  * Also intended for sizing small staging arrays of mbufs, e.g. in
> drivers.
> >  *
> >  * Note: Corresponds to one CPU cache line of object pointers.
> >  *  - 8 on most 64 bit architectures, 16 on POWER architecture
> (ppc_64).
> >  *  - 16 on all 32 bit architectures.
> >  */
> > #define RTE_PKT_BURST_SMALL (RTE_CACHE_LINE_SIZE / sizeof(void *))

Re: [PATCH v2] test: fix option block

On Sat, 12 Oct 2024 09:35:19 +
Mingjin Ye  wrote:

> The options allow (-a) and block (-b) cannot be used at the same time.
> Therefore, allow (-a) will not be added when block (-b) is present.
> 
> Fixes: b3ce7891ad38 ("test: fix probing in secondary process")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Mingjin Ye 
> ---

What is this patch trying to solve?

Right now starting dpdk-test with both options together causes an error
in EAL init.

root@hermes:/home/shemminger/DPDK/main# ./build/app/dpdk-test -a ae:00.0 -b 
00:1f.6
EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Options allow (-a) and block (-b) can't be used at the same time

Usage: ./build/app/dpdk-test [options]

Therefore it should never get into the process_dup function at all.

[DPDK/ethdev Bug 1564] Broadcom doesn't receive network packets via RX Interrupt (infinite lock rte_epoll_wait)

2024-10-12 Thread bugzilla

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

Bug ID: 1564
Summary: Broadcom doesn't receive network packets via RX
Interrupt (infinite lock rte_epoll_wait)
Product: DPDK
Version: 24.07
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: lu...@easy-way.app
Target Milestone: ---

The rte_epoll_wait function is never returning, I believe that the interrupts
are not being properly configured for the bnxt_en driver after upgrade.

Bug NIC: Broadcom NetXtreme-E BCM57508

It is important to note that the same code works on Mellanox NIC, more
precisely Mellanox ConnectX-5 Ex MT28800

Steps to reproduce:
1. Update the NIC firmware using niccli utility
Download:
https://docs.broadcom.com/docs/NXE_Linux_niccli_231.0.162.1

Command:
./niccli -i 1 install -online

Online Tutorial:
https://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/ethernet-nic-controllers/bcm957xxx/adapters/software-installation/updating-the-firmware/updating-the-firmware-online.html

2. Change IP 67.159.40.18/24 to your network IP

3. Change IP 67.159.40.17 to your default gateway

4. Compile the code below

The final C++ code (cpp):
https://pastebin.com/VH6PLiTU

5. Run the binary generated by the previous compilation

You will see the error, if you remove rte epoll_wait the ping works normally,
but if you use rte_epoll_wait it will never return

If necessary, I can provide access to my dedicated server that uses this
specific Broadcom NIC.

I can also provide access to the VNC console to access the server even after
starting the application.

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

Re: [PATCH v9 12/12] crypto/zsda: add zsda crypto PMD

On Fri, 11 Oct 2024 09:56:32 +0800
Hanxiao Li  wrote:

> diff --git a/drivers/crypto/zsda/zsda_sym_capabilities.h 
> b/drivers/crypto/zsda/zsda_sym_capabilities.h
> new file mode 100644
> index 00..dd387b36ad
> --- /dev/null
> +++ b/drivers/crypto/zsda/zsda_sym_capabilities.h
> @@ -0,0 +1,112 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2024 ZTE Corporation
> + */
> +
> +#ifndef _ZSDA_SYM_CAPABILITIES_H_
> +#define _ZSDA_SYM_CAPABILITIES_H_
> +
> +static const struct rte_cryptodev_capabilities 
> zsda_crypto_sym_capabilities[] = {
> + {/* SHA1 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {.xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA1,
> + .block_size = 64,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 20, .max = 20, 
> .increment = 2},
> + .iv_size = {0} },
> + }   },
> + }
> + },
> + {/* SHA224 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA224,
> + .block_size = 64,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 28, .max = 28, 
> .increment = 0},
> + .iv_size = {0} },
> + }   },
> + }
> + },
> + {/* SHA256 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA256,
> + .block_size = 64,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 32, .max = 32, 
> .increment = 0},
> + .iv_size = {0} },
> + } },
> + }
> + },
> + {/* SHA384 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA384,
> + .block_size = 128,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 48, .max = 48, 
> .increment = 0},
> + .iv_size = {0} },
> + } },
> + }
> + },
> + {/* SHA512 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA512,
> + .block_size = 128,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 64, .max = 64, 
> .increment = 0},
> + .iv_size = {0} },
> + } },
> + }
> + },
> + {/* SM3 */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + { .auth = {
> + .algo = RTE_CRYPTO_AUTH_SM3,
> + .block_size = 64,
> + .key_size = {.min = 0, .max = 0, .increment = 
> 0},
> + .digest_size = {.min = 32, .max = 32, 
> .increment = 0},
> + .iv_size = {0} },
> + } },
> + }
> + },
> + {/* AES XTS */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
> + { .cipher = {
> + .algo = RTE_CRYPTO_CIPHER_AES_XTS,
> + .block_size = 16,
> + .key_size = {.min = 16, .max = 32, .increment = 
> 16},
> + .iv_size = {.min = 16, .max = 16, .increment = 
> 0} },
> + } },
> + }
> + },
> + {/* SM4 XTS */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + { .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
> + { .cipher = {
> + .algo = RTE_CRYPTO_CIPHER_SM4_XTS,
> +

Re: [PATCH v2 3/3] net/tap: remove unnecessary checks in configure

On 10/12/2024 3:17 AM, Stephen Hemminger wrote:
> The ethdev layer already validates that the number of requested
> queues is less than the reported max queues.
> 
> Signed-off-by: Stephen Hemminger 
>

Acked-by: Ferruh Yigit 

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

Re: [PATCH v6 4/4] usertools/dpdk-devbind: print NUMA node

On Thu, 22 Aug 2024 11:38:26 +0100
Anatoly Burakov  wrote:

> Currently, devbind does not print out any NUMA information, which makes
> figuring out which NUMA node device belongs to not trivial. Add printouts
> for NUMA information if NUMA support is enabled on the system.
> 
> Signed-off-by: Anatoly Burakov 
> Acked-by: Robin Jarry 
> ---

Acked-by: Stephen Hemminger

RE: [EXTERNAL] Re: [PATCH v4 3/5] graph: add stats for node specific errors

2024-10-12 Thread Pavan Nikhilesh Bhagavatula

> > From: Robin Jarry 
> > Sent: Friday, October 11, 2024 3:24 PM
> > To: Pavan Nikhilesh Bhagavatula ; Jerin Jacob
> > ; Nithin Kumar Dabilpuram
> > ; Kiran Kumar Kokkilagadda
> > ; zhirun@intel.com; Zhirun Yan
> > 
> > Cc: dev@dpdk.org
> > Subject: [EXTERNAL] Re: [PATCH v4 3/5] graph: add stats for node specific
> > errors
> >
> > Hi Pavan, , Aug 16, 2024 at 17: 09: > From: Pavan Nikhilesh
> >  > > Add support for retrieving/printing stats
> > for node specific > errors using rte_graph_cluster_stats_get(). > > 
> > Signed-off-
> > by: Pavan
> >
> > Hi Pavan,
> >
> > , Aug 16, 2024 at 17:09:
> > > From: Pavan Nikhilesh 
> > >
> > > Add support for retrieving/printing stats for node specific
> > > errors using rte_graph_cluster_stats_get().
> > >
> > > Signed-off-by: Pavan Nikhilesh 
> > > ---
> >
> > [snip]
> >
> > > diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
> > > index b28143d737..12b6461cf5 100644
> > > --- a/lib/graph/rte_graph.h
> > > +++ b/lib/graph/rte_graph.h
> > > @@ -223,6 +223,10 @@ struct __rte_cache_aligned
> > rte_graph_cluster_node_stats {
> > >
> > >   uint64_t realloc_count; /**< Realloc count. */
> > >
> > > + uint8_t node_error_cntrs;  /**< Number of
> > Node error counters. */
> > > + char (*node_error_desc)[RTE_NODE_ERROR_DESC_SIZE]; /**< Names
> > of the Node error counters. */
> >
> > Why do you need the parentheses here?

The parenthesis signify that it's a pointer to array that has fixed size 
characters.
If we remove the parenthesis, compiler will treat it as array of pointers to 
char.

../lib/graph/graph_stats.c: In function ‘stats_mem_populate’:
../lib/graph/graph_stats.c:274:42: error: assignment to expression with array 
type
  274 | cluster->stat.error_desc = rte_zmalloc_socket(
  |  ^
../lib/graph/graph_stats.c:277:46: error: the comparison will always evaluate 
as ‘false’ for the address of ‘error_desc’ will never be NULL [-Werror=address]
  277 | if (cluster->stat.error_desc == NULL) {
  |  ^~
In file included from ../lib/graph/graph_private.h:17,
 from ../lib/graph/graph_stats.c:13:
../lib/graph/rte_graph.h:227:15: note: ‘error_desc’ declared here
  227 | char *error_desc[RTE_NODE_ERROR_DESC_SIZE]; /**< Names of the 
Node error counters. */
  |   ^~
cc1: all warnings being treated as errors

> >
> > > + uint64_t *node_error_count;/**< Total error
> > count per each error. */
> >
> > The node_ prefix is redundant here. Can you use something shorter?
> >
> >uint8_t errors_num; /**< Number of Node error counters. */
> >char (*errors_desc)[RTE_NODE_ERROR_DESC_SIZE];
> >uint64_t *errors_value;
> >
> 
> I will shrink them in the next version.
> 
> > Thanks!

Re: [PATCH v3 0/5] power: refactor power management library

On Tue, 8 Oct 2024 17:43:03 +
Sivaprasad Tummala  wrote:

> This patchset refactors the power management library, addressing both
> core and uncore power management. The primary changes involve the
> creation of dedicated directories for each driver within
> 'drivers/power/core/*' and 'drivers/power/uncore/*'.
> 
> This refactor significantly improves code organization, enhances
> clarity, and boosts maintainability. It lays the foundation for more
> focused development on individual drivers and facilitates seamless
> integration of future enhancements, particularly the AMD uncore driver.
> 
> Furthermore, this effort aims to streamline code maintenance by
> consolidating common functions for cpufreq and cppc across various
> core drivers, thus reducing code duplication.
> 
> Sivaprasad Tummala (5):
>   power: refactor core power management library
>   power: refactor uncore power management library
>   test/power: removed function pointer validations
>   power/amd_uncore: uncore support for AMD EPYC processors
>   maintainers: update for drivers/power

Looks good but several build failures.
It looks like the new internal function to get power ops is not
in version.map.

Also while looking, if I use IWYU it shows that errno.h and rte_errno.h
are included but never used.

Re: [PATCH] net/bonding: add user callback for bond xmit policy

On Thu, 15 Aug 2024 14:10:14 +0200
 wrote:

> diff --git a/drivers/net/bonding/rte_eth_bond.h 
> b/drivers/net/bonding/rte_eth_bond.h
> index f10165f2c6..66bc41097a 100644
> --- a/drivers/net/bonding/rte_eth_bond.h
> +++ b/drivers/net/bonding/rte_eth_bond.h
> @@ -91,6 +91,11 @@ extern "C" {
>  /**< Layer 2+3 (Ethernet MAC + IP Addresses) transmit load balancing */
>  #define BALANCE_XMIT_POLICY_LAYER34  (2)
>  /**< Layer 3+4 (IP Addresses + UDP Ports) transmit load balancing */
> +#define BALANCE_XMIT_POLICY_USER (3)
> +/**< User callback function to transmit load balancing */
> +
> +typedef void (*burst_xmit_hash_t)(struct rte_mbuf **buf, uint16_t nb_pkts,
> + uint16_t slave_count, uint16_t *slaves);

Change wording.

DPDK has replaced use of the non-inclusive term slave in bond driver.

Re: [PATCH v4 0/5] Stage-Ordered API and other extensions for ring library

On Tue, 17 Sep 2024 13:09:41 +0100
Konstantin Ananyev  wrote:

> From: Konstantin Ananyev 
> 
> v2 -> v3:
> - fix compilation/doxygen complains (attempt #2)
> - updated release notes
> 
> v2 -> v3:
> - fix compilation/doxygen complains
> - dropped patch:
>   "examples/l3fwd: make ACL work in pipeline and eventdev modes": [2]
>   As was mentioned in the patch desctiption it was way too big,
>   controversial and incomplete. If the community is ok to introduce
>   pipeline model into the l3fwd, then it is propbably worth to be
>   a separate patch series.
> 
> v1 -> v2:
> - rename 'elmst/objst' to 'meta' (Morten)
> - introduce new data-path APIs set: one with both meta{} and objs[],
>   second with just objs[] (Morten)
> - split data-path APIs into burst/bulk flavours (same as rte_ring)
> - added dump function for te_soring and improved dump() for rte_ring.
> - dropped patch:
>   " ring: minimize reads of the counterpart cache-line"
>   - no performance gain observed
>   - actually it does change behavior of conventional rte_ring
> enqueue/dequeue APIs -
> it could return available/free less then actually exist in the ring.
> As in some other libs we reliy on that information - it will
> introduce problems.
> 
> The main aim of these series is to extend ring library with
> new API that allows user to create/use Staged-Ordered-Ring (SORING)
> abstraction. In addition to that there are few other patches that serve
> different purposes:
> - first two patches are just code reordering to de-duplicate
>   and generalize existing rte_ring code.
> - patch #3 extends rte_ring_dump() to correctly print head/tail metadata
>   for different sync modes.
> - next two patches introduce SORING API into the ring library and
>   provide UT for it.
> 
> SORING overview
> ===
> Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues
> with multiple processing 'stages'. It is based on conventional DPDK
> rte_ring, re-uses many of its concepts, and even substantial part of
> its code.
> It can be viewed as an 'extension' of rte_ring functionality.
> In particular, main SORING properties:
> - circular ring buffer with fixed size objects
> - producer, consumer plus multiple processing stages in between.
> - allows to split objects processing into multiple stages.
> - objects remain in the same ring while moving from one stage to the other,
>   initial order is preserved, no extra copying needed.
> - preserves the ingress order of objects within the queue across multiple
>   stages
> - each stage (and producer/consumer) can be served by single and/or
>   multiple threads.
> 
> - number of stages, size and number of objects in the ring are
>  configurable at ring initialization time.
> 
> Data-path API provides four main operations:
> - enqueue/dequeue works in the same manner as for conventional rte_ring,
>   all rte_ring synchronization types are supported.
> - acquire/release - for each stage there is an acquire (start) and
>   release (finish) operation. After some objects are 'acquired' -
>   given thread can safely assume that it has exclusive ownership of
>   these objects till it will invoke 'release' for them.
>   After 'release', objects can be 'acquired' by next stage and/or dequeued
>   by the consumer (in case of last stage).
> 
> Expected use-case: applications that uses pipeline model
> (probably with multiple stages) for packet processing, when preserving
> incoming packet order is important.
> 
> The concept of ‘ring with stages’ is similar to DPDK OPDL eventdev PMD [1],
> but the internals are different.
> In particular, SORING maintains internal array of 'states' for each element
> in the ring that is  shared by all threads/processes that access the ring.
> That allows 'release' to avoid excessive waits on the tail value and helps
> to improve performancei and scalability.
> In terms of performance, with our measurements rte_soring and
> conventional rte_ring provide nearly identical numbers.
> As an example, on our SUT: Intel ICX CPU @ 2.00GHz,
> l3fwd (--lookup=acl) in pipeline mode [2] both
> rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same
> number of worker lcores.
> 
> [1] 
> https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China2017-Ma-OPDL.pdf
> [2] 
> https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.anan...@yandex.ru/
> 
> Eimear Morrissey (1):
>   ring: make dump function more verbose
> 
> Konstantin Ananyev (4):
>   ring: common functions for 'move head' ops
>   ring: make copying functions generic
>   ring/soring: introduce Staged Ordered Ring
>   app/test: add unit tests for soring API
> 
>  .mailmap   |   1 +
>  app/test/meson.build   |   3 +
>  app/test/test_ring_stress_impl.h   |   1 +
>  app/test/test_soring.c | 442 +
>  app/test/test_soring_mt_stress.c   |  40 ++
>  app/test/test_soring_stress.c  |  48

Re: [PATCH v2 0/3] net/tap: queue limit patches

On 10/12/2024 3:17 AM, Stephen Hemminger wrote:
> Some patches related to recent queue limit changes.
> 
> v2 - up the limit to maximum Linux can support
>  dont use static_assert here
>  get rid of unreachable checks in configure
> 
> Stephen Hemminger (3):
>   net/tap: handle increase in mp_max_fds
>   net/tap: increase the maximum allowable queues
>   net/tap: remove unnecessary checks in configure
> 

Hi Stephen,

Previous version already merged, but I am checking the difference in v2.

Patch 1/3 is identical.
Patch 2/3, I prefer the v1 version, that increases the queue limit to
64, instead of 253.

v1 patch 3/3 static assert seems gone, it seems because of the loongarch
build, but can we please root cause why it failed, and can the failure
be a test environment issue?

v2 patch 3/3 looks good, it can be merged separately.

Re: [PATCH v2] ethdev: verify queue ID when Tx done cleanup

On 10/12/2024 10:14 AM, Jie Hai wrote:
> From: Chengwen Feng 
> 
> Verify queue_id for rte_eth_tx_done_cleanup API.
> 
> Fixes: 44a718c457b5 ("ethdev: add API to free consumed buffers in Tx ring")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Chengwen Feng 
>

Reviewed-by: Ferruh Yigit 

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

[RESEND 2/2] dmadev: clean code for verify parameter

From: Chengwen Feng 

Make sure to verify the 'dev_id' parameter before using them.
Note: there is no actual problem with the current code, but it is
recommended to clean it up.

Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
---
 lib/dmadev/rte_dmadev.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 60c3d8ebf68e..4ba3b9380c5f 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -436,11 +436,12 @@ rte_dma_count_avail(void)
 int
 rte_dma_info_get(int16_t dev_id, struct rte_dma_info *dev_info)
 {
-   const struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   const struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id) || dev_info == NULL)
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (*dev->dev_ops->dev_info_get == NULL)
return -ENOTSUP;
@@ -462,12 +463,13 @@ rte_dma_info_get(int16_t dev_id, struct rte_dma_info 
*dev_info)
 int
 rte_dma_configure(int16_t dev_id, const struct rte_dma_conf *dev_conf)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
struct rte_dma_info dev_info;
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id) || dev_conf == NULL)
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (dev->data->dev_started != 0) {
RTE_DMA_LOG(ERR,
@@ -513,11 +515,12 @@ rte_dma_configure(int16_t dev_id, const struct 
rte_dma_conf *dev_conf)
 int
 rte_dma_start(int16_t dev_id)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (dev->data->dev_conf.nb_vchans == 0) {
RTE_DMA_LOG(ERR, "Device %d must be configured first", dev_id);
@@ -545,11 +548,12 @@ rte_dma_start(int16_t dev_id)
 int
 rte_dma_stop(int16_t dev_id)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (dev->data->dev_started == 0) {
RTE_DMA_LOG(WARNING, "Device %d already stopped", dev_id);
@@ -572,11 +576,12 @@ rte_dma_stop(int16_t dev_id)
 int
 rte_dma_close(int16_t dev_id)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
/* Device must be stopped before it can be closed */
if (dev->data->dev_started == 1) {
@@ -600,13 +605,14 @@ int
 rte_dma_vchan_setup(int16_t dev_id, uint16_t vchan,
const struct rte_dma_vchan_conf *conf)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
struct rte_dma_info dev_info;
bool src_is_dev, dst_is_dev;
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id) || conf == NULL)
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (dev->data->dev_started != 0) {
RTE_DMA_LOG(ERR,
@@ -693,10 +699,11 @@ rte_dma_vchan_setup(int16_t dev_id, uint16_t vchan,
 int
 rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct rte_dma_stats *stats)
 {
-   const struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   const struct rte_dma_dev *dev;
 
if (!rte_dma_is_valid(dev_id) || stats == NULL)
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (vchan >= dev->data->dev_conf.nb_vchans &&
vchan != RTE_DMA_ALL_VCHAN) {
@@ -715,11 +722,12 @@ rte_dma_stats_get(int16_t dev_id, uint16_t vchan, struct 
rte_dma_stats *stats)
 int
 rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   struct rte_dma_dev *dev;
int ret;
 
if (!rte_dma_is_valid(dev_id))
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (vchan >= dev->data->dev_conf.nb_vchans &&
vchan != RTE_DMA_ALL_VCHAN) {
@@ -739,10 +747,11 @@ rte_dma_stats_reset(int16_t dev_id, uint16_t vchan)
 int
 rte_dma_vchan_status(int16_t dev_id, uint16_t vchan, enum rte_dma_vchan_status 
*status)
 {
-   struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
+   struct rte_dma_dev *dev;
 
if (!rte_dma_is_valid(dev_id) || status == NULL)
return -EINVAL;
+   dev = &rte_dma_devices[dev_id];
 
if (vchan >= dev->data->dev_conf.nb_vchans) {
RTE_DMA_LOG(ERR, "Device %u vchan %u out of range", dev_id, 
vchan);
@@ -804,12 +813,13 @@ dma_dump_capability(FILE *f, uint64_t dev_capa)
 int
 rte_dma_dump(int16_t dev_id, FILE *f)

[RESEND 0/2] dmadev: clean code for dmadev

This patch set make clean codes for dmadev.

Chengwen Feng (2):
  dmadev: fix potential null pointer access
  dmadev: clean code for verify parameter

 lib/dmadev/rte_dmadev.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

-- 
2.22.0

[RESEND 1/2] dmadev: fix potential null pointer access

From: Chengwen Feng 

When rte_dma_vchan_status(dev_id, vchan, NULL) is called, a null pointer
access is triggered.
This patch adds the null pointer checker.

Fixes: 5e0f85912754 ("dmadev: add channel status check for testing use")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
---
 lib/dmadev/rte_dmadev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 845727210fab..60c3d8ebf68e 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -741,7 +741,7 @@ rte_dma_vchan_status(int16_t dev_id, uint16_t vchan, enum 
rte_dma_vchan_status *
 {
struct rte_dma_dev *dev = &rte_dma_devices[dev_id];
 
-   if (!rte_dma_is_valid(dev_id))
+   if (!rte_dma_is_valid(dev_id) || status == NULL)
return -EINVAL;
 
if (vchan >= dev->data->dev_conf.nb_vchans) {
-- 
2.22.0

[RESEND] net/hns3: verify reset type from firmware

From: Chengwen Feng 

Verify reset-type which get from firmware.

Fixes: 1c1eb759e9d7 ("net/hns3: support RAS process in Kunpeng 930")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
---
 drivers/net/hns3/hns3_intr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/hns3/hns3_intr.c b/drivers/net/hns3/hns3_intr.c
index f7162ee7bc5f..2de2b86b0297 100644
--- a/drivers/net/hns3/hns3_intr.c
+++ b/drivers/net/hns3/hns3_intr.c
@@ -2252,6 +2252,12 @@ hns3_handle_module_error_data(struct hns3_hw *hw, 
uint32_t *buf,
sum_err_info = (struct hns3_sum_err_info *)&buf[offset++];
mod_num = sum_err_info->mod_num;
reset_type = sum_err_info->reset_type;
+
+   if (reset_type >= HNS3_MAX_RESET) {
+   hns3_err(hw, "invalid reset type = %u", reset_type);
+   return;
+   }
+
if (reset_type && reset_type != HNS3_NONE_RESET)
hns3_atomic_set_bit(reset_type, &hw->reset.request);
 
-- 
2.22.0

[PATCH v2] ethdev: verify queue ID when Tx done cleanup

From: Chengwen Feng 

Verify queue_id for rte_eth_tx_done_cleanup API.

Fixes: 44a718c457b5 ("ethdev: add API to free consumed buffers in Tx ring")
Cc: sta...@dpdk.org

Signed-off-by: Chengwen Feng 
---
v2: make the check under RTE_ETHDEV_DEBUG_TX.
---
 lib/ethdev/rte_ethdev.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 12f42f1d68a9..6413c54e3b39 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -2910,6 +2910,12 @@ rte_eth_tx_done_cleanup(uint16_t port_id, uint16_t 
queue_id, uint32_t free_cnt)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
 
+#ifdef RTE_ETHDEV_DEBUG_TX
+   ret = eth_dev_validate_tx_queue(dev, queue_id);
+   if (ret != 0)
+   return ret;
+#endif
+
if (*dev->dev_ops->tx_done_cleanup == NULL)
return -ENOTSUP;
 
-- 
2.22.0

Re: [PATCH 0/4] clean code for dmadev and hns3


On 2024/9/5 14:46, Jie Hai wrote:
The patch set will be seperate into 3 part and resend, please see

patch[1/4]
https://patches.dpdk.org/project/dpdk/patch/20241012091437.21382-1-haij...@huawei.com/

patch[2/4]
https://patches.dpdk.org/project/dpdk/patch/20241012091457.21554-1-haij...@huawei.com/

patch[3/4][4/4]
https://patches.dpdk.org/project/dpdk/cover/20241012091735.24012-1-haij...@huawei.com/


This patch set make clean codes.

Chengwen Feng (4):
   ethdev: verify queue ID when Tx done cleanup
   net/hns3: verify reset type from firmware
   dmadev: fix potential null pointer access
   dmadev: clean code for verify parameter

  drivers/net/hns3/hns3_intr.c |  6 ++
  lib/dmadev/rte_dmadev.c  | 32 +---
  lib/ethdev/rte_ethdev.c  |  4 
  3 files changed, 31 insertions(+), 11 deletions(-)

[PATCH] examples/l3fwd: add option to set RX burst size