ABI - search results

DPDK patches and discussions
 help / color / mirror / Atom feed

Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download:

* [RFC] Fix cryptodev socket id for devices on unknown NUMA node
@ 2023-01-17 10:16  3% Didier Pallard
  0 siblings, 0 replies; 200+ results
From: Didier Pallard @ 2023-01-17 10:16 UTC (permalink / raw)
  To: Akhil Goyal, Fan Zhang, Olivier Matz; +Cc: dev

Since DPDK 22.11 and below commit:
https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183ed0ae2
rte_cryptodev_socket_id() could return an incorrect value of 255.
Problem has been seen during configuration of the qat device
on an Atom C3000 architecture. On this arch, PCI is not depending on
any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Due to incorrect cast to uint8_t, this value is stored as 255
in cryptodev structure and returned as such by rte_cryptodev_socket_id()
function.

Below patch proposes one way to fix the issue: casting to a signed int8_t
instead of the uint8_t. (it could also be casted to an int, that is the
usual type for numa_node, but this may break the ABI). This makes the
SOCKET_ID_ANY being propagated up to the user.
Another solution could be to always store a valid numa_node in this field
instead of just copying the numa_node field of the device, but this
requires to fix most crypto PMDs, that are currently just copying the
device value.

What is the preferred solution?

---
cryptodev: fix numa_node type

Since below commit, numa_node can be set to SOCKET_ID_ANY.
Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
is converted to 255, causing rte_cryptodev_socket_id to return
an incorrect value.

Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by default")
Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
---
 lib/cryptodev/cryptodev_pmd.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0020102eb7db..db4745d620f4 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
 struct rte_cryptodev_data {
 	/** Device ID for this instance */
 	uint8_t dev_id;
-	/** Socket ID where memory is allocated */
-	uint8_t socket_id;
+	/** Socket ID of the device */
+	int8_t socket_id;
 	/** Unique identifier name */
 	char name[RTE_CRYPTODEV_NAME_MAX_LEN];

-- 
2.30.2

^ permalink raw reply	[relevance 3%]

* [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev
  @ 2023-01-16 17:37  3%   ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 17:37 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz

Validate device operation when a device is stopped or restarted.

The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
possibilities in the test case.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
 			|| do_multi_copies(dev_id, vchan, 0, 0, 1);
 }
 
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+	/* device is already started on input, should be (re)started on output */
+
+	uint16_t id = 0;
+	enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+	/* - test stopping a device works ok,
+	 * - then do a start-stop without doing a copy
+	 * - finally restart the device
+	 * checking for errors at each stage, and validating we can still copy at the end.
+	 */
+	if (rte_dma_stop(dev_id) < 0)
+		ERR_RETURN("Error stopping device\n");
+
+	if (rte_dma_start(dev_id) < 0)
+		ERR_RETURN("Error restarting device\n");
+	if (rte_dma_stop(dev_id) < 0)
+		ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+	if (rte_dma_start(dev_id) < 0)
+		ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+	/* before doing a copy, we need to know what the next id will be it should
+	 * either be:
+	 * - the last completed job before start if driver does not reset id on stop
+	 * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+	 */
+	if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+		ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+	id += 1; /* id_count is next job id */
+	if (id != id_count && id != 0)
+		ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+				id, id_count);
+
+	id_count = id;
+	if (test_single_copy(dev_id, vchan) < 0)
+		ERR_RETURN("Error performing copy after device restart\n");
+	return 0;
+}
+
 /* Failure handling test cases - global macros and variables for those tests*/
 #define COMP_BURST_SZ	16
 #define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
 	if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
 		goto err;
 
+	/* run tests stopping/starting devices and check jobs still work after restart */
+	if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+		goto err;
+
 	/* run some burst capacity tests */
 	if (rte_dma_burst_capacity(dev_id, vchan) < 64)
 		printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev
  @ 2023-01-16 15:37  3% ` Bruce Richardson
    1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 15:37 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz

Validate device operation when a device is stopped or restarted.

The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
posibilities in the test case.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
 			|| do_multi_copies(dev_id, vchan, 0, 0, 1);
 }
 
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+	/* device is already started on input, should be (re)started on output */
+
+	uint16_t id = 0;
+	enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+	/* - test stopping a device works ok,
+	 * - then do a start-stop without doing a copy
+	 * - finally restart the device
+	 * checking for errors at each stage, and validating we can still copy at the end.
+	 */
+	if (rte_dma_stop(dev_id) < 0)
+		ERR_RETURN("Error stopping device\n");
+
+	if (rte_dma_start(dev_id) < 0)
+		ERR_RETURN("Error restarting device\n");
+	if (rte_dma_stop(dev_id) < 0)
+		ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+	if (rte_dma_start(dev_id) < 0)
+		ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+	/* before doing a copy, we need to know what the next id will be it should
+	 * either be:
+	 * - the last completed job before start if driver does not reset id on stop
+	 * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+	 */
+	if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+		ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+	id += 1; /* id_count is next job id */
+	if (id != id_count && id != 0)
+		ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+				id, id_count);
+
+	id_count = id;
+	if (test_single_copy(dev_id, vchan) < 0)
+		ERR_RETURN("Error performing copy after device restart\n");
+	return 0;
+}
+
 /* Failure handling test cases - global macros and variables for those tests*/
 #define COMP_BURST_SZ	16
 #define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
 	if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
 		goto err;
 
+	/* run tests stopping/starting devices and check jobs still work after restart */
+	if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+		goto err;
+
 	/* run some burst capacity tests */
 	if (rte_dma_burst_capacity(dev_id, vchan) < 64)
 		printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
  2022-12-19  7:06  3% ` [PATCH V8 " Huisong Li
@ 2023-01-16 12:06  0%   ` lihuisong (C)
  0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-16 12:06 UTC (permalink / raw)
  To: dev, Ferruh Yigit, Andrew Rybchenko
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen

Hi Ferruh and Andrew,

This patch series optimizes some codes and bug.
Can you take a look at this patch series?
If there are no other questions, can it be merged?

Best,
Huisong

在 2022/12/19 15:06, Huisong Li 写道:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation. This patch series uses 'u64' functions to
> do this.
>
> In addition, this patch series introduces two APIs to store unsigned
> integer values as hexadecimal encoded strings in telemetry library.
>
> ---
>   -v8: fix the coding style in patch 7/8
>   -v7: replace sprintf with snprintf in patch 6/8
>   -v6: fix code alignment to keep in line with codes in the file
>   -v5:
>      - drop a refactor patch.
>      - no limit the bit width for xxx_uint_hex API.
>   -v4:
>      - remove 'u32' value type.merg
>      - add padding zero for hexadecimal value
>   -v3: fix a misspelling mistake in commit log.
>   -v2:
>      - fix ABI break warning.
>      - introduce two APIs to store u32 and u64 values as hexadecimal
>        encoded strings.
>
> Huisong Li (8):
>    telemetry: move to header to controllable range
>    ethdev: fix possible data truncation and conversion error
>    mempool: fix possible data truncation and conversion error
>    cryptodev: fix possible data conversion error
>    mem: possible data truncation and conversion error
>    telemetry: support adding integer value as hexadecimal
>    test: add test cases for adding hex integer value API
>    ethdev: display capability values in hexadecimal format
>
>   app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
>   lib/cryptodev/rte_cryptodev.c      |   2 +-
>   lib/eal/common/eal_common_memory.c |  10 +-
>   lib/ethdev/rte_ethdev.c            |  19 ++--
>   lib/mempool/rte_mempool.c          |  24 ++---
>   lib/telemetry/rte_telemetry.h      |  52 +++++++++-
>   lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
>   lib/telemetry/version.map          |   9 ++
>   8 files changed, 309 insertions(+), 30 deletions(-)
>

^ permalink raw reply	[relevance 0%]

* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-26 16:44  4%                     ` Ori Kam
@ 2023-01-15 22:46  0%                       ` Thomas Monjalon
  0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-15 22:46 UTC (permalink / raw)
  To: Rongwei Liu, Jerin Jacob, Ori Kam
  Cc: dev, Matan Azrad, Slava Ovsiienko, Ferruh Yigit,
	Andrew Rybchenko, dev, Raslan Darawsheh, maxime.coquelin

26/12/2022 17:44, Ori Kam:
> From: Rongwei Liu <rongweil@nvidia.com>
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu wrote:
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote:
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote:
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu wrote:
> > > > > > > > > >
> > > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > > versions
> > > > > > > > >
> > > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > > support
> > > > > this?
> > > > > > > > >
> > > > > > > > There is a new member which was introduced into
> > > > > > > > rte_eth_dev_info but it
> > > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > > >
> > > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > > different ethdev structure and rte_flow structures across
> > > > > > > different DPDK
> > > > > ABI versions.
> > > > > > >
> > > > > > Besides this, there is no other ABI changes dependency.
> > > > > >
> > > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > > >
> > > > > OK. That's a relief. I understand the use case now.
> > > > >
> > > > > Why not simply use standard DPDK multiprocess model then.
> > > > > Primary process act as server for slow path API. Secondary process
> > > > > can come and go(aka can be updated at runtime) and use as client to
> > > > > update rules via primary-secondray communication mechanism.
> > > > >
> > > > Just image if process A and process B have ABI breakage like different
> > > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > > How can we quickly accommodate primary/secondary to be ABI
> > compatible
> > > across different versions?
> > > > It will be very huge effort and difficult to implement, at least in my
> > opinion.
> > > > What do you think?
> > >
> > > Yes. it difficult what ever approach we take, On other hand, ethdev
> > subsystem
> > > has other components like rte_tm and other offload etc, We can not simply
> > > have rte_eth_process_set_active() and things magical works across
> > different
> > > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > > another HW piece in NIC card for doing the metering but set by flow API.
> > > IMO, Customer can simply use standard multiprocess model if version are
> > > compatible without any special intelligence in application.
> > > Otherwise they can reload and start the application again or have special
> > > intelligence in application to cater the specific area of API they need to
> > > leverage based on server and client DPDK versions.
> > 
> > Thanks for the message.
> > IMO, we are trying to eliminate the version/ABI dependency with this new
> > added API.
> > For example, if meter action is in the flow rules:
> > 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> > 2. Process B starts with "rte_eth_process_set_active(false, flags)"
> > 
> > Just give Nvidia' hardware as example (other NIC vendors may not care if
> > group 0 or not)
> > If the process A' rules are in group 0, users should set them one by one to
> > process B.
> > Then either flush process A' rules or quit process A, then process B calls with
> > "rte_eth_process_set_active(true, flags)"
> > All is set.
> > It will avoid complex operations with client/server model and avoid user mis-
> > operation too.
> > We should avoid reload as much as possible since reloading is very time
> > consuming and may take up to few seconds.
> > In this time slot, there is no application to handle the traffic, and everything is
> > lost.
> > For end user especially cloud service providers, they are sensitive to the
> > traffic down time.
> 
> From my viewpoint the upgrade has nothing to do with DPDK as a library,
> the upgrade may be because of application upgrade.
> Unless I'm missing something, this API is not meant for API/ABI it is created
> to allow minimum downtime when doing upgrade of the application.
> Unless I'm missing something critical, since the upgrade in any case is not
> only for the DPDK but the entire app, there isn't any ABI/API issue.

Yes we can consider the case of an application upgrade with the same DPDK.
The patch needs to be reworded in this more realistic direction I think.
We can also improve the usage explanations.

That said, another high level question is about the scope of the feature.
In this patch, only ethdev is targetted.
Do you think we need the same migration mechanism in other classes
like vDPA, crypto, etc?




^ permalink raw reply	[relevance 0%]

* Re: [RFC] Remove Kernel Network Interface (KNI)
  @ 2023-01-14 22:21  3%         ` Tyler Retzlaff
  0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2023-01-14 22:21 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Thomas Monjalon, dev, Cristian Dumitrescu, Bruce Richardson,
	Anatoly Burakov

On Fri, Jan 13, 2023 at 03:25:30PM -0800, Stephen Hemminger wrote:
> On Fri, 13 Jan 2023 19:34:24 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 13/01/2023 18:13, Stephen Hemminger:
> > > On Fri, 13 Jan 2023 09:12:16 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >   
> > > > 13/01/2023 06:03, Stephen Hemminger:  
> > > > > The Linux special network driver for kernel networking has been
> > > > > a long term problem for DPDK. The performance benefits of KNI
> > > > > are available via virtio-user and XDP, and the simpler kernel
> > > > > interface via TAP is also available.
> > > > > 
> > > > > This driver has required lots of effort to keep up with the
> > > > > kernel API changes. And the overall architecture of the driver
> > > > > is fundamentally insecure and has unfixable locking and data
> > > > > race problems. No developer has been willing to do extensive
> > > > > tests or be the maintainer.
> > > > > 
> > > > > In short, the time has come to do some early spring cleaning
> > > > > and remove KNI from DPDK 23.03.    
> > > > 
> > > > In doc/guides/rel_notes/deprecation.rst it is announced
> > > > to be removed in 23.11. Let's keep this RFC for later :)
> > > > 
> > > >   
> > > 
> > > For 23.03 could we add a deprecation log message when library is
> > > used and when kernel module is loaded.  
> > 
> > We already have a message in the lib:
> > 
> > int
> > rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
> > {
> > 	RTE_LOG(WARNING, KNI, "WARNING: KNI is deprecated and will be removed in DPDK 23.11\n");
> > 
> > It is a good idea to add a message in the kernel module loading.
> > 
> > 
> > 
> > 
> 
> No matter how much we tell users, guarantee someone will still miss it and complain :-)

one of the techniques we use is to remove the headers in advance of
removing the ABI. the warning becomes a lot more clear when you can't
compile anymore but your existing binaries continue to run.

^ permalink raw reply	[relevance 3%]

* RE: [PATCH v3 0/9] Standardize telemetry int types
  2023-01-12 17:41  4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
  2023-01-12 17:41  3%   ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
  2023-01-12 17:41  3%   ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2023-01-13 16:39  0%   ` Power, Ciara
  2 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2023-01-13 16:39 UTC (permalink / raw)
  To: Richardson, Bruce, dev; +Cc: Richardson, Bruce

Hi Bruce,

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday 12 January 2023 17:41
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [PATCH v3 0/9] Standardize telemetry int types
> 
> Rather than having 64-bit unsigned types and 32-bit signed types supported
> by the telemetry lib, we should support 64-bit values for both types. On the
> naming side, since both are 64-bit, we should no longer call the unsigned
> value u64 - "uint" is better.
> 
> This patchset implements these changes as far as is possible while still
> keeping API and ABI compatibility.
> 
> * Internal structures and functions are updated to use 64-bit ints
> * Internal functions are renamed from u64 to uint
> * Public enum values are renamed from u64 to uint, and a macro is
>   added to ensure that older code still compiles
> * The public add_*_int functions are changed to take a 64-bit value
>   rather than a 32-bit one. Since this would be an ABI break, we
>   use function versioning to ensure older code still calls into
>   a wrapper function which takes a 32-bit value.
> 
> The patchset also contains a couple of other small cleanups to the telemetry
> code that were seen in passing when making these changes - removing RTE_
> prefix on internal enums, and simplifying the init of the the array of data
> types.
> 
> NOTE: the renaming of the u64 functions to uint is split across 3 patches in
> this set - patches 4,5 and 6. This is to make it easier to review and to avoid
> warnings about new functions not being marked initially as experimental.
> Some/all of these 3 can be combined on merge if so desired.
> 
> V3:
> - fix build issues due to missing a driver code change
> - fix spelling issue flagged by checkpatch
> 
> V2:
> - added additional patches to replace the old function calls within DPDK
>   code, something missed in RFC version
> - added new patch to make the renamed/new functions immediately public
>   allowing us to mark the original named versions as deprecated
> - re-ordered patches within the sit, so the extra cleanup changes come
>   first
> 
> Bruce Richardson (9):
>   telemetry: remove RTE prefix from internal enum values
>   telemetry: make array initialization more robust
>   telemetry: rename unsigned 64-bit enum value to uint
>   telemetry: add uint type as alias for u64
>   global: rename telemetry functions to newer versions
>   telemetry: mark old names of renamed fns as deprecated
>   telemetry: update json functions to use int/uint in names
>   telemetry: make internal int representation 64-bits
>   telemetry: change public API to use 64-bit signed values
> 
>  app/test/test_telemetry_data.c               | 22 ++---
>  app/test/test_telemetry_json.c               |  9 +-
>  doc/guides/rel_notes/deprecation.rst         |  5 ++
>  drivers/common/cnxk/roc_platform.h           |  4 +-
>  drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
>  drivers/net/cnxk/cnxk_ethdev_telemetry.c     |  6 +-
>  examples/ipsec-secgw/ipsec-secgw.c           | 72 +++++++--------
>  examples/l3fwd-power/main.c                  |  4 +-
>  lib/cryptodev/rte_cryptodev.c                |  6 +-
>  lib/dmadev/rte_dmadev.c                      |  2 +-
>  lib/eal/common/eal_common_memory.c           | 19 ++--
>  lib/ethdev/rte_ethdev.c                      | 12 +--
>  lib/ethdev/sff_telemetry.c                   |  2 +-
>  lib/eventdev/rte_event_eth_rx_adapter.c      | 22 ++---
>  lib/eventdev/rte_event_timer_adapter.c       | 38 ++++----
>  lib/eventdev/rte_eventdev.c                  |  5 +-
>  lib/ipsec/ipsec_telemetry.c                  | 33 +++----
>  lib/rawdev/rte_rawdev.c                      |  4 +-
>  lib/security/rte_security.c                  |  8 +-
>  lib/telemetry/meson.build                    |  1 +
>  lib/telemetry/rte_telemetry.h                | 51 +++++++++--
>  lib/telemetry/telemetry.c                    | 56 ++++++------
>  lib/telemetry/telemetry_data.c               | 95 ++++++++++++++------
>  lib/telemetry/telemetry_data.h               | 24 +++--
>  lib/telemetry/telemetry_json.h               | 16 ++--
>  lib/telemetry/version.map                    |  9 ++
>  26 files changed, 325 insertions(+), 224 deletions(-)
> 
> --
> 2.37.2

Series-Acked-by: Ciara Power <ciara.power@intel.com>


^ permalink raw reply	[relevance 0%]

* Re: trace point symbols
  @ 2023-01-13 11:22  3%         ` Jerin Jacob
  0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-01-13 11:22 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Thomas Monjalon, Ferruh Yigit, jerinj, bruce.richardson, dev,
	Ankur Dwivedi, orika, ferruh.yigit, chas3, humin29, linville,
	ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
	chandu, irusskikh, shepard.siegel, ed.czeck, john.miller,
	ajit.khaparde, somnath.kotur, mczekaj, sthotton, srinivasan,
	hkalra, rahul.lakkireddy, johndale, hyonkim, liudongdong3,
	yisen.zhuang, xuanziyang2, cloud.wangxiaoyun, zhouguoyang,
	simei.su, wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing,
	xiao.w.wang, jingjing.wu, junfeng.guo, rosen.xu, ndabilpuram,
	kirankumark, skori, skoteshwar, lironh, zr, radhac, vburru,
	sedara, matan, viacheslavo, sthemmin, longli, spinler,
	chaoyong.he, niklas.soderlund, hemant.agrawal, sachin.saxena,
	g.singh, apeksha.gupta, sachin.saxena, aboyer, rmody, shshaikh,
	dsinghrawat, andrew.rybchenko, jiawenwu, jianwang, jbehrens,
	maxime.coquelin, chenbo.xia, steven.webster, matt.peters,
	mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
	david.marchand

On Thu, Jan 12, 2023 at 3:13 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 12 January 2023 10.11
> >

> >
> > I would like to see a policy regarding trace symbols.
> > If we decide option 1 is not so useful,
> > then we should not export trace symbols at all and document this
> > policy.
> > Also there are some trace symbols which could be cleaned up.

I can send a patch to remove existing exposed symbols for option 1 in
DPDK repo. But, Is n't  an ABI break? The only downside, I can think
of, is that a few more entries in version.map file.
I don't have a strong option one way, either. Let me know what you think?

If we decided to remove then, In
https://doc.dpdk.org/guides/prog_guide/trace_lib.html, There is NOTE
section as following, I can remove that as well.

--
The RTE_TRACE_POINT_REGISTER defines the placeholder for the
rte_trace_point_t tracepoint object. The user must export a
__<trace_function_name> symbol in the library .map file for this
tracepoint to be used out of the library, in shared builds. For
example, __app_trace_string will be the exported symbol in the above
example.
---

>
> +1 for not exposing trace point symbols at all.
>
> The trace point symbols are only used internally by DPDK, so they should not be part of DPDK's public API.
>
> It might also make it easier for Bruce to move the trace library out of EAL.
>
> I'm not familiar with the CTF format, but I assume that if we don't expose the trace point symbols, the trace points can still be identified when parsing the trace file.

Yes. It won't impact. The only use case for option 1 is to avoid named lookup.

>

^ permalink raw reply	[relevance 3%]

* [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values
  2023-01-12 17:41  4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
  2023-01-12 17:41  3%   ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 17:41  3%   ` Bruce Richardson
  2023-01-13 16:39  0%   ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
  2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power

While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/meson.build      |  1 +
 lib/telemetry/rte_telemetry.h  |  4 ++--
 lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
 lib/telemetry/telemetry_data.h |  6 ++++++
 lib/telemetry/version.map      |  7 +++++++
 5 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
 sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
 headers = files('rte_telemetry.h')
 includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
  *   0 on success, negative errno on error
  */
 int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
 
 /**
  * Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
  *   0 on success, negative errno on error, E2BIG on string truncation of name.
  */
 int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
 
 /**
  * Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
 
+#include <rte_function_versioning.h>
 #include <rte_string_fns.h>
 
 #include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
 {
 	if (d->type != TEL_ARRAY_INT)
 		return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+		int64_t x), rte_tel_data_add_array_int_v24);
+
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
 {
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 	return 0;
 }
 
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 	if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
 		const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
 	} data; /* data container */
 };
 
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
 #endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
 	local: *;
 };
 
+DPDK_24 {
+	global:
+
+	rte_tel_data_add_array_int;
+	rte_tel_data_add_dict_int;
+} DPDK_23;
+
 INTERNAL {
 	rte_telemetry_legacy_register;
 	rte_telemetry_init;
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* [PATCH v3 8/9] telemetry: make internal int representation 64-bits
  2023-01-12 17:41  4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41  3%   ` Bruce Richardson
  2023-01-12 17:41  3%   ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
  2023-01-13 16:39  0%   ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
  2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power

The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
  */
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
-	int ival;
+	int64_t ival;
 	uint64_t uval;
 	struct container container;
 };
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* [PATCH v3 0/9] Standardize telemetry int types
  2022-12-13 18:27  4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
                   ` (3 preceding siblings ...)
  2023-01-12 10:58  4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41  4% ` Bruce Richardson
  2023-01-12 17:41  3%   ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
                     ` (2 more replies)
  4 siblings, 3 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson

Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.

This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.

* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
  added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
  rather than a 32-bit one. Since this would be an ABI break, we
  use function versioning to ensure older code still calls into
  a wrapper function which takes a 32-bit value.

The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.

NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.

V3:
- fix build issues due to missing a driver code change
- fix spelling issue flagged by checkpatch

V2:
- added additional patches to replace the old function calls within DPDK
  code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
  allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
  first

Bruce Richardson (9):
  telemetry: remove RTE prefix from internal enum values
  telemetry: make array initialization more robust
  telemetry: rename unsigned 64-bit enum value to uint
  telemetry: add uint type as alias for u64
  global: rename telemetry functions to newer versions
  telemetry: mark old names of renamed fns as deprecated
  telemetry: update json functions to use int/uint in names
  telemetry: make internal int representation 64-bits
  telemetry: change public API to use 64-bit signed values

 app/test/test_telemetry_data.c               | 22 ++---
 app/test/test_telemetry_json.c               |  9 +-
 doc/guides/rel_notes/deprecation.rst         |  5 ++
 drivers/common/cnxk/roc_platform.h           |  4 +-
 drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
 drivers/net/cnxk/cnxk_ethdev_telemetry.c     |  6 +-
 examples/ipsec-secgw/ipsec-secgw.c           | 72 +++++++--------
 examples/l3fwd-power/main.c                  |  4 +-
 lib/cryptodev/rte_cryptodev.c                |  6 +-
 lib/dmadev/rte_dmadev.c                      |  2 +-
 lib/eal/common/eal_common_memory.c           | 19 ++--
 lib/ethdev/rte_ethdev.c                      | 12 +--
 lib/ethdev/sff_telemetry.c                   |  2 +-
 lib/eventdev/rte_event_eth_rx_adapter.c      | 22 ++---
 lib/eventdev/rte_event_timer_adapter.c       | 38 ++++----
 lib/eventdev/rte_eventdev.c                  |  5 +-
 lib/ipsec/ipsec_telemetry.c                  | 33 +++----
 lib/rawdev/rte_rawdev.c                      |  4 +-
 lib/security/rte_security.c                  |  8 +-
 lib/telemetry/meson.build                    |  1 +
 lib/telemetry/rte_telemetry.h                | 51 +++++++++--
 lib/telemetry/telemetry.c                    | 56 ++++++------
 lib/telemetry/telemetry_data.c               | 95 ++++++++++++++------
 lib/telemetry/telemetry_data.h               | 24 +++--
 lib/telemetry/telemetry_json.h               | 16 ++--
 lib/telemetry/version.map                    |  9 ++
 26 files changed, 325 insertions(+), 224 deletions(-)

--
2.37.2

^ permalink raw reply	[relevance 4%]

* Re: [PATCH v4] devtools: parallelize ABI check
  2023-01-12 10:53  4%   ` David Marchand
@ 2023-01-12 14:14  4%     ` Ferruh Yigit
  0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-12 14:14 UTC (permalink / raw)
  To: David Marchand, Thomas Monjalon; +Cc: dev, bruce.richardson

On 1/12/2023 10:53 AM, David Marchand wrote:
> On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> Generation and comparison of ABI dumps are done on multiple cores
>> thanks to xargs -P0.
>> It can accelerate this long step by 5 in my tests.
>>
>> xargs reports a global error if one of the process has an error.
>>
>> Running a shell function with xargs requires to export it.
>> POSIX shell does not support function export except using an "eval trick".
>> Required variables are also exported.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
>> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
>> index c583eae2fd..31eceb42e6 100755
>> --- a/devtools/check-abi.sh
>> +++ b/devtools/check-abi.sh
>> @@ -34,20 +34,18 @@ else
>>         ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
>>  fi
>>
>> -error=
>> -for dump in $(find $refdir -name "*.dump"); do
>> +export newdir ABIDIFF_OPTIONS
>> +export diff_func='run_diff() {
>> +       dump=$1
>>         name=$(basename $dump)
>>         dump2=$(find $newdir -name $name)
>>         if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
>>                 echo "Error: cannot find $name in $newdir" >&2
>> -               error=1
>> -               continue
>> -       fi
>> +               return 1
>> +       fi;
> 
> No need for ; here.
> This can be fixed when applying (I tested both your patch and with
> this small fix).
> 
> 
>>         abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>>                 abiret=$?
>> -               echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
>> -               error=1
>> -               echo
>> +               echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>>                 if [ $(($abiret & 3)) -ne 0 ]; then
>>                         echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>>                 fi
>> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>>                 if [ $(($abiret & 8)) -ne 0 ]; then
>>                         echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>>                 fi
>> -               echo
>> +               return 1
>>         }
>> -done
>> +}'
>> +
>> +error=
>> +find $refdir -name "*.dump" |
>> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
>> +error=1
>>
>>  [ -z "$error" ] || [ -n "$warnonly" ]
> 
> For the record, on my system, calling this script is ~5 times faster:
> - before
> real    0m5,447s
> user    0m4,497s
> sys    0m0,937s
> 
> - after
> real    0m1,202s
> user    0m10,784s
> sys    0m2,027s
> 
> 
>> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
>> index f15a3b9aaf..61f7510ea1 100755
>> --- a/devtools/gen-abi.sh
>> +++ b/devtools/gen-abi.sh
>> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>>         fi
>>
>>         libname=$(basename $f)
>> -       abidw --out-file $dumpdir/${libname%.so*}.dump $f
>> -done
>> +       echo $dumpdir/${libname%.so*}.dump $f
>> +done |
>> +xargs -n2 -P0 abidw --out-file
>> --
>> 2.39.0
>>
> 
> - before
> real    0m8,237s
> user    0m7,704s
> sys    0m0,504s
> 
> - after
> real    0m2,517s
> user    0m14,145s
> sys    0m0,766s
> 
> 
> Ferruh, I am seeing quite different numbers for running those scripts
> (clearly not of the minute order).
> I switched to testing/building in tmpfs some time ago.
> It requires a good amount of memory (I empirically allocated 40G), but
> maybe worth a try for you?
> 

I run 'test-meson-builds.sh' script directly and yes I am getting
different numbers although there is still improvement, not in scale with
what you are getting, with v4 I have following:

- before
real    10m3.248s
user    39m8.664s
sys     14m52.870s

- after
real    7m49.086s
user    39m59.507s
sys     15m0.598s


What I am running exactly is:
time DPDK_ABI_REF_VERSION=v22.11.1 DPDK_ABI_REF_DIR=/tmp/dpdk-abiref
DPDK_ABI_REF_SRC=.../dpdk-stable/ ./devtools/test-meson-builds.sh

> 
> In any case, this patch lgtm.
> Acked-by: David Marchand <david.marchand@redhat.com>
> 
> 


^ permalink raw reply	[relevance 4%]

* [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values
  2023-01-12 10:58  4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
  2023-01-12 10:59  3%   ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 10:59  3%   ` Bruce Richardson
  1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power

While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/meson.build      |  1 +
 lib/telemetry/rte_telemetry.h  |  4 ++--
 lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
 lib/telemetry/telemetry_data.h |  6 ++++++
 lib/telemetry/version.map      |  7 +++++++
 5 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
 sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
 headers = files('rte_telemetry.h')
 includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
  *   0 on success, negative errno on error
  */
 int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
 
 /**
  * Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
  *   0 on success, negative errno on error, E2BIG on string truncation of name.
  */
 int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
 
 /**
  * Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
 
+#include <rte_function_versioning.h>
 #include <rte_string_fns.h>
 
 #include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
 {
 	if (d->type != TEL_ARRAY_INT)
 		return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+		int64_t x), rte_tel_data_add_array_int_v24);
+
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
 {
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 	return 0;
 }
 
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 	if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
 		const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
 	} data; /* data container */
 };
 
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
 #endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
 	local: *;
 };
 
+DPDK_24 {
+	global:
+
+	rte_tel_data_add_array_int;
+	rte_tel_data_add_dict_int;
+} DPDK_23;
+
 INTERNAL {
 	rte_telemetry_legacy_register;
 	rte_telemetry_init;
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* [PATCH v2 8/9] telemetry: make internal int representation 64-bits
  2023-01-12 10:58  4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 10:59  3%   ` Bruce Richardson
  2023-01-12 10:59  3%   ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
  1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power

The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
 lib/telemetry/telemetry_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
  */
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
-	int ival;
+	int64_t ival;
 	uint64_t uval;
 	struct container container;
 };
-- 
2.37.2


^ permalink raw reply	[relevance 3%]

* [PATCH v2 0/9] Standardize telemetry int types
  2022-12-13 18:27  4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
                   ` (2 preceding siblings ...)
  @ 2023-01-12 10:58  4% ` Bruce Richardson
  2023-01-12 10:59  3%   ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
  2023-01-12 10:59  3%   ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
  2023-01-12 17:41  4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
  4 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:58 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson

Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.

This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.

* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
  added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
  rather than a 32-bit one. Since this would be an ABI break, we
  use function versioning to ensure older code still calls into
  a wrapper function which takes a 32-bit value.

The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.

NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.

V2:
- added additional patches to replace the old function calls within DPDK
  code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
  allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
  first

Bruce Richardson (9):
  telemetry: remove RTE prefix from internal enum values
  telemetry: make array initialization more robust
  telemetry: rename unsigned 64-bit enum value to uint
  telemetry: add uint type as alias for u64
  global: rename telemetry functions to newer versions
  telemetry: mark old names of renamed fns as deprecated
  telemetry: update json functions to use int/uint in names
  telemetry: make internal int representation 64-bits
  telemetry: change public API to use 64-bit signed values

 app/test/test_telemetry_data.c               | 22 ++---
 app/test/test_telemetry_json.c               |  9 +-
 doc/guides/rel_notes/deprecation.rst         |  5 ++
 drivers/common/cnxk/roc_platform.h           |  2 +-
 drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
 drivers/net/cnxk/cnxk_ethdev_telemetry.c     |  6 +-
 examples/ipsec-secgw/ipsec-secgw.c           | 72 +++++++--------
 examples/l3fwd-power/main.c                  |  4 +-
 lib/cryptodev/rte_cryptodev.c                |  6 +-
 lib/dmadev/rte_dmadev.c                      |  2 +-
 lib/eal/common/eal_common_memory.c           | 19 ++--
 lib/ethdev/rte_ethdev.c                      | 12 +--
 lib/ethdev/sff_telemetry.c                   |  2 +-
 lib/eventdev/rte_event_eth_rx_adapter.c      | 22 ++---
 lib/eventdev/rte_event_timer_adapter.c       | 38 ++++----
 lib/eventdev/rte_eventdev.c                  |  5 +-
 lib/ipsec/ipsec_telemetry.c                  | 32 +++----
 lib/rawdev/rte_rawdev.c                      |  4 +-
 lib/security/rte_security.c                  |  8 +-
 lib/telemetry/meson.build                    |  1 +
 lib/telemetry/rte_telemetry.h                | 51 +++++++++--
 lib/telemetry/telemetry.c                    | 56 ++++++------
 lib/telemetry/telemetry_data.c               | 95 ++++++++++++++------
 lib/telemetry/telemetry_data.h               | 24 +++--
 lib/telemetry/telemetry_json.h               | 16 ++--
 lib/telemetry/version.map                    |  9 ++
 26 files changed, 323 insertions(+), 223 deletions(-)

--
2.37.2

^ permalink raw reply	[relevance 4%]

* Re: [PATCH v4] devtools: parallelize ABI check
  2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
@ 2023-01-12 10:53  4%   ` David Marchand
  2023-01-12 14:14  4%     ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-12 10:53 UTC (permalink / raw)
  To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, bruce.richardson

On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it.
> POSIX shell does not support function export except using an "eval trick".
> Required variables are also exported.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..31eceb42e6 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,20 +34,18 @@ else
>         ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
>  fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export newdir ABIDIFF_OPTIONS
> +export diff_func='run_diff() {
> +       dump=$1
>         name=$(basename $dump)
>         dump2=$(find $newdir -name $name)
>         if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
>                 echo "Error: cannot find $name in $newdir" >&2
> -               error=1
> -               continue
> -       fi
> +               return 1
> +       fi;

No need for ; here.
This can be fixed when applying (I tested both your patch and with
this small fix).


>         abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>                 abiret=$?
> -               echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> -               error=1
> -               echo
> +               echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>                 if [ $(($abiret & 3)) -ne 0 ]; then
>                         echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>                 fi
> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>                 if [ $(($abiret & 8)) -ne 0 ]; then
>                         echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>                 fi
> -               echo
> +               return 1
>         }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
> +error=1
>
>  [ -z "$error" ] || [ -n "$warnonly" ]

For the record, on my system, calling this script is ~5 times faster:
- before
real    0m5,447s
user    0m4,497s
sys    0m0,937s

- after
real    0m1,202s
user    0m10,784s
sys    0m2,027s


> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> index f15a3b9aaf..61f7510ea1 100755
> --- a/devtools/gen-abi.sh
> +++ b/devtools/gen-abi.sh
> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>         fi
>
>         libname=$(basename $f)
> -       abidw --out-file $dumpdir/${libname%.so*}.dump $f
> -done
> +       echo $dumpdir/${libname%.so*}.dump $f
> +done |
> +xargs -n2 -P0 abidw --out-file
> --
> 2.39.0
>

- before
real    0m8,237s
user    0m7,704s
sys    0m0,504s

- after
real    0m2,517s
user    0m14,145s
sys    0m0,766s


Ferruh, I am seeing quite different numbers for running those scripts
(clearly not of the minute order).
I switched to testing/building in tmpfs some time ago.
It requires a good amount of memory (I empirically allocated 40G), but
maybe worth a try for you?


In any case, this patch lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>


-- 
David Marchand


^ permalink raw reply	[relevance 4%]

* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
  2023-01-11 10:46  0%         ` Ferruh Yigit
@ 2023-01-12  2:26  0%           ` lihuisong (C)
  0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-12  2:26 UTC (permalink / raw)
  To: Ferruh Yigit, dev, andrew.rybchenko
  Cc: thomas, liudongdong3, huangdaode, fengchengwen


在 2023/1/11 18:46, Ferruh Yigit 写道:
> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>>> This patchset fix some bugs and support attaching and detaching port
>>>>> in primary and secondary.
>>>>>
>>>>> ---
>>>>>    -v4: fix a misspelling.
>>>>>    -v3:
>>>>>      1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>>> modification
>>>>>         for other bus type.
>>>>>      2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>>>         the probelm in patch 2/5.
>>>>>    -v2: resend due to CI unexplained failure.
>>>>>
>>>>> Huisong Li (5):
>>>>>     drivers/bus: restore driver assignment at front of probing
>>>>>     ethdev: fix skip valid port in probing callback
>>>>>     app/testpmd: check the validity of the port
>>>>>     app/testpmd: add attach and detach port for multiple process
>>>>>     app/testpmd: stop forwarding in new or destroy event
>>>>>
>>>> Hi Huisong,
>>>>
>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>> ABI compatibility warnings, is this expected:
>>> This is to be expected. Because we insert a device state,
>>> RTE_ETH_DEV_ALLOCATED,
>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>> We may have to announce it. What do you think?
>> If there is an actual ABI break, it can't go in this release, need to
>> wait LTS release and yes needs deprecation notice in advance.
>>
>> But not all enum value change warnings are real break, need to
>> investigate all warnings one by one.
>> Need to investigate if old application & new dpdk library may cause any
>> unexpected behavior for application.
>>
> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> enum solves the issue, although logically it won't look nice.
Thank you for your suggestion, Ferruh. It seems to be ok. I will fix it.
> Perhaps order can be fixed in next LTS, to have more logical order, but
> not quite sure if order worth the disturbance may cause in application.
Probably not worth it.
>>>> 1 function with some indirect sub-type change:
>>>>
>>>>     [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>>> some indirect sub-type changes:
>>>>       parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>>>         in pointed to type 'const rte_eth_dev':
>>>>           in unqualified underlying type 'struct rte_eth_dev' at
>>>> ethdev_driver.h:50:1:
>>>>             type size hasn't changed
>>>>             1 data member change:
>>>>               type of 'rte_eth_dev_state state' changed:
>>>>                 type size hasn't changed
>>>>                 1 enumerator insertion:
>>>>                   'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>>                 2 enumerator changes:
>>>>                   'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>>                   'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>>> to '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>>     [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>>>       parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>>>         in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>>           type size hasn't changed
>>>>           1 data member change:
>>>>             type of 'rte_eth_dev_state state' changed:
>>>>               type size hasn't changed
>>>>               1 enumerator insertion:
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>>               2 enumerator changes:
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>>     [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>>>       return type changed:
>>>>         in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>>           type size hasn't changed
>>>>           1 data member change:
>>>>             type of 'rte_eth_dev_state state' changed:
>>>>               type size hasn't changed
>>>>               1 enumerator insertion:
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>>               2 enumerator changes:
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>>                 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> ... there are more warnings for same issue ...
>>>>
>>>> .
> .

^ permalink raw reply	[relevance 0%]

* [PATCH v4] devtools: parallelize ABI check
  2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
  2023-01-09  9:34 23% ` [PATCH v2] " Thomas Monjalon
  2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 19:53 33% ` Thomas Monjalon
  2023-01-12 10:53  4%   ` David Marchand
  2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-11 19:53 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, bruce.richardson, Ferruh Yigit

Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.

xargs reports a global error if one of the process has an error.

Running a shell function with xargs requires to export it.
POSIX shell does not support function export except using an "eval trick".
Required variables are also exported.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
	- find dump2 inside the function
	- force bash because of export -f
v3:
	- revert to POSIX sh
	- use POSIX eval instead of export -f (issues on Ubuntu)
v4:
	- export all required variables
	- remove useless stdout echo calls
---
 devtools/check-abi.sh | 23 +++++++++++++----------
 devtools/gen-abi.sh   |  5 +++--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..31eceb42e6 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,20 +34,18 @@ else
 	ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
 fi
 
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export newdir ABIDIFF_OPTIONS
+export diff_func='run_diff() {
+	dump=$1
 	name=$(basename $dump)
 	dump2=$(find $newdir -name $name)
 	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
 		echo "Error: cannot find $name in $newdir" >&2
-		error=1
-		continue
-	fi
+		return 1
+	fi;
 	abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
 		abiret=$?
-		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
-		error=1
-		echo
+		echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
 		if [ $(($abiret & 3)) -ne 0 ]; then
 			echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
 		fi
@@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
 		if [ $(($abiret & 8)) -ne 0 ]; then
 			echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
 		fi
-		echo
+		return 1
 	}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
+error=1
 
 [ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
 	fi
 
 	libname=$(basename $f)
-	abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+	echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
-- 
2.39.0


^ permalink raw reply	[relevance 33%]

* Re: [PATCH v3] devtools: parallelize ABI check
  2023-01-11 14:11  4%   ` David Marchand
@ 2023-01-11 17:04  4%     ` Thomas Monjalon
  0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 17:04 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, Ferruh Yigit

11/01/2023 15:11, David Marchand:
> On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > +find $refdir -name "*.dump" |
> > +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> > +error=1
> 
> Do we need to pass $newdir ?
> Like, for example, ABIDIFF_OPTIONS seems inherited, right?

Actually ABIDIFF_OPTIONS was empty when calling the function.
I'll pass it as well.



^ permalink raw reply	[relevance 4%]

* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
  2022-12-21 10:29  2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
@ 2023-01-11 16:47  0%   ` Ori Kam
  0 siblings, 0 replies; 200+ results
From: Ori Kam @ 2023-01-11 16:47 UTC (permalink / raw)
  To: Jiawei(Jonny) Wang, Slava Ovsiienko,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Aman Singh, Yuying Zhang, Ferruh Yigit, Andrew Rybchenko
  Cc: dev, Raslan Darawsheh

Hi Jiawei,

> -----Original Message-----
> From: Jiawei(Jonny) Wang <jiaweiw@nvidia.com>
> Sent: Wednesday, 21 December 2022 12:30
> 
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
> 
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.
> 
> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
> 
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
> 
> For example, there're two hardware ports connects to a single DPDK
> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> 	port config 0 txq 0 affinity 1
> 	port config 0 txq 1 affinity 1
> 	port config 0 txq 2 affinity 2
> 	port config 0 txq 3 affinity 2
> 
> These commands config the TxQ index 0 and TxQ
 index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.
> 
> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
> ---

Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori


^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3] devtools: parallelize ABI check
  2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
  2023-01-11 14:10  4%   ` Bruce Richardson
@ 2023-01-11 14:11  4%   ` David Marchand
  2023-01-11 17:04  4%     ` Thomas Monjalon
  1 sibling, 1 reply; 200+ results
From: David Marchand @ 2023-01-11 14:11 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, Ferruh Yigit

On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
>         - find dump2 inside the function
>         - force bash because of export -f
> v3:
>         - revert to POSIX sh
>         - use POSIX eval instead of export -f (issues on Ubuntu)
> ---
>  devtools/check-abi.sh | 21 +++++++++++++--------
>  devtools/gen-abi.sh   |  5 +++--
>  2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..d58c867c60 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,19 +34,18 @@ else
>         ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
>  fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export diff_func='run_diff() {
> +       dump=$1
> +       newdir=$2
>         name=$(basename $dump)
>         dump2=$(find $newdir -name $name)
>         if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
>                 echo "Error: cannot find $name in $newdir" >&2
> -               error=1
> -               continue
> -       fi
> +               return 1
> +       fi;
>         abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>                 abiret=$?
> -               echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> -               error=1
> +               echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>                 echo
>                 if [ $(($abiret & 3)) -ne 0 ]; then
>                         echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> @@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
>                         echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>                 fi
>                 echo
> +               return 1
>         }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> +error=1

Do we need to pass $newdir ?
Like, for example, ABIDIFF_OPTIONS seems inherited, right?

Otherwise this trick looks to work.

-- 
David Marchand


^ permalink raw reply	[relevance 4%]

* Re: [PATCH v3] devtools: parallelize ABI check
  2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 14:10  4%   ` Bruce Richardson
  2023-01-11 14:11  4%   ` David Marchand
  1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 14:10 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: David Marchand, dev, Ferruh Yigit

On Wed, Jan 11, 2023 at 02:16:52PM +0100, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
> 
> xargs reports a global error if one of the process has an error.
> 
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
> 
Commit-log needs update based on changes in v3.

> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
> 	- find dump2 inside the function
> 	- force bash because of export -f
> v3:
> 	- revert to POSIX sh
> 	- use POSIX eval instead of export -f (issues on Ubuntu)
> ---
>  devtools/check-abi.sh | 21 +++++++++++++--------
>  devtools/gen-abi.sh   |  5 +++--
>  2 files changed, 16 insertions(+), 10 deletions(-)

^ permalink raw reply	[relevance 4%]

* [PATCH v3] devtools: parallelize ABI check
  2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
  2023-01-09  9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-11 13:16 33% ` Thomas Monjalon
  2023-01-11 14:10  4%   ` Bruce Richardson
  2023-01-11 14:11  4%   ` David Marchand
  2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
  2 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 13:16 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, Ferruh Yigit

Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.

xargs reports a global error if one of the process has an error.

Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
	- find dump2 inside the function
	- force bash because of export -f
v3:
	- revert to POSIX sh
	- use POSIX eval instead of export -f (issues on Ubuntu)
---
 devtools/check-abi.sh | 21 +++++++++++++--------
 devtools/gen-abi.sh   |  5 +++--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..d58c867c60 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,18 @@ else
 	ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
 fi
 
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export diff_func='run_diff() {
+	dump=$1
+	newdir=$2
 	name=$(basename $dump)
 	dump2=$(find $newdir -name $name)
 	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
 		echo "Error: cannot find $name in $newdir" >&2
-		error=1
-		continue
-	fi
+		return 1
+	fi;
 	abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
 		abiret=$?
-		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
-		error=1
+		echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
 		echo
 		if [ $(($abiret & 3)) -ne 0 ]; then
 			echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
 			echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
 		fi
 		echo
+		return 1
 	}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
+error=1
 
 [ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
 	fi
 
 	libname=$(basename $f)
-	abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+	echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
-- 
2.39.0


^ permalink raw reply	[relevance 33%]

* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
  2023-01-11 10:27  3%       ` Ferruh Yigit
@ 2023-01-11 10:46  0%         ` Ferruh Yigit
  2023-01-12  2:26  0%           ` lihuisong (C)
  0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:46 UTC (permalink / raw)
  To: lihuisong (C), dev, andrew.rybchenko
  Cc: thomas, liudongdong3, huangdaode, fengchengwen

On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>
>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>> This patchset fix some bugs and support attaching and detaching port
>>>> in primary and secondary.
>>>>
>>>> ---
>>>>   -v4: fix a misspelling.
>>>>   -v3:
>>>>     1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>> modification
>>>>        for other bus type.
>>>>     2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>>        the probelm in patch 2/5.
>>>>   -v2: resend due to CI unexplained failure.
>>>>
>>>> Huisong Li (5):
>>>>    drivers/bus: restore driver assignment at front of probing
>>>>    ethdev: fix skip valid port in probing callback
>>>>    app/testpmd: check the validity of the port
>>>>    app/testpmd: add attach and detach port for multiple process
>>>>    app/testpmd: stop forwarding in new or destroy event
>>>>
>>> Hi Huisong,
>>>
>>> I haven't checked the patch in detail yet, but I can see it gives some
>>> ABI compatibility warnings, is this expected:
>> This is to be expected. Because we insert a device state,
>> RTE_ETH_DEV_ALLOCATED,
>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>> We may have to announce it. What do you think?
> 
> If there is an actual ABI break, it can't go in this release, need to
> wait LTS release and yes needs deprecation notice in advance.
> 
> But not all enum value change warnings are real break, need to
> investigate all warnings one by one.
> Need to investigate if old application & new dpdk library may cause any
> unexpected behavior for application.
> 

OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
enum solves the issue, although logically it won't look nice.
Perhaps order can be fixed in next LTS, to have more logical order, but
not quite sure if order worth the disturbance may cause in application.

>>>
>>> 1 function with some indirect sub-type change:
>>>
>>>    [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>> some indirect sub-type changes:
>>>      parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>>        in pointed to type 'const rte_eth_dev':
>>>          in unqualified underlying type 'struct rte_eth_dev' at
>>> ethdev_driver.h:50:1:
>>>            type size hasn't changed
>>>            1 data member change:
>>>              type of 'rte_eth_dev_state state' changed:
>>>                type size hasn't changed
>>>                1 enumerator insertion:
>>>                  'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>                2 enumerator changes:
>>>                  'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>>                  'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>> to '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>>    [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>>      parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>          type size hasn't changed
>>>          1 data member change:
>>>            type of 'rte_eth_dev_state state' changed:
>>>              type size hasn't changed
>>>              1 enumerator insertion:
>>>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>              2 enumerator changes:
>>>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>>    [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>>      return type changed:
>>>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>          type size hasn't changed
>>>          1 data member change:
>>>            type of 'rte_eth_dev_state state' changed:
>>>              type size hasn't changed
>>>              1 enumerator insertion:
>>>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>              2 enumerator changes:
>>>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> ... there are more warnings for same issue ...
>>>
>>> .
> 


^ permalink raw reply	[relevance 0%]

* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
  2023-01-11  0:53  0%     ` lihuisong (C)
@ 2023-01-11 10:27  3%       ` Ferruh Yigit
  2023-01-11 10:46  0%         ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:27 UTC (permalink / raw)
  To: lihuisong (C), dev, andrew.rybchenko
  Cc: thomas, liudongdong3, huangdaode, fengchengwen

On 1/11/2023 12:53 AM, lihuisong (C) wrote:
> 
> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>> This patchset fix some bugs and support attaching and detaching port
>>> in primary and secondary.
>>>
>>> ---
>>>   -v4: fix a misspelling.
>>>   -v3:
>>>     1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>> modification
>>>        for other bus type.
>>>     2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>        the probelm in patch 2/5.
>>>   -v2: resend due to CI unexplained failure.
>>>
>>> Huisong Li (5):
>>>    drivers/bus: restore driver assignment at front of probing
>>>    ethdev: fix skip valid port in probing callback
>>>    app/testpmd: check the validity of the port
>>>    app/testpmd: add attach and detach port for multiple process
>>>    app/testpmd: stop forwarding in new or destroy event
>>>
>> Hi Huisong,
>>
>> I haven't checked the patch in detail yet, but I can see it gives some
>> ABI compatibility warnings, is this expected:
> This is to be expected. Because we insert a device state,
> RTE_ETH_DEV_ALLOCATED,
> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> We may have to announce it. What do you think?

If there is an actual ABI break, it can't go in this release, need to
wait LTS release and yes needs deprecation notice in advance.

But not all enum value change warnings are real break, need to
investigate all warnings one by one.
Need to investigate if old application & new dpdk library may cause any
unexpected behavior for application.

>>
>> 1 function with some indirect sub-type change:
>>
>>    [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>> some indirect sub-type changes:
>>      parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>        in pointed to type 'const rte_eth_dev':
>>          in unqualified underlying type 'struct rte_eth_dev' at
>> ethdev_driver.h:50:1:
>>            type size hasn't changed
>>            1 data member change:
>>              type of 'rte_eth_dev_state state' changed:
>>                type size hasn't changed
>>                1 enumerator insertion:
>>                  'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>                2 enumerator changes:
>>                  'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>>                  'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>> to '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>>    [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>      parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>          type size hasn't changed
>>          1 data member change:
>>            type of 'rte_eth_dev_state state' changed:
>>              type size hasn't changed
>>              1 enumerator insertion:
>>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>              2 enumerator changes:
>>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>>    [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>      return type changed:
>>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>          type size hasn't changed
>>          1 data member change:
>>            type of 'rte_eth_dev_state state' changed:
>>              type size hasn't changed
>>              1 enumerator insertion:
>>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>              2 enumerator changes:
>>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> ... there are more warnings for same issue ...
>>
>> .


^ permalink raw reply	[relevance 3%]

* Re: RFC abstracting atomics
  2023-01-10 20:10  3%   ` Tyler Retzlaff
@ 2023-01-11 10:10  0%     ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 10:10 UTC (permalink / raw)
  To: Tyler Retzlaff; +Cc: dev

On Tue, Jan 10, 2023 at 12:10:33PM -0800, Tyler Retzlaff wrote:
> On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> > On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > > hi folks,
> > > 
> > > i would like to introduce a layer of abstraction that would allow
> > > optional use of standard C11 atomics when the platform / toolchain
> > > combination has them available.
> > > 
> > > making the option usable would be a phased approach intended to focus
> > > review and minimize dealing with churn on such a broad change.
> > > 
> > > 1. provide an initial series to add the abstraction and the ability
> > >    control enablement with a meson option enable_stdatomics=false will
> > >    be the default.
> > > 
> > >    for all existing platform / toolchain combinations the default would
> > >    remain false. i.e. i have no plans to enable it for existing platforms
> > >    toolchain combinations but leaves a change of default open to the
> > >    community as a future discussion if it is desired.
> > > 
> > > 2. once the initial abstraction is integrated a series will be introduced to
> > >    port the tree to the abstraction with enable_stdatomics=false. the goal
> > >    being low or no change to the current use of gcc builtin C++11 memory
> > >    model atomics.
> > > 
> > > 3. once the tree is ported a final series will be introduced to introduce
> > >    the remaining change to allow the use of enable_stdatomics=true.
> > > 
> > > would appreciate any assistance / suggestions you can provide to
> > > introduce the abstraction smoothly.
> > > 
> > 
> > Plan generally sounds ok. However, beyond point #3, would there then be
> > plans to remove the option and always use stdatomics in future?
> 
> that is a discussion for the community i think on a per-platform /
> per-toolchain basis. there is likely to be resistance which is why i'm
> favoring the opt-in if you want model.
> 
> some potential arguments against switching.
> 
> * it's an abi break there is no way around it.
> * old compiler x stdatomics implementation is less optimal than
>   old compiler x __atomics (potential argument).
> * there's some "mixed" use of variables in the tree where sometimes we
>   operate on them as if they are atomic and sometimes not. the std
>   atomics apis doesn't support this sometimes atomic codegen you either
>   get atomic or you don't.
> * direct use of atomics default to seq_cst ordering if the strengthening
>   of the ordering is not desired each variable needs to be hunted down
>   and explicitly returned to relaxed ordering access.
> 
> > To slightly expand the scope of the discussion - would it be worthwhile
> > putting these abstractions in a new library in DPDK other than EAL, to
> > start the process of splitting out some of the lower-level material from
> > that library?
> 
> the abstraction as i have prototyped it is a set of conditionally
> compiled macros where the macros mirror the standard c atomics for
> naming and have been placed in include/generic/rte_atomics.h
> 
> i've no problem splitting it out into a separate library and then have
> EAL depend on it, but it is currently header only so i'm not sure if it
> is worth doing for that.
> 
> we can chew on that more in a couple days when i submit the base series
> if you like.
> 
Thanks.

One additional point that just became clear to me when I started thinking
about upping our DPDK C-standard-baseline. We need to be careful what we
are considering when we up our C baseline. We can mandate a specific
compiler minimum and C version for compiling up DPDK itself, but I think we
should not mandate that for the end applications.

That means that our header files, such as atomics, should not require C99
or C11 even if the build of DPDK itself does. More specifically, even if we
bump DPDK minimum to C11, we should still allow apps to build using older
compiler settings.

Therefore, we probably need to maintain non-C11 atomics code paths in
headers beyond the point at which DPDK itself uses C11 as a code baseline.

/Bruce

^ permalink raw reply	[relevance 0%]

* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
  2023-01-10 16:51  3%   ` Ferruh Yigit
@ 2023-01-11  0:53  0%     ` lihuisong (C)
  2023-01-11 10:27  3%       ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-11  0:53 UTC (permalink / raw)
  To: Ferruh Yigit, dev, andrew.rybchenko
  Cc: thomas, liudongdong3, huangdaode, fengchengwen


在 2023/1/11 0:51, Ferruh Yigit 写道:
> On 12/6/2022 9:26 AM, Huisong Li wrote:
>> This patchset fix some bugs and support attaching and detaching port
>> in primary and secondary.
>>
>> ---
>>   -v4: fix a misspelling.
>>   -v3:
>>     1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
>>        for other bus type.
>>     2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>        the probelm in patch 2/5.
>>   -v2: resend due to CI unexplained failure.
>>
>> Huisong Li (5):
>>    drivers/bus: restore driver assignment at front of probing
>>    ethdev: fix skip valid port in probing callback
>>    app/testpmd: check the validity of the port
>>    app/testpmd: add attach and detach port for multiple process
>>    app/testpmd: stop forwarding in new or destroy event
>>
> Hi Huisong,
>
> I haven't checked the patch in detail yet, but I can see it gives some
> ABI compatibility warnings, is this expected:
This is to be expected. Because we insert a device state, 
RTE_ETH_DEV_ALLOCATED,
before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
We may have to announce it. What do you think?
>
> 1 function with some indirect sub-type change:
>
>    [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
> some indirect sub-type changes:
>      parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>        in pointed to type 'const rte_eth_dev':
>          in unqualified underlying type 'struct rte_eth_dev' at
> ethdev_driver.h:50:1:
>            type size hasn't changed
>            1 data member change:
>              type of 'rte_eth_dev_state state' changed:
>                type size hasn't changed
>                1 enumerator insertion:
>                  'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>                2 enumerator changes:
>                  'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
>                  'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
> to '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
>    [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>      parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>          type size hasn't changed
>          1 data member change:
>            type of 'rte_eth_dev_state state' changed:
>              type size hasn't changed
>              1 enumerator insertion:
>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>              2 enumerator changes:
>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
>    [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
> ethdev_driver.c:72:1 has some indirect sub-type changes:
>      return type changed:
>        in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>          type size hasn't changed
>          1 data member change:
>            type of 'rte_eth_dev_state state' changed:
>              type size hasn't changed
>              1 enumerator insertion:
>                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>              2 enumerator changes:
>                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
>                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> ... there are more warnings for same issue ...
>
> .

^ permalink raw reply	[relevance 0%]

* Re: RFC abstracting atomics
  @ 2023-01-10 20:10  3%   ` Tyler Retzlaff
  2023-01-11 10:10  0%     ` Bruce Richardson
  0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-01-10 20:10 UTC (permalink / raw)
  To: Bruce Richardson; +Cc: dev

On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> > 
> > i would like to introduce a layer of abstraction that would allow
> > optional use of standard C11 atomics when the platform / toolchain
> > combination has them available.
> > 
> > making the option usable would be a phased approach intended to focus
> > review and minimize dealing with churn on such a broad change.
> > 
> > 1. provide an initial series to add the abstraction and the ability
> >    control enablement with a meson option enable_stdatomics=false will
> >    be the default.
> > 
> >    for all existing platform / toolchain combinations the default would
> >    remain false. i.e. i have no plans to enable it for existing platforms
> >    toolchain combinations but leaves a change of default open to the
> >    community as a future discussion if it is desired.
> > 
> > 2. once the initial abstraction is integrated a series will be introduced to
> >    port the tree to the abstraction with enable_stdatomics=false. the goal
> >    being low or no change to the current use of gcc builtin C++11 memory
> >    model atomics.
> > 
> > 3. once the tree is ported a final series will be introduced to introduce
> >    the remaining change to allow the use of enable_stdatomics=true.
> > 
> > would appreciate any assistance / suggestions you can provide to
> > introduce the abstraction smoothly.
> > 
> 
> Plan generally sounds ok. However, beyond point #3, would there then be
> plans to remove the option and always use stdatomics in future?

that is a discussion for the community i think on a per-platform /
per-toolchain basis. there is likely to be resistance which is why i'm
favoring the opt-in if you want model.

some potential arguments against switching.

* it's an abi break there is no way around it.
* old compiler x stdatomics implementation is less optimal than
  old compiler x __atomics (potential argument).
* there's some "mixed" use of variables in the tree where sometimes we
  operate on them as if they are atomic and sometimes not. the std
  atomics apis doesn't support this sometimes atomic codegen you either
  get atomic or you don't.
* direct use of atomics default to seq_cst ordering if the strengthening
  of the ordering is not desired each variable needs to be hunted down
  and explicitly returned to relaxed ordering access.

> To slightly expand the scope of the discussion - would it be worthwhile
> putting these abstractions in a new library in DPDK other than EAL, to
> start the process of splitting out some of the lower-level material from
> that library?

the abstraction as i have prototyped it is a set of conditionally
compiled macros where the macros mirror the standard c atomics for
naming and have been placed in include/generic/rte_atomics.h

i've no problem splitting it out into a separate library and then have
EAL depend on it, but it is currently header only so i'm not sure if it
is worth doing for that.

we can chew on that more in a couple days when i submit the base series
if you like.

> 
> /Bruce

^ permalink raw reply	[relevance 3%]

* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
  @ 2023-01-10 16:51  3%   ` Ferruh Yigit
  2023-01-11  0:53  0%     ` lihuisong (C)
  0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-10 16:51 UTC (permalink / raw)
  To: Huisong Li, dev, andrew.rybchenko
  Cc: thomas, liudongdong3, huangdaode, fengchengwen

On 12/6/2022 9:26 AM, Huisong Li wrote:
> This patchset fix some bugs and support attaching and detaching port
> in primary and secondary.
> 
> ---
>  -v4: fix a misspelling. 
>  -v3:
>    1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
>       for other bus type.
>    2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>       the probelm in patch 2/5. 
>  -v2: resend due to CI unexplained failure.
> 
> Huisong Li (5):
>   drivers/bus: restore driver assignment at front of probing
>   ethdev: fix skip valid port in probing callback
>   app/testpmd: check the validity of the port
>   app/testpmd: add attach and detach port for multiple process
>   app/testpmd: stop forwarding in new or destroy event
> 

Hi Huisong,

I haven't checked the patch in detail yet, but I can see it gives some
ABI compatibility warnings, is this expected:


1 function with some indirect sub-type change:

  [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
some indirect sub-type changes:
    parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
      in pointed to type 'const rte_eth_dev':
        in unqualified underlying type 'struct rte_eth_dev' at
ethdev_driver.h:50:1:
          type size hasn't changed
          1 data member change:
            type of 'rte_eth_dev_state state' changed:
              type size hasn't changed
              1 enumerator insertion:
                'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
              2 enumerator changes:
                'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
                'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
to '3' at rte_ethdev.h:2000:1

1 function with some indirect sub-type change:

  [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
    parameter 2 of type 'rte_eth_dev*' has sub-type changes:
      in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
        type size hasn't changed
        1 data member change:
          type of 'rte_eth_dev_state state' changed:
            type size hasn't changed
            1 enumerator insertion:
              'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
            2 enumerator changes:
              'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
              'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1

1 function with some indirect sub-type change:

  [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
ethdev_driver.c:72:1 has some indirect sub-type changes:
    return type changed:
      in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
        type size hasn't changed
        1 data member change:
          type of 'rte_eth_dev_state state' changed:
            type size hasn't changed
            1 enumerator insertion:
              'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
            2 enumerator changes:
              'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
              'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1

... there are more warnings for same issue ...


^ permalink raw reply	[relevance 3%]

* Re: [PATCH v2] devtools: parallelize ABI check
  2023-01-09  9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-10 11:08  4%   ` Ferruh Yigit
  0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-10 11:08 UTC (permalink / raw)
  To: Thomas Monjalon, David Marchand; +Cc: dev

On 1/9/2023 9:34 AM, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
> 
> xargs reports a global error if one of the process has an error.
> 
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2:
> 	- find dump2 inside the function
> 	- force bash because of export -f

It reduces script runtime ~2mins in my test.

Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>


^ permalink raw reply	[relevance 4%]

* [PATCH v2] devtools: parallelize ABI check
  2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
@ 2023-01-09  9:34 23% ` Thomas Monjalon
  2023-01-10 11:08  4%   ` Ferruh Yigit
  2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
  2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
  2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-09  9:34 UTC (permalink / raw)
  To: David Marchand; +Cc: dev

Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.

xargs reports a global error if one of the process has an error.

Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v2:
	- find dump2 inside the function
	- force bash because of export -f
---
 devtools/check-abi.sh | 20 +++++++++++++-------
 devtools/gen-abi.sh   |  5 +++--
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..4409f65ccd 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/bash -e
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright (c) 2019 Red Hat, Inc.
 
@@ -34,19 +34,18 @@ else
 	ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
 fi
 
-error=
-for dump in $(find $refdir -name "*.dump"); do
+run_diff() { # <dump1> <dir2>
+	dump=$1
+	newdir=$2
 	name=$(basename $dump)
 	dump2=$(find $newdir -name $name)
 	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
 		echo "Error: cannot find $name in $newdir" >&2
-		error=1
-		continue
+		return 1
 	fi
 	abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
 		abiret=$?
 		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
-		error=1
 		echo
 		if [ $(($abiret & 3)) -ne 0 ]; then
 			echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,14 @@ for dump in $(find $refdir -name "*.dump"); do
 			echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
 		fi
 		echo
+		return 1
 	}
-done
+}
+export -f run_diff
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'run_diff $0 '$newdir ||
+error=1
 
 [ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
 	fi
 
 	libname=$(basename $f)
-	abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+	echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
-- 
2.39.0


^ permalink raw reply	[relevance 23%]

* [PATCH] devtools: parallelize ABI check
@ 2023-01-07 13:39 33% Thomas Monjalon
  2023-01-09  9:34 23% ` [PATCH v2] " Thomas Monjalon
                   ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2023-01-07 13:39 UTC (permalink / raw)
  Cc: dev, David Marchand

Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.

xargs reports a global error if one of the process has an error.

Running a shell function with xargs requires to export it with -f.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 devtools/check-abi.sh | 33 ++++++++++++++++++++-------------
 devtools/gen-abi.sh   |  5 +++--
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..e2fa49217d 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,10 @@ else
 	ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
 fi
 
-error=
-for dump in $(find $refdir -name "*.dump"); do
-	name=$(basename $dump)
-	dump2=$(find $newdir -name $name)
-	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
-		echo "Error: cannot find $name in $newdir" >&2
-		error=1
-		continue
-	fi
-	abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
+run_diff() { # <dump1> <dump2>
+	abidiff $ABIDIFF_OPTIONS $1 $2 || {
 		abiret=$?
-		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
-		error=1
+		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $1 $2'" >&2
 		echo
 		if [ $(($abiret & 3)) -ne 0 ]; then
 			echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +49,23 @@ for dump in $(find $refdir -name "*.dump"); do
 			echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
 		fi
 		echo
+		return $abiret
 	}
-done
+}
+export -f run_diff
+
+error=
+for dump in $(find $refdir -name "*.dump"); do
+	name=$(basename $dump)
+	dump2=$(find $newdir -name $name)
+	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
+		echo "Error: cannot find $name in $newdir" >&2
+		error=1
+		continue
+	fi
+	echo $dump $dump2
+done |
+xargs -n2 -P0 sh -c 'run_diff $0 $1' ||
+error=1
 
 [ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
 	fi
 
 	libname=$(basename $f)
-	abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+	echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
-- 
2.39.0


^ permalink raw reply	[relevance 33%]

* RE: [PATCH v2] cryptodev: add algo enums to string conversion APIs
  2023-01-04  6:18  2% ` [PATCH v2] " Akhil Goyal
@ 2023-01-05 10:56  0%   ` Akhil Goyal
  0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2023-01-05 10:56 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
	hemant.agrawal, matan, g.singh, ruifeng.wang, Anoob Joseph,
	radu.nicolau, Volodymyr Fialko, ktraynor, david.marchand, thomas

> Subject: [PATCH v2] cryptodev: add algo enums to string conversion APIs
> 
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
> Acked-by: Ciara Power <ciara.power@intel.com>
> Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
> ---
Applied to dpdk-next-crypto


^ permalink raw reply	[relevance 0%]

* RE: [PATCH v3 1/3] ethdev: enable direct rearm with separate API
  @ 2023-01-04 10:11  4%         ` Morten Brørup
  0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2023-01-04 10:11 UTC (permalink / raw)
  To: Feifei Wang, thomas, Ferruh Yigit, Andrew Rybchenko
  Cc: dev, konstantin.v.ananyev, nd, Honnappa Nagarahalli, Ruifeng Wang, nd

> From: Feifei Wang [mailto:Feifei.Wang2@arm.com]
> Sent: Wednesday, 4 January 2023 09.51
> 
> Hi, Morten
> 
> > 发件人: Morten Brørup <mb@smartsharesystems.com>
> > 发送时间: Wednesday, January 4, 2023 4:22 PM
> >
> > > From: Feifei Wang [mailto:feifei.wang2@arm.com]
> > > Sent: Wednesday, 4 January 2023 08.31
> > >
> > > Add 'tx_fill_sw_ring' and 'rx_flush_descriptor' API into direct
> rearm
> > > mode for separate Rx and Tx Operation. And this can support
> different
> > > multiple sources in direct rearm mode. For examples, Rx driver is
> > > ixgbe, and Tx driver is i40e.
> > >
> > > Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Suggested-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > ---
> >
> > This feature looks very promising for performance. I am pleased to
> see
> > progress on it.
> >
> Thanks very much for your reviewing.
> 
> > Please confirm that the fast path functions are still thread safe,
> i.e. one EAL
> > thread may be calling rte_eth_rx_burst() while another EAL thread is
> calling
> > rte_eth_tx_burst().
> >
> For the multiple threads safe, like we say in cover letter, current
> direct-rearm support
> Rx and Tx in the same thread. If we consider multiple threads like
> 'pipeline model', there
> need to add 'lock' in the data path which can decrease the performance.
> Thus, the first step we do is try to enable direct-rearm in the single
> thread, and then we will consider
> to enable direct rearm in multiple threads and improve the performance.

OK, doing it in steps is a good idea for a feature like this - makes it easier to understand and review.

When proceeding to add support for the "pipeline model", perhaps the lockless principles from the rte_ring can be used in this feature too.

From a high level perspective, I'm somewhat worried that releasing a "work-in-progress" version of this feature in some DPDK version will cause API/ABI breakage discussions when progressing to the next steps of the implementation to make the feature more complete. Not only support for thread safety across simultaneous RX and TX, but also support for multiple mbuf pools per RX queue [1]. Marking the functions experimental should alleviate such discussions, but there is a risk of pushback to not break the API/ABI anyway.

[1]: https://elixir.bootlin.com/dpdk/v22.11.1/source/lib/ethdev/rte_ethdev.h#L1105

[...]

> > > --- a/lib/ethdev/ethdev_driver.h
> > > +++ b/lib/ethdev/ethdev_driver.h
> > > @@ -59,6 +59,10 @@ struct rte_eth_dev {
> > >  	eth_rx_descriptor_status_t rx_descriptor_status;
> > >  	/** Check the status of a Tx descriptor */
> > >  	eth_tx_descriptor_status_t tx_descriptor_status;
> > > +	/** Fill Rx sw-ring with Tx buffers in direct rearm mode */
> > > +	eth_tx_fill_sw_ring_t tx_fill_sw_ring;
> >
> > What is "Rx sw-ring"? Please confirm that this is not an Intel PMD
> specific
> > term and/or implementation detail, e.g. by providing a conceptual
> > implementation for a non-Intel PMD, e.g. mlx5.
> Rx sw_ring is used  to store mbufs in intel PMD. This is the same as
> 'rxq->elts'
> in mlx5. 

Sounds good.

Then all we need is consensus on a generic name for this, unless "Rx sw-ring" already is the generic name. (I'm not a PMD developer, so I might be completely off track here.) Naming is often debatable, so I'll stop talking about it now - I only wanted to highlight that we should avoid vendor-specific terms in public APIs intended to be implemented by multiple vendors. On the other hand... if no other vendors raise their voices before merging into the DPDK main repository, they forfeit their right to complain about it. ;-)

> Agree with that we need to providing a conceptual
> implementation for all PMDs.

My main point is that we should ensure that the feature is not too tightly coupled with the way Intel PMDs implement mbuf handling. Providing a conceptual implementation for a non-Intel PMD is one way of checking this.

The actual implementation in other PMDs could be left up to the various NIC vendors.

^ permalink raw reply	[relevance 4%]

* [PATCH v2] cryptodev: add algo enums to string conversion APIs
  2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
                   ` (3 preceding siblings ...)
  2022-12-14  9:32  0% ` Zhang, Fan
@ 2023-01-04  6:18  2% ` Akhil Goyal
  2023-01-05 10:56  0%   ` Akhil Goyal
  4 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-01-04  6:18 UTC (permalink / raw)
  To: dev
  Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
	hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
	radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
	Akhil Goyal

Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.

Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Ciara Power <ciara.power@intel.com>
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
---
Changes in v2: fixed Windows compilation

 app/test-crypto-perf/cperf_options_parsing.c |   6 +-
 app/test/test_cryptodev_asym.c               |   2 +-
 app/test/test_cryptodev_security_ipsec.c     |   8 +-
 doc/guides/rel_notes/deprecation.rst         |   7 +
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |   2 +-
 drivers/crypto/qat/qat_sym_session.c         |   7 +-
 examples/l2fwd-crypto/main.c                 |  12 +-
 lib/cryptodev/cryptodev_trace_points.c       |  12 ++
 lib/cryptodev/rte_crypto_asym.h              |   1 +
 lib/cryptodev/rte_crypto_sym.h               |   3 +
 lib/cryptodev/rte_cryptodev.c                | 183 ++++++++++++++++++-
 lib/cryptodev/rte_cryptodev.h                |  52 ++++++
 lib/cryptodev/rte_cryptodev_trace.h          |  32 ++++
 lib/cryptodev/version.map                    |  10 +
 14 files changed, 310 insertions(+), 27 deletions(-)

diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
 			opts->op_type == CPERF_CIPHER_THEN_AUTH ||
 			opts->op_type == CPERF_AUTH_THEN_CIPHER) {
 		printf("# auth algorithm: %s\n",
-			rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+			rte_cryptodev_get_auth_algo_string(opts->auth_algo));
 		printf("# auth operation: %s\n",
 			rte_crypto_auth_operation_strings[opts->auth_op]);
 		printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
 			opts->op_type == CPERF_CIPHER_THEN_AUTH ||
 			opts->op_type == CPERF_AUTH_THEN_CIPHER) {
 		printf("# cipher algorithm: %s\n",
-			rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+			rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
 		printf("# cipher operation: %s\n",
 			rte_crypto_cipher_operation_strings[opts->cipher_op]);
 		printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
 
 	if (opts->op_type == CPERF_AEAD) {
 		printf("# aead algorithm: %s\n",
-			rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+			rte_cryptodev_get_aead_algo_string(opts->aead_algo));
 		printf("# aead operation: %s\n",
 			rte_crypto_aead_operation_strings[opts->aead_op]);
 		printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
 	int i = 0;
 
 	printf("\nxform type: %s\n===================\n",
-			rte_crypto_asym_xform_strings[capa->xform_type]);
+			rte_cryptodev_asym_get_xform_string(capa->xform_type));
 	printf("operation supported -");
 
 	for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
 {
 	if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
 		printf("\t%s [%d]",
-		       rte_crypto_aead_algorithm_strings[param1->alg.aead],
+		       rte_cryptodev_get_aead_algo_string(param1->alg.aead),
 		       param1->key_length * 8);
 	} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
 		printf("\t%s",
-		       rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+		       rte_cryptodev_get_auth_algo_string(param1->alg.auth));
 		if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
 			printf(" [%dB ICV]", param1->digest_length);
 	} else {
 		printf("\t%s",
-		       rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+		       rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
 		if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
 			printf(" [%d]", param1->key_length * 8);
 		printf(" %s",
-		       rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+		       rte_cryptodev_get_auth_algo_string(param2->alg.auth));
 		if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
 			printf(" [%dB ICV]", param2->digest_length);
 	}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
   which got error interrupt to the application,
   so that application can reset that particular queue pair.
 
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+  ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+  ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+  Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+  ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+  ``rte_cryptodev_asym_get_xform_string`` respectively.
+
 * flow_classify: The flow_classify library and example have no maintainer.
   The library is experimental and, as such, it could be removed from DPDK.
   Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
 	if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
 		(xform->next != NULL)) {
 		OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
-			rte_crypto_asym_xform_strings[xform->xform_type]);
+			rte_cryptodev_asym_get_xform_string(xform->xform_type));
 		return ret;
 	}
 
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
 		if (!qat_is_cipher_alg_supported(
 			cipher_xform->algo, internals)) {
 			QAT_LOG(ERR, "%s not supported on this device",
-				rte_crypto_cipher_algorithm_strings
-					[cipher_xform->algo]);
+				rte_cryptodev_get_cipher_algo_string(
+					cipher_xform->algo));
 			ret = -ENOTSUP;
 			goto error_out;
 		}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
 	case RTE_CRYPTO_AUTH_ZUC_EIA3:
 		if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
 			QAT_LOG(ERR, "%s not supported on this device",
-				rte_crypto_auth_algorithm_strings
-				[auth_xform->algo]);
+				rte_cryptodev_get_auth_algo_string(auth_xform->algo));
 			return -ENOTSUP;
 		}
 		session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- Cipher information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+		rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
 	rte_hexdump(stdout, "Cipher key:",
 			options->cipher_xform.cipher.key.data,
 			options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- Authentication information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+		rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
 	rte_hexdump(stdout, "Auth key:",
 			options->auth_xform.auth.key.data,
 			options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- AEAD information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+		rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
 	rte_hexdump(stdout, "AEAD key:",
 			options->aead_xform.aead.key.data,
 			options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+			rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_auth_algorithm_strings[opt_auth_algo],
+			rte_cryptodev_get_auth_algo_string(opt_auth_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_aead_algorithm_strings[opt_aead_algo],
+			rte_cryptodev_get_aead_algo_string(opt_aead_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
 	lib.cryptodev.get.cipher.algo.enum)
 
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+	lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+	lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+	lib.cryptodev.get.cipher.algo.string)
+
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
 	lib.cryptodev.get.dev.id)
 
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
 	lib.cryptodev.asym.get.xform.enum)
 
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+	lib.cryptodev.asym.get.xform.string)
+
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
 	lib.cryptodev.asym.xform.capability.check.modlen)
 
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
 struct rte_cryptodev_asym_session;
 
 /** asym xform type name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_asym_xform_strings[];
 
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
 };
 
 /** Cipher algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_cipher_algorithm_strings[];
 
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
 };
 
 /** Authentication algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_auth_algorithm_strings[];
 
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
 };
 
 /** AEAD algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_aead_algorithm_strings[];
 
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..742a4c512e 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
 };
 
 /**
+ * @deprecated
  * The crypto cipher algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_cipher_algorithm_strings[] = {
 	[RTE_CRYPTO_CIPHER_3DES_CBC]	= "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
 	[RTE_CRYPTO_CIPHER_SM4_CTR]	= "sm4-ctr"
 };
 
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+	[RTE_CRYPTO_CIPHER_3DES_CBC]	= "3des-cbc",
+	[RTE_CRYPTO_CIPHER_3DES_ECB]	= "3des-ecb",
+	[RTE_CRYPTO_CIPHER_3DES_CTR]	= "3des-ctr",
+
+	[RTE_CRYPTO_CIPHER_AES_CBC]	= "aes-cbc",
+	[RTE_CRYPTO_CIPHER_AES_CTR]	= "aes-ctr",
+	[RTE_CRYPTO_CIPHER_AES_DOCSISBPI]	= "aes-docsisbpi",
+	[RTE_CRYPTO_CIPHER_AES_ECB]	= "aes-ecb",
+	[RTE_CRYPTO_CIPHER_AES_F8]	= "aes-f8",
+	[RTE_CRYPTO_CIPHER_AES_XTS]	= "aes-xts",
+
+	[RTE_CRYPTO_CIPHER_ARC4]	= "arc4",
+
+	[RTE_CRYPTO_CIPHER_DES_CBC]     = "des-cbc",
+	[RTE_CRYPTO_CIPHER_DES_DOCSISBPI]	= "des-docsisbpi",
+
+	[RTE_CRYPTO_CIPHER_NULL]	= "null",
+
+	[RTE_CRYPTO_CIPHER_KASUMI_F8]	= "kasumi-f8",
+	[RTE_CRYPTO_CIPHER_SNOW3G_UEA2]	= "snow3g-uea2",
+	[RTE_CRYPTO_CIPHER_ZUC_EEA3]	= "zuc-eea3",
+	[RTE_CRYPTO_CIPHER_SM4_ECB]	= "sm4-ecb",
+	[RTE_CRYPTO_CIPHER_SM4_CBC]	= "sm4-cbc",
+	[RTE_CRYPTO_CIPHER_SM4_CTR]	= "sm4-ctr"
+};
+
 /**
  * The crypto cipher operation strings identifiers.
  * It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
 };
 
 /**
+ * @deprecated
  * The crypto auth algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_auth_algorithm_strings[] = {
 	[RTE_CRYPTO_AUTH_AES_CBC_MAC]	= "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
 };
 
 /**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+	[RTE_CRYPTO_AUTH_AES_CBC_MAC]	= "aes-cbc-mac",
+	[RTE_CRYPTO_AUTH_AES_CMAC]	= "aes-cmac",
+	[RTE_CRYPTO_AUTH_AES_GMAC]	= "aes-gmac",
+	[RTE_CRYPTO_AUTH_AES_XCBC_MAC]	= "aes-xcbc-mac",
+
+	[RTE_CRYPTO_AUTH_MD5]		= "md5",
+	[RTE_CRYPTO_AUTH_MD5_HMAC]	= "md5-hmac",
+
+	[RTE_CRYPTO_AUTH_NULL]		= "null",
+
+	[RTE_CRYPTO_AUTH_SHA1]		= "sha1",
+	[RTE_CRYPTO_AUTH_SHA1_HMAC]	= "sha1-hmac",
+
+	[RTE_CRYPTO_AUTH_SHA224]	= "sha2-224",
+	[RTE_CRYPTO_AUTH_SHA224_HMAC]	= "sha2-224-hmac",
+	[RTE_CRYPTO_AUTH_SHA256]	= "sha2-256",
+	[RTE_CRYPTO_AUTH_SHA256_HMAC]	= "sha2-256-hmac",
+	[RTE_CRYPTO_AUTH_SHA384]	= "sha2-384",
+	[RTE_CRYPTO_AUTH_SHA384_HMAC]	= "sha2-384-hmac",
+	[RTE_CRYPTO_AUTH_SHA512]	= "sha2-512",
+	[RTE_CRYPTO_AUTH_SHA512_HMAC]	= "sha2-512-hmac",
+
+	[RTE_CRYPTO_AUTH_SHA3_224]	= "sha3-224",
+	[RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_256]	= "sha3-256",
+	[RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_384]	= "sha3-384",
+	[RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_512]	= "sha3-512",
+	[RTE_CRYPTO_AUTH_SHA3_512_HMAC]	= "sha3-512-hmac",
+
+	[RTE_CRYPTO_AUTH_KASUMI_F9]	= "kasumi-f9",
+	[RTE_CRYPTO_AUTH_SNOW3G_UIA2]	= "snow3g-uia2",
+	[RTE_CRYPTO_AUTH_ZUC_EIA3]	= "zuc-eia3",
+	[RTE_CRYPTO_AUTH_SM3]		= "sm3"
+};
+
+/**
+ * @deprecated
  * The crypto AEAD algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
 };
 
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
+	[RTE_CRYPTO_AEAD_AES_GCM]	= "aes-gcm",
+	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
 /**
  * The crypto AEAD operation strings identifiers.
  * It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
 };
 
 /**
+ * @deprecated
  * Asymmetric crypto transform operation strings identifiers.
  */
+__rte_deprecated
 const char *rte_crypto_asym_xform_strings[] = {
 	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
 	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
@@ -183,6 +281,23 @@ const char *rte_crypto_asym_xform_strings[] = {
 	[RTE_CRYPTO_ASYM_XFORM_ECPM]	= "ecpm",
 };
 
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *
+crypto_asym_xform_strings[] = {
+	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
+	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
+	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
+	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
+	[RTE_CRYPTO_ASYM_XFORM_DH]	= "dh",
+	[RTE_CRYPTO_ASYM_XFORM_DSA]	= "dsa",
+	[RTE_CRYPTO_ASYM_XFORM_ECDSA]	= "ecdsa",
+	[RTE_CRYPTO_ASYM_XFORM_ECPM]	= "ecpm",
+};
+
 /**
  * Asymmetric crypto operation strings identifiers.
  */
@@ -227,8 +342,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_cipher_algorithm) i;
 			ret = 0;
 			break;
@@ -247,8 +362,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_auth_algorithm) i;
 			ret = 0;
 			break;
@@ -267,8 +382,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_aead_algorithm) i;
 			ret = 0;
 			break;
@@ -287,9 +402,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+	for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
 		if (strcmp(xform_string,
-			rte_crypto_asym_xform_strings[i]) == 0) {
+			crypto_asym_xform_strings[i]) == 0) {
 			*xform_enum = (enum rte_crypto_asym_xform_type) i;
 			ret = 0;
 			break;
@@ -301,6 +416,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 	return ret;
 }
 
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if ((unsigned int)algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+		alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if ((unsigned int)algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+		alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if ((unsigned int)algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+		alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+	const char *xform_str = NULL;
+
+	if ((unsigned int)xform_enum < RTE_DIM(crypto_asym_xform_strings))
+		xform_str = crypto_asym_xform_strings[xform_enum];
+
+	rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+	return xform_str;
+}
+
 /**
  * The crypto auth operation strings identifiers.
  * It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
 rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 		const char *xform_string);
 
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param	xform_enum	xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
 
 /** Macro used at end of crypto PMD list */
 #define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
 	rte_trace_point_emit_int(ret);
 )
 
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_aead_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_auth_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_cipher_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
 RTE_TRACE_POINT(
 	rte_cryptodev_trace_get_dev_id,
 	RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
 	rte_trace_point_emit_int(ret);
 )
 
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_asym_get_xform_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+		const char *xform_string),
+	rte_trace_point_emit_int(xform_enum);
+	rte_trace_point_emit_string(xform_string);
+)
+
 RTE_TRACE_POINT(
 	rte_cryptodev_trace_asym_xform_capability_check_modlen,
 	RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
 	__rte_cryptodev_trace_sym_session_get_user_data;
 	__rte_cryptodev_trace_sym_session_set_user_data;
 	__rte_cryptodev_trace_count;
+
+	# added 23.03
+	rte_cryptodev_asym_get_xform_string;
+	rte_cryptodev_get_aead_algo_string;
+	rte_cryptodev_get_auth_algo_string;
+	rte_cryptodev_get_cipher_algo_string;
 };
 
 INTERNAL {
 	global:
 
+	__rte_cryptodev_trace_asym_get_xform_string;
+	__rte_cryptodev_trace_get_aead_algo_string;
+	__rte_cryptodev_trace_get_auth_algo_string;
+	__rte_cryptodev_trace_get_cipher_algo_string;
 	cryptodev_fp_ops_reset;
 	cryptodev_fp_ops_set;
 	rte_cryptodev_allocate_driver;
-- 
2.25.1


^ permalink raw reply	[relevance 2%]

* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 14:33  3%                   ` Rongwei Liu
@ 2022-12-26 16:44  4%                     ` Ori Kam
  2023-01-15 22:46  0%                       ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Ori Kam @ 2022-12-26 16:44 UTC (permalink / raw)
  To: Rongwei Liu, Jerin Jacob
  Cc: Matan Azrad, Slava Ovsiienko,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

Hi Rongwei and Jerin,

> -----Original Message-----
> From: Rongwei Liu <rongweil@nvidia.com>
> Sent: Wednesday, 21 December 2022 16:33
> 
> HI Jerin:
> 
> BR
> Rongwei
> 
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 21:12
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or
> standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > >
> > > HI Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 20:45
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-
> Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Hi Jerin:
> > > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan
> Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > HI Jerin:
> > > > > > >
> > > > > >
> > > > > > Hi Rongwei
> > > > > >
> > > > > > > BR
> > > > > > > Rongwei
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > > <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>;
> > > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > > active or standby
> > > > > > > >
> > > > > > > > External email: Use caution opening links or attachments
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > > <rongweil@nvidia.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > versions
> > > > > > > >
> > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > support
> > > > this?
> > > > > > > >
> > > > > > > There is a new member which was introduced into
> > > > > > > rte_eth_dev_info but it
> > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > >
> > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > different ethdev structure and rte_flow structures across
> > > > > > different DPDK
> > > > ABI versions.
> > > > > >
> > > > > Besides this, there is no other ABI changes dependency.
> > > > >
> > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > >
> > > > OK. That's a relief. I understand the use case now.
> > > >
> > > > Why not simply use standard DPDK multiprocess model then.
> > > > Primary process act as server for slow path API. Secondary process
> > > > can come and go(aka can be updated at runtime) and use as client to
> > > > update rules via primary-secondray communication mechanism.
> > > >
> > > Just image if process A and process B have ABI breakage like different
> > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > How can we quickly accommodate primary/secondary to be ABI
> compatible
> > across different versions?
> > > It will be very huge effort and difficult to implement, at least in my
> opinion.
> > > What do you think?
> >
> > Yes. it difficult what ever approach we take, On other hand, ethdev
> subsystem
> > has other components like rte_tm and other offload etc, We can not simply
> > have rte_eth_process_set_active() and things magical works across
> different
> > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > another HW piece in NIC card for doing the metering but set by flow API.
> > IMO, Customer can simply use standard multiprocess model if version are
> > compatible without any special intelligence in application.
> > Otherwise they can reload and start the application again or have special
> > intelligence in application to cater the specific area of API they need to
> > leverage based on server and client DPDK versions.
> 
> Thanks for the message.
> IMO, we are trying to eliminate the version/ABI dependency with this new
> added API.
> For example, if meter action is in the flow rules:
> 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> 2. Process B starts with "rte_eth_process_set_active(false, flags)"
> 
> Just give Nvidia' hardware as example (other NIC vendors may not care if
> group 0 or not)
> If the process A' rules are in group 0, users should set them one by one to
> process B.
> Then either flush process A' rules or quit process A, then process B calls with
> "rte_eth_process_set_active(true, flags)"
> All is set.
> It will avoid complex operations with client/server model and avoid user mis-
> operation too.
> We should avoid reload as much as possible since reloading is very time
> consuming and may take up to few seconds.
> In this time slot, there is no application to handle the traffic, and everything is
> lost.
> For end user especially cloud service providers, they are sensitive to the
> traffic down time.

From my viewpoint the upgrade has nothing to do with DPDK as a library,
the upgrade may be because of application upgrade.
Unless I'm missing something, this API is not meant for API/ABI it is created
to allow minimum downtime when doing upgrade of the application.
Unless I'm missing something critical, since the upgrade in any case is not
only for the DPDK but the entire app, there isn't any ABI/API issue.

^ permalink raw reply	[relevance 4%]

* Re: [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
  2022-12-09  9:02 13%   ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
@ 2022-12-21 15:02  4%     ` David Marchand
  0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-21 15:02 UTC (permalink / raw)
  To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit

On Fri, Dec 9, 2022 at 10:02 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> From: Ferruh Yigit <ferruh.yigit@amd.com>
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to clone for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
> 'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
> repository, or a remote git repository.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
>  DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
>  DPDK_ABI_REF_VERSION=v22.11.1     \
>  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>  ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changes since v1:
> - expanded DPDK_ABI_REF_SRC usage to "non-local" sources,

Series applied, thanks.


-- 
David Marchand


^ permalink raw reply	[relevance 4%]

* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 13:12  0%                 ` Jerin Jacob
@ 2022-12-21 14:33  3%                   ` Rongwei Liu
  2022-12-26 16:44  4%                     ` Ori Kam
  0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 14:33 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

HI Jerin:

BR
Rongwei

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 21:12
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 20:45
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Hi Jerin:
> > > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > HI Jerin:
> > > > > >
> > > > >
> > > > > Hi Rongwei
> > > > >
> > > > > > BR
> > > > > > Rongwei
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@amd.com>;
> > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > active or standby
> > > > > > >
> > > > > > > External email: Use caution opening links or attachments
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > <rongweil@nvidia.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > versions
> > > > > > >
> > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > support
> > > this?
> > > > > > >
> > > > > > There is a new member which was introduced into
> > > > > > rte_eth_dev_info but it
> > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > >
> > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > different ethdev structure and rte_flow structures across
> > > > > different DPDK
> > > ABI versions.
> > > > >
> > > > Besides this, there is no other ABI changes dependency.
> > > >
> > > > Assume there is a DPDK process A running with version v21.11 and
> > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > >
> > > OK. That's a relief. I understand the use case now.
> > >
> > > Why not simply use standard DPDK multiprocess model then.
> > > Primary process act as server for slow path API. Secondary process
> > > can come and go(aka can be updated at runtime) and use as client to
> > > update rules via primary-secondray communication mechanism.
> > >
> > Just image if process A and process B have ABI breakage like different
> rte_flow_item_*** and rte_flow_action_*** size and members.
> > How can we quickly accommodate primary/secondary to be ABI compatible
> across different versions?
> > It will be very huge effort and difficult to implement, at least in my opinion.
> > What do you think?
> 
> Yes. it difficult what ever approach we take, On other hand, ethdev subsystem
> has other components like rte_tm and other offload etc, We can not simply
> have rte_eth_process_set_active() and things magical works across different
> DPDK versions. Example, if rte_flow rule has meter action will depend on
> another HW piece in NIC card for doing the metering but set by flow API.
> IMO, Customer can simply use standard multiprocess model if version are
> compatible without any special intelligence in application.
> Otherwise they can reload and start the application again or have special
> intelligence in application to cater the specific area of API they need to
> leverage based on server and client DPDK versions.

Thanks for the message.
IMO, we are trying to eliminate the version/ABI dependency with this new added API.
For example, if meter action is in the flow rules:
1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
2. Process B starts with "rte_eth_process_set_active(false, flags)"

Just give Nvidia' hardware as example (other NIC vendors may not care if group 0 or not)
If the process A' rules are in group 0, users should set them one by one to process B.
Then either flush process A' rules or quit process A, then process B calls with "rte_eth_process_set_active(true, flags)"
All is set.
It will avoid complex operations with client/server model and avoid user mis-operation too.
We should avoid reload as much as possible since reloading is very time consuming and may take up to few seconds.
In this time slot, there is no application to handle the traffic, and everything is lost.
For end user especially cloud service providers, they are sensitive to the traffic down time.
> 
> 
> > >
> > > >
> > > > Now, process A has been running for long time and has lot of rules
> > > configured. It' "active" role per this API definition.
> > > > Process B starts and it should call this API and set itself to
> > > > "standby" role and user can program the flow rules as they want
> > > > and
> > > different NIC vendors may have different recommendations. Nvidia
> > > suggests only program process B with group 0' rules now.
> > > >
> > > > The user should sync all desired configurations from process A to
> > > > process B, and process A starts to yield traffic like "delete all
> > > > group 0 rules
> > > for Nvidia' NICs" or quit.
> > > > After that process B calls this API and set itself to "active"
> > > > role, now the hot-
> > > upgrade finishes.
> > > >
> > > > > > > > such as hot upgrade.
> > > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > > shorten the traffic downtime as much as possible.
> > > > > > > >
> > > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > > active or standby.
> > > > > > > >
> > > > > > > > The active role means rules are programmed to HW
> > > > > > > > immediately, and no
> > > > > > >
> > > > > > > Why it has to be specific only to rte_flow rule? If it
> > > > > > > spedieic to rte_flow, why it is in rte_eth_process_ name space?
> > > > > > For now, this design focuses on the flow rule offloading and
> > > > > > traffic
> > > > > redirection.
> > > > > > When switching process version, it' important to make sure
> > > > > > which
> > > > > application receives and handles the traffic.
> > > > >
> > > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > > >
> > > > It' not about changing DPDK version but upgrading DPDK from one
> > > > PMD
> > > version to another one.
> > > > Does the preceding example answer your question?
> > > > >
> > > > > > The changing should be effective across all probing eth
> > > > > > devices, that' why it
> > > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > > >
> > > > > > > Also, if we are moving the standby, What about the rule
> > > > > > > whose ABI is changed between versions?
> > > > > >
> > > > > > Like the comments mentioned: " Before role transition, all the
> > > > > > rules set by
> > > > > the active process should be flushed first. "
> > > > >
> > > > > What happens to rte_flow flow handles for existing ones  which
> > > > > is created with version X?
> > > > > Also What if new version Y has ABI change in rte_flow_pattern
> > > > > and rte_flow_action structure?
> > > > >
> > > > > For me, If DPDK version change is needed, simply reload the
> > > > > application. This API will soon bloat, and it will be a mess if
> > > > > to start handling Different DPDK version which is not ABI compatible at
> all.
> > > > >
> > > > Yes, you are right. Reloading the application is the easiest way
> > > > but it may have a long time Window that traffic is lost. No
> > > > traffic arrives at
> > > process A or process B.
> > > > We are trying to simplify the reloading logic and minimize the
> > > > traffic down
> > > time as much as possible.
> > > > The approach may differentiate hugely between different NIC
> > > > vendors, so I think it should be better if DPDK can provide an abstract API.
> > > >
> > > > If process A and process B are ABI different, it doesn't matter.
> > > > 1. Call this API with process A means older ABI.
> > > > 2. Call this API with process B means newer ABI.
> > > > It' have process concept and working scope.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > > > behavior changed. This is the default state.
> > > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > > active roles alive or back to active, the rules are
> > > > > > > > effective
> > > immediately.
> > > > > > > >
> > > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 3%]

* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 12:50  4%               ` Rongwei Liu
@ 2022-12-21 13:12  0%                 ` Jerin Jacob
  2022-12-21 14:33  3%                   ` Rongwei Liu
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 13:12 UTC (permalink / raw)
  To: Rongwei Liu
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 20:45
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Hi Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 19:00
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > HI Jerin:
> > > > >
> > > >
> > > > Hi Rongwei
> > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > Users may want to change the DPDK process to different
> > > > > > > versions
> > > > > >
> > > > > > Different version of DPDK? If there is any ABI change how to support
> > this?
> > > > > >
> > > > > There is a new member which was introduced into rte_eth_dev_info
> > > > > but it
> > > > shouldn’t be ABI breaking since using reserved fields.
> > > >
> > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > different ethdev structure and rte_flow structures across different DPDK
> > ABI versions.
> > > >
> > > Besides this, there is no other ABI changes dependency.
> > >
> > > Assume there is a DPDK process A running with version v21.11 and plan
> > > to upgrade to version v22.11. Let' call v22.11 as process B.
> >
> > OK. That's a relief. I understand the use case now.
> >
> > Why not simply use standard DPDK multiprocess model then.
> > Primary process act as server for slow path API. Secondary process can come
> > and go(aka can be updated at runtime) and use as client to update rules via
> > primary-secondray communication mechanism.
> >
> Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
> How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
> It will be very huge effort and difficult to implement, at least in my opinion.
> What do you think?

Yes. it difficult what ever approach we take,
On other hand, ethdev subsystem has other components like rte_tm and
other offload etc, We can not simply have rte_eth_process_set_active()
and things magical works across different DPDK versions. Example, if
rte_flow rule has meter action will depend on another HW piece in NIC
card for doing the metering but set by flow API.
IMO, Customer can simply use standard multiprocess model if version
are compatible without any special intelligence in application.
Otherwise they can reload and start the application again
or have special intelligence in application to cater the specific area
of API they need to leverage based on server and client DPDK versions.



> >
> > >
> > > Now, process A has been running for long time and has lot of rules
> > configured. It' "active" role per this API definition.
> > > Process B starts and it should call this API and set itself to
> > > "standby" role and user can program the flow rules as they want and
> > different NIC vendors may have different recommendations. Nvidia suggests
> > only program process B with group 0' rules now.
> > >
> > > The user should sync all desired configurations from process A to
> > > process B, and process A starts to yield traffic like "delete all group 0 rules
> > for Nvidia' NICs" or quit.
> > > After that process B calls this API and set itself to "active" role, now the hot-
> > upgrade finishes.
> > >
> > > > > > > such as hot upgrade.
> > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > shorten the traffic downtime as much as possible.
> > > > > > >
> > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > active or standby.
> > > > > > >
> > > > > > > The active role means rules are programmed to HW immediately,
> > > > > > > and no
> > > > > >
> > > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > > For now, this design focuses on the flow rule offloading and
> > > > > traffic
> > > > redirection.
> > > > > When switching process version, it' important to make sure which
> > > > application receives and handles the traffic.
> > > >
> > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > >
> > > It' not about changing DPDK version but upgrading DPDK from one PMD
> > version to another one.
> > > Does the preceding example answer your question?
> > > >
> > > > > The changing should be effective across all probing eth devices,
> > > > > that' why it
> > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > >
> > > > > > Also, if we are moving the standby, What about the rule whose
> > > > > > ABI is changed between versions?
> > > > >
> > > > > Like the comments mentioned: " Before role transition, all the
> > > > > rules set by
> > > > the active process should be flushed first. "
> > > >
> > > > What happens to rte_flow flow handles for existing ones  which is
> > > > created with version X?
> > > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > > rte_flow_action structure?
> > > >
> > > > For me, If DPDK version change is needed, simply reload the
> > > > application. This API will soon bloat, and it will be a mess if to
> > > > start handling Different DPDK version which is not ABI compatible at all.
> > > >
> > > Yes, you are right. Reloading the application is the easiest way but
> > > it may have a long time Window that traffic is lost. No traffic arrives at
> > process A or process B.
> > > We are trying to simplify the reloading logic and minimize the traffic down
> > time as much as possible.
> > > The approach may differentiate hugely between different NIC vendors,
> > > so I think it should be better if DPDK can provide an abstract API.
> > >
> > > If process A and process B are ABI different, it doesn't matter.
> > > 1. Call this API with process A means older ABI.
> > > 2. Call this API with process B means newer ABI.
> > > It' have process concept and working scope.
> > >
> > > >
> > > >
> > > >
> > > > > > > behavior changed. This is the default state.
> > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > active roles alive or back to active, the rules are effective
> > immediately.
> > > > > > >
> > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 0%]

* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 12:44  0%             ` Jerin Jacob
@ 2022-12-21 12:50  4%               ` Rongwei Liu
  2022-12-21 13:12  0%                 ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:50 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

HI Jerin:

BR
Rongwei

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 20:45
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Hi Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 19:00
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > HI Jerin:
> > > >
> > >
> > > Hi Rongwei
> > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > Users may want to change the DPDK process to different
> > > > > > versions
> > > > >
> > > > > Different version of DPDK? If there is any ABI change how to support
> this?
> > > > >
> > > > There is a new member which was introduced into rte_eth_dev_info
> > > > but it
> > > shouldn’t be ABI breaking since using reserved fields.
> > >
> > > That is just for rte_eth_dev_info. What about the ABI change in
> > > different ethdev structure and rte_flow structures across different DPDK
> ABI versions.
> > >
> > Besides this, there is no other ABI changes dependency.
> >
> > Assume there is a DPDK process A running with version v21.11 and plan
> > to upgrade to version v22.11. Let' call v22.11 as process B.
> 
> OK. That's a relief. I understand the use case now.
> 
> Why not simply use standard DPDK multiprocess model then.
> Primary process act as server for slow path API. Secondary process can come
> and go(aka can be updated at runtime) and use as client to update rules via
> primary-secondray communication mechanism.
> 
Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
It will be very huge effort and difficult to implement, at least in my opinion. 
What do you think?
> 
> >
> > Now, process A has been running for long time and has lot of rules
> configured. It' "active" role per this API definition.
> > Process B starts and it should call this API and set itself to
> > "standby" role and user can program the flow rules as they want and
> different NIC vendors may have different recommendations. Nvidia suggests
> only program process B with group 0' rules now.
> >
> > The user should sync all desired configurations from process A to
> > process B, and process A starts to yield traffic like "delete all group 0 rules
> for Nvidia' NICs" or quit.
> > After that process B calls this API and set itself to "active" role, now the hot-
> upgrade finishes.
> >
> > > > > > such as hot upgrade.
> > > > > > There is a strong requirement to simplify the logic and
> > > > > > shorten the traffic downtime as much as possible.
> > > > > >
> > > > > > This update introduces new rte_eth process role definitions:
> > > > > > active or standby.
> > > > > >
> > > > > > The active role means rules are programmed to HW immediately,
> > > > > > and no
> > > > >
> > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > For now, this design focuses on the flow rule offloading and
> > > > traffic
> > > redirection.
> > > > When switching process version, it' important to make sure which
> > > application receives and handles the traffic.
> > >
> > > Changing the DPDK version runtime is just beyond rte_flow driver.
> >
> > It' not about changing DPDK version but upgrading DPDK from one PMD
> version to another one.
> > Does the preceding example answer your question?
> > >
> > > > The changing should be effective across all probing eth devices,
> > > > that' why it
> > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > >
> > > > > Also, if we are moving the standby, What about the rule whose
> > > > > ABI is changed between versions?
> > > >
> > > > Like the comments mentioned: " Before role transition, all the
> > > > rules set by
> > > the active process should be flushed first. "
> > >
> > > What happens to rte_flow flow handles for existing ones  which is
> > > created with version X?
> > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > rte_flow_action structure?
> > >
> > > For me, If DPDK version change is needed, simply reload the
> > > application. This API will soon bloat, and it will be a mess if to
> > > start handling Different DPDK version which is not ABI compatible at all.
> > >
> > Yes, you are right. Reloading the application is the easiest way but
> > it may have a long time Window that traffic is lost. No traffic arrives at
> process A or process B.
> > We are trying to simplify the reloading logic and minimize the traffic down
> time as much as possible.
> > The approach may differentiate hugely between different NIC vendors,
> > so I think it should be better if DPDK can provide an abstract API.
> >
> > If process A and process B are ABI different, it doesn't matter.
> > 1. Call this API with process A means older ABI.
> > 2. Call this API with process B means newer ABI.
> > It' have process concept and working scope.
> >
> > >
> > >
> > >
> > > > > > behavior changed. This is the default state.
> > > > > > The standby role means rules are queued in the HW. If no
> > > > > > active roles alive or back to active, the rules are effective
> immediately.
> > > > > >
> > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 4%]

* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 12:05  5%           ` Rongwei Liu
@ 2022-12-21 12:44  0%             ` Jerin Jacob
  2022-12-21 12:50  4%               ` Rongwei Liu
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 12:44 UTC (permalink / raw)
  To: Rongwei Liu
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Hi Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 19:00
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > HI Jerin:
> > >
> >
> > Hi Rongwei
> >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 17:13
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Users may want to change the DPDK process to different versions
> > > >
> > > > Different version of DPDK? If there is any ABI change how to support this?
> > > >
> > > There is a new member which was introduced into rte_eth_dev_info but it
> > shouldn’t be ABI breaking since using reserved fields.
> >
> > That is just for rte_eth_dev_info. What about the ABI change in different
> > ethdev structure and rte_flow structures across different DPDK ABI versions.
> >
> Besides this, there is no other ABI changes dependency.
>
> Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
> version v22.11. Let' call v22.11 as process B.

OK. That's a relief. I understand the use case now.

Why not simply use standard DPDK multiprocess model then.
Primary process act as server for slow path API. Secondary process can
come and go(aka can be updated at runtime)
and use as client to update rules via primary-secondray communication mechanism.


>
> Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
> Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
> and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.
>
> The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
> rules for Nvidia' NICs" or quit.
> After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.
>
> > > > > such as hot upgrade.
> > > > > There is a strong requirement to simplify the logic and shorten
> > > > > the traffic downtime as much as possible.
> > > > >
> > > > > This update introduces new rte_eth process role definitions:
> > > > > active or standby.
> > > > >
> > > > > The active role means rules are programmed to HW immediately, and
> > > > > no
> > > >
> > > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > > rte_flow, why it is in rte_eth_process_ name space?
> > > For now, this design focuses on the flow rule offloading and traffic
> > redirection.
> > > When switching process version, it' important to make sure which
> > application receives and handles the traffic.
> >
> > Changing the DPDK version runtime is just beyond rte_flow driver.
>
> It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
> Does the preceding example answer your question?
> >
> > > The changing should be effective across all probing eth devices, that' why it
> > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > >
> > > > Also, if we are moving the standby, What about the rule whose ABI is
> > > > changed between versions?
> > >
> > > Like the comments mentioned: " Before role transition, all the rules set by
> > the active process should be flushed first. "
> >
> > What happens to rte_flow flow handles for existing ones  which is created with
> > version X?
> > Also What if new version Y has ABI change in rte_flow_pattern and
> > rte_flow_action structure?
> >
> > For me, If DPDK version change is needed, simply reload the application. This
> > API will soon bloat, and it will be a mess if to start handling Different DPDK
> > version which is not ABI compatible at all.
> >
> Yes, you are right. Reloading the application is the easiest way but it may have a long time
> Window that traffic is lost. No traffic arrives at process A or process B.
> We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
> The approach may differentiate hugely between different NIC vendors, so I think it should be better if
> DPDK can provide an abstract API.
>
> If process A and process B are ABI different, it doesn't matter.
> 1. Call this API with process A means older ABI.
> 2. Call this API with process B means newer ABI.
> It' have process concept and working scope.
>
> >
> >
> >
> > > > > behavior changed. This is the default state.
> > > > > The standby role means rules are queued in the HW. If no active
> > > > > roles alive or back to active, the rules are effective immediately.
> > > > >
> > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 0%]

* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21 10:59  5%         ` Jerin Jacob
@ 2022-12-21 12:05  5%           ` Rongwei Liu
  2022-12-21 12:44  0%             ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:05 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

Hi Jerin:

BR
Rongwei

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 19:00
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
> 
> Hi Rongwei
> 
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 17:13
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Users may want to change the DPDK process to different versions
> > >
> > > Different version of DPDK? If there is any ABI change how to support this?
> > >
> > There is a new member which was introduced into rte_eth_dev_info but it
> shouldn’t be ABI breaking since using reserved fields.
> 
> That is just for rte_eth_dev_info. What about the ABI change in different
> ethdev structure and rte_flow structures across different DPDK ABI versions.
> 
Besides this, there is no other ABI changes dependency.

Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
version v22.11. Let' call v22.11 as process B.

Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.

The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
rules for Nvidia' NICs" or quit.
After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.

> > > > such as hot upgrade.
> > > > There is a strong requirement to simplify the logic and shorten
> > > > the traffic downtime as much as possible.
> > > >
> > > > This update introduces new rte_eth process role definitions:
> > > > active or standby.
> > > >
> > > > The active role means rules are programmed to HW immediately, and
> > > > no
> > >
> > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > rte_flow, why it is in rte_eth_process_ name space?
> > For now, this design focuses on the flow rule offloading and traffic
> redirection.
> > When switching process version, it' important to make sure which
> application receives and handles the traffic.
> 
> Changing the DPDK version runtime is just beyond rte_flow driver.

It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
Does the preceding example answer your question?
> 
> > The changing should be effective across all probing eth devices, that' why it
> was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > >
> > > Also, if we are moving the standby, What about the rule whose ABI is
> > > changed between versions?
> >
> > Like the comments mentioned: " Before role transition, all the rules set by
> the active process should be flushed first. "
> 
> What happens to rte_flow flow handles for existing ones  which is created with
> version X?
> Also What if new version Y has ABI change in rte_flow_pattern and
> rte_flow_action structure?
> 
> For me, If DPDK version change is needed, simply reload the application. This
> API will soon bloat, and it will be a mess if to start handling Different DPDK
> version which is not ABI compatible at all.
> 
Yes, you are right. Reloading the application is the easiest way but it may have a long time
Window that traffic is lost. No traffic arrives at process A or process B. 
We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
The approach may differentiate hugely between different NIC vendors, so I think it should be better if 
DPDK can provide an abstract API.

If process A and process B are ABI different, it doesn't matter. 
1. Call this API with process A means older ABI.
2. Call this API with process B means newer ABI.
It' have process concept and working scope. 

> 
> 
> 
> > > > behavior changed. This is the default state.
> > > > The standby role means rules are queued in the HW. If no active
> > > > roles alive or back to active, the rules are effective immediately.
> > > >
> > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 5%]

* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21  9:32  3%       ` Rongwei Liu
@ 2022-12-21 10:59  5%         ` Jerin Jacob
  2022-12-21 12:05  5%           ` Rongwei Liu
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 10:59 UTC (permalink / raw)
  To: Rongwei Liu
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>

Hi Rongwei

> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 17:13
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Users may want to change the DPDK process to different versions
> >
> > Different version of DPDK? If there is any ABI change how to support this?
> >
> There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.

That is just for rte_eth_dev_info. What about the ABI change in
different ethdev structure and rte_flow structures across different
DPDK ABI versions.

> > > such as hot upgrade.
> > > There is a strong requirement to simplify the logic and shorten the
> > > traffic downtime as much as possible.
> > >
> > > This update introduces new rte_eth process role definitions: active or
> > > standby.
> > >
> > > The active role means rules are programmed to HW immediately, and no
> >
> > Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> > is in rte_eth_process_ name space?
> For now, this design focuses on the flow rule offloading and traffic redirection.
> When switching process version, it' important to make sure which application receives and handles the traffic.

Changing the DPDK version runtime is just beyond rte_flow driver.

> The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
> >
> > Also, if we are moving the standby, What about the rule whose ABI is changed
> > between versions?
>
> Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "

What happens to rte_flow flow handles for existing ones  which is
created with version X?
Also What if new version Y has ABI change in rte_flow_pattern and
rte_flow_action structure?

For me, If DPDK version change is needed, simply reload the
application. This API will soon bloat, and it will be a mess if to
start handling
Different DPDK version which is not ABI compatible at all.




> > > behavior changed. This is the default state.
> > > The standby role means rules are queued in the HW. If no active roles
> > > alive or back to active, the rules are effective immediately.
> > >
> > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>

^ permalink raw reply	[relevance 5%]

* [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
  @ 2022-12-21 10:29  2% ` Jiawei Wang
  2023-01-11 16:47  0%   ` Ori Kam
  0 siblings, 1 reply; 200+ results
From: Jiawei Wang @ 2022-12-21 10:29 UTC (permalink / raw)
  To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
	Ferruh Yigit, Andrew Rybchenko
  Cc: dev, rasland

For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the port
affinity of the received packets.

This patch adds the tx_affinity setting in Tx queue API, the affinity value
reflects packets be sent to which hardware port.

Adds the new tx_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.

This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) affinity (value)

For example, there're two hardware ports connects to a single DPDK
port (port id 0), and affinity 1 stood for hard port 1 and affinity
2 stood for hardware port 2, used the below command to config
tx affinity for each TxQ:
	port config 0 txq 0 affinity 1
	port config 0 txq 1 affinity 1
	port config 0 txq 2 affinity 2
	port config 0 txq 3 affinity 2

These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 1, and similar with hardware port 2 if sending packets
with TxQ 2 or TxQ 3.

Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
 app/test-pmd/cmdline.c                      | 84 +++++++++++++++++++++
 devtools/libabigail.abignore                |  5 ++
 doc/guides/rel_notes/release_22_03.rst      |  4 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
 lib/ethdev/rte_ethdev.h                     |  1 +
 5 files changed, 107 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..683cae1cab 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
 
 			"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
 			"    Cleanup txq mbufs for a specific Tx queue\n\n"
+
+			"port config <port_id> txq <queue_id> affinity <value>\n"
+			"    Set the port affinity value "
+			"on a specific Tx queue\n\n"
 		);
 	}
 
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
 	}
 };
 
+/* *** configure port txq affinity value *** */
+struct cmd_config_tx_affinity {
+	cmdline_fixed_string_t port;
+	cmdline_fixed_string_t config;
+	portid_t portid;
+	cmdline_fixed_string_t txq;
+	uint16_t qid;
+	cmdline_fixed_string_t affinity;
+	uint16_t value;
+};
+
+static void
+cmd_config_tx_affinity_parsed(void *parsed_result,
+				__rte_unused struct cmdline *cl,
+				 __rte_unused void *data)
+{
+	struct cmd_config_tx_affinity *res = parsed_result;
+	struct rte_port *port;
+
+	if (port_id_is_invalid(res->portid, ENABLED_WARN))
+		return;
+
+	if (res->portid == (portid_t)RTE_PORT_ALL) {
+		printf("Invalid port id\n");
+		return;
+	}
+
+	port = &ports[res->portid];
+
+	if (strcmp(res->txq, "txq")) {
+		printf("Unknown parameter\n");
+		return;
+	}
+	if (tx_queue_id_is_invalid(res->qid))
+		return;
+
+	port->txq[res->qid].conf.tx_affinity = res->value;
+
+	cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_affinity_port =
+	TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+				 port, "port");
+cmdline_parse_token_string_t cmd_config_tx_affinity_config =
+	TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+				 config, "config");
+cmdline_parse_token_num_t cmd_config_tx_affinity_portid =
+	TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+				 portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_txq =
+	TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+				 txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_affinity_qid =
+	TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+			      qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_affine =
+	TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+				 affinity, "affinity");
+cmdline_parse_token_num_t cmd_config_tx_affinity_value =
+	TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+			      value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_affinity = {
+	.f = cmd_config_tx_affinity_parsed,
+	.data = (void *)0,
+	.help_str = "port config <port_id> txq <queue_id> affinity <value>",
+	.tokens = {
+		(void *)&cmd_config_tx_affinity_port,
+		(void *)&cmd_config_tx_affinity_config,
+		(void *)&cmd_config_tx_affinity_portid,
+		(void *)&cmd_config_tx_affinity_txq,
+		(void *)&cmd_config_tx_affinity_qid,
+		(void *)&cmd_config_tx_affinity_affine,
+		(void *)&cmd_config_tx_affinity_value,
+		NULL,
+	},
+};
+
 /* ******************************************************************************** */
 
 /* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
 	(cmdline_parse_inst_t *)&cmd_show_capability,
 	(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
 	(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+	(cmdline_parse_inst_t *)&cmd_config_tx_affinity,
 	NULL,
 };
 
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
 [suppress_file]
         soname_regexp = ^librte_.*mlx.*glue\.
 
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+        name = rte_eth_txconf
+        has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ; Experimental APIs exceptions ;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
index 8acd3174f6..0d81ae7bc3 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -212,6 +212,10 @@ API Changes
 * ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
   which are kept for backward compatibility, are marked as deprecated.
 
+* ethdev: added a new field:
+
+  - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
+
 * cryptodev: The asymmetric session handling was modified to use a single
   mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
   to create a mempool with element size big enough to hold the generic asymmetric
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index c0ace56c1f..0c3317ee06 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
 
 This command should be run when the port is stopped, or else it will fail.
 
+config per queue Tx affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a affinity value per queue Tx offloading only on a specific Tx queue::
+
+   testpmd> port (port_id) txq (queue_id) affinity (value)
+
+* ``affinity``: reflects packet can be sent to which hardware port.
+                uses it on multiple hardware ports connect to
+                a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
 Config VXLAN Encap outer layers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 882ca585f2..813dbb34b5 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
 				      less free descriptors than this value. */
 
 	uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+	uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */
 	/**
 	 * Per-queue Tx offloads to be set  using RTE_ETH_TX_OFFLOAD_* flags.
 	 * Only offloads set on tx_queue_offload_capa or tx_offload_capa
-- 
2.18.1


^ permalink raw reply	[relevance 2%]

* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
  2022-12-21  9:12  4%     ` Jerin Jacob
@ 2022-12-21  9:32  3%       ` Rongwei Liu
  2022-12-21 10:59  5%         ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21  9:32 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
	NBU-Contact-Thomas Monjalon (EXTERNAL),
	Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh

HI Jerin:

BR
Rongwei

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 17:13
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Users may want to change the DPDK process to different versions
> 
> Different version of DPDK? If there is any ABI change how to support this?
> 
There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.
> > such as hot upgrade.
> > There is a strong requirement to simplify the logic and shorten the
> > traffic downtime as much as possible.
> >
> > This update introduces new rte_eth process role definitions: active or
> > standby.
> >
> > The active role means rules are programmed to HW immediately, and no
> 
> Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> is in rte_eth_process_ name space?
For now, this design focuses on the flow rule offloading and traffic redirection. 
When switching process version, it' important to make sure which application receives and handles the traffic.
The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
> 
> Also, if we are moving the standby, What about the rule whose ABI is changed
> between versions?

Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "
> > behavior changed. This is the default state.
> > The standby role means rules are queued in the HW. If no active roles
> > alive or back to active, the rules are effective immediately.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > ---
> >  doc/guides/nics/mlx5.rst               | 10 ++++
> >  doc/guides/rel_notes/release_22_03.rst |  5 ++
> >  lib/ethdev/ethdev_driver.h             | 63 ++++++++++++++++++++++++++
> >  lib/ethdev/rte_ethdev.c                | 41 +++++++++++++++++
> >  lib/ethdev/rte_ethdev.h                |  7 ++-
> >  lib/ethdev/version.map                 |  3 ++
> >  6 files changed, 128 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> > 51f51259e3..de1fdac0a1 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -2001,3 +2001,13 @@ where:
> >  * ``sw_queue_id``: queue index in range [64536, 65535].
> >    This range is the highest 1000 numbers.
> >  * ``hw_queue_id``: queue index given by HW in queue creation.
> > +
> > +ethdev set process active or standby
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +User should only program group 0 (fdb_def_rule_en=0) when
> > +``rte_eth_process_set_active`` has been called and set to a standby role.
> > +Group 0 is shared across different DPDK processes while the other
> > +groups are limited to the current process scope.
> > +The process can't move from active to standby role if preceding
> > +active application's rules are still present and vice versa.
> > diff --git a/doc/guides/rel_notes/release_22_03.rst
> > b/doc/guides/rel_notes/release_22_03.rst
> > index 0923707cb8..6fa48106c4 100644
> > --- a/doc/guides/rel_notes/release_22_03.rst
> > +++ b/doc/guides/rel_notes/release_22_03.rst
> > @@ -207,6 +207,11 @@ API Changes
> >  * ethdev: Old public macros and enumeration constants without
> ``RTE_ETH_`` prefix,
> >    which are kept for backward compatibility, are marked as deprecated.
> >
> > +* ethdev: added a new experimental api:
> > +
> > +  The new API ``rte_eth_process_set_active()`` was added.
> > +  If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api
> is not supported.
> > +
> >  * cryptodev: The asymmetric session handling was modified to use a single
> >    mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was
> added
> >    to create a mempool with element size big enough to hold the
> > generic asymmetric diff --git a/lib/ethdev/ethdev_driver.h
> > b/lib/ethdev/ethdev_driver.h index 6a550cfc83..3c583bc39d 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
> >         pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */  }
> > __rte_cache_aligned;
> >
> > +/**@{@name Different rte_eth role flag definitions which will be used
> > + *  when miagrating DPDK to a different version.
> > + */
> > +/*
> > + * Traffic coming from NIC domain rules will reach
> > + * both active and standby processes.
> > + */
> > +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> /**@}*/
> > +
> >  /**
> >   * @internal
> >   * The pool of *rte_eth_dev* structures. The size of the pool @@
> > -1087,6 +1097,22 @@ typedef const uint32_t
> *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
> >   */
> >  typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE
> > *file);
> >
> > +/**
> > + * @internal
> > + * Set rte_eth process to active or standby role.
> > + *
> > + * @param dev
> > + *   Port (ethdev) handle.
> > + * @param active
> > + *   Device (role) active or not (standby).
> > + * @param flag
> > + *   Role specific flag.
> > + *
> > + * @return
> > + *   Negative value on error, 0 on success.
> > + */
> > +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool
> > +active, uint32_t flag);
> > +
> >  /**
> >   * @internal Set Rx queue available descriptors threshold.
> >   * @see rte_eth_rx_avail_thresh_set() @@ -1403,6 +1429,8 @@ struct
> > eth_dev_ops {
> >         eth_cman_config_set_t cman_config_set;
> >         /** Retrieve congestion management configuration */
> >         eth_cman_config_get_t cman_config_get;
> > +       /** Set the whole rte_eth process to active or standby role. */
> > +       eth_process_set_active_t eth_process_set_active;
> >  };
> >
> >  /**
> > @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
> >         struct rte_eth_fdir_flex_conf flex_conf;  };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Set the rte_eth process to the active or standby role which
> > +affects
> > + * the flow rules offloading. It doesn't allow multiple processes to
> > +be the
> > + * same role unless no offload rules are set.
> > + * The active process flow rules are effective immediately while the
> > +standby
> > + * process rules will be matched (active) when the process becomes
> > +active or
> > + * when the traffic is not matched by the active process rules.
> > + * The active application will always receive traffic while the
> > +standby
> > + * application will receive traffic when no matching rules are
> > +present from
> > + * the active application.
> > + *
> > + * The application is active by default if this API is not called.
> > + *
> > + * When a process transforms from a standby to a active role, all
> > +preceding
> > + * flow rules which are queued by hardware will be effective immediately.
> > + * Before role transition, all the rules set by the active process
> > +should be
> > + * flushed first.
> > + *
> > + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set,
> NIC
> > +domain
> > + * flow rules are effective immediately even if a process is standby role.
> > + *
> > + * @param active
> > + *   Process active (role) or not (standby).
> > + * @param flag
> > + *   The role flag.
> > + * @return
> > + *   - (>=0) Number of rte devices which have been switched successfully.
> > + *   - (-EINVAL) if bad parameter.
> > + */
> > +__rte_experimental
> > +int rte_eth_process_set_active(bool active, uint32_t flag);
> > +
> >  #ifdef __cplusplus
> >  }
> >  #endif
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > 5d5e18db1e..f19da75bfe 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -6318,6 +6318,47 @@
> rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t
> *ptypes
> >         return j;
> >  }
> >
> > +int rte_eth_process_set_active(bool active, uint32_t flag) {
> > +       struct rte_eth_dev_info dev_info = {0};
> > +       uint32_t flags[RTE_MAX_ETHPORTS];
> > +       struct rte_eth_dev *dev;
> > +       uint16_t port_id;
> > +       int ret = 0;
> > +
> > +       /* Check if all devices support. */
> > +       RTE_ETH_FOREACH_DEV(port_id) {
> > +               dev = &rte_eth_devices[port_id];
> > +               if (*dev->dev_ops->dev_infos_get == NULL ||
> > +                   *dev->dev_ops->eth_process_set_active == NULL)
> > +                       return -ENOTSUP;
> > +               if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > +                       return -EINVAL;
> > +               if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> > +                       return -ENOTSUP;
> > +       }
> > +       RTE_ETH_FOREACH_DEV(port_id) {
> > +               dev = &rte_eth_devices[port_id];
> > +               if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > +                       goto err;
> > +               flags[port_id] = dev_info.eth_process_flag;
> > +               if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> > +                       goto err;
> > +               ret++;
> > +       }
> > +       return ret;
> > +err:
> > +       if (!ret)
> > +               return 0;
> > +       RTE_ETH_FOREACH_DEV(port_id) {
> > +               dev = &rte_eth_devices[port_id];
> > +               (*dev->dev_ops->eth_process_set_active)(dev, !active,
> flags[port_id]);
> > +               if (--ret == 0)
> > +                       break;
> > +       }
> > +       return 0;
> > +}
> > +
> >  RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
> >
> >  RTE_INIT(ethdev_init_telemetry)
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > c129ca1eaf..d29f051d6f 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
> >  #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP         RTE_BIT64(3)
> >  /** Device supports keeping shared flow objects across restart. */
> > #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> > +/**Device supports "rte_eth_process_set_active" callback. */ #define
> > +RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
> >  /**@}*/
> >
> >  /*
> > @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
> >         struct rte_eth_switch_info switch_info;
> >         /** Supported error handling mode. */
> >         enum rte_eth_err_handle_mode err_handle_mode;
> > +       /** Process specific role flag. */
> > +       uint32_t eth_process_flag;
> >
> > -       uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > +       uint32_t reserved_32s[1]; /**< Reserved for future fields */
> > +       uint64_t reserved_64s[1]; /**< Reserved for future fields */
> >         void *reserved_ptrs[2];   /**< Reserved for future fields */
> >  };
> >
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
> > 17201fbe0f..a5503f6fde 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -298,6 +298,9 @@ EXPERIMENTAL {
> >         rte_flow_get_q_aged_flows;
> >         rte_mtr_meter_policy_get;
> >         rte_mtr_meter_profile_get;
> > +
> > +       # added in 23.03
> > +       rte_eth_process_set_active;
> >  };
> >
> >  INTERNAL {
> > --
> > 2.27.0
> >

^ permalink raw reply	[relevance 3%]

* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
  @ 2022-12-21  9:12  4%     ` Jerin Jacob
  2022-12-21  9:32  3%       ` Rongwei Liu
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21  9:12 UTC (permalink / raw)
  To: Rongwei Liu
  Cc: matan, viacheslavo, orika, thomas, Ferruh Yigit,
	Andrew Rybchenko, dev, rasland

On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Users may want to change the DPDK process to different versions

Different version of DPDK? If there is any ABI change how to support this?

> such as hot upgrade.
> There is a strong requirement to simplify the logic and shorten the
> traffic downtime as much as possible.
>
> This update introduces new rte_eth process role definitions: active
> or standby.
>
> The active role means rules are programmed to HW immediately, and no

Why it has to be specific only to rte_flow rule? If it spedieic to
rte_flow, why it is in rte_eth_process_ name space?

Also, if we are moving the standby, What about the rule whose ABI is
changed between versions?

> behavior changed. This is the default state.
> The standby role means rules are queued in the HW. If no active roles
> alive or back to active, the rules are effective immediately.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> ---
>  doc/guides/nics/mlx5.rst               | 10 ++++
>  doc/guides/rel_notes/release_22_03.rst |  5 ++
>  lib/ethdev/ethdev_driver.h             | 63 ++++++++++++++++++++++++++
>  lib/ethdev/rte_ethdev.c                | 41 +++++++++++++++++
>  lib/ethdev/rte_ethdev.h                |  7 ++-
>  lib/ethdev/version.map                 |  3 ++
>  6 files changed, 128 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 51f51259e3..de1fdac0a1 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -2001,3 +2001,13 @@ where:
>  * ``sw_queue_id``: queue index in range [64536, 65535].
>    This range is the highest 1000 numbers.
>  * ``hw_queue_id``: queue index given by HW in queue creation.
> +
> +ethdev set process active or standby
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +User should only program group 0 (fdb_def_rule_en=0) when ``rte_eth_process_set_active``
> +has been called and set to a standby role.
> +Group 0 is shared across different DPDK processes while the other groups are limited
> +to the current process scope.
> +The process can't move from active to standby role if preceding active application's
> +rules are still present and vice versa.
> diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
> index 0923707cb8..6fa48106c4 100644
> --- a/doc/guides/rel_notes/release_22_03.rst
> +++ b/doc/guides/rel_notes/release_22_03.rst
> @@ -207,6 +207,11 @@ API Changes
>  * ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
>    which are kept for backward compatibility, are marked as deprecated.
>
> +* ethdev: added a new experimental api:
> +
> +  The new API ``rte_eth_process_set_active()`` was added.
> +  If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api is not supported.
> +
>  * cryptodev: The asymmetric session handling was modified to use a single
>    mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
>    to create a mempool with element size big enough to hold the generic asymmetric
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index 6a550cfc83..3c583bc39d 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
>         pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */
>  } __rte_cache_aligned;
>
> +/**@{@name Different rte_eth role flag definitions which will be used
> + *  when miagrating DPDK to a different version.
> + */
> +/*
> + * Traffic coming from NIC domain rules will reach
> + * both active and standby processes.
> + */
> +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> +/**@}*/
> +
>  /**
>   * @internal
>   * The pool of *rte_eth_dev* structures. The size of the pool
> @@ -1087,6 +1097,22 @@ typedef const uint32_t *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
>   */
>  typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE *file);
>
> +/**
> + * @internal
> + * Set rte_eth process to active or standby role.
> + *
> + * @param dev
> + *   Port (ethdev) handle.
> + * @param active
> + *   Device (role) active or not (standby).
> + * @param flag
> + *   Role specific flag.
> + *
> + * @return
> + *   Negative value on error, 0 on success.
> + */
> +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool active, uint32_t flag);
> +
>  /**
>   * @internal Set Rx queue available descriptors threshold.
>   * @see rte_eth_rx_avail_thresh_set()
> @@ -1403,6 +1429,8 @@ struct eth_dev_ops {
>         eth_cman_config_set_t cman_config_set;
>         /** Retrieve congestion management configuration */
>         eth_cman_config_get_t cman_config_get;
> +       /** Set the whole rte_eth process to active or standby role. */
> +       eth_process_set_active_t eth_process_set_active;
>  };
>
>  /**
> @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
>         struct rte_eth_fdir_flex_conf flex_conf;
>  };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Set the rte_eth process to the active or standby role which affects
> + * the flow rules offloading. It doesn't allow multiple processes to be the
> + * same role unless no offload rules are set.
> + * The active process flow rules are effective immediately while the standby
> + * process rules will be matched (active) when the process becomes active or
> + * when the traffic is not matched by the active process rules.
> + * The active application will always receive traffic while the standby
> + * application will receive traffic when no matching rules are present from
> + * the active application.
> + *
> + * The application is active by default if this API is not called.
> + *
> + * When a process transforms from a standby to a active role, all preceding
> + * flow rules which are queued by hardware will be effective immediately.
> + * Before role transition, all the rules set by the active process should be
> + * flushed first.
> + *
> + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set, NIC domain
> + * flow rules are effective immediately even if a process is standby role.
> + *
> + * @param active
> + *   Process active (role) or not (standby).
> + * @param flag
> + *   The role flag.
> + * @return
> + *   - (>=0) Number of rte devices which have been switched successfully.
> + *   - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_process_set_active(bool active, uint32_t flag);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 5d5e18db1e..f19da75bfe 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -6318,6 +6318,47 @@ rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t *ptypes
>         return j;
>  }
>
> +int rte_eth_process_set_active(bool active, uint32_t flag)
> +{
> +       struct rte_eth_dev_info dev_info = {0};
> +       uint32_t flags[RTE_MAX_ETHPORTS];
> +       struct rte_eth_dev *dev;
> +       uint16_t port_id;
> +       int ret = 0;
> +
> +       /* Check if all devices support. */
> +       RTE_ETH_FOREACH_DEV(port_id) {
> +               dev = &rte_eth_devices[port_id];
> +               if (*dev->dev_ops->dev_infos_get == NULL ||
> +                   *dev->dev_ops->eth_process_set_active == NULL)
> +                       return -ENOTSUP;
> +               if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> +                       return -EINVAL;
> +               if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> +                       return -ENOTSUP;
> +       }
> +       RTE_ETH_FOREACH_DEV(port_id) {
> +               dev = &rte_eth_devices[port_id];
> +               if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> +                       goto err;
> +               flags[port_id] = dev_info.eth_process_flag;
> +               if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> +                       goto err;
> +               ret++;
> +       }
> +       return ret;
> +err:
> +       if (!ret)
> +               return 0;
> +       RTE_ETH_FOREACH_DEV(port_id) {
> +               dev = &rte_eth_devices[port_id];
> +               (*dev->dev_ops->eth_process_set_active)(dev, !active, flags[port_id]);
> +               if (--ret == 0)
> +                       break;
> +       }
> +       return 0;
> +}
> +
>  RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
>
>  RTE_INIT(ethdev_init_telemetry)
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index c129ca1eaf..d29f051d6f 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
>  #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP         RTE_BIT64(3)
>  /** Device supports keeping shared flow objects across restart. */
>  #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> +/**Device supports "rte_eth_process_set_active" callback. */
> +#define RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
>  /**@}*/
>
>  /*
> @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
>         struct rte_eth_switch_info switch_info;
>         /** Supported error handling mode. */
>         enum rte_eth_err_handle_mode err_handle_mode;
> +       /** Process specific role flag. */
> +       uint32_t eth_process_flag;
>
> -       uint64_t reserved_64s[2]; /**< Reserved for future fields */
> +       uint32_t reserved_32s[1]; /**< Reserved for future fields */
> +       uint64_t reserved_64s[1]; /**< Reserved for future fields */
>         void *reserved_ptrs[2];   /**< Reserved for future fields */
>  };
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 17201fbe0f..a5503f6fde 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -298,6 +298,9 @@ EXPERIMENTAL {
>         rte_flow_get_q_aged_flows;
>         rte_mtr_meter_policy_get;
>         rte_mtr_meter_profile_get;
> +
> +       # added in 23.03
> +       rte_eth_process_set_active;
>  };
>
>  INTERNAL {
> --
> 2.27.0
>

^ permalink raw reply	[relevance 4%]

* DPDK 21.11.3 released
@ 2022-12-20 16:22  1% Kevin Traynor
  0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2022-12-20 16:22 UTC (permalink / raw)
  To: ktraynor, kevin, announce

Hi all,

Here is a new stable release:
	https://fast.dpdk.org/rel/dpdk-21.11.3.tar.xz

The git tree is at:
	https://dpdk.org/browse/dpdk-stable/?h=21.11

Release notes can be found here:
        http://doc.dpdk.org/guides-21.11/rel_notes/release_21_11.html#id5

This LTS release contains ~300 fixes from main branch
up to DPDK 22.11.

Thanks to the authors who helped with backports and to the
following who helped with validation:
Ubuntu, Intel, Nvidia and Red Hat.

Kevin.

---
 .github/workflows/build.yml                        |  23 +-
 VERSION                                            |   2 +-
 app/dumpcap/main.c                                 |  10 +-
 app/test-eventdev/test_pipeline_common.c           |   4 +-
 app/test-pmd/cmdline.c                             |  62 +++-
 app/test-pmd/config.c                              |   4 -
 app/test-pmd/csumonly.c                            |   6 +
 app/test-pmd/meson.build                           |   1 +
 app/test-pmd/noisy_vnf.c                           |   2 +-
 app/test-pmd/testpmd.c                             |  25 +-
 app/test-pmd/testpmd.h                             |   4 +-
 app/test/test_common.c                             |  56 ++-
 app/test/test_cryptodev.c                          |  20 +-
 app/test/test_cryptodev_asym.c                     |   4 +-
 .../test_cryptodev_security_pdcp_test_vectors.h    | 280 +++++++--------
 app/test/test_efd_perf.c                           |   1 -
 app/test/test_event_timer_adapter.c                |   2 -
 app/test/test_hash_perf.c                          |  11 +-
 app/test/test_hash_readwrite_lf_perf.c             |   1 -
 app/test/test_ipsec.c                              |   9 +-
 app/test/test_member.c                             |   1 -
 app/test/test_member_perf.c                        |   1 -
 app/test/test_pcapng.c                             |  42 ++-
 app/test/test_trace.c                              |  55 +--
 app/test/test_trace.h                              |   2 +
 buildtools/get-numa-count.py                       |   3 +-
 devtools/checkpatches.sh                           |  37 +-
 doc/guides/contributing/abi_policy.rst             |   2 +-
 doc/guides/contributing/abi_versioning.rst         |   2 +-
 doc/guides/cryptodevs/armv8.rst                    |   2 +-
 doc/guides/cryptodevs/bcmfs.rst                    |   2 +-
 doc/guides/freebsd_gsg/build_dpdk.rst              |   2 +-
 doc/guides/gpus/cuda.rst                           |   4 +-
 doc/guides/howto/openwrt.rst                       |   2 +-
 doc/guides/linux_gsg/build_dpdk.rst                |   8 +-
 .../linux_gsg/cross_build_dpdk_for_arm64.rst       |  12 +-
 doc/guides/nics/ark.rst                            |   2 +-
 doc/guides/nics/features.rst                       |   2 +-
 doc/guides/nics/features/bnxt.ini                  |   4 +-
 doc/guides/nics/features/cxgbe.ini                 |   4 +-
 doc/guides/nics/features/default.ini               |   1 +
 doc/guides/nics/features/dpaa2.ini                 |   4 +-
 doc/guides/nics/features/e1000.ini                 |   2 +-
 doc/guides/nics/features/enic.ini                  |   4 +-
 doc/guides/nics/features/hinic.ini                 |   2 +-
 doc/guides/nics/features/hns3.ini                  |   4 +-
 doc/guides/nics/features/i40e.ini                  |   4 +-
 doc/guides/nics/features/iavf.ini                  |   4 +-
 doc/guides/nics/features/ice.ini                   |   4 +-
 doc/guides/nics/features/igc.ini                   |   2 +-
 doc/guides/nics/features/ipn3ke.ini                |   4 +-
 doc/guides/nics/features/ixgbe.ini                 |   4 +-
 doc/guides/nics/features/mlx4.ini                  |   4 +-
 doc/guides/nics/features/mlx5.ini                  |   1 +
 doc/guides/nics/features/mvpp2.ini                 |   4 +-
 doc/guides/nics/features/tap.ini                   |   4 +-
 doc/guides/nics/features/txgbe.ini                 |   4 +-
 doc/guides/nics/intel_vf.rst                       |  17 +
 doc/guides/nics/mlx5.rst                           |   2 +
 doc/guides/nics/mvneta.rst                         |   2 +-
 doc/guides/nics/mvpp2.rst                          |   2 +-
 doc/guides/nics/virtio.rst                         |   2 +-
 doc/guides/platform/bluefield.rst                  |   4 +-
 doc/guides/platform/cnxk.rst                       |   4 +-
 doc/guides/platform/octeontx.rst                   |   8 +-
 doc/guides/prog_guide/build-sdk-meson.rst          |  39 +-
 doc/guides/prog_guide/event_timer_adapter.rst      |  15 +-
 doc/guides/prog_guide/lto.rst                      |   2 +-
 doc/guides/prog_guide/profile_app.rst              |   4 +-
 doc/guides/prog_guide/ring_lib.rst                 |   2 +-
 doc/guides/prog_guide/trace_lib.rst                |  14 +-
 doc/guides/prog_guide/vhost_lib.rst                |   6 +
 doc/guides/rel_notes/release_21_11.rst             | 391 +++++++++++++++++++++
 doc/guides/sample_app_ug/dma.rst                   |   2 +-
 doc/guides/sample_app_ug/vm_power_management.rst   |   4 +-
 doc/guides/testpmd_app_ug/run_app.rst              |   1 +
 doc/guides/testpmd_app_ug/testpmd_funcs.rst        |  12 +-
 doc/guides/tools/dumpcap.rst                       |   4 +-
 doc/guides/tools/proc_info.rst                     |  22 +-
 doc/guides/windows_gsg/build_dpdk.rst              |   4 +-
 drivers/baseband/acc100/rte_acc100_pmd.c           | 324 +++++++++++------
 drivers/baseband/acc100/rte_acc100_pmd.h           |   2 +
 drivers/bus/auxiliary/auxiliary_common.c           |   6 +
 drivers/bus/dpaa/base/qbman/bman.h                 |   4 +-
 drivers/common/cnxk/roc_nix_tm_ops.c               |  60 ++--
 drivers/common/cnxk/roc_npc_mcam.c                 |   4 +-
 drivers/common/cnxk/roc_npc_mcam_dump.c            |   6 +-
 drivers/common/cnxk/roc_npc_utils.c                |   2 +-
 drivers/common/iavf/iavf_adminq.c                  |   3 +-
 drivers/common/mlx5/mlx5_common.c                  |  21 +-
 drivers/common/mlx5/mlx5_common_mr.c               |   1 -
 drivers/common/mlx5/mlx5_common_mr.h               |   1 -
 drivers/common/qat/qat_pf2vf.c                     |   4 +-
 drivers/common/sfc_efx/base/ef10_nic.c             |   2 +-
 drivers/common/sfc_efx/base/rhead_virtio.c         |  12 +-
 drivers/compress/mlx5/meson.build                  |   1 -
 drivers/crypto/mlx5/meson.build                    |   1 -
 drivers/crypto/qat/qat_sym_session.c               |  23 +-
 drivers/dma/idxd/idxd_bus.c                        |   4 +
 drivers/event/cnxk/cn10k_eventdev.c                |   4 +
 drivers/event/cnxk/cn9k_eventdev.c                 |   4 +
 drivers/event/cnxk/cnxk_tim_worker.h               |   1 +
 drivers/event/dlb2/dlb2.c                          |   8 +-
 drivers/event/dsw/dsw_evdev.h                      |   8 +-
 drivers/event/dsw/dsw_event.c                      | 315 ++++++++++++-----
 drivers/event/sw/sw_evdev.c                        |   4 +-
 drivers/event/sw/sw_evdev_selftest.c               |   7 +-
 drivers/mempool/cnxk/cnxk_mempool_ops.c            |   8 +
 drivers/net/atlantic/atl_rxtx.c                    |   5 +-
 drivers/net/axgbe/axgbe_rxtx.c                     | 133 ++++---
 drivers/net/axgbe/axgbe_rxtx.h                     |   6 +
 drivers/net/bnxt/bnxt_ethdev.c                     |   7 +-
 drivers/net/bnxt/bnxt_hwrm.c                       |   2 +-
 drivers/net/bnxt/tf_ulp/ulp_flow_db.h              |   4 +-
 drivers/net/bonding/rte_eth_bond_api.c             |   5 +
 drivers/net/bonding/rte_eth_bond_pmd.c             | 102 +++---
 drivers/net/cnxk/cn10k_rx.h                        |  12 +-
 drivers/net/cnxk/cn10k_tx.h                        |   8 +-
 drivers/net/cnxk/cn9k_tx.h                         |   8 +-
 drivers/net/cnxk/cnxk_ethdev.c                     |   2 +-
 drivers/net/dpaa/dpaa_ethdev.c                     |  23 +-
 drivers/net/dpaa/dpaa_ethdev.h                     |  19 +
 drivers/net/dpaa/dpaa_flow.c                       |  13 +-
 drivers/net/dpaa/dpaa_flow.h                       |   5 +-
 drivers/net/dpaa/dpaa_rxtx.c                       |  87 +++--
 drivers/net/dpaa2/dpaa2_ethdev.c                   |  19 +
 drivers/net/dpaa2/dpaa2_ethdev.h                   |  21 ++
 drivers/net/dpaa2/dpaa2_mux.c                      |   2 +-
 drivers/net/dpaa2/dpaa2_rxtx.c                     | 111 ++++--
 drivers/net/enetfec/enet_ethdev.c                  |   4 +
 drivers/net/enetfec/enet_rxtx.c                    |  29 +-
 drivers/net/failsafe/failsafe_ops.c                |  32 +-
 drivers/net/hns3/hns3_cmd.h                        |   6 +
 drivers/net/hns3/hns3_ethdev.c                     |  30 +-
 drivers/net/hns3/hns3_ethdev.h                     |   3 +-
 drivers/net/hns3/hns3_ethdev_vf.c                  |  25 +-
 drivers/net/hns3/hns3_fdir.c                       |   3 +
 drivers/net/hns3/hns3_flow.c                       | 259 ++++++++------
 drivers/net/hns3/hns3_flow.h                       |   1 +
 drivers/net/hns3/hns3_mbx.c                        |   8 +-
 drivers/net/hns3/hns3_ptp.c                        |   1 -
 drivers/net/hns3/hns3_rss.c                        | 291 ++++++++++-----
 drivers/net/hns3/hns3_rss.h                        |   3 +-
 drivers/net/hns3/hns3_rxtx.c                       | 125 +++----
 drivers/net/hns3/hns3_rxtx_vec.c                   |  20 +-
 drivers/net/hns3/hns3_rxtx_vec_sve.c               |  13 +-
 drivers/net/hns3/hns3_stats.c                      |  26 +-
 drivers/net/i40e/i40e_ethdev.c                     |  45 +--
 drivers/net/i40e/i40e_hash.c                       |  10 +-
 drivers/net/i40e/i40e_vf_representor.c             |   4 +-
 drivers/net/iavf/iavf_ethdev.c                     |   1 +
 drivers/net/iavf/iavf_fdir.c                       |  32 ++
 drivers/net/iavf/iavf_ipsec_crypto.c               |  29 +-
 drivers/net/iavf/iavf_rxtx.c                       |  58 ++-
 drivers/net/iavf/iavf_rxtx.h                       |   2 +
 drivers/net/iavf/iavf_rxtx_vec_avx2.c              | 118 +++++--
 drivers/net/iavf/iavf_rxtx_vec_avx512.c            | 133 +++++--
 drivers/net/iavf/iavf_rxtx_vec_sse.c               | 170 +++++++--
 drivers/net/ice/base/ice_bst_tcam.c                |   6 +-
 drivers/net/ice/base/ice_common.c                  |  12 +-
 drivers/net/ice/base/ice_dcb.c                     |   2 +-
 drivers/net/ice/base/ice_flg_rd.c                  |   4 +-
 drivers/net/ice/base/ice_flow.c                    |  16 +-
 drivers/net/ice/base/ice_imem.c                    |   4 +-
 drivers/net/ice/base/ice_metainit.c                |   4 +-
 drivers/net/ice/base/ice_mk_grp.c                  |   4 +-
 drivers/net/ice/base/ice_parser.c                  |   7 +-
 drivers/net/ice/base/ice_pg_cam.c                  |  12 +-
 drivers/net/ice/base/ice_proto_grp.c               |   4 +-
 drivers/net/ice/base/ice_ptp_hw.c                  |  56 +--
 drivers/net/ice/base/ice_ptype_mk.c                |   4 +-
 drivers/net/ice/base/ice_sched.c                   |  24 +-
 drivers/net/ice/base/ice_switch.c                  |  15 +-
 drivers/net/ice/base/ice_type.h                    |  30 +-
 drivers/net/ice/base/ice_xlt_kb.c                  |  10 +-
 drivers/net/ice/ice_ethdev.c                       |  19 +-
 drivers/net/ice/ice_rxtx.c                         |  44 ++-
 drivers/net/ice/ice_rxtx.h                         |   2 +
 drivers/net/ionic/ionic_dev.c                      |   5 +-
 drivers/net/ionic/ionic_lif.c                      |   6 +-
 drivers/net/ionic/ionic_rx_filter.c                |   2 +-
 drivers/net/ionic/ionic_rxtx.c                     |  29 +-
 drivers/net/ixgbe/ixgbe_ethdev.c                   |  12 +-
 drivers/net/ixgbe/ixgbe_pf.c                       |   8 +-
 drivers/net/memif/rte_eth_memif.c                  |   8 +-
 drivers/net/mlx4/mlx4.c                            |   9 +-
 drivers/net/mlx4/mlx4_mp.c                         |   7 +-
 drivers/net/mlx5/linux/mlx5_ethdev_os.c            |  22 +-
 drivers/net/mlx5/linux/mlx5_mp_os.c                |   6 +-
 drivers/net/mlx5/linux/mlx5_os.c                   |  13 +-
 drivers/net/mlx5/mlx5.c                            |  32 +-
 drivers/net/mlx5/mlx5.h                            |   7 +-
 drivers/net/mlx5/mlx5_devx.c                       |   3 +-
 drivers/net/mlx5/mlx5_flow.c                       | 101 ++++--
 drivers/net/mlx5/mlx5_flow.h                       |  82 +++--
 drivers/net/mlx5/mlx5_flow_dv.c                    | 193 +++++-----
 drivers/net/mlx5/mlx5_flow_meter.c                 |   3 +-
 drivers/net/mlx5/mlx5_flow_verbs.c                 |  23 +-
 drivers/net/mlx5/mlx5_rxq.c                        |  15 +-
 drivers/net/mlx5/mlx5_trigger.c                    |  16 +
 drivers/net/mlx5/mlx5_tx.h                         | 108 +++---
 drivers/net/mlx5/mlx5_utils.c                      |   2 +-
 drivers/net/mlx5/windows/mlx5_flow_os.c            |   2 +-
 drivers/net/mvneta/mvneta_rxtx.c                   |   4 +
 drivers/net/nfp/nfp_common.c                       |   6 +-
 drivers/net/nfp/nfp_ethdev.c                       |  12 +-
 drivers/net/nfp/nfp_ethdev_vf.c                    |   1 -
 drivers/net/nfp/nfp_rxtx.c                         |  12 +-
 drivers/net/nfp/nfpcore/nfp_hwinfo.c               |   2 +-
 drivers/net/ngbe/base/ngbe_eeprom.c                |  32 --
 drivers/net/ngbe/base/ngbe_regs.h                  |   2 +-
 drivers/net/ngbe/base/ngbe_type.h                  |   7 +-
 drivers/net/ngbe/ngbe_ethdev.c                     |  20 +-
 drivers/net/qede/base/ecore_init_fw_funcs.c        |   2 +-
 drivers/net/qede/base/ecore_int.c                  |   4 +-
 drivers/net/tap/tap_flow.c                         |   2 +-
 drivers/net/tap/tap_tcmsgs.c                       |  18 +-
 drivers/net/tap/tap_tcmsgs.h                       |  16 +-
 drivers/net/txgbe/base/txgbe_eeprom.c              |  32 --
 drivers/net/txgbe/base/txgbe_type.h                |   4 +-
 drivers/net/txgbe/txgbe_ethdev.c                   |  11 +-
 drivers/net/txgbe/txgbe_flow.c                     |  33 +-
 drivers/net/virtio/virtio_ethdev.c                 |   7 +
 drivers/vdpa/ifc/ifcvf_vdpa.c                      |  27 +-
 drivers/vdpa/sfc/meson.build                       |   1 -
 examples/fips_validation/main.c                    |   4 +-
 examples/ipsec-secgw/ipsec-secgw.c                 |  21 +-
 examples/ipsec-secgw/sa.c                          |  52 ++-
 examples/l2fwd-crypto/main.c                       |   2 +-
 examples/l3fwd/l3fwd.h                             |   5 +
 examples/l3fwd/l3fwd_event.c                       |   6 +
 examples/l3fwd/main.c                              |   4 +-
 examples/qos_sched/cfg_file.c                      |   2 +-
 examples/qos_sched/profile.cfg                     |   2 -
 examples/vhost/main.c                              |  21 +-
 examples/vm_power_manager/channel_manager.c        |  19 +-
 lib/cryptodev/cryptodev_pmd.c                      |   4 +-
 lib/cryptodev/cryptodev_pmd.h                      |   2 +-
 lib/cryptodev/rte_cryptodev.c                      |  20 +-
 lib/eal/common/eal_common_proc.c                   |  17 +-
 lib/eal/common/eal_common_trace.c                  |  69 ++--
 lib/eal/common/eal_common_trace_ctf.c              |   3 -
 lib/eal/common/eal_common_trace_utils.c            |  11 +-
 lib/eal/common/eal_trace.h                         |   3 +-
 lib/eal/common/malloc_heap.c                       |   2 +-
 lib/eal/common/malloc_mp.c                         |   2 +-
 lib/eal/common/rte_service.c                       |  13 +-
 lib/eal/include/rte_bitmap.h                       |   2 -
 lib/eal/include/rte_common.h                       |   4 +-
 lib/eal/include/rte_hexdump.h                      |   4 -
 lib/eal/include/rte_memzone.h                      |   3 -
 lib/eal/include/rte_uuid.h                         |   4 +-
 lib/eventdev/rte_event_crypto_adapter.c            |  30 +-
 lib/eventdev/rte_event_eth_rx_adapter.h            |   2 +-
 lib/eventdev/rte_event_eth_tx_adapter.c            |  15 +-
 lib/fib/rte_fib.h                                  |   2 -
 lib/fib/rte_fib6.h                                 |   2 -
 lib/graph/rte_graph_worker.h                       |   4 +-
 lib/gro/gro_tcp4.c                                 |   8 +-
 lib/gro/gro_udp4.c                                 |   6 +-
 lib/hash/rte_cuckoo_hash.c                         |   1 +
 lib/hash/rte_thash.h                               |   2 -
 lib/ipsec/esp_outb.c                               |   8 +-
 lib/ipsec/rte_ipsec_sad.h                          |   2 -
 lib/kni/rte_kni.h                                  |   4 +-
 lib/lpm/rte_lpm.h                                  |   2 -
 lib/lpm/rte_lpm6.h                                 |   2 -
 lib/mbuf/rte_mbuf.h                                |   3 -
 lib/mempool/rte_mempool.c                          |  55 +--
 lib/mempool/rte_mempool.h                          |   3 +-
 lib/net/rte_ip.h                                   |  17 +-
 lib/node/ethdev_ctrl.c                             |   2 +
 lib/pcapng/rte_pcapng.c                            |  47 ++-
 lib/pdump/rte_pdump.c                              |   6 +
 lib/power/rte_power.h                              |  55 ---
 lib/reorder/rte_reorder.h                          |   2 -
 lib/rib/rte_rib.h                                  |   2 -
 lib/rib/rte_rib6.h                                 |   2 -
 lib/ring/rte_ring.h                                |  15 +-
 lib/ring/rte_ring_core.h                           |   4 +-
 lib/ring/rte_ring_elem.h                           |   1 -
 lib/ring/rte_ring_elem_pvt.h                       |  10 +
 lib/sched/rte_sched.c                              |   2 -
 lib/timer/rte_timer.c                              |  13 +-
 lib/vhost/rte_vhost.h                              |  15 +
 lib/vhost/rte_vhost_async.h                        |  18 +-
 lib/vhost/version.map                              |   1 +
 lib/vhost/vhost.c                                  |  30 ++
 lib/vhost/vhost_user.c                             |   1 +
 lib/vhost/virtio_net.c                             |  12 +-
 meson.build                                        |   2 +-
 291 files changed, 3988 insertions(+), 2219 deletions(-)
Abdullah Sevincer (1):
      event/dlb2: handle enqueuing more than maximum depth

Abhimanyu Saini (1):
      common/sfc_efx/base: remove VQ index check during VQ start

Aleksandr Miloshenko (1):
      net/iavf: fix Tx done descriptors cleanup

Alex Kiselev (1):
      net/tap: fix overflow of network interface index

Alexander Chernavin (1):
      net/virtio: fix crash when configured twice

Alexander Kozyrev (3):
      net/mlx5: fix shared Rx queue config reuse
      net/mlx5: fix first segment inline length
      net/mlx5: fix indexed pool local cache crash

Ali Alnubani (2):
      examples/l2fwd-crypto: fix typo in error message
      lib: remove empty return types from doxygen comments

Amit Prakash Shukla (6):
      net/mvneta: fix build with GCC 12
      test/ipsec: fix build with GCC 12
      ipsec: fix build with GCC 12
      crypto/qat: fix build with GCC 12
      net/i40e: fix build with MinGW GCC 12
      net/qede/base: fix 32-bit build with GCC 12

Andrew Boyer (5):
      net/ionic: fix endianness for Rx and Tx
      net/ionic: fix endianness for RSS
      net/ionic: fix adapter name for logging
      net/ionic: fix Rx filter save
      net/ionic: fix reported error stats

Anoob Joseph (1):
      test/crypto: fix PDCP vectors

Apeksha Gupta (2):
      net/enetfec: fix restart
      net/enetfec: fix buffer leak

Arek Kusztal (1):
      common/qat: fix VF to PF answer

Ashwin Sekhar T K (1):
      mempool/cnxk: fix destroying empty pool

Ben Magistro (1):
      doc: fix dumpcap interface parameter option

Benjamin Le Berre (1):
      net/bnxt: fix error code during MTU change

Bhagyada Modali (9):
      net/axgbe: fix scattered Rx
      net/axgbe: fix mbuf lengths in scattered Rx
      net/axgbe: fix length of each segment in scattered Rx
      net/axgbe: fix checksum and RSS in scattered Rx
      net/axgbe: optimise scattered Rx
      net/axgbe: remove freeing buffer in scattered Rx
      net/axgbe: reset end of packet in scattered Rx
      net/axgbe: clear buffer on scattered Rx chaining failure
      net/axgbe: save segment data in scattered Rx

Bing Zhao (2):
      net/mlx5: fix build with recent compilers
      bus/auxiliary: prevent device from being probed again

Brian Dooley (1):
      crypto/qat: fix null hash algorithm digest size

Changpeng Liu (1):
      vhost: add non-blocking API for posting interrupt

Chaoyong He (1):
      net/nfp: fix Rx descriptor DMA address

Chengwen Feng (8):
      net/hns3: fix crash in SVE Tx
      net/hns3: fix next-to-use overflow in SVE Tx
      net/hns3: fix next-to-use overflow in simple Tx
      net/hns3: fix crash when secondary process access FW
      net/hns3: revert Tx performance optimization
      net/hns3: revert fix mailbox communication with HW
      net/hns3: fix VF mailbox message handling
      app/testpmd: remove jumbo offload

Ciara Power (1):
      test/crypto: fix wireless auth digest segment

Conor Walsh (1):
      doc: fix reference to dma application example

Dariusz Sosnowski (1):
      net/mlx5: fix hairpin split with set VLAN VID action

David Marchand (23):
      vhost: fix virtqueue use after free on NUMA reallocation
      app/testpmd: restore ixgbe bypass commands
      net/failsafe: fix interrupt handle leak
      net/bnxt: fix build with GCC 13
      trace: fix mode for new trace point
      trace: fix mode change
      trace: fix leak with regexp
      trace: fix dynamically enabling trace points
      trace: fix race in debug dump
      ci: bump versions of actions in GHA
      ci: update to new API for step outputs in GHA
      service: fix build with clang 15
      vhost: fix build with clang 15
      bus/dpaa: fix build with clang 15
      net/atlantic: fix build with clang 15
      net/dpaa2: fix build with clang 15
      app/testpmd: fix build with clang 15
      app/testpmd: fix build with clang 15 in flow code
      test/efd: fix build with clang 15
      test/member: fix build with clang 15
      test/event: fix build with clang 15
      ci: enable ABI check in GHA
      trace: fix metadata dump

Dmitry Kozlyuk (4):
      build: enable developer mode for all working trees
      eal: fix side effect in some pointer arithmetic macros
      mempool: make event callbacks process-private
      common/mlx5: fix multi-process mempool registration

Dong Zhou (1):
      net/mlx5: fix thread workspace memory leak

Dongdong Liu (2):
      doc: fix application name in procinfo guide
      doc: document device dump in procinfo guide

Erik Gabriel Carrillo (1):
      service: fix early move to inactive status

Fidaullah Noonari (1):
      malloc: fix storage size for some allocations

Frank Du (1):
      net/ice: fix interrupt handler unregister

Gagandeep Singh (5):
      net/dpaa: fix buffer freeing in slow path
      net/dpaa: use internal mempool for SG table
      net/dpaa: fix buffer freeing on SG Tx
      net/dpaa2: use internal mempool for SG table
      net/dpaa2: fix buffer freeing on SG Tx

Ganapati Kundapura (1):
      eventdev/crypto: fix multi-process

Gregory Etelson (6):
      net/mlx5: fix RSS expansion buffer size
      app/testpmd: fix MAC header in checksum forward engine
      common/mlx5: fix shared mempool subscription
      net/mlx5: fix port initialization with small LRO
      net/mlx5: fix maximum LRO message size
      doc: add LRO size limitation in mlx5 guide

Haiyue Wang (1):
      ring: fix description

Hamza Khan (1):
      examples/vm_power_manager: use safe list iterator

Hanumanth Pothula (1):
      net/cnxk: fix DF bit in vector mode

Hernan Vargas (14):
      baseband/acc100: fix memory leak
      baseband/acc100: check turbo dec/enc input
      baseband/acc100: add null checks
      baseband/acc100: fix input length for CRC24B
      baseband/acc100: fix clearing PF IR outside handler
      baseband/acc100: fix device minimum alignment
      baseband/acc100: fix close cleanup
      baseband/acc100: add LDPC encoder padding function
      baseband/acc100: check AQ availability
      baseband/acc100: fix ring availability calculation
      baseband/acc100: enforce additional check on FCW
      baseband/acc100: fix null HARQ input case
      baseband/acc100: fix ring/queue allocation
      baseband/acc100: fix double MSI intr in TB mode

Huisong Li (18):
      net/hns3: fix Rx with PTP
      net/hns3: delete unused markup
      net/hns3: fix clearing hardware MAC statistics
      net/hns3: fix RSS filter restore
      net/hns3: fix RSS flow rule restore
      net/hns3: move flow direction rule recovery
      net/hns3: fix packet type for GENEVE
      net/hns3: fix IPv4 and IPv6 RSS
      net/hns3: fix typos in IPv6 SCTP fields
      net/hns3: fix IPv4 RSS
      net/hns3: add L3 and L4 RSS types
      net/bonding: fix slave device Rx/Tx offload configuration
      net/bonding: fix dropping valid MAC packets
      net/bonding: fix mbuf fast free handling
      net/hns3: extract functions to create RSS and FDIR flow rule
      net/hns3: fix RSS rule restore
      net/hns3: fix lock protection of RSS flow rule
      net/hns3: fix restore filter function input

Huzaifa Rahman (1):
      net/memif: fix crash with different number of Rx/Tx queues

Ilya Maximets (1):
      doc: fix support table for Ethernet/VLAN flow items

Ivan Malov (4):
      common/sfc_efx/base: fix maximum Tx data count
      net/bonding: fix descriptor limit reporting
      net/bonding: fix flow flush order on close
      net/bonding: set initial value of descriptor count alignment

James Hershaw (1):
      net/nfp: improve HW info header log readability

Jeremy Spewock (1):
      test/ipsec: skip if no compatible device

Jerin Jacob (2):
      eal: fix doxygen comments for UUID
      power: fix some doxygen comments

Jiawei Wang (4):
      net/mlx5: fix modify action with tunnel decapsulation
      net/mlx5: fix tunnel header with IPIP offload
      net/mlx5: fix source port checking in sample flow rule
      net/mlx5: fix mirror flow validation with ASO action

Jiawen Wu (6):
      net/txgbe: fix IPv6 flow rule
      net/txgbe: remove semaphore between SW/FW
      net/txgbe: rename some extended statistics
      net/ngbe: rename some extended statistics
      net/ngbe: remove semaphore between SW/FW
      net/ngbe: fix maximum frame size

Jie Hai (1):
      net/hns3: fix minimum Tx frame length

Jie Wang (1):
      net/i40e: fix jumbo frame Rx with X722

Jun Qiu (3):
      gro: trim tail padding bytes
      net/bonding: fix Tx hash for TCP
      hash: fix RCU configuration memory leak

Kai Ji (1):
      test/crypto: fix bitwise operator in a SNOW3G case

Kalesh AP (2):
      net/bnxt: remove unnecessary check
      net/bnxt: fix representor info freeing

Ke Zhang (2):
      net/i40e: fix VF representor release
      net/iavf: fix L3 checksum Tx offload flag

Kevin Liu (2):
      net/iavf: check illegal packet sizes
      net/ice: check illegal packet sizes

Kevin Traynor (9):
      Revert "cryptodev: fix missing SHA3 algorithm strings"
      version: 21.11.3-rc1
      Revert "net/i40e: fix jumbo frame Rx with X722"
      Revert "net/i40e: fix max frame size config at port level"
      Revert "net/i40e: enable maximum frame size at port level"
      Revert "net/iavf: add thread for event callbacks"
      vhost: fix doxygen warnings
      ring: squash gcc 12.2.1 warnings
      version: 21.11.3

Kumara Parameshwaran (1):
      gro: check payload length after trim

Long Li (2):
      net/mlx4: fix Verbs FD leak in secondary process
      net/mlx5: fix Verbs FD leak in secondary process

Long Wu (1):
      net/nfp: fix memory leak in Rx

Luca Boccassi (1):
      drivers: fix typos found by Lintian

Mao YingMing (1):
      net/bnxt: fix null pointer dereference in LED config

Mattias Rönnblom (3):
      net: accept unaligned data in checksum routines
      event/dsw: fix flow migration
      doc: fix event timer adapter guide

Maxime Coquelin (1):
      vhost: fix build with GCC 12

Megha Ajmera (2):
      sched: fix subport profile configuration
      examples/qos_sched: fix number of subport profiles

Michael Baum (5):
      net/mlx5: fix null check in devargs parsing
      doc: fix underlines in testpmd guide
      doc: fix colons in testpmd aged flow rules
      net/mlx5: fix race condition in counter pool resizing
      net/mlx5: fix port event cleaning order

Mingjin Ye (4):
      net/ice: support VXLAN-GPE tunnel offload
      net/i40e: fix pctype configuration for X722
      net/ice: fix scalar Rx path segment
      net/ice: fix scalar Tx path segment

Mário Kuka (1):
      pcapng: fix write more packets than IOV_MAX limit

Naga Harish K S V (4):
      eventdev/eth_tx: add spinlock for adapter start/stop
      eventdev/eth_tx: fix adapter stop
      timer: fix stopping all timers
      eventdev/eth_tx: fix queue delete

Nithin Dabilpuram (3):
      examples/ipsec-secgw: use Tx checksum offload conditionally
      examples/l3fwd: fix MTU configuration with event mode
      net/cnxk: fix later skip to include mbuf private data

Olivier Matz (8):
      cryptodev: fix unduly newlines in logs
      mem: fix API doc about allocation on secondary processes
      event/sw: fix flow ID init in self test
      event/sw: fix log in self test
      net/ixgbe: fix broadcast Rx on VF after promisc removal
      net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
      net/ixgbevf: fix promiscuous and allmulti
      devtools: fix checkpatch header retrieval from stdin

Pablo de Lara (1):
      examples/fips_validation: fix typo in error log

Pavan Nikhilesh (3):
      event/cnxk: fix missing xstats operations
      event/cnxk: fix mbuf offset calculation
      event/cnxk: fix missing mempool cookie marking

Peng Zhang (3):
      net/nfp: compose firmware file name with new hwinfo
      buildtools: fix NUMA nodes count
      net/nfp: fix internal buffer size and MTU check

Qi Zhang (12):
      net/ice/base: fix division during E822 PTP init
      net/ice/base: fix 100M speed capability
      net/ice/base: fix DSCP PFC TLV creation
      net/ice/base: fix media type of PHY 10G SFI C2C
      net/ice/base: fix function descriptions for parser
      net/ice/base: fix endian format
      net/ice/base: fix array overflow in add switch recipe
      net/ice/base: fix bit finding range over ptype bitmap
      net/ice/base: fix add MAC rule
      net/ice/base: fix double VLAN in promiscuous mode
      net/ice/base: ignore promiscuous already exist
      net/ice/base: fix input set of GTPoGRE

Qiming Yang (1):
      app/testpmd: skip port reset in secondary process

Radu Nicolau (6):
      net/iavf: update IPsec ESN values when updating session
      net/iavf: fix IPsec flow create error check
      net/iavf: fix SPI check
      net/iavf: fix queue stop for large VF
      examples/ipsec-secgw: fix Tx checksum offload flag
      examples/ipsec-secgw: fix Tx checksum offload flag

Raja Zidane (1):
      net/mlx5: fix Tx check for hardware descriptor length

Rohit Raj (1):
      net/dpaa: fix jumbo packet Rx in case of VSP

Satha Rao (1):
      common/cnxk: fix schedule weight update

Satheesh Paul (3):
      common/cnxk: fix log level during MCAM allocation
      common/cnxk: fix missing flow counter reset
      common/cnxk: fix printing disabled MKEX registers

Shiqi Liu (2):
      node: check Rx element allocation
      dma/idxd: check DSA device allocation

Shun Hao (4):
      net/mlx5: fix meter profile delete after disable
      net/mlx5: fix action flag data type
      net/mlx5: fix drop action validation
      net/mlx5: fix assert when creating meter policy

Stephen Coleman (1):
      doc: fix typo depreciated instead of deprecated

Stephen Hemminger (8):
      event/sw: fix device name in dump
      eal: fix data race in multi-process support
      pdump: do not allow enable/disable in primary process
      app/dumpcap: fix crash on cleanup
      app/dumpcap: fix pathname for output file
      app/testpmd: make quit flag volatile
      ring: remove leftover comment about watermark
      doc: avoid meson deprecation in setup

Steve Yang (1):
      net/iavf: fix pattern check for flow director parser

Steven Zou (1):
      common/iavf: avoid copy in async mode

Sunyang Wu (1):
      test/crypto: fix debug messages

Taekyung Kim (1):
      vdpa/ifc: handle data path update failure

Tal Shnaiderman (1):
      net/mlx5: fix thread termination check on Windows

Thomas Monjalon (2):
      drivers: remove unused build variable
      doc: add Rx buffer split capability for mlx5

Ting Xu (1):
      net/ice/base: fix inner symmetric RSS hash in raw flow

Tomasz Jonak (1):
      net/ice: fix null function pointer call

Vanshika Shukla (1):
      net/dpaa2: fix DPDMUX error behaviour

Viacheslav Ovsiienko (3):
      net/mlx5: fix check for orphan wait descriptor
      net/mlx5: fix single not inline packet storing
      net/mlx5: fix inline length exceeding descriptor limit

Vladimir Medvedkin (2):
      test/hash: remove dead code in extendable bucket test
      test/hash: fix bulk lookup check

Volodymyr Fialko (3):
      cryptodev: fix missing SHA3 algorithm strings
      eventdev: fix name of Rx conf type in documentation
      app/eventdev: fix limits in error message

Wenwu Ma (1):
      examples/vhost: fix use after free

Wenzhuo Lu (1):
      net/iavf: fix VLAN offload

Yi Li (1):
      doc: fix maximum packet size of virtio driver

Yiding Zhou (4):
      net/iavf: fix VLAN insertion
      net/iavf: revert VLAN insertion fix
      net/ice/base: fix duplicate flow rules
      net/iavf: add thread for event callbacks

Yunjian Wang (2):
      net/bonding: fix array overflow in Rx burst
      net/bonding: fix double slave link status query

Zhichao Zeng (3):
      net/ice: fix RSS hash update
      net/iavf: fix processing VLAN TCI in SSE path
      net/iavf: fix outer checksum flags

Zhirun Yan (1):
      graph: fix node objects allocation


^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
  2022-12-19 10:37  0%         ` Thomas Monjalon
@ 2022-12-19 13:22  0%           ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-19 13:22 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand

On Mon, Dec 19, 2022 at 11:37:19AM +0100, Thomas Monjalon wrote:
> 15/12/2022 14:58, Bruce Richardson:
> > On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > > 15/12/2022 10:44, Bruce Richardson:
> > > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > > than the existing "u64" one, we can for now:
> > > > > > * rename all internal values to use uint rather than u64
> > > > > > * add new function names to alias the existing u64 ones
> > > > > > 
> > > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > 
> > > > > when adding __rte_experimental api i have been asked to add the
> > > > > following boilerplate documentation block. i'm not pushing it, just
> > > > > recalling it is what i get asked for, so in case it's something we do?
> > > > > see lib/eal/include/rte_thread.h as an example
> > > > > 
> > > > > 
> > > > > ```
> > > > >  * @warning
> > > > >  * @b EXPERIMENTAL: this API may change without prior notice.
> > > > > ```
> > > > >
> > > > 
> > > > Ok, thanks for the notice.
> > > > 
> > > > Actually, related to this, since we are adding these functions as aliases
> > > > for existing stable functions, I would like to see these being added not as
> > > > experimental. The reason for that, is that while they are experimental, we
> > > > cannot feasibly mark the old function names as deprecated. :-(
> > > > 
> > > > Adding Thomas and David on CC for their thoughts.
> > > 
> > > Is it related to telemetry?
> > > 
> > > In general, yes we cannot deprecate something if there is no stable replacement.
> > > The recommended step is to introduce a new experimental API
> > > and deprecate the old one when the new API is stable.
> > > 
> > Yes, understood.
> > What we are really trying to do here is to rename an API, by process of
> > adding the new API and then marking the old one as deprecated. The small
> > issue is that adding the new one it is by default experimental, meaning we
> > need to wait for deprecating old one. Ideally, as soon as the new API is
> > added, we would like to point people to use that, but can't really do so
> > while it is experimental.
> > 
> > ---
> > 
> > By way of explicit detail, Morten pointed out the inconsistency in the
> > telemetry APIs and types:
> > 
> > * we have add_*_int, which takes a 32-bit signed value
> > * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
> > 
> > The ideal end-state is to always use 64-bit values (since there is no space
> > saving from 32-bit as a union is used), and just name everything as "int"
> > or "uint" for signed/unsigned. The two big steps here are:
> > 
> > * expanding type of the "int" functions to take 64-bit parameters - this is
> >   ABI change but not API one, since existing code will happily promote
> >   values on compile. Therefore, we just use ABI versioning to have a 32-bit
> >   version for older linked binaries.
> > * the rename of the rte_tel_data_add_array_u64 and
> >   rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
> >   compatibility is easier, as we can just add new functions, the overall
> >   process is slower since the new functions technically should be added as
> >   experimental - hence the email. For the case of function renaming, do we
> >   still need to have the "renamed" versions as experimental initially?
> 
> If a function is simply renamed, I think there is no need for the experimental step.
> Would we keep an alias with the old name for some time?
> 
Yes, the old name should go through the deprecation process. No 
hurry with removal.

/Bruce

^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
  2022-12-15 13:58  4%       ` Bruce Richardson
@ 2022-12-19 10:37  0%         ` Thomas Monjalon
  2022-12-19 13:22  0%           ` Bruce Richardson
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-19 10:37 UTC (permalink / raw)
  To: Bruce Richardson; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand

15/12/2022 14:58, Bruce Richardson:
> On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > 15/12/2022 10:44, Bruce Richardson:
> > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > than the existing "u64" one, we can for now:
> > > > > * rename all internal values to use uint rather than u64
> > > > > * add new function names to alias the existing u64 ones
> > > > > 
> > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > 
> > > > when adding __rte_experimental api i have been asked to add the
> > > > following boilerplate documentation block. i'm not pushing it, just
> > > > recalling it is what i get asked for, so in case it's something we do?
> > > > see lib/eal/include/rte_thread.h as an example
> > > > 
> > > > 
> > > > ```
> > > >  * @warning
> > > >  * @b EXPERIMENTAL: this API may change without prior notice.
> > > > ```
> > > >
> > > 
> > > Ok, thanks for the notice.
> > > 
> > > Actually, related to this, since we are adding these functions as aliases
> > > for existing stable functions, I would like to see these being added not as
> > > experimental. The reason for that, is that while they are experimental, we
> > > cannot feasibly mark the old function names as deprecated. :-(
> > > 
> > > Adding Thomas and David on CC for their thoughts.
> > 
> > Is it related to telemetry?
> > 
> > In general, yes we cannot deprecate something if there is no stable replacement.
> > The recommended step is to introduce a new experimental API
> > and deprecate the old one when the new API is stable.
> > 
> Yes, understood.
> What we are really trying to do here is to rename an API, by process of
> adding the new API and then marking the old one as deprecated. The small
> issue is that adding the new one it is by default experimental, meaning we
> need to wait for deprecating old one. Ideally, as soon as the new API is
> added, we would like to point people to use that, but can't really do so
> while it is experimental.
> 
> ---
> 
> By way of explicit detail, Morten pointed out the inconsistency in the
> telemetry APIs and types:
> 
> * we have add_*_int, which takes a 32-bit signed value
> * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
> 
> The ideal end-state is to always use 64-bit values (since there is no space
> saving from 32-bit as a union is used), and just name everything as "int"
> or "uint" for signed/unsigned. The two big steps here are:
> 
> * expanding type of the "int" functions to take 64-bit parameters - this is
>   ABI change but not API one, since existing code will happily promote
>   values on compile. Therefore, we just use ABI versioning to have a 32-bit
>   version for older linked binaries.
> * the rename of the rte_tel_data_add_array_u64 and
>   rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
>   compatibility is easier, as we can just add new functions, the overall
>   process is slower since the new functions technically should be added as
>   experimental - hence the email. For the case of function renaming, do we
>   still need to have the "renamed" versions as experimental initially?

If a function is simply renamed, I think there is no need for the experimental step.
Would we keep an alias with the old name for some time?



^ permalink raw reply	[relevance 0%]

* [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
                     ` (5 preceding siblings ...)
  2022-12-16  1:54  3% ` [PATCH V7 " Huisong Li
@ 2022-12-19  7:06  3% ` Huisong Li
  2023-01-16 12:06  0%   ` lihuisong (C)
  6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-19  7:06 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v8: fix the coding style in patch 7/8
 -v7: replace sprintf with snprintf in patch 6/8
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 309 insertions(+), 30 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* Re: 21.11.3 patches review and test
  2022-12-06 11:29  1% 21.11.3 patches review and test Kevin Traynor
  2022-12-13 11:48  0% ` Christian Ehrhardt
@ 2022-12-16  7:55  0% ` YangHang Liu
  1 sibling, 0 replies; 200+ results
From: YangHang Liu @ 2022-12-16  7:55 UTC (permalink / raw)
  To: Kevin Traynor
  Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
	David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
	John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
	qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yuan.peng,
	zhaoyan.chen, Chao Yang

[-- Attachment #1: Type: text/plain, Size: 19006 bytes --]

Hi Kevin,

RedHat QE does not find new issues about the 21.11.3 dpdk during the tests.

We tested below 17 scenarios and all got PASS on RHEL8:

   - Guest with device assignment(PF) throughput testing(1G hugepage size):
   PASS
   - Guest with device assignment(PF) throughput testing(2M hugepage size)
   : PASS
   - Guest with device assignment(VF) throughput testing: PASS
   - PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
   - PVP vhost-user 2Q throughput testing: PASS
   - PVP vhost-user 1Q - cross numa node throughput testing: PASS
   - Guest with vhost-user 2 queues throughput testing: PASS
   - vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect:
   PASS
   - vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
   - PVP 1Q live migration testing: PASS
   - PVP 1Q cross numa node live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
   - Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
   - Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
   - Host PF + DPDK testing: PASS
   - Host VF + DPDK testing: PASS

Versions:

   - kernel 4.18
   - qemu-kvm-6.2
   - DPDK
      - commit 0bb6905a88784306878d9fceb0aa1c1ec68d1397 (tag: v21.11.3-rc1)
      Author: Kevin Traynor <ktraynor@redhat.com>
      Date:   Mon Dec 5 11:53:33 2022 +0000
          version: 21.11.3-rc1
          Signed-off-by: Kevin Traynor <ktraynor@redhat.com>


NICs: X540-AT2 NIC(ixgbe, 10G)


Best Regards,
YangHang Liu


On Tue, Dec 6, 2022 at 7:29 PM Kevin Traynor <ktraynor@redhat.com> wrote:

> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
>     https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
>     https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
>       event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
>       common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
>       net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
>       net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
>       net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
>       net/mlx5: fix shared Rx queue config reuse
>       net/mlx5: fix first segment inline length
>       net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
>       examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
>       net/mvneta: fix build with GCC 12
>       test/ipsec: fix build with GCC 12
>       ipsec: fix build with GCC 12
>       crypto/qat: fix build with GCC 12
>       net/i40e: fix build with MinGW GCC 12
>       net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
>       net/ionic: fix endianness for Rx and Tx
>       net/ionic: fix endianness for RSS
>       net/ionic: fix adapter name for logging
>       net/ionic: fix Rx filter save
>       net/ionic: fix reported error stats
>
> Anoob Joseph (1):
>       test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
>       net/enetfec: fix restart
>       net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
>       common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
>       mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
>       doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
>       net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
>       net/axgbe: fix scattered Rx
>       net/axgbe: fix mbuf lengths in scattered Rx
>       net/axgbe: fix length of each segment in scattered Rx
>       net/axgbe: fix checksum and RSS in scattered Rx
>       net/axgbe: optimise scattered Rx
>       net/axgbe: remove freeing buffer in scattered Rx
>       net/axgbe: reset end of packet in scattered Rx
>       net/axgbe: clear buffer on scattered Rx chaining failure
>       net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
>       net/mlx5: fix build with recent compilers
>       bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
>       crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
>       vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
>       net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
>       net/hns3: fix crash in SVE Tx
>       net/hns3: fix next-to-use overflow in SVE Tx
>       net/hns3: fix next-to-use overflow in simple Tx
>       net/hns3: fix crash when secondary process access FW
>       net/hns3: revert Tx performance optimization
>       net/hns3: revert fix mailbox communication with HW
>       net/hns3: fix VF mailbox message handling
>       app/testpmd: remove jumbo offload
>
> Ciara Power (1):
>       test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
>       doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
>       net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
>       vhost: fix virtqueue use after free on NUMA reallocation
>       app/testpmd: restore ixgbe bypass commands
>       net/failsafe: fix interrupt handle leak
>       net/bnxt: fix build with GCC 13
>       trace: fix mode for new trace point
>       trace: fix mode change
>       trace: fix leak with regexp
>       trace: fix dynamically enabling trace points
>       trace: fix race in debug dump
>       ci: bump versions of actions in GHA
>       ci: update to new API for step outputs in GHA
>       service: fix build with clang 15
>       vhost: fix build with clang 15
>       bus/dpaa: fix build with clang 15
>       net/atlantic: fix build with clang 15
>       net/dpaa2: fix build with clang 15
>       app/testpmd: fix build with clang 15
>       app/testpmd: fix build with clang 15 in flow code
>       test/efd: fix build with clang 15
>       test/member: fix build with clang 15
>       test/event: fix build with clang 15
>       ci: enable ABI check in GHA
>       trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
>       build: enable developer mode for all working trees
>       eal: fix side effect in some pointer arithmetic macros
>       mempool: make event callbacks process-private
>       common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
>       net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
>       doc: fix application name in procinfo guide
>       doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
>       service: fix early move to inactive status
>
> Fidaullah Noonari (1):
>       malloc: fix storage size for some allocations
>
> Frank Du (1):
>       net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
>       net/dpaa: fix buffer freeing in slow path
>       net/dpaa: use internal mempool for SG table
>       net/dpaa: fix buffer freeing on SG Tx
>       net/dpaa2: use internal mempool for SG table
>       net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
>       eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
>       net/mlx5: fix RSS expansion buffer size
>       app/testpmd: fix MAC header in checksum forward engine
>       common/mlx5: fix shared mempool subscription
>       net/mlx5: fix port initialization with small LRO
>       net/mlx5: fix maximum LRO message size
>       doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
>       ring: fix description
>
> Hamza Khan (1):
>       examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
>       net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
>       baseband/acc100: fix memory leak
>       baseband/acc100: check turbo dec/enc input
>       baseband/acc100: add null checks
>       baseband/acc100: fix input length for CRC24B
>       baseband/acc100: fix clearing PF IR outside handler
>       baseband/acc100: fix device minimum alignment
>       baseband/acc100: fix close cleanup
>       baseband/acc100: add LDPC encoder padding function
>       baseband/acc100: check AQ availability
>       baseband/acc100: fix ring availability calculation
>       baseband/acc100: enforce additional check on FCW
>       baseband/acc100: fix null HARQ input case
>       baseband/acc100: fix ring/queue allocation
>       baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
>       net/hns3: fix Rx with PTP
>       net/hns3: delete unused markup
>       net/hns3: fix clearing hardware MAC statistics
>       net/hns3: fix RSS filter restore
>       net/hns3: fix RSS flow rule restore
>       net/hns3: move flow direction rule recovery
>       net/hns3: fix packet type for GENEVE
>       net/hns3: fix IPv4 and IPv6 RSS
>       net/hns3: fix typos in IPv6 SCTP fields
>       net/hns3: fix IPv4 RSS
>       net/hns3: add L3 and L4 RSS types
>       net/bonding: fix slave device Rx/Tx offload configuration
>       net/bonding: fix dropping valid MAC packets
>       net/bonding: fix mbuf fast free handling
>       net/hns3: extract functions to create RSS and FDIR flow rule
>       net/hns3: fix RSS rule restore
>       net/hns3: fix lock protection of RSS flow rule
>       net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
>       net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
>       doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
>       common/sfc_efx/base: fix maximum Tx data count
>       net/bonding: fix descriptor limit reporting
>       net/bonding: fix flow flush order on close
>
> James Hershaw (1):
>       net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
>       test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
>       eal: fix doxygen comments for UUID
>       power: fix some doxygen comments
>
> Jiawei Wang (4):
>       net/mlx5: fix modify action with tunnel decapsulation
>       net/mlx5: fix tunnel header with IPIP offload
>       net/mlx5: fix source port checking in sample flow rule
>       net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
>       net/txgbe: fix IPv6 flow rule
>       net/txgbe: remove semaphore between SW/FW
>       net/txgbe: rename some extended statistics
>       net/ngbe: rename some extended statistics
>       net/ngbe: remove semaphore between SW/FW
>       net/ngbe: fix maximum frame size
>
> Jie Hai (1):
>       net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
>       net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
>       gro: trim tail padding bytes
>       net/bonding: fix Tx hash for TCP
>       hash: fix RCU configuration memory leak
>
> Kai Ji (1):
>       test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
>       net/bnxt: remove unnecessary check
>       net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
>       net/i40e: fix VF representor release
>       net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
>       net/iavf: check illegal packet sizes
>       net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
>       Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
>       gro: check payload length after trim
>
> Long Li (2):
>       net/mlx4: fix Verbs FD leak in secondary process
>       net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
>       net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
>       drivers: fix typos found by Lintian
>
> Mao YingMing (1):
>       net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
>       net: accept unaligned data in checksum routines
>       event/dsw: fix flow migration
>       doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
>       vhost: fix build with GCC 12
>
> Megha Ajmera (2):
>       sched: fix subport profile configuration
>       examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
>       net/mlx5: fix null check in devargs parsing
>       doc: fix underlines in testpmd guide
>       doc: fix colons in testpmd aged flow rules
>       net/mlx5: fix race condition in counter pool resizing
>       net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
>       net/ice: support VXLAN-GPE tunnel offload
>       net/i40e: fix pctype configuration for X722
>       net/ice: fix scalar Rx path segment
>       net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
>       pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
>       eventdev/eth_tx: add spinlock for adapter start/stop
>       eventdev/eth_tx: fix adapter stop
>       timer: fix stopping all timers
>       eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
>       examples/ipsec-secgw: use Tx checksum offload conditionally
>       examples/l3fwd: fix MTU configuration with event mode
>       net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
>       cryptodev: fix unduly newlines in logs
>       mem: fix API doc about allocation on secondary processes
>       event/sw: fix flow ID init in self test
>       event/sw: fix log in self test
>       net/ixgbe: fix broadcast Rx on VF after promisc removal
>       net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
>       net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
>       examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
>       event/cnxk: fix missing xstats operations
>       event/cnxk: fix mbuf offset calculation
>       event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
>       net/nfp: compose firmware file name with new hwinfo
>       buildtools: fix NUMA nodes count
>       net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
>       net/ice/base: fix division during E822 PTP init
>       net/ice/base: fix 100M speed capability
>       net/ice/base: fix DSCP PFC TLV creation
>       net/ice/base: fix media type of PHY 10G SFI C2C
>       net/ice/base: fix function descriptions for parser
>       net/ice/base: fix endian format
>       net/ice/base: fix array overflow in add switch recipe
>       net/ice/base: fix bit finding range over ptype bitmap
>       net/ice/base: fix add MAC rule
>       net/ice/base: fix double VLAN in promiscuous mode
>       net/ice/base: ignore promiscuous already exist
>       net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
>       app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
>       net/iavf: update IPsec ESN values when updating session
>       net/iavf: fix IPsec flow create error check
>       net/iavf: fix SPI check
>       net/iavf: fix queue stop for large VF
>       examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
>       net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
>       net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
>       common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
>       common/cnxk: fix log level during MCAM allocation
>       common/cnxk: fix missing flow counter reset
>       common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
>       node: check Rx element allocation
>       dma/idxd: check DSA device allocation
>
> Shun Hao (4):
>       net/mlx5: fix meter profile delete after disable
>       net/mlx5: fix action flag data type
>       net/mlx5: fix drop action validation
>       net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
>       doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
>       event/sw: fix device name in dump
>       eal: fix data race in multi-process support
>       pdump: do not allow enable/disable in primary process
>       app/dumpcap: fix crash on cleanup
>       app/dumpcap: fix pathname for output file
>       app/testpmd: make quit flag volatile
>       ring: remove leftover comment about watermark
>       doc: avoid meson deprecation in setup
>
> Steve Yang (1):
>       net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
>       common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
>       test/crypto: fix debug messages
>
> Taekyung Kim (1):
>       vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
>       net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
>       drivers: remove unused build variable
>       doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
>       net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
>       net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
>       net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
>       net/mlx5: fix check for orphan wait descriptor
>       net/mlx5: fix single not inline packet storing
>       net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
>       test/hash: remove dead code in extendable bucket test
>       test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
>       cryptodev: fix missing SHA3 algorithm strings
>       eventdev: fix name of Rx conf type in documentation
>       app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
>       examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
>       net/iavf: fix VLAN offload
>
> Yi Li (1):
>       doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
>       net/iavf: fix VLAN insertion
>       net/iavf: revert VLAN insertion fix
>       net/ice/base: fix duplicate flow rules
>       net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
>       net/bonding: fix array overflow in Rx burst
>       net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
>       net/ice: fix RSS hash update
>       net/iavf: fix processing VLAN TCI in SSE path
>       net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
>       graph: fix node objects allocation
>
>

[-- Attachment #2: Type: text/html, Size: 22341 bytes --]

^ permalink raw reply	[relevance 0%]

* [PATCH V7 0/8] telemetry: fix data truncation and conversion error and add hex integer API
                     ` (4 preceding siblings ...)
  2022-12-15 10:31  3% ` [PATCH V6 " Huisong Li
@ 2022-12-16  1:54  3% ` Huisong Li
  2022-12-19  7:06  3% ` [PATCH V8 " Huisong Li
  6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-16  1:54 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v7: replace sprintf with snprintf in patch 6/8
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 309 insertions(+), 30 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
  @ 2022-12-15 13:58  4%       ` Bruce Richardson
  2022-12-19 10:37  0%         ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-15 13:58 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand

On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> 15/12/2022 10:44, Bruce Richardson:
> > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > For future standardization on the "uint" name for unsigned values rather
> > > > than the existing "u64" one, we can for now:
> > > > * rename all internal values to use uint rather than u64
> > > > * add new function names to alias the existing u64 ones
> > > > 
> > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > ---
> > > >  lib/telemetry/rte_telemetry.h  | 36 ++++++++++++++++++++++++++++++++++
> > > >  lib/telemetry/telemetry.c      | 16 +++++++--------
> > > >  lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++--------
> > > >  lib/telemetry/telemetry_data.h |  4 ++--
> > > >  lib/telemetry/version.map      |  7 +++++++
> > > >  5 files changed, 73 insertions(+), 18 deletions(-)
> > > > 
> > > > diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> > > > index c2ad65effe..60877dae0a 100644
> > > > --- a/lib/telemetry/rte_telemetry.h
> > > > +++ b/lib/telemetry/rte_telemetry.h
> > > > @@ -8,6 +8,8 @@
> > > >  #ifndef _RTE_TELEMETRY_H_
> > > >  #define _RTE_TELEMETRY_H_
> > > >  
> > > > +#include <rte_compat.h>
> > > > +
> > > >  #ifdef __cplusplus
> > > >  extern "C" {
> > > >  #endif
> > > > @@ -121,6 +123,22 @@ int
> > > >  rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
> > > >  
> > > >  /**
> > > 
> > > when adding __rte_experimental api i have been asked to add the
> > > following boilerplate documentation block. i'm not pushing it, just
> > > recalling it is what i get asked for, so in case it's something we do?
> > > see lib/eal/include/rte_thread.h as an example
> > > 
> > > 
> > > ```
> > >  * @warning
> > >  * @b EXPERIMENTAL: this API may change without prior notice.
> > > ```
> > >
> > 
> > Ok, thanks for the notice.
> > 
> > Actually, related to this, since we are adding these functions as aliases
> > for existing stable functions, I would like to see these being added not as
> > experimental. The reason for that, is that while they are experimental, we
> > cannot feasibly mark the old function names as deprecated. :-(
> > 
> > Adding Thomas and David on CC for their thoughts.
> 
> Is it related to telemetry?
> 
> In general, yes we cannot deprecate something if there is no stable replacement.
> The recommended step is to introduce a new experimental API
> and deprecate the old one when the new API is stable.
> 
Yes, understood.
What we are really trying to do here is to rename an API, by process of
adding the new API and then marking the old one as deprecated. The small
issue is that adding the new one it is by default experimental, meaning we
need to wait for deprecating old one. Ideally, as soon as the new API is
added, we would like to point people to use that, but can't really do so
while it is experimental.

---

By way of explicit detail, Morten pointed out the inconsistency in the
telemetry APIs and types:

* we have add_*_int, which takes a 32-bit signed value
* we have add_*_u64 which takes 64-bit unsigned (as name suggests).

The ideal end-state is to always use 64-bit values (since there is no space
saving from 32-bit as a union is used), and just name everything as "int"
or "uint" for signed/unsigned. The two big steps here are:

* expanding type of the "int" functions to take 64-bit parameters - this is
  ABI change but not API one, since existing code will happily promote
  values on compile. Therefore, we just use ABI versioning to have a 32-bit
  version for older linked binaries.
* the rename of the rte_tel_data_add_array_u64 and
  rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
  compatibility is easier, as we can just add new functions, the overall
  process is slower since the new functions technically should be added as
  experimental - hence the email. For the case of function renaming, do we
  still need to have the "renamed" versions as experimental initially?

Given where we are in the overall DPDK releases cycle, it's not a major
issue either way, I just would like some clarity. My main concern with
having it spread over a couple of releases, is that it's more likely a step
will be missed/forgotten somewhere along the way! 

/Bruce

^ permalink raw reply	[relevance 4%]

* [PATCH V6 0/8] telemetry: fix data truncation and conversion error and add hex integer API
                     ` (3 preceding siblings ...)
  2022-12-14 12:32  3% ` [PATCH V5 0/8] " Huisong Li
@ 2022-12-15 10:31  3% ` Huisong Li
  2022-12-16  1:54  3% ` [PATCH V7 " Huisong Li
  2022-12-19  7:06  3% ` [PATCH V8 " Huisong Li
  6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-15 10:31 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  72 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 308 insertions(+), 30 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
  2022-12-14 17:53  0%     ` Tyler Retzlaff
@ 2022-12-15  2:39  0%       ` lihuisong (C)
  0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-15  2:39 UTC (permalink / raw)
  To: dev


在 2022/12/15 1:53, Tyler Retzlaff 写道:
> On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>> Sent: Tuesday, 13 December 2022 19.28
>>>
>>> While the unsigned values added to telemetry dicts/arrays were up to
>>> 64-bits in size, the sized values were only up to 32-bits. We can
>>> standardize the API by having both int and uint functions take 64-bit
>>> values. For ABI compatibility, we use function versioning to ensure
>>> older binaries can still use the older functions taking a 32-bit
>>> parameter.
>>>
>>> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
>>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>> ---
>> Excellent example of how to use function versioning for ABI compatibility.
>>
>> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>>
> minor comments that can be optionally addressed. lgtm
>
> Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> .
LGTM
Series-acked-by: Huisong Li <lihuisong@huawei.com>

But I feel this patchset needs to be applied after the following patchset:
http://patches.dpdk.org/project/dpdk/list/?series=26124
The above patchset fixes some problems about possible data truncation and
conversion error, and will backport to stable branch.

^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
  2022-12-13 20:19  3%   ` Morten Brørup
@ 2022-12-14 17:53  0%     ` Tyler Retzlaff
  2022-12-15  2:39  0%       ` lihuisong (C)
  0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-14 17:53 UTC (permalink / raw)
  To: Morten Brørup; +Cc: Bruce Richardson, dev

On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 13 December 2022 19.28
> > 
> > While the unsigned values added to telemetry dicts/arrays were up to
> > 64-bits in size, the sized values were only up to 32-bits. We can
> > standardize the API by having both int and uint functions take 64-bit
> > values. For ABI compatibility, we use function versioning to ensure
> > older binaries can still use the older functions taking a 32-bit
> > parameter.
> > 
> > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> 
> Excellent example of how to use function versioning for ABI compatibility.
> 
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
> 

minor comments that can be optionally addressed. lgtm

Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

^ permalink raw reply	[relevance 0%]

* [PATCH V5 0/8] telemetry: fix data truncation and conversion error and add hex integer API
                     ` (2 preceding siblings ...)
  2022-12-13 10:15  3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
@ 2022-12-14 12:32  3% ` Huisong Li
  2022-12-15 10:31  3% ` [PATCH V6 " Huisong Li
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-14 12:32 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  74 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 310 insertions(+), 30 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* Re: [PATCH] cryptodev: add algo enums to string conversion APIs
  2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
                   ` (2 preceding siblings ...)
  2022-12-13  8:22  0% ` Power, Ciara
@ 2022-12-14  9:32  0% ` Zhang, Fan
  2023-01-04  6:18  2% ` [PATCH v2] " Akhil Goyal
  4 siblings, 0 replies; 200+ results
From: Zhang, Fan @ 2022-12-14  9:32 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: ciara.power, kai.ji, pablo.de.lara.guarch, hemant.agrawal, matan,
	g.singh, ruifeng.wang, anoobj, radu.nicolau, vfialko, ktraynor,
	david.marchand, thomas

On 12/12/2022 3:10 PM, Akhil Goyal wrote:
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
>   app/test-crypto-perf/cperf_options_parsing.c |   6 +-
>   app/test/test_cryptodev_asym.c               |   2 +-
>   app/test/test_cryptodev_security_ipsec.c     |   8 +-
>   doc/guides/rel_notes/deprecation.rst         |   7 +
>   drivers/crypto/openssl/rte_openssl_pmd_ops.c |   2 +-
>   drivers/crypto/qat/qat_sym_session.c         |   7 +-
>   examples/l2fwd-crypto/main.c                 |  12 +-
>   lib/cryptodev/cryptodev_trace_points.c       |  12 ++
>   lib/cryptodev/rte_crypto_asym.h              |   1 +
>   lib/cryptodev/rte_crypto_sym.h               |   3 +
>   lib/cryptodev/rte_cryptodev.c                | 182 ++++++++++++++++++-
>   lib/cryptodev/rte_cryptodev.h                |  52 ++++++
>   lib/cryptodev/rte_cryptodev_trace.h          |  32 ++++
>   lib/cryptodev/version.map                    |  10 +
>   14 files changed, 309 insertions(+), 27 deletions(-)
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>

^ permalink raw reply	[relevance 0%]

* RE: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
  2022-12-13 18:27  3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2022-12-13 20:19  3%   ` Morten Brørup
  2022-12-14 17:53  0%     ` Tyler Retzlaff
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-13 20:19 UTC (permalink / raw)
  To: Bruce Richardson, dev

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 13 December 2022 19.28
> 
> While the unsigned values added to telemetry dicts/arrays were up to
> 64-bits in size, the sized values were only up to 32-bits. We can
> standardize the API by having both int and uint functions take 64-bit
> values. For ABI compatibility, we use function versioning to ensure
> older binaries can still use the older functions taking a 32-bit
> parameter.
> 
> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---

Excellent example of how to use function versioning for ABI compatibility.

Series-acked-by: Morten Brørup <mb@smartsharesystems.com>


^ permalink raw reply	[relevance 3%]

* [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
  2022-12-13 18:27  4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
  2022-12-13 18:27  3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2022-12-13 18:27  3% ` Bruce Richardson
  2022-12-13 20:19  3%   ` Morten Brørup
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup

While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/meson.build      |  1 +
 lib/telemetry/rte_telemetry.h  |  4 ++--
 lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
 lib/telemetry/telemetry_data.h |  6 ++++++
 lib/telemetry/version.map      |  7 +++++++
 5 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
 sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
 headers = files('rte_telemetry.h')
 includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 60877dae0a..baa7b21f6b 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
  *   0 on success, negative errno on error
  */
 int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
 
 /**
  * Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
  *   0 on success, negative errno on error, E2BIG on string truncation of name.
  */
 int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
 
 /**
  * Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
 
+#include <rte_function_versioning.h>
 #include <rte_string_fns.h>
 
 #include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
 {
 	if (d->type != TEL_ARRAY_INT)
 		return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+	return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+		int64_t x), rte_tel_data_add_array_int_v24);
+
 int
 rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
 {
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 	return 0;
 }
 
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 	if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+	return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+		const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
 int
 rte_tel_data_add_dict_uint(struct rte_tel_data *d,
 		const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
 	} data; /* data container */
 };
 
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
 #endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 0f70d82dfc..85df19c4d8 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -19,6 +19,13 @@ DPDK_23 {
 	local: *;
 };
 
+DPDK_24 {
+	global:
+
+	rte_tel_data_add_array_int;
+	rte_tel_data_add_dict_int;
+} DPDK_23;
+
 EXPERIMENTAL {
 	global:
 
-- 
2.34.1


^ permalink raw reply	[relevance 3%]

* [RFC PATCH 6/7] telemetry: make internal int representation 64-bits
  2022-12-13 18:27  4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
@ 2022-12-13 18:27  3% ` Bruce Richardson
  2022-12-13 18:27  3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson, Morten Brørup

The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.

Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/telemetry_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
  */
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
-	int ival;
+	int64_t ival;
 	uint64_t uval;
 	struct container container;
 };
-- 
2.34.1


^ permalink raw reply	[relevance 3%]

* [RFC PATCH 0/7] Standardize telemetry int types
@ 2022-12-13 18:27  4% Bruce Richardson
  2022-12-13 18:27  3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
                   ` (4 more replies)
  0 siblings, 5 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson

Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.

This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.

* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
  added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
  rather than a 32-bit one. Since this would be an ABI break, we
  use function versioning to ensure older code still calls into
  a wrapper function which takes a 32-bit value.

Finally, the patchset also contains a couple of other small cleanups
to the telemetry code that were seen in passing when making these
changes.

Bruce Richardson (7):
  telemetry: rename unsigned 64-bit enum value to uint
  telemetry: add uint type as alias for u64
  telemetry: remove RTE prefix from internal enum values
  telemetry: make array initialization more robust
  telemetry: update json functions to use int/uint in names
  telemetry: make internal int representation 64-bits
  telemetry: change public API to use 64-bit signed values

 app/test/test_telemetry_data.c               | 10 +--
 app/test/test_telemetry_json.c               |  9 +-
 drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c |  4 +-
 drivers/net/cnxk/cnxk_ethdev_telemetry.c     |  2 +-
 lib/cryptodev/rte_cryptodev.c                |  2 +-
 lib/ethdev/rte_ethdev.c                      |  2 +-
 lib/ethdev/sff_telemetry.c                   |  2 +-
 lib/ipsec/ipsec_telemetry.c                  |  2 +-
 lib/security/rte_security.c                  |  4 +-
 lib/telemetry/meson.build                    |  1 +
 lib/telemetry/rte_telemetry.h                | 46 +++++++++-
 lib/telemetry/telemetry.c                    | 56 ++++++------
 lib/telemetry/telemetry_data.c               | 95 ++++++++++++++------
 lib/telemetry/telemetry_data.h               | 24 +++--
 lib/telemetry/telemetry_json.h               | 16 ++--
 lib/telemetry/version.map                    | 14 +++
 16 files changed, 192 insertions(+), 97 deletions(-)

--
2.34.1

^ permalink raw reply	[relevance 4%]

* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
  2022-12-13 15:49  3%     ` Robin Jarry
  2022-12-13 16:39  0%       ` Morten Brørup
@ 2022-12-13 17:45  0%       ` Tyler Retzlaff
  1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-13 17:45 UTC (permalink / raw)
  To: Robin Jarry; +Cc: dev, Morten Brørup, Kevin Laatz

On Tue, Dec 13, 2022 at 04:49:31PM +0100, Robin Jarry wrote:
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
> 
> As you may have noticed, I forgot to add -v4 for that iteration...
> 
> > diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
> >  int
> >  rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >  
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + *   The lcore to consider.
> > + * @param [out] busy_cycles
> > + *   The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + *   The total amount of time since application start, in TSC cycles.
> > + * @return
> > + *   - 0 if both busy and total were set correctly.
> > + *   - a negative value if the information is not available or if any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > +	unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);
> 
> Instead of two uint64_t pointers, I was thinking a better approach would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
> 
> Thoughts?

yes, please.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 12:16  3%           ` Bruce Richardson
  2022-12-13 11:00  0%             ` Morten Brørup
@ 2022-12-13 17:12  3%             ` Bruce Richardson
  1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 17:12 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen

On Mon, Dec 12, 2022 at 12:16:07PM +0000, Bruce Richardson wrote:
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > > 
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32 and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > > > break
> > > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format, but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > > 
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would make
> > > sense to explicitly add it, but it seems like a lot of extra code for
> > > little or no benefit until we support something like that.
> > 
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> > </rant>
> 
> Yes, not making "int" an "i64" type was a poor design decision on my part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this as
> you suggest at the next ABI break window.
> 
Actually, most of the work for this can be done without affecting ABI, I
believe, and for the two functions that would be affected, function
versioning could be used to cover those. I think it's better to make the
change now using versioning rather than waiting, as it's likely to be
forgotten if we wait.

I'll work up a patchset for this so we can review and discuss...

/Bruce

^ permalink raw reply	[relevance 3%]

* RE: [PATCH 2/4] eal: allow applications to report their cpu usage
  2022-12-13 15:49  3%     ` Robin Jarry
@ 2022-12-13 16:39  0%       ` Morten Brørup
  2022-12-13 17:45  0%       ` Tyler Retzlaff
  1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 16:39 UTC (permalink / raw)
  To: Robin Jarry, dev; +Cc: Kevin Laatz, mattias.ronnblom

> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Tuesday, 13 December 2022 16.50
> 
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that
> were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
> 
> As you may have noticed, I forgot to add -v4 for that iteration...
> 
> > diff --git a/lib/eal/include/rte_lcore.h
> b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int
> lcore_id, void *arg);
> >  int
> >  rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + *   The lcore to consider.
> > + * @param [out] busy_cycles
> > + *   The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + *   The total amount of time since application start, in TSC
> cycles.
> > + * @return
> > + *   - 0 if both busy and total were set correctly.
> > + *   - a negative value if the information is not available or if
> any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > +	unsigned int lcore_id, uint64_t *busy_cycles, uint64_t
> *total_cycles);
> 
> Instead of two uint64_t pointers, I was thinking a better approach
> would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
> 
> Thoughts?

I like the idea.

For compatibility between newer DPDK libraries (with more fields) and older applications, the callback should return an indication of how much of the structure it has filled, so DPDK knows that some fields are unfilled.

The simplest method would be that the callback returns the number of bytes of the structure filled instead of 0 on success. However, that would not allow for holes in the returned structure.

Alternatively, a bitfield can be the first field in the structure, each bit representing a data field in the structure. That would allow flexibility to fill any of up to 64 fields. So with total_cycles and busy_cycles as data fields, the returned structure would contain e.g. {3, 1000, 900}. (As a personal preference, I would put total_cycles before busy_cycles in such a structure.)

And I'm not saying that fields must be uint64_t; they can be any size.

On the other hand, I might be suggesting too much flexibility with the bitfield proposal. Perhaps the simple method suffices. And perhaps only uint64_t fields suffice.

-Morten

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
  @ 2022-12-13 15:49  3%     ` Robin Jarry
  2022-12-13 16:39  0%       ` Morten Brørup
  2022-12-13 17:45  0%       ` Tyler Retzlaff
  0 siblings, 2 replies; 200+ results
From: Robin Jarry @ 2022-12-13 15:49 UTC (permalink / raw)
  To: dev; +Cc: Morten Brørup, Kevin Laatz

Robin Jarry, Dec 07, 2022 at 17:21:
> Allow applications to register a callback that will be invoked in
> rte_lcore_dump() and when requesting lcore info in the telemetry API.
>
> The callback is expected to return the number of TSC cycles that have
> passed since application start and the number of these cycles that were
> spent doing busy work.
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
> v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles

As you may have noticed, I forgot to add -v4 for that iteration...

> diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> index 6938c3fd7b81..df7f0a8e07c6 100644
> --- a/lib/eal/include/rte_lcore.h
> +++ b/lib/eal/include/rte_lcore.h
> @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
>  int
>  rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
>  
> +/**
> + * Callback to allow applications to report CPU usage.
> + *
> + * @param [in] lcore_id
> + *   The lcore to consider.
> + * @param [out] busy_cycles
> + *   The amount of busy time since application start, in TSC cycles.
> + * @param [out] total_cycles
> + *   The total amount of time since application start, in TSC cycles.
> + * @return
> + *   - 0 if both busy and total were set correctly.
> + *   - a negative value if the information is not available or if any error occurred.
> + */
> +typedef int (*rte_lcore_usage_cb)(
> +	unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);

Instead of two uint64_t pointers, I was thinking a better approach would
be to pass a pointer to a struct containing these two fields. That way
it leaves room for adding more counters if need be. And do so without
breaking the ABI.

Thoughts?


^ permalink raw reply	[relevance 3%]

* [PATCH] ci: drop Travis configuration
@ 2022-12-13 15:07  3% David Marchand
  0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-13 15:07 UTC (permalink / raw)
  To: dev; +Cc: Honnappa.Nagarahalli, thomas, Aaron Conole, Michael Santana

We stopped using Travis in the main branch and in the public CI in favor
of GHA more than a year ago.
The UNH community lab now covers testing native compilation and unit
tests for ARM platforms.

We decided to stop maintaining the configuration in our repository with
the argument that "if it is not tested, it is broken".

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 .ci/linux-build.sh                  |  19 ---
 .travis.yml                         | 172 ----------------------------
 MAINTAINERS                         |   1 -
 devtools/check-spdx-tag.sh          |   2 +-
 doc/guides/contributing/patches.rst |   4 -
 5 files changed, 1 insertion(+), 197 deletions(-)
 delete mode 100644 .travis.yml

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 5225dc71c4..ab0994388a 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -9,25 +9,6 @@ fi
 # Builds are run as root in containers, no need for sudo
 [ "$(id -u)" != '0' ] || alias sudo=
 
-on_error() {
-    if [ $? = 0 ]; then
-        exit
-    fi
-    FILES_TO_PRINT="build/meson-logs/testlog.txt"
-    FILES_TO_PRINT="$FILES_TO_PRINT build/.ninja_log"
-    FILES_TO_PRINT="$FILES_TO_PRINT build/meson-logs/meson-log.txt"
-    FILES_TO_PRINT="$FILES_TO_PRINT build/gdb.log"
-
-    for pr_file in $FILES_TO_PRINT; do
-        if [ -e "$pr_file" ]; then
-            cat "$pr_file"
-        fi
-    done
-}
-# We capture the error logs as artifacts in Github Actions, no need to dump
-# them via a EXIT handler.
-[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
-
 install_libabigail() {
     version=$1
     instdir=$2
diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 0936788dc7..0000000000
--- a/.travis.yml
+++ /dev/null
@@ -1,172 +0,0 @@
-# default values for all jobs
-language: c
-cache:
-  ccache: true
-  directories:
-    - libabigail
-    - reference
-
-dist: bionic
-
-os: linux
-
-addons:
-  apt:
-    update: true
-    packages: &required_packages
-      - [libnuma-dev, python3-setuptools, python3-wheel, python3-pip, python3-pyelftools, ninja-build]
-      - [libbsd-dev, libpcap-dev, libibverbs-dev, libcrypto++-dev, libfdt-dev, libjansson-dev]
-      - [libarchive-dev]
-
-_aarch64_packages: &aarch64_packages
-  - *required_packages
-  - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_aarch64_clang_packages: &aarch64_clang_packages
-  - *required_packages
-  - [libgcc-7-dev-arm64-cross, libatomic1-arm64-cross, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_libabigail_build_packages: &libabigail_build_packages
-  - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
-
-_build_32b_packages: &build_32b_packages
-  - *required_packages
-  - [gcc-multilib]
-
-_doc_packages: &doc_packages
-  - [doxygen, graphviz, python3-sphinx]
-
-before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
-script: ./.ci/${TRAVIS_OS_NAME}-build.sh
-
-env:
-  global:
-    - LIBABIGAIL_VERSION=libabigail-2.1
-    - REF_GIT_REPO=https://dpdk.org/git/dpdk-stable
-    - REF_GIT_TAG=v22.11.1
-
-jobs:
-  include:
-  # x86_64 gcc jobs
-  - env: DEF_LIB="static"
-    arch: amd64
-    compiler: gcc
-  - env: DEF_LIB="shared" RUN_TESTS=true
-    arch: amd64
-    compiler: gcc
-  - env: DEF_LIB="shared" BUILD_DOCS=true
-    arch: amd64
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *required_packages
-          - *doc_packages
-  - env: DEF_LIB="shared" ABI_CHECKS=true
-    arch: amd64
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *required_packages
-          - *libabigail_build_packages
-  # x86_64 clang jobs
-  - env: DEF_LIB="static"
-    arch: amd64
-    compiler: clang
-  - env: DEF_LIB="shared" RUN_TESTS=true
-    arch: amd64
-    compiler: clang
-  - env: DEF_LIB="shared" BUILD_DOCS=true
-    arch: amd64
-    compiler: clang
-    addons:
-      apt:
-        packages:
-          - *required_packages
-          - *doc_packages
-  # x86_64 cross-compiling 32-bits jobs
-  - env: DEF_LIB="static" BUILD_32BIT=true
-    arch: amd64
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *build_32b_packages
-  # x86_64 cross-compiling aarch64 jobs
-  - env: DEF_LIB="static" AARCH64=true
-    arch: amd64
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *aarch64_packages
-  - env: DEF_LIB="shared" AARCH64=true
-    arch: amd64
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *aarch64_packages
-  - env: DEF_LIB="static" AARCH64=true
-    arch: amd64
-    compiler: clang
-    addons:
-      apt:
-        packages:
-          - *aarch64_clang_packages
-  - env: DEF_LIB="shared" AARCH64=true
-    arch: amd64
-    compiler: clang
-    addons:
-      apt:
-        packages:
-          - *aarch64_clang_packages
-  # aarch64 gcc jobs
-  - env: DEF_LIB="static"
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: gcc
-  - env: DEF_LIB="shared" RUN_TESTS=true
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: gcc
-  - env: DEF_LIB="shared" BUILD_DOCS=true
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *required_packages
-          - *doc_packages
-  - env: DEF_LIB="shared" ABI_CHECKS=true
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: gcc
-    addons:
-      apt:
-        packages:
-          - *required_packages
-          - *libabigail_build_packages
-  # aarch64 clang jobs
-  - env: DEF_LIB="static"
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: clang
-  - env: DEF_LIB="shared" RUN_TESTS=true
-    dist: focal
-    arch: arm64-graviton2
-    virt: vm
-    group: edge
-    compiler: clang
diff --git a/MAINTAINERS b/MAINTAINERS
index 3dc3f5b348..9a0f416d2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -131,7 +131,6 @@ F: devtools/check-meson.py
 Public CI
 M: Aaron Conole <aconole@redhat.com>
 M: Michael Santana <maicolgabriel@hotmail.com>
-F: .travis.yml
 F: .github/workflows/build.yml
 F: .ci/
 
diff --git a/devtools/check-spdx-tag.sh b/devtools/check-spdx-tag.sh
index 89b2d643a4..7624778a8c 100755
--- a/devtools/check-spdx-tag.sh
+++ b/devtools/check-spdx-tag.sh
@@ -20,7 +20,7 @@ check_spdx() {
 	echo "--------------------------"
     fi
     git grep -L SPDX-License-Identifier -- \
-	':^.git*' ':^.mailmap' ':^.ci/*' ':^.travis.yml' \
+	':^.git*' ':^.mailmap' ':^.ci/*' \
 	':^README' ':^MAINTAINERS' ':^VERSION' ':^ABI_VERSION' \
 	':^*/Kbuild' ':^*/README' \
 	':^license/' ':^config/' ':^buildtools/' ':^*/poetry.lock' \
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index b3eaf7df03..e286d9e6d5 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -35,10 +35,6 @@ It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/p
 If you are using the GitHub service, pushing to a branch will trigger GitHub
 Actions to automatically build your changes and run unit tests and ABI checks.
 
-Additionally, a Travis configuration is available in DPDK but Travis free usage
-is limited to a few builds.
-You can link your repository to the ``travis-ci.com`` build service.
-
 The development process requires some familiarity with the ``git`` version control system.
 Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
 
-- 
2.38.1


^ permalink raw reply	[relevance 3%]

* Re: 21.11.3 patches review and test
  2022-12-06 11:29  1% 21.11.3 patches review and test Kevin Traynor
@ 2022-12-13 11:48  0% ` Christian Ehrhardt
  2022-12-16  7:55  0% ` YangHang Liu
  1 sibling, 0 replies; 200+ results
From: Christian Ehrhardt @ 2022-12-13 11:48 UTC (permalink / raw)
  To: Kevin Traynor
  Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
	David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
	John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
	qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yanghliu,
	yuan.peng, zhaoyan.chen

On Tue, Dec 6, 2022 at 12:30 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
>     https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
>     https://dpdk.org/browse/dpdk-stable/

Hi Kevin,
testing 22.11.3 builds and a bunch of workloads and stressing things
under Ubuntu 22.04.
TL;DR: for what I ran all LGTM, no regressions found (but I only have
a small subset of HW and use cases, I hope others will reply as well
later this week).

V: 21.11.3~rc1-0ubuntu0.22.04.1~jammyppa1

1.0.0 (08:19:13): phys (BM) tests
  1.1.0 (08:19:13): initialize environment
    1.1.1 (08:21:02): testpmd  => Pass
    1.1.2 (08:23:07): check testpmd output  => Pass
2.0.0 (08:23:07): prep virtual test environment

1.0.0 (08:25:37): virt tests
  1.1.0 (08:25:37): initialize environment
3.0.0 (08:27:02): performance tests
  3.1.0 (08:27:02): prep benchmarks
  3.2.0 (08:27:24): performance tests
    3.2.1 (08:27:32): test guest-openvswitch for OVS-5CPU  => Pass
    3.2.2 (08:46:45): test guest-dpdk-vhost-user-client-multiq for
OVSDPDK-VUC  => Pass
4.0.0 (09:06:10): VUC endurance checks
  4.1.0 (09:06:10): prep VUC endurance tests
    4.1.1 (09:18:48): start stop guests (client)  => Pass
    4.1.2 (10:31:22): add/remove ports (client)  => Pass
  4.2.0 (10:40:52): Final cleanup

> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
>       event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
>       common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
>       net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
>       net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
>       net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
>       net/mlx5: fix shared Rx queue config reuse
>       net/mlx5: fix first segment inline length
>       net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
>       examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
>       net/mvneta: fix build with GCC 12
>       test/ipsec: fix build with GCC 12
>       ipsec: fix build with GCC 12
>       crypto/qat: fix build with GCC 12
>       net/i40e: fix build with MinGW GCC 12
>       net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
>       net/ionic: fix endianness for Rx and Tx
>       net/ionic: fix endianness for RSS
>       net/ionic: fix adapter name for logging
>       net/ionic: fix Rx filter save
>       net/ionic: fix reported error stats
>
> Anoob Joseph (1):
>       test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
>       net/enetfec: fix restart
>       net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
>       common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
>       mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
>       doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
>       net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
>       net/axgbe: fix scattered Rx
>       net/axgbe: fix mbuf lengths in scattered Rx
>       net/axgbe: fix length of each segment in scattered Rx
>       net/axgbe: fix checksum and RSS in scattered Rx
>       net/axgbe: optimise scattered Rx
>       net/axgbe: remove freeing buffer in scattered Rx
>       net/axgbe: reset end of packet in scattered Rx
>       net/axgbe: clear buffer on scattered Rx chaining failure
>       net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
>       net/mlx5: fix build with recent compilers
>       bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
>       crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
>       vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
>       net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
>       net/hns3: fix crash in SVE Tx
>       net/hns3: fix next-to-use overflow in SVE Tx
>       net/hns3: fix next-to-use overflow in simple Tx
>       net/hns3: fix crash when secondary process access FW
>       net/hns3: revert Tx performance optimization
>       net/hns3: revert fix mailbox communication with HW
>       net/hns3: fix VF mailbox message handling
>       app/testpmd: remove jumbo offload
>
> Ciara Power (1):
>       test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
>       doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
>       net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
>       vhost: fix virtqueue use after free on NUMA reallocation
>       app/testpmd: restore ixgbe bypass commands
>       net/failsafe: fix interrupt handle leak
>       net/bnxt: fix build with GCC 13
>       trace: fix mode for new trace point
>       trace: fix mode change
>       trace: fix leak with regexp
>       trace: fix dynamically enabling trace points
>       trace: fix race in debug dump
>       ci: bump versions of actions in GHA
>       ci: update to new API for step outputs in GHA
>       service: fix build with clang 15
>       vhost: fix build with clang 15
>       bus/dpaa: fix build with clang 15
>       net/atlantic: fix build with clang 15
>       net/dpaa2: fix build with clang 15
>       app/testpmd: fix build with clang 15
>       app/testpmd: fix build with clang 15 in flow code
>       test/efd: fix build with clang 15
>       test/member: fix build with clang 15
>       test/event: fix build with clang 15
>       ci: enable ABI check in GHA
>       trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
>       build: enable developer mode for all working trees
>       eal: fix side effect in some pointer arithmetic macros
>       mempool: make event callbacks process-private
>       common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
>       net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
>       doc: fix application name in procinfo guide
>       doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
>       service: fix early move to inactive status
>
> Fidaullah Noonari (1):
>       malloc: fix storage size for some allocations
>
> Frank Du (1):
>       net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
>       net/dpaa: fix buffer freeing in slow path
>       net/dpaa: use internal mempool for SG table
>       net/dpaa: fix buffer freeing on SG Tx
>       net/dpaa2: use internal mempool for SG table
>       net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
>       eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
>       net/mlx5: fix RSS expansion buffer size
>       app/testpmd: fix MAC header in checksum forward engine
>       common/mlx5: fix shared mempool subscription
>       net/mlx5: fix port initialization with small LRO
>       net/mlx5: fix maximum LRO message size
>       doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
>       ring: fix description
>
> Hamza Khan (1):
>       examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
>       net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
>       baseband/acc100: fix memory leak
>       baseband/acc100: check turbo dec/enc input
>       baseband/acc100: add null checks
>       baseband/acc100: fix input length for CRC24B
>       baseband/acc100: fix clearing PF IR outside handler
>       baseband/acc100: fix device minimum alignment
>       baseband/acc100: fix close cleanup
>       baseband/acc100: add LDPC encoder padding function
>       baseband/acc100: check AQ availability
>       baseband/acc100: fix ring availability calculation
>       baseband/acc100: enforce additional check on FCW
>       baseband/acc100: fix null HARQ input case
>       baseband/acc100: fix ring/queue allocation
>       baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
>       net/hns3: fix Rx with PTP
>       net/hns3: delete unused markup
>       net/hns3: fix clearing hardware MAC statistics
>       net/hns3: fix RSS filter restore
>       net/hns3: fix RSS flow rule restore
>       net/hns3: move flow direction rule recovery
>       net/hns3: fix packet type for GENEVE
>       net/hns3: fix IPv4 and IPv6 RSS
>       net/hns3: fix typos in IPv6 SCTP fields
>       net/hns3: fix IPv4 RSS
>       net/hns3: add L3 and L4 RSS types
>       net/bonding: fix slave device Rx/Tx offload configuration
>       net/bonding: fix dropping valid MAC packets
>       net/bonding: fix mbuf fast free handling
>       net/hns3: extract functions to create RSS and FDIR flow rule
>       net/hns3: fix RSS rule restore
>       net/hns3: fix lock protection of RSS flow rule
>       net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
>       net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
>       doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
>       common/sfc_efx/base: fix maximum Tx data count
>       net/bonding: fix descriptor limit reporting
>       net/bonding: fix flow flush order on close
>
> James Hershaw (1):
>       net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
>       test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
>       eal: fix doxygen comments for UUID
>       power: fix some doxygen comments
>
> Jiawei Wang (4):
>       net/mlx5: fix modify action with tunnel decapsulation
>       net/mlx5: fix tunnel header with IPIP offload
>       net/mlx5: fix source port checking in sample flow rule
>       net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
>       net/txgbe: fix IPv6 flow rule
>       net/txgbe: remove semaphore between SW/FW
>       net/txgbe: rename some extended statistics
>       net/ngbe: rename some extended statistics
>       net/ngbe: remove semaphore between SW/FW
>       net/ngbe: fix maximum frame size
>
> Jie Hai (1):
>       net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
>       net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
>       gro: trim tail padding bytes
>       net/bonding: fix Tx hash for TCP
>       hash: fix RCU configuration memory leak
>
> Kai Ji (1):
>       test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
>       net/bnxt: remove unnecessary check
>       net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
>       net/i40e: fix VF representor release
>       net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
>       net/iavf: check illegal packet sizes
>       net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
>       Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
>       gro: check payload length after trim
>
> Long Li (2):
>       net/mlx4: fix Verbs FD leak in secondary process
>       net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
>       net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
>       drivers: fix typos found by Lintian
>
> Mao YingMing (1):
>       net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
>       net: accept unaligned data in checksum routines
>       event/dsw: fix flow migration
>       doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
>       vhost: fix build with GCC 12
>
> Megha Ajmera (2):
>       sched: fix subport profile configuration
>       examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
>       net/mlx5: fix null check in devargs parsing
>       doc: fix underlines in testpmd guide
>       doc: fix colons in testpmd aged flow rules
>       net/mlx5: fix race condition in counter pool resizing
>       net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
>       net/ice: support VXLAN-GPE tunnel offload
>       net/i40e: fix pctype configuration for X722
>       net/ice: fix scalar Rx path segment
>       net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
>       pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
>       eventdev/eth_tx: add spinlock for adapter start/stop
>       eventdev/eth_tx: fix adapter stop
>       timer: fix stopping all timers
>       eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
>       examples/ipsec-secgw: use Tx checksum offload conditionally
>       examples/l3fwd: fix MTU configuration with event mode
>       net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
>       cryptodev: fix unduly newlines in logs
>       mem: fix API doc about allocation on secondary processes
>       event/sw: fix flow ID init in self test
>       event/sw: fix log in self test
>       net/ixgbe: fix broadcast Rx on VF after promisc removal
>       net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
>       net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
>       examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
>       event/cnxk: fix missing xstats operations
>       event/cnxk: fix mbuf offset calculation
>       event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
>       net/nfp: compose firmware file name with new hwinfo
>       buildtools: fix NUMA nodes count
>       net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
>       net/ice/base: fix division during E822 PTP init
>       net/ice/base: fix 100M speed capability
>       net/ice/base: fix DSCP PFC TLV creation
>       net/ice/base: fix media type of PHY 10G SFI C2C
>       net/ice/base: fix function descriptions for parser
>       net/ice/base: fix endian format
>       net/ice/base: fix array overflow in add switch recipe
>       net/ice/base: fix bit finding range over ptype bitmap
>       net/ice/base: fix add MAC rule
>       net/ice/base: fix double VLAN in promiscuous mode
>       net/ice/base: ignore promiscuous already exist
>       net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
>       app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
>       net/iavf: update IPsec ESN values when updating session
>       net/iavf: fix IPsec flow create error check
>       net/iavf: fix SPI check
>       net/iavf: fix queue stop for large VF
>       examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
>       net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
>       net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
>       common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
>       common/cnxk: fix log level during MCAM allocation
>       common/cnxk: fix missing flow counter reset
>       common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
>       node: check Rx element allocation
>       dma/idxd: check DSA device allocation
>
> Shun Hao (4):
>       net/mlx5: fix meter profile delete after disable
>       net/mlx5: fix action flag data type
>       net/mlx5: fix drop action validation
>       net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
>       doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
>       event/sw: fix device name in dump
>       eal: fix data race in multi-process support
>       pdump: do not allow enable/disable in primary process
>       app/dumpcap: fix crash on cleanup
>       app/dumpcap: fix pathname for output file
>       app/testpmd: make quit flag volatile
>       ring: remove leftover comment about watermark
>       doc: avoid meson deprecation in setup
>
> Steve Yang (1):
>       net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
>       common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
>       test/crypto: fix debug messages
>
> Taekyung Kim (1):
>       vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
>       net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
>       drivers: remove unused build variable
>       doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
>       net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
>       net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
>       net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
>       net/mlx5: fix check for orphan wait descriptor
>       net/mlx5: fix single not inline packet storing
>       net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
>       test/hash: remove dead code in extendable bucket test
>       test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
>       cryptodev: fix missing SHA3 algorithm strings
>       eventdev: fix name of Rx conf type in documentation
>       app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
>       examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
>       net/iavf: fix VLAN offload
>
> Yi Li (1):
>       doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
>       net/iavf: fix VLAN insertion
>       net/iavf: revert VLAN insertion fix
>       net/ice/base: fix duplicate flow rules
>       net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
>       net/bonding: fix array overflow in Rx burst
>       net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
>       net/ice: fix RSS hash update
>       net/iavf: fix processing VLAN TCI in SSE path
>       net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
>       graph: fix node objects allocation
>


-- 
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd

^ permalink raw reply	[relevance 0%]

* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 12:16  3%           ` Bruce Richardson
@ 2022-12-13 11:00  0%             ` Morten Brørup
  2022-12-13 17:12  3%             ` Bruce Richardson
  1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 11:00 UTC (permalink / raw)
  To: Bruce Richardson, Huisong Li
  Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen



Med venlig hilsen / Kind regards,
-Morten Brørup


> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 13.16
> To: Morten Brørup
> Cc: Huisong Li; dev@dpdk.org; ciara.power@intel.com;
> liudongdong3@huawei.com; huangdaode@huawei.com; fengchengwen@huawei.com
> Subject: Re: [PATCH V3 00/11] telemetry: add u32 value type and hex
> integer string API
> 
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by
> the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer
> capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem
> of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32
> and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix
> ABI
> > > > > break
> > > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for
> u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space
> internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for
> output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning
> that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a
> u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format,
> but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to
> wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require
> the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To
> make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would
> make
> > > sense to explicitly add it, but it seems like a lot of extra code
> for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion,
> so the existing _int function should be updated to take an int64_t
> value, and the _u64 function should be renamed to _uint (and still take
> an uint64_t value). However, that would break the ABI, and would need
> to go through some process for that. So let's not change this now.
> > </rant>
> 
> Yes, not making "int" an "i64" type was a poor design decision on my
> part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this
> as
> you suggest at the next ABI break window.
> 
> >
> > I tend to agree with Bruce on this: Let's get rid of the new u32
> functions, and rely on the u64 functions for that instead.
> >
> > >
> > > > >
> > > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > > instead
> > > > > only
> > > > > add the functions for outputting hex values. Those hex output
> > > functions
> > > > > could take an additional parameter indicating the desired hex
> > > output
> > > > > length, as there could well be cases where we want just 16-bit
> hex
> > > > > value
> > > > > too.
> > > >
> > > > The way I read the patch series, the hex output length is not
> fixed,
> > > but an u64 value of 5 will be output as 0x5, not
> 0x0000000000000005.
> > > >
> > > > So the only benefit of having both u32_hex and u64_hex functions
> is
> > > to avoid type promotion from uint32_t to uint64_t on input for 32
> bit
> > > values.
> > > >
> > > > Instead of passing a 3rd parameter or adding u16_hex functions,
> we
> > > could consider just having one set of hex functions using uint64_t
> for
> > > the value, and rely on type promotion for 32 and 16 bit values.
> > > >
> > >
> > > +1 to having only a single hex function, and I think type promotion
> > > should
> > > work fine.
> > >
> > > However, I still think it might be worthwhile allowing the user to
> pass
> > > in
> > > a min output length parameter too. I find for many hex strings
> having
> > > the
> > > leading zeros to explicitly show the length can be useful. The
> value
> > > "0"
> > > could cover the current behaviour of no-padding, otherwise the
> > > parameter
> > > should indicate the number of bits to be displayed. (If we want to
> lock
> > > it
> > > down we can use an enum parameter rather than int to limit it to 0,
> 8,
> > > 16,
> > > 32 or 64 bit displayed values).
> >
> > An extra parameter for minimum output length (in number of input
> bits) would be very nice, and makes avoids a set of functions for each
> bit width.
> >
> > (I don't think it should be lock it down to some special bit lengths;
> there is no need to prevent 24 bit or other exotic bit widths.)
> >
> > Something like this:
> >
> > char str[64]; // Big enough length.
> > if (bits != 0) {
> >   char format[16]; // Big enough length.
> >   sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> >   sprintf(str, format, value);
> > } else {
> >   sprintf(str, "0x%" PRIx64, value);
> > }
> >
> 
> LGTM.

From a higher level perspective, I'm wondering why passing an uint32_t as x to rte_tel_data_add_{dict|array}_int(struct rte_tel_data *d, int x) doesn't produce a compiler warning about risky type conversion. And similarly passing a signed value to the _u64 functions.

Wouldn't it make sense to wrap these functions in a macro, so -Wconversion could be enabled when they are used? (I guess -Wconversion is default disabled when building DPDK.)

-Morten


^ permalink raw reply	[relevance 0%]

* [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API
    2022-12-09 11:04  3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
  2022-12-12  6:42  3% ` [PATCH V3 " Huisong Li
@ 2022-12-13 10:15  3% ` Huisong Li
  2022-12-14 12:32  3% ` [PATCH V5 0/8] " Huisong Li
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-13 10:15 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (9):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping between value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 158 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  55 +++++++++-
 lib/telemetry/telemetry_data.c     |  86 ++++++++++++++--
 lib/telemetry/version.map          |   9 ++
 8 files changed, 327 insertions(+), 36 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
  2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
  2022-12-13  7:31  0% ` Ruifeng Wang
  2022-12-13  7:37  0% ` Anoob Joseph
@ 2022-12-13  8:22  0% ` Power, Ciara
  2022-12-14  9:32  0% ` Zhang, Fan
  2023-01-04  6:18  2% ` [PATCH v2] " Akhil Goyal
  4 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2022-12-13  8:22 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: fanzhang.oss, Ji, Kai, De Lara Guarch, Pablo, hemant.agrawal,
	matan, g.singh, ruifeng.wang, anoobj, Nicolau, Radu, vfialko,
	ktraynor, david.marchand, thomas

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday 12 December 2022 15:10
> To: dev@dpdk.org
> Cc: Power, Ciara <ciara.power@intel.com>; fanzhang.oss@gmail.com; Ji, Kai
> <kai.ji@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com;
> matan@nvidia.com; g.singh@nxp.com; ruifeng.wang@arm.com;
> anoobj@marvell.com; Nicolau, Radu <radu.nicolau@intel.com>;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com;
> thomas@monjalon.net; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
> 
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
<snip>

Acked-by: Ciara Power <ciara.power@intel.com>

^ permalink raw reply	[relevance 0%]

* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
  2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
  2022-12-13  7:31  0% ` Ruifeng Wang
@ 2022-12-13  7:37  0% ` Anoob Joseph
  2022-12-13  8:22  0% ` Power, Ciara
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2022-12-13  7:37 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
	hemant.agrawal, matan, g.singh, ruifeng.wang, radu.nicolau,
	Volodymyr Fialko, ktraynor, david.marchand, thomas, Akhil Goyal

> 
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>

Acked-by: Anoob Joseph <anoobj@marvell.com>

^ permalink raw reply	[relevance 0%]

* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
  2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
@ 2022-12-13  7:31  0% ` Ruifeng Wang
  2022-12-13  7:37  0% ` Anoob Joseph
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Ruifeng Wang @ 2022-12-13  7:31 UTC (permalink / raw)
  To: Akhil Goyal, dev
  Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
	hemant.agrawal, matan, g.singh, anoobj, radu.nicolau, vfialko,
	ktraynor, david.marchand, thomas, nd

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, December 12, 2022 11:10 PM
> To: dev@dpdk.org
> Cc: ciara.power@intel.com; fanzhang.oss@gmail.com; kai.ji@intel.com;
> pablo.de.lara.guarch@intel.com; hemant.agrawal@nxp.com; matan@nvidia.com; g.singh@nxp.com;
> Ruifeng Wang <Ruifeng.Wang@arm.com>; anoobj@marvell.com; radu.nicolau@intel.com;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com; thomas@monjalon.net;
> Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
> 
> Symmetric/Asymmetric algorithm strings are accessed by application using arrays in
> cryptodev lib, which hampers new algorithms addition in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break release.
> New APIs are added for getting the algorithm strings based on enum values.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
>  app/test-crypto-perf/cperf_options_parsing.c |   6 +-
>  app/test/test_cryptodev_asym.c               |   2 +-
>  app/test/test_cryptodev_security_ipsec.c     |   8 +-
>  doc/guides/rel_notes/deprecation.rst         |   7 +
>  drivers/crypto/openssl/rte_openssl_pmd_ops.c |   2 +-
>  drivers/crypto/qat/qat_sym_session.c         |   7 +-
>  examples/l2fwd-crypto/main.c                 |  12 +-
>  lib/cryptodev/cryptodev_trace_points.c       |  12 ++
>  lib/cryptodev/rte_crypto_asym.h              |   1 +
>  lib/cryptodev/rte_crypto_sym.h               |   3 +
>  lib/cryptodev/rte_cryptodev.c                | 182 ++++++++++++++++++-
>  lib/cryptodev/rte_cryptodev.h                |  52 ++++++
>  lib/cryptodev/rte_cryptodev_trace.h          |  32 ++++
>  lib/cryptodev/version.map                    |  10 +
>  14 files changed, 309 insertions(+), 27 deletions(-)
> 
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 12:03  3%         ` Morten Brørup
  2022-12-12 12:16  3%           ` Bruce Richardson
@ 2022-12-13  3:02  0%           ` lihuisong (C)
  1 sibling, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-13  3:02 UTC (permalink / raw)
  To: Morten Brørup, Bruce Richardson
  Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen


在 2022/12/12 20:03, Morten Brørup 写道:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Monday, 12 December 2022 12.21
>>
>> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>> Sent: Monday, 12 December 2022 11.32
>>>>
>>>> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
>>>>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>>>>> rte_tel_data_add_dict/array_int API. This may cause data
>> conversion
>>>> error
>>>>> or data truncation.
>>>>>
>>>>> The 'u32' data can not be assigned to signed 32-bit integer.
>> However,
>>>>> assigning to u64 is very wasteful, after all, the buffer capacity
>> of
>>>> each
>>>>> transfer is limited. So it is necessary for 'u32' data to add
>> usigned
>>>>> 32-bit integer type and a series of 'u32' operation APIs.
>>>>>
>>>>> This patchset uses the new 'u32' API to resolve the problem of
>> data
>>>>> conversion error, and use the 'u64' API to add 'u64' data.
>>>>>
>>>>> In addition, this patchset introduces two APIs to store u32 and
>> u64
>>>>> values as hexadecimal encoded strings in telemetry library.
>>>>>
>>>>> --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
>>>> break
>>>>> warning.  - introduce two APIs to store u32 and u64 values as
>>>> hexadecimal
>>>>> encoded strings.
>>>>>
>>>> I'm not convinced about adding the u32 value generically to the
>>>> telemetry
>>>> lib - except in the case of having explicit function calls for u32
>> vs
>>>> u64
>>>> hex strings. Having a u32 type doesn't gain us any space internally
>>>> over a
>>>> u64 value, since all values are in a union type. Also, for output
>> as
>>>> json,
>>>> the numeric values are all output as decimal values, meaning that
>> the
>>>> value
>>>> 1 appears as the same size in the output string whether it is a u32
>> or
>>>> u64
>>>> type. Now, it may save space in a future binary output format, but
>> even
>>>> then it still may not do so.
>>> I agree that a u32 doesn't gain any space internally.
>>>
>>> However, many SNMP counters are unsigned 32 bit, and expected to wrap
>> around as such.
>>> So I suppose the u32 type might be useful for SNMP, if obtained
>> through the telemetry library.
>>> Alternatively, we could somehow reuse the u64 type and require the
>> application to pass (value & UINT32_MAX) to the u64 functions. To make
>> this easy to use, we should add some wrappers to do it for the
>> application. And eventually we would probably end up with something
>> very similar to this patch.
>> I think just using the u64 functions is probably simplest and best
>> right
>> now. If we add support for something like snmp then yes, it would make
>> sense to explicitly add it, but it seems like a lot of extra code for
>> little or no benefit until we support something like that.
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
All right. Let's drop the new u32 functions.
>
>>>> Therefore, I'd tend to keep the existing u64 type as-is, and
>> instead
>>>> only
>>>> add the functions for outputting hex values. Those hex output
>> functions
>>>> could take an additional parameter indicating the desired hex
>> output
>>>> length, as there could well be cases where we want just 16-bit hex
>>>> value
>>>> too.
>>> The way I read the patch series, the hex output length is not fixed,
>> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>>> So the only benefit of having both u32_hex and u64_hex functions is
>> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
>> values.
>>> Instead of passing a 3rd parameter or adding u16_hex functions, we
>> could consider just having one set of hex functions using uint64_t for
>> the value, and rely on type promotion for 32 and 16 bit values.
>> +1 to having only a single hex function, and I think type promotion
>> should
>> work fine.
>>
>> However, I still think it might be worthwhile allowing the user to pass
>> in
>> a min output length parameter too. I find for many hex strings having
>> the
>> leading zeros to explicitly show the length can be useful. The value
>> "0"
>> could cover the current behaviour of no-padding, otherwise the
>> parameter
>> should indicate the number of bits to be displayed. (If we want to lock
>> it
>> down we can use an enum parameter rather than int to limit it to 0, 8,
>> 16,
>> 32 or 64 bit displayed values).
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
>    char format[16]; // Big enough length.
>    sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
>    sprintf(str, format, value);
> } else {
>    sprintf(str, "0x%" PRIx64, value);
> }
Fix it in v4.
>> All that said, I'm not massively concerned if we want to just keep the
>> current approach of always just printing without any leading zeros.
>> It's a
>> nice-to-have only for me.
>>
>> /Bruce
>
> .

^ permalink raw reply	[relevance 0%]

* [PATCH] cryptodev: add algo enums to string conversion APIs
@ 2022-12-12 15:10  2% Akhil Goyal
  2022-12-13  7:31  0% ` Ruifeng Wang
                   ` (4 more replies)
  0 siblings, 5 replies; 200+ results
From: Akhil Goyal @ 2022-12-12 15:10 UTC (permalink / raw)
  To: dev
  Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
	hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
	radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
	Akhil Goyal

Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.

Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
 app/test-crypto-perf/cperf_options_parsing.c |   6 +-
 app/test/test_cryptodev_asym.c               |   2 +-
 app/test/test_cryptodev_security_ipsec.c     |   8 +-
 doc/guides/rel_notes/deprecation.rst         |   7 +
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |   2 +-
 drivers/crypto/qat/qat_sym_session.c         |   7 +-
 examples/l2fwd-crypto/main.c                 |  12 +-
 lib/cryptodev/cryptodev_trace_points.c       |  12 ++
 lib/cryptodev/rte_crypto_asym.h              |   1 +
 lib/cryptodev/rte_crypto_sym.h               |   3 +
 lib/cryptodev/rte_cryptodev.c                | 182 ++++++++++++++++++-
 lib/cryptodev/rte_cryptodev.h                |  52 ++++++
 lib/cryptodev/rte_cryptodev_trace.h          |  32 ++++
 lib/cryptodev/version.map                    |  10 +
 14 files changed, 309 insertions(+), 27 deletions(-)

diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
 			opts->op_type == CPERF_CIPHER_THEN_AUTH ||
 			opts->op_type == CPERF_AUTH_THEN_CIPHER) {
 		printf("# auth algorithm: %s\n",
-			rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+			rte_cryptodev_get_auth_algo_string(opts->auth_algo));
 		printf("# auth operation: %s\n",
 			rte_crypto_auth_operation_strings[opts->auth_op]);
 		printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
 			opts->op_type == CPERF_CIPHER_THEN_AUTH ||
 			opts->op_type == CPERF_AUTH_THEN_CIPHER) {
 		printf("# cipher algorithm: %s\n",
-			rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+			rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
 		printf("# cipher operation: %s\n",
 			rte_crypto_cipher_operation_strings[opts->cipher_op]);
 		printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
 
 	if (opts->op_type == CPERF_AEAD) {
 		printf("# aead algorithm: %s\n",
-			rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+			rte_cryptodev_get_aead_algo_string(opts->aead_algo));
 		printf("# aead operation: %s\n",
 			rte_crypto_aead_operation_strings[opts->aead_op]);
 		printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
 	int i = 0;
 
 	printf("\nxform type: %s\n===================\n",
-			rte_crypto_asym_xform_strings[capa->xform_type]);
+			rte_cryptodev_asym_get_xform_string(capa->xform_type));
 	printf("operation supported -");
 
 	for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
 {
 	if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
 		printf("\t%s [%d]",
-		       rte_crypto_aead_algorithm_strings[param1->alg.aead],
+		       rte_cryptodev_get_aead_algo_string(param1->alg.aead),
 		       param1->key_length * 8);
 	} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
 		printf("\t%s",
-		       rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+		       rte_cryptodev_get_auth_algo_string(param1->alg.auth));
 		if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
 			printf(" [%dB ICV]", param1->digest_length);
 	} else {
 		printf("\t%s",
-		       rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+		       rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
 		if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
 			printf(" [%d]", param1->key_length * 8);
 		printf(" %s",
-		       rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+		       rte_cryptodev_get_auth_algo_string(param2->alg.auth));
 		if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
 			printf(" [%dB ICV]", param2->digest_length);
 	}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
   which got error interrupt to the application,
   so that application can reset that particular queue pair.
 
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+  ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+  ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+  Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+  ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+  ``rte_cryptodev_asym_get_xform_string`` respectively.
+
 * flow_classify: The flow_classify library and example have no maintainer.
   The library is experimental and, as such, it could be removed from DPDK.
   Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
 	if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
 		(xform->next != NULL)) {
 		OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
-			rte_crypto_asym_xform_strings[xform->xform_type]);
+			rte_cryptodev_asym_get_xform_string(xform->xform_type));
 		return ret;
 	}
 
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
 		if (!qat_is_cipher_alg_supported(
 			cipher_xform->algo, internals)) {
 			QAT_LOG(ERR, "%s not supported on this device",
-				rte_crypto_cipher_algorithm_strings
-					[cipher_xform->algo]);
+				rte_cryptodev_get_cipher_algo_string(
+					cipher_xform->algo));
 			ret = -ENOTSUP;
 			goto error_out;
 		}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
 	case RTE_CRYPTO_AUTH_ZUC_EIA3:
 		if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
 			QAT_LOG(ERR, "%s not supported on this device",
-				rte_crypto_auth_algorithm_strings
-				[auth_xform->algo]);
+				rte_cryptodev_get_auth_algo_string(auth_xform->algo));
 			return -ENOTSUP;
 		}
 		session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- Cipher information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+		rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
 	rte_hexdump(stdout, "Cipher key:",
 			options->cipher_xform.cipher.key.data,
 			options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- Authentication information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+		rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
 	rte_hexdump(stdout, "Auth key:",
 			options->auth_xform.auth.key.data,
 			options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
 {
 	printf("\n---- AEAD information ---\n");
 	printf("Algorithm: %s\n",
-		rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+		rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
 	rte_hexdump(stdout, "AEAD key:",
 			options->aead_xform.aead.key.data,
 			options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+			rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_auth_algorithm_strings[opt_auth_algo],
+			rte_cryptodev_get_auth_algo_string(opt_auth_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
 	if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
 		printf("Algorithm %s not supported by cryptodev %u"
 			" or device not of preferred type (%s)\n",
-			rte_crypto_aead_algorithm_strings[opt_aead_algo],
+			rte_cryptodev_get_aead_algo_string(opt_aead_algo),
 			cdev_id,
 			options->string_type);
 		return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
 	lib.cryptodev.get.cipher.algo.enum)
 
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+	lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+	lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+	lib.cryptodev.get.cipher.algo.string)
+
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
 	lib.cryptodev.get.dev.id)
 
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
 	lib.cryptodev.asym.get.xform.enum)
 
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+	lib.cryptodev.asym.get.xform.string)
+
 RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
 	lib.cryptodev.asym.xform.capability.check.modlen)
 
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
 struct rte_cryptodev_asym_session;
 
 /** asym xform type name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_asym_xform_strings[];
 
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
 };
 
 /** Cipher algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_cipher_algorithm_strings[];
 
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
 };
 
 /** Authentication algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_auth_algorithm_strings[];
 
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
 };
 
 /** AEAD algorithm name strings */
+__rte_deprecated
 extern const char *
 rte_crypto_aead_algorithm_strings[];
 
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..1e98f13dac 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
 };
 
 /**
+ * @deprecated
  * The crypto cipher algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_cipher_algorithm_strings[] = {
 	[RTE_CRYPTO_CIPHER_3DES_CBC]	= "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
 	[RTE_CRYPTO_CIPHER_SM4_CTR]	= "sm4-ctr"
 };
 
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+	[RTE_CRYPTO_CIPHER_3DES_CBC]	= "3des-cbc",
+	[RTE_CRYPTO_CIPHER_3DES_ECB]	= "3des-ecb",
+	[RTE_CRYPTO_CIPHER_3DES_CTR]	= "3des-ctr",
+
+	[RTE_CRYPTO_CIPHER_AES_CBC]	= "aes-cbc",
+	[RTE_CRYPTO_CIPHER_AES_CTR]	= "aes-ctr",
+	[RTE_CRYPTO_CIPHER_AES_DOCSISBPI]	= "aes-docsisbpi",
+	[RTE_CRYPTO_CIPHER_AES_ECB]	= "aes-ecb",
+	[RTE_CRYPTO_CIPHER_AES_F8]	= "aes-f8",
+	[RTE_CRYPTO_CIPHER_AES_XTS]	= "aes-xts",
+
+	[RTE_CRYPTO_CIPHER_ARC4]	= "arc4",
+
+	[RTE_CRYPTO_CIPHER_DES_CBC]     = "des-cbc",
+	[RTE_CRYPTO_CIPHER_DES_DOCSISBPI]	= "des-docsisbpi",
+
+	[RTE_CRYPTO_CIPHER_NULL]	= "null",
+
+	[RTE_CRYPTO_CIPHER_KASUMI_F8]	= "kasumi-f8",
+	[RTE_CRYPTO_CIPHER_SNOW3G_UEA2]	= "snow3g-uea2",
+	[RTE_CRYPTO_CIPHER_ZUC_EEA3]	= "zuc-eea3",
+	[RTE_CRYPTO_CIPHER_SM4_ECB]	= "sm4-ecb",
+	[RTE_CRYPTO_CIPHER_SM4_CBC]	= "sm4-cbc",
+	[RTE_CRYPTO_CIPHER_SM4_CTR]	= "sm4-ctr"
+};
+
 /**
  * The crypto cipher operation strings identifiers.
  * It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
 };
 
 /**
+ * @deprecated
  * The crypto auth algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_auth_algorithm_strings[] = {
 	[RTE_CRYPTO_AUTH_AES_CBC_MAC]	= "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
 };
 
 /**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+	[RTE_CRYPTO_AUTH_AES_CBC_MAC]	= "aes-cbc-mac",
+	[RTE_CRYPTO_AUTH_AES_CMAC]	= "aes-cmac",
+	[RTE_CRYPTO_AUTH_AES_GMAC]	= "aes-gmac",
+	[RTE_CRYPTO_AUTH_AES_XCBC_MAC]	= "aes-xcbc-mac",
+
+	[RTE_CRYPTO_AUTH_MD5]		= "md5",
+	[RTE_CRYPTO_AUTH_MD5_HMAC]	= "md5-hmac",
+
+	[RTE_CRYPTO_AUTH_NULL]		= "null",
+
+	[RTE_CRYPTO_AUTH_SHA1]		= "sha1",
+	[RTE_CRYPTO_AUTH_SHA1_HMAC]	= "sha1-hmac",
+
+	[RTE_CRYPTO_AUTH_SHA224]	= "sha2-224",
+	[RTE_CRYPTO_AUTH_SHA224_HMAC]	= "sha2-224-hmac",
+	[RTE_CRYPTO_AUTH_SHA256]	= "sha2-256",
+	[RTE_CRYPTO_AUTH_SHA256_HMAC]	= "sha2-256-hmac",
+	[RTE_CRYPTO_AUTH_SHA384]	= "sha2-384",
+	[RTE_CRYPTO_AUTH_SHA384_HMAC]	= "sha2-384-hmac",
+	[RTE_CRYPTO_AUTH_SHA512]	= "sha2-512",
+	[RTE_CRYPTO_AUTH_SHA512_HMAC]	= "sha2-512-hmac",
+
+	[RTE_CRYPTO_AUTH_SHA3_224]	= "sha3-224",
+	[RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_256]	= "sha3-256",
+	[RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_384]	= "sha3-384",
+	[RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+	[RTE_CRYPTO_AUTH_SHA3_512]	= "sha3-512",
+	[RTE_CRYPTO_AUTH_SHA3_512_HMAC]	= "sha3-512-hmac",
+
+	[RTE_CRYPTO_AUTH_KASUMI_F9]	= "kasumi-f9",
+	[RTE_CRYPTO_AUTH_SNOW3G_UIA2]	= "snow3g-uia2",
+	[RTE_CRYPTO_AUTH_ZUC_EIA3]	= "zuc-eia3",
+	[RTE_CRYPTO_AUTH_SM3]		= "sm3"
+};
+
+/**
+ * @deprecated
  * The crypto AEAD algorithm strings identifiers.
  * It could be used in application command line.
  */
+__rte_deprecated
 const char *
 rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
 };
 
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
+	[RTE_CRYPTO_AEAD_AES_GCM]	= "aes-gcm",
+	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
 /**
  * The crypto AEAD operation strings identifiers.
  * It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
 };
 
 /**
+ * @deprecated
  * Asymmetric crypto transform operation strings identifiers.
  */
+__rte_deprecated
 const char *rte_crypto_asym_xform_strings[] = {
 	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
 	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
@@ -183,6 +281,22 @@ const char *rte_crypto_asym_xform_strings[] = {
 	[RTE_CRYPTO_ASYM_XFORM_ECPM]	= "ecpm",
 };
 
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *crypto_asym_xform_strings[] = {
+	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
+	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
+	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
+	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
+	[RTE_CRYPTO_ASYM_XFORM_DH]	= "dh",
+	[RTE_CRYPTO_ASYM_XFORM_DSA]	= "dsa",
+	[RTE_CRYPTO_ASYM_XFORM_ECDSA]	= "ecdsa",
+	[RTE_CRYPTO_ASYM_XFORM_ECPM]	= "ecpm",
+};
+
 /**
  * Asymmetric crypto operation strings identifiers.
  */
@@ -227,8 +341,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_cipher_algorithm) i;
 			ret = 0;
 			break;
@@ -247,8 +361,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_auth_algorithm) i;
 			ret = 0;
 			break;
@@ -267,8 +381,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
-		if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+	for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+		if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
 			*algo_enum = (enum rte_crypto_aead_algorithm) i;
 			ret = 0;
 			break;
@@ -287,9 +401,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 	unsigned int i;
 	int ret = -1;	/* Invalid string */
 
-	for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+	for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
 		if (strcmp(xform_string,
-			rte_crypto_asym_xform_strings[i]) == 0) {
+			crypto_asym_xform_strings[i]) == 0) {
 			*xform_enum = (enum rte_crypto_asym_xform_type) i;
 			ret = 0;
 			break;
@@ -301,6 +415,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 	return ret;
 }
 
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if (algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+		alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if (algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+		alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+	const char *alg_str = NULL;
+
+	if (algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+		alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+	rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+	return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+	const char *xform_str = NULL;
+
+	if (xform_enum < RTE_DIM(crypto_asym_xform_strings))
+		xform_str = crypto_asym_xform_strings[xform_enum];
+
+	rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+	return xform_str;
+}
+
 /**
  * The crypto auth operation strings identifiers.
  * It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
 rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 		const char *xform_string);
 
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param	algo_enum	AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param	xform_enum	xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
 
 /** Macro used at end of crypto PMD list */
 #define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
 	rte_trace_point_emit_int(ret);
 )
 
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_aead_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_auth_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_get_cipher_algo_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+		const char *algo_string),
+	rte_trace_point_emit_int(algo_enum);
+	rte_trace_point_emit_string(algo_string);
+)
+
 RTE_TRACE_POINT(
 	rte_cryptodev_trace_get_dev_id,
 	RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
 	rte_trace_point_emit_int(ret);
 )
 
+RTE_TRACE_POINT(
+	rte_cryptodev_trace_asym_get_xform_string,
+	RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+		const char *xform_string),
+	rte_trace_point_emit_int(xform_enum);
+	rte_trace_point_emit_string(xform_string);
+)
+
 RTE_TRACE_POINT(
 	rte_cryptodev_trace_asym_xform_capability_check_modlen,
 	RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
 	__rte_cryptodev_trace_sym_session_get_user_data;
 	__rte_cryptodev_trace_sym_session_set_user_data;
 	__rte_cryptodev_trace_count;
+
+	# added 23.03
+	rte_cryptodev_asym_get_xform_string;
+	rte_cryptodev_get_aead_algo_string;
+	rte_cryptodev_get_auth_algo_string;
+	rte_cryptodev_get_cipher_algo_string;
 };
 
 INTERNAL {
 	global:
 
+	__rte_cryptodev_trace_asym_get_xform_string;
+	__rte_cryptodev_trace_get_aead_algo_string;
+	__rte_cryptodev_trace_get_auth_algo_string;
+	__rte_cryptodev_trace_get_cipher_algo_string;
 	cryptodev_fp_ops_reset;
 	cryptodev_fp_ops_set;
 	rte_cryptodev_allocate_driver;
-- 
2.25.1


^ permalink raw reply	[relevance 2%]

* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 12:03  3%         ` Morten Brørup
@ 2022-12-12 12:16  3%           ` Bruce Richardson
  2022-12-13 11:00  0%             ` Morten Brørup
  2022-12-13 17:12  3%             ` Bruce Richardson
  2022-12-13  3:02  0%           ` lihuisong (C)
  1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2022-12-12 12:16 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen

On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 12.21
> > 
> > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Monday, 12 December 2022 11.32
> > > >
> > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > conversion
> > > > error
> > > > > or data truncation.
> > > > >
> > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > However,
> > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > of
> > > > each
> > > > > transfer is limited. So it is necessary for 'u32' data to add
> > usigned
> > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > >
> > > > > This patchset uses the new 'u32' API to resolve the problem of
> > data
> > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > >
> > > > > In addition, this patchset introduces two APIs to store u32 and
> > u64
> > > > > values as hexadecimal encoded strings in telemetry library.
> > > > >
> > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > > break
> > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > hexadecimal
> > > > > encoded strings.
> > > > >
> > > > I'm not convinced about adding the u32 value generically to the
> > > > telemetry
> > > > lib - except in the case of having explicit function calls for u32
> > vs
> > > > u64
> > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > over a
> > > > u64 value, since all values are in a union type. Also, for output
> > as
> > > > json,
> > > > the numeric values are all output as decimal values, meaning that
> > the
> > > > value
> > > > 1 appears as the same size in the output string whether it is a u32
> > or
> > > > u64
> > > > type. Now, it may save space in a future binary output format, but
> > even
> > > > then it still may not do so.
> > >
> > > I agree that a u32 doesn't gain any space internally.
> > >
> > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > around as such.
> > >
> > > So I suppose the u32 type might be useful for SNMP, if obtained
> > through the telemetry library.
> > >
> > > Alternatively, we could somehow reuse the u64 type and require the
> > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > this easy to use, we should add some wrappers to do it for the
> > application. And eventually we would probably end up with something
> > very similar to this patch.
> > >
> > 
> > I think just using the u64 functions is probably simplest and best
> > right
> > now. If we add support for something like snmp then yes, it would make
> > sense to explicitly add it, but it seems like a lot of extra code for
> > little or no benefit until we support something like that.
> 
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>

Yes, not making "int" an "i64" type was a poor design decision on my part
in the earlier versions. Thankfully negative values are rarely needed
beyond the range of 32-bits, but we should probably look to update this as
you suggest at the next ABI break window.

> 
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
> 
> > 
> > > >
> > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > instead
> > > > only
> > > > add the functions for outputting hex values. Those hex output
> > functions
> > > > could take an additional parameter indicating the desired hex
> > output
> > > > length, as there could well be cases where we want just 16-bit hex
> > > > value
> > > > too.
> > >
> > > The way I read the patch series, the hex output length is not fixed,
> > but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> > >
> > > So the only benefit of having both u32_hex and u64_hex functions is
> > to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> > values.
> > >
> > > Instead of passing a 3rd parameter or adding u16_hex functions, we
> > could consider just having one set of hex functions using uint64_t for
> > the value, and rely on type promotion for 32 and 16 bit values.
> > >
> > 
> > +1 to having only a single hex function, and I think type promotion
> > should
> > work fine.
> > 
> > However, I still think it might be worthwhile allowing the user to pass
> > in
> > a min output length parameter too. I find for many hex strings having
> > the
> > leading zeros to explicitly show the length can be useful. The value
> > "0"
> > could cover the current behaviour of no-padding, otherwise the
> > parameter
> > should indicate the number of bits to be displayed. (If we want to lock
> > it
> > down we can use an enum parameter rather than int to limit it to 0, 8,
> > 16,
> > 32 or 64 bit displayed values).
> 
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
> 
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
> 
> Something like this:
> 
> char str[64]; // Big enough length.
> if (bits != 0) {
>   char format[16]; // Big enough length.
>   sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
>   sprintf(str, format, value);
> } else {
>   sprintf(str, "0x%" PRIx64, value);
> }
> 

LGTM.

^ permalink raw reply	[relevance 3%]

* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 11:20  0%       ` Bruce Richardson
@ 2022-12-12 12:03  3%         ` Morten Brørup
  2022-12-12 12:16  3%           ` Bruce Richardson
  2022-12-13  3:02  0%           ` lihuisong (C)
  0 siblings, 2 replies; 200+ results
From: Morten Brørup @ 2022-12-12 12:03 UTC (permalink / raw)
  To: Bruce Richardson, Huisong Li
  Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 12.21
> 
> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 11.32
> > >
> > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > rte_tel_data_add_dict/array_int API. This may cause data
> conversion
> > > error
> > > > or data truncation.
> > > >
> > > > The 'u32' data can not be assigned to signed 32-bit integer.
> However,
> > > > assigning to u64 is very wasteful, after all, the buffer capacity
> of
> > > each
> > > > transfer is limited. So it is necessary for 'u32' data to add
> usigned
> > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > >
> > > > This patchset uses the new 'u32' API to resolve the problem of
> data
> > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > >
> > > > In addition, this patchset introduces two APIs to store u32 and
> u64
> > > > values as hexadecimal encoded strings in telemetry library.
> > > >
> > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > break
> > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > hexadecimal
> > > > encoded strings.
> > > >
> > > I'm not convinced about adding the u32 value generically to the
> > > telemetry
> > > lib - except in the case of having explicit function calls for u32
> vs
> > > u64
> > > hex strings. Having a u32 type doesn't gain us any space internally
> > > over a
> > > u64 value, since all values are in a union type. Also, for output
> as
> > > json,
> > > the numeric values are all output as decimal values, meaning that
> the
> > > value
> > > 1 appears as the same size in the output string whether it is a u32
> or
> > > u64
> > > type. Now, it may save space in a future binary output format, but
> even
> > > then it still may not do so.
> >
> > I agree that a u32 doesn't gain any space internally.
> >
> > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> around as such.
> >
> > So I suppose the u32 type might be useful for SNMP, if obtained
> through the telemetry library.
> >
> > Alternatively, we could somehow reuse the u64 type and require the
> application to pass (value & UINT32_MAX) to the u64 functions. To make
> this easy to use, we should add some wrappers to do it for the
> application. And eventually we would probably end up with something
> very similar to this patch.
> >
> 
> I think just using the u64 functions is probably simplest and best
> right
> now. If we add support for something like snmp then yes, it would make
> sense to explicitly add it, but it seems like a lot of extra code for
> little or no benefit until we support something like that.

<rant>
If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
</rant>

I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.

> 
> > >
> > > Therefore, I'd tend to keep the existing u64 type as-is, and
> instead
> > > only
> > > add the functions for outputting hex values. Those hex output
> functions
> > > could take an additional parameter indicating the desired hex
> output
> > > length, as there could well be cases where we want just 16-bit hex
> > > value
> > > too.
> >
> > The way I read the patch series, the hex output length is not fixed,
> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> >
> > So the only benefit of having both u32_hex and u64_hex functions is
> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> values.
> >
> > Instead of passing a 3rd parameter or adding u16_hex functions, we
> could consider just having one set of hex functions using uint64_t for
> the value, and rely on type promotion for 32 and 16 bit values.
> >
> 
> +1 to having only a single hex function, and I think type promotion
> should
> work fine.
> 
> However, I still think it might be worthwhile allowing the user to pass
> in
> a min output length parameter too. I find for many hex strings having
> the
> leading zeros to explicitly show the length can be useful. The value
> "0"
> could cover the current behaviour of no-padding, otherwise the
> parameter
> should indicate the number of bits to be displayed. (If we want to lock
> it
> down we can use an enum parameter rather than int to limit it to 0, 8,
> 16,
> 32 or 64 bit displayed values).

An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.

(I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)

Something like this:

char str[64]; // Big enough length.
if (bits != 0) {
  char format[16]; // Big enough length.
  sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
  sprintf(str, format, value);
} else {
  sprintf(str, "0x%" PRIx64, value);
}

> 
> All that said, I'm not massively concerned if we want to just keep the
> current approach of always just printing without any leading zeros.
> It's a
> nice-to-have only for me.
> 
> /Bruce


^ permalink raw reply	[relevance 3%]

* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 11:02  0%     ` Morten Brørup
@ 2022-12-12 11:20  0%       ` Bruce Richardson
  2022-12-12 12:03  3%         ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 11:20 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen

On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 11.32
> > 
> > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > rte_tel_data_add_dict/array_int API. This may cause data conversion
> > error
> > > or data truncation.
> > >
> > > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > > assigning to u64 is very wasteful, after all, the buffer capacity of
> > each
> > > transfer is limited. So it is necessary for 'u32' data to add usigned
> > > 32-bit integer type and a series of 'u32' operation APIs.
> > >
> > > This patchset uses the new 'u32' API to resolve the problem of data
> > > conversion error, and use the 'u64' API to add 'u64' data.
> > >
> > > In addition, this patchset introduces two APIs to store u32 and u64
> > > values as hexadecimal encoded strings in telemetry library.
> > >
> > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > break
> > > warning.  - introduce two APIs to store u32 and u64 values as
> > hexadecimal
> > > encoded strings.
> > >
> > I'm not convinced about adding the u32 value generically to the
> > telemetry
> > lib - except in the case of having explicit function calls for u32 vs
> > u64
> > hex strings. Having a u32 type doesn't gain us any space internally
> > over a
> > u64 value, since all values are in a union type. Also, for output as
> > json,
> > the numeric values are all output as decimal values, meaning that the
> > value
> > 1 appears as the same size in the output string whether it is a u32 or
> > u64
> > type. Now, it may save space in a future binary output format, but even
> > then it still may not do so.
> 
> I agree that a u32 doesn't gain any space internally.
> 
> However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
> 
> So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
> 
> Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
> 

I think just using the u64 functions is probably simplest and best right
now. If we add support for something like snmp then yes, it would make
sense to explicitly add it, but it seems like a lot of extra code for
little or no benefit until we support something like that.

> > 
> > Therefore, I'd tend to keep the existing u64 type as-is, and instead
> > only
> > add the functions for outputting hex values. Those hex output functions
> > could take an additional parameter indicating the desired hex output
> > length, as there could well be cases where we want just 16-bit hex
> > value
> > too.
> 
> The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> 
> So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
> 
> Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
> 

+1 to having only a single hex function, and I think type promotion should
work fine.

However, I still think it might be worthwhile allowing the user to pass in
a min output length parameter too. I find for many hex strings having the
leading zeros to explicitly show the length can be useful. The value "0"
could cover the current behaviour of no-padding, otherwise the parameter
should indicate the number of bits to be displayed. (If we want to lock it
down we can use an enum parameter rather than int to limit it to 0, 8, 16,
32 or 64 bit displayed values).

All that said, I'm not massively concerned if we want to just keep the
current approach of always just printing without any leading zeros. It's a
nice-to-have only for me.

/Bruce

^ permalink raw reply	[relevance 0%]

* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12 10:31  0%   ` Bruce Richardson
@ 2022-12-12 11:02  0%     ` Morten Brørup
  2022-12-12 11:20  0%       ` Bruce Richardson
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-12 11:02 UTC (permalink / raw)
  To: Bruce Richardson, Huisong Li
  Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 11.32
> 
> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > rte_tel_data_add_dict/array_int API. This may cause data conversion
> error
> > or data truncation.
> >
> > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > assigning to u64 is very wasteful, after all, the buffer capacity of
> each
> > transfer is limited. So it is necessary for 'u32' data to add usigned
> > 32-bit integer type and a series of 'u32' operation APIs.
> >
> > This patchset uses the new 'u32' API to resolve the problem of data
> > conversion error, and use the 'u64' API to add 'u64' data.
> >
> > In addition, this patchset introduces two APIs to store u32 and u64
> > values as hexadecimal encoded strings in telemetry library.
> >
> > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> break
> > warning.  - introduce two APIs to store u32 and u64 values as
> hexadecimal
> > encoded strings.
> >
> I'm not convinced about adding the u32 value generically to the
> telemetry
> lib - except in the case of having explicit function calls for u32 vs
> u64
> hex strings. Having a u32 type doesn't gain us any space internally
> over a
> u64 value, since all values are in a union type. Also, for output as
> json,
> the numeric values are all output as decimal values, meaning that the
> value
> 1 appears as the same size in the output string whether it is a u32 or
> u64
> type. Now, it may save space in a future binary output format, but even
> then it still may not do so.

I agree that a u32 doesn't gain any space internally.

However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.

So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.

Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.

> 
> Therefore, I'd tend to keep the existing u64 type as-is, and instead
> only
> add the functions for outputting hex values. Those hex output functions
> could take an additional parameter indicating the desired hex output
> length, as there could well be cases where we want just 16-bit hex
> value
> too.

The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.

So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.

Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.


^ permalink raw reply	[relevance 0%]

* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-12  6:42  3% ` [PATCH V3 " Huisong Li
@ 2022-12-12 10:31  0%   ` Bruce Richardson
  2022-12-12 11:02  0%     ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 10:31 UTC (permalink / raw)
  To: Huisong Li; +Cc: dev, mb, ciara.power, liudongdong3, huangdaode, fengchengwen

On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion error
> or data truncation.
> 
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of each
> transfer is limited. So it is necessary for 'u32' data to add usigned
> 32-bit integer type and a series of 'u32' operation APIs.
> 
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
> 
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library. 
> 
> --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI break
> warning.  - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings. 
>
I'm not convinced about adding the u32 value generically to the telemetry
lib - except in the case of having explicit function calls for u32 vs u64
hex strings. Having a u32 type doesn't gain us any space internally over a
u64 value, since all values are in a union type. Also, for output as json,
the numeric values are all output as decimal values, meaning that the value
1 appears as the same size in the output string whether it is a u32 or u64
type. Now, it may save space in a future binary output format, but even
then it still may not do so.

Therefore, I'd tend to keep the existing u64 type as-is, and instead only
add the functions for outputting hex values. Those hex output functions
could take an additional parameter indicating the desired hex output
length, as there could well be cases where we want just 16-bit hex value
too.

/Bruce

^ permalink raw reply	[relevance 0%]

* [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
    2022-12-09 11:04  3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-12  6:42  3% ` Huisong Li
  2022-12-12 10:31  0%   ` Bruce Richardson
  2022-12-13 10:15  3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-12  6:42 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.

The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.

This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.

In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library. 

---
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (11):
  telemetry: move to header to controllable range
  telemetry: add u32 value type
  test: add test cases for adding u32 value API
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping betwween value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer values API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c     |  23 ++-
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  14 +-
 lib/ethdev/rte_ethdev.c            |  13 +-
 lib/mempool/rte_mempool.c          |  24 +--
 lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
 lib/telemetry/telemetry.c          |  25 ++-
 lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
 lib/telemetry/telemetry_data.h     |   2 +
 lib/telemetry/telemetry_json.h     |  29 ++++
 lib/telemetry/version.map          |  14 ++
 12 files changed, 581 insertions(+), 48 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-09 18:24  0%   ` Morten Brørup
@ 2022-12-12  6:23  0%     ` lihuisong (C)
  0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-12  6:23 UTC (permalink / raw)
  To: Morten Brørup, dev
  Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen


在 2022/12/10 2:24, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Friday, 9 December 2022 12.05
>>
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation.
>>
>> The 'u32' data can not be assigned to signed 32-bit integer. However,
>> assigning to u64 is very wasteful, after all, the buffer capacity of
>> each transfer is limited. So it is necessary for 'u32' data to add
>> usigned 32-bit integer type and a series of 'u32' operation APIs.
>>
>> This patchset uses the new 'u32' API to resolve the problem of data
>> conversion error, and use the 'u64' API to add 'u64' data.
>>
>> In addition, this patchset introduces two APIs to store u32 and u64
>> values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>>   -v2:
>>      - fix ABI break warning.
>>      - introduce two APIs to store u32 and u64 values as hexadecimal
>>        encoded strings.
> Looks good.
>
> Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
I think this name can represent the type of value stored in dict or 
array.😁
>
> In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Yes, you are right. I'll try fix it in another patch.
>
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
>
> .

^ permalink raw reply	[relevance 0%]

* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-09 11:04  3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
  2022-12-09 18:24  0%   ` Morten Brørup
@ 2022-12-11  9:02  0%   ` fengchengwen
  1 sibling, 0 replies; 200+ results
From: fengchengwen @ 2022-12-11  9:02 UTC (permalink / raw)
  To: Huisong Li, dev
  Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode

LGTM
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>

On 2022/12/9 19:04, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
>   -v2:
>      - fix ABI break warning.
>      - introduce two APIs to store u32 and u64 values as hexadecimal
>        encoded strings.
>
> Huisong Li (11):
>    telemetry: move to header to controllable range
>    telemetry: add u32 value type
>    test: add test cases for adding u32 value API
>    ethdev: fix possible data truncation and conversion error
>    mempool: fix possible data truncation and conversion error
>    cryptodev: fix possible data conversion error
>    mem: possible data truncation and conversion error
>    telemetry: refactor mapping betwween value and array type
>    telemetry: support adding integer value as hexadecimal
>    test: add test cases for adding hex integer values API
>    ethdev: display capability values in hexadecimal format
>
>   app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
>   app/test/test_telemetry_json.c     |  23 ++-
>   lib/cryptodev/rte_cryptodev.c      |   2 +-
>   lib/eal/common/eal_common_memory.c |  14 +-
>   lib/ethdev/rte_ethdev.c            |  13 +-
>   lib/mempool/rte_mempool.c          |  24 +--
>   lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
>   lib/telemetry/telemetry.c          |  25 ++-
>   lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
>   lib/telemetry/telemetry_data.h     |   2 +
>   lib/telemetry/telemetry_json.h     |  29 ++++
>   lib/telemetry/version.map          |  14 ++
>   12 files changed, 581 insertions(+), 48 deletions(-)
>

^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  2022-12-09 22:38  0%             ` Stephen Hemminger
@ 2022-12-09 23:55  0%               ` Tyler Retzlaff
  0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 23:55 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
	Bruce Richardson

On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 22:14:33 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 09/12/2022 17:48, Stephen Hemminger:
> > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >   
> > > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.    
> > > > > 
> > > > > i think this raises a good question. is the purpose of setting a thread name
> > > > > meant to be something we can use from the application or is it something that
> > > > > is for debugging diagnostics and may be a best effort?    
> > > > 
> > > > I think yes it is only for debugging.
> > > > So best effort looks to be a good approach.
> > > > I'm not sure you need to replace the functions.
> > > > Can you just complete the implementations?  
> > > 
> > > 
> > > Surprisingly, thread names are not preserved in core dumps.
> > > The core dump standard used by Linux does not put thread name in the image.
> > > Since this is a ELF ABI unlikely to be ever be added.  
> > 
> > What is missing exactly to have thread name in the core dump?
> > 
> > 
> 
> Linux core dump file format is ELF.
> The thread info is storewd in the file notes as NT_PRPSINFO
> which contains info but not the thread name. In the kernel
> thread name is under comm.
> 
> 
> typedef struct prpsinfo {       /* Information about process                 */
>   unsigned char  pr_state;      /* Numeric process state                     */
>   char           pr_sname;      /* Char for pr_state                         */
>   unsigned char  pr_zomb;       /* Zombie                                    */
>   signed char    pr_nice;       /* Nice val                                  */
>   unsigned long  pr_flag;       /* Flags                                     */
> 
>   uint32_t       pr_uid;        /* User ID                                   */
>   uint32_t       pr_gid;        /* Group ID                                  */
> 
>   pid_t          pr_pid;        /* Process ID                                */
>   pid_t          pr_ppid;       /* Parent's process ID                       */
>   pid_t          pr_pgrp;       /* Group ID                                  */
>   pid_t          pr_sid;        /* Session ID                                */
>   char           pr_fname[16];  /* Filename of executable                    */
>   char           pr_psargs[80]; /* Initial part of arg list                  */
> } prpsinfo;
> 
> 
> Stack Overflow leads to this pages
> https://www.gabriel.urdhr.fr/2015/05/29/core-file/
> https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
> 
> Only know this because of investigating how to get thread names
> to show up in Azure with Watson.

from a dpdk specific perspective if we want to consistently have a
thread name in a dump / coredump then we have a better chance of
success just storing it in our applications namespace ourselves.
relying on platform-specific facilities to preserve it seems hit and
miss at best.

^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  2022-12-09 21:14  0%           ` Thomas Monjalon
@ 2022-12-09 22:38  0%             ` Stephen Hemminger
  2022-12-09 23:55  0%               ` Tyler Retzlaff
  0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-12-09 22:38 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Tyler Retzlaff, Morten Brørup, dev, david.marchand,
	Bruce Richardson

On Fri, 09 Dec 2022 22:14:33 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 09/12/2022 17:48, Stephen Hemminger:
> > On Fri, 09 Dec 2022 08:53:57 +0100
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >   
> > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.    
> > > > 
> > > > i think this raises a good question. is the purpose of setting a thread name
> > > > meant to be something we can use from the application or is it something that
> > > > is for debugging diagnostics and may be a best effort?    
> > > 
> > > I think yes it is only for debugging.
> > > So best effort looks to be a good approach.
> > > I'm not sure you need to replace the functions.
> > > Can you just complete the implementations?  
> > 
> > 
> > Surprisingly, thread names are not preserved in core dumps.
> > The core dump standard used by Linux does not put thread name in the image.
> > Since this is a ELF ABI unlikely to be ever be added.  
> 
> What is missing exactly to have thread name in the core dump?
> 
> 

Linux core dump file format is ELF.
The thread info is storewd in the file notes as NT_PRPSINFO
which contains info but not the thread name. In the kernel
thread name is under comm.


typedef struct prpsinfo {       /* Information about process                 */
  unsigned char  pr_state;      /* Numeric process state                     */
  char           pr_sname;      /* Char for pr_state                         */
  unsigned char  pr_zomb;       /* Zombie                                    */
  signed char    pr_nice;       /* Nice val                                  */
  unsigned long  pr_flag;       /* Flags                                     */

  uint32_t       pr_uid;        /* User ID                                   */
  uint32_t       pr_gid;        /* Group ID                                  */

  pid_t          pr_pid;        /* Process ID                                */
  pid_t          pr_ppid;       /* Parent's process ID                       */
  pid_t          pr_pgrp;       /* Group ID                                  */
  pid_t          pr_sid;        /* Session ID                                */
  char           pr_fname[16];  /* Filename of executable                    */
  char           pr_psargs[80]; /* Initial part of arg list                  */
} prpsinfo;


Stack Overflow leads to this pages
https://www.gabriel.urdhr.fr/2015/05/29/core-file/
https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html

Only know this because of investigating how to get thread names
to show up in Azure with Watson.

^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  2022-12-09 16:48  3%         ` Stephen Hemminger
  2022-12-09 20:06  0%           ` Tyler Retzlaff
@ 2022-12-09 21:14  0%           ` Thomas Monjalon
  2022-12-09 22:38  0%             ` Stephen Hemminger
  1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-09 21:14 UTC (permalink / raw)
  To: Stephen Hemminger, Tyler Retzlaff
  Cc: Morten Brørup, dev, david.marchand, Bruce Richardson

09/12/2022 17:48, Stephen Hemminger:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.  
> > > 
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?  
> > 
> > I think yes it is only for debugging.
> > So best effort looks to be a good approach.
> > I'm not sure you need to replace the functions.
> > Can you just complete the implementations?
> 
> 
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.

What is missing exactly to have thread name in the core dump?



^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  2022-12-09 16:48  3%         ` Stephen Hemminger
@ 2022-12-09 20:06  0%           ` Tyler Retzlaff
  2022-12-09 21:14  0%           ` Thomas Monjalon
  1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 20:06 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
	Bruce Richardson

hey,

combining the reply to both Thomas and Stephen since i think this series
http://mails.dpdk.org/archives/dev/2022-December/257238.html addresses
both feedback comments.

On Fri, Dec 09, 2022 at 08:48:14AM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.  
> > > 
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?  
> > 

> Thomas Monjalon <thomas@monjalon.net> wrote:

> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?

the patch series put forward allows a set / get name per-lcore, where
you get implicit (but not exposed via the eal api) call to underlying
platform thread setname.

the intent here is if you have it and it works you'll get it and if you
don't you won't but the eal doesn't force the application to deal with it
conditionally on a per-platform basis.

> Stephen wrote:
> 
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.

the patchset addresses this by actually keeping a copy of the name set,
so it will be available in the coredump.

the intent here is to make it available for use by the application i.e.
get that works on all platforms, but also you can actually pull the name
out under a debugger or a dump and does not require any conditional
dancing per-platform by the application.

as an aside there are 2 series up for review that finally clean the
remaining platform-specific thread references from the eal public
interface.

http://mails.dpdk.org/archives/dev/2022-December/257238.html
http://mails.dpdk.org/archives/dev/2022-December/257413.html

the set get name api patch series i'm preparing a v2 for due to some
minor things caught by the ci and an issue with mingw but otherwise if
we can get these in it will unblock a lot of the internal detail
cleanups we've been trying to accomplish.

really appreciate it guys.

thanks.

^ permalink raw reply	[relevance 0%]

* RE: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
  2022-12-09 11:04  3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-09 18:24  0%   ` Morten Brørup
  2022-12-12  6:23  0%     ` lihuisong (C)
  2022-12-11  9:02  0%   ` fengchengwen
  1 sibling, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-09 18:24 UTC (permalink / raw)
  To: Huisong Li, dev
  Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen

> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Friday, 9 December 2022 12.05
> 
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
> 
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
> 
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
> 
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
> 
> ---
>  -v2:
>     - fix ABI break warning.
>     - introduce two APIs to store u32 and u64 values as hexadecimal
>       encoded strings.

Looks good.

Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.

In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?


Series-acked-by: Morten Brørup <mb@smartsharesystems.com>


^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  @ 2022-12-09 16:48  3%         ` Stephen Hemminger
  2022-12-09 20:06  0%           ` Tyler Retzlaff
  2022-12-09 21:14  0%           ` Thomas Monjalon
  0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2022-12-09 16:48 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Morten Brørup, Tyler Retzlaff, dev, david.marchand,
	Bruce Richardson

On Fri, 09 Dec 2022 08:53:57 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.  
> > 
> > i think this raises a good question. is the purpose of setting a thread name
> > meant to be something we can use from the application or is it something that
> > is for debugging diagnostics and may be a best effort?  
> 
> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?


Surprisingly, thread names are not preserved in core dumps.
The core dump standard used by Linux does not put thread name in the image.
Since this is a ELF ABI unlikely to be ever be added.

^ permalink raw reply	[relevance 3%]

* [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
  @ 2022-12-09 11:04  3% ` Huisong Li
  2022-12-09 18:24  0%   ` Morten Brørup
  2022-12-11  9:02  0%   ` fengchengwen
  2022-12-12  6:42  3% ` [PATCH V3 " Huisong Li
                   ` (5 subsequent siblings)
  6 siblings, 2 replies; 200+ results
From: Huisong Li @ 2022-12-09 11:04 UTC (permalink / raw)
  To: dev
  Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
	fengchengwen, lihuisong

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.

The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.

This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.

In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library. 

---
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (11):
  telemetry: move to header to controllable range
  telemetry: add u32 value type
  test: add test cases for adding u32 value API
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping betwween value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer values API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c     |  23 ++-
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  14 +-
 lib/ethdev/rte_ethdev.c            |  13 +-
 lib/mempool/rte_mempool.c          |  24 +--
 lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
 lib/telemetry/telemetry.c          |  25 ++-
 lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
 lib/telemetry/telemetry_data.h     |   2 +
 lib/telemetry/telemetry_json.h     |  29 ++++
 lib/telemetry/version.map          |  14 ++
 12 files changed, 581 insertions(+), 48 deletions(-)

-- 
2.33.0


^ permalink raw reply	[relevance 3%]

* [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
  @ 2022-12-09  9:02 13%   ` David Marchand
  2022-12-21 15:02  4%     ` David Marchand
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-09  9:02 UTC (permalink / raw)
  To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit

From: Ferruh Yigit <ferruh.yigit@amd.com>

By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.

This patch enables selecting different repository to clone for reference
using 'DPDK_ABI_REF_SRC' environment variable.
'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
repository, or a remote git repository.

It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
 DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
 DPDK_ABI_REF_VERSION=v22.11.1     \
 DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
 ./devtools/test-meson-builds.sh
`

When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.

Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.

Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v1:
- expanded DPDK_ABI_REF_SRC usage to "non-local" sources,

---
 devtools/test-meson-builds.sh | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 02541c19aa..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -19,6 +19,7 @@ srcdir=$(dirname $(readlink -f $0))/..
 # - DPDK_MESON_OPTIONS
 #
 # - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
 # - DPDK_ABI_REF_VERSION
 #
 # - DPDK_BUILD_TEST_EXAMPLES
@@ -187,10 +188,15 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
 		if [ ! -d $abirefdir/$targetdir ]; then
 			# clone current sources
 			if [ ! -d $abirefdir/src ]; then
-				git clone --local --no-hardlinks \
+				abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+				abirefcloneopts=
+				if [ -d $abirefsrc ]; then
+					abirefcloneopts="--local --no-hardlinks"
+				fi
+				git clone $abirefcloneopts \
 					--single-branch \
 					-b $DPDK_ABI_REF_VERSION \
-					$srcdir $abirefdir/src
+					$abirefsrc $abirefdir/src
 			fi
 
 			rm -rf $abirefdir/build
-- 
2.38.1


^ permalink raw reply	[relevance 13%]

* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
  2022-12-09  8:22  8%   ` David Marchand
@ 2022-12-09  8:44  4%     ` Ferruh Yigit
  0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-12-09  8:44 UTC (permalink / raw)
  To: David Marchand; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal

On 12/9/2022 8:22 AM, David Marchand wrote:
> On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>
>> By default 'test-meson-builds.sh' script clones the repository which the
>> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
>> as a reference for ABI check.
>>
>> This patch enables selecting different repository to close for reference
>> using 'DPDK_ABI_REF_SRC' environment variable.
>>
>> It is possible to put these variables to 'devel.config' config file, or
>> provide via command line, like:
>> `
>>  DPDK_ABI_REF_SRC=~/dpdk-stable/   \
> 
> DPDK_ABI_REF_SRC could be passed as a remote repository.
> This should remove the need for any "git remote" configuration.
> 
> $ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
> DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh
> 

+1 to 'DPDK_ABI_REF_SRC' accept either folder or remote git repo.

Can you send a v2 with your sign off added, or do you want me send a v2?

> 
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 406bf4e184..48f4e52df3 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
>  #
>  # - DPDK_MESON_OPTIONS
>  #
> -# - DPDK_ABI_REF_SRC
>  # - DPDK_ABI_REF_DIR
> +# - DPDK_ABI_REF_SRC
>  # - DPDK_ABI_REF_VERSION
>  #
>  # - DPDK_BUILD_TEST_EXAMPLES
> @@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
> <ABI check> [meson options]
>         if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
>                 abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
>                 if [ ! -d $abirefdir/$targetdir ]; then
> -                       abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
>                         # clone current sources
>                         if [ ! -d $abirefdir/src ]; then
> -                               git clone --local --no-hardlinks \
> +                               abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
> +                               abirefcloneopts=
> +                               if [ -d $abirefsrc ]; then
> +                                       abirefcloneopts="--local --no-hardlinks"
> +                               fi
> +                               git clone $abirefcloneopts \
>                                         --single-branch \
>                                         -b $DPDK_ABI_REF_VERSION \
>                                         $abirefsrc $abirefdir/src
> 
> 
>>  DPDK_ABI_REF_VERSION=v22.11.1     \
>>  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>>  ./devtools/test-meson-builds.sh
>> `
>>
>> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
>> previously.
>>
>> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
>> other repo as a new 'remote' to the exiting git repository.
> 
> 
> 


^ permalink raw reply	[relevance 4%]

* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
  2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
  2022-12-08 18:14  7%   ` [EXT] " Akhil Goyal
@ 2022-12-09  8:22  8%   ` David Marchand
  2022-12-09  8:44  4%     ` Ferruh Yigit
  1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-12-09  8:22 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal

On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
>  DPDK_ABI_REF_SRC=~/dpdk-stable/   \

DPDK_ABI_REF_SRC could be passed as a remote repository.
This should remove the need for any "git remote" configuration.

$ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh


diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 406bf4e184..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
 #
 # - DPDK_MESON_OPTIONS
 #
-# - DPDK_ABI_REF_SRC
 # - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
 # - DPDK_ABI_REF_VERSION
 #
 # - DPDK_BUILD_TEST_EXAMPLES
@@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
<ABI check> [meson options]
        if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
                abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
                if [ ! -d $abirefdir/$targetdir ]; then
-                       abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
                        # clone current sources
                        if [ ! -d $abirefdir/src ]; then
-                               git clone --local --no-hardlinks \
+                               abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+                               abirefcloneopts=
+                               if [ -d $abirefsrc ]; then
+                                       abirefcloneopts="--local --no-hardlinks"
+                               fi
+                               git clone $abirefcloneopts \
                                        --single-branch \
                                        -b $DPDK_ABI_REF_VERSION \
                                        $abirefsrc $abirefdir/src


>  DPDK_ABI_REF_VERSION=v22.11.1     \
>  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>  ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.



-- 
David Marchand


^ permalink raw reply	[relevance 8%]

* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
  2022-12-08 19:43  4%     ` Thomas Monjalon
@ 2022-12-09  4:16  4%       ` Akhil Goyal
  0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-09  4:16 UTC (permalink / raw)
  To: Thomas Monjalon, Ferruh Yigit, Bruce Richardson; +Cc: David Marchand, dev

> 08/12/2022 19:14, Akhil Goyal:
> > > By default 'test-meson-builds.sh' script clones the repository which the
> > > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > > as a reference for ABI check.
> > >
> > > This patch enables selecting different repository to close for reference
> > > using 'DPDK_ABI_REF_SRC' environment variable.
> > >
> > > It is possible to put these variables to 'devel.config' config file, or
> > > provide via command line, like:
> > > `
> > >  DPDK_ABI_REF_SRC=~/dpdk-stable/   \
> > >  DPDK_ABI_REF_VERSION=v22.11.1     \
> > >  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> > >  ./devtools/test-meson-builds.sh
> > > `
> > >
> > > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > > previously.
> > >
> > > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > > other repo as a new 'remote' to the exiting git repository.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > ---
> >
> > Acked-by: Akhil Goyal <gakhil@marvell.com>
> >
> > Worked for me, but I still needed to clone the dpdk-stable repo manually.
> > I was hoping, test-meson-build.sh would do that by itself.
> > Had it been a tag in same repo, it would have been straight forward as before.
> > I would still suggest to add a tag v22.11.1 in main branch and all can use that
> instead of v22.11.
> 
> First, v22.11.1 exists already in dpdk-stable.
> Second, vXX.YY.z tags are supposed to be only in dpdk-stable.

May be some other tag name we can think. v22.11.hotfix or something better.
I was just asking to give a name to commit, and NOT updating the VERSION file.

> 
> > The fix that we are talking about is a mandatory one for each one to use for
> ABI checks,
> > dpdk-stable patches are not mandatory for the users.
> 
> You could have dpdk-stable as a remote in your main DPDK directory.
> If you don't want to do that, you could refer to the commit SHA1 of the fix I
> think.
> 
Adding remote did not solve the issue as the commits are different(version commit).
I cloned stable repo separately and it worked for me.
Since you refer to use commit SHA, why not give it a name, remembering SHA is not easy.

-Akhil


^ permalink raw reply	[relevance 4%]

* Re: [PATCH v2 1/3] eal: add rte control thread create API
  2022-12-07 16:38  3%       ` Tyler Retzlaff
@ 2022-12-08 21:59  0%         ` Mattias Rönnblom
  0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-12-08 21:59 UTC (permalink / raw)
  To: Tyler Retzlaff; +Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb

On 2022-12-07 17:38, Tyler Retzlaff wrote:
> On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
>> On 2022-12-06 18:28, Tyler Retzlaff wrote:
>>> Add rte_control_thread_create API as a replacement for
>>> rte_ctrl_thread_create to allow deprecation of the use of platform
>>> specific types in DPDK public API.
>>>
>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>> ---
>>>   lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
>>>   lib/eal/include/rte_thread.h       | 29 ++++++++++++
>>>   lib/eal/version.map                |  3 ++
>>>   3 files changed, 117 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
>>> index c5d8b43..7950b50 100644
>>> --- a/lib/eal/common/eal_common_thread.c
>>> +++ b/lib/eal/common/eal_common_thread.c
>>> @@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
>>>   };
>>>   struct rte_thread_ctrl_params {
>>> -	void *(*start_routine)(void *);
>>> +	union {
>>> +		void *(*start_routine)(void *);
>>> +		rte_thread_func thread_func;
>>
>> To be consistent with function naming scheme, where "ctrl" is the
>> old API, and "control" the new, you could call the start functions
>> something with "ctrl" and "control" as well.
> 
> i'll make this change in v3.
> 
>>
>> Maybe it's worth mentioning that fact somewhere in the beginning of
>> the file, as a comment (i.e., that "ctrl" denotes the old API).
> 
> i'll make this change in v3.
> 
>>
>>> +	} u;
>>>   	void *arg;
>>>   	int ret;
>>
>> Why is 'ret' needed? (This question is unrelated to your patch.)
> 
> i'm not the original author so difficult to answer authoritatively. but
> if i have to speculate i'd say it might be to work around the windows
> pthread_join stub being implemented as a noop. specifically it didn't
> communicate the return value from the start_routine.
> 
> the recently added rte_thread_join addresses this (which
> rte_control_thread_create uses) and could remove ret parameter and to
> avoid touching the new function implementation in the future it can not
> use ret now.
> 
> i'll make this change in v3.
> 
> for the original function i will leave the code as is to minimize the
> diff. when rte_ctrl_thread_create is removed i'll make a note to
> eliminate the ret parameter as well.
> 

I would focus on minimizing the complexity of the end result, rather 
than the size of the patch.

>>
>>>   	/* Control thread status.
>>> @@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
>>>   	enum __rte_ctrl_thread_status ctrl_thread_status;
>>>   };
>>> -static void *ctrl_thread_init(void *arg)
>>> +static int ctrl_thread_init(void *arg)
>>>   {
>>>   	struct internal_config *internal_conf =
>>>   		eal_get_internal_configuration();
>>>   	rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
>>>   	struct rte_thread_ctrl_params *params = arg;
>>> -	void *(*start_routine)(void *) = params->start_routine;
>>> -	void *routine_arg = params->arg;
>>>   	__rte_thread_init(rte_lcore_id(), cpuset);
>>>   	params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
>>> @@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
>>>   	if (params->ret != 0) {
>>>   		__atomic_store_n(&params->ctrl_thread_status,
>>>   			CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
>>> -		return NULL;
>>> +		return params->ret;
>>>   	}
>>>   	__atomic_store_n(&params->ctrl_thread_status,
>>>   		CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
>>> -	return start_routine(routine_arg);
>>> +	return 0;
>>> +}
>>> +
>>> +static void *ctrl_thread_start(void *arg)
>>> +{
>>> +	struct rte_thread_ctrl_params *params = arg;
>>> +	void *(*start_routine)(void *) = params->u.start_routine;
>>> +
>>> +	if (ctrl_thread_init(arg) != 0)
>>> +		return NULL;
>>> +
>>> +	return start_routine(params->arg);
>>> +}
>>> +
>>> +static uint32_t control_thread_start(void *arg)
>>> +{
>>> +	struct rte_thread_ctrl_params *params = arg;
>>> +	rte_thread_func start_routine = params->u.thread_func;
>>> +
>>> +	if (ctrl_thread_init(arg) != 0)
>>> +		return params->ret;
>>> +
>>> +	return start_routine(params->arg);
>>>   }
>>>   int
>>> @@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
>>>   	if (!params)
>>>   		return -ENOMEM;
>>> -	params->start_routine = start_routine;
>>> +	params->u.start_routine = start_routine;
>>>   	params->arg = arg;
>>>   	params->ret = 0;
>>>   	params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> -	ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
>>> +	ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
>>>   	if (ret != 0) {
>>>   		free(params);
>>>   		return -ret;
>>> @@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
>>>   }
>>>   int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> +	const rte_thread_attr_t *attr,
>>> +	rte_thread_func start_routine, void *arg)
>>> +{
>>> +	struct rte_thread_ctrl_params *params;
>>> +	enum __rte_ctrl_thread_status ctrl_thread_status;
>>> +	int ret;
>>> +
>>> +	params = malloc(sizeof(*params));
>>> +	if (!params)
>>
>> params == NULL
> 
> copied from original code, i'll fix the style in the new function to
> comply with the dpdk coding standard.
> 
> i'll fix in v3.
> 
>>
>>> +		return -ENOMEM;
>>> +
>>> +	params->u.thread_func = start_routine;
>>> +	params->arg = arg;
>>> +	params->ret = 0;
>>> +	params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> +
>>> +	ret = rte_thread_create(thread, attr, control_thread_start, params);
>>> +	if (ret != 0) {
>>> +		free(params);
>>> +		return -ret;
>>> +	}
>>> +
>>> +	if (name != NULL) {
>>> +		ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
>>> +		if (ret < 0)
>>> +			RTE_LOG(DEBUG, EAL,
>>> +				"Cannot set name for ctrl thread\n");
>>> +	}
>>> +
>>> +	/* Wait for the control thread to initialize successfully */
>>> +	while ((ctrl_thread_status =
>>> +			__atomic_load_n(&params->ctrl_thread_status,
>>> +			__ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
>>> +		/* Yield the CPU. Using sched_yield call requires maintaining
>>> +		 * another implementation for Windows as sched_yield is not
>>> +		 * supported on Windows.
>>> +		 */
>>
>> sched_yield() also doesn't necessarily yield the CPU.
> 
> copied from original code and understood, but are you requesting a
> change here or just a comment correction? can you offer wording you
> would find suitable?
> 

I would just remove the comment.

"Yield the CPU. sched_yield() may seem like a natural choice here, but 
does not guarantee that a context switch will actually occur, and also 
does not exist on Windows."


>>
>>> +		rte_delay_us_sleep(1);
>>> +	}
>>> +
>>> +	/* Check if the control thread encountered an error */
>>> +	if (ctrl_thread_status == CTRL_THREAD_ERROR) {
>>> +		/* ctrl thread is exiting */
>>> +		rte_thread_join(*thread, NULL);
>>> +	}
>>> +
>>> +	ret = params->ret;
>>> +	free(params);
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +int
>>>   rte_thread_register(void)
>>>   {
>>>   	unsigned int lcore_id;
>>> diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
>>> index b9edf70..ae7afbe 100644
>>> --- a/lib/eal/include/rte_thread.h
>>> +++ b/lib/eal/include/rte_thread.h
>>> @@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
>>>   		rte_thread_func thread_func, void *arg);
>>>   /**
>>> + * Create a control thread.
>>> + *
>>> + * Creates a control thread with the given name and attributes. The
>>> + * affinity of the new thread is based on the CPU affinity retrieved
>>> + * at the time rte_eal_init() was called, the dataplane and service
>>> + * lcores are then excluded. If setting the name of the thread fails,
>>
>> "the EAL threads are then excluded"
> 
> i'll modify in v3.
> 
>>
>>> + * the error is ignored and a debug message is logged.
>>> + *
>>> + * @param thread
>>> + *   Filled with the thread id of the new created thread.
>>> + * @param name
>>> + *   The name of the control thread (max 16 characters including '\0').
>>
>> Is there a constant for this limit?
> 
> i have a series introducing rte_lcore_{set,get}_name api that introduces
> a constant (probably i'll post it today). as of this series there is no
> constant.
> 
>>
>>> + * @param thread_attr
>>> + *   Attributes for the new thread.
>>> + * @param thread_func
>>> + *   Function to be executed by the new thread.
>>> + * @param arg
>>> + *   Argument passed to start_routine.
>>> + * @return
>>> + *   On success, returns 0; on error, it returns a negative value
>>> + *   corresponding to the error number.
>>
>> List the possible error codes.
> 
> i would like to see the range of codes be part of the api & abi i've
> received resistance to the idea. for now i'll nack this comment which
> leaves it consistent with other apis documentation.
>>
>>> + */
>>> +__rte_experimental
>>> +int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> +		const rte_thread_attr_t *thread_attr,
>>> +		rte_thread_func thread_func, void *arg);
>>> +
>>> +/**
>>>    * @warning
>>>    * @b EXPERIMENTAL: this API may change without prior notice.
>>>    *
>>> diff --git a/lib/eal/version.map b/lib/eal/version.map
>>> index 7ad12a7..8f9eeb9 100644
>>> --- a/lib/eal/version.map
>>> +++ b/lib/eal/version.map
>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>>   	rte_thread_detach;
>>>   	rte_thread_equal;
>>>   	rte_thread_join;
>>> +
>>> +	# added in 23.03
>>> +	rte_control_thread_create;
>>>   };
>>>   INTERNAL {

^ permalink raw reply	[relevance 0%]

* Re: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
  2022-12-08 18:14  7%   ` [EXT] " Akhil Goyal
@ 2022-12-08 19:43  4%     ` Thomas Monjalon
  2022-12-09  4:16  4%       ` Akhil Goyal
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 19:43 UTC (permalink / raw)
  To: Ferruh Yigit, Bruce Richardson, Akhil Goyal; +Cc: David Marchand, dev

08/12/2022 19:14, Akhil Goyal:
> > By default 'test-meson-builds.sh' script clones the repository which the
> > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > as a reference for ABI check.
> > 
> > This patch enables selecting different repository to close for reference
> > using 'DPDK_ABI_REF_SRC' environment variable.
> > 
> > It is possible to put these variables to 'devel.config' config file, or
> > provide via command line, like:
> > `
> >  DPDK_ABI_REF_SRC=~/dpdk-stable/   \
> >  DPDK_ABI_REF_VERSION=v22.11.1     \
> >  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> >  ./devtools/test-meson-builds.sh
> > `
> > 
> > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > previously.
> > 
> > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > other repo as a new 'remote' to the exiting git repository.
> > 
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > ---
> 
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> 
> Worked for me, but I still needed to clone the dpdk-stable repo manually.
> I was hoping, test-meson-build.sh would do that by itself.
> Had it been a tag in same repo, it would have been straight forward as before.
> I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.

First, v22.11.1 exists already in dpdk-stable.
Second, vXX.YY.z tags are supposed to be only in dpdk-stable.

> The fix that we are talking about is a mandatory one for each one to use for ABI checks,
> dpdk-stable patches are not mandatory for the users.

You could have dpdk-stable as a remote in your main DPDK directory.
If you don't want to do that, you could refer to the commit SHA1 of the fix I think.



^ permalink raw reply	[relevance 4%]

* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
  2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
@ 2022-12-08 18:14  7%   ` Akhil Goyal
  2022-12-08 19:43  4%     ` Thomas Monjalon
  2022-12-09  8:22  8%   ` David Marchand
  1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-08 18:14 UTC (permalink / raw)
  To: Ferruh Yigit, Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev

> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
> 
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
> 
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
>  DPDK_ABI_REF_SRC=~/dpdk-stable/   \
>  DPDK_ABI_REF_VERSION=v22.11.1     \
>  DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>  ./devtools/test-meson-builds.sh
> `
> 
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
> 
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
> 
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---

Acked-by: Akhil Goyal <gakhil@marvell.com>

Worked for me, but I still needed to clone the dpdk-stable repo manually.
I was hoping, test-meson-build.sh would do that by itself.
Had it been a tag in same repo, it would have been straight forward as before.
I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.
The fix that we are talking about is a mandatory one for each one to use for ABI checks,
dpdk-stable patches are not mandatory for the users.

-Akhil




^ permalink raw reply	[relevance 7%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-08 13:22  3%                       ` Thomas Monjalon
@ 2022-12-08 16:06  0%                         ` Patrick Robb
  0 siblings, 0 replies; 200+ results
From: Patrick Robb @ 2022-12-08 16:06 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
	Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
	Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
	Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
	stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]

Thomas - thanks for the response. We will proceed with making the necessary
changes for using v22.11.1.

On Thu, Dec 8, 2022 at 8:22 AM Thomas Monjalon <thomas@monjalon.net> wrote:

> I'm sorry Patrick that it gives you more work.
> Your proposals below don't look possible because a tag is something fixed
> forever.
> We had an ABI issue in the initial tag so we cannot use the tag v22.11 as
> planned.
> I don't see how we can better plan except having more tests on release
> candidates.
>
>
> 07/12/2022 19:00, Patrick Robb:
> > Hello,
> >
> > Community Lab team members are wondering whether it is possible to bump
> > v22.11 to include at least this patch. We have an existing codebase which
> > relies on a vXX.XX scheme for producing ABI references. We parse that out
> > at different places in our code, so fixing this to handle vXX.XX.X will
> > require some changes on our end. We can do that, but it puts the timeline
> > on turning on ABI testing at the community lab back some. A v22.11 tagged
> > release with this patch would allow for us to turn on ABI testing
> > immediately. There was also a suggestion that having the "base" tag (like
> > the simple v22.11) point to the latest revision is a more standard
> version
> > naming approach and may be more intuitive than what is being used
> currently.
> >
> > If that is not possible, we will update our code to be able to refer to a
> > vXX.XX.X tag for producing the ABI reference. If we adopt this approach,
> we
> > would like to request that with future releases, a "vXX.XX.0" tag could
> > always be made available for us to produce ABI references from. That way,
> > we can prepare for turning on ABI testing knowing beforehand the tag name
> > we will be using.
> >
> > On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >
> > > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > > wrote:
> > > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > > >>> 05/12/2022 14:47, Akhil Goyal:
> > > >>>> But adding a tag on same repo is more convenient from developer
> point
> > > of view.
> > > >>>> However, it is my personal view, others may differ.
> > > >>>
> > > >>> From developer point of view, you should use
> > > devtools/test-meson-builds.sh
> > > >>> which does the "git clone" for you.
> > > >>>
> > > >>> This is what I have in ~/.config/dpdk/devel.config
> > > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > > >>>
> > > >>
> > > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > > >> variable to select which repo to clone?
> > > >> If so, I can send a patch for it.
> > > >
> > > > I was wondering too...
> > > > I would expect most maintainers have the stable repo in their config
> > > > but it would not hurt to handle the case when they don't for others.
> > > >
> > > > +1
> > >
> > > Sent following if it helps:
> > > https://patches.dpdk.org/project/dpdk/list/?series=26015
>
>
>
>
>
>

-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 6221 bytes --]

^ permalink raw reply	[relevance 0%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-07 18:00  5%                     ` Patrick Robb
@ 2022-12-08 13:22  3%                       ` Thomas Monjalon
  2022-12-08 16:06  0%                         ` Patrick Robb
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 13:22 UTC (permalink / raw)
  To: Patrick Robb
  Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
	Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
	Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
	Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
	stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

I'm sorry Patrick that it gives you more work.
Your proposals below don't look possible because a tag is something fixed forever.
We had an ABI issue in the initial tag so we cannot use the tag v22.11 as planned.
I don't see how we can better plan except having more tests on release candidates.


07/12/2022 19:00, Patrick Robb:
> Hello,
> 
> Community Lab team members are wondering whether it is possible to bump
> v22.11 to include at least this patch. We have an existing codebase which
> relies on a vXX.XX scheme for producing ABI references. We parse that out
> at different places in our code, so fixing this to handle vXX.XX.X will
> require some changes on our end. We can do that, but it puts the timeline
> on turning on ABI testing at the community lab back some. A v22.11 tagged
> release with this patch would allow for us to turn on ABI testing
> immediately. There was also a suggestion that having the "base" tag (like
> the simple v22.11) point to the latest revision is a more standard version
> naming approach and may be more intuitive than what is being used currently.
> 
> If that is not possible, we will update our code to be able to refer to a
> vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
> would like to request that with future releases, a "vXX.XX.0" tag could
> always be made available for us to produce ABI references from. That way,
> we can prepare for turning on ABI testing knowing beforehand the tag name
> we will be using.
> 
> On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> 
> > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > wrote:
> > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > >>> 05/12/2022 14:47, Akhil Goyal:
> > >>>> But adding a tag on same repo is more convenient from developer point
> > of view.
> > >>>> However, it is my personal view, others may differ.
> > >>>
> > >>> From developer point of view, you should use
> > devtools/test-meson-builds.sh
> > >>> which does the "git clone" for you.
> > >>>
> > >>> This is what I have in ~/.config/dpdk/devel.config
> > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > >>>
> > >>
> > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > >> variable to select which repo to clone?
> > >> If so, I can send a patch for it.
> > >
> > > I was wondering too...
> > > I would expect most maintainers have the stable repo in their config
> > > but it would not hurt to handle the case when they don't for others.
> > >
> > > +1
> >
> > Sent following if it helps:
> > https://patches.dpdk.org/project/dpdk/list/?series=26015






^ permalink raw reply	[relevance 3%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  @ 2022-12-07 18:00  5%                     ` Patrick Robb
  2022-12-08 13:22  3%                       ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Patrick Robb @ 2022-12-07 18:00 UTC (permalink / raw)
  To: Ferruh Yigit
  Cc: David Marchand, Thomas Monjalon, Akhil Goyal, ci,
	Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
	Xueming(Steven) Li, dev, stable, Bruce Richardson,
	Michael Santana, Abdullah Ömer Yamaç,
	Aaron Conole

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

Hello,

Community Lab team members are wondering whether it is possible to bump
v22.11 to include at least this patch. We have an existing codebase which
relies on a vXX.XX scheme for producing ABI references. We parse that out
at different places in our code, so fixing this to handle vXX.XX.X will
require some changes on our end. We can do that, but it puts the timeline
on turning on ABI testing at the community lab back some. A v22.11 tagged
release with this patch would allow for us to turn on ABI testing
immediately. There was also a suggestion that having the "base" tag (like
the simple v22.11) point to the latest revision is a more standard version
naming approach and may be more intuitive than what is being used currently.

If that is not possible, we will update our code to be able to refer to a
vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
would like to request that with future releases, a "vXX.XX.0" tag could
always be made available for us to produce ABI references from. That way,
we can prepare for turning on ABI testing knowing beforehand the tag name
we will be using.

On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:

> On 12/6/2022 10:18 AM, David Marchand wrote:
> > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> >>> 05/12/2022 14:47, Akhil Goyal:
> >>>> But adding a tag on same repo is more convenient from developer point
> of view.
> >>>> However, it is my personal view, others may differ.
> >>>
> >>> From developer point of view, you should use
> devtools/test-meson-builds.sh
> >>> which does the "git clone" for you.
> >>>
> >>> This is what I have in ~/.config/dpdk/devel.config
> >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> >>> export DPDK_ABI_REF_VERSION=v22.11.1
> >>>
> >>
> >> Does it help to update 'test-meson-builds.sh' to use an environment
> >> variable to select which repo to clone?
> >> If so, I can send a patch for it.
> >
> > I was wondering too...
> > I would expect most maintainers have the stable repo in their config
> > but it would not hurt to handle the case when they don't for others.
> >
> > +1
> >
> >
>
> Sent following if it helps:
> https://patches.dpdk.org/project/dpdk/list/?series=26015
>

-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 5075 bytes --]

^ permalink raw reply	[relevance 5%]

* Re: [PATCH v2 1/3] eal: add rte control thread create API
  @ 2022-12-07 16:38  3%       ` Tyler Retzlaff
  2022-12-08 21:59  0%         ` Mattias Rönnblom
  0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-07 16:38 UTC (permalink / raw)
  To: Mattias Rönnblom
  Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb

On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
> On 2022-12-06 18:28, Tyler Retzlaff wrote:
> >Add rte_control_thread_create API as a replacement for
> >rte_ctrl_thread_create to allow deprecation of the use of platform
> >specific types in DPDK public API.
> >
> >Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >---
> >  lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
> >  lib/eal/include/rte_thread.h       | 29 ++++++++++++
> >  lib/eal/version.map                |  3 ++
> >  3 files changed, 117 insertions(+), 8 deletions(-)
> >
> >diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
> >index c5d8b43..7950b50 100644
> >--- a/lib/eal/common/eal_common_thread.c
> >+++ b/lib/eal/common/eal_common_thread.c
> >@@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
> >  };
> >  struct rte_thread_ctrl_params {
> >-	void *(*start_routine)(void *);
> >+	union {
> >+		void *(*start_routine)(void *);
> >+		rte_thread_func thread_func;
> 
> To be consistent with function naming scheme, where "ctrl" is the
> old API, and "control" the new, you could call the start functions
> something with "ctrl" and "control" as well.

i'll make this change in v3.

> 
> Maybe it's worth mentioning that fact somewhere in the beginning of
> the file, as a comment (i.e., that "ctrl" denotes the old API).

i'll make this change in v3.

> 
> >+	} u;
> >  	void *arg;
> >  	int ret;
> 
> Why is 'ret' needed? (This question is unrelated to your patch.)

i'm not the original author so difficult to answer authoritatively. but
if i have to speculate i'd say it might be to work around the windows
pthread_join stub being implemented as a noop. specifically it didn't
communicate the return value from the start_routine.

the recently added rte_thread_join addresses this (which
rte_control_thread_create uses) and could remove ret parameter and to
avoid touching the new function implementation in the future it can not
use ret now.

i'll make this change in v3.

for the original function i will leave the code as is to minimize the
diff. when rte_ctrl_thread_create is removed i'll make a note to
eliminate the ret parameter as well.

> 
> >  	/* Control thread status.
> >@@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
> >  	enum __rte_ctrl_thread_status ctrl_thread_status;
> >  };
> >-static void *ctrl_thread_init(void *arg)
> >+static int ctrl_thread_init(void *arg)
> >  {
> >  	struct internal_config *internal_conf =
> >  		eal_get_internal_configuration();
> >  	rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> >  	struct rte_thread_ctrl_params *params = arg;
> >-	void *(*start_routine)(void *) = params->start_routine;
> >-	void *routine_arg = params->arg;
> >  	__rte_thread_init(rte_lcore_id(), cpuset);
> >  	params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
> >@@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
> >  	if (params->ret != 0) {
> >  		__atomic_store_n(&params->ctrl_thread_status,
> >  			CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
> >-		return NULL;
> >+		return params->ret;
> >  	}
> >  	__atomic_store_n(&params->ctrl_thread_status,
> >  		CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
> >-	return start_routine(routine_arg);
> >+	return 0;
> >+}
> >+
> >+static void *ctrl_thread_start(void *arg)
> >+{
> >+	struct rte_thread_ctrl_params *params = arg;
> >+	void *(*start_routine)(void *) = params->u.start_routine;
> >+
> >+	if (ctrl_thread_init(arg) != 0)
> >+		return NULL;
> >+
> >+	return start_routine(params->arg);
> >+}
> >+
> >+static uint32_t control_thread_start(void *arg)
> >+{
> >+	struct rte_thread_ctrl_params *params = arg;
> >+	rte_thread_func start_routine = params->u.thread_func;
> >+
> >+	if (ctrl_thread_init(arg) != 0)
> >+		return params->ret;
> >+
> >+	return start_routine(params->arg);
> >  }
> >  int
> >@@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
> >  	if (!params)
> >  		return -ENOMEM;
> >-	params->start_routine = start_routine;
> >+	params->u.start_routine = start_routine;
> >  	params->arg = arg;
> >  	params->ret = 0;
> >  	params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >-	ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> >+	ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
> >  	if (ret != 0) {
> >  		free(params);
> >  		return -ret;
> >@@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
> >  }
> >  int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+	const rte_thread_attr_t *attr,
> >+	rte_thread_func start_routine, void *arg)
> >+{
> >+	struct rte_thread_ctrl_params *params;
> >+	enum __rte_ctrl_thread_status ctrl_thread_status;
> >+	int ret;
> >+
> >+	params = malloc(sizeof(*params));
> >+	if (!params)
> 
> params == NULL

copied from original code, i'll fix the style in the new function to
comply with the dpdk coding standard.

i'll fix in v3.

> 
> >+		return -ENOMEM;
> >+
> >+	params->u.thread_func = start_routine;
> >+	params->arg = arg;
> >+	params->ret = 0;
> >+	params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >+
> >+	ret = rte_thread_create(thread, attr, control_thread_start, params);
> >+	if (ret != 0) {
> >+		free(params);
> >+		return -ret;
> >+	}
> >+
> >+	if (name != NULL) {
> >+		ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
> >+		if (ret < 0)
> >+			RTE_LOG(DEBUG, EAL,
> >+				"Cannot set name for ctrl thread\n");
> >+	}
> >+
> >+	/* Wait for the control thread to initialize successfully */
> >+	while ((ctrl_thread_status =
> >+			__atomic_load_n(&params->ctrl_thread_status,
> >+			__ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
> >+		/* Yield the CPU. Using sched_yield call requires maintaining
> >+		 * another implementation for Windows as sched_yield is not
> >+		 * supported on Windows.
> >+		 */
> 
> sched_yield() also doesn't necessarily yield the CPU.

copied from original code and understood, but are you requesting a
change here or just a comment correction? can you offer wording you
would find suitable?

> 
> >+		rte_delay_us_sleep(1);
> >+	}
> >+
> >+	/* Check if the control thread encountered an error */
> >+	if (ctrl_thread_status == CTRL_THREAD_ERROR) {
> >+		/* ctrl thread is exiting */
> >+		rte_thread_join(*thread, NULL);
> >+	}
> >+
> >+	ret = params->ret;
> >+	free(params);
> >+
> >+	return ret;
> >+}
> >+
> >+int
> >  rte_thread_register(void)
> >  {
> >  	unsigned int lcore_id;
> >diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> >index b9edf70..ae7afbe 100644
> >--- a/lib/eal/include/rte_thread.h
> >+++ b/lib/eal/include/rte_thread.h
> >@@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
> >  		rte_thread_func thread_func, void *arg);
> >  /**
> >+ * Create a control thread.
> >+ *
> >+ * Creates a control thread with the given name and attributes. The
> >+ * affinity of the new thread is based on the CPU affinity retrieved
> >+ * at the time rte_eal_init() was called, the dataplane and service
> >+ * lcores are then excluded. If setting the name of the thread fails,
> 
> "the EAL threads are then excluded"

i'll modify in v3.

> 
> >+ * the error is ignored and a debug message is logged.
> >+ *
> >+ * @param thread
> >+ *   Filled with the thread id of the new created thread.
> >+ * @param name
> >+ *   The name of the control thread (max 16 characters including '\0').
> 
> Is there a constant for this limit?

i have a series introducing rte_lcore_{set,get}_name api that introduces
a constant (probably i'll post it today). as of this series there is no
constant.

> 
> >+ * @param thread_attr
> >+ *   Attributes for the new thread.
> >+ * @param thread_func
> >+ *   Function to be executed by the new thread.
> >+ * @param arg
> >+ *   Argument passed to start_routine.
> >+ * @return
> >+ *   On success, returns 0; on error, it returns a negative value
> >+ *   corresponding to the error number.
> 
> List the possible error codes.

i would like to see the range of codes be part of the api & abi i've
received resistance to the idea. for now i'll nack this comment which
leaves it consistent with other apis documentation.
> 
> >+ */
> >+__rte_experimental
> >+int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+		const rte_thread_attr_t *thread_attr,
> >+		rte_thread_func thread_func, void *arg);
> >+
> >+/**
> >   * @warning
> >   * @b EXPERIMENTAL: this API may change without prior notice.
> >   *
> >diff --git a/lib/eal/version.map b/lib/eal/version.map
> >index 7ad12a7..8f9eeb9 100644
> >--- a/lib/eal/version.map
> >+++ b/lib/eal/version.map
> >@@ -440,6 +440,9 @@ EXPERIMENTAL {
> >  	rte_thread_detach;
> >  	rte_thread_equal;
> >  	rte_thread_join;
> >+
> >+	# added in 23.03
> >+	rte_control_thread_create;
> >  };
> >  INTERNAL {

^ permalink raw reply	[relevance 3%]

* [PATCH 2/2] devtools: configure source repo to use as ABI reference
  @ 2022-12-06 12:23 17% ` Ferruh Yigit
  2022-12-08 18:14  7%   ` [EXT] " Akhil Goyal
  2022-12-09  8:22  8%   ` David Marchand
    1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2022-12-06 12:23 UTC (permalink / raw)
  To: Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev

By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.

This patch enables selecting different repository to close for reference
using 'DPDK_ABI_REF_SRC' environment variable.

It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
 DPDK_ABI_REF_SRC=~/dpdk-stable/   \
 DPDK_ABI_REF_VERSION=v22.11.1     \
 DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
 ./devtools/test-meson-builds.sh
`

When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.

Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.

Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
 devtools/test-meson-builds.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index bbe90e2bde2e..8a0ed92fcf0a 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,6 +18,7 @@ srcdir=$(dirname $(readlink -f $0))/..
 #
 # - DPDK_MESON_OPTIONS
 #
+# - DPDK_ABI_REF_SRC
 # - DPDK_ABI_REF_DIR
 # - DPDK_ABI_REF_VERSION
 #
@@ -185,12 +186,13 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
 	if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
 		abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
 		if [ ! -d $abirefdir/$targetdir ]; then
+			abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
 			# clone current sources
 			if [ ! -d $abirefdir/src ]; then
 				git clone --local --no-hardlinks \
 					--single-branch \
 					-b $DPDK_ABI_REF_VERSION \
-					$srcdir $abirefdir/src
+					$abirefsrc $abirefdir/src
 			fi
 
 			rm -rf $abirefdir/build
-- 
2.25.1


^ permalink raw reply	[relevance 17%]

* 21.11.3 patches review and test
@ 2022-12-06 11:29  1% Kevin Traynor
  2022-12-13 11:48  0% ` Christian Ehrhardt
  2022-12-16  7:55  0% ` YangHang Liu
  0 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2022-12-06 11:29 UTC (permalink / raw)
  To: stable
  Cc: dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
	David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
	John McNamara, Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi,
	Pei Zhang, qian.q.xu, Raslan Darawsheh, Thomas Monjalon,
	yanghliu, yuan.peng, zhaoyan.chen

Hi all,

Here is a list of patches targeted for stable release 21.11.3.

The planned date for the final release is 19th December.

Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.

A release candidate tarball can be found at:

    https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1

These patches are located at branch 21.11 of dpdk-stable repo:
    https://dpdk.org/browse/dpdk-stable/

Thanks.

Kevin

---
Abdullah Sevincer (1):
      event/dlb2: handle enqueuing more than maximum depth

Abhimanyu Saini (1):
      common/sfc_efx/base: remove VQ index check during VQ start

Aleksandr Miloshenko (1):
      net/iavf: fix Tx done descriptors cleanup

Alex Kiselev (1):
      net/tap: fix overflow of network interface index

Alexander Chernavin (1):
      net/virtio: fix crash when configured twice

Alexander Kozyrev (3):
      net/mlx5: fix shared Rx queue config reuse
      net/mlx5: fix first segment inline length
      net/mlx5: fix indexed pool local cache crash

Ali Alnubani (1):
      examples/l2fwd-crypto: fix typo in error message

Amit Prakash Shukla (6):
      net/mvneta: fix build with GCC 12
      test/ipsec: fix build with GCC 12
      ipsec: fix build with GCC 12
      crypto/qat: fix build with GCC 12
      net/i40e: fix build with MinGW GCC 12
      net/qede/base: fix 32-bit build with GCC 12

Andrew Boyer (5):
      net/ionic: fix endianness for Rx and Tx
      net/ionic: fix endianness for RSS
      net/ionic: fix adapter name for logging
      net/ionic: fix Rx filter save
      net/ionic: fix reported error stats

Anoob Joseph (1):
      test/crypto: fix PDCP vectors

Apeksha Gupta (2):
      net/enetfec: fix restart
      net/enetfec: fix buffer leak

Arek Kusztal (1):
      common/qat: fix VF to PF answer

Ashwin Sekhar T K (1):
      mempool/cnxk: fix destroying empty pool

Ben Magistro (1):
      doc: fix dumpcap interface parameter option

Benjamin Le Berre (1):
      net/bnxt: fix error code during MTU change

Bhagyada Modali (9):
      net/axgbe: fix scattered Rx
      net/axgbe: fix mbuf lengths in scattered Rx
      net/axgbe: fix length of each segment in scattered Rx
      net/axgbe: fix checksum and RSS in scattered Rx
      net/axgbe: optimise scattered Rx
      net/axgbe: remove freeing buffer in scattered Rx
      net/axgbe: reset end of packet in scattered Rx
      net/axgbe: clear buffer on scattered Rx chaining failure
      net/axgbe: save segment data in scattered Rx

Bing Zhao (2):
      net/mlx5: fix build with recent compilers
      bus/auxiliary: prevent device from being probed again

Brian Dooley (1):
      crypto/qat: fix null hash algorithm digest size

Changpeng Liu (1):
      vhost: add non-blocking API for posting interrupt

Chaoyong He (1):
      net/nfp: fix Rx descriptor DMA address

Chengwen Feng (8):
      net/hns3: fix crash in SVE Tx
      net/hns3: fix next-to-use overflow in SVE Tx
      net/hns3: fix next-to-use overflow in simple Tx
      net/hns3: fix crash when secondary process access FW
      net/hns3: revert Tx performance optimization
      net/hns3: revert fix mailbox communication with HW
      net/hns3: fix VF mailbox message handling
      app/testpmd: remove jumbo offload

Ciara Power (1):
      test/crypto: fix wireless auth digest segment

Conor Walsh (1):
      doc: fix reference to dma application example

Dariusz Sosnowski (1):
      net/mlx5: fix hairpin split with set VLAN VID action

David Marchand (23):
      vhost: fix virtqueue use after free on NUMA reallocation
      app/testpmd: restore ixgbe bypass commands
      net/failsafe: fix interrupt handle leak
      net/bnxt: fix build with GCC 13
      trace: fix mode for new trace point
      trace: fix mode change
      trace: fix leak with regexp
      trace: fix dynamically enabling trace points
      trace: fix race in debug dump
      ci: bump versions of actions in GHA
      ci: update to new API for step outputs in GHA
      service: fix build with clang 15
      vhost: fix build with clang 15
      bus/dpaa: fix build with clang 15
      net/atlantic: fix build with clang 15
      net/dpaa2: fix build with clang 15
      app/testpmd: fix build with clang 15
      app/testpmd: fix build with clang 15 in flow code
      test/efd: fix build with clang 15
      test/member: fix build with clang 15
      test/event: fix build with clang 15
      ci: enable ABI check in GHA
      trace: fix metadata dump

Dmitry Kozlyuk (4):
      build: enable developer mode for all working trees
      eal: fix side effect in some pointer arithmetic macros
      mempool: make event callbacks process-private
      common/mlx5: fix multi-process mempool registration

Dong Zhou (1):
      net/mlx5: fix thread workspace memory leak

Dongdong Liu (2):
      doc: fix application name in procinfo guide
      doc: document device dump in procinfo guide

Erik Gabriel Carrillo (1):
      service: fix early move to inactive status

Fidaullah Noonari (1):
      malloc: fix storage size for some allocations

Frank Du (1):
      net/ice: fix interrupt handler unregister

Gagandeep Singh (5):
      net/dpaa: fix buffer freeing in slow path
      net/dpaa: use internal mempool for SG table
      net/dpaa: fix buffer freeing on SG Tx
      net/dpaa2: use internal mempool for SG table
      net/dpaa2: fix buffer freeing on SG Tx

Ganapati Kundapura (1):
      eventdev/crypto: fix multi-process

Gregory Etelson (6):
      net/mlx5: fix RSS expansion buffer size
      app/testpmd: fix MAC header in checksum forward engine
      common/mlx5: fix shared mempool subscription
      net/mlx5: fix port initialization with small LRO
      net/mlx5: fix maximum LRO message size
      doc: add LRO size limitation in mlx5 guide

Haiyue Wang (1):
      ring: fix description

Hamza Khan (1):
      examples/vm_power_manager: use safe list iterator

Hanumanth Pothula (1):
      net/cnxk: fix DF bit in vector mode

Hernan Vargas (14):
      baseband/acc100: fix memory leak
      baseband/acc100: check turbo dec/enc input
      baseband/acc100: add null checks
      baseband/acc100: fix input length for CRC24B
      baseband/acc100: fix clearing PF IR outside handler
      baseband/acc100: fix device minimum alignment
      baseband/acc100: fix close cleanup
      baseband/acc100: add LDPC encoder padding function
      baseband/acc100: check AQ availability
      baseband/acc100: fix ring availability calculation
      baseband/acc100: enforce additional check on FCW
      baseband/acc100: fix null HARQ input case
      baseband/acc100: fix ring/queue allocation
      baseband/acc100: fix double MSI intr in TB mode

Huisong Li (18):
      net/hns3: fix Rx with PTP
      net/hns3: delete unused markup
      net/hns3: fix clearing hardware MAC statistics
      net/hns3: fix RSS filter restore
      net/hns3: fix RSS flow rule restore
      net/hns3: move flow direction rule recovery
      net/hns3: fix packet type for GENEVE
      net/hns3: fix IPv4 and IPv6 RSS
      net/hns3: fix typos in IPv6 SCTP fields
      net/hns3: fix IPv4 RSS
      net/hns3: add L3 and L4 RSS types
      net/bonding: fix slave device Rx/Tx offload configuration
      net/bonding: fix dropping valid MAC packets
      net/bonding: fix mbuf fast free handling
      net/hns3: extract functions to create RSS and FDIR flow rule
      net/hns3: fix RSS rule restore
      net/hns3: fix lock protection of RSS flow rule
      net/hns3: fix restore filter function input

Huzaifa Rahman (1):
      net/memif: fix crash with different number of Rx/Tx queues

Ilya Maximets (1):
      doc: fix support table for Ethernet/VLAN flow items

Ivan Malov (3):
      common/sfc_efx/base: fix maximum Tx data count
      net/bonding: fix descriptor limit reporting
      net/bonding: fix flow flush order on close

James Hershaw (1):
      net/nfp: improve HW info header log readability

Jeremy Spewock (1):
      test/ipsec: skip if no compatible device

Jerin Jacob (2):
      eal: fix doxygen comments for UUID
      power: fix some doxygen comments

Jiawei Wang (4):
      net/mlx5: fix modify action with tunnel decapsulation
      net/mlx5: fix tunnel header with IPIP offload
      net/mlx5: fix source port checking in sample flow rule
      net/mlx5: fix mirror flow validation with ASO action

Jiawen Wu (6):
      net/txgbe: fix IPv6 flow rule
      net/txgbe: remove semaphore between SW/FW
      net/txgbe: rename some extended statistics
      net/ngbe: rename some extended statistics
      net/ngbe: remove semaphore between SW/FW
      net/ngbe: fix maximum frame size

Jie Hai (1):
      net/hns3: fix minimum Tx frame length

Jie Wang (1):
      net/i40e: fix jumbo frame Rx with X722

Jun Qiu (3):
      gro: trim tail padding bytes
      net/bonding: fix Tx hash for TCP
      hash: fix RCU configuration memory leak

Kai Ji (1):
      test/crypto: fix bitwise operator in a SNOW3G case

Kalesh AP (2):
      net/bnxt: remove unnecessary check
      net/bnxt: fix representor info freeing

Ke Zhang (2):
      net/i40e: fix VF representor release
      net/iavf: fix L3 checksum Tx offload flag

Kevin Liu (2):
      net/iavf: check illegal packet sizes
      net/ice: check illegal packet sizes

Kevin Traynor (1):
      Revert "cryptodev: fix missing SHA3 algorithm strings"

Kumara Parameshwaran (1):
      gro: check payload length after trim

Long Li (2):
      net/mlx4: fix Verbs FD leak in secondary process
      net/mlx5: fix Verbs FD leak in secondary process

Long Wu (1):
      net/nfp: fix memory leak in Rx

Luca Boccassi (1):
      drivers: fix typos found by Lintian

Mao YingMing (1):
      net/bnxt: fix null pointer dereference in LED config

Mattias Rönnblom (3):
      net: accept unaligned data in checksum routines
      event/dsw: fix flow migration
      doc: fix event timer adapter guide

Maxime Coquelin (1):
      vhost: fix build with GCC 12

Megha Ajmera (2):
      sched: fix subport profile configuration
      examples/qos_sched: fix number of subport profiles

Michael Baum (5):
      net/mlx5: fix null check in devargs parsing
      doc: fix underlines in testpmd guide
      doc: fix colons in testpmd aged flow rules
      net/mlx5: fix race condition in counter pool resizing
      net/mlx5: fix port event cleaning order

Mingjin Ye (4):
      net/ice: support VXLAN-GPE tunnel offload
      net/i40e: fix pctype configuration for X722
      net/ice: fix scalar Rx path segment
      net/ice: fix scalar Tx path segment

Mário Kuka (1):
      pcapng: fix write more packets than IOV_MAX limit

Naga Harish K S V (4):
      eventdev/eth_tx: add spinlock for adapter start/stop
      eventdev/eth_tx: fix adapter stop
      timer: fix stopping all timers
      eventdev/eth_tx: fix queue delete

Nithin Dabilpuram (3):
      examples/ipsec-secgw: use Tx checksum offload conditionally
      examples/l3fwd: fix MTU configuration with event mode
      net/cnxk: fix later skip to include mbuf private data

Olivier Matz (7):
      cryptodev: fix unduly newlines in logs
      mem: fix API doc about allocation on secondary processes
      event/sw: fix flow ID init in self test
      event/sw: fix log in self test
      net/ixgbe: fix broadcast Rx on VF after promisc removal
      net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
      net/ixgbevf: fix promiscuous and allmulti

Pablo de Lara (1):
      examples/fips_validation: fix typo in error log

Pavan Nikhilesh (3):
      event/cnxk: fix missing xstats operations
      event/cnxk: fix mbuf offset calculation
      event/cnxk: fix missing mempool cookie marking

Peng Zhang (3):
      net/nfp: compose firmware file name with new hwinfo
      buildtools: fix NUMA nodes count
      net/nfp: fix internal buffer size and MTU check

Qi Zhang (12):
      net/ice/base: fix division during E822 PTP init
      net/ice/base: fix 100M speed capability
      net/ice/base: fix DSCP PFC TLV creation
      net/ice/base: fix media type of PHY 10G SFI C2C
      net/ice/base: fix function descriptions for parser
      net/ice/base: fix endian format
      net/ice/base: fix array overflow in add switch recipe
      net/ice/base: fix bit finding range over ptype bitmap
      net/ice/base: fix add MAC rule
      net/ice/base: fix double VLAN in promiscuous mode
      net/ice/base: ignore promiscuous already exist
      net/ice/base: fix input set of GTPoGRE

Qiming Yang (1):
      app/testpmd: skip port reset in secondary process

Radu Nicolau (5):
      net/iavf: update IPsec ESN values when updating session
      net/iavf: fix IPsec flow create error check
      net/iavf: fix SPI check
      net/iavf: fix queue stop for large VF
      examples/ipsec-secgw: fix Tx checksum offload flag

Raja Zidane (1):
      net/mlx5: fix Tx check for hardware descriptor length

Rohit Raj (1):
      net/dpaa: fix jumbo packet Rx in case of VSP

Satha Rao (1):
      common/cnxk: fix schedule weight update

Satheesh Paul (3):
      common/cnxk: fix log level during MCAM allocation
      common/cnxk: fix missing flow counter reset
      common/cnxk: fix printing disabled MKEX registers

Shiqi Liu (2):
      node: check Rx element allocation
      dma/idxd: check DSA device allocation

Shun Hao (4):
      net/mlx5: fix meter profile delete after disable
      net/mlx5: fix action flag data type
      net/mlx5: fix drop action validation
      net/mlx5: fix assert when creating meter policy

Stephen Coleman (1):
      doc: fix typo depreciated instead of deprecated

Stephen Hemminger (8):
      event/sw: fix device name in dump
      eal: fix data race in multi-process support
      pdump: do not allow enable/disable in primary process
      app/dumpcap: fix crash on cleanup
      app/dumpcap: fix pathname for output file
      app/testpmd: make quit flag volatile
      ring: remove leftover comment about watermark
      doc: avoid meson deprecation in setup

Steve Yang (1):
      net/iavf: fix pattern check for flow director parser

Steven Zou (1):
      common/iavf: avoid copy in async mode

Sunyang Wu (1):
      test/crypto: fix debug messages

Taekyung Kim (1):
      vdpa/ifc: handle data path update failure

Tal Shnaiderman (1):
      net/mlx5: fix thread termination check on Windows

Thomas Monjalon (2):
      drivers: remove unused build variable
      doc: add Rx buffer split capability for mlx5

Ting Xu (1):
      net/ice/base: fix inner symmetric RSS hash in raw flow

Tomasz Jonak (1):
      net/ice: fix null function pointer call

Vanshika Shukla (1):
      net/dpaa2: fix DPDMUX error behaviour

Viacheslav Ovsiienko (3):
      net/mlx5: fix check for orphan wait descriptor
      net/mlx5: fix single not inline packet storing
      net/mlx5: fix inline length exceeding descriptor limit

Vladimir Medvedkin (2):
      test/hash: remove dead code in extendable bucket test
      test/hash: fix bulk lookup check

Volodymyr Fialko (3):
      cryptodev: fix missing SHA3 algorithm strings
      eventdev: fix name of Rx conf type in documentation
      app/eventdev: fix limits in error message

Wenwu Ma (1):
      examples/vhost: fix use after free

Wenzhuo Lu (1):
      net/iavf: fix VLAN offload

Yi Li (1):
      doc: fix maximum packet size of virtio driver

Yiding Zhou (4):
      net/iavf: fix VLAN insertion
      net/iavf: revert VLAN insertion fix
      net/ice/base: fix duplicate flow rules
      net/iavf: add thread for event callbacks

Yunjian Wang (2):
      net/bonding: fix array overflow in Rx burst
      net/bonding: fix double slave link status query

Zhichao Zeng (3):
      net/ice: fix RSS hash update
      net/iavf: fix processing VLAN TCI in SSE path
      net/iavf: fix outer checksum flags

Zhirun Yan (1):
      graph: fix node objects allocation


^ permalink raw reply	[relevance 1%]

* [PATCH] devtools: update Meson setup command
@ 2022-12-06 10:16  4% Thomas Monjalon
  0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-12-06 10:16 UTC (permalink / raw)
  To: dev; +Cc: Aaron Conole, Michael Santana, Bruce Richardson

The command "meson build" causes a deprecation warning with meson 0.64:

WARNING: Running the setup command as `meson [options]` instead of
	`meson setup [options]` is ambiguous and deprecated.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 .ci/linux-build.sh            | 2 +-
 devtools/test-meson-builds.sh | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index baec65a914..5225dc71c4 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -163,7 +163,7 @@ if [ "$ABI_CHECKS" = "true" ]; then
     if [ ! -d reference ]; then
         refsrcdir=$(readlink -f $(pwd)/../dpdk-$REF_GIT_TAG)
         git clone --single-branch -b "$REF_GIT_TAG" $REF_GIT_REPO $refsrcdir
-        meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
+        meson setup $OPTS -Dexamples= $refsrcdir $refsrcdir/build
         ninja -C $refsrcdir/build
         DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
         devtools/gen-abi.sh reference
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 3a308bc9af..7efd5576fc 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -124,8 +124,8 @@ config () # <dir> <builddir> <meson options>
 		options="$options -D$option"
 	done
 	options="$options $*"
-	echo "$MESON $options $dir $builddir" >&$verbose
-	$MESON $options $dir $builddir
+	echo "$MESON setup $options $dir $builddir" >&$verbose
+	$MESON setup $options $dir $builddir
 }
 
 compile () # <builddir>
-- 
2.38.1


^ permalink raw reply	[relevance 4%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 15:37  0%             ` Thomas Monjalon
  2022-12-05 16:26  0%               ` Akhil Goyal
@ 2022-12-06 10:12  0%               ` Ferruh Yigit
    1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-12-06 10:12 UTC (permalink / raw)
  To: Thomas Monjalon, David Marchand, Akhil Goyal
  Cc: ci, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
	Xueming(Steven) Li, dev, stable, Bruce Richardson,
	Michael Santana, Abdullah Ömer Yamaç,
	Aaron Conole

On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> 05/12/2022 14:47, Akhil Goyal:
>>> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
>>>>> Please, maintainers and CI teams, when you enable ABI checks in the
>>>>> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
>>>>> tag as a reference.
>>>>> Thanks.
>>>>
>>>> Should we also add a tag on main repo, as new development does not happen
>>>> on stable tree?
>>>
>>> You can fetch the v22.11.1 tag from the stable tree.
>> Yes, that is an obvious option.
>> But adding a tag on same repo is more convenient from developer point of view. 
>> However, it is my personal view, others may differ.
> 
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
> 
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
> 

Does it help to update 'test-meson-builds.sh' to use an environment
variable to select which repo to clone?
If so, I can send a patch for it.


^ permalink raw reply	[relevance 0%]

* Re: [PATCH 3/3] eal: deprecate pthread control thread create API
  @ 2022-12-06  0:24  3%     ` Tyler Retzlaff
  0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-06  0:24 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: dev, thomas, david.marchand, olivier.matz

On Mon, Dec 05, 2022 at 01:18:05PM -0800, Stephen Hemminger wrote:
> On Mon,  5 Dec 2022 12:24:28 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> 
> > +
> > +* eal: The function ``rte_ctrl_thread_create`` will be removed and
> > +  replaced by the new ``rte_control_thread_create``api, continuing the
> > +  effort to decouple eal from platform-specific thread implementations.
> 
> If you want to change this (which is a good idea)
> then mark the function with __rte_deprecated now, and cleanup all the examples
> and test programs please.

i would like to mark it deprecated now but it seems the policy governing
abi replacement prevent me from doing so.

```
3.3.3. New API replacing previous one
If a new API proposed functionally replaces an existing one, when the
new API becomes non-experimental then the old one is marked with
__rte_deprecated. Deprecated APIs are removed completely just after the
next LTS.
```

as i interpreted this i am not permitted to mark the old api
__rte_deprecated until the new api is no longer marked
__rte_experimental.

of course i'm happy to skip marking the new api __rte_experimental if
people find that a satisfactory solution?

let me know.

^ permalink raw reply	[relevance 3%]

* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 15:37  0%             ` Thomas Monjalon
@ 2022-12-05 16:26  0%               ` Akhil Goyal
  2022-12-06 10:12  0%               ` Ferruh Yigit
  1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-05 16:26 UTC (permalink / raw)
  To: Thomas Monjalon, David Marchand
  Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
	Xueming(Steven) Li, dev, stable, Bruce Richardson,
	Michael Santana, Abdullah Ömer Yamaç,
	Aaron Conole

> 05/12/2022 14:47, Akhil Goyal:
> > > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > > tag as a reference.
> > > > > Thanks.
> > > >
> > > > Should we also add a tag on main repo, as new development does not
> happen
> > > > on stable tree?
> > >
> > > You can fetch the v22.11.1 tag from the stable tree.
> > Yes, that is an obvious option.
> > But adding a tag on same repo is more convenient from developer point of
> view.
> > However, it is my personal view, others may differ.
> 
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
> 
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
Ok got it, thanks.

^ permalink raw reply	[relevance 0%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 13:47  0%           ` Akhil Goyal
@ 2022-12-05 15:37  0%             ` Thomas Monjalon
  2022-12-05 16:26  0%               ` Akhil Goyal
  2022-12-06 10:12  0%               ` Ferruh Yigit
  0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2022-12-05 15:37 UTC (permalink / raw)
  To: David Marchand, Akhil Goyal
  Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
	Xueming(Steven) Li, dev, stable, Bruce Richardson,
	Michael Santana, Abdullah Ömer Yamaç,
	Aaron Conole

05/12/2022 14:47, Akhil Goyal:
> > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > tag as a reference.
> > > > Thanks.
> > >
> > > Should we also add a tag on main repo, as new development does not happen
> > > on stable tree?
> > 
> > You can fetch the v22.11.1 tag from the stable tree.
> Yes, that is an obvious option.
> But adding a tag on same repo is more convenient from developer point of view. 
> However, it is my personal view, others may differ.

From developer point of view, you should use devtools/test-meson-builds.sh
which does the "git clone" for you.

This is what I have in ~/.config/dpdk/devel.config
export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
export DPDK_ABI_REF_VERSION=v22.11.1




^ permalink raw reply	[relevance 0%]

* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 12:36  0%         ` David Marchand
@ 2022-12-05 13:47  0%           ` Akhil Goyal
  2022-12-05 15:37  0%             ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 13:47 UTC (permalink / raw)
  To: David Marchand
  Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
	Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
	Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
	Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
	stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > tag as a reference.
> > > Thanks.
> >
> > Should we also add a tag on main repo, as new development does not happen
> > on stable tree?
> 
> You can fetch the v22.11.1 tag from the stable tree.
Yes, that is an obvious option.
But adding a tag on same repo is more convenient from developer point of view. 
However, it is my personal view, others may differ.

-Akhil

^ permalink raw reply	[relevance 0%]

* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 10:43  0%       ` [EXT] " Akhil Goyal
@ 2022-12-05 12:36  0%         ` David Marchand
  2022-12-05 13:47  0%           ` Akhil Goyal
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-05 12:36 UTC (permalink / raw)
  To: Akhil Goyal
  Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
	Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
	Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
	Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
	stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > Please, maintainers and CI teams, when you enable ABI checks in the
> > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > tag as a reference.
> > Thanks.
>
> Should we also add a tag on main repo, as new development does not happen
> on stable tree?

You can fetch the v22.11.1 tag from the stable tree.


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-05 10:23  3%     ` David Marchand
@ 2022-12-05 10:43  0%       ` Akhil Goyal
  2022-12-05 12:36  0%         ` David Marchand
  0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 10:43 UTC (permalink / raw)
  To: David Marchand, ci, Thomas Monjalon, Ferruh Yigit,
	Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
	Xueming(Steven) Li
  Cc: dev, stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

> On Fri, Dec 2, 2022 at 2:39 PM Aaron Conole <aconole@redhat.com> wrote:
> >
> > David Marchand <david.marchand@redhat.com> writes:
> >
> > > ld exports any global symbol by default if no version script is passed.
> > > As a consequence, the incriminated change let any public symbol leak
> > > out of the driver shared libraries.
> > >
> > > Hide again those symbols by providing a default map file which
> > > unexports any global symbol using a local: * catch-all statement.
> > >
> > > The checks are skipped for this default map file as it is intentionnally
> > > an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> > > maps")) and there is nothing else to check in this map.
> > >
> > > This change impacts the exported symbols, hence, bump the version in the
> > > ABI check to the v22.11.1 from the 22.11 LTS branch.
> > >
> > > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > > Cc: stable@dpdk.org
> > >
> > > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Aaron Conole <aconole@redhat.com>
> 
> Series applied.
> 
> Please, maintainers and CI teams, when you enable ABI checks in the
> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> tag as a reference.
> Thanks.

Should we also add a tag on main repo, as new development does not happen
on stable tree?

Regards,
Akhil

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-02 13:39  0%   ` Aaron Conole
@ 2022-12-05 10:23  3%     ` David Marchand
  2022-12-05 10:43  0%       ` [EXT] " Akhil Goyal
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-05 10:23 UTC (permalink / raw)
  To: David Marchand, ci, Thomas Monjalon, Ferruh Yigit,
	Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
	Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
	Xia, Chenbo, Akhil Goyal, Luca Boccassi, Kevin Traynor,
	Christian Ehrhardt, Xueming(Steven) Li
  Cc: dev, stable, Bruce Richardson, Michael Santana,
	Abdullah Ömer Yamaç,
	Aaron Conole

On Fri, Dec 2, 2022 at 2:39 PM Aaron Conole <aconole@redhat.com> wrote:
>
> David Marchand <david.marchand@redhat.com> writes:
>
> > ld exports any global symbol by default if no version script is passed.
> > As a consequence, the incriminated change let any public symbol leak
> > out of the driver shared libraries.
> >
> > Hide again those symbols by providing a default map file which
> > unexports any global symbol using a local: * catch-all statement.
> >
> > The checks are skipped for this default map file as it is intentionnally
> > an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> > maps")) and there is nothing else to check in this map.
> >
> > This change impacts the exported symbols, hence, bump the version in the
> > ABI check to the v22.11.1 from the 22.11 LTS branch.
> >
> > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Aaron Conole <aconole@redhat.com>

Series applied.

Please, maintainers and CI teams, when you enable ABI checks in the
main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
tag as a reference.
Thanks.


-- 
David Marchand


^ permalink raw reply	[relevance 3%]

* mbuf performance optimization
@ 2022-12-03 17:13  3% Morten Brørup
  0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-03 17:13 UTC (permalink / raw)
  To: olivier.matz, Shijith Thotton, thomas, andrew.rybchenko,
	honnappa.nagarahalli, bruce.richardson
  Cc: dev

I have been playing around with the idea to make some changes to avoid using the mbuf's 2nd cache line in many common cases, which would reduce the cache pressure significantly, and thus improve performance. I would like to discuss if it is doable. (And let's just assume that ABI breakage is an acceptable tradeoff.)

Move 'tx_offload' to the 1st cache line
---------------------------------------
Under all circumstances:

We would need to move the 'tx_offload' field to the 1st cache line. This field is set by the application's packet forwarding pipeline stage, and read by the PMD TX function. In most cases, these two stages directly follow each other.

This also means that we must make room for it by moving a 64 bit field from the 1st to the 2nd cache line. It could be the 'next' or the 'pool' field, as discussed below.

The 'next' field - make it conditional
--------------------------------------
Optimization for (1) non-segmented packets:

We could avoid touching the 'next' field by making the 'next' field depend on something in the first cache line. E.g.:
- Use the 'ol_flags' field. Add a RTE_MBUF_F_MORE_SEGS flag, to be set/cleared when setting/clearing the 'next' field.
- Use the 'nb_segs' field. Set the 'nb_segs' field to a value >1 when setting the 'next' field, and set it to 1 when clearing the 'next' field.

The 'pool' field - use it less frequently
-----------------------------------------
Optimizations for (2) single-mempool TX queues and (3) single-mempool applications:

The 'pool' field seems to be only used by when a PMD frees a burst of mbufs that it has finished transmitting. Please correct me if I am wrong here.

We could introduce a sibling to RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE, with the only requirement that the mbufs come from the same mempool. When set, only the first mbuf in a burst gets its 'pool' field read, thus avoiding reading it in the remaining mbufs in the burst.

For single-mempool applications, we could introduce a global 'mbuf_pool' variable, to be used instead of the mbuf's 'pool' field, if set.

Med venlig hilsen / Kind regards,
-Morten Brørup

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
  2022-12-02 11:09  3% ` [PATCH v4 1/2] " David Marchand
@ 2022-12-02 13:39  0%   ` Aaron Conole
  2022-12-05 10:23  3%     ` David Marchand
  0 siblings, 1 reply; 200+ results
From: Aaron Conole @ 2022-12-02 13:39 UTC (permalink / raw)
  To: David Marchand
  Cc: dev, ferruh.yigit, stable, Luca Boccassi, Bruce Richardson,
	Michael Santana, Thomas Monjalon, Abdullah Ömer Yamaç

David Marchand <david.marchand@redhat.com> writes:

> ld exports any global symbol by default if no version script is passed.
> As a consequence, the incriminated change let any public symbol leak
> out of the driver shared libraries.
>
> Hide again those symbols by providing a default map file which
> unexports any global symbol using a local: * catch-all statement.
>
> The checks are skipped for this default map file as it is intentionnally
> an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> maps")) and there is nothing else to check in this map.
>
> This change impacts the exported symbols, hence, bump the version in the
> ABI check to the v22.11.1 from the 22.11 LTS branch.
>
> Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> Cc: stable@dpdk.org
>
> Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> ---

Acked-by: Aaron Conole <aconole@redhat.com>


^ permalink raw reply	[relevance 0%]

* [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
    2022-11-29 18:23  3% ` Ferruh Yigit
@ 2022-12-02 11:09  3% ` David Marchand
  2022-12-02 13:39  0%   ` Aaron Conole
  1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-12-02 11:09 UTC (permalink / raw)
  To: dev
  Cc: ferruh.yigit, stable, Luca Boccassi, Bruce Richardson,
	Aaron Conole, Michael Santana, Thomas Monjalon,
	Abdullah Ömer Yamaç

ld exports any global symbol by default if no version script is passed.
As a consequence, the incriminated change let any public symbol leak
out of the driver shared libraries.

Hide again those symbols by providing a default map file which
unexports any global symbol using a local: * catch-all statement.

The checks are skipped for this default map file as it is intentionnally
an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
maps")) and there is nothing else to check in this map.

This change impacts the exported symbols, hence, bump the version in the
ABI check to the v22.11.1 from the 22.11 LTS branch.

Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
Cc: stable@dpdk.org

Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
---
Changes since v3:
- updated ABI reference now that 22.11.1 is released,

Changes since v2:
- separated the Windows cleanup in next patch,

Changes since v1:
- excluded drivers/version.map from maps checked by default in
  check-symbol-maps.sh,

---
 .github/workflows/build.yml   |  3 +-
 .travis.yml                   |  3 +-
 devtools/check-symbol-maps.sh |  2 +-
 drivers/meson.build           | 68 +++++++++++++++++++----------------
 drivers/version.map           |  3 ++
 5 files changed, 45 insertions(+), 34 deletions(-)
 create mode 100644 drivers/version.map

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 9527ad1f8c..6bad94098e 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -25,7 +25,8 @@ jobs:
       MINGW: ${{ matrix.config.cross == 'mingw' }}
       MINI: ${{ matrix.config.mini != '' }}
       PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
-      REF_GIT_TAG: v22.11
+      REF_GIT_REPO: https://dpdk.org/git/dpdk-stable
+      REF_GIT_TAG: v22.11.1
       RISCV64: ${{ matrix.config.cross == 'riscv64' }}
       RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
 
diff --git a/.travis.yml b/.travis.yml
index b99444620f..0936788dc7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -42,7 +42,8 @@ script: ./.ci/${TRAVIS_OS_NAME}-build.sh
 env:
   global:
     - LIBABIGAIL_VERSION=libabigail-2.1
-    - REF_GIT_TAG=v22.11
+    - REF_GIT_REPO=https://dpdk.org/git/dpdk-stable
+    - REF_GIT_TAG=v22.11.1
 
 jobs:
   include:
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 0a6062de26..8c116bfa9c 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -8,7 +8,7 @@ cd $(dirname $0)/..
 export LC_ALL=C
 
 if [ $# = 0 ] ; then
-    set -- $(find lib drivers -name '*.map')
+    set -- $(find lib drivers -name '*.map' -a ! -path drivers/version.map)
 fi
 
 ret=0
diff --git a/drivers/meson.build b/drivers/meson.build
index c4ff3ff1ba..5188302057 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -210,40 +210,46 @@ foreach subpath:subdirs
 
         lk_deps = []
         lk_args = []
-        if fs.is_file(version_map)
-            def_file = custom_target(lib_name + '_def',
-                    command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
-                    input: version_map,
-                    output: '@0@_exports.def'.format(lib_name))
-
-            mingw_map = custom_target(lib_name + '_mingw',
-                    command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
-                    input: version_map,
-                    output: '@0@_mingw.map'.format(lib_name))
-
-            lk_deps = [version_map, def_file, mingw_map]
-            if is_windows
-                if is_ms_linker
-                    lk_args = ['-Wl,/def:' + def_file.full_path()]
-                    if meson.version().version_compare('<0.54.0')
-                        lk_args += ['-Wl,/implib:drivers\\' + implib]
-                    endif
-                else
-                    lk_args = ['-Wl,--version-script=' + mingw_map.full_path()]
+        if not fs.is_file(version_map)
+            version_map = '@0@/version.map'.format(meson.current_source_dir())
+            lk_deps += [version_map]
+        else
+            lk_deps += [version_map]
+            if not is_windows and developer_mode
+                # on unix systems check the output of the
+                # check-symbols.sh script, using it as a
+                # dependency of the .so build
+                lk_deps += custom_target(lib_name + '.sym_chk',
+                        command: [check_symbols, version_map, '@INPUT@'],
+                        capture: true,
+                        input: static_lib,
+                        output: lib_name + '.sym_chk')
+            endif
+        endif
+
+        def_file = custom_target(lib_name + '_def',
+                command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
+                input: version_map,
+                output: '@0@_exports.def'.format(lib_name))
+
+        mingw_map = custom_target(lib_name + '_mingw',
+                command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
+                input: version_map,
+                output: '@0@_mingw.map'.format(lib_name))
+
+        lk_deps += [def_file, mingw_map]
+
+        if is_windows
+            if is_ms_linker
+                lk_args = ['-Wl,/def:' + def_file.full_path()]
+                if meson.version().version_compare('<0.54.0')
+                    lk_args += ['-Wl,/implib:drivers\\' + implib]
                 endif
             else
-                lk_args = ['-Wl,--version-script=' + version_map]
-                if developer_mode
-                    # on unix systems check the output of the
-                    # check-symbols.sh script, using it as a
-                    # dependency of the .so build
-                    lk_deps += custom_target(lib_name + '.sym_chk',
-                            command: [check_symbols, version_map, '@INPUT@'],
-                            capture: true,
-                            input: static_lib,
-                            output: lib_name + '.sym_chk')
-                endif
+                lk_args = ['-Wl,--version-script=' + mingw_map.full_path()]
             endif
+        else
+            lk_args = ['-Wl,--version-script=' + version_map]
         endif
 
         shared_lib = shared_library(lib_name, sources,
diff --git a/drivers/version.map b/drivers/version.map
new file mode 100644
index 0000000000..78c3585d7c
--- /dev/null
+++ b/drivers/version.map
@@ -0,0 +1,3 @@
+DPDK_23 {
+	local: *;
+};
-- 
2.38.1


^ permalink raw reply	[relevance 3%]

* DPDK 22.11.1 released
@ 2022-12-02  9:46  4% David Marchand
  0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-02  9:46 UTC (permalink / raw)
  To: announce

Hi all,

Here is a new 22.11 release:
	https://fast.dpdk.org/rel/dpdk-${stable_release}.tar.xz

The git tree is at:
	https://dpdk.org/browse/dpdk-stable/?h=22.11

This LTS release contains one fix on the drivers ABI for the 22.11
release.

This 22.11.1 release should be used instead of the 22.11.0.
It will serve as the ABI reference for the 22.11 LTS branch and
later main releases (23.03 and 23.07).


-- 
David Marchand

---
 VERSION                                |  2 +-
 devtools/check-symbol-maps.sh          |  2 +-
 doc/guides/rel_notes/release_22_11.rst |  9 +++++++++
 drivers/meson.build                    | 68 +++++++++++++++++++++++++++++++++++++-------------------------------
 drivers/version.map                    |  3 +++
 5 files changed, 51 insertions(+), 33 deletions(-)

David Marchand (2):
      drivers: fix symbol exports when map is omitted
      version: 22.11.1


^ permalink raw reply	[relevance 4%]

* RE: help with pthread_t deprecation / api changes
  2022-12-02  1:12  0% ` Tyler Retzlaff
@ 2022-12-02  8:03  0%   ` Morten Brørup
    0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-02  8:03 UTC (permalink / raw)
  To: Tyler Retzlaff, dev, thomas, david.marchand, stephen, Bruce Richardson

+Bruce, FreeBSD EAL maintainer

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 2 December 2022 02.12
> 
> On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> >
> > i'd like to continue work moving to our platform abstracted
> rte_thread
> > but ran into a hiccup. for some recent and not so recent apis it
> appears
> > they managed to slip in without ever being __experimental.
> >
> > as a function of the dpdk project api/abi policy this means we can't
> > change or remove some of these functions without following the
> > deprecation process.
> >
> > the apis that are causing me immediate difficulty are
> > rte_thread_setname and rte_ctrl_thread_create.
> 
> after looking in more detail at our current implementations of these
> functions i would like to backtrack a little and limit the scope of
> discussion to rte_thread_setname and rte_thread_getname.
> 
> as eal functions they aren't doing a good job in abstracting the
> environment for applications, meaning an application would have to wrap
> their use in platform conditional checks.

<rant>
This is one of the consequences of a bloated EAL.

How is an application supposed to run on top of an EAL that isn't fully implemented by the underlying environments?

I have complained about this before, but am not afraid to repeat it:
I wish the EAL wasn't treated as some catch-all library where it is easy to throw in new features, which really belong in separate libraries!
</rant>

> 
> current status.
> 
> rte_thread_getname
>   * freebsd, no implementation and it appears no possible support
>   * linux, implementation conditional on __GLIBC_PREREQ(2, 12)
>   * windows, can be implemented but isn't, noop success
>   * fortunately is marked __rte_experimental
>   * called in 1 place only from eal (logging)
> 
> i would propose to present a consistent abstraction the best thing to
> do
> here is just remove rte_thread_getname. providing a version that
> requires an application to do conditional dances / compilation based on
> platform gains nothing.

My initial thought was that it should be provided for symmetry reasons.
However, thinking about it, it is probably only used for debugging, trace, and similar. It is probably not used in any meaningful way by applications. So I won't oppose to removing it.

Alternatively:
If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.

> 
> rte_thread_setname
>   * freebsd, implemented, imposes no limit on name length, suppresses
> errors
>   * linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes
>     limit of 16 (including terminating NUL) on name length, may return
> an
>     error
>   * windows, can be implemented, no explicit limit on name length, may
>     return errors
>   * unfortunately not marked __rte_experimental
> 
> i would propose to provide a replacement with the name
> rte_thread_set_name with more consistent behavior across the 3
> platforms.
> 
>   * returns errors for platforms that return errors, but the caller
>     is free to ignore them.
>   * explicit limit of 16 (including terminating NUL) on name length,
>     names that are provided that exceed the limit are truncated without
>     error.

The function should not silently modify the provided data (i.e. truncate the name). I would prefer doing both: Return ERANGE (like pthread_setname_np()), but use the truncated name anyway. Then the application can choose to ignore or deal with the return code.


^ permalink raw reply	[relevance 0%]

* Re: help with pthread_t deprecation / api changes
  2022-11-30 22:54  4% help with pthread_t deprecation / api changes Tyler Retzlaff
@ 2022-12-02  1:12  0% ` Tyler Retzlaff
  2022-12-02  8:03  0%   ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-02  1:12 UTC (permalink / raw)
  To: dev, thomas, david.marchand, mb, stephen

On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote:
> hi folks,
> 
> i'd like to continue work moving to our platform abstracted rte_thread
> but ran into a hiccup. for some recent and not so recent apis it appears
> they managed to slip in without ever being __experimental. 
> 
> as a function of the dpdk project api/abi policy this means we can't
> change or remove some of these functions without following the
> deprecation process.
> 
> the apis that are causing me immediate difficulty are
> rte_thread_setname and rte_ctrl_thread_create.

after looking in more detail at our current implementations of these
functions i would like to backtrack a little and limit the scope of 
discussion to rte_thread_setname and rte_thread_getname.

as eal functions they aren't doing a good job in abstracting the
environment for applications, meaning an application would have to wrap
their use in platform conditional checks.

current status.

rte_thread_getname
  * freebsd, no implementation and it appears no possible support
  * linux, implementation conditional on __GLIBC_PREREQ(2, 12)
  * windows, can be implemented but isn't, noop success
  * fortunately is marked __rte_experimental
  * called in 1 place only from eal (logging)

i would propose to present a consistent abstraction the best thing to do
here is just remove rte_thread_getname. providing a version that
requires an application to do conditional dances / compilation based on
platform gains nothing.

rte_thread_setname
  * freebsd, implemented, imposes no limit on name length, suppresses errors
  * linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes
    limit of 16 (including terminating NUL) on name length, may return an
    error
  * windows, can be implemented, no explicit limit on name length, may
    return errors
  * unfortunately not marked __rte_experimental

i would propose to provide a replacement with the name
rte_thread_set_name with more consistent behavior across the 3 platforms.

  * returns errors for platforms that return errors, but the caller
    is free to ignore them.
  * explicit limit of 16 (including terminating NUL) on name length,
    names that are provided that exceed the limit are truncated without
    error.

your feedback would be appreciated.

thanks

> i think the least painful path forward to deprecating and removing these
> apis is probably just to introduce the replacements with new names.
> 
> 1. introduce functions with the following names marked as
>    __experimental.
> 
>    rte_control_thread_create(rte_thread_t *, ...)
>    rte_thread_set_name(rte_thread_t, ...)
>    rte_thread_get_name(rte_thread_t, ...)
> 
>    along with the new functions, new unit tests will be included.
> 
> 2. update dpdk internal implementation to use the new functions.
> 
> 3. immediately remove the following functions from the public headers
>    and issue an api deprecation notice for the functions not marked
>    experimental.
> 
>    rte_ctrl_thread_create(pthread_t *, ...)
>    rte_thread_setname(pthread_t *, ...)
> 
> 4. when the new functions have their __experimental marking removed
>    issue an abi deprecation notice for the functions from (2).
> 
> i'm open to feedback/suggestions of a better approach if anyone has one
> to offer.
> 
> thanks!

^ permalink raw reply	[relevance 0%]

* DPDK Release Status Meeting 2022-12-01
@ 2022-12-01 19:01  3% Mcnamara, John
  0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2022-12-01 19:01 UTC (permalink / raw)
  To: dev; +Cc: thomas, david.marchand

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

Release status meeting minutes 2022-12-01
=========================================

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

Participants:
* ARM [No]
* Canonical [No]
* Debian/Microsoft
* Intel
* Marvell [No]
* Nvidia
* Red Hat
* Xilinx/AMD


Release Dates
-------------

The following are the proposed current dates for 23.03:


* V1:      25 December 2022
* RC1:      8 February 2023
* RC2:      1 March    2023
* RC3:      8 March    2023
* Release: 20 March    2023


Subtrees
--------

* next-net
  * No update.

* next-net-intel
  * No update.

* next-net-mlx
  * No update.

* next-net-mvl
  * No update.

* next-eventdev
  * No update.

* next-virtio
  * No update.

* next-crypto
  * No update.

* main
  * 22.11 released.
  * We are looking for a new shared maintainer for next-net
  * There is an ABI breakage issue
    * Will be fixed in release 22.11.1 on stable.
  * Call for roadmaps for 23.03



Proposed Schedule for 2023
--------------------------

See also http://core.dpdk.org/roadmap/#dates

23.03
  * Proposal deadline (RFC/v1 patches): 25 December 2022
  * API freeze (-rc1): 8 February 2023
  * PMD features freeze (-rc2): 1 March 2023
  * Builtin applications features freeze (-rc3): 8 March 2023
  * Release: 20 March 2023

23.07
  * Proposal deadline (RFC/v1 patches): 15 April 2023
  * API freeze (-rc1): 31 May 2023
  * PMD features freeze (-rc2): 21 June 2023
  * Builtin applications features freeze (-rc3): 28 June 2023
  * Release: 12 July 2023

23.11
  * Proposal deadline (RFC/v1 patches): 12 August 2023
  * API freeze (-rc1): 29 September 2023
  * PMD features freeze (-rc2): 20 October 2023
  * Builtin applications features freeze (-rc3): 27 October 2023
  * Release: 15 November 2023


LTS
---

Next releases will be:

* 21.11.3
  * Backport patches have been sent.
  * Merging of 22.11 patches in progress.

* 20.11.7
  * Backport patches have been sent.
  * Merging of 22.11 patches in progress.

* 19.11.14
  * Backport patches have been sent.
  * Merging of 22.11 patches in progress.



* Distros
  * v20.11 in Debian 11
  * Ubuntu 22.04 contains 21.11

Defects
-------

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


DPDK Release Status Meetings
----------------------------

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

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

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

[-- Attachment #2: Type: text/html, Size: 15674 bytes --]

^ permalink raw reply	[relevance 3%]

* Re: [PATCH] version: 23.03-rc0
  2022-12-01 15:37  0% ` Thomas Monjalon
@ 2022-12-01 15:50  0%   ` David Marchand
  0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-01 15:50 UTC (permalink / raw)
  To: dev; +Cc: Thomas Monjalon

On Thu, Dec 1, 2022 at 4:37 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 28/11/2022 09:33, David Marchand:
> > Start a new release cycle with empty release notes.
> > Bump version and ABI minor.
> > libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
> > to this version and enable ABI checks.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied.
Here we go with a new release.

The proposed dates for the main milestones are:
Proposal deadline (RFC/v1 patches): 25 December 2022
API freeze (-rc1): 8 February 2023
PMD features freeze (-rc2): 1 March 2023
Builtin applications features freeze (-rc3): 8 March 2023
Release: 20 March 2023

Don't forget to send your roadmaps!


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] version: 23.03-rc0
  2022-11-28  8:33 11% [PATCH] version: 23.03-rc0 David Marchand
@ 2022-12-01 15:37  0% ` Thomas Monjalon
  2022-12-01 15:50  0%   ` David Marchand
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-01 15:37 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, ci

28/11/2022 09:33, David Marchand:
> Start a new release cycle with empty release notes.
> Bump version and ABI minor.
> libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
> to this version and enable ABI checks.
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>

Acked-by: Thomas Monjalon <thomas@monjalon.net>



^ permalink raw reply	[relevance 0%]

* help with pthread_t deprecation / api changes
@ 2022-11-30 22:54  4% Tyler Retzlaff
  2022-12-02  1:12  0% ` Tyler Retzlaff
  0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-11-30 22:54 UTC (permalink / raw)
  To: dev; +Cc: thomas

hi folks,

i'd like to continue work moving to our platform abstracted rte_thread
but ran into a hiccup. for some recent and not so recent apis it appears
they managed to slip in without ever being __experimental. 

as a function of the dpdk project api/abi policy this means we can't
change or remove some of these functions without following the
deprecation process.

the apis that are causing me immediate difficulty are
rte_thread_setname and rte_ctrl_thread_create.

i think the least painful path forward to deprecating and removing these
apis is probably just to introduce the replacements with new names.

1. introduce functions with the following names marked as
   __experimental.

   rte_control_thread_create(rte_thread_t *, ...)
   rte_thread_set_name(rte_thread_t, ...)
   rte_thread_get_name(rte_thread_t, ...)

   along with the new functions, new unit tests will be included.

2. update dpdk internal implementation to use the new functions.

3. immediately remove the following functions from the public headers
   and issue an api deprecation notice for the functions not marked
   experimental.

   rte_ctrl_thread_create(pthread_t *, ...)
   rte_thread_setname(pthread_t *, ...)

4. when the new functions have their __experimental marking removed
   issue an abi deprecation notice for the functions from (2).

i'm open to feedback/suggestions of a better approach if anyone has one
to offer.

thanks!

^ permalink raw reply	[relevance 4%]

* Re: [PATCH] drivers: fix symbol exports when map is omitted
  2022-11-30  8:27  0%     ` David Marchand
@ 2022-11-30  9:19  0%       ` Ferruh Yigit
  0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-11-30  9:19 UTC (permalink / raw)
  To: David Marchand, Thomas Monjalon
  Cc: dev, stable, Luca Boccassi, Bruce Richardson,
	Abdullah Ömer Yamaç

On 11/30/2022 8:27 AM, David Marchand wrote:
> On Wed, Nov 30, 2022 at 8:13 AM David Marchand
> <david.marchand@redhat.com> wrote:
>>> I assume this will cause warnings for ABI check scripts, how can we
>>> prevent the warnings?
>>
>> Indeed.
>>
>> Some options:
>> - add exhaustive suppression rules in devtools/libabigail.abignore,
>> - retag the v22.11 release with this fix, but we already announced it
>> and people started downloading the tarball,
>> - release a .1 version and compare ABI against it (either in the main
>> repo, or in the 22.11 stable branch, through for the ABI check in GHA,
>> it would be simpler to have the tag in the main repo..),
> 
> (let's forget about my concern on GHA, we have the REF_GIT_REPO param,
> so we can point at the dpdk-stable repo, and go with a "normal"
> release in 22.11 stable branch)
> 

OK to have v22.11.1 stable release with this fix.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] drivers: fix symbol exports when map is omitted
  2022-11-30  7:13  4%   ` David Marchand
@ 2022-11-30  8:27  0%     ` David Marchand
  2022-11-30  9:19  0%       ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-30  8:27 UTC (permalink / raw)
  To: Ferruh Yigit, Thomas Monjalon
  Cc: dev, stable, Luca Boccassi, Bruce Richardson,
	Abdullah Ömer Yamaç

On Wed, Nov 30, 2022 at 8:13 AM David Marchand
<david.marchand@redhat.com> wrote:
> > I assume this will cause warnings for ABI check scripts, how can we
> > prevent the warnings?
>
> Indeed.
>
> Some options:
> - add exhaustive suppression rules in devtools/libabigail.abignore,
> - retag the v22.11 release with this fix, but we already announced it
> and people started downloading the tarball,
> - release a .1 version and compare ABI against it (either in the main
> repo, or in the 22.11 stable branch, through for the ABI check in GHA,
> it would be simpler to have the tag in the main repo..),

(let's forget about my concern on GHA, we have the REF_GIT_REPO param,
so we can point at the dpdk-stable repo, and go with a "normal"
release in 22.11 stable branch)

>
> Do you have other ideas?
>


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] drivers: fix symbol exports when map is omitted
  2022-11-29 18:23  3% ` Ferruh Yigit
@ 2022-11-30  7:13  4%   ` David Marchand
  2022-11-30  8:27  0%     ` David Marchand
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-30  7:13 UTC (permalink / raw)
  To: Ferruh Yigit, Thomas Monjalon
  Cc: dev, stable, Luca Boccassi, Bruce Richardson,
	Abdullah Ömer Yamaç

On Tue, Nov 29, 2022 at 7:23 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 11/29/2022 2:00 PM, David Marchand wrote:
> > ld exports any global symbol by default if no version script is passed.
> > As a consequence, the incriminated change let any public symbol leak
> > out of the driver shared libraries.
> >
> > Hide again those symbols by providing a default map file which
> > unexports any global symbol using a local: * catchall statement.
> >
>
> I assume this will cause warnings for ABI check scripts, how can we
> prevent the warnings?

Indeed.

Some options:
- add exhaustive suppression rules in devtools/libabigail.abignore,
- retag the v22.11 release with this fix, but we already announced it
and people started downloading the tarball,
- release a .1 version and compare ABI against it (either in the main
repo, or in the 22.11 stable branch, through for the ABI check in GHA,
it would be simpler to have the tag in the main repo..),

Do you have other ideas?


>
> > The check on symbols is skipped for this default map file as it is
> > intentionnally an empty map (see commit b67bdda86cd4 ("devtools: catch
> > empty symbol maps")) and there is nothing to check in it.
> >
>
> How it is skipped, './devtools/check-symbol-maps.sh' still complains
> about 'drivers/version.map' for me.

I had considered the call check-symbols.sh during build.
But it is true that if you call check-symbol-maps.sh alone, we will
get a warning.

I will exclude it in v2.


>
> > While at it, move Windows specific objects where needed for better
> > readability.
> >
>
> +1
>
> > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
>
> Not tested on Windows, but for Linux:
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>

UNH Windows tests look fine.


-- 
David Marchand


^ permalink raw reply	[relevance 4%]

* Re: [PATCH] drivers: fix symbol exports when map is omitted
  @ 2022-11-29 18:23  3% ` Ferruh Yigit
  2022-11-30  7:13  4%   ` David Marchand
  2022-12-02 11:09  3% ` [PATCH v4 1/2] " David Marchand
  1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-11-29 18:23 UTC (permalink / raw)
  To: David Marchand, dev
  Cc: stable, Luca Boccassi, Bruce Richardson, Abdullah Ömer Yamaç

On 11/29/2022 2:00 PM, David Marchand wrote:
> ld exports any global symbol by default if no version script is passed.
> As a consequence, the incriminated change let any public symbol leak
> out of the driver shared libraries.
> 
> Hide again those symbols by providing a default map file which
> unexports any global symbol using a local: * catchall statement.
> 

I assume this will cause warnings for ABI check scripts, how can we
prevent the warnings?

> The check on symbols is skipped for this default map file as it is
> intentionnally an empty map (see commit b67bdda86cd4 ("devtools: catch
> empty symbol maps")) and there is nothing to check in it.
> 

How it is skipped, './devtools/check-symbol-maps.sh' still complains
about 'drivers/version.map' for me.

> While at it, move Windows specific objects where needed for better
> readability.
> 

+1

> Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> Cc: stable@dpdk.org
> 
> Reported-by: Luca Boccassi <luca.boccassi@microsoft.com> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>


Not tested on Windows, but for Linux:
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>


^ permalink raw reply	[relevance 3%]

* [PATCH] version: 23.03-rc0
@ 2022-11-28  8:33 11% David Marchand
  2022-12-01 15:37  0% ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-28  8:33 UTC (permalink / raw)
  To: dev; +Cc: thomas, ci

Start a new release cycle with empty release notes.
Bump version and ABI minor.
libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
to this version and enable ABI checks.

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
For CI guys: it is time to enable ABI checks again.

---
 .github/workflows/build.yml            |   6 +-
 .travis.yml                            |  23 ++++-
 ABI_VERSION                            |   2 +-
 VERSION                                |   2 +-
 doc/guides/rel_notes/index.rst         |   1 +
 doc/guides/rel_notes/release_23_03.rst | 138 +++++++++++++++++++++++++
 6 files changed, 165 insertions(+), 7 deletions(-)
 create mode 100644 doc/guides/rel_notes/release_23_03.rst

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 82d83f4030..9527ad1f8c 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -21,11 +21,11 @@ jobs:
       BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
       CC: ccache ${{ matrix.config.compiler }}
       DEF_LIB: ${{ matrix.config.library }}
-      LIBABIGAIL_VERSION: libabigail-1.8
+      LIBABIGAIL_VERSION: libabigail-2.1
       MINGW: ${{ matrix.config.cross == 'mingw' }}
       MINI: ${{ matrix.config.mini != '' }}
       PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
-      REF_GIT_TAG: none
+      REF_GIT_TAG: v22.11
       RISCV64: ${{ matrix.config.cross == 'riscv64' }}
       RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
 
@@ -38,7 +38,7 @@ jobs:
             mini: mini
           - os: ubuntu-20.04
             compiler: gcc
-            checks: doc+tests
+            checks: abi+doc+tests
           - os: ubuntu-20.04
             compiler: clang
             checks: asan+doc+tests
diff --git a/.travis.yml b/.travis.yml
index 4bb5bf629e..b99444620f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -41,8 +41,8 @@ script: ./.ci/${TRAVIS_OS_NAME}-build.sh
 
 env:
   global:
-    - LIBABIGAIL_VERSION=libabigail-1.8
-    - REF_GIT_TAG=none
+    - LIBABIGAIL_VERSION=libabigail-2.1
+    - REF_GIT_TAG=v22.11
 
 jobs:
   include:
@@ -61,6 +61,14 @@ jobs:
         packages:
           - *required_packages
           - *doc_packages
+  - env: DEF_LIB="shared" ABI_CHECKS=true
+    arch: amd64
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - *required_packages
+          - *libabigail_build_packages
   # x86_64 clang jobs
   - env: DEF_LIB="static"
     arch: amd64
@@ -137,6 +145,17 @@ jobs:
         packages:
           - *required_packages
           - *doc_packages
+  - env: DEF_LIB="shared" ABI_CHECKS=true
+    dist: focal
+    arch: arm64-graviton2
+    virt: vm
+    group: edge
+    compiler: gcc
+    addons:
+      apt:
+        packages:
+          - *required_packages
+          - *libabigail_build_packages
   # aarch64 clang jobs
   - env: DEF_LIB="static"
     dist: focal
diff --git a/ABI_VERSION b/ABI_VERSION
index 919c868b57..a12b18e437 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-23.0
+23.1
diff --git a/VERSION b/VERSION
index 7af24b7ddb..61240e02c2 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-22.11.0
+23.03.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index f6782b91db..57475a8158 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
     :maxdepth: 1
     :numbered:
 
+    release_23_03
     release_22_11
     release_22_07
     release_22_03
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
new file mode 100644
index 0000000000..b8c5b68d6c
--- /dev/null
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+   Copyright 2022 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 23.03
+==================
+
+.. **Read this first.**
+
+   The text in the sections below explains how to update the release notes.
+
+   Use proper spelling, capitalization and punctuation in all sections.
+
+   Variable and config names should be quoted as fixed width text:
+   ``LIKE_THIS``.
+
+   Build the docs and view the output file to ensure the changes are correct::
+
+      ninja -C build doc
+      xdg-open build/doc/guides/html/rel_notes/release_23_03.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release.
+   Sample format:
+
+   * **Add a title in the past tense with a full stop.**
+
+     Add a short 1-2 sentence description in the past tense.
+     The description should be enough to allow someone scanning
+     the release notes to understand the new feature.
+
+     If the feature adds a lot of sub-features you can use a bullet list
+     like this:
+
+     * Added feature foo to do something.
+     * Enhanced feature bar to do something else.
+
+     Refer to the previous release notes for examples.
+
+     Suggested order in release notes items:
+     * Core libs (EAL, mempool, ring, mbuf, buses)
+     * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
+       - ethdev (lib, PMDs)
+       - cryptodev (lib, PMDs)
+       - eventdev (lib, PMDs)
+       - etc
+     * Other libs
+     * Apps, Examples, Tools (if significant)
+
+     This section is a comment. Do not overwrite or remove it.
+     Also, make sure to start the actual text at the margin.
+     =======================================================
+
+
+Removed Items
+-------------
+
+.. This section should contain removed items in this release. Sample format:
+
+   * Add a short 1-2 sentence description of the removed item
+     in the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =======================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+   * sample: Add a short 1-2 sentence description of the API change
+     which was announced in the previous releases and made in this release.
+     Start with a scope label like "ethdev:".
+     Use fixed width quotes for ``function_names`` or ``struct_names``.
+     Use the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =======================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+   * sample: Add a short 1-2 sentence description of the ABI change
+     which was announced in the previous releases and made in this release.
+     Start with a scope label like "ethdev:".
+     Use fixed width quotes for ``function_names`` or ``struct_names``.
+     Use the past tense.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =======================================================
+
+* No ABI change that would break compatibility with 22.11.
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+   * **Add title in present tense with full stop.**
+
+     Add a short 1-2 sentence description of the known issue
+     in the present tense. Add information on any known workarounds.
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =======================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+   with this release.
+
+   The format is:
+
+   * <vendor> platform with <vendor> <type of devices> combinations
+
+     * List of CPU
+     * List of OS
+     * List of devices
+     * Other relevant details...
+
+   This section is a comment. Do not overwrite or remove it.
+   Also, make sure to start the actual text at the margin.
+   =======================================================
-- 
2.38.1


^ permalink raw reply	[relevance 11%]

* DPDK 22.11 released
@ 2022-11-27 22:22  4% Thomas Monjalon
  0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-11-27 22:22 UTC (permalink / raw)
  To: announce

A new major release is available:
	https://fast.dpdk.org/rel/dpdk-22.11.tar.xz

It was a comfortable release cycle:
	1387 commits from 193 authors
	1902 files changed, 137224 insertions(+), 61256 deletions(-)

The branch 22.11 should be supported for at least two years, maybe more,
making it recommended for system integration and deployment.

The new major ABI version is 23.
The next releases 23.03 and 23.07 will be ABI-compatible with 22.11.

Below are some new features:
	- LoongArch build
	- Intel uncore frequency control
	- mempool optimizations
	- new mbuf layout for IOVA-as-VA build
	- multiple mbuf pools per Rx queue
	- Rx buffer split based on protocol
	- hardware congestion management
	- hairpin memory configuration
	- proactive NIC error handling
	- Rx/Tx descriptor dump
	- flow API extensions
	- GVE (Google Virtual Ethernet)
	- IDPF (Intel Infrastructure DataPath Function)
	- UADK supporting HiSilicon crypto
	- MACsec processing offload
	- ShangMi crypto algorithms
	- baseband FFT operations
	- eventdev Tx queue start/stop
	- eventdev crypto vectorization
	- NitroSketch membership
	- DTS introduction in DPDK repository

More details in the release notes:
	https://doc.dpdk.org/guides/rel_notes/release_22_11.html

There are 74 new contributors (including authors, reviewers and testers).
Welcome to Abdullah Sevincer, Abhishek Maheshwari, Alan Liu,
Aleksandr Miloshenko, Alex Vesker, Alexander Chernavin, Allen Hubbe,
Amit Prakash Shukla, Anatolii Gerasymenko, Arkadiusz Kubalewski,
Arshdeep Kaur, Benjamin Le Berre, Bhagyada Modali, David MacDougal,
Dawid Zielinski, Dexia Li, Dukai Yuan, Erez Shitrit, Fei Qin, Frank Du,
Gal Shalom, Grzegorz Siwik, Hamdan Igbaria, Hamza Khan, Henning Schild,
Huang Wei, Huzaifa Rahman, James Hershaw, Jeremy Spewock, Jin Ling,
Joey Xing, Jun Qiu, Kaiwen Deng, Karen Sornek, Ke Xu, Kevin O'Sullivan,
Lei Cai, Lei Ji, Leszek Zygo, Long Wu, Lukasz Czapnik, Lukasz Kupczak,
Mah Yock Gen, Mandal Purna Chandra, Mao YingMing, Marcin Szycik,
Michael Savisko, Min Zhou, Mingjin Ye, Mingshan Zhang, Mário Kuka,
Piotr Gardocki, Qingmin Liu, R Mohamed Shah, Roman Storozhenko,
Sathesh Edara, Sergey Temerkhanov, Shiqi Liu, Stephen Coleman,
Steven Zou, Sunil Uttarwar, Sunyang Wu, Sylvia Grundwürmer,
Tadhg Kearney, Taekyung Kim, Taripin Samuel, Tomasz Jonak,
Tomasz Zawadzki, Tsotne Chakhvadze, Usman Tanveer, Wiktor Pilarczyk,
Yaqi Tang, Yi Li and Zhangfei Gao.

Below is the number of commits per employer (with authors count):
	456     Intel (65)
	227     Marvell (29)
	179     NVIDIA (28)
	 83     Corigine (6)
	 81     Red Hat (5)
	 60     Huawei (6)
	 58     AMD (5)
	 55     Microsoft (4)
	 53     OKTET Labs (2)
	 19     NXP (5)
	 14     Ericsson (1)
	 13     6WIND (2)
	        ...

A big thank to all courageous people who took on the non rewarding task
of reviewing other's job.
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
	 53     Akhil Goyal <gakhil@marvell.com>
	 45     Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
	 36     Morten Brørup <mb@smartsharesystems.com>
	 34     Niklas Söderlund <niklas.soderlund@corigine.com>
	 34     Bruce Richardson <bruce.richardson@intel.com>
	 33     David Marchand <david.marchand@redhat.com>
	 31     Ori Kam <orika@nvidia.com>
	 25     Maxime Coquelin <maxime.coquelin@redhat.com>
	 21     Jerin Jacob <jerinj@marvell.com>
	 20     Chengwen Feng <fengchengwen@huawei.com>

The next version will be 23.03 in March.
The new features for 23.03 can be submitted during the next 4 weeks:
	http://core.dpdk.org/roadmap#dates
Please share your roadmap.

Thanks everyone

^ permalink raw reply	[relevance 4%]

* [PATCH v1] doc: update release notes for 22.11
@ 2022-11-24 16:56  3% John McNamara
  0 siblings, 0 replies; 200+ results
From: John McNamara @ 2022-11-24 16:56 UTC (permalink / raw)
  To: dev; +Cc: thomas, John McNamara

Fix grammar, spelling and formatting of DPDK 22.11 release notes.

Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
 doc/guides/rel_notes/release_22_11.rst | 92 +++++++++++++-------------
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
index f427deab31..99e1b06d08 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -58,34 +58,34 @@ New Features
 * **Added initial LoongArch architecture support.**
 
   Added EAL implementation for LoongArch architecture.
-  The initial devices the porting was tested on included Loongson 3A5000,
+  The initial port was tested on Loongson 3A5000,
   Loongson 3C5000 and Loongson 3C5000L.
   In theory this implementation should work with any target based on
   ``LoongArch`` ISA.
 
 * **Added support for multiple mbuf pools per ethdev Rx queue.**
 
-  The capability allows application to provide many mempools
-  of different size, and PMD and/or NIC to choose a memory pool
-  based on the packet's length and/or Rx buffers availability.
+  Added a capability which allows an application to provide many mempools
+  of different size, and PMDs and/or NICs to choose a memory pool
+  based on the packet's length and/or Rx buffer availability.
 
 * **Added support for congestion management in ethdev.**
 
   Added new API functions ``rte_eth_cman_config_init()``,
-  ``rte_eth_cman_config_get()``, ``rte_eth_cman_config_set()``,
-  ``rte_eth_cman_info_get()`` to support congestion management.
+  ``rte_eth_cman_config_get()``, ``rte_eth_cman_config_set()``
+  and ``rte_eth_cman_info_get()`` to support congestion management.
 
 * **Added protocol header based buffer split.**
 
   * Added ``rte_eth_buffer_split_get_supported_hdr_ptypes()`` to get supported
     header protocols to split at.
-  * Supported protocol-based buffer split using added ``proto_hdr``
-    in structure ``rte_eth_rxseg_split``.
+  * Added support for protocol-based buffer split using new ``proto_hdr``
+    field in structure ``rte_eth_rxseg_split``.
 
 * **Added proactive error handling mode for ethdev.**
 
   Added proactive error handling mode for ethdev,
-  and three events were introduced: ``RTE_ETH_EVENT_ERR_RECOVERING``
+  and introduced three new events: ``RTE_ETH_EVENT_ERR_RECOVERING``
   to report that the port is recovering from an error,
   ``RTE_ETH_EVENT_RECOVER_SUCCESS`` and ``RTE_ETH_EVENT_RECOVER_FAILED``.
 
@@ -118,32 +118,32 @@ New Features
 
   Added connection tracking action number hint to ``rte_flow_configure``
   and ``rte_flow_info_get``.
-  PMD can prepare the connection tracking resources according to the hint.
+  The PMD can prepare the connection tracking resources according to the hint.
 
 * **Added support for queue-based async query in flow API.**
 
-  Added new function ``rte_flow_async_action_handle_query()``,
+  Added new function ``rte_flow_async_action_handle_query()``
   to query the action asynchronously.
 
 * **Extended metering and marking support in the flow API.**
 
-  * Added METER_COLOR item to match color marker set by a meter.
+  * Added ``METER_COLOR`` item to match color marker set by a meter.
   * Added ability to set color marker via modify field flow API.
-  * Added meter API to get a pointer to profile/policy by their ID.
-  * Added METER_MARK action for metering with lockless profile/policy access.
+  * Added meter API to get a pointer to the profile/policy by their ID.
+  * Added ``METER_MARK`` action for metering with lockless profile/policy access.
 
 * **Added flow offload action to route packets to kernel.**
 
-  Added new flow action which allows application to re-route packets
+  Added new flow action which allows an application to re-route packets
   directly to the kernel without software involvement.
 
 * **Updated AF_XDP driver.**
 
-  * Made compatible with libbpf v0.8.0 (when used with libxdp).
+  * Updated AF_XDP driver to make it compatible with libbpf v0.8.0 (when used with libxdp).
 
 * **Updated AMD Pensando ionic driver.**
 
-  * Updated to reflect that Pensando has been acquired by AMD.
+  * Updated ionic driver to reflect that Pensando has been acquired by AMD.
   * Enhanced data path to provide substantial performance improvements.
   * Added support for mbuf fast free.
   * Added support for advertising packet types.
@@ -151,7 +151,7 @@ New Features
   * Added Q-in-CMB feature controlled by device option ``ionic_cmb``.
   * Added optimized handlers for non-scattered Rx and Tx.
 
-* **Added GVE net PMD**
+* **Added GVE net PMD.**
 
   * Added the new ``gve`` net driver for Google Virtual Ethernet devices.
   * See the :doc:`../nics/gve` NIC guide for more details on this new driver.
@@ -172,25 +172,25 @@ New Features
 
 * **Updated Marvell cnxk driver.**
 
-  * Added support for flow action REPRESENTED_PORT.
+  * Added support for flow action ``REPRESENTED_PORT``.
   * Added support for congestion management.
 
 * **Added Microsoft mana driver.**
 
-  Disabled by default because of missing dependency.
+  The driver has been disabled by default because of a, currently, missing dependency.
 
 * **Updated Netronome nfp driver.**
 
   Added flow API support:
 
-  * Added the support of flower firmware.
+  * Added support for the flower firmware.
   * Added the flower service infrastructure.
   * Added the control message interactive channels between PMD and firmware.
-  * Added the support of representor port.
+  * Added support for a representor port.
 
 * **Updated NVIDIA mlx5 driver.**
 
-  * Added full support for queue-based async HW steering.
+  * Added full support for queue-based async hardware steering.
 
     - Support of FDB.
     - Support of control flow and isolate mode.
@@ -202,7 +202,7 @@ New Features
 
 * **Updated NXP dpaa2 driver.**
 
-  * Added support for flow action REPRESENTED_PORT.
+  * Added support for flow action ``REPRESENTED_PORT``.
 
 * **Updated Wangxun ngbe driver.**
 
@@ -216,8 +216,8 @@ New Features
 * **Added non-blocking notify API to vhost library.**
 
   Added ``rte_vhost_vring_call_nonblock`` API to notify the guest that
-  used descriptors have been added to the vring in non-blocking way.
-  User should check the return value of this API and try again if needed.
+  used descriptors have been added to the vring in n aon-blocking way.
+  The user should check the return value of this API and try again if needed.
 
 * **Added support for MACsec in rte_security.**
 
@@ -237,7 +237,7 @@ New Features
 
 * **Updated Marvell cnxk crypto driver.**
 
-  * Added AES-CCM support in lookaside protocol (IPsec) for CN9K & CN10K.
+  * Added AES-CCM support in lookaside protocol (IPsec) for CN9K and  CN10K.
   * Added AES & DES DOCSIS algorithm support in lookaside crypto for CN9K.
 
 * **Updated aesni_mb crypto driver.**
@@ -259,7 +259,7 @@ New Features
 * **Added bbdev operation for FFT processing.**
 
   Added a new operation type in bbdev for FFT processing with new functions
-  ``rte_bbdev_enqueue_fft_ops``, ``rte_bbdev_dequeue_fft_ops``,
+  ``rte_bbdev_enqueue_fft_ops`` and ``rte_bbdev_dequeue_fft_ops``,
   and related structures.
 
 * **Added Intel ACC200 bbdev driver.**
@@ -285,13 +285,13 @@ New Features
 
 * **Added event crypto adapter vectorization support.**
 
-  Added support to aggregate crypto operations processed by event crypto adapter
-  into single event containing ``rte_event_vector``
+  Added support for aggregating crypto operations processed by event crypto adapter
+  into a single event containing ``rte_event_vector``
   whose event type is ``RTE_EVENT_TYPE_CRYPTODEV_VECTOR``.
 
 * **Added NitroSketch in membership library.**
 
-  Added a new data structure called sketch into membership library,
+  Added a new data structure called sketch into the membership library,
   to profile the traffic efficiently.
   NitroSketch provides high-fidelity approximate measurements
   and appears as a promising alternative to traditional approaches
@@ -320,7 +320,7 @@ New Features
   Added support for asymmetric crypto algorithms.
   See the :doc:`../sample_app_ug/fips_validation` for more details.
 
-* **Rewritten pmdinfo script.**
+* **Rewrote pmdinfo script.**
 
   The ``dpdk-pmdinfo.py`` script was rewritten to produce valid JSON only.
   PCI-IDs parsing has been removed.
@@ -347,16 +347,16 @@ Removed Items
 * mem: Removed not implemented and deprecated ``rte_malloc_set_limit``.
 
 * ethdev: removed ``RTE_FLOW_ITEM_TYPE_PF``;
-  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
 
 * ethdev: removed ``RTE_FLOW_ITEM_TYPE_VF``;
-  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
 
 * ethdev: removed ``RTE_FLOW_ITEM_TYPE_PHY_PORT``;
-  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+  use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
 
 * ethdev: removed ``RTE_FLOW_ACTION_TYPE_PHY_PORT``;
-  use ``RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT``.
+  use ``RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT`` instead.
 
 * ethdev: removed ``OF_SET_MPLS_TTL``, ``OF_DEC_MPLS_TTL``,
   ``OF_SET_NW_TTL``, ``OF_COPY_TTL_OUT`` and ``OF_COPY_TTL_IN``
@@ -382,30 +382,30 @@ API Changes
    Also, make sure to start the actual text at the margin.
    =======================================================
 
-* eal: RTE_FUNC_PTR_OR_* macros have been marked deprecated and will be removed
+* eal: ``RTE_FUNC_PTR_OR_*`` macros have been marked deprecated and will be removed
   in the future. Applications can use ``devtools/cocci/func_or_ret.cocci``
   to update their code.
 
-* eal: Updated ``rte_eal_remote_launch`` so it returns -EPIPE in case of
+* eal: Updated ``rte_eal_remote_launch`` so it returns ``-EPIPE`` in case of
   a read or write error on the pipe, instead of calling ``rte_panic``.
 
-* eal: Updated return types for rte_{bsf,fls} inline functions
+* eal: Updated return types for ``rte_{bsf,fls}`` inline functions
   to be consistently ``uint32_t``.
 
-* mempool: Deprecated helper macro ``MEMPOOL_HEADER_SIZE()`` is removed.
+* mempool: Deprecated helper macro ``MEMPOOL_HEADER_SIZE()`` has been removed.
   The replacement macro ``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
 
 * mempool: Deprecated macro to register mempool driver
-  ``MEMPOOL_REGISTER_OPS()`` is removed. Use replacement macro
+  ``MEMPOOL_REGISTER_OPS()`` has been removed. Use replacement macro
   ``RTE_MEMPOOL_REGISTER_OPS()`` instead.
 
 * mempool: Deprecated macros ``MEMPOOL_PG_NUM_DEFAULT`` and
-  ``MEMPOOL_PG_SHIFT_MAX`` are removed. These macros are not used and
+  ``MEMPOOL_PG_SHIFT_MAX`` have been removed. These macros are not used and
   not required any more.
 
 * mbuf: Removed deprecated ``PKT_*`` flags.
   Use corresponding flags with ``RTE_MBUF_F_`` prefix instead.
-  Application can use ``devtools/cocci/prefix_mbuf_offload_flags.cocci``
+  Applications can use ``devtools/cocci/prefix_mbuf_offload_flags.cocci``
   to replace all occurrences of old mbuf flags in C code.
 
 * bus: Changed the device numa node to -1 when NUMA information is unavailable.
@@ -502,7 +502,7 @@ API Changes
   from experimental to stable.
 
 * ethdev: Banned the use of attributes ``ingress``/``egress`` in "transfer"
-  flows, as the final step of deprecation process that had been started
+  flows, as the final step of the deprecation process that had been started
   in DPDK 21.11. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
 
 * vhost: Promoted ``rte_vhost_vring_stats_get()``,
@@ -523,7 +523,7 @@ API Changes
   The API ``rte_security_session_create`` was updated to take only one mempool
   which has enough space to hold session and driver private data.
 
-* security: MACsec support is added which resulted in updates
+* security: MACsec support has been added which resulted in updates
   to structures ``rte_security_macsec_xform``, ``rte_security_macsec_stats``
   and security capability structure ``rte_security_capability``
   to accommodate MACsec capabilities.
@@ -605,7 +605,7 @@ ABI Changes
   to ``rte_event_queue_conf`` structure.
 
 * eventdev: The field ``*u64s`` in the structure ``rte_event_vector`` is replaced
-  with ``u64s`` as the field is supposed to hold array of uint64_t values.
+  with ``u64s`` as the field is supposed to hold an array of ``uint64_t`` values.
 
 * eventdev: The structure ``rte_event_vector`` was updated to include a new bit
   field ``elem_offset:12``. The bits are taken from the bitfield ``rsvd:15``.
-- 
2.31.1


^ permalink raw reply	[relevance 3%]

* RE: Regarding User Data in DPDK ACL Library.
  2022-11-22 13:38  0%           ` Konstantin Ananyev
@ 2022-11-22 15:53  0%             ` Honnappa Nagarahalli
  0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2022-11-22 15:53 UTC (permalink / raw)
  To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd

<snip>
> > >
> > > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > > > <venki.bsv@gmail.com> wrote:
> > > > > >
> > > > > > > Hi DPDK Team,
> > > > > > >
> > > > > > > After the ACL match for highest priority DPDK Classification
> > > > > > > API returns User Data Which is as mentioned below in the document.
> > > > > > >
> > > > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > > > Development Kit
> > > > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > > > >
> > > > > > >
> > > > > > >    - *userdata*: A user-defined value. For each category, a successful
> > > > > > >    match returns the userdata field of the highest priority
> > > > > > > matched
> > > rule.
> > > > > When
> > > > > > >    no rules match, returned value is zero
> > > > > > >
> > > > > > > I Wonder Why User Data Support does not returns 64 bit
> > > > > > > values,
> > > > >
> > > > > As I remember if first version of ACL code it was something
> > > > > about space savings to improve performance...
> > > > > Now I think it is more just a historical reason.
> > > > > It would be good to change userdata to 64bit, but I presume it
> > > > > will be ABI breakage.
> > > > Agree. We should support 64b and even 128b (since architectures
> > > > support 128b atomic operations). This reduces required memory
> > > > barriers
> > > required if the data size <= the size of atomic operations.
> > >
> > > Hmm...  sorry, didn’t get you  here.
> > > I do understand the user intention to save pointer to arbitrary
> > > memory location as user-data (64-bit).
> > > But how does the size of atomic mem-ops relate?
> > > Konstantin
> > What I meant is, if your data fits within 64b or 128b, having another
> indirection requires:
> >
> > 1) one additional memory operation to store the data (the first one
> > being the store to the index)
> > 2) on the control plane, we would need a release barrier between
> > 'store data' and 'store index' (not a significant issue). On the data plane, we
> could use relaxed ordering between 'load index' and 'load data', so we do not
> need a barrier here.
> >
> > So, looks like there is no barrier over-head on the data plane, but overhead of
> one additional memory operation.
> 
> ACL doesn't provide ability to dynamically update the rules or associated user-
> data.
> Whole ACL table has to be rebuild.
Ok, then the ordering does not matter, all the loads on the data plane should be relaxed and not atomic (searching through the code does not show any).

> Konstantin
> 
> 


^ permalink raw reply	[relevance 0%]

* RE: Regarding User Data in DPDK ACL Library.
  2022-11-21 16:56  0%         ` Honnappa Nagarahalli
@ 2022-11-22 13:38  0%           ` Konstantin Ananyev
  2022-11-22 15:53  0%             ` Honnappa Nagarahalli
  0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-22 13:38 UTC (permalink / raw)
  To: Honnappa Nagarahalli, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd



> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Monday, November 21, 2022 4:57 PM
> To: Konstantin Ananyev <konstantin.ananyev@huawei.com>; Stephen Hemminger <stephen@networkplumber.org>; venkatesh bs
> <venki.bsv@gmail.com>
> Cc: users@dpdk.org; dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: RE: Regarding User Data in DPDK ACL Library.
> 
> <snip>
> >
> > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > > <venki.bsv@gmail.com> wrote:
> > > > >
> > > > > > Hi DPDK Team,
> > > > > >
> > > > > > After the ACL match for highest priority DPDK Classification API
> > > > > > returns User Data Which is as mentioned below in the document.
> > > > > >
> > > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > > Development Kit
> > > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > > >
> > > > > >
> > > > > >    - *userdata*: A user-defined value. For each category, a successful
> > > > > >    match returns the userdata field of the highest priority matched
> > rule.
> > > > When
> > > > > >    no rules match, returned value is zero
> > > > > >
> > > > > > I Wonder Why User Data Support does not returns 64 bit values,
> > > >
> > > > As I remember if first version of ACL code it was something about
> > > > space savings to improve performance...
> > > > Now I think it is more just a historical reason.
> > > > It would be good to change userdata to 64bit, but I presume it will
> > > > be ABI breakage.
> > > Agree. We should support 64b and even 128b (since architectures
> > > support 128b atomic operations). This reduces required memory barriers
> > required if the data size <= the size of atomic operations.
> >
> > Hmm...  sorry, didn’t get you  here.
> > I do understand the user intention to save pointer to arbitrary memory
> > location as user-data (64-bit).
> > But how does the size of atomic mem-ops relate?
> > Konstantin
> What I meant is, if your data fits within 64b or 128b, having another indirection requires:
> 
> 1) one additional memory operation to store the data (the first one being the store to the index)
> 2) on the control plane, we would need a release barrier between 'store data' and 'store index' (not a significant issue). On the data
> plane, we could use relaxed ordering between 'load index' and 'load data', so we do not need a barrier here.
> 
> So, looks like there is no barrier over-head on the data plane, but overhead of one additional memory operation.

ACL doesn't provide ability to dynamically update the rules or associated user-data.
Whole ACL table has to be rebuild.
Konstantin 




^ permalink raw reply	[relevance 0%]

* [PATCH] net/nfp: update descriptors logic
@ 2022-11-22 13:09  3% Niklas Söderlund
  0 siblings, 0 replies; 200+ results
From: Niklas Söderlund @ 2022-11-22 13:09 UTC (permalink / raw)
  To: dev; +Cc: oss-drivers, Jin Liu, Chaoyong He, Niklas Söderlund

From: Jin Liu <jin.liu@corigine.com>

The minimum value of TX/RX descriptors for NFP3800 card is not same
with NFP4000 card, the minimum value of NFP4000 card is 256 while
NFP3800 card is 512, add the minimum descriptor macro for NFP3800
card.

Modify the logic of get descriptor value, assign the value of descriptor
for the corresponding network card according to its type.

In TX stage, firmware with NFD3 use one descriptor per packet while
firmware with NFDk use two descriptors. In order to be consistent
with the kernel driver, the number of descriptor of firmware with
NFDk should be divided by 2.

Signed-off-by: Jin Liu <jin.liu@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
 drivers/net/nfp/nfp_common.c | 86 ++++++++++++++++++++++++++++++++++--
 drivers/net/nfp/nfp_common.h |  6 +++
 drivers/net/nfp/nfp_rxtx.c   | 51 ++++++++++++++-------
 drivers/net/nfp/nfp_rxtx.h   |  3 ++
 4 files changed, 127 insertions(+), 19 deletions(-)

diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index 71711bfa228e..4defd6d93871 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -697,13 +697,91 @@ nfp_net_stats_reset(struct rte_eth_dev *dev)
 	return 0;
 }
 
+int
+nfp_net_rx_desc_limits(struct nfp_net_hw *hw,
+		uint16_t *min_rx_desc,
+		uint16_t *max_rx_desc)
+{
+	*max_rx_desc = NFP_NET_MAX_RX_DESC;
+
+	switch (hw->device_id) {
+	case PCI_DEVICE_ID_NFP3800_PF_NIC:
+	case PCI_DEVICE_ID_NFP3800_VF_NIC:
+		*min_rx_desc = NFP3800_NET_MIN_RX_DESC;
+		return 0;
+	case PCI_DEVICE_ID_NFP4000_PF_NIC:
+	case PCI_DEVICE_ID_NFP6000_PF_NIC:
+	case PCI_DEVICE_ID_NFP6000_VF_NIC:
+		*min_rx_desc = NFP_NET_MIN_RX_DESC;
+		return 0;
+	default:
+		PMD_DRV_LOG(ERR, "Unknown NFP device id.");
+		return -EINVAL;
+	}
+}
+
+int
+nfp_net_tx_desc_limits(struct nfp_net_hw *hw,
+		uint16_t *min_tx_desc,
+		uint16_t *max_tx_desc)
+{
+	uint16_t tx_dpp;
+
+	switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+	case NFP_NET_CFG_VERSION_DP_NFD3:
+		tx_dpp = NFD3_TX_DESC_PER_SIMPLE_PKT;
+		break;
+	case NFP_NET_CFG_VERSION_DP_NFDK:
+		if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+			PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+				NFD_CFG_MAJOR_VERSION_of(hw->ver));
+			return -EINVAL;
+		}
+		tx_dpp = NFDK_TX_DESC_PER_SIMPLE_PKT;
+		break;
+	default:
+		PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+		return -EINVAL;
+	}
+
+	*max_tx_desc = NFP_NET_MAX_TX_DESC / tx_dpp;
+
+	switch (hw->device_id) {
+	case PCI_DEVICE_ID_NFP3800_PF_NIC:
+	case PCI_DEVICE_ID_NFP3800_VF_NIC:
+		*min_tx_desc = NFP3800_NET_MIN_TX_DESC / tx_dpp;
+		return 0;
+	case PCI_DEVICE_ID_NFP4000_PF_NIC:
+	case PCI_DEVICE_ID_NFP6000_PF_NIC:
+	case PCI_DEVICE_ID_NFP6000_VF_NIC:
+		*min_tx_desc = NFP_NET_MIN_TX_DESC / tx_dpp;
+		return 0;
+	default:
+		PMD_DRV_LOG(ERR, "Unknown NFP device id.");
+		return -EINVAL;
+	}
+}
+
 int
 nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
+	int ret;
+	uint16_t min_rx_desc;
+	uint16_t max_rx_desc;
+	uint16_t min_tx_desc;
+	uint16_t max_tx_desc;
 	struct nfp_net_hw *hw;
 
 	hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 
+	ret = nfp_net_rx_desc_limits(hw, &min_rx_desc, &max_rx_desc);
+	if (ret != 0)
+		return ret;
+
+	ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+	if (ret != 0)
+		return ret;
+
 	dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
 	dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
 	dev_info->min_rx_bufsize = RTE_ETHER_MIN_MTU;
@@ -764,14 +842,14 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 	};
 
 	dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
-		.nb_max = NFP_NET_MAX_RX_DESC,
-		.nb_min = NFP_NET_MIN_RX_DESC,
+		.nb_max = max_rx_desc,
+		.nb_min = min_rx_desc,
 		.nb_align = NFP_ALIGN_RING_DESC,
 	};
 
 	dev_info->tx_desc_lim = (struct rte_eth_desc_lim) {
-		.nb_max = NFP_NET_MAX_TX_DESC,
-		.nb_min = NFP_NET_MIN_TX_DESC,
+		.nb_max = max_tx_desc,
+		.nb_min = min_tx_desc,
 		.nb_align = NFP_ALIGN_RING_DESC,
 		.nb_seg_max = NFP_TX_MAX_SEG,
 		.nb_mtu_seg_max = NFP_TX_MAX_MTU_SEG,
diff --git a/drivers/net/nfp/nfp_common.h b/drivers/net/nfp/nfp_common.h
index 36c19b47e4d5..a871e437e4d2 100644
--- a/drivers/net/nfp/nfp_common.h
+++ b/drivers/net/nfp/nfp_common.h
@@ -447,6 +447,12 @@ void nfp_net_close_rx_queue(struct rte_eth_dev *dev);
 void nfp_net_stop_tx_queue(struct rte_eth_dev *dev);
 void nfp_net_close_tx_queue(struct rte_eth_dev *dev);
 int nfp_net_set_vxlan_port(struct nfp_net_hw *hw, size_t idx, uint16_t port);
+int nfp_net_rx_desc_limits(struct nfp_net_hw *hw,
+		uint16_t *min_rx_desc,
+		uint16_t *max_rx_desc);
+int nfp_net_tx_desc_limits(struct nfp_net_hw *hw,
+		uint16_t *min_tx_desc,
+		uint16_t *max_tx_desc);
 
 #define NFP_NET_DEV_PRIVATE_TO_HW(adapter)\
 	(&((struct nfp_net_adapter *)adapter)->hw)
diff --git a/drivers/net/nfp/nfp_rxtx.c b/drivers/net/nfp/nfp_rxtx.c
index 01cffdfde0b4..0de7312e217d 100644
--- a/drivers/net/nfp/nfp_rxtx.c
+++ b/drivers/net/nfp/nfp_rxtx.c
@@ -439,6 +439,9 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
 		       const struct rte_eth_rxconf *rx_conf,
 		       struct rte_mempool *mp)
 {
+	int ret;
+	uint16_t min_rx_desc;
+	uint16_t max_rx_desc;
 	const struct rte_memzone *tz;
 	struct nfp_net_rxq *rxq;
 	struct nfp_net_hw *hw;
@@ -448,11 +451,14 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
 
 	PMD_INIT_FUNC_TRACE();
 
+	ret = nfp_net_rx_desc_limits(hw, &min_rx_desc, &max_rx_desc);
+	if (ret != 0)
+		return ret;
+
 	/* Validating number of descriptors */
 	rx_desc_sz = nb_desc * sizeof(struct nfp_net_rx_desc);
 	if (rx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
-	    nb_desc > NFP_NET_MAX_RX_DESC ||
-	    nb_desc < NFP_NET_MIN_RX_DESC) {
+	    nb_desc > max_rx_desc || nb_desc < min_rx_desc) {
 		PMD_DRV_LOG(ERR, "Wrong nb_desc value");
 		return -EINVAL;
 	}
@@ -502,7 +508,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
 	 */
 	tz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
 				   sizeof(struct nfp_net_rx_desc) *
-				   NFP_NET_MAX_RX_DESC, NFP_MEMZONE_ALIGN,
+				   max_rx_desc, NFP_MEMZONE_ALIGN,
 				   socket_id);
 
 	if (tz == NULL) {
@@ -628,6 +634,9 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 		       uint16_t nb_desc, unsigned int socket_id,
 		       const struct rte_eth_txconf *tx_conf)
 {
+	int ret;
+	uint16_t min_tx_desc;
+	uint16_t max_tx_desc;
 	const struct rte_memzone *tz;
 	struct nfp_net_txq *txq;
 	uint16_t tx_free_thresh;
@@ -638,11 +647,14 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 
 	PMD_INIT_FUNC_TRACE();
 
+	ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+	if (ret != 0)
+		return ret;
+
 	/* Validating number of descriptors */
 	tx_desc_sz = nb_desc * sizeof(struct nfp_net_nfd3_tx_desc);
-	if (tx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
-	    nb_desc > NFP_NET_MAX_TX_DESC ||
-	    nb_desc < NFP_NET_MIN_TX_DESC) {
+	if ((NFD3_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC != 0 ||
+	     nb_desc > max_tx_desc || nb_desc < min_tx_desc) {
 		PMD_DRV_LOG(ERR, "Wrong nb_desc value");
 		return -EINVAL;
 	}
@@ -688,7 +700,8 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 	 */
 	tz = rte_eth_dma_zone_reserve(dev, "tx_ring", queue_idx,
 				   sizeof(struct nfp_net_nfd3_tx_desc) *
-				   NFP_NET_MAX_TX_DESC, NFP_MEMZONE_ALIGN,
+				   NFD3_TX_DESC_PER_SIMPLE_PKT *
+				   max_tx_desc, NFP_MEMZONE_ALIGN,
 				   socket_id);
 	if (tz == NULL) {
 		PMD_DRV_LOG(ERR, "Error allocating tx dma");
@@ -697,7 +710,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 		return -ENOMEM;
 	}
 
-	txq->tx_count = nb_desc;
+	txq->tx_count = nb_desc * NFD3_TX_DESC_PER_SIMPLE_PKT;
 	txq->tx_free_thresh = tx_free_thresh;
 	txq->tx_pthresh = tx_conf->tx_thresh.pthresh;
 	txq->tx_hthresh = tx_conf->tx_thresh.hthresh;
@@ -716,7 +729,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 
 	/* mbuf pointers array for referencing mbufs linked to TX descriptors */
 	txq->txbufs = rte_zmalloc_socket("txq->txbufs",
-					 sizeof(*txq->txbufs) * nb_desc,
+					 sizeof(*txq->txbufs) * txq->tx_count,
 					 RTE_CACHE_LINE_SIZE, socket_id);
 	if (txq->txbufs == NULL) {
 		nfp_net_tx_queue_release(dev, queue_idx);
@@ -735,7 +748,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
 	 * of descriptors in log2 format
 	 */
 	nn_cfg_writeq(hw, NFP_NET_CFG_TXR_ADDR(queue_idx), txq->dma);
-	nn_cfg_writeb(hw, NFP_NET_CFG_TXR_SZ(queue_idx), rte_log2_u32(nb_desc));
+	nn_cfg_writeb(hw, NFP_NET_CFG_TXR_SZ(queue_idx), rte_log2_u32(txq->tx_count));
 
 	return 0;
 }
@@ -760,7 +773,8 @@ nfp_net_nfd3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pk
 	PMD_TX_LOG(DEBUG, "working for queue %u at pos %d and %u packets",
 		   txq->qidx, txq->wr_p, nb_pkts);
 
-	if ((nfp_net_nfd3_free_tx_desc(txq) < nb_pkts) || (nfp_net_nfd3_txq_full(txq)))
+	if (nfp_net_nfd3_free_tx_desc(txq) < NFD3_TX_DESC_PER_SIMPLE_PKT * nb_pkts ||
+	    nfp_net_nfd3_txq_full(txq))
 		nfp_net_tx_free_bufs(txq);
 
 	free_descs = (uint16_t)nfp_net_nfd3_free_tx_desc(txq);
@@ -879,6 +893,9 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
 		unsigned int socket_id,
 		const struct rte_eth_txconf *tx_conf)
 {
+	int ret;
+	uint16_t min_tx_desc;
+	uint16_t max_tx_desc;
 	const struct rte_memzone *tz;
 	struct nfp_net_txq *txq;
 	uint16_t tx_free_thresh;
@@ -889,11 +906,15 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
 
 	PMD_INIT_FUNC_TRACE();
 
+	ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+	if (ret != 0)
+		return ret;
+
 	/* Validating number of descriptors */
 	tx_desc_sz = nb_desc * sizeof(struct nfp_net_nfdk_tx_desc);
-	if (((NFDK_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC) != 0 ||
-	    ((NFDK_TX_DESC_PER_SIMPLE_PKT * nb_desc) % NFDK_TX_DESC_BLOCK_CNT) != 0 ||
-	      nb_desc > NFP_NET_MAX_TX_DESC || nb_desc < NFP_NET_MIN_TX_DESC) {
+	if ((NFDK_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC != 0 ||
+	    (NFDK_TX_DESC_PER_SIMPLE_PKT * nb_desc) % NFDK_TX_DESC_BLOCK_CNT != 0 ||
+	     nb_desc > max_tx_desc || nb_desc < min_tx_desc) {
 		PMD_DRV_LOG(ERR, "Wrong nb_desc value");
 		return -EINVAL;
 	}
@@ -938,7 +959,7 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
 	tz = rte_eth_dma_zone_reserve(dev, "tx_ring", queue_idx,
 				sizeof(struct nfp_net_nfdk_tx_desc) *
 				NFDK_TX_DESC_PER_SIMPLE_PKT *
-				NFP_NET_MAX_TX_DESC, NFP_MEMZONE_ALIGN,
+				max_tx_desc, NFP_MEMZONE_ALIGN,
 				socket_id);
 	if (tz == NULL) {
 		PMD_DRV_LOG(ERR, "Error allocating tx dma");
diff --git a/drivers/net/nfp/nfp_rxtx.h b/drivers/net/nfp/nfp_rxtx.h
index ced05fde908d..4f0de5e93227 100644
--- a/drivers/net/nfp/nfp_rxtx.h
+++ b/drivers/net/nfp/nfp_rxtx.h
@@ -31,9 +31,11 @@
  */
 #define NFP_NET_MAX_TX_DESC (32 * 1024)
 #define NFP_NET_MIN_TX_DESC 256
+#define NFP3800_NET_MIN_TX_DESC 512
 
 #define NFP_NET_MAX_RX_DESC (32 * 1024)
 #define NFP_NET_MIN_RX_DESC 256
+#define NFP3800_NET_MIN_RX_DESC 512
 
 /* Descriptor alignment */
 #define NFP_ALIGN_RING_DESC 128
@@ -57,6 +59,7 @@
 #define NFDK_DESC_TX_DMA_LEN_HEAD       0x0fff
 #define NFDK_DESC_TX_TYPE_HEAD          0xf000
 #define NFDK_DESC_TX_DMA_LEN            0x3fff
+#define NFD3_TX_DESC_PER_SIMPLE_PKT     1
 #define NFDK_TX_DESC_PER_SIMPLE_PKT     2
 #define NFDK_DESC_TX_TYPE_TSO           2
 #define NFDK_DESC_TX_TYPE_SIMPLE        8
-- 
2.38.1


^ permalink raw reply	[relevance 3%]

* RE: Regarding User Data in DPDK ACL Library.
  2022-11-21 14:15  0%       ` Konstantin Ananyev
@ 2022-11-21 16:56  0%         ` Honnappa Nagarahalli
  2022-11-22 13:38  0%           ` Konstantin Ananyev
  0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-21 16:56 UTC (permalink / raw)
  To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd

<snip>
> 
> > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > <venki.bsv@gmail.com> wrote:
> > > >
> > > > > Hi DPDK Team,
> > > > >
> > > > > After the ACL match for highest priority DPDK Classification API
> > > > > returns User Data Which is as mentioned below in the document.
> > > > >
> > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > Development Kit
> > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > >
> > > > >
> > > > >    - *userdata*: A user-defined value. For each category, a successful
> > > > >    match returns the userdata field of the highest priority matched
> rule.
> > > When
> > > > >    no rules match, returned value is zero
> > > > >
> > > > > I Wonder Why User Data Support does not returns 64 bit values,
> > >
> > > As I remember if first version of ACL code it was something about
> > > space savings to improve performance...
> > > Now I think it is more just a historical reason.
> > > It would be good to change userdata to 64bit, but I presume it will
> > > be ABI breakage.
> > Agree. We should support 64b and even 128b (since architectures
> > support 128b atomic operations). This reduces required memory barriers
> required if the data size <= the size of atomic operations.
> 
> Hmm...  sorry, didn’t get you  here.
> I do understand the user intention to save pointer to arbitrary memory
> location as user-data (64-bit).
> But how does the size of atomic mem-ops relate?
> Konstantin
What I meant is, if your data fits within 64b or 128b, having another indirection requires:

1) one additional memory operation to store the data (the first one being the store to the index)
2) on the control plane, we would need a release barrier between 'store data' and 'store index' (not a significant issue). On the data plane, we could use relaxed ordering between 'load index' and 'load data', so we do not need a barrier here.

So, looks like there is no barrier over-head on the data plane, but overhead of one additional memory operation.

^ permalink raw reply	[relevance 0%]

* RE: Regarding User Data in DPDK ACL Library.
  2022-11-21  5:40  0%     ` Honnappa Nagarahalli
@ 2022-11-21 14:15  0%       ` Konstantin Ananyev
  2022-11-21 16:56  0%         ` Honnappa Nagarahalli
  0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-21 14:15 UTC (permalink / raw)
  To: Honnappa Nagarahalli, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd



> > > On Thu, 17 Nov 2022 19:28:12 +0530
> > > venkatesh bs <venki.bsv@gmail.com> wrote:
> > >
> > > > Hi DPDK Team,
> > > >
> > > > After the ACL match for highest priority DPDK Classification API
> > > > returns User Data Which is as mentioned below in the document.
> > > >
> > > > 53. Packet Classification and Access Control — Data Plane
> > > > Development Kit
> > > > 22.11.0-rc2 documentation (dpdk.org)
> > > >
> > > >
> > > >    - *userdata*: A user-defined value. For each category, a successful
> > > >    match returns the userdata field of the highest priority matched rule.
> > When
> > > >    no rules match, returned value is zero
> > > >
> > > > I Wonder Why User Data Support does not returns 64 bit values,
> >
> > As I remember if first version of ACL code it was something about space
> > savings to improve performance...
> > Now I think it is more just a historical reason.
> > It would be good to change userdata to 64bit, but I presume it will be ABI
> > breakage.
> Agree. We should support 64b and even 128b (since architectures support 128b atomic operations). This reduces required memory
> barriers required if the data size <= the size of atomic operations.

Hmm...  sorry, didn’t get you  here.
I do understand the user intention to save pointer to arbitrary memory location as user-data (64-bit).
But how does the size of atomic mem-ops relate?
Konstantin 

^ permalink raw reply	[relevance 0%]

* RE: Regarding User Data in DPDK ACL Library.
  2022-11-18 10:30  3%   ` Konstantin Ananyev
  2022-11-19 13:13  0%     ` venkatesh bs
@ 2022-11-21  5:40  0%     ` Honnappa Nagarahalli
  2022-11-21 14:15  0%       ` Konstantin Ananyev
  1 sibling, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-21  5:40 UTC (permalink / raw)
  To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd

<snip>

> 
> 
> > On Thu, 17 Nov 2022 19:28:12 +0530
> > venkatesh bs <venki.bsv@gmail.com> wrote:
> >
> > > Hi DPDK Team,
> > >
> > > After the ACL match for highest priority DPDK Classification API
> > > returns User Data Which is as mentioned below in the document.
> > >
> > > 53. Packet Classification and Access Control — Data Plane
> > > Development Kit
> > > 22.11.0-rc2 documentation (dpdk.org)
> > >
> > >
> > >    - *userdata*: A user-defined value. For each category, a successful
> > >    match returns the userdata field of the highest priority matched rule.
> When
> > >    no rules match, returned value is zero
> > >
> > > I Wonder Why User Data Support does not returns 64 bit values,
> 
> As I remember if first version of ACL code it was something about space
> savings to improve performance...
> Now I think it is more just a historical reason.
> It would be good to change userdata to 64bit, but I presume it will be ABI
> breakage.
Agree. We should support 64b and even 128b (since architectures support 128b atomic operations). This reduces required memory barriers required if the data size <= the size of atomic operations.

> 
> > Always its
> > > possible that User Data in Application Can be 64bit long, But since
> > > 64 bit User data can't be returned by DPDK ACL Library, Application
> > > should have the conversion algorithm from 64 to 32 bit during Rule
> > > add and vice versa after classification.
> > >
> > > I Wonder if anyone would have faced this issue, Please suggest any
> > > suggestions if somewhere am wrong in understanding/Possible Solution
> > > if someone has already gone through this issue.
> > >
> > > Thanks In Advance.
> > > Regards,
> > > Venkatesh B Siddappa.
> >
> > It looks like all users of this API use the userdata to be the index
> > into a table of application specific rules.
> 
> Yes, that's the most common way.
> Another one would be always (build/search) acl rules with two categories:
> rule for both categories will be identical, while data different (low/ho 32bits),
> but that's a bit too awkward from my perspective.
> 
> 
> 


^ permalink raw reply	[relevance 0%]

* Re: Regarding User Data in DPDK ACL Library.
  2022-11-18 10:30  3%   ` Konstantin Ananyev
@ 2022-11-19 13:13  0%     ` venkatesh bs
  2022-11-21  5:40  0%     ` Honnappa Nagarahalli
  1 sibling, 0 replies; 200+ results
From: venkatesh bs @ 2022-11-19 13:13 UTC (permalink / raw)
  To: Konstantin Ananyev; +Cc: Stephen Hemminger, users, dev

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

Hi  konstantin, @stephen@networkplumber.org <stephen@networkplumber.org>

Thanks for the reply and your suggestions. I will try to see what can best
fit into my application.

Thanks & Regards,
Venkatesh.


On Fri, Nov 18, 2022 at 4:01 PM Konstantin Ananyev <
konstantin.ananyev@huawei.com> wrote:

>
>
> > On Thu, 17 Nov 2022 19:28:12 +0530
> > venkatesh bs <venki.bsv@gmail.com> wrote:
> >
> > > Hi DPDK Team,
> > >
> > > After the ACL match for highest priority DPDK Classification API
> returns
> > > User Data Which is as mentioned below in the document.
> > >
> > > 53. Packet Classification and Access Control — Data Plane Development
> Kit
> > > 22.11.0-rc2 documentation (dpdk.org)
> > >
> > >
> > >    - *userdata*: A user-defined value. For each category, a successful
> > >    match returns the userdata field of the highest priority matched
> rule. When
> > >    no rules match, returned value is zero
> > >
> > > I Wonder Why User Data Support does not returns 64 bit values,
>
> As I remember if first version of ACL code it was something about space
> savings
> to improve performance...
> Now I think it is more just a historical reason.
> It would be good to change userdata to 64bit, but I presume it will be ABI
> breakage.
>
> > Always its
> > > possible that User Data in Application Can be 64bit long, But since 64
> bit
> > > User data can't be returned by DPDK ACL Library, Application should
> have
> > > the conversion algorithm from 64 to 32 bit during Rule add and vice
> versa
> > > after classification.
> > >
> > > I Wonder if anyone would have faced this issue, Please suggest any
> > > suggestions if somewhere am wrong in understanding/Possible Solution if
> > > someone has already gone through this issue.
> > >
> > > Thanks In Advance.
> > > Regards,
> > > Venkatesh B Siddappa.
> >
> > It looks like all users of this API use the userdata to be the index
> > into a table of application specific rules.
>
> Yes, that's the most common way.
> Another one would be always (build/search) acl rules with two categories:
> rule for both categories will be identical, while data different (low/ho
> 32bits),
> but that's a bit too awkward from my perspective.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3115 bytes --]

^ permalink raw reply	[relevance 0%]

* RE: Regarding User Data in DPDK ACL Library.
  @ 2022-11-18 10:30  3%   ` Konstantin Ananyev
  2022-11-19 13:13  0%     ` venkatesh bs
  2022-11-21  5:40  0%     ` Honnappa Nagarahalli
  0 siblings, 2 replies; 200+ results
From: Konstantin Ananyev @ 2022-11-18 10:30 UTC (permalink / raw)
  To: Stephen Hemminger, venkatesh bs; +Cc: users, dev



> On Thu, 17 Nov 2022 19:28:12 +0530
> venkatesh bs <venki.bsv@gmail.com> wrote:
> 
> > Hi DPDK Team,
> >
> > After the ACL match for highest priority DPDK Classification API returns
> > User Data Which is as mentioned below in the document.
> >
> > 53. Packet Classification and Access Control — Data Plane Development Kit
> > 22.11.0-rc2 documentation (dpdk.org)
> >
> >
> >    - *userdata*: A user-defined value. For each category, a successful
> >    match returns the userdata field of the highest priority matched rule. When
> >    no rules match, returned value is zero
> >
> > I Wonder Why User Data Support does not returns 64 bit values,
 
As I remember if first version of ACL code it was something about space savings
to improve performance...
Now I think it is more just a historical reason.
It would be good to change userdata to 64bit, but I presume it will be ABI breakage.

> Always its
> > possible that User Data in Application Can be 64bit long, But since 64 bit
> > User data can't be returned by DPDK ACL Library, Application should have
> > the conversion algorithm from 64 to 32 bit during Rule add and vice versa
> > after classification.
> >
> > I Wonder if anyone would have faced this issue, Please suggest any
> > suggestions if somewhere am wrong in understanding/Possible Solution if
> > someone has already gone through this issue.
> >
> > Thanks In Advance.
> > Regards,
> > Venkatesh B Siddappa.
> 
> It looks like all users of this API use the userdata to be the index
> into a table of application specific rules.

Yes, that's the most common way.
Another one would be always (build/search) acl rules with two categories:
rule for both categories will be identical, while data different (low/ho 32bits),
but that's a bit too awkward from my perspective. 
 




^ permalink raw reply	[relevance 3%]

* Re: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
  @ 2022-11-15 16:13  0%   ` Thomas Monjalon
  0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-11-15 16:13 UTC (permalink / raw)
  To: Stephen Coleman; +Cc: dev, Ray Kinsella

19/04/2022 17:44, Ray Kinsella:
> 
> Stephen Coleman <omegacoleman@gmail.com> writes:
> 
> > From 1871ee6f7b98ef89b7c4893d90b5ea264660c201 Mon Sep 17 00:00:00 2001
> > From: youcai <omegacoleman@gmail.com>
> > Date: Tue, 19 Apr 2022 14:38:36 +0800
> > Subject: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
> > Cc: Ray Kinsella <mdr@ashroe.eu>
> >
> > Same issue was fixed in ABI policy in ec5c0f8, but more of this
> > misuse persist in comments and docs. 'depreciated' means diminish
> > in value over a period of time. It should not appear here.
> >
> > Signed-off-by: youcai <omegacoleman@gmail.com>
> > ---
> >  doc/guides/contributing/abi_policy.rst     | 2 +-
> >  doc/guides/contributing/abi_versioning.rst | 2 +-
> >  lib/kni/rte_kni.h                          | 4 ++--
> >  3 files changed, 4 insertions(+), 4 deletions(-)
> >
> Acked-by: Ray Kinsella <mdr@ashroe.eu>

Applied, sorry for the delay, the patch was corrupted.



^ permalink raw reply	[relevance 0%]

* RE: [RFC] mempool: zero-copy cache put bulk
  2022-11-09 22:45  0%         ` Honnappa Nagarahalli
@ 2022-11-10 10:15  0%           ` Morten Brørup
  0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-11-10 10:15 UTC (permalink / raw)
  To: Honnappa Nagarahalli, dev, olivier.matz, andrew.rybchenko,
	Kamalakshitha Aligeri, Bruce Richardson
  Cc: nd, nd

> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, 9 November 2022 23.46
> >
> > +To: Bruce also showed interest in this topic, and might have more
> insights.
> >
> > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > Sent: Wednesday, 9 November 2022 18.58
> > >
> > > <snip>
> > >
> > > >
> > > > > From: Honnappa Nagarahalli
> [mailto:Honnappa.Nagarahalli@arm.com]
> > > > > Sent: Sunday, 6 November 2022 00.11
> > > > >
> > > > > + Akshitha, she is working on similar patch
> > > > >
> > > > > Few comments inline
> > > > >
> > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > > > >
> > > > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > > > performance,
> > > > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > > > without
> > > > > a
> > > > > > performance regression.
> > > > > >
> > > > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > > > >
> > > > > >
> > > > > > This RFC offers a conceptual zero-copy put function, where
> the
> > > > > application
> > > > > > promises to store some objects, and in return gets an address
> > > where
> > > > > to store
> > > > > > them.
> > > > > >
> > > > > > I would like some early feedback.
> > > > > >
> > > > > > Notes:
> > > > > > * Allowing the 'cache' parameter to be NULL, and getting it
> from
> > > the
> > > > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > > > I am not sure why the 'cache' parameter is required for this
> API.
> > > This
> > > > > API should take the mem pool as the parameter.
> > > > >
> > > > > We have based our API on 'rte_mempool_do_generic_put' and
> removed
> > > > the
> > > > > 'cache' parameter.
> > > >
> > > > I thoroughly considered omitting the 'cache' parameter, but
> included
> > > it for
> > > > two reasons:
> > > >
> > > > 1. The function is a "mempool cache" function (i.e. primarily
> > > > working
> > > on the
> > > > mempool cache), not a "mempool" function.
> > > >
> > > > So it is appropriate to have a pointer directly to the structure
> it
> > > is working on.
> > > > Following this through, I also made 'cache' the first parameter
> and
> > > 'mp' the
> > > > second, like in rte_mempool_cache_flush().
> > > I am wondering if the PMD should be aware of the cache or not. For
> ex:
> > > in the case of pipeline mode, the RX and TX side of the PMD are
> > > running on different cores.
> >
> > In that example, the PMD can store two cache pointers, one for each
> of the
> > RX and TX side.
> I did not understand this. If RX core and TX core have their own per-
> core caches the logic would not work. For ex: the RX core cache would
> not get filled.
> 
> In the case of pipeline mode, there will not be a per-core cache. The
> buffers would be allocated and freed from a global ring or a global
> lockless stack.

Aha... Now I understand what you mean: You are referring to use cases where the mempool is configured to *not* have a mempool cache.

For a mempool without a mempool cache, the proposed "mempool cache" zero-copy functions can obviously not be used.

We need "mempool" zero-copy functions for the mempools that have no mempool cache.

However, those functions depend on the mempool's underlying backing store.

E.g. zero-copy access to a ring has certain requirements [1].

[1]: http://doc.dpdk.org/guides/prog_guide/ring_lib.html#ring-peek-zero-copy-api

For a stack, I think it is possible to locklessly zero-copy pop objects. But it is impossible to locklessly zero-copy push elements to a stack; another thread can race to pop some objects from the stack before the pushing thread has finished writing them into the stack.

Furthermore, the ring zero-copy get function cannot return a consecutive array of objects when wrapping, and PMD functions using vector instructions usually rely on handling chunks of e.g. 8 objects.

Just for a second, let me theorize into the absurd: Even worse, if a mempool's underlying backing store does not use an array of pointers as its internal storage structure, it is impossible to use a pointer to an array of pointers for zero-copy transactions. E.g. if the backing store uses a list or a tree structure for its storage, a pointer to somewhere in the list or tree structure is not an array of objects pointers.

Anyway, we could consider designing a generic API for zero-copy mempool get/put; but it should be compatible with all underlying backing stores - or return failure, so the PMD can fall back to the standard functions, if the mempool is in a state where zero-copy access to a contiguous burst cannot be provided. E.g. zero-copy get from a ring can return failure when zero-copy access to the ring is temporarily unavailable due to being at a point where it would wrap.

Here is a conceptual proposal for such an API.

/* Mempool zero-copy transaction state. Opaque outside the mempool API. */
struct rte_mempool_zc_transaction_state {
	char	opaque[RTE_CACHE_LINE_SIZE];
};

/** Start zero-copy get/put bulk transaction.
 *
 * @param[in] mp
 *   Pointer to the mempool.
 * @param[out] obj_table_ptr
 *   Where to store the pointer to
 *   the zero-copy array of objects in the mempool.
 * @param[in] n
 *   Number of objects in the transaction.
 * @param[in] cache
 *   Pointer to the mempool cache. May be NULL if unknown.
 * @param[out] transaction
 *   Where to store the opaque transaction information.
 *   Used internally by the mempool library.
 * @return
 *   - 1: Transaction completed;
 *        '_finish' must not be called.
 *   - 0: Transaction started;
 *        '_finish' must be called to complete the transaction.
 *   - <0: Error; failure code.
 */
static __rte_always_inline int
rte_mempool_get/put_zc_bulk_start(
	struct rte_mempool *mp,
	void ***obj_table_ptr,
	unsigned int n,
	struct rte_mempool_cache *cache,
	rte_mempool_zc_transaction_state *transaction);

/** Finish zero-copy get/put bulk transaction.
 *
 * @param[in] mp
 *   Pointer to mempool.
 * @param[in] obj_table_ptr
 *   Pointer to the zero-copy array of objects in the mempool,
 *   returned by the 'start' function.
 * @param[in] n
 *   Number of objects in the transaction.
 *   Must be the same as for the 'start' function.
 * @param[in] transaction
 *   Opaque transaction information,
 *   returned by the 'start' function.
 *   Used internally by the mempool library.
 */
static __rte_always_inline void
rte_mempool_get/put_zc_bulk_finish(
	struct rte_mempool *mp,
	void **obj_table,
	unsigned int n,
	rte_mempool_zc_transaction_state *transaction);

Note that these are *bulk* functions, so 'n' has to remain the same for a 'finish' call as it was for the 'start' call of a transaction.

And then the underlying backing stores would need to provide callbacks that implement these functions, if they offer zero-copy functionality.

The mempool implementation of these could start by checking for a mempool cache, and use the "mempool cache" zero-copy if present.

Some internal state information (from the mempool library or the underlying mempool backing store) may need to be carried over from the 'start' to the 'finish' function, so I have added a transaction state parameter. The transaction state must be held by the application for thread safety reasons. Think of this like the 'flags' parameter to the Linux kernel's spin_lock_irqsave/irqrestore() functions.

We could omit the 'obj_table' and 'n' parameters from the 'finish' functions and store them in the transaction state if needed; but we might possibly achieve higher performance by passing them as parameters instead.

> 
> >
> > And if the PMD is unaware of the cache pointer, it can look it up at
> runtime
> > using rte_lcore_id(), like it does in the current Intel PMDs.
> >
> > > However, since the rte_mempool_cache_flush API is provided, may be
> > > that decision is already done? Interestingly,
> rte_mempool_cache_flush
> > > is called by just a single PMD.
> >
> > I intentionally aligned this RFC with rte_mempool_cache_flush() to
> maintain
> > consistency.
> >
> > However, the API is not set in stone. It should always be acceptable
> to
> > consider improved alternatives.
> >
> > >
> > > So, the question is, should we allow zero-copy only for per-core
> cache
> > > or for other cases as well.
> >
> > I suppose that the mempool library was designed to have a mempool
> > associated with exactly one mempool cache per core. (Alternatively,
> the
> > mempool can be configured with no mempool caches at all.)
> >
> > We should probably stay loyal to that design concept, and only allow
> zero-
> > copy for per-core cache.
> >
> > If you can come up with an example of the opposite, I would like to
> explore
> > that option too... I can't think of a good example myself, and
> perhaps I'm
> > overlooking a relevant use case.
> The use case I am talking about is the pipeline mode as I mentioned
> above. Let me know if you agree.

I see what you mean, and I don't object. :-)

However, I still think the "mempool cache" zero-copy functions could be useful.

They would be needed for the generic "mempool" zero-copy functions anyway.

And the "mempool cache" zero-copy functions are much simpler to design, implement and use than the "mempool" zero-copy functions, so it is a good first step.

> 
> >
> > >
> > > >
> > > > 2. In most cases, the function only accesses the mempool
> structure
> > > > in
> > > order to
> > > > get the cache pointer. Skipping this step improves performance.
> > > >
> > > > And since the cache is created along with the mempool itself (and
> > > thus never
> > > > changes for a mempool), it would be safe for the PMD to store the
> > > 'cache'
> > > > pointer along with the 'mp' pointer in the PMD's queue structure.
> > > Agreed
> > >
> > > >
> > > > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> > > "struct
> > > > rte_mempool_cache *cache" field, which could be used
> > > > i40e_rxq_rearm()
> > > [1]
> > > > instead of "cache = rte_mempool_default_cache(rxq->mp,
> > > rte_lcore_id())".
> > > >
> > > > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > > > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> > > >
> > > > > This new API, on success, returns the pointer to memory where
> the
> > > > > objects are copied. On failure it returns NULL and the caller
> has
> > > to
> > > > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> > > could
> > > > > do this as well and PMD does not need to do anything if it gets
> a
> > > NULL
> > > > > pointer.
> > > >
> > > > Yes, we agree about these two details:
> > > >
> > > > 1. The function should return a pointer, not an integer.
> > > > It would be a waste to use a another CPU register to convey a
> > > success/error
> > > > integer value, when the success/failure information is just as
> > > > easily
> > > conveyed
> > > > by the pointer return value (non-NULL/NULL), and rte_errno for
> > > various error
> > > > values in the unlikely cases.
> > > >
> > > > 2. The function should leave it up to the PMD what to do if
> direct
> > > access to
> > > > the cache is unavailable.
> > > Just wondering about the advantage of this. I do not think PMD's
> have
> > > much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
> >
> > I agree, but that was not my point. Let me try to rephrase:
> >
> > The PMD is more likely to know how to efficiently build the array of
> mbufs to
> > pass to rte_mempool_ops_enqueue_bulk() than the mempool library -
> many
> > PMDs already implement a variety of vector instruction variants to do
> exactly
> > that. So we should not try to be clever and add a fallback path -
> this job
> > belongs in the PMD.
> >
> > The PMD might not even have the array of mbufs lined up when calling
> > rte_mempool_cache_put_bulk_promise(). The PMD could have an array of
> > internal structures, where the mbuf pointer is an element in that
> structure.
> Agree, you are correct. We should leave it to PMD to handle the failure
> case.
> 
> >
> > >
> > > >
> > > > >
> > > > > We should think about providing  similar API on the RX side to
> > > > > keep
> > > it
> > > > > symmetric.
> > > >
> > > > I sent an RFC for that too:
> > > >
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > > > smartserver.smartshare.dk/T/#u
> > > >
> > > >
> > > > >
> > > > > > * Asserting that the 'mp' parameter is not NULL is not done
> by
> > > other
> > > > > > functions, so I omitted it here too.
> > > > > >
> > > > > > NB: Please ignore formatting. Also, this code has not even
> been
> > > > > compile
> > > > > > tested.
> > > > > We are little bit ahead, tested the changes with i40e PF PMD,
> > > > > wrote unit test cases, going through internal review, will send
> > > > > out RFC
> > > on
> > > > > Monday
> > > >
> > > > Sounds good. Looking forward to review.
> > > >
> > > > >
> > > > > >
> > > > > > /**
> > > > > >  * Promise to put objects in a mempool via zero-copy access
> to a
> > > > > user-owned
> > > > > > mempool cache.
> > > > > >  *
> > > > > >  * @param cache
> > > > > >  *   A pointer to the mempool cache.
> > > > > >  * @param mp
> > > > > >  *   A pointer to the mempool.
> > > > > >  * @param n
> > > > > >  *   The number of objects to be put in the mempool cache.
> > > > > >  * @return
> > > > > >  *   The pointer to where to put the objects in the mempool
> > > cache.
> > > > > >  *   NULL on error
> > > > > >  *   with rte_errno set appropriately.
> > > > > >  */
> > > > > > static __rte_always_inline void *
> > > > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > > > *cache,
> > > > > >         struct rte_mempool *mp,
> > > > > >         unsigned int n)
> > > > > > {
> > > > > >     void **cache_objs;
> > > > > >
> > > > > >     if (cache == NULL)
> > > > > >         cache = rte_mempool_default_cache(mp,
> rte_lcore_id());
> > > Any reason we need this? If we are expecting the PMD to store the
> > > pointer to cache and a NULL is passed, it would mean it is a
> mempool
> > > with no per-core cache?
> > > We could also leave the NULL check to the PMD.
> >
> > Personally, I would strongly prefer requiring the cache pointer to be
> valid,
> > and use RTE_ASSERT() here, instead of allowing a NULL pointer as a
> special
> > case to look it up inside the function. I consider this special NULL
> case useless
> > bloat, which does not belong in a fast path library function.
> >
> > But I copied this approach from rte_mempool_cache_flush().
> The API definition does not bind it to do this check. We might be able
> to delete the check in rte_mempool_cache_flush.
> 
> >
> > We could expose an "unsafe" function where is not allowed to pass
> NULL
> > pointers, and a "safe" function (fixing the cache pointer if NULL)
> for
> > consistency.
> >
> > If the rte_mempool_cache_flush() function is popular, we could also
> expose
> > an "unsafe" variant where passing NULL pointers are disallowed.
> >
> > I wonder if there are any examples of such safe/unsafe variants in
> DPDK? It
> > would be nice with a common naming convention for such function
> variants.
> >
> > >
> > > > > >     if (cache == NULL) {
> > > > > >         rte_errno = EINVAL;
> > > > > >         return NULL;
> > > > > >     }
> > > > > >
> > > > > >     rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > > > >
> > > > > >     /* The request itself is too big for the cache */
> > > > > >     if (unlikely(n > cache->flushthresh)) {
> > > > > >         rte_errno = EINVAL;
> > > > > >         return NULL;
> > > > > >     }
> > > > > >
> > > > > >     /*
> > > > > >      * The cache follows the following algorithm:
> > > > > >      *   1. If the objects cannot be added to the cache
> without
> > > > > crossing
> > > > > >      *      the flush threshold, flush the cache to the
> backend.
> > > > > >      *   2. Add the objects to the cache.
> > > > > >      */
> > > > > >
> > > > > >     if (cache->len + n <= cache->flushthresh) {
> > > > > >         cache_objs = &cache->objs[cache->len];
> > > > > >         cache->len += n;
> > > > > >     } else {
> > > > > >         cache_objs = &cache->objs[0];
> > > > > >         rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache-
> >len);
> > > > > >         cache->len = n;
> > > > > >     }
> > > > > >
> > > > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> > > These are new stats. Do these break ABI compatibility (though these
> > > are under DEBUG flag)?
> >
> > They are not mempool cache stats, they are only kept in the cache
> structure
> > to provide alternative (i.e. faster) update access to some (i.e. the
> most often
> > updated) of the existing mempool stats. The patch is [1], and part of
> a series
> > currently being discussed if should go into 22.11-rc3 or not [2].
> >
> > [1]:
> > https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-
> 3-
> > mb@smartsharesystems.com/
> > [2]:
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6
> > @smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b35327
> > 7082f
> >
> > >
> > > > > >
> > > > > >     return cache_objs;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > Med venlig hilsen / Kind regards, -Morten Brørup
> > > > > >
> > > > >
> > >
> 


^ permalink raw reply	[relevance 0%]

* RE: [RFC] mempool: zero-copy cache put bulk
  2022-11-09 20:36  0%       ` Morten Brørup
@ 2022-11-09 22:45  0%         ` Honnappa Nagarahalli
  2022-11-10 10:15  0%           ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-09 22:45 UTC (permalink / raw)
  To: Morten Brørup, dev, olivier.matz, andrew.rybchenko,
	Kamalakshitha Aligeri, Bruce Richardson
  Cc: nd, nd

<snip>

> 
> +To: Bruce also showed interest in this topic, and might have more insights.
> 
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Wednesday, 9 November 2022 18.58
> >
> > <snip>
> >
> > >
> > > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > > Sent: Sunday, 6 November 2022 00.11
> > > >
> > > > + Akshitha, she is working on similar patch
> > > >
> > > > Few comments inline
> > > >
> > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > > >
> > > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > > performance,
> > > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > > without
> > > > a
> > > > > performance regression.
> > > > >
> > > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > > >
> > > > >
> > > > > This RFC offers a conceptual zero-copy put function, where the
> > > > application
> > > > > promises to store some objects, and in return gets an address
> > where
> > > > to store
> > > > > them.
> > > > >
> > > > > I would like some early feedback.
> > > > >
> > > > > Notes:
> > > > > * Allowing the 'cache' parameter to be NULL, and getting it from
> > the
> > > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > > I am not sure why the 'cache' parameter is required for this API.
> > This
> > > > API should take the mem pool as the parameter.
> > > >
> > > > We have based our API on 'rte_mempool_do_generic_put' and removed
> > > the
> > > > 'cache' parameter.
> > >
> > > I thoroughly considered omitting the 'cache' parameter, but included
> > it for
> > > two reasons:
> > >
> > > 1. The function is a "mempool cache" function (i.e. primarily
> > > working
> > on the
> > > mempool cache), not a "mempool" function.
> > >
> > > So it is appropriate to have a pointer directly to the structure it
> > is working on.
> > > Following this through, I also made 'cache' the first parameter and
> > 'mp' the
> > > second, like in rte_mempool_cache_flush().
> > I am wondering if the PMD should be aware of the cache or not. For ex:
> > in the case of pipeline mode, the RX and TX side of the PMD are
> > running on different cores.
> 
> In that example, the PMD can store two cache pointers, one for each of the
> RX and TX side.
I did not understand this. If RX core and TX core have their own per-core caches the logic would not work. For ex: the RX core cache would not get filled.

In the case of pipeline mode, there will not be a per-core cache. The buffers would be allocated and freed from a global ring or a global lockless stack.

> 
> And if the PMD is unaware of the cache pointer, it can look it up at runtime
> using rte_lcore_id(), like it does in the current Intel PMDs.
> 
> > However, since the rte_mempool_cache_flush API is provided, may be
> > that decision is already done? Interestingly, rte_mempool_cache_flush
> > is called by just a single PMD.
> 
> I intentionally aligned this RFC with rte_mempool_cache_flush() to maintain
> consistency.
> 
> However, the API is not set in stone. It should always be acceptable to
> consider improved alternatives.
> 
> >
> > So, the question is, should we allow zero-copy only for per-core cache
> > or for other cases as well.
> 
> I suppose that the mempool library was designed to have a mempool
> associated with exactly one mempool cache per core. (Alternatively, the
> mempool can be configured with no mempool caches at all.)
> 
> We should probably stay loyal to that design concept, and only allow zero-
> copy for per-core cache.
> 
> If you can come up with an example of the opposite, I would like to explore
> that option too... I can't think of a good example myself, and perhaps I'm
> overlooking a relevant use case.
The use case I am talking about is the pipeline mode as I mentioned above. Let me know if you agree.

> 
> >
> > >
> > > 2. In most cases, the function only accesses the mempool structure
> > > in
> > order to
> > > get the cache pointer. Skipping this step improves performance.
> > >
> > > And since the cache is created along with the mempool itself (and
> > thus never
> > > changes for a mempool), it would be safe for the PMD to store the
> > 'cache'
> > > pointer along with the 'mp' pointer in the PMD's queue structure.
> > Agreed
> >
> > >
> > > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> > "struct
> > > rte_mempool_cache *cache" field, which could be used
> > > i40e_rxq_rearm()
> > [1]
> > > instead of "cache = rte_mempool_default_cache(rxq->mp,
> > rte_lcore_id())".
> > >
> > > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> > >
> > > > This new API, on success, returns the pointer to memory where the
> > > > objects are copied. On failure it returns NULL and the caller has
> > to
> > > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> > could
> > > > do this as well and PMD does not need to do anything if it gets a
> > NULL
> > > > pointer.
> > >
> > > Yes, we agree about these two details:
> > >
> > > 1. The function should return a pointer, not an integer.
> > > It would be a waste to use a another CPU register to convey a
> > success/error
> > > integer value, when the success/failure information is just as
> > > easily
> > conveyed
> > > by the pointer return value (non-NULL/NULL), and rte_errno for
> > various error
> > > values in the unlikely cases.
> > >
> > > 2. The function should leave it up to the PMD what to do if direct
> > access to
> > > the cache is unavailable.
> > Just wondering about the advantage of this. I do not think PMD's have
> > much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
> 
> I agree, but that was not my point. Let me try to rephrase:
> 
> The PMD is more likely to know how to efficiently build the array of mbufs to
> pass to rte_mempool_ops_enqueue_bulk() than the mempool library - many
> PMDs already implement a variety of vector instruction variants to do exactly
> that. So we should not try to be clever and add a fallback path - this job
> belongs in the PMD.
> 
> The PMD might not even have the array of mbufs lined up when calling
> rte_mempool_cache_put_bulk_promise(). The PMD could have an array of
> internal structures, where the mbuf pointer is an element in that structure.
Agree, you are correct. We should leave it to PMD to handle the failure case.

> 
> >
> > >
> > > >
> > > > We should think about providing  similar API on the RX side to
> > > > keep
> > it
> > > > symmetric.
> > >
> > > I sent an RFC for that too:
> > >
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > > smartserver.smartshare.dk/T/#u
> > >
> > >
> > > >
> > > > > * Asserting that the 'mp' parameter is not NULL is not done by
> > other
> > > > > functions, so I omitted it here too.
> > > > >
> > > > > NB: Please ignore formatting. Also, this code has not even been
> > > > compile
> > > > > tested.
> > > > We are little bit ahead, tested the changes with i40e PF PMD,
> > > > wrote unit test cases, going through internal review, will send
> > > > out RFC
> > on
> > > > Monday
> > >
> > > Sounds good. Looking forward to review.
> > >
> > > >
> > > > >
> > > > > /**
> > > > >  * Promise to put objects in a mempool via zero-copy access to a
> > > > user-owned
> > > > > mempool cache.
> > > > >  *
> > > > >  * @param cache
> > > > >  *   A pointer to the mempool cache.
> > > > >  * @param mp
> > > > >  *   A pointer to the mempool.
> > > > >  * @param n
> > > > >  *   The number of objects to be put in the mempool cache.
> > > > >  * @return
> > > > >  *   The pointer to where to put the objects in the mempool
> > cache.
> > > > >  *   NULL on error
> > > > >  *   with rte_errno set appropriately.
> > > > >  */
> > > > > static __rte_always_inline void *
> > > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > > *cache,
> > > > >         struct rte_mempool *mp,
> > > > >         unsigned int n)
> > > > > {
> > > > >     void **cache_objs;
> > > > >
> > > > >     if (cache == NULL)
> > > > >         cache = rte_mempool_default_cache(mp, rte_lcore_id());
> > Any reason we need this? If we are expecting the PMD to store the
> > pointer to cache and a NULL is passed, it would mean it is a mempool
> > with no per-core cache?
> > We could also leave the NULL check to the PMD.
> 
> Personally, I would strongly prefer requiring the cache pointer to be valid,
> and use RTE_ASSERT() here, instead of allowing a NULL pointer as a special
> case to look it up inside the function. I consider this special NULL case useless
> bloat, which does not belong in a fast path library function.
> 
> But I copied this approach from rte_mempool_cache_flush().
The API definition does not bind it to do this check. We might be able to delete the check in rte_mempool_cache_flush.

> 
> We could expose an "unsafe" function where is not allowed to pass NULL
> pointers, and a "safe" function (fixing the cache pointer if NULL) for
> consistency.
> 
> If the rte_mempool_cache_flush() function is popular, we could also expose
> an "unsafe" variant where passing NULL pointers are disallowed.
> 
> I wonder if there are any examples of such safe/unsafe variants in DPDK? It
> would be nice with a common naming convention for such function variants.
> 
> >
> > > > >     if (cache == NULL) {
> > > > >         rte_errno = EINVAL;
> > > > >         return NULL;
> > > > >     }
> > > > >
> > > > >     rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > > >
> > > > >     /* The request itself is too big for the cache */
> > > > >     if (unlikely(n > cache->flushthresh)) {
> > > > >         rte_errno = EINVAL;
> > > > >         return NULL;
> > > > >     }
> > > > >
> > > > >     /*
> > > > >      * The cache follows the following algorithm:
> > > > >      *   1. If the objects cannot be added to the cache without
> > > > crossing
> > > > >      *      the flush threshold, flush the cache to the backend.
> > > > >      *   2. Add the objects to the cache.
> > > > >      */
> > > > >
> > > > >     if (cache->len + n <= cache->flushthresh) {
> > > > >         cache_objs = &cache->objs[cache->len];
> > > > >         cache->len += n;
> > > > >     } else {
> > > > >         cache_objs = &cache->objs[0];
> > > > >         rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > > > >         cache->len = n;
> > > > >     }
> > > > >
> > > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> > These are new stats. Do these break ABI compatibility (though these
> > are under DEBUG flag)?
> 
> They are not mempool cache stats, they are only kept in the cache structure
> to provide alternative (i.e. faster) update access to some (i.e. the most often
> updated) of the existing mempool stats. The patch is [1], and part of a series
> currently being discussed if should go into 22.11-rc3 or not [2].
> 
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-3-
> mb@smartsharesystems.com/
> [2]:
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6
> @smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b35327
> 7082f
> 
> >
> > > > >
> > > > >     return cache_objs;
> > > > > }
> > > > >
> > > > >
> > > > > Med venlig hilsen / Kind regards, -Morten Brørup
> > > > >
> > > >
> >


^ permalink raw reply	[relevance 0%]

* RE: [RFC] mempool: zero-copy cache put bulk
  2022-11-09 17:57  3%     ` Honnappa Nagarahalli
@ 2022-11-09 20:36  0%       ` Morten Brørup
  2022-11-09 22:45  0%         ` Honnappa Nagarahalli
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-11-09 20:36 UTC (permalink / raw)
  To: Honnappa Nagarahalli, dev, olivier.matz, andrew.rybchenko,
	Kamalakshitha Aligeri, Bruce Richardson
  Cc: nd

+To: Bruce also showed interest in this topic, and might have more insights.

> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, 9 November 2022 18.58
> 
> <snip>
> 
> >
> > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > Sent: Sunday, 6 November 2022 00.11
> > >
> > > + Akshitha, she is working on similar patch
> > >
> > > Few comments inline
> > >
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > >
> > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > performance,
> > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > without
> > > a
> > > > performance regression.
> > > >
> > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > >
> > > >
> > > > This RFC offers a conceptual zero-copy put function, where the
> > > application
> > > > promises to store some objects, and in return gets an address
> where
> > > to store
> > > > them.
> > > >
> > > > I would like some early feedback.
> > > >
> > > > Notes:
> > > > * Allowing the 'cache' parameter to be NULL, and getting it from
> the
> > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > I am not sure why the 'cache' parameter is required for this API.
> This
> > > API should take the mem pool as the parameter.
> > >
> > > We have based our API on 'rte_mempool_do_generic_put' and removed
> > the
> > > 'cache' parameter.
> >
> > I thoroughly considered omitting the 'cache' parameter, but included
> it for
> > two reasons:
> >
> > 1. The function is a "mempool cache" function (i.e. primarily working
> on the
> > mempool cache), not a "mempool" function.
> >
> > So it is appropriate to have a pointer directly to the structure it
> is working on.
> > Following this through, I also made 'cache' the first parameter and
> 'mp' the
> > second, like in rte_mempool_cache_flush().
> I am wondering if the PMD should be aware of the cache or not. For ex:
> in the case of pipeline mode, the RX and TX side of the PMD are running
> on different cores.

In that example, the PMD can store two cache pointers, one for each of the RX and TX side.

And if the PMD is unaware of the cache pointer, it can look it up at runtime using rte_lcore_id(), like it does in the current Intel PMDs.

> However, since the rte_mempool_cache_flush API is provided, may be that
> decision is already done? Interestingly, rte_mempool_cache_flush is
> called by just a single PMD.

I intentionally aligned this RFC with rte_mempool_cache_flush() to maintain consistency.

However, the API is not set in stone. It should always be acceptable to consider improved alternatives.

> 
> So, the question is, should we allow zero-copy only for per-core cache
> or for other cases as well.

I suppose that the mempool library was designed to have a mempool associated with exactly one mempool cache per core. (Alternatively, the mempool can be configured with no mempool caches at all.)

We should probably stay loyal to that design concept, and only allow zero-copy for per-core cache.

If you can come up with an example of the opposite, I would like to explore that option too... I can't think of a good example myself, and perhaps I'm overlooking a relevant use case.

> 
> >
> > 2. In most cases, the function only accesses the mempool structure in
> order to
> > get the cache pointer. Skipping this step improves performance.
> >
> > And since the cache is created along with the mempool itself (and
> thus never
> > changes for a mempool), it would be safe for the PMD to store the
> 'cache'
> > pointer along with the 'mp' pointer in the PMD's queue structure.
> Agreed
> 
> >
> > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> "struct
> > rte_mempool_cache *cache" field, which could be used i40e_rxq_rearm()
> [1]
> > instead of "cache = rte_mempool_default_cache(rxq->mp,
> rte_lcore_id())".
> >
> > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> >
> > > This new API, on success, returns the pointer to memory where the
> > > objects are copied. On failure it returns NULL and the caller has
> to
> > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> could
> > > do this as well and PMD does not need to do anything if it gets a
> NULL
> > > pointer.
> >
> > Yes, we agree about these two details:
> >
> > 1. The function should return a pointer, not an integer.
> > It would be a waste to use a another CPU register to convey a
> success/error
> > integer value, when the success/failure information is just as easily
> conveyed
> > by the pointer return value (non-NULL/NULL), and rte_errno for
> various error
> > values in the unlikely cases.
> >
> > 2. The function should leave it up to the PMD what to do if direct
> access to
> > the cache is unavailable.
> Just wondering about the advantage of this. I do not think PMD's have
> much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'

I agree, but that was not my point. Let me try to rephrase:

The PMD is more likely to know how to efficiently build the array of mbufs to pass to rte_mempool_ops_enqueue_bulk() than the mempool library - many PMDs already implement a variety of vector instruction variants to do exactly that. So we should not try to be clever and add a fallback path - this job belongs in the PMD.

The PMD might not even have the array of mbufs lined up when calling rte_mempool_cache_put_bulk_promise(). The PMD could have an array of internal structures, where the mbuf pointer is an element in that structure.

> 
> >
> > >
> > > We should think about providing  similar API on the RX side to keep
> it
> > > symmetric.
> >
> > I sent an RFC for that too:
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > smartserver.smartshare.dk/T/#u
> >
> >
> > >
> > > > * Asserting that the 'mp' parameter is not NULL is not done by
> other
> > > > functions, so I omitted it here too.
> > > >
> > > > NB: Please ignore formatting. Also, this code has not even been
> > > compile
> > > > tested.
> > > We are little bit ahead, tested the changes with i40e PF PMD, wrote
> > > unit test cases, going through internal review, will send out RFC
> on
> > > Monday
> >
> > Sounds good. Looking forward to review.
> >
> > >
> > > >
> > > > /**
> > > >  * Promise to put objects in a mempool via zero-copy access to a
> > > user-owned
> > > > mempool cache.
> > > >  *
> > > >  * @param cache
> > > >  *   A pointer to the mempool cache.
> > > >  * @param mp
> > > >  *   A pointer to the mempool.
> > > >  * @param n
> > > >  *   The number of objects to be put in the mempool cache.
> > > >  * @return
> > > >  *   The pointer to where to put the objects in the mempool
> cache.
> > > >  *   NULL on error
> > > >  *   with rte_errno set appropriately.
> > > >  */
> > > > static __rte_always_inline void *
> > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > *cache,
> > > >         struct rte_mempool *mp,
> > > >         unsigned int n)
> > > > {
> > > >     void **cache_objs;
> > > >
> > > >     if (cache == NULL)
> > > >         cache = rte_mempool_default_cache(mp, rte_lcore_id());
> Any reason we need this? If we are expecting the PMD to store the
> pointer to cache and a NULL is passed, it would mean it is a mempool
> with no per-core cache?
> We could also leave the NULL check to the PMD.

Personally, I would strongly prefer requiring the cache pointer to be valid, and use RTE_ASSERT() here, instead of allowing a NULL pointer as a special case to look it up inside the function. I consider this special NULL case useless bloat, which does not belong in a fast path library function.

But I copied this approach from rte_mempool_cache_flush().

We could expose an "unsafe" function where is not allowed to pass NULL pointers, and a "safe" function (fixing the cache pointer if NULL) for consistency.

If the rte_mempool_cache_flush() function is popular, we could also expose an "unsafe" variant where passing NULL pointers are disallowed.

I wonder if there are any examples of such safe/unsafe variants in DPDK? It would be nice with a common naming convention for such function variants.

> 
> > > >     if (cache == NULL) {
> > > >         rte_errno = EINVAL;
> > > >         return NULL;
> > > >     }
> > > >
> > > >     rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > >
> > > >     /* The request itself is too big for the cache */
> > > >     if (unlikely(n > cache->flushthresh)) {
> > > >         rte_errno = EINVAL;
> > > >         return NULL;
> > > >     }
> > > >
> > > >     /*
> > > >      * The cache follows the following algorithm:
> > > >      *   1. If the objects cannot be added to the cache without
> > > crossing
> > > >      *      the flush threshold, flush the cache to the backend.
> > > >      *   2. Add the objects to the cache.
> > > >      */
> > > >
> > > >     if (cache->len + n <= cache->flushthresh) {
> > > >         cache_objs = &cache->objs[cache->len];
> > > >         cache->len += n;
> > > >     } else {
> > > >         cache_objs = &cache->objs[0];
> > > >         rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > > >         cache->len = n;
> > > >     }
> > > >
> > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> These are new stats. Do these break ABI compatibility (though these are
> under DEBUG flag)?

They are not mempool cache stats, they are only kept in the cache structure to provide alternative (i.e. faster) update access to some (i.e. the most often updated) of the existing mempool stats. The patch is [1], and part of a series currently being discussed if should go into 22.11-rc3 or not [2].

[1]: https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-3-mb@smartsharesystems.com/
[2]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6@smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b353277082f

> 
> > > >
> > > >     return cache_objs;
> > > > }
> > > >
> > > >
> > > > Med venlig hilsen / Kind regards,
> > > > -Morten Brørup
> > > >
> > >
> 


^ permalink raw reply	[relevance 0%]

* RE: [RFC] mempool: zero-copy cache put bulk
  @ 2022-11-09 17:57  3%     ` Honnappa Nagarahalli
  2022-11-09 20:36  0%       ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-09 17:57 UTC (permalink / raw)
  To: Morten Brørup, dev, olivier.matz, andrew.rybchenko,
	Kamalakshitha Aligeri
  Cc: nd, nd

<snip>

> 
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Sunday, 6 November 2022 00.11
> >
> > + Akshitha, she is working on similar patch
> >
> > Few comments inline
> >
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Saturday, November 5, 2022 8:40 AM
> > >
> > > Zero-copy access to the mempool cache is beneficial for PMD
> > performance,
> > > and must be provided by the mempool library to fix [Bug 1052]
> > > without
> > a
> > > performance regression.
> > >
> > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > >
> > >
> > > This RFC offers a conceptual zero-copy put function, where the
> > application
> > > promises to store some objects, and in return gets an address where
> > to store
> > > them.
> > >
> > > I would like some early feedback.
> > >
> > > Notes:
> > > * Allowing the 'cache' parameter to be NULL, and getting it from the
> > > mempool instead, was inspired by rte_mempool_cache_flush().
> > I am not sure why the 'cache' parameter is required for this API. This
> > API should take the mem pool as the parameter.
> >
> > We have based our API on 'rte_mempool_do_generic_put' and removed
> the
> > 'cache' parameter.
> 
> I thoroughly considered omitting the 'cache' parameter, but included it for
> two reasons:
> 
> 1. The function is a "mempool cache" function (i.e. primarily working on the
> mempool cache), not a "mempool" function.
> 
> So it is appropriate to have a pointer directly to the structure it is working on.
> Following this through, I also made 'cache' the first parameter and 'mp' the
> second, like in rte_mempool_cache_flush().
I am wondering if the PMD should be aware of the cache or not. For ex: in the case of pipeline mode, the RX and TX side of the PMD are running on different cores.
However, since the rte_mempool_cache_flush API is provided, may be that decision is already done? Interestingly, rte_mempool_cache_flush is called by just a single PMD.

So, the question is, should we allow zero-copy only for per-core cache or for other cases as well.

> 
> 2. In most cases, the function only accesses the mempool structure in order to
> get the cache pointer. Skipping this step improves performance.
> 
> And since the cache is created along with the mempool itself (and thus never
> changes for a mempool), it would be safe for the PMD to store the 'cache'
> pointer along with the 'mp' pointer in the PMD's queue structure.
Agreed

> 
> E.g. in the i40e PMD the i40e_rx_queue structure could include a "struct
> rte_mempool_cache *cache" field, which could be used i40e_rxq_rearm() [1]
> instead of "cache = rte_mempool_default_cache(rxq->mp, rte_lcore_id())".
> 
> [1] https://elixir.bootlin.com/dpdk/v22.11-
> rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> 
> > This new API, on success, returns the pointer to memory where the
> > objects are copied. On failure it returns NULL and the caller has to
> > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API could
> > do this as well and PMD does not need to do anything if it gets a NULL
> > pointer.
> 
> Yes, we agree about these two details:
> 
> 1. The function should return a pointer, not an integer.
> It would be a waste to use a another CPU register to convey a success/error
> integer value, when the success/failure information is just as easily conveyed
> by the pointer return value (non-NULL/NULL), and rte_errno for various error
> values in the unlikely cases.
> 
> 2. The function should leave it up to the PMD what to do if direct access to
> the cache is unavailable.
Just wondering about the advantage of this. I do not think PMD's have much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'

> 
> >
> > We should think about providing  similar API on the RX side to keep it
> > symmetric.
> 
> I sent an RFC for that too:
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> smartserver.smartshare.dk/T/#u
> 
> 
> >
> > > * Asserting that the 'mp' parameter is not NULL is not done by other
> > > functions, so I omitted it here too.
> > >
> > > NB: Please ignore formatting. Also, this code has not even been
> > compile
> > > tested.
> > We are little bit ahead, tested the changes with i40e PF PMD, wrote
> > unit test cases, going through internal review, will send out RFC on
> > Monday
> 
> Sounds good. Looking forward to review.
> 
> >
> > >
> > > /**
> > >  * Promise to put objects in a mempool via zero-copy access to a
> > user-owned
> > > mempool cache.
> > >  *
> > >  * @param cache
> > >  *   A pointer to the mempool cache.
> > >  * @param mp
> > >  *   A pointer to the mempool.
> > >  * @param n
> > >  *   The number of objects to be put in the mempool cache.
> > >  * @return
> > >  *   The pointer to where to put the objects in the mempool cache.
> > >  *   NULL on error
> > >  *   with rte_errno set appropriately.
> > >  */
> > > static __rte_always_inline void *
> > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> *cache,
> > >         struct rte_mempool *mp,
> > >         unsigned int n)
> > > {
> > >     void **cache_objs;
> > >
> > >     if (cache == NULL)
> > >         cache = rte_mempool_default_cache(mp, rte_lcore_id());
Any reason we need this? If we are expecting the PMD to store the pointer to cache and a NULL is passed, it would mean it is a mempool with no per-core cache?
We could also leave the NULL check to the PMD.

> > >     if (cache == NULL) {
> > >         rte_errno = EINVAL;
> > >         return NULL;
> > >     }
> > >
> > >     rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > >
> > >     /* The request itself is too big for the cache */
> > >     if (unlikely(n > cache->flushthresh)) {
> > >         rte_errno = EINVAL;
> > >         return NULL;
> > >     }
> > >
> > >     /*
> > >      * The cache follows the following algorithm:
> > >      *   1. If the objects cannot be added to the cache without
> > crossing
> > >      *      the flush threshold, flush the cache to the backend.
> > >      *   2. Add the objects to the cache.
> > >      */
> > >
> > >     if (cache->len + n <= cache->flushthresh) {
> > >         cache_objs = &cache->objs[cache->len];
> > >         cache->len += n;
> > >     } else {
> > >         cache_objs = &cache->objs[0];
> > >         rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > >         cache->len = n;
> > >     }
> > >
> > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > >     RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
These are new stats. Do these break ABI compatibility (though these are under DEBUG flag)?

> > >
> > >     return cache_objs;
> > > }
> > >
> > >
> > > Med venlig hilsen / Kind regards,
> > > -Morten Brørup
> > >
> >


^ permalink raw reply	[relevance 3%]

* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
  2022-11-09 10:19  4%               ` Konstantin Ananyev
@ 2022-11-09 11:42  0%                 ` Morten Brørup
  0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-11-09 11:42 UTC (permalink / raw)
  To: Konstantin Ananyev, Mattias Rönnblom, Bruce Richardson,
	Thomas Monjalon
  Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
	stephen, jerinj

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Wednesday, 9 November 2022 11.20
> 
> > On 2022-11-09 06:03, Morten Brørup wrote:
> > >> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > >> Sent: Tuesday, 8 November 2022 18.38
> > >>>
> > >>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > >>>> 08/11/2022 15:30, Morten Brørup:
> > >>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > >>>>>> 08/11/2022 12:25, Morten Brørup:
> > >>>>>>> From: Morten Brørup
> > >>>>>>>> From: Konstantin Ananyev
> > >> [mailto:konstantin.ananyev@huawei.com]
> > >>>>>>>> Sent: Tuesday, 8 November 2022 10.20
> > >>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > >>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> > >> (cache)-
> > >>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-
> 313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-
> > caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
> > >>>>>>>>
> > >>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
> > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-
> 454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-
> > 4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
> > >>>>>> (n))
> > >>>>>>>> Apart from that, LGTM.
> > >>>>>>>> Series-Acked-by: Konstantin Ananyev
> > >> <konstantin.ananyev@huawei.com>
> > >>>>>>>
> > >>>>>>> @Thomas, this series should be ready to apply... it now has
> > >> been:
> > >>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > >>>>>> <andrew.rybchenko@oktetlabs.ru>
> > >>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > >>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > >>>>>>
> > >>>>>> Being acked does not mean it is good to apply in -rc3.
> > >>>>>
> > >>>>> I understand that the RFC/v1 of this series was formally too
> late
> > >> to make it in 22.11, so I will not complain loudly if you choose
> to
> > >>> omit it for 22.11.
> > >>>>>
> > >>>>> With two independent reviews, including from a mempool
> > >> maintainer, I still have some hope. Also considering the risk
> > >> assessment
> > >>> below. ;-)
> > >>>>>
> > >>>>>> Please tell what is the benefit for 22.11 (before/after and
> > >> condition).
> > >>>>>
> > >>>>> Short version: With this series, mempool statistics can be used
> > >> in production. Without it, the performance cost
> > >>> (mempool_perf_autotest: -74 %) is prohibitive!
> > >>>>>
> > >>>>> Long version:
> > >>>>>
> > >>>>> The patch series provides significantly higher performance for
> > >> mempool statistics, which are readable through
> > >>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > >>>>>
> > >>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG
> at
> > >> build time to get mempool statistics.
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before
> and
> > >> after each mempool object, which are all verified on
> > >>> get/put from the mempool. According to mempool_perf_autotest, the
> > >> performance cost of mempool statistics (by setting
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> > >> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> > >>> production!
> > >>>>>
> > >>>>> With this series, the performance cost of mempool statistics
> (by
> > >> setting RTE_LIBRTE_MEMPOOL_STATS) in
> > >>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> > >> used in production.
> > >>>>>
> > >>>>>> Note there is a real risk doing such change that late.
> > >>>>>
> > >>>>> Risk assessment:
> > >>>>>
> > >>>>> The patch series has zero effect unless either
> > >> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> > >>> building. They are not set in the default build.
> > >>>>
> > >>>> If theses build flags are not set, there is no risk and no
> benefit.
> > >>>> But if they are set, there is a risk of regression,
> > >>>> for the benefit of an increased performance of a debug feature.
> > >>>> I would say it is better to avoid any functional regression in a
> > >> debug feature
> > >>>> at this stage.
> > >>>> Any other opinion?
> > >>>>
> > >>> While I agree that we should avoid any functional regression, I
> > >> wonder how
> > >>> widely used the debug feature is, and how big the risk of a
> > >> regression is?
> > >>> Even if there is one, having a regression in a debug feature is a
> lot
> > >> less
> > >>> serious than having one in something which goes into production.
> > >>>
> > >>
> > >> Unless it introduces an ABI breakage (as I understand it doesn't),
> I'll
> > >> wait till 23.03.
> > >> Just in case.
> > >
> > > If built (both before and after this series) without
> RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS,
> > which is introduced by the series), there is no ABI breakage.
> > >
> > > If built (both before and after this series) with
> RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the
> > ABI differs between before and after this series: The stats array
> disappears from struct rte_mempool, and the output from
> > rte_mempool_dump() does not include the statistics.
> > >
> 
> Can we probably always enable RTE_LIBRTE_MEMPOOL_STATS when
> RTE_LIBRTE_MEMPOOL_DEBUG is on?

That would fix the rte_mempool_dump() API breakage, yes.

But since it's only a partial fix, I don't think we should do it.

> 
> > > If built (both before and after this series) with
> RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI
> > also differs between before and after this series: The size of the
> stats array in struct rte_mempool grows by one element.
> 
> Ah yes, missed that one.
> So the question is then - does it count as formal ABI breakage or not?

Yes, this is a key question!

However, performance improvements are not accepted as LTS patches, so not including it in -rc3 will make it useless until 23.11. (At least for users deploying only LTS releases.)

> If yes, then probably better to go ahead with these changes for 22.11
> (it sounds too prohibitive to wait for an year here).
> Or at least take in the part that introduce the ABI breakage.

Without the 3rd patch in the series, the performance is not fully optimized. (Remember: Only relevant when built with RTE_LIBRTE_MEMPOOL_STATS.)

> If not, probably not bit deal to wait till 23.03.
> 
> > >> BTW, as a side thought - if the impact is really that small now,
> would
> > >> it make sense to make
> > >> it run-time option, instead of compile-time one?
> > >
> > > The mempool get/put functions are very lean when built without
> STATS or DEBUG. With a runtime option, the resulting code would
> > be slightly longer, and only one additional conditional would be hit
> in the common case (i.e. when the objects don't miss the mempool
> > cache). So with stats disabled (at runtime), it would only add a very
> small performance cost. However, checking the value of the
> > enabled/disabled variable can cause a CPU cache miss, which has a
> performance cost. And the enabled/disabled variable should
> > definitely be global - if it is per mempool, it will cause many CPU
> cache misses (because the common case doesn't touch the mempool
> > structure, only the mempool cache structure).
> > >
> 
> Yes, either a global one, or put it into both structs:
> rte_mempool_cache and rte_mempool.

That is doable. There is room for it in rte_mempool_cache, and it can be a flag in rte_mempool.

> 
> > It's not totally obvious that a conditional is better than just
> always
> > performing these simple arithmetic operations, even if you don't know
> if
> > you need the result (i.e., if stats is enabled or not), especially
> since
> > they operate on a cache line that is very likely already owned by the
> > core running the core (since the 'len' fields is frequently used).
> 
> Yep, that's another option - always update the cache part.

Yes, always updating the rte_mempool_cache stats to avoid the conditional in the likely code path seems like a viable concept.

(And for now, we can ignore that 64 bit stats are somewhat more costly on 32 bit architectures if tearing must be avoided. I say that we can ignore it for now, because this kind of tearing is ignored for 64 bit stats everywhere in DPDK, so it should be ignorable here too.)

> 
> > > Also, checking the runtime option should have unlikely(), so the
> performance cost of the stats (when enabled at runtime) is also
> > higher than with a build time option. (Yes, dynamic branch prediction
> will alleviate most of this, but it will consume entries in the
> > branch predictor table - these are inlined functions. Just like we
> always try to avoid cache misses in DPDK, we should also try to
> > conserve branch predictor table entries. I hate the argument that
> branch prediction fixes conditionals, especially if they are weird or
> > could have been avoided.)
> > >
> > > In the cost/benefit analysis, we need to consider that these
> statistics are not fill/emptiness level status or similar, but only
> debug
> > counters (number of get/put transactions and objects), so we need to
> ask ourselves this question: How many users are interested in
> > these statistics for production and are unable to build their
> application with RTE_LIBRTE_MEMPOOL_STATS?
> 
> Obviously, I don't have such stats.
> From my perspective - I am ok to spend few extra cycles to avoid
> building separate binary.
> Again, I guess that  with global switch the impact will be negligible.
> But anyway, it will require even more changes and another ABI breakage
> (as stats should always be included),
> so it definitely out of scope for this release.

Agree. This series can be tweaked further, as the discussion clearly shows.

However, time is about to run out on. If we want to include it 22.11, we should take it into -rc3 without any of the discussed modifications (except fixing the macro to satisfy checkpatch).

Furthermore, the discussed modifications - various ways of handling a runtime option - will introduce some performance degradation with the default build configuration. Regardless how small we think the performance degradation is, I would hesitate to introduce a performance degradation in -rc3.

The current patch series has zero performance effect with the default build configuration.

> 
> > > For example, we (SmartShare Systems) are only interested in them
> for application profiling purposes... trying to improve the
> > performance by striving for a higher number of objects per burst in
> every pipeline stage.
> > >
> > >> Konstantin


^ permalink raw reply	[relevance 0%]

* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
  2022-11-09  8:21  0%             ` Mattias Rönnblom
@ 2022-11-09 10:19  4%               ` Konstantin Ananyev
  2022-11-09 11:42  0%                 ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-09 10:19 UTC (permalink / raw)
  To: Mattias Rönnblom, Morten Brørup, Bruce Richardson,
	Thomas Monjalon
  Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
	stephen, jerinj


> On 2022-11-09 06:03, Morten Brørup wrote:
> >> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> >> Sent: Tuesday, 8 November 2022 18.38
> >>>
> >>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> >>>> 08/11/2022 15:30, Morten Brørup:
> >>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>> 08/11/2022 12:25, Morten Brørup:
> >>>>>>> From: Morten Brørup
> >>>>>>>> From: Konstantin Ananyev
> >> [mailto:konstantin.ananyev@huawei.com]
> >>>>>>>> Sent: Tuesday, 8 November 2022 10.20
> >>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> >>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> >> (cache)-
> >>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-
> caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
> >>>>>>>>
> >>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
> >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-
> 4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
> >>>>>> (n))
> >>>>>>>> Apart from that, LGTM.
> >>>>>>>> Series-Acked-by: Konstantin Ananyev
> >> <konstantin.ananyev@huawei.com>
> >>>>>>>
> >>>>>>> @Thomas, this series should be ready to apply... it now has
> >> been:
> >>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
> >>>>>> <andrew.rybchenko@oktetlabs.ru>
> >>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> >>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> >>>>>>
> >>>>>> Being acked does not mean it is good to apply in -rc3.
> >>>>>
> >>>>> I understand that the RFC/v1 of this series was formally too late
> >> to make it in 22.11, so I will not complain loudly if you choose to
> >>> omit it for 22.11.
> >>>>>
> >>>>> With two independent reviews, including from a mempool
> >> maintainer, I still have some hope. Also considering the risk
> >> assessment
> >>> below. ;-)
> >>>>>
> >>>>>> Please tell what is the benefit for 22.11 (before/after and
> >> condition).
> >>>>>
> >>>>> Short version: With this series, mempool statistics can be used
> >> in production. Without it, the performance cost
> >>> (mempool_perf_autotest: -74 %) is prohibitive!
> >>>>>
> >>>>> Long version:
> >>>>>
> >>>>> The patch series provides significantly higher performance for
> >> mempool statistics, which are readable through
> >>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> >>>>>
> >>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
> >> build time to get mempool statistics.
> >>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
> >> after each mempool object, which are all verified on
> >>> get/put from the mempool. According to mempool_perf_autotest, the
> >> performance cost of mempool statistics (by setting
> >>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> >> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> >>> production!
> >>>>>
> >>>>> With this series, the performance cost of mempool statistics (by
> >> setting RTE_LIBRTE_MEMPOOL_STATS) in
> >>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> >> used in production.
> >>>>>
> >>>>>> Note there is a real risk doing such change that late.
> >>>>>
> >>>>> Risk assessment:
> >>>>>
> >>>>> The patch series has zero effect unless either
> >> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> >>> building. They are not set in the default build.
> >>>>
> >>>> If theses build flags are not set, there is no risk and no benefit.
> >>>> But if they are set, there is a risk of regression,
> >>>> for the benefit of an increased performance of a debug feature.
> >>>> I would say it is better to avoid any functional regression in a
> >> debug feature
> >>>> at this stage.
> >>>> Any other opinion?
> >>>>
> >>> While I agree that we should avoid any functional regression, I
> >> wonder how
> >>> widely used the debug feature is, and how big the risk of a
> >> regression is?
> >>> Even if there is one, having a regression in a debug feature is a lot
> >> less
> >>> serious than having one in something which goes into production.
> >>>
> >>
> >> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
> >> wait till 23.03.
> >> Just in case.
> >
> > If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS,
> which is introduced by the series), there is no ABI breakage.
> >
> > If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the
> ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from
> rte_mempool_dump() does not include the statistics.
> >

Can we probably always enable RTE_LIBRTE_MEMPOOL_STATS when RTE_LIBRTE_MEMPOOL_DEBUG is on? 

> > If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI
> also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.

Ah yes, missed that one.
So the question is then - does it count as formal ABI breakage or not?
If yes, then probably better to go ahead with these changes for 22.11
(it sounds too prohibitive to wait for an year here).  
Or at least take in the part that introduce the ABI breakage.
If not, probably not bit deal to wait till 23.03.

> >> BTW, as a side thought - if the impact is really that small now, would
> >> it make sense to make
> >> it run-time option, instead of compile-time one?
> >
> > The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would
> be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool
> cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the
> enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should
> definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool
> structure, only the mempool cache structure).
> >

Yes, either a global one, or put it into both structs: rte_mempool_cache and rte_mempool.

> It's not totally obvious that a conditional is better than just always
> performing these simple arithmetic operations, even if you don't know if
> you need the result (i.e., if stats is enabled or not), especially since
> they operate on a cache line that is very likely already owned by the
> core running the core (since the 'len' fields is frequently used).

Yep, that's another option - always update the cache part.

> > Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also
> higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the
> branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to
> conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or
> could have been avoided.)
> >
> > In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug
> counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in
> these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?

Obviously, I don't have such stats.
From my perspective - I am ok to spend few extra cycles to avoid building separate binary.
Again, I guess that  with global switch the impact will be negligible. 
But anyway, it will require even more changes and another ABI breakage (as stats should always be included),
so it definitely out of scope for this release. 

> > For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the
> performance by striving for a higher number of objects per burst in every pipeline stage.
> >
> >> Konstantin


^ permalink raw reply	[relevance 4%]

* Re: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
  2022-11-09  5:03  4%           ` Morten Brørup
@ 2022-11-09  8:21  0%             ` Mattias Rönnblom
  2022-11-09 10:19  4%               ` Konstantin Ananyev
  0 siblings, 1 reply; 200+ results
From: Mattias Rönnblom @ 2022-11-09  8:21 UTC (permalink / raw)
  To: Morten Brørup, Konstantin Ananyev, Bruce Richardson,
	Thomas Monjalon
  Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
	stephen, jerinj

On 2022-11-09 06:03, Morten Brørup wrote:
>> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
>> Sent: Tuesday, 8 November 2022 18.38
>>>
>>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
>>>> 08/11/2022 15:30, Morten Brørup:
>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>> 08/11/2022 12:25, Morten Brørup:
>>>>>>> From: Morten Brørup
>>>>>>>> From: Konstantin Ananyev
>> [mailto:konstantin.ananyev@huawei.com]
>>>>>>>> Sent: Tuesday, 8 November 2022 10.20
>>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
>>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
>> (cache)-
>>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
>>>>>>>>
>>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
>>>>>> (n))
>>>>>>>> Apart from that, LGTM.
>>>>>>>> Series-Acked-by: Konstantin Ananyev
>> <konstantin.ananyev@huawei.com>
>>>>>>>
>>>>>>> @Thomas, this series should be ready to apply... it now has
>> been:
>>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
>>>>>> <andrew.rybchenko@oktetlabs.ru>
>>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
>>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>>>>>>
>>>>>> Being acked does not mean it is good to apply in -rc3.
>>>>>
>>>>> I understand that the RFC/v1 of this series was formally too late
>> to make it in 22.11, so I will not complain loudly if you choose to
>>> omit it for 22.11.
>>>>>
>>>>> With two independent reviews, including from a mempool
>> maintainer, I still have some hope. Also considering the risk
>> assessment
>>> below. ;-)
>>>>>
>>>>>> Please tell what is the benefit for 22.11 (before/after and
>> condition).
>>>>>
>>>>> Short version: With this series, mempool statistics can be used
>> in production. Without it, the performance cost
>>> (mempool_perf_autotest: -74 %) is prohibitive!
>>>>>
>>>>> Long version:
>>>>>
>>>>> The patch series provides significantly higher performance for
>> mempool statistics, which are readable through
>>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
>>>>>
>>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
>> build time to get mempool statistics.
>>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
>> after each mempool object, which are all verified on
>>> get/put from the mempool. According to mempool_perf_autotest, the
>> performance cost of mempool statistics (by setting
>>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
>> mempools with cache (i.e. mbuf pools). Prohibitive for use in
>>> production!
>>>>>
>>>>> With this series, the performance cost of mempool statistics (by
>> setting RTE_LIBRTE_MEMPOOL_STATS) in
>>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
>> used in production.
>>>>>
>>>>>> Note there is a real risk doing such change that late.
>>>>>
>>>>> Risk assessment:
>>>>>
>>>>> The patch series has zero effect unless either
>> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
>>> building. They are not set in the default build.
>>>>
>>>> If theses build flags are not set, there is no risk and no benefit.
>>>> But if they are set, there is a risk of regression,
>>>> for the benefit of an increased performance of a debug feature.
>>>> I would say it is better to avoid any functional regression in a
>> debug feature
>>>> at this stage.
>>>> Any other opinion?
>>>>
>>> While I agree that we should avoid any functional regression, I
>> wonder how
>>> widely used the debug feature is, and how big the risk of a
>> regression is?
>>> Even if there is one, having a regression in a debug feature is a lot
>> less
>>> serious than having one in something which goes into production.
>>>
>>
>> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
>> wait till 23.03.
>> Just in case.
> 
> If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS, which is introduced by the series), there is no ABI breakage.
> 
> If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from rte_mempool_dump() does not include the statistics.
> 
> If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.
> 
>> BTW, as a side thought - if the impact is really that small now, would
>> it make sense to make
>> it run-time option, instead of compile-time one?
> 
> The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool structure, only the mempool cache structure).
> 

It's not totally obvious that a conditional is better than just always 
performing these simple arithmetic operations, even if you don't know if 
you need the result (i.e., if stats is enabled or not), especially since 
they operate on a cache line that is very likely already owned by the 
core running the core (since the 'len' fields is frequently used).

> Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or could have been avoided.)
> 
> In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?
> 
> For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the performance by striving for a higher number of objects per burst in every pipeline stage.
> 
>> Konstantin


^ permalink raw reply	[relevance 0%]

* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
  2022-11-08 17:38  3%         ` Konstantin Ananyev
@ 2022-11-09  5:03  4%           ` Morten Brørup
  2022-11-09  8:21  0%             ` Mattias Rönnblom
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-11-09  5:03 UTC (permalink / raw)
  To: Konstantin Ananyev, Bruce Richardson, Thomas Monjalon
  Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
	mattias.ronnblom, stephen, jerinj

> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Tuesday, 8 November 2022 18.38
> >
> > On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > > 08/11/2022 15:30, Morten Brørup:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 08/11/2022 12:25, Morten Brørup:
> > > > > > From: Morten Brørup
> > > > > > > From: Konstantin Ananyev
> [mailto:konstantin.ananyev@huawei.com]
> > > > > > > Sent: Tuesday, 8 November 2022 10.20
> > > > > > > > +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > > > > > > > +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> (cache)-
> > > > > >stats.name += n
> > > > > > >
> > > > > > > As Andrew already pointed, it needs to be: ((cache)-
> >stats.name +=
> > > > > (n))
> > > > > > > Apart from that, LGTM.
> > > > > > > Series-Acked-by: Konstantin Ananyev
> <konstantin.ananyev@huawei.com>
> > > > > >
> > > > > > @Thomas, this series should be ready to apply... it now has
> been:
> > > > > > Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>
> > > > > > Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > > >
> > > > > Being acked does not mean it is good to apply in -rc3.
> > > >
> > > > I understand that the RFC/v1 of this series was formally too late
> to make it in 22.11, so I will not complain loudly if you choose to
> > omit it for 22.11.
> > > >
> > > > With two independent reviews, including from a mempool
> maintainer, I still have some hope. Also considering the risk
> assessment
> > below. ;-)
> > > >
> > > > > Please tell what is the benefit for 22.11 (before/after and
> condition).
> > > >
> > > > Short version: With this series, mempool statistics can be used
> in production. Without it, the performance cost
> > (mempool_perf_autotest: -74 %) is prohibitive!
> > > >
> > > > Long version:
> > > >
> > > > The patch series provides significantly higher performance for
> mempool statistics, which are readable through
> > rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > > >
> > > > Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
> build time to get mempool statistics.
> > RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
> after each mempool object, which are all verified on
> > get/put from the mempool. According to mempool_perf_autotest, the
> performance cost of mempool statistics (by setting
> > RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> > production!
> > > >
> > > > With this series, the performance cost of mempool statistics (by
> setting RTE_LIBRTE_MEMPOOL_STATS) in
> > mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> used in production.
> > > >
> > > > > Note there is a real risk doing such change that late.
> > > >
> > > > Risk assessment:
> > > >
> > > > The patch series has zero effect unless either
> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> > building. They are not set in the default build.
> > >
> > > If theses build flags are not set, there is no risk and no benefit.
> > > But if they are set, there is a risk of regression,
> > > for the benefit of an increased performance of a debug feature.
> > > I would say it is better to avoid any functional regression in a
> debug feature
> > > at this stage.
> > > Any other opinion?
> > >
> > While I agree that we should avoid any functional regression, I
> wonder how
> > widely used the debug feature is, and how big the risk of a
> regression is?
> > Even if there is one, having a regression in a debug feature is a lot
> less
> > serious than having one in something which goes into production.
> >
> 
> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
> wait till 23.03.
> Just in case.

If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS, which is introduced by the series), there is no ABI breakage.

If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from rte_mempool_dump() does not include the statistics.

If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.

> BTW, as a side thought - if the impact is really that small now, would
> it make sense to make
> it run-time option, instead of compile-time one?

The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool structure, only the mempool cache structure).

Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or could have been avoided.)

In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?

For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the performance by striving for a higher number of objects per burst in every pipeline stage.

> Konstantin

^ permalink raw reply	[relevance 4%]

* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
  @ 2022-11-08 17:38  3%         ` Konstantin Ananyev
  2022-11-09  5:03  4%           ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-08 17:38 UTC (permalink / raw)
  To: Bruce Richardson, Thomas Monjalon
  Cc: Morten Brørup, andrew.rybchenko, olivier.matz,
	david.marchand, dev, hofors, mattias.ronnblom, stephen, jerinj


> 
> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > 08/11/2022 15:30, Morten Brørup:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 08/11/2022 12:25, Morten Brørup:
> > > > > From: Morten Brørup
> > > > > > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > > > > > Sent: Tuesday, 8 November 2022 10.20
> > > > > > > +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > > > > > > +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n) (cache)-
> > > > >stats.name += n
> > > > > >
> > > > > > As Andrew already pointed, it needs to be: ((cache)->stats.name +=
> > > > (n))
> > > > > > Apart from that, LGTM.
> > > > > > Series-Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > > >
> > > > > @Thomas, this series should be ready to apply... it now has been:
> > > > > Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>
> > > > > Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > >
> > > > Being acked does not mean it is good to apply in -rc3.
> > >
> > > I understand that the RFC/v1 of this series was formally too late to make it in 22.11, so I will not complain loudly if you choose to
> omit it for 22.11.
> > >
> > > With two independent reviews, including from a mempool maintainer, I still have some hope. Also considering the risk assessment
> below. ;-)
> > >
> > > > Please tell what is the benefit for 22.11 (before/after and condition).
> > >
> > > Short version: With this series, mempool statistics can be used in production. Without it, the performance cost
> (mempool_perf_autotest: -74 %) is prohibitive!
> > >
> > > Long version:
> > >
> > > The patch series provides significantly higher performance for mempool statistics, which are readable through
> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > >
> > > Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at build time to get mempool statistics.
> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and after each mempool object, which are all verified on
> get/put from the mempool. According to mempool_perf_autotest, the performance cost of mempool statistics (by setting
> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for mempools with cache (i.e. mbuf pools). Prohibitive for use in
> production!
> > >
> > > With this series, the performance cost of mempool statistics (by setting RTE_LIBRTE_MEMPOOL_STATS) in
> mempool_perf_autotest is only 6.7 %, so mempool statistics can be used in production.
> > >
> > > > Note there is a real risk doing such change that late.
> > >
> > > Risk assessment:
> > >
> > > The patch series has zero effect unless either RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> building. They are not set in the default build.
> >
> > If theses build flags are not set, there is no risk and no benefit.
> > But if they are set, there is a risk of regression,
> > for the benefit of an increased performance of a debug feature.
> > I would say it is better to avoid any functional regression in a debug feature
> > at this stage.
> > Any other opinion?
> >
> While I agree that we should avoid any functional regression, I wonder how
> widely used the debug feature is, and how big the risk of a regression is?
> Even if there is one, having a regression in a debug feature is a lot less
> serious than having one in something which goes into production.
> 

Unless it introduces an ABI breakage (as I understand it doesn't), I'll wait till 23.03.
Just in case.
BTW, as a side thought - if the impact is really that small now, would it make sense to make
it run-time option, instead of compile-time one?
Konstantin

^ permalink raw reply	[relevance 3%]

* [PATCH 2/2] devtools: stop depending on libabigail xml format
  2022-11-03 15:47  9% [PATCH 0/2] ABI check updates David Marchand
  2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
@ 2022-11-03 15:47 41% ` David Marchand
  1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
  To: dev; +Cc: thomas, ci, Aaron Conole, Michael Santana, Bruce Richardson

A ABI reference depends on:
- DPDK build options,
- toolchain compiler and versions,
- libabigail version.

The reason for the latter point is that, when the ABI reference was
generated, ABI xml files were dumped in a format depending on the
libabigail version.
Those xml files were then later used to compare against modified
code.

There are a few disadvantages with this method:
- since the xml files are dependent on the libabigail version, when
  updating CI environments, a change in the libabigail package requires
  regenerating the ABI references,
- comparing xml files with abidiff is not well tested, as we (DPDK)
  uncovered bugs in libabigail that were not hit with comparing .so,

Switch to comparing .so directly, remove this dependence and update GHA
script.

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 .ci/linux-build.sh            |  4 ----
 .github/workflows/build.yml   |  2 +-
 MAINTAINERS                   |  1 -
 devtools/check-abi.sh         | 15 ++++++++-------
 devtools/gen-abi.sh           | 26 --------------------------
 devtools/test-meson-builds.sh |  5 -----
 6 files changed, 9 insertions(+), 44 deletions(-)
 delete mode 100755 devtools/gen-abi.sh

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index baec65a914..ce91b0af04 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -143,8 +143,6 @@ fi
 if [ "$ABI_CHECKS" = "true" ]; then
     if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
         rm -rf libabigail
-        # if we change libabigail, invalidate existing abi cache
-        rm -rf reference
     fi
 
     if [ ! -d libabigail ]; then
@@ -166,7 +164,6 @@ if [ "$ABI_CHECKS" = "true" ]; then
         meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
         ninja -C $refsrcdir/build
         DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
-        devtools/gen-abi.sh reference
         find reference/usr/local -name '*.a' -delete
         rm -rf reference/usr/local/bin
         rm -rf reference/usr/local/share
@@ -174,7 +171,6 @@ if [ "$ABI_CHECKS" = "true" ]; then
     fi
 
     DESTDIR=$(pwd)/install ninja -C build install
-    devtools/gen-abi.sh install
     devtools/check-abi.sh reference install ${ABI_CHECKS_WARN_ONLY:-}
 fi
 
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index a595c12354..b23f8805cb 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -71,7 +71,7 @@ jobs:
         echo -n '::set-output name=libabigail::'
         echo 'libabigail-${{ matrix.config.os }}'
         echo -n '::set-output name=abi::'
-        echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+        echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.REF_GIT_TAG }}'
     - name: Retrieve ccache cache
       uses: actions/cache@v2
       with:
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c9922123e..9bafec37e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,7 +90,6 @@ F: devtools/check-spdx-tag.sh
 F: devtools/check-symbol-change.sh
 F: devtools/check-symbol-maps.sh
 F: devtools/checkpatches.sh
-F: devtools/gen-abi.sh
 F: devtools/get-maintainer.sh
 F: devtools/git-log-fixes.sh
 F: devtools/load-devel-config
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index b1bf633f2a..078de43629 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -35,21 +35,22 @@ else
 fi
 
 error=
-for dump in $(find $refdir -name "*.dump"); do
-	name=$(basename $dump)
-	if grep -q "; SKIP_LIBRARY=${name%.dump}\>" $(dirname $0)/libabigail.abignore; then
+for lib in $(find $refdir -name "*.so.*" -a ! -type l); do
+	name=$(basename $lib)
+	if grep -q "; SKIP_LIBRARY=${name%.so.*}\>" $(dirname $0)/libabigail.abignore; then
 		echo "Skipped $name" >&2
 		continue
 	fi
-	dump2=$(find $newdir -name $name)
-	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
+	# Look for a library with the same major ABI version
+	lib2=$(find $newdir -name "${name%.*}.*" -a ! -type l)
+	if [ -z "$lib2" ] || [ ! -e "$lib2" ]; then
 		echo "Error: cannot find $name in $newdir" >&2
 		error=1
 		continue
 	fi
-	abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
+	abidiff $ABIDIFF_OPTIONS $lib $lib2 || {
 		abiret=$?
-		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
+		echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $lib $lib2'" >&2
 		error=1
 		echo
 		if [ $(($abiret & 3)) -ne 0 ]; then
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
deleted file mode 100755
index f15a3b9aaf..0000000000
--- a/devtools/gen-abi.sh
+++ /dev/null
@@ -1,26 +0,0 @@
-#!/bin/sh -e
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright (c) 2019 Red Hat, Inc.
-
-if [ $# != 1 ]; then
-	echo "Usage: $0 installdir" >&2
-	exit 1
-fi
-
-installdir=$1
-if [ ! -d $installdir ]; then
-	echo "Error: install directory '$installdir' does not exist." >&2
-	exit 1
-fi
-
-dumpdir=$installdir/dump
-rm -rf $dumpdir
-mkdir -p $dumpdir
-for f in $(find $installdir -name "*.so.*"); do
-	if test -L $f; then
-		continue
-	fi
-
-	libname=$(basename $f)
-	abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 3a308bc9af..971650e621 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -188,7 +188,6 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
 				-Dexamples= $*
 			compile $abirefdir/build
 			install_target $abirefdir/build $abirefdir/$targetdir
-			$srcdir/devtools/gen-abi.sh $abirefdir/$targetdir
 
 			# save disk space by removing static libs and apps
 			find $abirefdir/$targetdir/usr/local -name '*.a' -delete
@@ -199,10 +198,6 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
 		install_target $builds_dir/$targetdir \
 			$(readlink -f $builds_dir/$targetdir/install)
 		echo "Checking ABI compatibility of $targetdir" >&$verbose
-		echo $srcdir/devtools/gen-abi.sh \
-			$(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
-		$srcdir/devtools/gen-abi.sh \
-			$(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
 		echo $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
 			$(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
 		$srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
-- 
2.38.1


^ permalink raw reply	[relevance 41%]

* [PATCH 1/2] devtools: unify configuration for ABI check
  2022-11-03 15:47  9% [PATCH 0/2] ABI check updates David Marchand
@ 2022-11-03 15:47 21% ` David Marchand
  2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
  1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
  To: dev; +Cc: thomas, ci

We have been skipping removed libraries in the ABI check by updating the
check-abi.sh script itself.
See, for example, commit 33584c19ddc2 ("raw/dpaa2_qdma: remove driver").

Having two places for exception is a bit confusing, and those exceptions
are best placed in a single configuration file out of the check script.

Besides, a next patch will switch the check from comparing ABI xml files
to directly comparing .so files. In this mode, libabigail does not
support the soname_regexp syntax used for the mlx glue libraries.

Let's handle these special cases in libabigail.abignore using comments.

Taking the raw/dpaa2_qdma driver as an example, it would be possible to
skip it by adding:

 ; SKIP_LIBRARY=librte_net_mlx4_glue
+; SKIP_LIBRARY=librte_raw_dpaa2_qdma

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 devtools/check-abi.sh        |  4 ++++
 devtools/libabigail.abignore | 12 +++++++++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..b1bf633f2a 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -37,6 +37,10 @@ fi
 error=
 for dump in $(find $refdir -name "*.dump"); do
 	name=$(basename $dump)
+	if grep -q "; SKIP_LIBRARY=${name%.dump}\>" $(dirname $0)/libabigail.abignore; then
+		echo "Skipped $name" >&2
+		continue
+	fi
 	dump2=$(find $newdir -name $name)
 	if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
 		echo "Error: cannot find $name in $newdir" >&2
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..3ff51509de 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -16,9 +16,15 @@
 [suppress_variable]
         name_regexp = _pmd_info$
 
-; Ignore changes on soname for mlx glue internal drivers
-[suppress_file]
-        soname_regexp = ^librte_.*mlx.*glue\.
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+; Special rules to skip libraries ;
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;
+; This is not a libabigail rule (see check-abi.sh).
+; This is used for driver removal and other special cases like mlx glue libs.
+;
+; SKIP_LIBRARY=librte_common_mlx5_glue
+; SKIP_LIBRARY=librte_net_mlx4_glue
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ; Experimental APIs exceptions ;
-- 
2.38.1


^ permalink raw reply	[relevance 21%]

* [PATCH 0/2] ABI check updates
@ 2022-11-03 15:47  9% David Marchand
  2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
  2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
  0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
  To: dev; +Cc: thomas, ci

This series moves ABI exceptions in a single configuration file and
simplifies the ABI check so that no artefact depending on libabigail
version is stored in the CI.

-- 
David Marchand

David Marchand (2):
  devtools: unify configuration for ABI check
  devtools: stop depending on libabigail xml format

 .ci/linux-build.sh            |  4 ----
 .github/workflows/build.yml   |  2 +-
 MAINTAINERS                   |  1 -
 devtools/check-abi.sh         | 17 +++++++++++------
 devtools/gen-abi.sh           | 26 --------------------------
 devtools/libabigail.abignore  | 12 +++++++++---
 devtools/test-meson-builds.sh |  5 -----
 7 files changed, 21 insertions(+), 46 deletions(-)
 delete mode 100755 devtools/gen-abi.sh

-- 
2.38.1


^ permalink raw reply	[relevance 9%]

* Re: [PATCH v2 3/3] mempool: use cache for frequently updated statistics
  2022-11-02  9:29  4%       ` Morten Brørup
@ 2022-11-02 17:55  0%         ` Mattias Rönnblom
  0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-11-02 17:55 UTC (permalink / raw)
  To: Morten Brørup, olivier.matz, andrew.rybchenko, stephen,
	jerinj, bruce.richardson, thomas
  Cc: dev

On 2022-11-02 10:29, Morten Brørup wrote:
>> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
>> Sent: Wednesday, 2 November 2022 09.01
>>
>> On 2022-10-31 12:26, Morten Brørup wrote:
> 
> [...]
> 
>>> +++ b/lib/mempool/rte_mempool.h
>>> @@ -86,6 +86,21 @@ struct rte_mempool_cache {
>>>    	uint32_t size;	      /**< Size of the cache */
>>>    	uint32_t flushthresh; /**< Threshold before we flush excess
>> elements */
>>>    	uint32_t len;	      /**< Current cache count */
>>> +	uint32_t unused0;
>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
>>> +	/*
>>> +	 * Alternative location for the most frequently updated mempool
>> statistics (per-lcore),
>>> +	 * providing faster update access when using a mempool cache.
>>> +	 */
>>> +	struct {
>>> +		uint64_t put_bulk;          /**< Number of puts. */
>>> +		uint64_t put_objs;          /**< Number of objects
>> successfully put. */
>>> +		uint64_t get_success_bulk;  /**< Successful allocation
>> number. */
>>> +		uint64_t get_success_objs;  /**< Objects successfully
>> allocated. */
>>> +	} stats;                        /**< Statistics */
>>> +#else
>>> +	uint64_t unused1[4];
>>
>> Are a particular DPDK version supposed to be ABI compatible with
>> itself,
>> with different configuration options? E.g., with and without
>> RTE_LIBRTE_MEMPOOL_STATS. Is that why you have those 4 unused
>> uint64_ts?
> 
> Valid point: There was no ABI compatibility between with and without RTE_LIBRTE_MEMPOOL_STATS before this patch, so there is no need to add partial ABI compatibility here.
> 
> The #else part of this structure should be removed.
> 
> Does anyone disagree?
> 
>>> +#endif
> 

I have no opinion on that matter, but I have another question: if you 
remove 'unused1', should you also remove the unused0 field?

^ permalink raw reply	[relevance 0%]

* RE: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
  2022-11-02 12:13  4%     ` David Marchand
@ 2022-11-02 12:31  0%       ` Akhil Goyal
  0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-11-02 12:31 UTC (permalink / raw)
  To: David Marchand
  Cc: Kevin Traynor, Volodymyr Fialko, dev, Ravi Kumar, Ali Alnubani,
	Jerin Jacob Kollanukkaran, Anoob Joseph, Thomas Monjalon

> Subject: Re: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
> 
> On Wed, Nov 2, 2022 at 11:58 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > This is being flagged as an ABI break for 21.11.3 [1]. I don't see it
> > > mentioned in the commit message or discussed, is it ok for main branch?
> >
> > Ok, we can keep it to main only.
> > But it will be an issue on 21.11.
> >
> > >
> > > Thanks to Ali for reporting. I will revert on 21.11 branch.
> > >
> > > [1]
> > > 1 Changed variable:
> > >
> > >    [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at
> > > rte_crypto_sym.h:372:1:
> > >      size of symbol changed from 168 to 232
> 
> My two cents.
> 
> We have a algo "string to num" helper (rte_cryptodev_get_auth_algo_enum).
> 
> This code is not performance sensitive, is it?
> If we add the, opposite, "num to string" helper, we can hide the
> rte_crypto_auth_algorithm_strings symbol from the public ABI and avoid
> this kind of issues in the future.
> 
> And looking at lib/crypto map, there are other arrays (*_strings
> symbols) that are subject to similar "extending" issues.
> 
> We are late in the release for adding new API though such helpers
> would be really simple.
> Hiding such symbols is something to consider before entering ABI freeze.
> 
Agreed, but it is quite late for this cycle.
We can plan these helper APIs for next release cycle and remove these symbols in 23.11.

^ permalink raw reply	[relevance 0%]

* Re: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
  2022-11-02 10:58  0%   ` [EXT] " Akhil Goyal
@ 2022-11-02 12:13  4%     ` David Marchand
  2022-11-02 12:31  0%       ` Akhil Goyal
  0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-02 12:13 UTC (permalink / raw)
  To: Akhil Goyal
  Cc: Kevin Traynor, Volodymyr Fialko, dev, Ravi Kumar, Ali Alnubani,
	Jerin Jacob Kollanukkaran, Anoob Joseph, Thomas Monjalon

On Wed, Nov 2, 2022 at 11:58 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > This is being flagged as an ABI break for 21.11.3 [1]. I don't see it
> > mentioned in the commit message or discussed, is it ok for main branch?
>
> Ok, we can keep it to main only.
> But it will be an issue on 21.11.
>
> >
> > Thanks to Ali for reporting. I will revert on 21.11 branch.
> >
> > [1]
> > 1 Changed variable:
> >
> >    [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at
> > rte_crypto_sym.h:372:1:
> >      size of symbol changed from 168 to 232

My two cents.

We have a algo "string to num" helper (rte_cryptodev_get_auth_algo_enum).

This code is not performance sensitive, is it?
If we add the, opposite, "num to string" helper, we can hide the
rte_crypto_auth_algorithm_strings symbol from the public ABI and avoid
this kind of issues in the future.

And looking at lib/crypto map, there are other arrays (*_strings
symbols) that are subject to similar "extending" issues.

We are late in the release for adding new API though such helpers
would be really simple.
Hiding such symbols is something to consider before entering ABI freeze.

-- 
David Marchand

^ permalink raw reply	[relevance 4%]

* RE: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
  2022-11-02 10:50  4% ` Kevin Traynor
@ 2022-11-02 10:58  0%   ` Akhil Goyal
  2022-11-02 12:13  4%     ` David Marchand
  0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-11-02 10:58 UTC (permalink / raw)
  To: Kevin Traynor, Volodymyr Fialko, dev, Fan Zhang, Ravi Kumar,
	Ali Alnubani
  Cc: Jerin Jacob Kollanukkaran, Anoob Joseph

> On 15/09/2022 09:26, Volodymyr Fialko wrote:
> > SHA3 family algorithms were missing in the array of algorithm strings.
> >
> > Fixes: 1df800f89518 ("crypto/ccp: support SHA3 family")
> >
> > Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> > ---
> >   lib/cryptodev/rte_cryptodev.c | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> >
> > diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> > index 42f3221052..35661f5347 100644
> > --- a/lib/cryptodev/rte_cryptodev.c
> > +++ b/lib/cryptodev/rte_cryptodev.c
> > @@ -130,6 +130,15 @@ rte_crypto_auth_algorithm_strings[] = {
> >   	[RTE_CRYPTO_AUTH_SHA512]	= "sha2-512",
> >   	[RTE_CRYPTO_AUTH_SHA512_HMAC]	= "sha2-512-hmac",
> >
> > +	[RTE_CRYPTO_AUTH_SHA3_224]	= "sha3-224",
> > +	[RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
> > +	[RTE_CRYPTO_AUTH_SHA3_256]	= "sha3-256",
> > +	[RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
> > +	[RTE_CRYPTO_AUTH_SHA3_384]	= "sha3-384",
> > +	[RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
> > +	[RTE_CRYPTO_AUTH_SHA3_512]	= "sha3-512",
> > +	[RTE_CRYPTO_AUTH_SHA3_512_HMAC]	= "sha3-512-hmac",
> > +
> >   	[RTE_CRYPTO_AUTH_KASUMI_F9]	= "kasumi-f9",
> >   	[RTE_CRYPTO_AUTH_SNOW3G_UIA2]	= "snow3g-uia2",
> >   	[RTE_CRYPTO_AUTH_ZUC_EIA3]	= "zuc-eia3"
> 
> This is being flagged as an ABI break for 21.11.3 [1]. I don't see it
> mentioned in the commit message or discussed, is it ok for main branch?

Ok, we can keep it to main only.
But it will be an issue on 21.11. 

> 
> Thanks to Ali for reporting. I will revert on 21.11 branch.
> 
> [1]
> 1 Changed variable:
> 
>    [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at
> rte_crypto_sym.h:372:1:
>      size of symbol changed from 168 to 232
> 
> Error: ABI issue reported for 'abidiff --suppr
> dpdk/devtools/libabigail.abignore --no-added-syms --headers-dir1
> /opt/dpdklab/abi_references/v21.11/armgigabyteref/include --headers-dir2
> build_install/include
> /opt/dpdklab/abi_references/v21.11/armgigabyteref/dump/librte_cryptodev.du
> mp
> build_install/dump/librte_cryptodev.dump'


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] cryptodev: add missing algorithm strings
  @ 2022-11-02 10:50  4% ` Kevin Traynor
  2022-11-02 10:58  0%   ` [EXT] " Akhil Goyal
  0 siblings, 1 reply; 200+ results
From: Kevin Traynor @ 2022-11-02 10:50 UTC (permalink / raw)
  To: Volodymyr Fialko, dev, Akhil Goyal, Fan Zhang, Ravi Kumar, Ali Alnubani
  Cc: jerinj, anoobj

On 15/09/2022 09:26, Volodymyr Fialko wrote:
> SHA3 family algorithms were missing in the array of algorithm strings.
> 
> Fixes: 1df800f89518 ("crypto/ccp: support SHA3 family")
> 
> Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
> ---
>   lib/cryptodev/rte_cryptodev.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index 42f3221052..35661f5347 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -130,6 +130,15 @@ rte_crypto_auth_algorithm_strings[] = {
>   	[RTE_CRYPTO_AUTH_SHA512]	= "sha2-512",
>   	[RTE_CRYPTO_AUTH_SHA512_HMAC]	= "sha2-512-hmac",
>   
> +	[RTE_CRYPTO_AUTH_SHA3_224]	= "sha3-224",
> +	[RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
> +	[RTE_CRYPTO_AUTH_SHA3_256]	= "sha3-256",
> +	[RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
> +	[RTE_CRYPTO_AUTH_SHA3_384]	= "sha3-384",
> +	[RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
> +	[RTE_CRYPTO_AUTH_SHA3_512]	= "sha3-512",
> +	[RTE_CRYPTO_AUTH_SHA3_512_HMAC]	= "sha3-512-hmac",
> +
>   	[RTE_CRYPTO_AUTH_KASUMI_F9]	= "kasumi-f9",
>   	[RTE_CRYPTO_AUTH_SNOW3G_UIA2]	= "snow3g-uia2",
>   	[RTE_CRYPTO_AUTH_ZUC_EIA3]	= "zuc-eia3"

This is being flagged as an ABI break for 21.11.3 [1]. I don't see it 
mentioned in the commit message or discussed, is it ok for main branch?

Thanks to Ali for reporting. I will revert on 21.11 branch.

[1]
1 Changed variable:

   [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at 
rte_crypto_sym.h:372:1:
     size of symbol changed from 168 to 232

Error: ABI issue reported for 'abidiff --suppr 
dpdk/devtools/libabigail.abignore --no-added-syms --headers-dir1 
/opt/dpdklab/abi_references/v21.11/armgigabyteref/include --headers-dir2 
build_install/include 
/opt/dpdklab/abi_references/v21.11/armgigabyteref/dump/librte_cryptodev.dump 
build_install/dump/librte_cryptodev.dump'


^ permalink raw reply	[relevance 4%]

* RE: [PATCH v2 3/3] mempool: use cache for frequently updated statistics
  2022-11-02  8:01  3%     ` Mattias Rönnblom
@ 2022-11-02  9:29  4%       ` Morten Brørup
  2022-11-02 17:55  0%         ` Mattias Rönnblom
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-11-02  9:29 UTC (permalink / raw)
  To: Mattias Rönnblom, olivier.matz, andrew.rybchenko, stephen,
	jerinj, bruce.richardson, thomas
  Cc: dev

> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
> Sent: Wednesday, 2 November 2022 09.01
> 
> On 2022-10-31 12:26, Morten Brørup wrote:

[...]

> > +++ b/lib/mempool/rte_mempool.h
> > @@ -86,6 +86,21 @@ struct rte_mempool_cache {
> >   	uint32_t size;	      /**< Size of the cache */
> >   	uint32_t flushthresh; /**< Threshold before we flush excess
> elements */
> >   	uint32_t len;	      /**< Current cache count */
> > +	uint32_t unused0;
> > +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > +	/*
> > +	 * Alternative location for the most frequently updated mempool
> statistics (per-lcore),
> > +	 * providing faster update access when using a mempool cache.
> > +	 */
> > +	struct {
> > +		uint64_t put_bulk;          /**< Number of puts. */
> > +		uint64_t put_objs;          /**< Number of objects
> successfully put. */
> > +		uint64_t get_success_bulk;  /**< Successful allocation
> number. */
> > +		uint64_t get_success_objs;  /**< Objects successfully
> allocated. */
> > +	} stats;                        /**< Statistics */
> > +#else
> > +	uint64_t unused1[4];
> 
> Are a particular DPDK version supposed to be ABI compatible with
> itself,
> with different configuration options? E.g., with and without
> RTE_LIBRTE_MEMPOOL_STATS. Is that why you have those 4 unused
> uint64_ts?

Valid point: There was no ABI compatibility between with and without RTE_LIBRTE_MEMPOOL_STATS before this patch, so there is no need to add partial ABI compatibility here.

The #else part of this structure should be removed.

Does anyone disagree?

> > +#endif


^ permalink raw reply	[relevance 4%]

* Re: [PATCH v2 3/3] mempool: use cache for frequently updated statistics
  @ 2022-11-02  8:01  3%     ` Mattias Rönnblom
  2022-11-02  9:29  4%       ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Mattias Rönnblom @ 2022-11-02  8:01 UTC (permalink / raw)
  To: Morten Brørup, olivier.matz, andrew.rybchenko, stephen,
	jerinj, bruce.richardson
  Cc: thomas, dev

On 2022-10-31 12:26, Morten Brørup wrote:
> When built with statistics enabled (RTE_LIBRTE_MEMPOOL_STATS defined), the
> performance of mempools with caches is improved as follows.
> 
> When accessing objects in the mempool, either the put_bulk and put_objs or
> the get_success_bulk and get_success_objs statistics counters are likely
> to be incremented.
> 
> By adding an alternative set of these counters to the mempool cache
> structure, accesing the dedicated statistics structure is avoided in the
> likely cases where these counters are incremented.
> 
> The trick here is that the cache line holding the mempool cache structure
> is accessed anyway, in order to access the 'len' or 'flushthresh' fields.
> Updating some statistics counters in the same cache line has lower
> performance cost than accessing the statistics counters in the dedicated
> statistics structure, which resides in another cache line.
> 
> mempool_perf_autotest with this patch shows the follwing change in
> rate_persec.
> 
> Compared to only spliting statistics from debug:
> +1.5 % and +14.4 %, respectively without and with cache.
> 
> Compared to not enabling mempool stats:
> -4.4 % and -9.9 %, respectively without and with cache.
> 
> v2:
> * Move the statistics counters into a stats structure.
> 
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>   lib/mempool/rte_mempool.c |  9 +++++
>   lib/mempool/rte_mempool.h | 73 ++++++++++++++++++++++++++++++++-------
>   2 files changed, 69 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
> index e6208125e0..a18e39af04 100644
> --- a/lib/mempool/rte_mempool.c
> +++ b/lib/mempool/rte_mempool.c
> @@ -1286,6 +1286,15 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp)
>   		sum.get_success_blks += mp->stats[lcore_id].get_success_blks;
>   		sum.get_fail_blks += mp->stats[lcore_id].get_fail_blks;
>   	}
> +	if (mp->cache_size != 0) {
> +		/* Add the statistics stored in the mempool caches. */
> +		for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> +			sum.put_bulk += mp->local_cache[lcore_id].stats.put_bulk;
> +			sum.put_objs += mp->local_cache[lcore_id].stats.put_objs;
> +			sum.get_success_bulk += mp->local_cache[lcore_id].stats.get_success_bulk;
> +			sum.get_success_objs += mp->local_cache[lcore_id].stats.get_success_objs;
> +		}
> +	}
>   	fprintf(f, "  stats:\n");
>   	fprintf(f, "    put_bulk=%"PRIu64"\n", sum.put_bulk);
>   	fprintf(f, "    put_objs=%"PRIu64"\n", sum.put_objs);
> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> index 16e7e62e3c..5806e75609 100644
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -86,6 +86,21 @@ struct rte_mempool_cache {
>   	uint32_t size;	      /**< Size of the cache */
>   	uint32_t flushthresh; /**< Threshold before we flush excess elements */
>   	uint32_t len;	      /**< Current cache count */
> +	uint32_t unused0;
> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> +	/*
> +	 * Alternative location for the most frequently updated mempool statistics (per-lcore),
> +	 * providing faster update access when using a mempool cache.
> +	 */
> +	struct {
> +		uint64_t put_bulk;          /**< Number of puts. */
> +		uint64_t put_objs;          /**< Number of objects successfully put. */
> +		uint64_t get_success_bulk;  /**< Successful allocation number. */
> +		uint64_t get_success_objs;  /**< Objects successfully allocated. */
> +	} stats;                        /**< Statistics */
> +#else
> +	uint64_t unused1[4];

Are a particular DPDK version supposed to be ABI compatible with itself, 
with different configuration options? E.g., with and without 
RTE_LIBRTE_MEMPOOL_STATS. Is that why you have those 4 unused uint64_ts?

> +#endif
>   	/**
>   	 * Cache objects
>   	 *
> @@ -296,14 +311,14 @@ struct rte_mempool {
>   	| RTE_MEMPOOL_F_NO_IOVA_CONTIG \
>   	)
>   /**
> - * @internal When debug is enabled, store some statistics.
> + * @internal When stats is enabled, store some statistics.
>    *
>    * @param mp
>    *   Pointer to the memory pool.
>    * @param name
>    *   Name of the statistics field to increment in the memory pool.
>    * @param n
> - *   Number to add to the object-oriented statistics.
> + *   Number to add to the statistics.
>    */
>   #ifdef RTE_LIBRTE_MEMPOOL_STATS
>   #define RTE_MEMPOOL_STAT_ADD(mp, name, n) do {                  \
> @@ -312,6 +327,23 @@ struct rte_mempool {
>   #else
>   #define RTE_MEMPOOL_STAT_ADD(mp, name, n) do {} while (0)
>   #endif
> +/**
> + * @internal When stats is enabled, store some statistics.
> + *
> + * @param cache
> + *   Pointer to the memory pool cache.
> + * @param name
> + *   Name of the statistics field to increment in the memory pool cache.
> + * @param n
> + *   Number to add to the statistics.
> + */
> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n) do { \
> +		(cache)->stats.name += n;               \
> +	} while (0)
> +#else
> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n) do {} while (0)

Somewhat unrelated comment: maybe <rte_common.h> should have a RTE_NOP 
macro.

> +#endif
>   
>   /**
>    * @internal Calculate the size of the mempool header.
> @@ -1327,13 +1359,17 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table,
>   {
>   	void **cache_objs;
>   
> +	/* No cache provided */
> +	if (unlikely(cache == NULL))
> +		goto driver_enqueue;
> +
>   	/* increment stat now, adding in mempool always success */
> -	RTE_MEMPOOL_STAT_ADD(mp, put_bulk, 1);
> -	RTE_MEMPOOL_STAT_ADD(mp, put_objs, n);
> +	RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> +	RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
>   
> -	/* No cache provided or the request itself is too big for the cache */
> -	if (unlikely(cache == NULL || n > cache->flushthresh))
> -		goto driver_enqueue;
> +	/* The request itself is too big for the cache */
> +	if (unlikely(n > cache->flushthresh))
> +		goto driver_enqueue_stats_incremented;
>   
>   	/*
>   	 * The cache follows the following algorithm:
> @@ -1358,6 +1394,12 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table,
>   
>   driver_enqueue:
>   
> +	/* increment stat now, adding in mempool always success */
> +	RTE_MEMPOOL_STAT_ADD(mp, put_bulk, 1);
> +	RTE_MEMPOOL_STAT_ADD(mp, put_objs, n);
> +
> +driver_enqueue_stats_incremented:
> +
>   	/* push objects to the backend */
>   	rte_mempool_ops_enqueue_bulk(mp, obj_table, n);
>   }
> @@ -1464,8 +1506,8 @@ rte_mempool_do_generic_get(struct rte_mempool *mp, void **obj_table,
>   	if (remaining == 0) {
>   		/* The entire request is satisfied from the cache. */
>   
> -		RTE_MEMPOOL_STAT_ADD(mp, get_success_bulk, 1);
> -		RTE_MEMPOOL_STAT_ADD(mp, get_success_objs, n);
> +		RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_bulk, 1);
> +		RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_objs, n);
>   
>   		return 0;
>   	}
> @@ -1494,8 +1536,8 @@ rte_mempool_do_generic_get(struct rte_mempool *mp, void **obj_table,
>   
>   	cache->len = cache->size;
>   
> -	RTE_MEMPOOL_STAT_ADD(mp, get_success_bulk, 1);
> -	RTE_MEMPOOL_STAT_ADD(mp, get_success_objs, n);
> +	RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_bulk, 1);
> +	RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_objs, n);
>   
>   	return 0;
>   
> @@ -1517,8 +1559,13 @@ rte_mempool_do_generic_get(struct rte_mempool *mp, void **obj_table,
>   		RTE_MEMPOOL_STAT_ADD(mp, get_fail_bulk, 1);
>   		RTE_MEMPOOL_STAT_ADD(mp, get_fail_objs, n);
>   	} else {
> -		RTE_MEMPOOL_STAT_ADD(mp, get_success_bulk, 1);
> -		RTE_MEMPOOL_STAT_ADD(mp, get_success_objs, n);
> +		if (likely(cache != NULL)) {
> +			RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_bulk, 1);
> +			RTE_MEMPOOL_CACHE_STAT_ADD(cache, get_success_objs, n);
> +		} else {
> +			RTE_MEMPOOL_STAT_ADD(mp, get_success_bulk, 1);
> +			RTE_MEMPOOL_STAT_ADD(mp, get_success_objs, n);
> +		}
>   	}
>   
>   	return ret;

^ permalink raw reply	[relevance 3%]

* Re: release candidate 22.11-rc1
    2022-10-13  5:28  0% ` Jiang, YuX
  2022-10-24 13:12  0% ` David Marchand
@ 2022-10-27 21:00  0% ` Thinh Tran
  2 siblings, 0 replies; 200+ results
From: Thinh Tran @ 2022-10-27 21:00 UTC (permalink / raw)
  To: Thomas Monjalon, dpdk-dev

Hello,

IBM - Power Systems
DPDK 22.11.0-rc1


* Basic PF on Mellanox: No new issues or regressions were seen.
* Performance: not tested.
* OS: RHEL 8.5  kernel: 4.18.0-348.el8.ppc64le
         with gcc version 8.5.0 20210514 (Red Hat 8.5.0-10)
       RHEL 9.0  kernel: 5.14.0-70.13.1.el9_0.ppc64le
         with gcc version 11.2.1 20220127 (Red Hat 11.2.1-9)

Systems tested:
  - IBM Power9 PowerNV 9006-22P
     NICs:
      - Mellanox Technologies MT28800 Family [ConnectX-5 Ex]
      - firmware version: 16.34.1002
      - MLNX_OFED_LINUX-5.7-1.0.2.1 (OFED-5.7-1.0.2)

  - LPARs on IBM Power10 CHRP IBM,9105-22A
     NICs:
     - Mellanox Technologies MT28800 Family [ConnectX-5 Ex]
     - firmware version: 16.34.1002
     - MLNX_OFED_LINUX-5.7-1.0.2.1 (OFED-5.7-1.0.2)

Regards,
Thinh Tran

On 10/10/2022 8:50 PM, Thomas Monjalon wrote:
> A new DPDK release candidate is ready for testing:
> 	https://git.dpdk.org/dpdk/tag/?id=v22.11-rc1
> 
> There are 737 new patches in this snapshot,
> including many API/ABI compatibility breakages.
> This release won't be ABI-compatible with previous ones.
> 
> Release notes:
> 	https://doc.dpdk.org/guides/rel_notes/release_22_11.html
> 
> Highlights of 22.11-rc1:
> 	- LoongArch build
> 	- Intel uncore frequency control
> 	- multiple mbuf pools per Rx queue
> 	- Rx buffer split based on protocol
> 	- hardware congestion management
> 	- hairpin memory configuration
> 	- Rx/Tx descriptor dump
> 	- flow API extensions
> 	- MACsec processing offload
> 	- ShangMi crypto algorithms
> 	- baseband FFT operations
> 	- eventdev Tx queue start/stop
> 	- eventdev crypto vectorization
> 	- NitroSketch membership
> 
> Some work is in progress to optimize the mempool cache.
> Some patches are part of -rc1, and more could be merged in -rc2.
> Please measure the performance of this release candidate,
> and check these mempool patches:
> 	https://patches.dpdk.org/project/dpdk/list/?series=25063
> 
> Please test and report issues on bugs.dpdk.org.
> 
> DPDK 22.11-rc2 is expected in two weeks.
> 
> Thank you everyone
> 
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] mempool: cache align mempool cache objects
  2022-10-27 12:11  0%         ` Morten Brørup
@ 2022-10-27 15:20  0%           ` Olivier Matz
  0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2022-10-27 15:20 UTC (permalink / raw)
  To: Morten Brørup
  Cc: andrew.rybchenko, jerinj, thomas, bruce.richardson, dev

On Thu, Oct 27, 2022 at 02:11:29PM +0200, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, 27 October 2022 13.43
> > 
> > On Thu, Oct 27, 2022 at 11:22:07AM +0200, Morten Brørup wrote:
> > > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > > Sent: Thursday, 27 October 2022 10.35
> > > >
> > > > Hi Morten,
> > > >
> > > > On Wed, Oct 26, 2022 at 04:44:36PM +0200, Morten Brørup wrote:
> > > > > Add __rte_cache_aligned to the objs array.
> > > > >
> > > > > It makes no difference in the general case, but if get/put
> > operations
> > > > are
> > > > > always 32 objects, it will reduce the number of memory (or last
> > level
> > > > > cache) accesses from five to four 64 B cache lines for every
> > get/put
> > > > > operation.
> > > > >
> > > > > For readability reasons, an example using 16 objects follows:
> > > > >
> > > > > Currently, with 16 objects (128B), we access to 3
> > > > > cache lines:
> > > > >
> > > > >       ┌────────┐
> > > > >       │len     │
> > > > > cache │********│---
> > > > > line0 │********│ ^
> > > > >       │********│ |
> > > > >       ├────────┤ | 16 objects
> > > > >       │********│ | 128B
> > > > > cache │********│ |
> > > > > line1 │********│ |
> > > > >       │********│ |
> > > > >       ├────────┤ |
> > > > >       │********│_v_
> > > > > cache │        │
> > > > > line2 │        │
> > > > >       │        │
> > > > >       └────────┘
> > > > >
> > > > > With the alignment, it is also 3 cache lines:
> > > > >
> > > > >       ┌────────┐
> > > > >       │len     │
> > > > > cache │        │
> > > > > line0 │        │
> > > > >       │        │
> > > > >       ├────────┤---
> > > > >       │********│ ^
> > > > > cache │********│ |
> > > > > line1 │********│ |
> > > > >       │********│ |
> > > > >       ├────────┤ | 16 objects
> > > > >       │********│ | 128B
> > > > > cache │********│ |
> > > > > line2 │********│ |
> > > > >       │********│ v
> > > > >       └────────┘---
> > > > >
> > > > > However, accessing the objects at the bottom of the mempool cache
> > is
> > > > a
> > > > > special case, where cache line0 is also used for objects.
> > > > >
> > > > > Consider the next burst (and any following bursts):
> > > > >
> > > > > Current:
> > > > >       ┌────────┐
> > > > >       │len     │
> > > > > cache │        │
> > > > > line0 │        │
> > > > >       │        │
> > > > >       ├────────┤
> > > > >       │        │
> > > > > cache │        │
> > > > > line1 │        │
> > > > >       │        │
> > > > >       ├────────┤
> > > > >       │        │
> > > > > cache │********│---
> > > > > line2 │********│ ^
> > > > >       │********│ |
> > > > >       ├────────┤ | 16 objects
> > > > >       │********│ | 128B
> > > > > cache │********│ |
> > > > > line3 │********│ |
> > > > >       │********│ |
> > > > >       ├────────┤ |
> > > > >       │********│_v_
> > > > > cache │        │
> > > > > line4 │        │
> > > > >       │        │
> > > > >       └────────┘
> > > > > 4 cache lines touched, incl. line0 for len.
> > > > >
> > > > > With the proposed alignment:
> > > > >       ┌────────┐
> > > > >       │len     │
> > > > > cache │        │
> > > > > line0 │        │
> > > > >       │        │
> > > > >       ├────────┤
> > > > >       │        │
> > > > > cache │        │
> > > > > line1 │        │
> > > > >       │        │
> > > > >       ├────────┤
> > > > >       │        │
> > > > > cache │        │
> > > > > line2 │        │
> > > > >       │        │
> > > > >       ├────────┤
> > > > >       │********│---
> > > > > cache │********│ ^
> > > > > line3 │********│ |
> > > > >       │********│ | 16 objects
> > > > >       ├────────┤ | 128B
> > > > >       │********│ |
> > > > > cache │********│ |
> > > > > line4 │********│ |
> > > > >       │********│_v_
> > > > >       └────────┘
> > > > > Only 3 cache lines touched, incl. line0 for len.
> > > >
> > > > I understand your logic, but are we sure that having an application
> > > > that
> > > > works with bulks of 32 means that the cache will stay aligned to 32
> > > > elements for the whole life of the application?
> > > >
> > > > In an application, the alignment of the cache can change if you
> > have
> > > > any of:
> > > > - software queues (reassembly for instance)
> > > > - packet duplication (bridge, multicast)
> > > > - locally generated packets (keepalive, control protocol)
> > > > - pipeline to other cores
> > > >
> > > > Even with testpmd, which work by bulk of 32, I can see that the
> > size
> > > > of the cache filling is not aligned to 32. Right after starting the
> > > > application, we already have this:
> > > >
> > > >   internal cache infos:
> > > >     cache_size=250
> > > >     cache_count[0]=231
> > > >
> > > > This is probably related to the hw rx rings size, number of queues,
> > > > number of ports.
> > > >
> > > > The "250" default value for cache size in testpmd is questionable,
> > but
> > > > with --mbcache=256, the behavior is similar.
> > > >
> > > > Also, when we transmit to a NIC, the mbufs are not returned
> > immediatly
> > > > to the pool, they may stay in the hw tx ring during some time,
> > which is
> > > > a driver decision.
> > > >
> > > > After processing traffic on cores 8 and 24 with this testpmd, I
> > get:
> > > >     cache_count[0]=231
> > > >     cache_count[8]=123
> > > >     cache_count[24]=122
> > > >
> > > > In my opinion, it is not realistic to think that the mempool cache
> > will
> > > > remain aligned to cachelines. In these conditions, it looks better
> > to
> > > > keep the structure packed to avoid wasting memory.
> > >
> > > I agree that is a special use case to only access the mempool cache
> > in
> > > bursts of 32 objects, so the accesses are always cache line
> > > aligned. (Generalized, the burst size must not be 32; a burst size
> > > that is a multiple of RTE_CACHE_LINE_SIZE/sizeof(void*), i.e. a burst
> > > size of 8 on a 64-bit architecture, will do.)
> > 
> > Is there a real situation where it happens to always have read/write
> > accesses per bulks of 32? From what I see in my quick test, it is not
> > the case, even with testpmd.
> > 
> > > Adding a hole of 52 byte per mempool cache is nothing, considering
> > > that the mempool cache already uses 8 KB (RTE_MEMPOOL_CACHE_MAX_SIZE
> > *
> > > 2 * sizeof(void*) = 1024 * 8 byte) for the objects.
> > >
> > > Also - assuming that memory allocations are cache line aligned - the
> > > 52 byte of unused memory cannot be used regardless if they are before
> > > or after the objects. Instead of having 52 B unused after the
> > objects,
> > > we might as well have a hole of 52 B unused before the objects. In
> > > other words: There is really no downside to this.
> > 
> > Correct, the memory waste argument to nack the patch is invalid.
> > 
> > > Jerin also presented a separate argument for moving the objects to
> > > another cache line than the len field: The risk for "load-after-store
> > > stall" when loading the len field after storing objects in cache
> > line0
> > > [1].
> > >
> > > [1]: http://inbox.dpdk.org/dev/CALBAE1P4zFYdLwoQukn5Q-V-
> > nTvc_UBWmWjhaV2uVBXQRytSSA@mail.gmail.com/
> > 
> > I'll be prudent on this justification without numbers. The case where
> > we
> > access to the objects of the first cache line (among several KB) is
> > maybe not that frequent.
> > 
> > > A new idea just popped into my head: The hot debug statistics
> > > counters (put_bulk, put_objs, get_success_bulk, get_success_objs)
> > > could be moved to this free space, reducing the need to touch another
> > > cache line for debug counters. I haven’t thought this idea through
> > > yet; it might conflict with Jerin's comment.
> > 
> > Yes, but since the stats are only enabled when RTE_LIBRTE_MEMPOOL_DEBUG
> > is set, it won't have any impact on non-debug builds.
> 
> Correct, but I do expect that it would reduce the performance cost of using RTE_LIBRTE_MEMPOOL_DEBUG. I'll provide such a patch shortly.
> 
> > 
> > 
> > Honnestly, I find it hard to convince myself that it is a real
> > optimization. I don't see any reason why it would be slower though. So
> > since we already broke the mempool cache struct ABI in a previous
> > commit, and since it won't consume more memory, I'm ok to include that
> > patch.
> 
> I don't know if there are any such applications now, and you are probably right that there are not. But this patch opens a road towards it.
> 
> Acked-by ?

Acked-by: Olivier Matz <olivier.matz@6wind.com>

Thanks Morten

> 
> > It would be great to have numbers to put some weight in the
> > balance.
> 
> Yes, it would also be great if drivers didn't copy-paste code from the mempool library, so the performance effect of modifications in the mempool library would be reflected in such tests.
> 
> > 
> > 
> > 
> > 
> > >
> > > >
> > > > Olivier
> > > >
> > > >
> > > > >
> > > > > Credits go to Olivier Matz for the nice ASCII graphics.
> > > > >
> > > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > ---
> > > > >  lib/mempool/rte_mempool.h | 6 ++++--
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/mempool/rte_mempool.h
> > b/lib/mempool/rte_mempool.h
> > > > > index 1f5707f46a..3725a72951 100644
> > > > > --- a/lib/mempool/rte_mempool.h
> > > > > +++ b/lib/mempool/rte_mempool.h
> > > > > @@ -86,11 +86,13 @@ struct rte_mempool_cache {
> > > > >  	uint32_t size;	      /**< Size of the cache */
> > > > >  	uint32_t flushthresh; /**< Threshold before we flush excess
> > > > elements */
> > > > >  	uint32_t len;	      /**< Current cache count */
> > > > > -	/*
> > > > > +	/**
> > > > > +	 * Cache objects
> > > > > +	 *
> > > > >  	 * Cache is allocated to this size to allow it to overflow
> > in
> > > > certain
> > > > >  	 * cases to avoid needless emptying of cache.
> > > > >  	 */
> > > > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache
> > objects */
> > > > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> > __rte_cache_aligned;
> > > > >  } __rte_cache_aligned;
> > > > >
> > > > >  /**
> > > > > --
> > > > > 2.17.1
> > > > >
> > >
> 

^ permalink raw reply	[relevance 0%]

* RE: [PATCH] mempool: cache align mempool cache objects
  2022-10-27 11:42  3%       ` Olivier Matz
@ 2022-10-27 12:11  0%         ` Morten Brørup
  2022-10-27 15:20  0%           ` Olivier Matz
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-10-27 12:11 UTC (permalink / raw)
  To: Olivier Matz; +Cc: andrew.rybchenko, jerinj, thomas, bruce.richardson, dev

> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, 27 October 2022 13.43
> 
> On Thu, Oct 27, 2022 at 11:22:07AM +0200, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Thursday, 27 October 2022 10.35
> > >
> > > Hi Morten,
> > >
> > > On Wed, Oct 26, 2022 at 04:44:36PM +0200, Morten Brørup wrote:
> > > > Add __rte_cache_aligned to the objs array.
> > > >
> > > > It makes no difference in the general case, but if get/put
> operations
> > > are
> > > > always 32 objects, it will reduce the number of memory (or last
> level
> > > > cache) accesses from five to four 64 B cache lines for every
> get/put
> > > > operation.
> > > >
> > > > For readability reasons, an example using 16 objects follows:
> > > >
> > > > Currently, with 16 objects (128B), we access to 3
> > > > cache lines:
> > > >
> > > >       ┌────────┐
> > > >       │len     │
> > > > cache │********│---
> > > > line0 │********│ ^
> > > >       │********│ |
> > > >       ├────────┤ | 16 objects
> > > >       │********│ | 128B
> > > > cache │********│ |
> > > > line1 │********│ |
> > > >       │********│ |
> > > >       ├────────┤ |
> > > >       │********│_v_
> > > > cache │        │
> > > > line2 │        │
> > > >       │        │
> > > >       └────────┘
> > > >
> > > > With the alignment, it is also 3 cache lines:
> > > >
> > > >       ┌────────┐
> > > >       │len     │
> > > > cache │        │
> > > > line0 │        │
> > > >       │        │
> > > >       ├────────┤---
> > > >       │********│ ^
> > > > cache │********│ |
> > > > line1 │********│ |
> > > >       │********│ |
> > > >       ├────────┤ | 16 objects
> > > >       │********│ | 128B
> > > > cache │********│ |
> > > > line2 │********│ |
> > > >       │********│ v
> > > >       └────────┘---
> > > >
> > > > However, accessing the objects at the bottom of the mempool cache
> is
> > > a
> > > > special case, where cache line0 is also used for objects.
> > > >
> > > > Consider the next burst (and any following bursts):
> > > >
> > > > Current:
> > > >       ┌────────┐
> > > >       │len     │
> > > > cache │        │
> > > > line0 │        │
> > > >       │        │
> > > >       ├────────┤
> > > >       │        │
> > > > cache │        │
> > > > line1 │        │
> > > >       │        │
> > > >       ├────────┤
> > > >       │        │
> > > > cache │********│---
> > > > line2 │********│ ^
> > > >       │********│ |
> > > >       ├────────┤ | 16 objects
> > > >       │********│ | 128B
> > > > cache │********│ |
> > > > line3 │********│ |
> > > >       │********│ |
> > > >       ├────────┤ |
> > > >       │********│_v_
> > > > cache │        │
> > > > line4 │        │
> > > >       │        │
> > > >       └────────┘
> > > > 4 cache lines touched, incl. line0 for len.
> > > >
> > > > With the proposed alignment:
> > > >       ┌────────┐
> > > >       │len     │
> > > > cache │        │
> > > > line0 │        │
> > > >       │        │
> > > >       ├────────┤
> > > >       │        │
> > > > cache │        │
> > > > line1 │        │
> > > >       │        │
> > > >       ├────────┤
> > > >       │        │
> > > > cache │        │
> > > > line2 │        │
> > > >       │        │
> > > >       ├────────┤
> > > >       │********│---
> > > > cache │********│ ^
> > > > line3 │********│ |
> > > >       │********│ | 16 objects
> > > >       ├────────┤ | 128B
> > > >       │********│ |
> > > > cache │********│ |
> > > > line4 │********│ |
> > > >       │********│_v_
> > > >       └────────┘
> > > > Only 3 cache lines touched, incl. line0 for len.
> > >
> > > I understand your logic, but are we sure that having an application
> > > that
> > > works with bulks of 32 means that the cache will stay aligned to 32
> > > elements for the whole life of the application?
> > >
> > > In an application, the alignment of the cache can change if you
> have
> > > any of:
> > > - software queues (reassembly for instance)
> > > - packet duplication (bridge, multicast)
> > > - locally generated packets (keepalive, control protocol)
> > > - pipeline to other cores
> > >
> > > Even with testpmd, which work by bulk of 32, I can see that the
> size
> > > of the cache filling is not aligned to 32. Right after starting the
> > > application, we already have this:
> > >
> > >   internal cache infos:
> > >     cache_size=250
> > >     cache_count[0]=231
> > >
> > > This is probably related to the hw rx rings size, number of queues,
> > > number of ports.
> > >
> > > The "250" default value for cache size in testpmd is questionable,
> but
> > > with --mbcache=256, the behavior is similar.
> > >
> > > Also, when we transmit to a NIC, the mbufs are not returned
> immediatly
> > > to the pool, they may stay in the hw tx ring during some time,
> which is
> > > a driver decision.
> > >
> > > After processing traffic on cores 8 and 24 with this testpmd, I
> get:
> > >     cache_count[0]=231
> > >     cache_count[8]=123
> > >     cache_count[24]=122
> > >
> > > In my opinion, it is not realistic to think that the mempool cache
> will
> > > remain aligned to cachelines. In these conditions, it looks better
> to
> > > keep the structure packed to avoid wasting memory.
> >
> > I agree that is a special use case to only access the mempool cache
> in
> > bursts of 32 objects, so the accesses are always cache line
> > aligned. (Generalized, the burst size must not be 32; a burst size
> > that is a multiple of RTE_CACHE_LINE_SIZE/sizeof(void*), i.e. a burst
> > size of 8 on a 64-bit architecture, will do.)
> 
> Is there a real situation where it happens to always have read/write
> accesses per bulks of 32? From what I see in my quick test, it is not
> the case, even with testpmd.
> 
> > Adding a hole of 52 byte per mempool cache is nothing, considering
> > that the mempool cache already uses 8 KB (RTE_MEMPOOL_CACHE_MAX_SIZE
> *
> > 2 * sizeof(void*) = 1024 * 8 byte) for the objects.
> >
> > Also - assuming that memory allocations are cache line aligned - the
> > 52 byte of unused memory cannot be used regardless if they are before
> > or after the objects. Instead of having 52 B unused after the
> objects,
> > we might as well have a hole of 52 B unused before the objects. In
> > other words: There is really no downside to this.
> 
> Correct, the memory waste argument to nack the patch is invalid.
> 
> > Jerin also presented a separate argument for moving the objects to
> > another cache line than the len field: The risk for "load-after-store
> > stall" when loading the len field after storing objects in cache
> line0
> > [1].
> >
> > [1]: http://inbox.dpdk.org/dev/CALBAE1P4zFYdLwoQukn5Q-V-
> nTvc_UBWmWjhaV2uVBXQRytSSA@mail.gmail.com/
> 
> I'll be prudent on this justification without numbers. The case where
> we
> access to the objects of the first cache line (among several KB) is
> maybe not that frequent.
> 
> > A new idea just popped into my head: The hot debug statistics
> > counters (put_bulk, put_objs, get_success_bulk, get_success_objs)
> > could be moved to this free space, reducing the need to touch another
> > cache line for debug counters. I haven’t thought this idea through
> > yet; it might conflict with Jerin's comment.
> 
> Yes, but since the stats are only enabled when RTE_LIBRTE_MEMPOOL_DEBUG
> is set, it won't have any impact on non-debug builds.

Correct, but I do expect that it would reduce the performance cost of using RTE_LIBRTE_MEMPOOL_DEBUG. I'll provide such a patch shortly.

> 
> 
> Honnestly, I find it hard to convince myself that it is a real
> optimization. I don't see any reason why it would be slower though. So
> since we already broke the mempool cache struct ABI in a previous
> commit, and since it won't consume more memory, I'm ok to include that
> patch.

I don't know if there are any such applications now, and you are probably right that there are not. But this patch opens a road towards it.

Acked-by ?

> It would be great to have numbers to put some weight in the
> balance.

Yes, it would also be great if drivers didn't copy-paste code from the mempool library, so the performance effect of modifications in the mempool library would be reflected in such tests.

> 
> 
> 
> 
> >
> > >
> > > Olivier
> > >
> > >
> > > >
> > > > Credits go to Olivier Matz for the nice ASCII graphics.
> > > >
> > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > > ---
> > > >  lib/mempool/rte_mempool.h | 6 ++++--
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/mempool/rte_mempool.h
> b/lib/mempool/rte_mempool.h
> > > > index 1f5707f46a..3725a72951 100644
> > > > --- a/lib/mempool/rte_mempool.h
> > > > +++ b/lib/mempool/rte_mempool.h
> > > > @@ -86,11 +86,13 @@ struct rte_mempool_cache {
> > > >  	uint32_t size;	      /**< Size of the cache */
> > > >  	uint32_t flushthresh; /**< Threshold before we flush excess
> > > elements */
> > > >  	uint32_t len;	      /**< Current cache count */
> > > > -	/*
> > > > +	/**
> > > > +	 * Cache objects
> > > > +	 *
> > > >  	 * Cache is allocated to this size to allow it to overflow
> in
> > > certain
> > > >  	 * cases to avoid needless emptying of cache.
> > > >  	 */
> > > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache
> objects */
> > > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> __rte_cache_aligned;
> > > >  } __rte_cache_aligned;
> > > >
> > > >  /**
> > > > --
> > > > 2.17.1
> > > >
> >


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] mempool: cache align mempool cache objects
  @ 2022-10-27 11:42  3%       ` Olivier Matz
  2022-10-27 12:11  0%         ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2022-10-27 11:42 UTC (permalink / raw)
  To: Morten Brørup
  Cc: andrew.rybchenko, jerinj, thomas, bruce.richardson, dev

On Thu, Oct 27, 2022 at 11:22:07AM +0200, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, 27 October 2022 10.35
> > 
> > Hi Morten,
> > 
> > On Wed, Oct 26, 2022 at 04:44:36PM +0200, Morten Brørup wrote:
> > > Add __rte_cache_aligned to the objs array.
> > >
> > > It makes no difference in the general case, but if get/put operations
> > are
> > > always 32 objects, it will reduce the number of memory (or last level
> > > cache) accesses from five to four 64 B cache lines for every get/put
> > > operation.
> > >
> > > For readability reasons, an example using 16 objects follows:
> > >
> > > Currently, with 16 objects (128B), we access to 3
> > > cache lines:
> > >
> > >       ┌────────┐
> > >       │len     │
> > > cache │********│---
> > > line0 │********│ ^
> > >       │********│ |
> > >       ├────────┤ | 16 objects
> > >       │********│ | 128B
> > > cache │********│ |
> > > line1 │********│ |
> > >       │********│ |
> > >       ├────────┤ |
> > >       │********│_v_
> > > cache │        │
> > > line2 │        │
> > >       │        │
> > >       └────────┘
> > >
> > > With the alignment, it is also 3 cache lines:
> > >
> > >       ┌────────┐
> > >       │len     │
> > > cache │        │
> > > line0 │        │
> > >       │        │
> > >       ├────────┤---
> > >       │********│ ^
> > > cache │********│ |
> > > line1 │********│ |
> > >       │********│ |
> > >       ├────────┤ | 16 objects
> > >       │********│ | 128B
> > > cache │********│ |
> > > line2 │********│ |
> > >       │********│ v
> > >       └────────┘---
> > >
> > > However, accessing the objects at the bottom of the mempool cache is
> > a
> > > special case, where cache line0 is also used for objects.
> > >
> > > Consider the next burst (and any following bursts):
> > >
> > > Current:
> > >       ┌────────┐
> > >       │len     │
> > > cache │        │
> > > line0 │        │
> > >       │        │
> > >       ├────────┤
> > >       │        │
> > > cache │        │
> > > line1 │        │
> > >       │        │
> > >       ├────────┤
> > >       │        │
> > > cache │********│---
> > > line2 │********│ ^
> > >       │********│ |
> > >       ├────────┤ | 16 objects
> > >       │********│ | 128B
> > > cache │********│ |
> > > line3 │********│ |
> > >       │********│ |
> > >       ├────────┤ |
> > >       │********│_v_
> > > cache │        │
> > > line4 │        │
> > >       │        │
> > >       └────────┘
> > > 4 cache lines touched, incl. line0 for len.
> > >
> > > With the proposed alignment:
> > >       ┌────────┐
> > >       │len     │
> > > cache │        │
> > > line0 │        │
> > >       │        │
> > >       ├────────┤
> > >       │        │
> > > cache │        │
> > > line1 │        │
> > >       │        │
> > >       ├────────┤
> > >       │        │
> > > cache │        │
> > > line2 │        │
> > >       │        │
> > >       ├────────┤
> > >       │********│---
> > > cache │********│ ^
> > > line3 │********│ |
> > >       │********│ | 16 objects
> > >       ├────────┤ | 128B
> > >       │********│ |
> > > cache │********│ |
> > > line4 │********│ |
> > >       │********│_v_
> > >       └────────┘
> > > Only 3 cache lines touched, incl. line0 for len.
> > 
> > I understand your logic, but are we sure that having an application
> > that
> > works with bulks of 32 means that the cache will stay aligned to 32
> > elements for the whole life of the application?
> > 
> > In an application, the alignment of the cache can change if you have
> > any of:
> > - software queues (reassembly for instance)
> > - packet duplication (bridge, multicast)
> > - locally generated packets (keepalive, control protocol)
> > - pipeline to other cores
> > 
> > Even with testpmd, which work by bulk of 32, I can see that the size
> > of the cache filling is not aligned to 32. Right after starting the
> > application, we already have this:
> > 
> >   internal cache infos:
> >     cache_size=250
> >     cache_count[0]=231
> > 
> > This is probably related to the hw rx rings size, number of queues,
> > number of ports.
> > 
> > The "250" default value for cache size in testpmd is questionable, but
> > with --mbcache=256, the behavior is similar.
> > 
> > Also, when we transmit to a NIC, the mbufs are not returned immediatly
> > to the pool, they may stay in the hw tx ring during some time, which is
> > a driver decision.
> > 
> > After processing traffic on cores 8 and 24 with this testpmd, I get:
> >     cache_count[0]=231
> >     cache_count[8]=123
> >     cache_count[24]=122
> > 
> > In my opinion, it is not realistic to think that the mempool cache will
> > remain aligned to cachelines. In these conditions, it looks better to
> > keep the structure packed to avoid wasting memory.
> 
> I agree that is a special use case to only access the mempool cache in
> bursts of 32 objects, so the accesses are always cache line
> aligned. (Generalized, the burst size must not be 32; a burst size
> that is a multiple of RTE_CACHE_LINE_SIZE/sizeof(void*), i.e. a burst
> size of 8 on a 64-bit architecture, will do.)

Is there a real situation where it happens to always have read/write
accesses per bulks of 32? From what I see in my quick test, it is not
the case, even with testpmd.

> Adding a hole of 52 byte per mempool cache is nothing, considering
> that the mempool cache already uses 8 KB (RTE_MEMPOOL_CACHE_MAX_SIZE *
> 2 * sizeof(void*) = 1024 * 8 byte) for the objects.
>
> Also - assuming that memory allocations are cache line aligned - the
> 52 byte of unused memory cannot be used regardless if they are before
> or after the objects. Instead of having 52 B unused after the objects,
> we might as well have a hole of 52 B unused before the objects. In
> other words: There is really no downside to this.

Correct, the memory waste argument to nack the patch is invalid.

> Jerin also presented a separate argument for moving the objects to
> another cache line than the len field: The risk for "load-after-store
> stall" when loading the len field after storing objects in cache line0
> [1].
> 
> [1]: http://inbox.dpdk.org/dev/CALBAE1P4zFYdLwoQukn5Q-V-nTvc_UBWmWjhaV2uVBXQRytSSA@mail.gmail.com/

I'll be prudent on this justification without numbers. The case where we
access to the objects of the first cache line (among several KB) is
maybe not that frequent.

> A new idea just popped into my head: The hot debug statistics
> counters (put_bulk, put_objs, get_success_bulk, get_success_objs)
> could be moved to this free space, reducing the need to touch another
> cache line for debug counters. I haven’t thought this idea through
> yet; it might conflict with Jerin's comment.

Yes, but since the stats are only enabled when RTE_LIBRTE_MEMPOOL_DEBUG
is set, it won't have any impact on non-debug builds.


Honnestly, I find it hard to convince myself that it is a real
optimization. I don't see any reason why it would be slower though. So
since we already broke the mempool cache struct ABI in a previous
commit, and since it won't consume more memory, I'm ok to include that
patch. It would be great to have numbers to put some weight in the
balance.




> 
> > 
> > Olivier
> > 
> > 
> > >
> > > Credits go to Olivier Matz for the nice ASCII graphics.
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > ---
> > >  lib/mempool/rte_mempool.h | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> > > index 1f5707f46a..3725a72951 100644
> > > --- a/lib/mempool/rte_mempool.h
> > > +++ b/lib/mempool/rte_mempool.h
> > > @@ -86,11 +86,13 @@ struct rte_mempool_cache {
> > >  	uint32_t size;	      /**< Size of the cache */
> > >  	uint32_t flushthresh; /**< Threshold before we flush excess
> > elements */
> > >  	uint32_t len;	      /**< Current cache count */
> > > -	/*
> > > +	/**
> > > +	 * Cache objects
> > > +	 *
> > >  	 * Cache is allocated to this size to allow it to overflow in
> > certain
> > >  	 * cases to avoid needless emptying of cache.
> > >  	 */
> > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache objects */
> > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2] __rte_cache_aligned;
> > >  } __rte_cache_aligned;
> > >
> > >  /**
> > > --
> > > 2.17.1
> > >
> 

^ permalink raw reply	[relevance 3%]

* Re: [PATCH] ci: combine static and shared linking build tests
  2022-10-20 15:34  0% ` Aaron Conole
@ 2022-10-27 11:21  0%   ` David Marchand
  0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-10-27 11:21 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, Bruce Richardson, Aaron Conole, Michael Santana

On Thu, Oct 20, 2022 at 5:34 PM Aaron Conole <aconole@redhat.com> wrote:
> > Save some cpu time and disk by testing linking against static and shared
> > library in single environments.
> >
> > The .ci/linux-build.sh is modified so it reconfigures an existing build
> > directory: an empty DEF_LIB= means that static and shared builds are
> > to be tested.
> >
> > ABI checks, documentation generation and unit tests are disabled for
> > static builds as they would be redundant with the check against
> > dynamically linked binaries, if any.
> >
> > Note:
> > - --cross-file is an option that can be passed to meson only when
> >   creating a build environment,
> > - for some other reason, --buildtype and other non -D options are only
> >   accepted when setting up a build directory with meson. When
> >   reconfiguring, only their -D$option forms are accepted,
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Aaron Conole <aconole@redhat.com>

Applied, thanks.


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* RE: [PATCH] vhost: promote per-queue stats API to stable
    2022-10-17 13:22  0% ` David Marchand
  2022-10-24  8:53  0% ` Xia, Chenbo
@ 2022-10-26  9:31  0% ` Xia, Chenbo
  2 siblings, 0 replies; 200+ results
From: Xia, Chenbo @ 2022-10-26  9:31 UTC (permalink / raw)
  To: Maxime Coquelin, dev, david.marchand

> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Monday, October 10, 2022 11:38 PM
> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>;
> david.marchand@redhat.com
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: [PATCH] vhost: promote per-queue stats API to stable
> 
> This patch promotes the per-queue stats API to stable.
> The API has been used by the Vhost PMD since v22.07, and
> David Marchand posted a patch to make use of it in next
> OVS release[0].
> 
> [0]:
> http://patchwork.ozlabs.org/project/openvswitch/patch/20221007111613.16955
> 24-4-david.marchand@redhat.com/
> 
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  doc/guides/rel_notes/release_22_11.rst | 4 ++++
>  lib/vhost/rte_vhost.h                  | 3 ---
>  lib/vhost/version.map                  | 6 +++---
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_22_11.rst
> b/doc/guides/rel_notes/release_22_11.rst
> index 37bd392f34..d5d3eeae24 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -443,6 +443,10 @@ API Changes
> 
>  * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
> 
> +* vhost: Promoted ``rte_vhost_vring_stats_get()``,
> +  ``rte_vhost_vring_stats_get_names()`` and
> ``rte_vhost_vring_stats_reset()``
> +  from experimental to stable.
> +
> 
>  ABI Changes
>  -----------
> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
> index bb7d86a432..59c98a0afb 100644
> --- a/lib/vhost/rte_vhost.h
> +++ b/lib/vhost/rte_vhost.h
> @@ -1075,7 +1075,6 @@ rte_vhost_slave_config_change(int vid, bool
> need_reply);
>   *  - Failure if lower than 0. The device ID or queue ID is invalid or
>   +    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get_names(int vid, uint16_t queue_id,
>  		struct rte_vhost_stat_name *name, unsigned int size);
> @@ -1103,7 +1102,6 @@ rte_vhost_vring_stats_get_names(int vid, uint16_t
> queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>  		struct rte_vhost_stat *stats, unsigned int n);
> @@ -1120,7 +1118,6 @@ rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_reset(int vid, uint16_t queue_id);
> 
> diff --git a/lib/vhost/version.map b/lib/vhost/version.map
> index 7a00b65740..8c5e8aa8d3 100644
> --- a/lib/vhost/version.map
> +++ b/lib/vhost/version.map
> @@ -57,6 +57,9 @@ DPDK_23 {
>  	rte_vhost_set_vring_base;
>  	rte_vhost_va_from_guest_pa;
>  	rte_vhost_vring_call;
> +	rte_vhost_vring_stats_get;
> +	rte_vhost_vring_stats_get_names;
> +	rte_vhost_vring_stats_reset;
> 
>  	local: *;
>  };
> @@ -88,9 +91,6 @@ EXPERIMENTAL {
> 
>  	# added in 22.07
>  	rte_vhost_async_get_inflight_thread_unsafe;
> -	rte_vhost_vring_stats_get_names;
> -	rte_vhost_vring_stats_get;
> -	rte_vhost_vring_stats_reset;
>  	rte_vhost_async_try_dequeue_burst;
>  	rte_vhost_driver_get_vdpa_dev_type;
>  	rte_vhost_clear_queue;
> --
> 2.37.3

Applied to next-virtio/main, thanks

^ permalink raw reply	[relevance 0%]

* Re: release candidate 22.11-rc1
    2022-10-13  5:28  0% ` Jiang, YuX
@ 2022-10-24 13:12  0% ` David Marchand
  2022-10-27 21:00  0% ` Thinh Tran
  2 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-10-24 13:12 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: dev, YangHang Liu, Maxime Coquelin

Hello,

On Tue, Oct 11, 2022 at 3:50 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> A new DPDK release candidate is ready for testing:
>         https://git.dpdk.org/dpdk/tag/?id=v22.11-rc1
>
> There are 737 new patches in this snapshot,
> including many API/ABI compatibility breakages.
> This release won't be ABI-compatible with previous ones.
>
> Release notes:
>         https://doc.dpdk.org/guides/rel_notes/release_22_11.html
>
> Highlights of 22.11-rc1:
>         - LoongArch build
>         - Intel uncore frequency control
>         - multiple mbuf pools per Rx queue
>         - Rx buffer split based on protocol
>         - hardware congestion management
>         - hairpin memory configuration
>         - Rx/Tx descriptor dump
>         - flow API extensions
>         - MACsec processing offload
>         - ShangMi crypto algorithms
>         - baseband FFT operations
>         - eventdev Tx queue start/stop
>         - eventdev crypto vectorization
>         - NitroSketch membership
>
> Some work is in progress to optimize the mempool cache.
> Some patches are part of -rc1, and more could be merged in -rc2.
> Please measure the performance of this release candidate,
> and check these mempool patches:
>         https://patches.dpdk.org/project/dpdk/list/?series=25063
>
> Please test and report issues on bugs.dpdk.org.
>
> DPDK 22.11-rc2 is expected in two weeks.
>
> Thank you everyone
>
>

Red Hat QE ran its non regression test suites and found no issue.



See below for details:
Test scenario:

Guest with device assignment(PF) throughput testing(1G hugepage size): PASS
Guest with device assignment(PF) throughput testing(2M hugepage size) : PASS
Guest with device assignment(VF) throughput testing: PASS
PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
PVP vhost-user 2Q throughput testing: PASS
PVP vhost-user 1Q - cross numa node throughput testing: PASS
Guest with vhost-user 2 queues throughput testing: PASS
vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS
vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
PVP 1Q live migration testing: PASS
PVP 1Q cross numa node live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
Host PF + DPDK testing: PASS
Host VF + DPDK testing: PASS

Test version:

kernel 5.14
qemu 7.1
dpdk: git://dpdk.org/dpdk
# git log -1

commit a74b1b25136a592c275afbfa6b70771469750aee

Author: Thomas Monjalon <thomas@monjalon.net>

Date:   Tue Oct 11 02:39:28 2022 +0200

version: 22.11-rc1

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

NICs: X540-AT2 NIC(ixgbe, 10G)


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* RE: [PATCH] vhost: promote per-queue stats API to stable
    2022-10-17 13:22  0% ` David Marchand
@ 2022-10-24  8:53  0% ` Xia, Chenbo
  2022-10-26  9:31  0% ` Xia, Chenbo
  2 siblings, 0 replies; 200+ results
From: Xia, Chenbo @ 2022-10-24  8:53 UTC (permalink / raw)
  To: Maxime Coquelin, dev; +Cc: david.marchand

> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Monday, October 10, 2022 11:38 PM
> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>;
> david.marchand@redhat.com
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Subject: [PATCH] vhost: promote per-queue stats API to stable
> 
> This patch promotes the per-queue stats API to stable.
> The API has been used by the Vhost PMD since v22.07, and
> David Marchand posted a patch to make use of it in next
> OVS release[0].
> 
> [0]:
> http://patchwork.ozlabs.org/project/openvswitch/patch/20221007111613.16955
> 24-4-david.marchand@redhat.com/
> 
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  doc/guides/rel_notes/release_22_11.rst | 4 ++++
>  lib/vhost/rte_vhost.h                  | 3 ---
>  lib/vhost/version.map                  | 6 +++---
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_22_11.rst
> b/doc/guides/rel_notes/release_22_11.rst
> index 37bd392f34..d5d3eeae24 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -443,6 +443,10 @@ API Changes
> 
>  * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
> 
> +* vhost: Promoted ``rte_vhost_vring_stats_get()``,
> +  ``rte_vhost_vring_stats_get_names()`` and
> ``rte_vhost_vring_stats_reset()``
> +  from experimental to stable.
> +
> 
>  ABI Changes
>  -----------
> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
> index bb7d86a432..59c98a0afb 100644
> --- a/lib/vhost/rte_vhost.h
> +++ b/lib/vhost/rte_vhost.h
> @@ -1075,7 +1075,6 @@ rte_vhost_slave_config_change(int vid, bool
> need_reply);
>   *  - Failure if lower than 0. The device ID or queue ID is invalid or
>   +    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get_names(int vid, uint16_t queue_id,
>  		struct rte_vhost_stat_name *name, unsigned int size);
> @@ -1103,7 +1102,6 @@ rte_vhost_vring_stats_get_names(int vid, uint16_t
> queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>  		struct rte_vhost_stat *stats, unsigned int n);
> @@ -1120,7 +1118,6 @@ rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_reset(int vid, uint16_t queue_id);
> 
> diff --git a/lib/vhost/version.map b/lib/vhost/version.map
> index 7a00b65740..8c5e8aa8d3 100644
> --- a/lib/vhost/version.map
> +++ b/lib/vhost/version.map
> @@ -57,6 +57,9 @@ DPDK_23 {
>  	rte_vhost_set_vring_base;
>  	rte_vhost_va_from_guest_pa;
>  	rte_vhost_vring_call;
> +	rte_vhost_vring_stats_get;
> +	rte_vhost_vring_stats_get_names;
> +	rte_vhost_vring_stats_reset;
> 
>  	local: *;
>  };
> @@ -88,9 +91,6 @@ EXPERIMENTAL {
> 
>  	# added in 22.07
>  	rte_vhost_async_get_inflight_thread_unsafe;
> -	rte_vhost_vring_stats_get_names;
> -	rte_vhost_vring_stats_get;
> -	rte_vhost_vring_stats_reset;
>  	rte_vhost_async_try_dequeue_burst;
>  	rte_vhost_driver_get_vdpa_dev_type;
>  	rte_vhost_clear_queue;
> --
> 2.37.3

Reviewed-by: Chenbo Xia <chenbo.xia@intel.com>

^ permalink raw reply	[relevance 0%]

* RE: [PATCH v6 3/8] net/gve: add support for device initialization
  2022-10-20 14:42  3%     ` Ferruh Yigit
@ 2022-10-24  2:10  0%       ` Guo, Junfeng
  0 siblings, 0 replies; 200+ results
From: Guo, Junfeng @ 2022-10-24  2:10 UTC (permalink / raw)
  To: Ferruh Yigit, Zhang, Qi Z, Wu, Jingjing, Xing, Beilei
  Cc: dev, Li, Xiaoyun, awogbemila, Richardson, Bruce, hemant.agrawal,
	stephen, Xia, Chenbo, Zhang, Helin, Wang, Haiyue



> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Thursday, October 20, 2022 22:42
> To: Guo, Junfeng <junfeng.guo@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Xing,
> Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Li, Xiaoyun <xiaoyun.li@intel.com>;
> awogbemila@google.com; Richardson, Bruce
> <bruce.richardson@intel.com>; hemant.agrawal@nxp.com;
> stephen@networkplumber.org; Xia, Chenbo <chenbo.xia@intel.com>;
> Zhang, Helin <helin.zhang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>
> Subject: Re: [PATCH v6 3/8] net/gve: add support for device initialization
> 
> On 10/20/2022 11:36 AM, Junfeng Guo wrote:
> 
> >
> > Support device init and add following devops skeleton:
> >   - dev_configure
> >   - dev_start
> >   - dev_stop
> >   - dev_close
> >
> > Note that build system (including doc) is also added in this patch.
> >
> > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> > Signed-off-by: Xiaoyun Li <xiaoyun.li@intel.com>
> > Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
> 
> <...>
> 
> > index 1c3daf141d..715013fa35 100644
> > --- a/doc/guides/rel_notes/release_22_11.rst
> > +++ b/doc/guides/rel_notes/release_22_11.rst
> > @@ -140,6 +140,11 @@ New Features
> >
> >     * Made compatible with libbpf v0.8.0 (when used with libxdp).
> >
> > +* **Added GVE net PMD**
> > +
> > +  * Added the new ``gve`` net driver for Google Virtual Ethernet devices.
> > +  * See the :doc:`../nics/gve` NIC guide for more details on this new
> driver.
> > +
> 
> Can you please move it one more down, just above 'Intel', to sort it
> alphabetically based on Vendor name, in this case 'G' I guess.
> We are almost there :)

Sure, thanks for reminding this!

> 
> <...>
> 
> > +static int
> > +gve_dev_init(struct rte_eth_dev *eth_dev)
> > +{
> > +       struct gve_priv *priv = eth_dev->data->dev_private;
> > +       int max_tx_queues, max_rx_queues;
> > +       struct rte_pci_device *pci_dev;
> > +       struct gve_registers *reg_bar;
> > +       rte_be32_t *db_bar;
> > +       int err;
> > +
> > +       eth_dev->dev_ops = &gve_eth_dev_ops;
> > +
> > +       if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> > +               return 0;
> > +
> > +       pci_dev = RTE_DEV_TO_PCI(eth_dev->device);
> > +
> > +       reg_bar = pci_dev->mem_resource[GVE_REG_BAR].addr;
> > +       if (!reg_bar) {
> > +               PMD_DRV_LOG(ERR, "Failed to map pci bar!");
> > +               return -ENOMEM;
> > +       }
> > +
> > +       db_bar = pci_dev->mem_resource[GVE_DB_BAR].addr;
> > +       if (!db_bar) {
> > +               PMD_DRV_LOG(ERR, "Failed to map doorbell bar!");
> > +               return -ENOMEM;
> > +       }
> > +
> > +       gve_write_version(&reg_bar->driver_version);
> > +       /* Get max queues to alloc etherdev */
> > +       max_tx_queues = ioread32be(&reg_bar->max_tx_queues);
> > +       max_rx_queues = ioread32be(&reg_bar->max_rx_queues);
> > +
> > +       priv->reg_bar0 = reg_bar;
> > +       priv->db_bar2 = db_bar;
> > +       priv->pci_dev = pci_dev;
> > +       priv->state_flags = 0x0;
> > +
> > +       priv->max_nb_txq = max_tx_queues;
> > +       priv->max_nb_rxq = max_rx_queues;
> > +
> > +       err = gve_init_priv(priv, false);
> > +       if (err)
> > +               return err;
> > +
> > +       eth_dev->data->mac_addrs = rte_zmalloc("gve_mac", sizeof(struct
> rte_ether_addr), 0);
> > +       if (!eth_dev->data->mac_addrs) {
> > +               PMD_DRV_LOG(ERR, "Failed to allocate memory to store mac
> address");
> > +               return -ENOMEM;
> > +       }
> > +       rte_ether_addr_copy(&priv->dev_addr, eth_dev->data-
> >mac_addrs);
> > +
> 
> What is the value in 'priv->dev_addr'?
> Even allocating memory for 'eth_dev->data->mac_addrs' removed or not,
> as
> we discussed, independent from it, need to set a valid value to
> 'priv->dev_addr'.

Again, thanks for the explanation!
Will update this and re-validate for this.
The addr value could be like " 42:01:0A:00:08:03".
Thanks!

> 
> <...>
> 
> > diff --git a/drivers/net/gve/version.map b/drivers/net/gve/version.map
> > new file mode 100644
> > index 0000000000..c2e0723b4c
> > --- /dev/null
> > +++ b/drivers/net/gve/version.map
> > @@ -0,0 +1,3 @@
> > +DPDK_22 {
> 
> DPDK_23
> 
> In case it is not clear, since this comment skipped in previous a few
> versions, the ABI version should be 'DPDK_23', so the content of this
> file should be;
> 
> DPDK_23 {
>          local: *;
> };

Sure, will update this in the coming version. Thanks a lot!


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] eventdev: fix event vector documentation typo
  @ 2022-10-21  9:42  8% ` Jerin Jacob
  0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-10-21  9:42 UTC (permalink / raw)
  To: Mattias Rönnblom; +Cc: Jerin Jacob, dev, pbhagavatula, stable

On Fri, Oct 21, 2022 at 1:48 PM Mattias Rönnblom
<mattias.ronnblom@ericsson.com> wrote:
>
> The Eventdev guide had got the type of the rte_event_vector struct's
> u64s union field wrong.
>
> Fixes: 1cc44d409271 ("eventdev: introduce event vector capability")
> Cc: pbhagavatula@marvell.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>

Thanks, Squashed this change as

    doc: fix eventdev doc updates

    Fixed release notes for changes made in eventdev library.
    Also updated the eventdev guide had got the type of the
    rte_event_vector struct's u64s union field wrong.

    Fixes: 5fa63911e43b ("eventdev: replace padding type in event vector")
    Fixes: 0fbb55efa542 ("eventdev: add element offset to event vector")
    Fixes: d986276f9b72 ("eventdev: add prefix to public symbol")
    Fixes: 1cc44d409271 ("eventdev: introduce event vector capability")

    Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
    Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>

    Acked-by: Jerin Jacob <jerinj@marvell.com>

diff --git a/doc/guides/prog_guide/eventdev.rst
b/doc/guides/prog_guide/eventdev.rst
index 8c13c5832c..2c83176846 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -85,7 +85,7 @@ flexibility in what the actual vector is.

 * ``struct rte_mbuf *mbufs[0]`` - An array of mbufs.
 * ``void *ptrs[0]`` - An array of pointers.
-* ``uint64_t *u64s[0]`` - An array of uint64_t elements.
+* ``uint64_t u64s[0]`` - An array of uint64_t elements.

 The size of the event vector is related to the total number of elements it is
 configured to hold, this is achieved by making `rte_event_vector` a variable
diff --git a/doc/guides/rel_notes/release_22_11.rst
b/doc/guides/rel_notes/release_22_11.rst
index 1c3daf141d..0d45043271 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -478,6 +478,9 @@ API Changes

 * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.

+* eventdev: The function pointer definition ``eventdev_stop_flush_t`` is
+  renamed to ``rte_eventdev_stop_flush_t`` to avoid conflicts with application
+  symbols.

 ABI Changes
 -----------
@@ -520,6 +523,14 @@ ABI Changes
 * eventdev: Added ``weight`` and ``affinity`` fields
   to ``rte_event_queue_conf`` structure.

+* eventdev: The field ``*u64s`` in the structure ``rte_event_vector``
is replaced
+  with ``u64s`` as the field is supposed to hold array of uint64_t values.
+
+* eventdev: The structure ``rte_event_vector`` was updated to include a new bit
+  field ``elem_offset:12`` the bits are taken from the bitfield ``rsvd:15``.
+  The element offset defines the offset into the vector array at
+  which valid elements start.
+

> ---
>  doc/guides/prog_guide/eventdev.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
> index 8c13c5832c..2c83176846 100644
> --- a/doc/guides/prog_guide/eventdev.rst
> +++ b/doc/guides/prog_guide/eventdev.rst
> @@ -85,7 +85,7 @@ flexibility in what the actual vector is.
>
>  * ``struct rte_mbuf *mbufs[0]`` - An array of mbufs.
>  * ``void *ptrs[0]`` - An array of pointers.
> -* ``uint64_t *u64s[0]`` - An array of uint64_t elements.
> +* ``uint64_t u64s[0]`` - An array of uint64_t elements.
>
>  The size of the event vector is related to the total number of elements it is
>  configured to hold, this is achieved by making `rte_event_vector` a variable
> --
> 2.34.1
>

^ permalink raw reply	[relevance 8%]

* Re: [PATCH] ci: combine static and shared linking build tests
  2022-10-17 14:07  3% [PATCH] ci: combine static and shared linking build tests David Marchand
  2022-10-20 11:44  0% ` David Marchand
@ 2022-10-20 15:34  0% ` Aaron Conole
  2022-10-27 11:21  0%   ` David Marchand
  1 sibling, 1 reply; 200+ results
From: Aaron Conole @ 2022-10-20 15:34 UTC (permalink / raw)
  To: David Marchand; +Cc: dev, Michael Santana

David Marchand <david.marchand@redhat.com> writes:

> Save some cpu time and disk by testing linking against static and shared
> library in single environments.
>
> The .ci/linux-build.sh is modified so it reconfigures an existing build
> directory: an empty DEF_LIB= means that static and shared builds are
> to be tested.
>
> ABI checks, documentation generation and unit tests are disabled for
> static builds as they would be redundant with the check against
> dynamically linked binaries, if any.
>
> Note:
> - --cross-file is an option that can be passed to meson only when
>   creating a build environment,
> - for some other reason, --buildtype and other non -D options are only
>   accepted when setting up a build directory with meson. When
>   reconfiguring, only their -D$option forms are accepted,
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---

Probably also saves overall time because we would need fewer runners.  I
think this is a good change.

Acked-by: Aaron Conole <aconole@redhat.com>


^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 3/8] net/gve: add support for device initialization
  @ 2022-10-20 14:42  3%     ` Ferruh Yigit
  2022-10-24  2:10  0%       ` Guo, Junfeng
  0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-10-20 14:42 UTC (permalink / raw)
  To: Junfeng Guo, qi.z.zhang, jingjing.wu, beilei.xing
  Cc: dev, xiaoyun.li, awogbemila, bruce.richardson, hemant.agrawal,
	stephen, chenbo.xia, helin.zhang, Haiyue Wang

On 10/20/2022 11:36 AM, Junfeng Guo wrote:

> 
> Support device init and add following devops skeleton:
>   - dev_configure
>   - dev_start
>   - dev_stop
>   - dev_close
> 
> Note that build system (including doc) is also added in this patch.
> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> Signed-off-by: Xiaoyun Li <xiaoyun.li@intel.com>
> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>

<...>

> index 1c3daf141d..715013fa35 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -140,6 +140,11 @@ New Features
> 
>     * Made compatible with libbpf v0.8.0 (when used with libxdp).
> 
> +* **Added GVE net PMD**
> +
> +  * Added the new ``gve`` net driver for Google Virtual Ethernet devices.
> +  * See the :doc:`../nics/gve` NIC guide for more details on this new driver.
> +

Can you please move it one more down, just above 'Intel', to sort it 
alphabetically based on Vendor name, in this case 'G' I guess.
We are almost there :)

<...>

> +static int
> +gve_dev_init(struct rte_eth_dev *eth_dev)
> +{
> +       struct gve_priv *priv = eth_dev->data->dev_private;
> +       int max_tx_queues, max_rx_queues;
> +       struct rte_pci_device *pci_dev;
> +       struct gve_registers *reg_bar;
> +       rte_be32_t *db_bar;
> +       int err;
> +
> +       eth_dev->dev_ops = &gve_eth_dev_ops;
> +
> +       if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> +               return 0;
> +
> +       pci_dev = RTE_DEV_TO_PCI(eth_dev->device);
> +
> +       reg_bar = pci_dev->mem_resource[GVE_REG_BAR].addr;
> +       if (!reg_bar) {
> +               PMD_DRV_LOG(ERR, "Failed to map pci bar!");
> +               return -ENOMEM;
> +       }
> +
> +       db_bar = pci_dev->mem_resource[GVE_DB_BAR].addr;
> +       if (!db_bar) {
> +               PMD_DRV_LOG(ERR, "Failed to map doorbell bar!");
> +               return -ENOMEM;
> +       }
> +
> +       gve_write_version(&reg_bar->driver_version);
> +       /* Get max queues to alloc etherdev */
> +       max_tx_queues = ioread32be(&reg_bar->max_tx_queues);
> +       max_rx_queues = ioread32be(&reg_bar->max_rx_queues);
> +
> +       priv->reg_bar0 = reg_bar;
> +       priv->db_bar2 = db_bar;
> +       priv->pci_dev = pci_dev;
> +       priv->state_flags = 0x0;
> +
> +       priv->max_nb_txq = max_tx_queues;
> +       priv->max_nb_rxq = max_rx_queues;
> +
> +       err = gve_init_priv(priv, false);
> +       if (err)
> +               return err;
> +
> +       eth_dev->data->mac_addrs = rte_zmalloc("gve_mac", sizeof(struct rte_ether_addr), 0);
> +       if (!eth_dev->data->mac_addrs) {
> +               PMD_DRV_LOG(ERR, "Failed to allocate memory to store mac address");
> +               return -ENOMEM;
> +       }
> +       rte_ether_addr_copy(&priv->dev_addr, eth_dev->data->mac_addrs);
> +

What is the value in 'priv->dev_addr'?
Even allocating memory for 'eth_dev->data->mac_addrs' removed or not, as 
we discussed, independent from it, need to set a valid value to 
'priv->dev_addr'.

<...>

> diff --git a/drivers/net/gve/version.map b/drivers/net/gve/version.map
> new file mode 100644
> index 0000000000..c2e0723b4c
> --- /dev/null
> +++ b/drivers/net/gve/version.map
> @@ -0,0 +1,3 @@
> +DPDK_22 {

DPDK_23

In case it is not clear, since this comment skipped in previous a few 
versions, the ABI version should be 'DPDK_23', so the content of this 
file should be;

DPDK_23 {
         local: *;
};


^ permalink raw reply	[relevance 3%]

* Re: [PATCH] ci: combine static and shared linking build tests
  2022-10-17 14:07  3% [PATCH] ci: combine static and shared linking build tests David Marchand
@ 2022-10-20 11:44  0% ` David Marchand
  2022-10-20 15:34  0% ` Aaron Conole
  1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-10-20 11:44 UTC (permalink / raw)
  To: dev; +Cc: Aaron Conole, Michael Santana

On Mon, Oct 17, 2022 at 4:08 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Save some cpu time and disk by testing linking against static and shared
> library in single environments.

Some additional info.

Before, 2h27 of cpu:
https://github.com/ovsrobot/dpdk/actions/runs/3265097067/usage

After, 2h07 of cpu:
https://github.com/ovsrobot/dpdk/actions/runs/3265960025/usage

The gain in cpu time (and global duration of the tests) is smaller
than what I saw.
Quite likely, it is dependent on what is being done on the runners.


>
> The .ci/linux-build.sh is modified so it reconfigures an existing build
> directory: an empty DEF_LIB= means that static and shared builds are
> to be tested.
>
> ABI checks, documentation generation and unit tests are disabled for
> static builds as they would be redundant with the check against
> dynamically linked binaries, if any.
>
> Note:
> - --cross-file is an option that can be passed to meson only when
>   creating a build environment,
> - for some other reason, --buildtype and other non -D options are only
>   accepted when setting up a build directory with meson. When
>   reconfiguring, only their -D$option forms are accepted,
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>

-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* RE: release candidate 22.11-rc1
  2022-10-13  5:28  0% ` Jiang, YuX
@ 2022-10-20  5:24  0%   ` Jiang, YuX
  0 siblings, 0 replies; 200+ results
From: Jiang, YuX @ 2022-10-20  5:24 UTC (permalink / raw)
  To: Thomas Monjalon, dev
  Cc: Devlin, Michelle, Mcnamara, John, Chen, Zhaoyan, Peng, Yuan

> -----Original Message-----
> From: Jiang, YuX
> Sent: Thursday, October 13, 2022 1:28 PM
> To: Thomas Monjalon <thomas@monjalon.net>; dev <dev@dpdk.org>
> Cc: Devlin, Michelle <michelle.devlin@intel.com>; Mcnamara, John
> <john.mcnamara@intel.com>; Chen, Zhaoyan <zhaoyan.chen@intel.com>;
> Peng, Yuan <yuan.peng@intel.com>
> Subject: RE: release candidate 22.11-rc1
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Tuesday, October 11, 2022 9:50 AM
> > To: announce@dpdk.org
> > Subject: release candidate 22.11-rc1
> >
> > A new DPDK release candidate is ready for testing:
> > 	https://git.dpdk.org/dpdk/tag/?id=v22.11-rc1
> >
> > There are 737 new patches in this snapshot, including many API/ABI
> > compatibility breakages.
> > This release won't be ABI-compatible with previous ones.
> >
> > Release notes:
> > 	https://doc.dpdk.org/guides/rel_notes/release_22_11.html
> >
> > Highlights of 22.11-rc1:
> > 	- LoongArch build
> > 	- Intel uncore frequency control
> > 	- multiple mbuf pools per Rx queue
> > 	- Rx buffer split based on protocol
> > 	- hardware congestion management
> > 	- hairpin memory configuration
> > 	- Rx/Tx descriptor dump
> > 	- flow API extensions
> > 	- MACsec processing offload
> > 	- ShangMi crypto algorithms
> > 	- baseband FFT operations
> > 	- eventdev Tx queue start/stop
> > 	- eventdev crypto vectorization
> > 	- NitroSketch membership
> >
> > Some work is in progress to optimize the mempool cache.
> > Some patches are part of -rc1, and more could be merged in -rc2.
> > Please measure the performance of this release candidate, and check
> > these mempool patches:
> > 	https://patches.dpdk.org/project/dpdk/list/?series=25063
> >
> > Please test and report issues on bugs.dpdk.org.
> >
> > DPDK 22.11-rc2 is expected in two weeks.
> >
> > Thank you everyone
> >
> Update the test status for Intel part. Till now dpdk22.11-rc1 test execution rate
> is 60%. Two critical issues are found.
> 1, [22.11-rc1]iavf macfwd performance drop 40%, Intel dev is under
> investigating.
> 2, dpdk_vm_power_manger failed to start and coredumps:
>   Fix patch:
> https://patches.dpdk.org/project/dpdk/patch/20221012123637.51640-1-
> markus.theil@tu-ilmenau.de/. but not verify yet.
> # Basic Intel(R) NIC testing
> * Build or compile:
>  *Build: cover the build test combination with latest GCC/Clang version and the
> popular OS revision such as Ubuntu20.04.5, Ubuntu22.04.1, Fedora36, RHEL8.6
> etc.
>   - All test passed.
>  *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as
> Ubuntu22.04.1 and RHEL8.6.
>   - All test passed.
> * PF/VF(i40e, ixgbe): test scenarios including PF/VF-
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> 	- Execution rate is 80%.
> 	- New bug: https://bugs.dpdk.org/show_bug.cgi?id=1101 [dpdk-
> 22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed
> 		Bad commit is a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0
> mempool: fix get objects from mempool with cache
> * PF/VF(ice): test scenarios including Switch features/Package
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
> Descriptor, etc.
> 	- Execution rate is 80%. Find 5 new issues, Intel dev is under
> investigating.
> * Intel NIC single core/NIC performance: test scenarios including PF/VF single
> core performance test, RFC2544 Zero packet loss performance test, etc.
> 	- Execution rate is 80%. Find one critical issue: [22.11-rc1]iavf macfwd
> performance drop 40%, Intel dev is under investigating.
> * Power and IPsec:
>  * Power: test scenarios including bi-direction/Telemetry/Empty Poll
> Lib/Priority Base Frequency, etc.
> 	- Under testing. One critical issue is found: dpdk_vm_power_manger
> failed to start and coredumps.
>  * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test -
> QAT&SW/FIB library, etc.
> 	- Execution rate is 40%. Find one issue, Intel dev is under investigating.
> # Basic cryptodev and virtio testing
> * Virtio: both function and performance test are covered. Such as
> PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf
> testing/VMAWARE ESXI 7.0u3, etc.
> 	- Execution rate is 80%. No new issue is found.
> 	- Known issue's fix patch:
> http://patches.dpdk.org/project/dpdk/patch/20221011030803.16746-3-
> cheng1.jiang@intel.com/.
> * Cryptodev:
>  *Function test: test scenarios including Cryptodev API testing/CompressDev
> ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
> 	- Under testing. Find one bug about FIPS tests are failing, Intel dev is
> under investigating.
>  *Performance test: test scenarios including Throughput Performance
> /Cryptodev Latency, etc.
> 	- Under testing.
> 
> Best regards,
> Yu Jiang

Update the test status for Intel part. Till now dpdk22.11-rc1 test is almost finished. Two critical issues are found. 
1, [22.11-rc1]iavf macfwd performance drop 40%, Intel dev revert this bad patch.
2, dpdk_vm_power_manger failed to start and coredumps: 
Fix patch: https://patches.dpdk.org/project/dpdk/patch/20221012123637.51640-1-markus.theil@tu-ilmenau.de/.  
# Basic Intel(R) NIC testing
* Build or compile:  
 *Build: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu20.04.5, Ubuntu22.04.1, Fedora36, RHEL8.6 etc.
  - All test passed.
 *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu22.04.1 and RHEL8.6.
  - All test passed.
* Meson test: find 3 bugs
	- https://bugs.dpdk.org/show_bug.cgi?id=1101 [dpdk-22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed
		- fixed by https://patches.dpdk.org/project/dpdk/patch/20221014203710.6172-1-olivier.matz@6wind.com/
	- https://bugs.dpdk.org/show_bug.cgi?id=1105 dpdk-22.11] unit_tests_loopback: pmd_perf_autotest failed -> On going
	- https://bugs.dpdk.org/show_bug.cgi?id=1107 [22.11-rc1][meson test] seqlock_autotest test failed -> On going
* PF/VF(i40e, ixgbe): test scenarios including PF/VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. 
	- All test done. Find 3+ bugs, Intel Dev is under investigating.
	- Asan bug: asan error detected memory leaks when quit testpmd
		- Can be fixed by https://patches.dpdk.org/project/dpdk/patch/20221019123743.1282969-1-kevin.laatz@intel.com/
* PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
	- All test done. Find 3+ new issues, Intel dev are under investigating.		
* Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, RFC2544 Zero packet loss performance test, etc.
	- All test done. Issue about [22.11-rc1]iavf macfwd performance drop 40%, Dev revert the bad patch to fix.
* Power and IPsec: 
 * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc. 
	- All test done.
 * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc.
	- All test done. Find 2 new  bugs.
	- Bug https://bugs.dpdk.org/show_bug.cgi?id=1106 ipsec-secgw inline test fail
		- Can be fixed by https://patches.dpdk.org/project/dpdk/patch/20220930124055.2682935-1-radu.nicolau@intel.com/
# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u3, etc.
	- All test done. No new issue is found. 
	- Known issue's fix patch: http://patches.dpdk.org/project/dpdk/patch/20221011030803.16746-3-cheng1.jiang@intel.com/.
* Cryptodev: 
 *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
	- All test done. Find one bug about FIPS tests are failing, Intel dev are under investigating.
 *Performance test: test scenarios including Throughput Performance /Cryptodev Latency, etc.
	- All test done. No performance drop.

Best regards,
Yu Jiang

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2] eventdev: increase xstats ID width to 64 bits
  2022-10-13 11:35  1% ` [PATCH v2] " pbhagavatula
@ 2022-10-19 13:24  0%   ` Jerin Jacob
  0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-10-19 13:24 UTC (permalink / raw)
  To: pbhagavatula
  Cc: mb, jerinj, thomas, Shijith Thotton, Timothy McDaniel,
	Mattias Rönnblom, Liang Ma, Peter Mccarthy,
	Harry van Haaren, dev

On Thu, Oct 13, 2022 at 5:05 PM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Increase xstats ID width from 32 to 64 bits. This also
> fixes the xstats ID datatype discrepancy between reset and
> rest of the xstats family.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Reviewed-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>


Acked-by: Jerin Jacob <jerinj@marvell.com>
Applied to dpdk-next-net-eventdev/for-main. Thanks
> ---
>  v2 Changes:
>  - Fix compilation on 32 bit platforms. (Mattias)
>
>  doc/guides/rel_notes/release_22_11.rst   |   5 ++
>  drivers/event/cnxk/cnxk_eventdev.h       |   6 +-
>  drivers/event/cnxk/cnxk_eventdev_stats.c |   6 +-
>  drivers/event/dlb2/dlb2_priv.h           |   8 +-
>  drivers/event/dlb2/dlb2_xstats.c         |  18 ++--
>  drivers/event/dsw/dsw_evdev.h            |   6 +-
>  drivers/event/dsw/dsw_xstats.c           |  32 +++----
>  drivers/event/opdl/opdl_evdev.h          |   8 +-
>  drivers/event/opdl/opdl_evdev_xstats.c   |   8 +-
>  drivers/event/opdl/opdl_test.c           |   4 +-
>  drivers/event/sw/sw_evdev.h              |   8 +-
>  drivers/event/sw/sw_evdev_selftest.c     | 101 +++++++++++------------
>  drivers/event/sw/sw_evdev_xstats.c       |  18 ++--
>  lib/eventdev/eventdev_pmd.h              |   8 +-
>  lib/eventdev/rte_eventdev.c              |  12 +--
>  lib/eventdev/rte_eventdev.h              |   8 +-
>  16 files changed, 128 insertions(+), 128 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
> index 2da8bc9661..6b76ad5566 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -454,6 +454,11 @@ API Changes
>
>  * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
>
> +* eventdev: The datatype of the ID parameter in the functions
> +  ``rte_event_dev_xstats_names_get``, ``rte_event_dev_xstats_get``,
> +  ``rte_event_dev_xstats_by_name_get`` and ``rte_event_dev_xstats_reset``
> +  is changed to ``uint64_t`` from ``unsigned int`` and ``uint32_t``.
> +
>
>  ABI Changes
>  -----------
> diff --git a/drivers/event/cnxk/cnxk_eventdev.h b/drivers/event/cnxk/cnxk_eventdev.h
> index f68c2aee23..738e335ea4 100644
> --- a/drivers/event/cnxk/cnxk_eventdev.h
> +++ b/drivers/event/cnxk/cnxk_eventdev.h
> @@ -271,14 +271,14 @@ int cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
>                               enum rte_event_dev_xstats_mode mode,
>                               uint8_t queue_port_id,
>                               struct rte_event_dev_xstats_name *xstats_names,
> -                             unsigned int *ids, unsigned int size);
> +                             uint64_t *ids, unsigned int size);
>  int cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>                         enum rte_event_dev_xstats_mode mode,
> -                       uint8_t queue_port_id, const unsigned int ids[],
> +                       uint8_t queue_port_id, const uint64_t ids[],
>                         uint64_t values[], unsigned int n);
>  int cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
>                           enum rte_event_dev_xstats_mode mode,
> -                         int16_t queue_port_id, const uint32_t ids[],
> +                         int16_t queue_port_id, const uint64_t ids[],
>                           uint32_t n);
>
>  /* CN9K */
> diff --git a/drivers/event/cnxk/cnxk_eventdev_stats.c b/drivers/event/cnxk/cnxk_eventdev_stats.c
> index a3b548f462..715ca9cd8f 100644
> --- a/drivers/event/cnxk/cnxk_eventdev_stats.c
> +++ b/drivers/event/cnxk/cnxk_eventdev_stats.c
> @@ -103,7 +103,7 @@ static struct cnxk_sso_xstats_name sso_hwgrp_xstats[] = {
>  int
>  cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>                     enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -                   const unsigned int ids[], uint64_t values[], unsigned int n)
> +                   const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
>         struct roc_sso_hwgrp_stats hwgrp_stats;
> @@ -170,7 +170,7 @@ cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>  int
>  cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
>                       enum rte_event_dev_xstats_mode mode,
> -                     int16_t queue_port_id, const uint32_t ids[], uint32_t n)
> +                     int16_t queue_port_id, const uint64_t ids[], uint32_t n)
>  {
>         struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
>         struct roc_sso_hwgrp_stats hwgrp_stats;
> @@ -235,7 +235,7 @@ cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
>                           enum rte_event_dev_xstats_mode mode,
>                           uint8_t queue_port_id,
>                           struct rte_event_dev_xstats_name *xstats_names,
> -                         unsigned int *ids, unsigned int size)
> +                         uint64_t *ids, unsigned int size)
>  {
>         struct rte_event_dev_xstats_name xstats_names_copy[CNXK_SSO_NUM_XSTATS];
>         struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
> diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
> index 9ef5bcb901..52f0ab9935 100644
> --- a/drivers/event/dlb2/dlb2_priv.h
> +++ b/drivers/event/dlb2/dlb2_priv.h
> @@ -688,20 +688,20 @@ void dlb2_xstats_uninit(struct dlb2_eventdev *dlb2);
>
>  int dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n);
> +               const uint64_t ids[], uint64_t values[], unsigned int n);
>
>  int dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstat_names,
> -               unsigned int *ids, unsigned int size);
> +               uint64_t *ids, unsigned int size);
>
>  uint64_t dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
> -                                         const char *name, unsigned int *id);
> +                                         const char *name, uint64_t *id);
>
>  int dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 int16_t queue_port_id,
> -               const uint32_t ids[],
> +               const uint64_t ids[],
>                 uint32_t nb_ids);
>
>  int test_dlb2_eventdev(void);
> diff --git a/drivers/event/dlb2/dlb2_xstats.c b/drivers/event/dlb2/dlb2_xstats.c
> index d4c8d99034..ff15271dda 100644
> --- a/drivers/event/dlb2/dlb2_xstats.c
> +++ b/drivers/event/dlb2/dlb2_xstats.c
> @@ -666,7 +666,7 @@ int
>  dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size)
> +               uint64_t *ids, unsigned int size)
>  {
>         const struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>         unsigned int i;
> @@ -717,7 +717,7 @@ dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>  static int
>  dlb2_xstats_update(struct dlb2_eventdev *dlb2,
>                 enum rte_event_dev_xstats_mode mode,
> -               uint8_t queue_port_id, const unsigned int ids[],
> +               uint8_t queue_port_id, const uint64_t ids[],
>                 uint64_t values[], unsigned int n, const uint32_t reset)
>  {
>         unsigned int i;
> @@ -791,7 +791,7 @@ dlb2_xstats_update(struct dlb2_eventdev *dlb2,
>  int
>  dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n)
> +               const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>         const uint32_t reset = 0;
> @@ -802,7 +802,7 @@ dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>
>  uint64_t
>  dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
> -                                const char *name, unsigned int *id)
> +                                const char *name, uint64_t *id)
>  {
>         struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>         unsigned int i;
> @@ -876,7 +876,7 @@ dlb2_xstats_reset_range(struct dlb2_eventdev *dlb2, uint32_t start,
>
>  static int
>  dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
> -                       const uint32_t ids[], uint32_t nb_ids)
> +                       const uint64_t ids[], uint32_t nb_ids)
>  {
>         const uint32_t reset = 1;
>
> @@ -898,7 +898,7 @@ dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
>
>  static int
>  dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
> -                      const uint32_t ids[], uint32_t nb_ids)
> +                      const uint64_t ids[], uint32_t nb_ids)
>  {
>         const uint32_t reset = 1;
>         int offset = dlb2->xstats_offset_for_port[port_id];
> @@ -917,14 +917,14 @@ dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
>  }
>
>  static int
> -dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint32_t ids[],
> +dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint64_t ids[],
>                       uint32_t nb_ids)
>  {
>         uint32_t i;
>
>         if (ids) {
>                 for (i = 0; i < nb_ids; i++) {
> -                       uint32_t id = ids[i];
> +                       uint64_t id = ids[i];
>
>                         if (id >= dlb2->xstats_count_mode_dev)
>                                 return -EINVAL;
> @@ -942,7 +942,7 @@ int
>  dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
>                            enum rte_event_dev_xstats_mode mode,
>                            int16_t queue_port_id,
> -                          const uint32_t ids[],
> +                          const uint64_t ids[],
>                            uint32_t nb_ids)
>  {
>         struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
> diff --git a/drivers/event/dsw/dsw_evdev.h b/drivers/event/dsw/dsw_evdev.h
> index df7dcc5577..6416a8a898 100644
> --- a/drivers/event/dsw/dsw_evdev.h
> +++ b/drivers/event/dsw/dsw_evdev.h
> @@ -283,12 +283,12 @@ int dsw_xstats_get_names(const struct rte_eventdev *dev,
>                          enum rte_event_dev_xstats_mode mode,
>                          uint8_t queue_port_id,
>                          struct rte_event_dev_xstats_name *xstats_names,
> -                        unsigned int *ids, unsigned int size);
> +                        uint64_t *ids, unsigned int size);
>  int dsw_xstats_get(const struct rte_eventdev *dev,
>                    enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -                  const unsigned int ids[], uint64_t values[], unsigned int n);
> +                  const uint64_t ids[], uint64_t values[], unsigned int n);
>  uint64_t dsw_xstats_get_by_name(const struct rte_eventdev *dev,
> -                               const char *name, unsigned int *id);
> +                               const char *name, uint64_t *id);
>
>  static inline struct dsw_evdev *
>  dsw_pmd_priv(const struct rte_eventdev *eventdev)
> diff --git a/drivers/event/dsw/dsw_xstats.c b/drivers/event/dsw/dsw_xstats.c
> index 4f7d4e3ff9..2a83a28b41 100644
> --- a/drivers/event/dsw/dsw_xstats.c
> +++ b/drivers/event/dsw/dsw_xstats.c
> @@ -15,8 +15,8 @@
>   */
>  #define DSW_XSTATS_ID_PARAM_BITS (8)
>  #define DSW_XSTATS_ID_STAT_BITS                                        \
> -       (sizeof(unsigned int)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
> -#define DSW_XSTATS_ID_STAT_MASK ((1 << DSW_XSTATS_ID_STAT_BITS) - 1)
> +       (sizeof(uint64_t)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
> +#define DSW_XSTATS_ID_STAT_MASK ((UINT64_C(1) << DSW_XSTATS_ID_STAT_BITS) - 1)
>
>  #define DSW_XSTATS_ID_GET_PARAM(id)            \
>         ((id)>>DSW_XSTATS_ID_STAT_BITS)
> @@ -25,7 +25,7 @@
>         ((id) & DSW_XSTATS_ID_STAT_MASK)
>
>  #define DSW_XSTATS_ID_CREATE(id, param_value)                  \
> -       (((param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
> +       ((((uint64_t)param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
>
>  typedef
>  uint64_t (*dsw_xstats_dev_get_value_fn)(struct dsw_evdev *dsw);
> @@ -169,7 +169,7 @@ static struct dsw_xstats_port dsw_port_xstats[] = {
>  typedef
>  void (*dsw_xstats_foreach_fn)(const char *xstats_name,
>                               enum rte_event_dev_xstats_mode mode,
> -                             uint8_t queue_port_id, unsigned int xstats_id,
> +                             uint8_t queue_port_id, uint64_t xstats_id,
>                               void *data);
>
>  static void
> @@ -193,7 +193,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
>              stat_idx < RTE_DIM(dsw_port_xstats);) {
>                 struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
>                 char xstats_name[RTE_EVENT_DEV_XSTATS_NAME_SIZE];
> -               unsigned int xstats_id;
> +               uint64_t xstats_id;
>
>                 if (xstat->per_queue) {
>                         xstats_id = DSW_XSTATS_ID_CREATE(stat_idx, queue_id);
> @@ -219,7 +219,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
>
>  struct store_ctx {
>         struct rte_event_dev_xstats_name *names;
> -       unsigned int *ids;
> +       uint64_t *ids;
>         unsigned int count;
>         unsigned int capacity;
>  };
> @@ -227,7 +227,7 @@ struct store_ctx {
>  static void
>  dsw_xstats_store_stat(const char *xstats_name,
>                       enum rte_event_dev_xstats_mode mode,
> -                     uint8_t queue_port_id, unsigned int xstats_id,
> +                     uint8_t queue_port_id, uint64_t xstats_id,
>                       void *data)
>  {
>         struct store_ctx *ctx = data;
> @@ -248,7 +248,7 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
>                      enum rte_event_dev_xstats_mode mode,
>                      uint8_t queue_port_id,
>                      struct rte_event_dev_xstats_name *xstats_names,
> -                    unsigned int *ids, unsigned int capacity)
> +                    uint64_t *ids, unsigned int capacity)
>  {
>         struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>
> @@ -276,13 +276,13 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
>
>  static int
>  dsw_xstats_dev_get(const struct rte_eventdev *dev,
> -                  const unsigned int ids[], uint64_t values[], unsigned int n)
> +                  const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>         unsigned int i;
>
>         for (i = 0; i < n; i++) {
> -               unsigned int id = ids[i];
> +               uint64_t id = ids[i];
>                 struct dsw_xstat_dev *xstat = &dsw_dev_xstats[id];
>                 values[i] = xstat->get_value_fn(dsw);
>         }
> @@ -291,13 +291,13 @@ dsw_xstats_dev_get(const struct rte_eventdev *dev,
>
>  static int
>  dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
> -                   const unsigned int ids[], uint64_t values[], unsigned int n)
> +                   const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>         unsigned int i;
>
>         for (i = 0; i < n; i++) {
> -               unsigned int id = ids[i];
> +               uint64_t id = ids[i];
>                 unsigned int stat_idx = DSW_XSTATS_ID_GET_STAT(id);
>                 struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
>                 uint8_t queue_id = 0;
> @@ -313,7 +313,7 @@ dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
>  int
>  dsw_xstats_get(const struct rte_eventdev *dev,
>                enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -              const unsigned int ids[], uint64_t values[], unsigned int n)
> +              const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         switch (mode) {
>         case RTE_EVENT_DEV_XSTATS_DEVICE:
> @@ -332,14 +332,14 @@ dsw_xstats_get(const struct rte_eventdev *dev,
>  struct find_ctx {
>         const struct rte_eventdev *dev;
>         const char *name;
> -       unsigned int *id;
> +       uint64_t *id;
>         uint64_t value;
>  };
>
>  static void
>  dsw_xstats_find_stat(const char *xstats_name,
>                      enum rte_event_dev_xstats_mode mode,
> -                    uint8_t queue_port_id, unsigned int xstats_id,
> +                    uint8_t queue_port_id, uint64_t xstats_id,
>                      void *data)
>  {
>         struct find_ctx *ctx = data;
> @@ -354,7 +354,7 @@ dsw_xstats_find_stat(const char *xstats_name,
>
>  uint64_t
>  dsw_xstats_get_by_name(const struct rte_eventdev *dev, const char *name,
> -                      unsigned int *id)
> +                      uint64_t *id)
>  {
>         struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>         uint16_t port_id;
> diff --git a/drivers/event/opdl/opdl_evdev.h b/drivers/event/opdl/opdl_evdev.h
> index 2dca0a8a98..1ca166b37c 100644
> --- a/drivers/event/opdl/opdl_evdev.h
> +++ b/drivers/event/opdl/opdl_evdev.h
> @@ -289,16 +289,16 @@ int opdl_xstats_uninit(struct rte_eventdev *dev);
>  int opdl_xstats_get_names(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size);
> +               uint64_t *ids, unsigned int size);
>  int opdl_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n);
> +               const uint64_t ids[], uint64_t values[], unsigned int n);
>  uint64_t opdl_xstats_get_by_name(const struct rte_eventdev *dev,
> -               const char *name, unsigned int *id);
> +               const char *name, uint64_t *id);
>  int opdl_xstats_reset(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 int16_t queue_port_id,
> -               const uint32_t ids[],
> +               const uint64_t ids[],
>                 uint32_t nb_ids);
>
>  int opdl_add_event_handlers(struct rte_eventdev *dev);
> diff --git a/drivers/event/opdl/opdl_evdev_xstats.c b/drivers/event/opdl/opdl_evdev_xstats.c
> index 27b3d88023..b382f6619d 100644
> --- a/drivers/event/opdl/opdl_evdev_xstats.c
> +++ b/drivers/event/opdl/opdl_evdev_xstats.c
> @@ -65,7 +65,7 @@ opdl_xstats_get_names(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size)
> +               uint64_t *ids, unsigned int size)
>  {
>         struct opdl_evdev *device = opdl_pmd_priv(dev);
>
> @@ -99,7 +99,7 @@ int
>  opdl_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 uint8_t queue_port_id,
> -               const unsigned int ids[],
> +               const uint64_t ids[],
>                 uint64_t values[], unsigned int n)
>  {
>         struct opdl_evdev *device = opdl_pmd_priv(dev);
> @@ -133,7 +133,7 @@ opdl_xstats_get(const struct rte_eventdev *dev,
>
>  uint64_t
>  opdl_xstats_get_by_name(const struct rte_eventdev *dev,
> -               const char *name, unsigned int *id)
> +               const char *name, uint64_t *id)
>  {
>         struct opdl_evdev *device = opdl_pmd_priv(dev);
>
> @@ -161,7 +161,7 @@ opdl_xstats_get_by_name(const struct rte_eventdev *dev,
>  int
>  opdl_xstats_reset(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
> -               int16_t queue_port_id, const uint32_t ids[],
> +               int16_t queue_port_id, const uint64_t ids[],
>                 uint32_t nb_ids)
>  {
>         struct opdl_evdev *device = opdl_pmd_priv(dev);
> diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
> index 3cbe2139ee..b69c4769dc 100644
> --- a/drivers/event/opdl/opdl_test.c
> +++ b/drivers/event/opdl/opdl_test.c
> @@ -471,7 +471,7 @@ atomic_basic(struct test *t)
>         return 0;
>  }
>  static __rte_always_inline int
> -check_qid_stats(uint32_t id[], int index)
> +check_qid_stats(uint64_t id[], int index)
>  {
>
>         if (index == 0) {
> @@ -509,7 +509,7 @@ check_statistics(void)
>                                 0);
>                 if (num_stats > 0) {
>
> -                       uint32_t id[num_stats];
> +                       uint64_t id[num_stats];
>                         struct rte_event_dev_xstats_name names[num_stats];
>                         uint64_t values[num_stats];
>
> diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
> index 8542b7d34d..c7b943a72b 100644
> --- a/drivers/event/sw/sw_evdev.h
> +++ b/drivers/event/sw/sw_evdev.h
> @@ -301,16 +301,16 @@ int sw_xstats_uninit(struct sw_evdev *dev);
>  int sw_xstats_get_names(const struct rte_eventdev *dev,
>         enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>         struct rte_event_dev_xstats_name *xstats_names,
> -       unsigned int *ids, unsigned int size);
> +       uint64_t *ids, unsigned int size);
>  int sw_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n);
> +               const uint64_t ids[], uint64_t values[], unsigned int n);
>  uint64_t sw_xstats_get_by_name(const struct rte_eventdev *dev,
> -               const char *name, unsigned int *id);
> +               const char *name, uint64_t *id);
>  int sw_xstats_reset(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 int16_t queue_port_id,
> -               const uint32_t ids[],
> +               const uint64_t ids[],
>                 uint32_t nb_ids);
>
>  int test_sw_eventdev(void);
> diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
> index ed7ae6a685..62d66744f2 100644
> --- a/drivers/event/sw/sw_evdev_selftest.c
> +++ b/drivers/event/sw/sw_evdev_selftest.c
> @@ -92,7 +92,7 @@ xstats_print(void)
>  {
>         const uint32_t XSTATS_MAX = 1024;
>         uint32_t i;
> -       uint32_t ids[XSTATS_MAX];
> +       uint64_t ids[XSTATS_MAX];
>         uint64_t values[XSTATS_MAX];
>         struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>
> @@ -310,15 +310,14 @@ static inline int
>  test_event_dev_stats_get(int dev_id, struct test_event_dev_stats *stats)
>  {
>         static uint32_t i;
> -       static uint32_t total_ids[3]; /* rx, tx and drop */
> -       static uint32_t port_rx_pkts_ids[MAX_PORTS];
> -       static uint32_t port_rx_dropped_ids[MAX_PORTS];
> -       static uint32_t port_inflight_ids[MAX_PORTS];
> -       static uint32_t port_tx_pkts_ids[MAX_PORTS];
> -       static uint32_t qid_rx_pkts_ids[MAX_QIDS];
> -       static uint32_t qid_rx_dropped_ids[MAX_QIDS];
> -       static uint32_t qid_tx_pkts_ids[MAX_QIDS];
> -
> +       static uint64_t total_ids[3]; /* rx, tx and drop */
> +       static uint64_t port_rx_pkts_ids[MAX_PORTS];
> +       static uint64_t port_rx_dropped_ids[MAX_PORTS];
> +       static uint64_t port_inflight_ids[MAX_PORTS];
> +       static uint64_t port_tx_pkts_ids[MAX_PORTS];
> +       static uint64_t qid_rx_pkts_ids[MAX_QIDS];
> +       static uint64_t qid_rx_dropped_ids[MAX_QIDS];
> +       static uint64_t qid_tx_pkts_ids[MAX_QIDS];
>
>         stats->rx_pkts = rte_event_dev_xstats_by_name_get(dev_id,
>                         "dev_rx", &total_ids[0]);
> @@ -863,7 +862,7 @@ xstats_tests(struct test *t)
>         const uint32_t XSTATS_MAX = 1024;
>
>         uint32_t i;
> -       uint32_t ids[XSTATS_MAX];
> +       uint64_t ids[XSTATS_MAX];
>         uint64_t values[XSTATS_MAX];
>         struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>
> @@ -963,11 +962,10 @@ xstats_tests(struct test *t)
>         static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4, 1};
>         for (i = 0; (signed int)i < ret; i++) {
>                 if (expected[i] != values[i]) {
> -                       printf(
> -                               "%d Error xstat %d (id %d) %s : %"PRIu64
> -                               ", expect %"PRIu64"\n",
> -                               __LINE__, i, ids[i], xstats_names[i].name,
> -                               values[i], expected[i]);
> +                       printf("%d Error xstat %d (id %" PRIu64
> +                              ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +                              __LINE__, i, ids[i], xstats_names[i].name,
> +                              values[i], expected[i]);
>                         goto fail;
>                 }
>         }
> @@ -982,11 +980,10 @@ xstats_tests(struct test *t)
>                                         0, ids, values, num_stats);
>         for (i = 0; (signed int)i < ret; i++) {
>                 if (expected_zero[i] != values[i]) {
> -                       printf(
> -                               "%d Error, xstat %d (id %d) %s : %"PRIu64
> -                               ", expect %"PRIu64"\n",
> -                               __LINE__, i, ids[i], xstats_names[i].name,
> -                               values[i], expected_zero[i]);
> +                       printf("%d Error, xstat %d (id %" PRIu64
> +                              ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +                              __LINE__, i, ids[i], xstats_names[i].name,
> +                              values[i], expected_zero[i]);
>                         goto fail;
>                 }
>         }
> @@ -1058,11 +1055,10 @@ xstats_tests(struct test *t)
>                                         0, ids, values, num_stats);
>         for (i = 0; (signed int)i < ret; i++) {
>                 if (port_expected_zero[i] != values[i]) {
> -                       printf(
> -                               "%d, Error, xstat %d (id %d) %s : %"PRIu64
> -                               ", expect %"PRIu64"\n",
> -                               __LINE__, i, ids[i], xstats_names[i].name,
> -                               values[i], port_expected_zero[i]);
> +                       printf("%d, Error, xstat %d (id %" PRIu64
> +                              ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +                              __LINE__, i, ids[i], xstats_names[i].name,
> +                              values[i], port_expected_zero[i]);
>                         goto fail;
>                 }
>         }
> @@ -1095,11 +1091,10 @@ xstats_tests(struct test *t)
>         };
>         for (i = 0; (signed int)i < ret; i++) {
>                 if (queue_expected[i] != values[i]) {
> -                       printf(
> -                               "%d, Error, xstat %d (id %d) %s : %"PRIu64
> -                               ", expect %"PRIu64"\n",
> -                               __LINE__, i, ids[i], xstats_names[i].name,
> -                               values[i], queue_expected[i]);
> +                       printf("%d, Error, xstat %d (id %" PRIu64
> +                              ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +                              __LINE__, i, ids[i], xstats_names[i].name,
> +                              values[i], queue_expected[i]);
>                         goto fail;
>                 }
>         }
> @@ -1129,11 +1124,10 @@ xstats_tests(struct test *t)
>         int fails = 0;
>         for (i = 0; (signed int)i < ret; i++) {
>                 if (queue_expected_zero[i] != values[i]) {
> -                       printf(
> -                               "%d, Error, xstat %d (id %d) %s : %"PRIu64
> -                               ", expect %"PRIu64"\n",
> -                               __LINE__, i, ids[i], xstats_names[i].name,
> -                               values[i], queue_expected_zero[i]);
> +                       printf("%d, Error, xstat %d (id %" PRIu64
> +                              ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +                              __LINE__, i, ids[i], xstats_names[i].name,
> +                              values[i], queue_expected_zero[i]);
>                         fails++;
>                 }
>         }
> @@ -1160,7 +1154,7 @@ xstats_id_abuse_tests(struct test *t)
>         const uint32_t XSTATS_MAX = 1024;
>         const uint32_t link_port = 2;
>
> -       uint32_t ids[XSTATS_MAX];
> +       uint64_t ids[XSTATS_MAX];
>         struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>
>         /* Create instance with 4 ports */
> @@ -1379,7 +1373,7 @@ xstats_brute_force(struct test *t)
>  {
>         uint32_t i;
>         const uint32_t XSTATS_MAX = 1024;
> -       uint32_t ids[XSTATS_MAX];
> +       uint64_t ids[XSTATS_MAX];
>         uint64_t values[XSTATS_MAX];
>         struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>
> @@ -1454,7 +1448,7 @@ xstats_id_reset_tests(struct test *t)
>  #define XSTATS_MAX 1024
>         int ret;
>         uint32_t i;
> -       uint32_t ids[XSTATS_MAX];
> +       uint64_t ids[XSTATS_MAX];
>         uint64_t values[XSTATS_MAX];
>         struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>
> @@ -1510,13 +1504,14 @@ xstats_id_reset_tests(struct test *t)
>         };
>         uint64_t dev_expected[] = {NPKTS, NPKTS, 0, 1, 0, 0, 4, 1};
>         for (i = 0; (int)i < ret; i++) {
> -               unsigned int id;
> +               uint64_t id;
>                 uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>                                                                 dev_names[i],
>                                                                 &id);
>                 if (id != i) {
> -                       printf("%d: %s id incorrect, expected %d got %d\n",
> -                                       __LINE__, dev_names[i], i, id);
> +                       printf("%d: %s id incorrect, expected %d got %" PRIu64
> +                              "\n",
> +                              __LINE__, dev_names[i], i, id);
>                         goto fail;
>                 }
>                 if (val != dev_expected[i]) {
> @@ -1631,20 +1626,20 @@ xstats_id_reset_tests(struct test *t)
>
>         int failed = 0;
>         for (i = 0; (int)i < ret; i++) {
> -               unsigned int id;
> +               uint64_t id;
>                 uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>                                                                 port_names[i],
>                                                                 &id);
>                 if (id != i + PORT_OFF) {
> -                       printf("%d: %s id incorrect, expected %d got %d\n",
> -                                       __LINE__, port_names[i], i+PORT_OFF,
> -                                       id);
> +                       printf("%d: %s id incorrect, expected %d got %" PRIu64
> +                              "\n",
> +                              __LINE__, port_names[i], i + PORT_OFF, id);
>                         failed = 1;
>                 }
>                 if (val != port_expected[i]) {
> -                       printf("%d: %s value incorrect, expected %"PRIu64
> -                               " got %d\n", __LINE__, port_names[i],
> -                               port_expected[i], id);
> +                       printf("%d: %s value incorrect, expected %" PRIu64
> +                              " got %" PRIu64 "\n",
> +                              __LINE__, port_names[i], port_expected[i], id);
>                         failed = 1;
>                 }
>                 /* reset to zero */
> @@ -1746,14 +1741,14 @@ xstats_id_reset_tests(struct test *t)
>
>         failed = 0;
>         for (i = 0; (int)i < ret; i++) {
> -               unsigned int id;
> +               uint64_t id;
>                 uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>                                                                 queue_names[i],
>                                                                 &id);
>                 if (id != i + QUEUE_OFF) {
> -                       printf("%d: %s id incorrect, expected %d got %d\n",
> -                                       __LINE__, queue_names[i], i+QUEUE_OFF,
> -                                       id);
> +                       printf("%d: %s id incorrect, expected %d got %" PRIu64
> +                              "\n",
> +                              __LINE__, queue_names[i], i + QUEUE_OFF, id);
>                         failed = 1;
>                 }
>                 if (val != queue_expected[i]) {
> diff --git a/drivers/event/sw/sw_evdev_xstats.c b/drivers/event/sw/sw_evdev_xstats.c
> index c2647d7da2..fbac8f3ab5 100644
> --- a/drivers/event/sw/sw_evdev_xstats.c
> +++ b/drivers/event/sw/sw_evdev_xstats.c
> @@ -393,7 +393,7 @@ int
>  sw_xstats_get_names(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size)
> +               uint64_t *ids, unsigned int size)
>  {
>         const struct sw_evdev *sw = sw_pmd_priv_const(dev);
>         unsigned int i;
> @@ -444,7 +444,7 @@ sw_xstats_get_names(const struct rte_eventdev *dev,
>
>  static int
>  sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
> -               uint8_t queue_port_id, const unsigned int ids[],
> +               uint8_t queue_port_id, const uint64_t ids[],
>                 uint64_t values[], unsigned int n, const uint32_t reset,
>                 const uint32_t ret_if_n_lt_nstats)
>  {
> @@ -509,7 +509,7 @@ sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
>  int
>  sw_xstats_get(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n)
> +               const uint64_t ids[], uint64_t values[], unsigned int n)
>  {
>         struct sw_evdev *sw = sw_pmd_priv(dev);
>         const uint32_t reset = 0;
> @@ -520,7 +520,7 @@ sw_xstats_get(const struct rte_eventdev *dev,
>
>  uint64_t
>  sw_xstats_get_by_name(const struct rte_eventdev *dev,
> -               const char *name, unsigned int *id)
> +               const char *name, uint64_t *id)
>  {
>         const struct sw_evdev *sw = sw_pmd_priv_const(dev);
>         unsigned int i;
> @@ -556,7 +556,7 @@ sw_xstats_reset_range(struct sw_evdev *sw, uint32_t start, uint32_t num)
>
>  static int
>  sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
> -               const uint32_t ids[], uint32_t nb_ids)
> +               const uint64_t ids[], uint32_t nb_ids)
>  {
>         const uint32_t reset = 1;
>         const uint32_t ret_n_lt_stats = 0;
> @@ -577,7 +577,7 @@ sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
>
>  static int
>  sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
> -               const uint32_t ids[], uint32_t nb_ids)
> +               const uint64_t ids[], uint32_t nb_ids)
>  {
>         const uint32_t reset = 1;
>         const uint32_t ret_n_lt_stats = 0;
> @@ -597,12 +597,12 @@ sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
>  }
>
>  static int
> -sw_xstats_reset_dev(struct sw_evdev *sw, const uint32_t ids[], uint32_t nb_ids)
> +sw_xstats_reset_dev(struct sw_evdev *sw, const uint64_t ids[], uint32_t nb_ids)
>  {
>         uint32_t i;
>         if (ids) {
>                 for (i = 0; i < nb_ids; i++) {
> -                       uint32_t id = ids[i];
> +                       uint64_t id = ids[i];
>                         if (id >= sw->xstats_count_mode_dev)
>                                 return -EINVAL;
>                         sw_xstats_reset_range(sw, id, 1);
> @@ -619,7 +619,7 @@ int
>  sw_xstats_reset(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 int16_t queue_port_id,
> -               const uint32_t ids[],
> +               const uint64_t ids[],
>                 uint32_t nb_ids)
>  {
>         struct sw_evdev *sw = sw_pmd_priv(dev);
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index e49ff23db5..aebab26852 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -529,7 +529,7 @@ typedef void (*eventdev_dump_t)(struct rte_eventdev *dev, FILE *f);
>   */
>  typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -               const unsigned int ids[], uint64_t values[], unsigned int n);
> +               const uint64_t ids[], uint64_t values[], unsigned int n);
>
>  /**
>   * Resets the statistic values in xstats for the device, based on mode.
> @@ -537,7 +537,7 @@ typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
>  typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode,
>                 int16_t queue_port_id,
> -               const uint32_t ids[],
> +               const uint64_t ids[],
>                 uint32_t nb_ids);
>
>  /**
> @@ -564,7 +564,7 @@ typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
>  typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size);
> +               uint64_t *ids, unsigned int size);
>
>  /**
>   * Get value of one stats and optionally return its id
> @@ -582,7 +582,7 @@ typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
>   *   if id pointer is non-NULL
>   */
>  typedef uint64_t (*eventdev_xstats_get_by_name)(const struct rte_eventdev *dev,
> -               const char *name, unsigned int *id);
> +               const char *name, uint64_t *id);
>
>
>  /**
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index 845f8dbb6e..b0414206d9 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -1161,7 +1161,7 @@ int
>  rte_event_dev_xstats_names_get(uint8_t dev_id,
>                 enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>                 struct rte_event_dev_xstats_name *xstats_names,
> -               unsigned int *ids, unsigned int size)
> +               uint64_t *ids, unsigned int size)
>  {
>         RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
>         const int cnt_expected_entries = xstats_get_count(dev_id, mode,
> @@ -1183,7 +1183,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
>  /* retrieve eventdev extended statistics */
>  int
>  rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
> -               uint8_t queue_port_id, const unsigned int ids[],
> +               uint8_t queue_port_id, const uint64_t ids[],
>                 uint64_t values[], unsigned int n)
>  {
>         RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
> @@ -1198,11 +1198,11 @@ rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
>
>  uint64_t
>  rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
> -               unsigned int *id)
> +               uint64_t *id)
>  {
>         RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
>         const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> -       unsigned int temp = -1;
> +       uint64_t temp = -1;
>
>         if (id != NULL)
>                 *id = (unsigned int)-1;
> @@ -1217,7 +1217,7 @@ rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
>
>  int rte_event_dev_xstats_reset(uint8_t dev_id,
>                 enum rte_event_dev_xstats_mode mode, int16_t queue_port_id,
> -               const uint32_t ids[], uint32_t nb_ids)
> +               const uint64_t ids[], uint32_t nb_ids)
>  {
>         RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
>         struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> @@ -1658,7 +1658,7 @@ eventdev_build_telemetry_data(int dev_id,
>                               struct rte_tel_data *d)
>  {
>         struct rte_event_dev_xstats_name *xstat_names;
> -       unsigned int *ids;
> +       uint64_t *ids;
>         uint64_t *values;
>         int i, ret, num_xstats;
>
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 60e9043ac4..82e8976e57 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -1784,7 +1784,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
>                                enum rte_event_dev_xstats_mode mode,
>                                uint8_t queue_port_id,
>                                struct rte_event_dev_xstats_name *xstats_names,
> -                              unsigned int *ids,
> +                              uint64_t *ids,
>                                unsigned int size);
>
>  /**
> @@ -1817,7 +1817,7 @@ int
>  rte_event_dev_xstats_get(uint8_t dev_id,
>                          enum rte_event_dev_xstats_mode mode,
>                          uint8_t queue_port_id,
> -                        const unsigned int ids[],
> +                        const uint64_t ids[],
>                          uint64_t values[], unsigned int n);
>
>  /**
> @@ -1838,7 +1838,7 @@ rte_event_dev_xstats_get(uint8_t dev_id,
>   */
>  uint64_t
>  rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
> -                                unsigned int *id);
> +                                uint64_t *id);
>
>  /**
>   * Reset the values of the xstats of the selected component in the device.
> @@ -1864,7 +1864,7 @@ int
>  rte_event_dev_xstats_reset(uint8_t dev_id,
>                            enum rte_event_dev_xstats_mode mode,
>                            int16_t queue_port_id,
> -                          const uint32_t ids[],
> +                          const uint64_t ids[],
>                            uint32_t nb_ids);
>
>  /**
> --
> 2.25.1
>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] eventdev: update release notes
  2022-10-13  9:15 10% [PATCH] eventdev: update release notes pbhagavatula
@ 2022-10-19 13:00  0% ` Jerin Jacob
  0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-10-19 13:00 UTC (permalink / raw)
  To: pbhagavatula; +Cc: jerinj, dev

On Thu, Oct 13, 2022 at 2:48 PM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Update release notes for changes made in eventdev library.
>
> Fixes: 5fa63911e43b ("eventdev: replace padding type in event vector")
> Fixes: 0fbb55efa542 ("eventdev: add element offset to event vector")
> Fixes: d986276f9b72 ("eventdev: add prefix to public symbol")
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>


Updated the git commit as follows and applied to
dpdk-next-net-eventdev/for-main. Thanks

    doc: fix release note to include evendev changes

    Update release notes for changes made in eventdev library.

    Fixes: 5fa63911e43b ("eventdev: replace padding type in event vector")
    Fixes: 0fbb55efa542 ("eventdev: add element offset to event vector")
    Fixes: d986276f9b72 ("eventdev: add prefix to public symbol")

    Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
    Acked-by: Jerin Jacob <jerinj@marvell.com>

> ---
>  doc/guides/rel_notes/release_22_11.rst | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
> index 2da8bc9661..800dcf2b53 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -454,6 +454,9 @@ API Changes
>
>  * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
>
> +* eventdev: The function pointer definition ``eventdev_stop_flush_t`` is
> +  renamed to ``rte_eventdev_stop_flush_t`` to avoid conflicts with application
> +  symbols.
>
>  ABI Changes
>  -----------
> @@ -496,6 +499,13 @@ ABI Changes
>  * eventdev: Added ``weight`` and ``affinity`` fields
>    to ``rte_event_queue_conf`` structure.
>
> +* eventdev: The field ``*u64s`` in the structure ``rte_event_vector`` is replaced
> +  with ``u64s`` as the field is supposed to hold array of uint64_t values.
> +
> +* eventdev: The structure ``rte_event_vector`` was updated to include a new bit
> +  field ``elem_offset:12`` the bits are taken from the bitfield ``rsvd:15``.
> +  The element offset defines the offset into the vector array at
> +  which valid elements start.
>
>  Known Issues
>  ------------
> --
> 2.25.1
>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 03/24] net/nfp: add the flow APIs of nfp PMD
  2022-10-19 11:30  0%         ` Chaoyong He
@ 2022-10-19 11:38  0%           ` Ferruh Yigit
  0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-10-19 11:38 UTC (permalink / raw)
  To: Chaoyong He; +Cc: oss-drivers, Niklas Soderlund, dev

On 10/19/2022 12:30 PM, Chaoyong He wrote:
>> On 10/19/2022 4:00 AM, Chaoyong He wrote:
>>>> On 10/10/2022 7:08 AM, Chaoyong He wrote:
>>>>> Add the flow validate/create/query/destroy/flush API of nfp PMD.
>>>>>
>>>>> The flow create API construct a control cmsg and send it to
>>>>> firmware, then add this flow  to the hash table.
>>>>>
>>>>> The flow query API get flow stats from the flow_priv structure.
>>>>> Note there exist an rte_spin_lock to prevent the update and query
>>>>> action occur at the same time.
>>>>>
>>>>> The flow destroy API construct a control cmsg and send it to
>>>>> firmware, then adelete this flow from the hash table.
>>>>>
>>>>> The flow flush API just iterate the flows in hash table and call the
>>>>> flow destroy API.
>>>>>
>>>>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>>>>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>>>>
>>>> <...>
>>>>
>>>>> +static void
>>>>> +nfp_flow_stats_get(struct rte_eth_dev *dev,
>>>>> +             struct rte_flow *nfp_flow,
>>>>> +             void *data)
>>>>> +{
>>>>> +     uint32_t ctx_id;
>>>>> +     struct rte_flow *flow;
>>>>> +     struct nfp_flow_priv *priv;
>>>>> +     struct nfp_fl_stats *stats;
>>>>> +     struct rte_flow_query_count *query;
>>>>> +
>>>>> +     priv = nfp_flow_dev_to_priv(dev);
>>>>> +     flow = nfp_flow_table_search(priv, nfp_flow);
>>>>> +     if (flow == NULL) {
>>>>> +             PMD_DRV_LOG(ERR, "Can not find statistics for this flow.");
>>>>> +             return;
>>>>> +     }
>>>>> +
>>>>> +     query = (struct rte_flow_query_count *)data;
>>>>> +     ctx_id = rte_be_to_cpu_32(nfp_flow->payload.meta->host_ctx_id);
>>>>> +     stats = &priv->stats[ctx_id];
>>>>> +
>>>>> +     rte_spinlock_lock(&priv->stats_lock);
>>>>> +     if (stats->pkts && stats->bytes) {
>>>>
>>>> Is it guaranteed that 'query' ("void *data") is zeroed out when it is
>>>> provided by application?
>>>>
>>
>> Let me clarify this comment,
>>
>> When "stats->pkts == 0", not taken this branch and 'query' fields are not
>> updated. How caller can know if 'query' has random values or assigned values,
>> won't it be good to memset query.
>>
> 
> Okay, I understand it now. I'll revise like what you said in the next version patch, thanks.
> 
>>>>> +             query->hits = stats->pkts;
>>>>> +             query->bytes = stats->bytes;
>>>>> +             query->hits_set = 1;
>>>>> +             query->bytes_set = 1;
>>>>> +             stats->pkts = 0;
>>>>> +             stats->bytes = 0;
>>>>
>>>> need to check 'reset' field of action to decide reset or not.
>>>>
>>
>> And this one also seems not answered, to there is an attribute of action to
>> request resetting stats, above code ignores it.
>>
> 
> How about like this:
> ```
> 	if (stats->pkts != 0 && stats->bytes != 0) {
> 		query->hits = stats->pkts;
> 		query->bytes = stats->bytes;
> 		query->hits_set = 1;
> 		query->bytes_set = 1;
> 		if (query->reset != 0) {
> 	                             rte_spinlock_lock(&priv->stats_lock);
> 			stats->pkts = 0;
> 			stats->bytes = 0;
>                                             rte_spinlock_unlock(&priv->stats_lock);
> 		}

ack

> 	} else {
>                               memset(query, 0, sizeof(*query));
>                }

memset can go outside of the if block for simplicity, but both are OK, 
up to you.

> ```
> 
> And I'm not quite sure if I should add a check about the `reserved` field like this:
> ```
> 	query = (struct rte_flow_query_count *)data;
> 	if (query->reserved != 0) {
> 		PMD_DRV_LOG(ERR, "The reserved field should always be 0!");
> 		return;
> 	}
> ```

I don't think it is required to check reserved fields.

> 
>>>> <...>
>>>>
>>>>> @@ -75,6 +101,7 @@ struct nfp_fl_stats {
>>>>>
>>>>>     struct nfp_flow_priv {
>>>>>         uint32_t hash_seed; /**< Hash seed for hash tables in this
>>>>> structure. */
>>>>> +     uint64_t flower_version; /**< Flow version, always increase.
>>>>> + */
>>>>
>>>> Is this version to keep unique value per flow configuration? If so as
>>>> far as I can see '.validate' is updating this value, is this expected?
>>>>
>>>> Also who suppose to use this value?
>>>
>>> Yes, it is expected.
>>>
>>> This value is part of the nfp_flow_meta, and which is part of the flow
>>> offloaded to the firmware.
>>> And the content of the flow offloaded to the firmware is the ABI of
>>> the firmware, so it's can't easily change.
>>
>> I am not sure we are on same page. This variable is increased when a flow
>> rule is added or validated by application, how this is part of ABI?
>>
>> Also whenever application validates a flow this 'flower_version' value is
>> increased. Application is just validating the flow, not adding a flow so nothing
>> changes in the HW config.
>> And this increase in the 'flower_version' variable may cause driver/hw think
>> that config is changed?
> 
> Okay, I will revise to make sure the '.validate' won't change this value anymore, thanks.

ack

^ permalink raw reply	[relevance 0%]

* RE: [PATCH v2 03/24] net/nfp: add the flow APIs of nfp PMD
  2022-10-19 11:11  3%       ` Ferruh Yigit
@ 2022-10-19 11:30  0%         ` Chaoyong He
  2022-10-19 11:38  0%           ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: Chaoyong He @ 2022-10-19 11:30 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: oss-drivers, Niklas Soderlund, dev

> On 10/19/2022 4:00 AM, Chaoyong He wrote:
> >> On 10/10/2022 7:08 AM, Chaoyong He wrote:
> >>> Add the flow validate/create/query/destroy/flush API of nfp PMD.
> >>>
> >>> The flow create API construct a control cmsg and send it to
> >>> firmware, then add this flow  to the hash table.
> >>>
> >>> The flow query API get flow stats from the flow_priv structure.
> >>> Note there exist an rte_spin_lock to prevent the update and query
> >>> action occur at the same time.
> >>>
> >>> The flow destroy API construct a control cmsg and send it to
> >>> firmware, then adelete this flow from the hash table.
> >>>
> >>> The flow flush API just iterate the flows in hash table and call the
> >>> flow destroy API.
> >>>
> >>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> >>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
> >>
> >> <...>
> >>
> >>> +static void
> >>> +nfp_flow_stats_get(struct rte_eth_dev *dev,
> >>> +             struct rte_flow *nfp_flow,
> >>> +             void *data)
> >>> +{
> >>> +     uint32_t ctx_id;
> >>> +     struct rte_flow *flow;
> >>> +     struct nfp_flow_priv *priv;
> >>> +     struct nfp_fl_stats *stats;
> >>> +     struct rte_flow_query_count *query;
> >>> +
> >>> +     priv = nfp_flow_dev_to_priv(dev);
> >>> +     flow = nfp_flow_table_search(priv, nfp_flow);
> >>> +     if (flow == NULL) {
> >>> +             PMD_DRV_LOG(ERR, "Can not find statistics for this flow.");
> >>> +             return;
> >>> +     }
> >>> +
> >>> +     query = (struct rte_flow_query_count *)data;
> >>> +     ctx_id = rte_be_to_cpu_32(nfp_flow->payload.meta->host_ctx_id);
> >>> +     stats = &priv->stats[ctx_id];
> >>> +
> >>> +     rte_spinlock_lock(&priv->stats_lock);
> >>> +     if (stats->pkts && stats->bytes) {
> >>
> >> Is it guaranteed that 'query' ("void *data") is zeroed out when it is
> >> provided by application?
> >>
> 
> Let me clarify this comment,
> 
> When "stats->pkts == 0", not taken this branch and 'query' fields are not
> updated. How caller can know if 'query' has random values or assigned values,
> won't it be good to memset query.
> 

Okay, I understand it now. I'll revise like what you said in the next version patch, thanks.

> >>> +             query->hits = stats->pkts;
> >>> +             query->bytes = stats->bytes;
> >>> +             query->hits_set = 1;
> >>> +             query->bytes_set = 1;
> >>> +             stats->pkts = 0;
> >>> +             stats->bytes = 0;
> >>
> >> need to check 'reset' field of action to decide reset or not.
> >>
> 
> And this one also seems not answered, to there is an attribute of action to
> request resetting stats, above code ignores it.
> 

How about like this:
```
	if (stats->pkts != 0 && stats->bytes != 0) {
		query->hits = stats->pkts;
		query->bytes = stats->bytes;
		query->hits_set = 1;
		query->bytes_set = 1;
		if (query->reset != 0) {
	                             rte_spinlock_lock(&priv->stats_lock);
			stats->pkts = 0;
			stats->bytes = 0;
                                           rte_spinlock_unlock(&priv->stats_lock);
		}
	} else {
                             memset(query, 0, sizeof(*query));
              }
```

And I'm not quite sure if I should add a check about the `reserved` field like this:
```
	query = (struct rte_flow_query_count *)data;
	if (query->reserved != 0) {
		PMD_DRV_LOG(ERR, "The reserved field should always be 0!");
		return;
	}
```

> >> <...>
> >>
> >>> @@ -75,6 +101,7 @@ struct nfp_fl_stats {
> >>>
> >>>    struct nfp_flow_priv {
> >>>        uint32_t hash_seed; /**< Hash seed for hash tables in this
> >>> structure. */
> >>> +     uint64_t flower_version; /**< Flow version, always increase.
> >>> + */
> >>
> >> Is this version to keep unique value per flow configuration? If so as
> >> far as I can see '.validate' is updating this value, is this expected?
> >>
> >> Also who suppose to use this value?
> >
> > Yes, it is expected.
> >
> > This value is part of the nfp_flow_meta, and which is part of the flow
> > offloaded to the firmware.
> > And the content of the flow offloaded to the firmware is the ABI of
> > the firmware, so it's can't easily change.
> 
> I am not sure we are on same page. This variable is increased when a flow
> rule is added or validated by application, how this is part of ABI?
> 
> Also whenever application validates a flow this 'flower_version' value is
> increased. Application is just validating the flow, not adding a flow so nothing
> changes in the HW config.
> And this increase in the 'flower_version' variable may cause driver/hw think
> that config is changed?

Okay, I will revise to make sure the '.validate' won't change this value anymore, thanks.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 03/24] net/nfp: add the flow APIs of nfp PMD
  2022-10-19  3:00  3%     ` Chaoyong He
@ 2022-10-19 11:11  3%       ` Ferruh Yigit
  2022-10-19 11:30  0%         ` Chaoyong He
  0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-10-19 11:11 UTC (permalink / raw)
  To: Chaoyong He; +Cc: oss-drivers, Niklas Soderlund, dev

On 10/19/2022 4:00 AM, Chaoyong He wrote:
>> On 10/10/2022 7:08 AM, Chaoyong He wrote:
>>> Add the flow validate/create/query/destroy/flush API of nfp PMD.
>>>
>>> The flow create API construct a control cmsg and send it to firmware,
>>> then add this flow  to the hash table.
>>>
>>> The flow query API get flow stats from the flow_priv structure.
>>> Note there exist an rte_spin_lock to prevent the update and query
>>> action occur at the same time.
>>>
>>> The flow destroy API construct a control cmsg and send it to firmware,
>>> then adelete this flow from the hash table.
>>>
>>> The flow flush API just iterate the flows in hash table and call the
>>> flow destroy API.
>>>
>>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>>
>> <...>
>>
>>> +static void
>>> +nfp_flow_stats_get(struct rte_eth_dev *dev,
>>> +             struct rte_flow *nfp_flow,
>>> +             void *data)
>>> +{
>>> +     uint32_t ctx_id;
>>> +     struct rte_flow *flow;
>>> +     struct nfp_flow_priv *priv;
>>> +     struct nfp_fl_stats *stats;
>>> +     struct rte_flow_query_count *query;
>>> +
>>> +     priv = nfp_flow_dev_to_priv(dev);
>>> +     flow = nfp_flow_table_search(priv, nfp_flow);
>>> +     if (flow == NULL) {
>>> +             PMD_DRV_LOG(ERR, "Can not find statistics for this flow.");
>>> +             return;
>>> +     }
>>> +
>>> +     query = (struct rte_flow_query_count *)data;
>>> +     ctx_id = rte_be_to_cpu_32(nfp_flow->payload.meta->host_ctx_id);
>>> +     stats = &priv->stats[ctx_id];
>>> +
>>> +     rte_spinlock_lock(&priv->stats_lock);
>>> +     if (stats->pkts && stats->bytes) {
>>
>> Is it guaranteed that 'query' ("void *data") is zeroed out when it is provided
>> by application?
>>

Let me clarify this comment,

When "stats->pkts == 0", not taken this branch and 'query' fields are 
not updated. How caller can know if 'query' has random values or 
assigned values, won't it be good to memset query.

>>> +             query->hits = stats->pkts;
>>> +             query->bytes = stats->bytes;
>>> +             query->hits_set = 1;
>>> +             query->bytes_set = 1;
>>> +             stats->pkts = 0;
>>> +             stats->bytes = 0;
>>
>> need to check 'reset' field of action to decide reset or not.
>>

And this one also seems not answered, to there is an attribute of action 
to request resetting stats, above code ignores it.

>> <...>
>>
>>> @@ -75,6 +101,7 @@ struct nfp_fl_stats {
>>>
>>>    struct nfp_flow_priv {
>>>        uint32_t hash_seed; /**< Hash seed for hash tables in this
>>> structure. */
>>> +     uint64_t flower_version; /**< Flow version, always increase. */
>>
>> Is this version to keep unique value per flow configuration? If so as far as I
>> can see '.validate' is updating this value, is this expected?
>>
>> Also who suppose to use this value?
> 
> Yes, it is expected.
> 
> This value is part of the nfp_flow_meta, and which is part of the flow offloaded
> to the firmware.
> And the content of the flow offloaded to the firmware is the ABI of the firmware,
> so it's can't easily change.

I am not sure we are on same page. This variable is increased when a 
flow rule is added or validated by application, how this is part of ABI?

Also whenever application validates a flow this 'flower_version' value 
is increased. Application is just validating the flow, not adding a flow 
so nothing changes in the HW config.
And this increase in the 'flower_version' variable may cause driver/hw 
think that config is changed?

^ permalink raw reply	[relevance 3%]

* RE: [PATCH v2 03/24] net/nfp: add the flow APIs of nfp PMD
  @ 2022-10-19  3:00  3%     ` Chaoyong He
  2022-10-19 11:11  3%       ` Ferruh Yigit
  0 siblings, 1 reply; 200+ results
From: Chaoyong He @ 2022-10-19  3:00 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: oss-drivers, Niklas Soderlund, dev

> On 10/10/2022 7:08 AM, Chaoyong He wrote:
> > Add the flow validate/create/query/destroy/flush API of nfp PMD.
> >
> > The flow create API construct a control cmsg and send it to firmware,
> > then add this flow  to the hash table.
> >
> > The flow query API get flow stats from the flow_priv structure.
> > Note there exist an rte_spin_lock to prevent the update and query
> > action occur at the same time.
> >
> > The flow destroy API construct a control cmsg and send it to firmware,
> > then adelete this flow from the hash table.
> >
> > The flow flush API just iterate the flows in hash table and call the
> > flow destroy API.
> >
> > Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
> > Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
> 
> <...>
> 
> > +static void
> > +nfp_flow_stats_get(struct rte_eth_dev *dev,
> > +             struct rte_flow *nfp_flow,
> > +             void *data)
> > +{
> > +     uint32_t ctx_id;
> > +     struct rte_flow *flow;
> > +     struct nfp_flow_priv *priv;
> > +     struct nfp_fl_stats *stats;
> > +     struct rte_flow_query_count *query;
> > +
> > +     priv = nfp_flow_dev_to_priv(dev);
> > +     flow = nfp_flow_table_search(priv, nfp_flow);
> > +     if (flow == NULL) {
> > +             PMD_DRV_LOG(ERR, "Can not find statistics for this flow.");
> > +             return;
> > +     }
> > +
> > +     query = (struct rte_flow_query_count *)data;
> > +     ctx_id = rte_be_to_cpu_32(nfp_flow->payload.meta->host_ctx_id);
> > +     stats = &priv->stats[ctx_id];
> > +
> > +     rte_spinlock_lock(&priv->stats_lock);
> > +     if (stats->pkts && stats->bytes) {
> 
> Is it guaranteed that 'query' ("void *data") is zeroed out when it is provided
> by application?
> 
> > +             query->hits = stats->pkts;
> > +             query->bytes = stats->bytes;
> > +             query->hits_set = 1;
> > +             query->bytes_set = 1;
> > +             stats->pkts = 0;
> > +             stats->bytes = 0;
> 
> need to check 'reset' field of action to decide reset or not.
> 
> <...>
> 
> > @@ -75,6 +101,7 @@ struct nfp_fl_stats {
> >
> >   struct nfp_flow_priv {
> >       uint32_t hash_seed; /**< Hash seed for hash tables in this
> > structure. */
> > +     uint64_t flower_version; /**< Flow version, always increase. */
> 
> Is this version to keep unique value per flow configuration? If so as far as I
> can see '.validate' is updating this value, is this expected?
> 
> Also who suppose to use this value?

Yes, it is expected.

This value is part of the nfp_flow_meta, and which is part of the flow offloaded
to the firmware.
And the content of the flow offloaded to the firmware is the ABI of the firmware,
so it's can't easily change. 

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v6 3/4] mempool: fix cache flushing algorithm
  2022-10-15  6:57  0%                 ` Morten Brørup
@ 2022-10-18 16:32  0%                   ` Jerin Jacob
  0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2022-10-18 16:32 UTC (permalink / raw)
  To: Morten Brørup; +Cc: Olivier Matz, Andrew Rybchenko, dev, Bruce Richardson

On Sat, Oct 15, 2022 at 12:27 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Friday, 14 October 2022 21.51
> >
> > On Fri, Oct 14, 2022 at 05:57:39PM +0200, Morten Brørup wrote:
> > > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > > Sent: Friday, 14 October 2022 16.01
> > > >
> > > > Hi Morten, Andrew,
> > > >
> > > > On Sun, Oct 09, 2022 at 05:08:39PM +0200, Morten Brørup wrote:
> > > > > > From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > > > Sent: Sunday, 9 October 2022 16.52
> > > > > >
> > > > > > On 10/9/22 17:31, Morten Brørup wrote:
> > > > > > >> From: Andrew Rybchenko
> > [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > > > >> Sent: Sunday, 9 October 2022 15.38
> > > > > > >>
> > > > > > >> From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > >>
> > > > >
> > > > > [...]
> > > >
> > > > I finally took a couple of hours to carefully review the mempool-
> > > > related
> > > > series (including the ones that have already been pushed).
> > > >
> > > > The new behavior looks better to me in all situations I can think
> > > > about.
> > >
> > > Extreme care is required when touching a core library like the
> > mempool.
> > >
> > > Thank you, Olivier.
> > >
> > > >
> > > > >
> > > > > > >> --- a/lib/mempool/rte_mempool.h
> > > > > > >> +++ b/lib/mempool/rte_mempool.h
> > > > > > >> @@ -90,7 +90,7 @@ struct rte_mempool_cache {
> > > > > > >>     * Cache is allocated to this size to allow it to
> > overflow
> > > > in
> > > > > > >> certain
> > > > > > >>     * cases to avoid needless emptying of cache.
> > > > > > >>     */
> > > > > > >> -  void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**<
> > Cache
> > > > objects */
> > > > > > >> +  void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**<
> > Cache
> > > > objects */
> > > > > > >>   } __rte_cache_aligned;
> > > > > > >
> > > > > > > How much are we allowed to break the ABI here?
> > > > > > >
> > > > > > > This patch reduces the size of the structure by removing a
> > now
> > > > unused
> > > > > > part at the end, which should be harmless.
> > > >
> > > > It is an ABI breakage: an existing application will use the new
> > 22.11
> > > > function to create the mempool (with a smaller cache), but will use
> > the
> > > > old inlined get/put that can exceed MAX_SIZE x 2 will remain.
> > > >
> > > > But this is a nice memory consumption improvement, in my opinion we
> > > > should accept it for 22.11 with an entry in the release note.
> > > >
> > > >
> > > > > > >
> > > > > > > If we may also move the position of the objs array, I would
> > add
> > > > > > __rte_cache_aligned to the objs array. It makes no difference
> > in
> > > > the
> > > > > > general case, but if get/put operations are always 32 objects,
> > it
> > > > will
> > > > > > reduce the number of memory (or last level cache) accesses from
> > > > five to
> > > > > > four 64 B cache lines for every get/put operation.
> > > >
> > > > Will it really be the case? Since cache->len has to be accessed
> > too,
> > > > I don't think it would make a difference.
> > >
> > > Yes, the first cache line, containing cache->len, will be accessed
> > always. I forgot to count that; so the improvement by aligning cache-
> > >objs will be five cache line accesses instead of six.
> > >
> > > Let me try to explain the scenario in other words:
> > >
> > > In an application where a mempool cache is only accessed in bursts of
> > 32 objects (256 B), it matters if those 256 B accesses in the mempool
> > cache start at a cache line aligned address or not. If cache line
> > aligned, accessing those 256 B in the mempool cache will only touch 4
> > cache lines; if not, 5 cache lines will be touched. (For architectures
> > with 128 B cache line, it will be 2 instead of 3 touched cache lines
> > per mempool cache get/put operation in applications using only bursts
> > of 32 objects.)
> > >
> > > If we cache line align cache->objs, those bursts of 32 objects (256
> > B) will be cache line aligned: Any address at cache->objs[N * 32
> > objects] is cache line aligned if objs->objs[0] is cache line aligned.
> > >
> > > Currently, the cache->objs directly follows cache->len, which makes
> > cache->objs[0] cache line unaligned.
> > >
> > > If we decide to break the mempool cache ABI, we might as well include
> > my suggested cache line alignment performance improvement. It doesn't
> > degrade performance for mempool caches not only accessed in bursts of
> > 32 objects.
> >
> > I don't follow you. Currently, with 16 objects (128B), we access to 3
> > cache lines:
> >
> >       ┌────────┐
> >       │len     │
> > cache │********│---
> > line0 │********│ ^
> >       │********│ |
> >       ├────────┤ | 16 objects
> >       │********│ | 128B
> > cache │********│ |
> > line1 │********│ |
> >       │********│ |
> >       ├────────┤ |
> >       │********│_v_
> > cache │        │
> > line2 │        │
> >       │        │
> >       └────────┘
> >
> > With the alignment, it is also 3 cache lines:
> >
> >       ┌────────┐
> >       │len     │
> > cache │        │
> > line0 │        │
> >       │        │
> >       ├────────┤---
> >       │********│ ^
> > cache │********│ |
> > line1 │********│ |
> >       │********│ |
> >       ├────────┤ | 16 objects
> >       │********│ | 128B
> > cache │********│ |
> > line2 │********│ |
> >       │********│ v
> >       └────────┘---
> >
> >
> > Am I missing something?
>
> Accessing the objects at the bottom of the mempool cache is a special case, where cache line0 is also used for objects.
>
> Consider the next burst (and any following bursts):
>
> Current:
>       ┌────────┐
>       │len     │
> cache │        │
> line0 │        │
>       │        │
>       ├────────┤
>       │        │
> cache │        │
> line1 │        │
>       │        │
>       ├────────┤
>       │        │
> cache │********│---
> line2 │********│ ^
>       │********│ |
>       ├────────┤ | 16 objects
>       │********│ | 128B
> cache │********│ |
> line3 │********│ |
>       │********│ |
>       ├────────┤ |
>       │********│_v_
> cache │        │
> line4 │        │
>       │        │
>       └────────┘
> 4 cache lines touched, incl. line0 for len.
>
> With the proposed alignment:
>       ┌────────┐
>       │len     │
> cache │        │
> line0 │        │
>       │        │
>       ├────────┤
>       │        │
> cache │        │
> line1 │        │
>       │        │
>       ├────────┤
>       │        │
> cache │        │
> line2 │        │
>       │        │
>       ├────────┤
>       │********│---
> cache │********│ ^
> line3 │********│ |
>       │********│ | 16 objects
>       ├────────┤ | 128B
>       │********│ |
> cache │********│ |
> line4 │********│ |
>       │********│_v_
>       └────────┘
> Only 3 cache lines touched, incl. line0 for len.


When tested with testpmd,l3fwd there was less than 1% regression. It
could be noise.
But making the cacheline alignment is fixing that.

In addition to @Morten Brørup  point, I think, there is a factor
"load" stall on cache->len read, What I meant by that is:

In the case  of (len and objs) are in the same cache line. Assume objs
are written as stores operation and not read anything on cacheline
VS a few stores done for objects and on subsequent len read via
enqueue operation may stall based where those obj reached in
the cache hierarchy and cache policy(write-back vs write-through)

If we are seeing no regression with cachealinged with various platform
testing then I think it make sense to make cache aligned.

>
>
> >
> > >
> > > >
> > > >
> > > > > > >
> > > > > > >     uint32_t len;         /**< Current cache count */
> > > > > > > -   /*
> > > > > > > -    * Cache is allocated to this size to allow it to overflow
> > > > in
> > > > > > certain
> > > > > > > -    * cases to avoid needless emptying of cache.
> > > > > > > -    */
> > > > > > > -   void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> > > > objects */
> > > > > > > +   /**
> > > > > > > +    * Cache objects
> > > > > > > +    *
> > > > > > > +    * Cache is allocated to this size to allow it to overflow
> > > > in
> > > > > > certain
> > > > > > > +    * cases to avoid needless emptying of cache.
> > > > > > > +    */
> > > > > > > +   void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> > > > __rte_cache_aligned;
> > > > > > > } __rte_cache_aligned;
> > > > > >
> > > > > > I think aligning objs on cacheline should be a separate patch.
> > > > >
> > > > > Good point. I'll let you do it. :-)
> > > > >
> > > > > PS: Thank you for following up on this patch series, Andrew!
> > > >
> > > > Many thanks for this rework.
> > > >
> > > > Acked-by: Olivier Matz <olivier.matz@6wind.com>
> > >
> > > Perhaps Reviewed-by would be appropriate?
> >
> > I was thinking that "Acked-by" was commonly used by maintainers, and
> > "Reviewed-by" for reviews by community members. After reading the
> > documentation again, it's not that clear now in my mind :)
> >
> > Thanks,
> > Olivier
>

^ permalink raw reply	[relevance 0%]

* [PATCH] ci: combine static and shared linking build tests
@ 2022-10-17 14:07  3% David Marchand
  2022-10-20 11:44  0% ` David Marchand
  2022-10-20 15:34  0% ` Aaron Conole
  0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-10-17 14:07 UTC (permalink / raw)
  To: dev; +Cc: Aaron Conole, Michael Santana

Save some cpu time and disk by testing linking against static and shared
library in single environments.

The .ci/linux-build.sh is modified so it reconfigures an existing build
directory: an empty DEF_LIB= means that static and shared builds are
to be tested.

ABI checks, documentation generation and unit tests are disabled for
static builds as they would be redundant with the check against
dynamically linked binaries, if any.

Note:
- --cross-file is an option that can be passed to meson only when
  creating a build environment,
- for some other reason, --buildtype and other non -D options are only
  accepted when setting up a build directory with meson. When
  reconfiguring, only their -D$option forms are accepted,

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 .ci/linux-build.sh          | 25 ++++++++++++++++++-------
 .github/workflows/build.yml | 28 ----------------------------
 2 files changed, 18 insertions(+), 35 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 14148fef4a..baec65a914 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -1,5 +1,11 @@
 #!/bin/sh -xe
 
+if [ -z "${DEF_LIB:-}" ]; then
+    DEF_LIB=static ABI_CHECKS= BUILD_DOCS= RUN_TESTS= $0
+    DEF_LIB=shared $0
+    exit
+fi
+
 # Builds are run as root in containers, no need for sudo
 [ "$(id -u)" != '0' ] || alias sudo=
 
@@ -78,10 +84,6 @@ if [ "$RISCV64" = "true" ]; then
     cross_file=config/riscv/riscv64_linux_gcc
 fi
 
-if [ -n "$cross_file" ]; then
-    OPTS="$OPTS --cross-file $cross_file"
-fi
-
 if [ "$BUILD_DOCS" = "true" ]; then
     OPTS="$OPTS -Denable_docs=true"
 fi
@@ -101,8 +103,8 @@ else
 fi
 
 OPTS="$OPTS -Dplatform=generic"
-OPTS="$OPTS --default-library=$DEF_LIB"
-OPTS="$OPTS --buildtype=debugoptimized"
+OPTS="$OPTS -Ddefault_library=$DEF_LIB"
+OPTS="$OPTS -Dbuildtype=debugoptimized"
 OPTS="$OPTS -Dcheck_includes=true"
 if [ "$MINI" = "true" ]; then
     OPTS="$OPTS -Denable_drivers=net/null"
@@ -118,7 +120,16 @@ if [ "$ASAN" = "true" ]; then
     fi
 fi
 
-meson build --werror $OPTS
+OPTS="$OPTS -Dwerror=true"
+
+if [ -d build ]; then
+    meson configure build $OPTS
+else
+    if [ -n "$cross_file" ]; then
+        OPTS="$OPTS --cross-file $cross_file"
+    fi
+    meson setup build $OPTS
+fi
 ninja -C build
 
 if [ -z "$cross_file" ]; then
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index b32758ff6f..82d83f4030 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -35,21 +35,12 @@ jobs:
         config:
           - os: ubuntu-20.04
             compiler: gcc
-            library: static
-          - os: ubuntu-20.04
-            compiler: gcc
-            library: shared
             mini: mini
           - os: ubuntu-20.04
             compiler: gcc
-            library: shared
             checks: doc+tests
           - os: ubuntu-20.04
             compiler: clang
-            library: static
-          - os: ubuntu-20.04
-            compiler: clang
-            library: shared
             checks: asan+doc+tests
           - os: ubuntu-20.04
             compiler: gcc
@@ -61,23 +52,12 @@ jobs:
             cross: mingw
           - os: ubuntu-20.04
             compiler: gcc
-            library: static
-            cross: aarch64
-          - os: ubuntu-20.04
-            compiler: gcc
-            library: shared
             cross: aarch64
           - os: ubuntu-20.04
             compiler: gcc
-            library: static
             cross: ppc64le
           - os: ubuntu-20.04
             compiler: gcc
-            library: shared
-            cross: ppc64le
-          - os: ubuntu-20.04
-            compiler: gcc
-            library: shared
             cross: riscv64
 
     steps:
@@ -218,16 +198,8 @@ jobs:
         config:
           - image: fedora:35
             compiler: gcc
-            library: static
-          - image: fedora:35
-            compiler: gcc
-            library: shared
-          - image: fedora:35
-            compiler: clang
-            library: static
           - image: fedora:35
             compiler: clang
-            library: shared
 
     steps:
     - name: Checkout sources
-- 
2.37.3


^ permalink raw reply	[relevance 3%]

* Re: [PATCH] vhost: promote per-queue stats API to stable
  @ 2022-10-17 13:22  0% ` David Marchand
  2022-10-24  8:53  0% ` Xia, Chenbo
  2022-10-26  9:31  0% ` Xia, Chenbo
  2 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-10-17 13:22 UTC (permalink / raw)
  To: Maxime Coquelin; +Cc: dev, chenbo.xia

On Mon, Oct 10, 2022 at 5:37 PM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
>
> This patch promotes the per-queue stats API to stable.
> The API has been used by the Vhost PMD since v22.07, and
> David Marchand posted a patch to make use of it in next
> OVS release[0].
>
> [0]: http://patchwork.ozlabs.org/project/openvswitch/patch/20221007111613.1695524-4-david.marchand@redhat.com/
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  doc/guides/rel_notes/release_22_11.rst | 4 ++++
>  lib/vhost/rte_vhost.h                  | 3 ---
>  lib/vhost/version.map                  | 6 +++---
>  3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
> index 37bd392f34..d5d3eeae24 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -443,6 +443,10 @@ API Changes
>
>  * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
>

Nit: in the RN, vhost library updates go earlier.


> +* vhost: Promoted ``rte_vhost_vring_stats_get()``,
> +  ``rte_vhost_vring_stats_get_names()`` and ``rte_vhost_vring_stats_reset()``
> +  from experimental to stable.
> +
>
>  ABI Changes
>  -----------
> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
> index bb7d86a432..59c98a0afb 100644
> --- a/lib/vhost/rte_vhost.h
> +++ b/lib/vhost/rte_vhost.h
> @@ -1075,7 +1075,6 @@ rte_vhost_slave_config_change(int vid, bool need_reply);
>   *  - Failure if lower than 0. The device ID or queue ID is invalid or
>   +    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get_names(int vid, uint16_t queue_id,
>                 struct rte_vhost_stat_name *name, unsigned int size);
> @@ -1103,7 +1102,6 @@ rte_vhost_vring_stats_get_names(int vid, uint16_t queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>                 struct rte_vhost_stat *stats, unsigned int n);
> @@ -1120,7 +1118,6 @@ rte_vhost_vring_stats_get(int vid, uint16_t queue_id,
>   *  - Failure if lower than 0. The device ID or queue ID is invalid, or
>   *    statistics collection is not enabled.
>   */
> -__rte_experimental
>  int
>  rte_vhost_vring_stats_reset(int vid, uint16_t queue_id);
>
> diff --git a/lib/vhost/version.map b/lib/vhost/version.map
> index 7a00b65740..8c5e8aa8d3 100644
> --- a/lib/vhost/version.map
> +++ b/lib/vhost/version.map
> @@ -57,6 +57,9 @@ DPDK_23 {
>         rte_vhost_set_vring_base;
>         rte_vhost_va_from_guest_pa;
>         rte_vhost_vring_call;
> +       rte_vhost_vring_stats_get;
> +       rte_vhost_vring_stats_get_names;
> +       rte_vhost_vring_stats_reset;
>
>         local: *;
>  };
> @@ -88,9 +91,6 @@ EXPERIMENTAL {
>
>         # added in 22.07
>         rte_vhost_async_get_inflight_thread_unsafe;
> -       rte_vhost_vring_stats_get_names;
> -       rte_vhost_vring_stats_get;
> -       rte_vhost_vring_stats_reset;
>         rte_vhost_async_try_dequeue_burst;
>         rte_vhost_driver_get_vdpa_dev_type;
>         rte_vhost_clear_queue;
> --
> 2.37.3
>

Acked-by: David Marchand <david.marchand@redhat.com>


-- 
David Marchand


^ permalink raw reply	[relevance 0%]

* RE: [PATCH v6 3/4] mempool: fix cache flushing algorithm
  2022-10-14 19:50  0%               ` Olivier Matz
@ 2022-10-15  6:57  0%                 ` Morten Brørup
  2022-10-18 16:32  0%                   ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-10-15  6:57 UTC (permalink / raw)
  To: Olivier Matz; +Cc: Andrew Rybchenko, dev, Bruce Richardson

> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Friday, 14 October 2022 21.51
> 
> On Fri, Oct 14, 2022 at 05:57:39PM +0200, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Friday, 14 October 2022 16.01
> > >
> > > Hi Morten, Andrew,
> > >
> > > On Sun, Oct 09, 2022 at 05:08:39PM +0200, Morten Brørup wrote:
> > > > > From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > > Sent: Sunday, 9 October 2022 16.52
> > > > >
> > > > > On 10/9/22 17:31, Morten Brørup wrote:
> > > > > >> From: Andrew Rybchenko
> [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > > >> Sent: Sunday, 9 October 2022 15.38
> > > > > >>
> > > > > >> From: Morten Brørup <mb@smartsharesystems.com>
> > > > > >>
> > > >
> > > > [...]
> > >
> > > I finally took a couple of hours to carefully review the mempool-
> > > related
> > > series (including the ones that have already been pushed).
> > >
> > > The new behavior looks better to me in all situations I can think
> > > about.
> >
> > Extreme care is required when touching a core library like the
> mempool.
> >
> > Thank you, Olivier.
> >
> > >
> > > >
> > > > > >> --- a/lib/mempool/rte_mempool.h
> > > > > >> +++ b/lib/mempool/rte_mempool.h
> > > > > >> @@ -90,7 +90,7 @@ struct rte_mempool_cache {
> > > > > >>   	 * Cache is allocated to this size to allow it to
> overflow
> > > in
> > > > > >> certain
> > > > > >>   	 * cases to avoid needless emptying of cache.
> > > > > >>   	 */
> > > > > >> -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**<
> Cache
> > > objects */
> > > > > >> +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**<
> Cache
> > > objects */
> > > > > >>   } __rte_cache_aligned;
> > > > > >
> > > > > > How much are we allowed to break the ABI here?
> > > > > >
> > > > > > This patch reduces the size of the structure by removing a
> now
> > > unused
> > > > > part at the end, which should be harmless.
> > >
> > > It is an ABI breakage: an existing application will use the new
> 22.11
> > > function to create the mempool (with a smaller cache), but will use
> the
> > > old inlined get/put that can exceed MAX_SIZE x 2 will remain.
> > >
> > > But this is a nice memory consumption improvement, in my opinion we
> > > should accept it for 22.11 with an entry in the release note.
> > >
> > >
> > > > > >
> > > > > > If we may also move the position of the objs array, I would
> add
> > > > > __rte_cache_aligned to the objs array. It makes no difference
> in
> > > the
> > > > > general case, but if get/put operations are always 32 objects,
> it
> > > will
> > > > > reduce the number of memory (or last level cache) accesses from
> > > five to
> > > > > four 64 B cache lines for every get/put operation.
> > >
> > > Will it really be the case? Since cache->len has to be accessed
> too,
> > > I don't think it would make a difference.
> >
> > Yes, the first cache line, containing cache->len, will be accessed
> always. I forgot to count that; so the improvement by aligning cache-
> >objs will be five cache line accesses instead of six.
> >
> > Let me try to explain the scenario in other words:
> >
> > In an application where a mempool cache is only accessed in bursts of
> 32 objects (256 B), it matters if those 256 B accesses in the mempool
> cache start at a cache line aligned address or not. If cache line
> aligned, accessing those 256 B in the mempool cache will only touch 4
> cache lines; if not, 5 cache lines will be touched. (For architectures
> with 128 B cache line, it will be 2 instead of 3 touched cache lines
> per mempool cache get/put operation in applications using only bursts
> of 32 objects.)
> >
> > If we cache line align cache->objs, those bursts of 32 objects (256
> B) will be cache line aligned: Any address at cache->objs[N * 32
> objects] is cache line aligned if objs->objs[0] is cache line aligned.
> >
> > Currently, the cache->objs directly follows cache->len, which makes
> cache->objs[0] cache line unaligned.
> >
> > If we decide to break the mempool cache ABI, we might as well include
> my suggested cache line alignment performance improvement. It doesn't
> degrade performance for mempool caches not only accessed in bursts of
> 32 objects.
> 
> I don't follow you. Currently, with 16 objects (128B), we access to 3
> cache lines:
> 
>       ┌────────┐
>       │len     │
> cache │********│---
> line0 │********│ ^
>       │********│ |
>       ├────────┤ | 16 objects
>       │********│ | 128B
> cache │********│ |
> line1 │********│ |
>       │********│ |
>       ├────────┤ |
>       │********│_v_
> cache │        │
> line2 │        │
>       │        │
>       └────────┘
> 
> With the alignment, it is also 3 cache lines:
> 
>       ┌────────┐
>       │len     │
> cache │        │
> line0 │        │
>       │        │
>       ├────────┤---
>       │********│ ^
> cache │********│ |
> line1 │********│ |
>       │********│ |
>       ├────────┤ | 16 objects
>       │********│ | 128B
> cache │********│ |
> line2 │********│ |
>       │********│ v
>       └────────┘---
> 
> 
> Am I missing something?

Accessing the objects at the bottom of the mempool cache is a special case, where cache line0 is also used for objects.

Consider the next burst (and any following bursts):

Current:
      ┌────────┐
      │len     │
cache │        │
line0 │        │
      │        │
      ├────────┤
      │        │
cache │        │
line1 │        │
      │        │
      ├────────┤
      │        │
cache │********│---
line2 │********│ ^
      │********│ |
      ├────────┤ | 16 objects
      │********│ | 128B
cache │********│ |
line3 │********│ |
      │********│ |
      ├────────┤ |
      │********│_v_
cache │        │
line4 │        │
      │        │
      └────────┘
4 cache lines touched, incl. line0 for len.

With the proposed alignment:
      ┌────────┐
      │len     │
cache │        │
line0 │        │
      │        │
      ├────────┤
      │        │
cache │        │
line1 │        │
      │        │
      ├────────┤
      │        │
cache │        │
line2 │        │
      │        │
      ├────────┤
      │********│---
cache │********│ ^
line3 │********│ |
      │********│ | 16 objects
      ├────────┤ | 128B
      │********│ |
cache │********│ |
line4 │********│ |
      │********│_v_
      └────────┘
Only 3 cache lines touched, incl. line0 for len.


> 
> >
> > >
> > >
> > > > > >
> > > > > > 	uint32_t len;	      /**< Current cache count */
> > > > > > -	/*
> > > > > > -	 * Cache is allocated to this size to allow it to overflow
> > > in
> > > > > certain
> > > > > > -	 * cases to avoid needless emptying of cache.
> > > > > > -	 */
> > > > > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> > > objects */
> > > > > > +	/**
> > > > > > +	 * Cache objects
> > > > > > +	 *
> > > > > > +	 * Cache is allocated to this size to allow it to overflow
> > > in
> > > > > certain
> > > > > > +	 * cases to avoid needless emptying of cache.
> > > > > > +	 */
> > > > > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> > > __rte_cache_aligned;
> > > > > > } __rte_cache_aligned;
> > > > >
> > > > > I think aligning objs on cacheline should be a separate patch.
> > > >
> > > > Good point. I'll let you do it. :-)
> > > >
> > > > PS: Thank you for following up on this patch series, Andrew!
> > >
> > > Many thanks for this rework.
> > >
> > > Acked-by: Olivier Matz <olivier.matz@6wind.com>
> >
> > Perhaps Reviewed-by would be appropriate?
> 
> I was thinking that "Acked-by" was commonly used by maintainers, and
> "Reviewed-by" for reviews by community members. After reading the
> documentation again, it's not that clear now in my mind :)
> 
> Thanks,
> Olivier


^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 3/4] mempool: fix cache flushing algorithm
  2022-10-14 15:57  3%             ` Morten Brørup
@ 2022-10-14 19:50  0%               ` Olivier Matz
  2022-10-15  6:57  0%                 ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2022-10-14 19:50 UTC (permalink / raw)
  To: Morten Brørup; +Cc: Andrew Rybchenko, dev, Bruce Richardson

On Fri, Oct 14, 2022 at 05:57:39PM +0200, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Friday, 14 October 2022 16.01
> > 
> > Hi Morten, Andrew,
> > 
> > On Sun, Oct 09, 2022 at 05:08:39PM +0200, Morten Brørup wrote:
> > > > From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > Sent: Sunday, 9 October 2022 16.52
> > > >
> > > > On 10/9/22 17:31, Morten Brørup wrote:
> > > > >> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > > >> Sent: Sunday, 9 October 2022 15.38
> > > > >>
> > > > >> From: Morten Brørup <mb@smartsharesystems.com>
> > > > >>
> > >
> > > [...]
> > 
> > I finally took a couple of hours to carefully review the mempool-
> > related
> > series (including the ones that have already been pushed).
> > 
> > The new behavior looks better to me in all situations I can think
> > about.
> 
> Extreme care is required when touching a core library like the mempool.
> 
> Thank you, Olivier.
> 
> > 
> > >
> > > > >> --- a/lib/mempool/rte_mempool.h
> > > > >> +++ b/lib/mempool/rte_mempool.h
> > > > >> @@ -90,7 +90,7 @@ struct rte_mempool_cache {
> > > > >>   	 * Cache is allocated to this size to allow it to overflow
> > in
> > > > >> certain
> > > > >>   	 * cases to avoid needless emptying of cache.
> > > > >>   	 */
> > > > >> -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> > objects */
> > > > >> +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache
> > objects */
> > > > >>   } __rte_cache_aligned;
> > > > >
> > > > > How much are we allowed to break the ABI here?
> > > > >
> > > > > This patch reduces the size of the structure by removing a now
> > unused
> > > > part at the end, which should be harmless.
> > 
> > It is an ABI breakage: an existing application will use the new 22.11
> > function to create the mempool (with a smaller cache), but will use the
> > old inlined get/put that can exceed MAX_SIZE x 2 will remain.
> > 
> > But this is a nice memory consumption improvement, in my opinion we
> > should accept it for 22.11 with an entry in the release note.
> > 
> > 
> > > > >
> > > > > If we may also move the position of the objs array, I would add
> > > > __rte_cache_aligned to the objs array. It makes no difference in
> > the
> > > > general case, but if get/put operations are always 32 objects, it
> > will
> > > > reduce the number of memory (or last level cache) accesses from
> > five to
> > > > four 64 B cache lines for every get/put operation.
> > 
> > Will it really be the case? Since cache->len has to be accessed too,
> > I don't think it would make a difference.
> 
> Yes, the first cache line, containing cache->len, will be accessed always. I forgot to count that; so the improvement by aligning cache->objs will be five cache line accesses instead of six.
> 
> Let me try to explain the scenario in other words:
> 
> In an application where a mempool cache is only accessed in bursts of 32 objects (256 B), it matters if those 256 B accesses in the mempool cache start at a cache line aligned address or not. If cache line aligned, accessing those 256 B in the mempool cache will only touch 4 cache lines; if not, 5 cache lines will be touched. (For architectures with 128 B cache line, it will be 2 instead of 3 touched cache lines per mempool cache get/put operation in applications using only bursts of 32 objects.)
> 
> If we cache line align cache->objs, those bursts of 32 objects (256 B) will be cache line aligned: Any address at cache->objs[N * 32 objects] is cache line aligned if objs->objs[0] is cache line aligned.
> 
> Currently, the cache->objs directly follows cache->len, which makes cache->objs[0] cache line unaligned.
> 
> If we decide to break the mempool cache ABI, we might as well include my suggested cache line alignment performance improvement. It doesn't degrade performance for mempool caches not only accessed in bursts of 32 objects.

I don't follow you. Currently, with 16 objects (128B), we access to 3
cache lines:

      ┌────────┐
      │len     │
cache │********│---
line0 │********│ ^
      │********│ |
      ├────────┤ | 16 objects
      │********│ | 128B
cache │********│ |
line1 │********│ |
      │********│ |
      ├────────┤ |
      │********│_v_
cache │        │
line2 │        │
      │        │
      └────────┘

With the alignment, it is also 3 cache lines:

      ┌────────┐
      │len     │
cache │        │
line0 │        │
      │        │
      ├────────┤---
      │********│ ^
cache │********│ |
line1 │********│ |
      │********│ |
      ├────────┤ | 16 objects
      │********│ | 128B
cache │********│ |
line2 │********│ |
      │********│ v
      └────────┘---


Am I missing something?

> 
> > 
> > 
> > > > >
> > > > > 	uint32_t len;	      /**< Current cache count */
> > > > > -	/*
> > > > > -	 * Cache is allocated to this size to allow it to overflow
> > in
> > > > certain
> > > > > -	 * cases to avoid needless emptying of cache.
> > > > > -	 */
> > > > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> > objects */
> > > > > +	/**
> > > > > +	 * Cache objects
> > > > > +	 *
> > > > > +	 * Cache is allocated to this size to allow it to overflow
> > in
> > > > certain
> > > > > +	 * cases to avoid needless emptying of cache.
> > > > > +	 */
> > > > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> > __rte_cache_aligned;
> > > > > } __rte_cache_aligned;
> > > >
> > > > I think aligning objs on cacheline should be a separate patch.
> > >
> > > Good point. I'll let you do it. :-)
> > >
> > > PS: Thank you for following up on this patch series, Andrew!
> > 
> > Many thanks for this rework.
> > 
> > Acked-by: Olivier Matz <olivier.matz@6wind.com>
> 
> Perhaps Reviewed-by would be appropriate?

I was thinking that "Acked-by" was commonly used by maintainers, and
"Reviewed-by" for reviews by community members. After reading the
documentation again, it's not that clear now in my mind :)

Thanks,
Olivier

^ permalink raw reply	[relevance 0%]

* RE: [PATCH v6 3/4] mempool: fix cache flushing algorithm
  2022-10-14 14:01  3%           ` Olivier Matz
@ 2022-10-14 15:57  3%             ` Morten Brørup
  2022-10-14 19:50  0%               ` Olivier Matz
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-10-14 15:57 UTC (permalink / raw)
  To: Olivier Matz; +Cc: Andrew Rybchenko, dev, Bruce Richardson

> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Friday, 14 October 2022 16.01
> 
> Hi Morten, Andrew,
> 
> On Sun, Oct 09, 2022 at 05:08:39PM +0200, Morten Brørup wrote:
> > > From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > Sent: Sunday, 9 October 2022 16.52
> > >
> > > On 10/9/22 17:31, Morten Brørup wrote:
> > > >> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > > >> Sent: Sunday, 9 October 2022 15.38
> > > >>
> > > >> From: Morten Brørup <mb@smartsharesystems.com>
> > > >>
> >
> > [...]
> 
> I finally took a couple of hours to carefully review the mempool-
> related
> series (including the ones that have already been pushed).
> 
> The new behavior looks better to me in all situations I can think
> about.

Extreme care is required when touching a core library like the mempool.

Thank you, Olivier.

> 
> >
> > > >> --- a/lib/mempool/rte_mempool.h
> > > >> +++ b/lib/mempool/rte_mempool.h
> > > >> @@ -90,7 +90,7 @@ struct rte_mempool_cache {
> > > >>   	 * Cache is allocated to this size to allow it to overflow
> in
> > > >> certain
> > > >>   	 * cases to avoid needless emptying of cache.
> > > >>   	 */
> > > >> -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> objects */
> > > >> +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache
> objects */
> > > >>   } __rte_cache_aligned;
> > > >
> > > > How much are we allowed to break the ABI here?
> > > >
> > > > This patch reduces the size of the structure by removing a now
> unused
> > > part at the end, which should be harmless.
> 
> It is an ABI breakage: an existing application will use the new 22.11
> function to create the mempool (with a smaller cache), but will use the
> old inlined get/put that can exceed MAX_SIZE x 2 will remain.
> 
> But this is a nice memory consumption improvement, in my opinion we
> should accept it for 22.11 with an entry in the release note.
> 
> 
> > > >
> > > > If we may also move the position of the objs array, I would add
> > > __rte_cache_aligned to the objs array. It makes no difference in
> the
> > > general case, but if get/put operations are always 32 objects, it
> will
> > > reduce the number of memory (or last level cache) accesses from
> five to
> > > four 64 B cache lines for every get/put operation.
> 
> Will it really be the case? Since cache->len has to be accessed too,
> I don't think it would make a difference.

Yes, the first cache line, containing cache->len, will be accessed always. I forgot to count that; so the improvement by aligning cache->objs will be five cache line accesses instead of six.

Let me try to explain the scenario in other words:

In an application where a mempool cache is only accessed in bursts of 32 objects (256 B), it matters if those 256 B accesses in the mempool cache start at a cache line aligned address or not. If cache line aligned, accessing those 256 B in the mempool cache will only touch 4 cache lines; if not, 5 cache lines will be touched. (For architectures with 128 B cache line, it will be 2 instead of 3 touched cache lines per mempool cache get/put operation in applications using only bursts of 32 objects.)

If we cache line align cache->objs, those bursts of 32 objects (256 B) will be cache line aligned: Any address at cache->objs[N * 32 objects] is cache line aligned if objs->objs[0] is cache line aligned.

Currently, the cache->objs directly follows cache->len, which makes cache->objs[0] cache line unaligned.

If we decide to break the mempool cache ABI, we might as well include my suggested cache line alignment performance improvement. It doesn't degrade performance for mempool caches not only accessed in bursts of 32 objects.

> 
> 
> > > >
> > > > 	uint32_t len;	      /**< Current cache count */
> > > > -	/*
> > > > -	 * Cache is allocated to this size to allow it to overflow
> in
> > > certain
> > > > -	 * cases to avoid needless emptying of cache.
> > > > -	 */
> > > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache
> objects */
> > > > +	/**
> > > > +	 * Cache objects
> > > > +	 *
> > > > +	 * Cache is allocated to this size to allow it to overflow
> in
> > > certain
> > > > +	 * cases to avoid needless emptying of cache.
> > > > +	 */
> > > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]
> __rte_cache_aligned;
> > > > } __rte_cache_aligned;
> > >
> > > I think aligning objs on cacheline should be a separate patch.
> >
> > Good point. I'll let you do it. :-)
> >
> > PS: Thank you for following up on this patch series, Andrew!
> 
> Many thanks for this rework.
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>

Perhaps Reviewed-by would be appropriate?


^ permalink raw reply	[relevance 3%]

* Re: [PATCH v6 3/4] mempool: fix cache flushing algorithm
  @ 2022-10-14 14:01  3%           ` Olivier Matz
  2022-10-14 15:57  3%             ` Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2022-10-14 14:01 UTC (permalink / raw)
  To: Morten Brørup; +Cc: Andrew Rybchenko, dev, Bruce Richardson

Hi Morten, Andrew,

On Sun, Oct 09, 2022 at 05:08:39PM +0200, Morten Brørup wrote:
> > From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > Sent: Sunday, 9 October 2022 16.52
> > 
> > On 10/9/22 17:31, Morten Brørup wrote:
> > >> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> > >> Sent: Sunday, 9 October 2022 15.38
> > >>
> > >> From: Morten Brørup <mb@smartsharesystems.com>
> > >>
> 
> [...]

I finally took a couple of hours to carefully review the mempool-related
series (including the ones that have already been pushed).

The new behavior looks better to me in all situations I can think about.

> 
> > >> --- a/lib/mempool/rte_mempool.h
> > >> +++ b/lib/mempool/rte_mempool.h
> > >> @@ -90,7 +90,7 @@ struct rte_mempool_cache {
> > >>   	 * Cache is allocated to this size to allow it to overflow in
> > >> certain
> > >>   	 * cases to avoid needless emptying of cache.
> > >>   	 */
> > >> -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
> > >> +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2]; /**< Cache objects */
> > >>   } __rte_cache_aligned;
> > >
> > > How much are we allowed to break the ABI here?
> > >
> > > This patch reduces the size of the structure by removing a now unused
> > part at the end, which should be harmless.

It is an ABI breakage: an existing application will use the new 22.11
function to create the mempool (with a smaller cache), but will use the
old inlined get/put that can exceed MAX_SIZE x 2 will remain.

But this is a nice memory consumption improvement, in my opinion we
should accept it for 22.11 with an entry in the release note.


> > >
> > > If we may also move the position of the objs array, I would add
> > __rte_cache_aligned to the objs array. It makes no difference in the
> > general case, but if get/put operations are always 32 objects, it will
> > reduce the number of memory (or last level cache) accesses from five to
> > four 64 B cache lines for every get/put operation.

Will it really be the case? Since cache->len has to be accessed too,
I don't think it would make a difference.


> > >
> > > 	uint32_t len;	      /**< Current cache count */
> > > -	/*
> > > -	 * Cache is allocated to this size to allow it to overflow in
> > certain
> > > -	 * cases to avoid needless emptying of cache.
> > > -	 */
> > > -	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 3]; /**< Cache objects */
> > > +	/**
> > > +	 * Cache objects
> > > +	 *
> > > +	 * Cache is allocated to this size to allow it to overflow in
> > certain
> > > +	 * cases to avoid needless emptying of cache.
> > > +	 */
> > > +	void *objs[RTE_MEMPOOL_CACHE_MAX_SIZE * 2] __rte_cache_aligned;
> > > } __rte_cache_aligned;
> > 
> > I think aligning objs on cacheline should be a separate patch.
> 
> Good point. I'll let you do it. :-)
> 
> PS: Thank you for following up on this patch series, Andrew!

Many thanks for this rework.

Acked-by: Olivier Matz <olivier.matz@6wind.com>

^ permalink raw reply	[relevance 3%]

* [PATCH v2] eventdev: increase xstats ID width to 64 bits
  2022-10-13  9:23  2% [PATCH] eventdev: increase xstats ID width to 64 bits pbhagavatula
  2022-10-13 10:16  0% ` Mattias Rönnblom
@ 2022-10-13 11:35  1% ` pbhagavatula
  2022-10-19 13:24  0%   ` Jerin Jacob
  1 sibling, 1 reply; 200+ results
From: pbhagavatula @ 2022-10-13 11:35 UTC (permalink / raw)
  To: mb, jerinj, thomas, Pavan Nikhilesh, Shijith Thotton,
	Timothy McDaniel, Mattias Rönnblom, Liang Ma,
	Peter Mccarthy, Harry van Haaren
  Cc: dev

From: Pavan Nikhilesh <pbhagavatula@marvell.com>

Increase xstats ID width from 32 to 64 bits. This also
fixes the xstats ID datatype discrepancy between reset and
rest of the xstats family.

Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Reviewed-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
---
 v2 Changes:
 - Fix compilation on 32 bit platforms. (Mattias)

 doc/guides/rel_notes/release_22_11.rst   |   5 ++
 drivers/event/cnxk/cnxk_eventdev.h       |   6 +-
 drivers/event/cnxk/cnxk_eventdev_stats.c |   6 +-
 drivers/event/dlb2/dlb2_priv.h           |   8 +-
 drivers/event/dlb2/dlb2_xstats.c         |  18 ++--
 drivers/event/dsw/dsw_evdev.h            |   6 +-
 drivers/event/dsw/dsw_xstats.c           |  32 +++----
 drivers/event/opdl/opdl_evdev.h          |   8 +-
 drivers/event/opdl/opdl_evdev_xstats.c   |   8 +-
 drivers/event/opdl/opdl_test.c           |   4 +-
 drivers/event/sw/sw_evdev.h              |   8 +-
 drivers/event/sw/sw_evdev_selftest.c     | 101 +++++++++++------------
 drivers/event/sw/sw_evdev_xstats.c       |  18 ++--
 lib/eventdev/eventdev_pmd.h              |   8 +-
 lib/eventdev/rte_eventdev.c              |  12 +--
 lib/eventdev/rte_eventdev.h              |   8 +-
 16 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
index 2da8bc9661..6b76ad5566 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -454,6 +454,11 @@ API Changes

 * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.

+* eventdev: The datatype of the ID parameter in the functions
+  ``rte_event_dev_xstats_names_get``, ``rte_event_dev_xstats_get``,
+  ``rte_event_dev_xstats_by_name_get`` and ``rte_event_dev_xstats_reset``
+  is changed to ``uint64_t`` from ``unsigned int`` and ``uint32_t``.
+

 ABI Changes
 -----------
diff --git a/drivers/event/cnxk/cnxk_eventdev.h b/drivers/event/cnxk/cnxk_eventdev.h
index f68c2aee23..738e335ea4 100644
--- a/drivers/event/cnxk/cnxk_eventdev.h
+++ b/drivers/event/cnxk/cnxk_eventdev.h
@@ -271,14 +271,14 @@ int cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
 			      enum rte_event_dev_xstats_mode mode,
 			      uint8_t queue_port_id,
 			      struct rte_event_dev_xstats_name *xstats_names,
-			      unsigned int *ids, unsigned int size);
+			      uint64_t *ids, unsigned int size);
 int cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 			enum rte_event_dev_xstats_mode mode,
-			uint8_t queue_port_id, const unsigned int ids[],
+			uint8_t queue_port_id, const uint64_t ids[],
 			uint64_t values[], unsigned int n);
 int cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
 			  enum rte_event_dev_xstats_mode mode,
-			  int16_t queue_port_id, const uint32_t ids[],
+			  int16_t queue_port_id, const uint64_t ids[],
 			  uint32_t n);

 /* CN9K */
diff --git a/drivers/event/cnxk/cnxk_eventdev_stats.c b/drivers/event/cnxk/cnxk_eventdev_stats.c
index a3b548f462..715ca9cd8f 100644
--- a/drivers/event/cnxk/cnxk_eventdev_stats.c
+++ b/drivers/event/cnxk/cnxk_eventdev_stats.c
@@ -103,7 +103,7 @@ static struct cnxk_sso_xstats_name sso_hwgrp_xstats[] = {
 int
 cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 		    enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		    const unsigned int ids[], uint64_t values[], unsigned int n)
+		    const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
 	struct roc_sso_hwgrp_stats hwgrp_stats;
@@ -170,7 +170,7 @@ cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 int
 cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
 		      enum rte_event_dev_xstats_mode mode,
-		      int16_t queue_port_id, const uint32_t ids[], uint32_t n)
+		      int16_t queue_port_id, const uint64_t ids[], uint32_t n)
 {
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
 	struct roc_sso_hwgrp_stats hwgrp_stats;
@@ -235,7 +235,7 @@ cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
 			  enum rte_event_dev_xstats_mode mode,
 			  uint8_t queue_port_id,
 			  struct rte_event_dev_xstats_name *xstats_names,
-			  unsigned int *ids, unsigned int size)
+			  uint64_t *ids, unsigned int size)
 {
 	struct rte_event_dev_xstats_name xstats_names_copy[CNXK_SSO_NUM_XSTATS];
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index 9ef5bcb901..52f0ab9935 100644
--- a/drivers/event/dlb2/dlb2_priv.h
+++ b/drivers/event/dlb2/dlb2_priv.h
@@ -688,20 +688,20 @@ void dlb2_xstats_uninit(struct dlb2_eventdev *dlb2);

 int dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);

 int dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstat_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);

 uint64_t dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
-					  const char *name, unsigned int *id);
+					  const char *name, uint64_t *id);

 int dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);

 int test_dlb2_eventdev(void);
diff --git a/drivers/event/dlb2/dlb2_xstats.c b/drivers/event/dlb2/dlb2_xstats.c
index d4c8d99034..ff15271dda 100644
--- a/drivers/event/dlb2/dlb2_xstats.c
+++ b/drivers/event/dlb2/dlb2_xstats.c
@@ -666,7 +666,7 @@ int
 dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	const struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	unsigned int i;
@@ -717,7 +717,7 @@ dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 static int
 dlb2_xstats_update(struct dlb2_eventdev *dlb2,
 		enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n, const uint32_t reset)
 {
 	unsigned int i;
@@ -791,7 +791,7 @@ dlb2_xstats_update(struct dlb2_eventdev *dlb2,
 int
 dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n)
+		const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	const uint32_t reset = 0;
@@ -802,7 +802,7 @@ dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,

 uint64_t
 dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
-				 const char *name, unsigned int *id)
+				 const char *name, uint64_t *id)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	unsigned int i;
@@ -876,7 +876,7 @@ dlb2_xstats_reset_range(struct dlb2_eventdev *dlb2, uint32_t start,

 static int
 dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
-			const uint32_t ids[], uint32_t nb_ids)
+			const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;

@@ -898,7 +898,7 @@ dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,

 static int
 dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
-		       const uint32_t ids[], uint32_t nb_ids)
+		       const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	int offset = dlb2->xstats_offset_for_port[port_id];
@@ -917,14 +917,14 @@ dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
 }

 static int
-dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint32_t ids[],
+dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint64_t ids[],
 		      uint32_t nb_ids)
 {
 	uint32_t i;

 	if (ids) {
 		for (i = 0; i < nb_ids; i++) {
-			uint32_t id = ids[i];
+			uint64_t id = ids[i];

 			if (id >= dlb2->xstats_count_mode_dev)
 				return -EINVAL;
@@ -942,7 +942,7 @@ int
 dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
 			   enum rte_event_dev_xstats_mode mode,
 			   int16_t queue_port_id,
-			   const uint32_t ids[],
+			   const uint64_t ids[],
 			   uint32_t nb_ids)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
diff --git a/drivers/event/dsw/dsw_evdev.h b/drivers/event/dsw/dsw_evdev.h
index df7dcc5577..6416a8a898 100644
--- a/drivers/event/dsw/dsw_evdev.h
+++ b/drivers/event/dsw/dsw_evdev.h
@@ -283,12 +283,12 @@ int dsw_xstats_get_names(const struct rte_eventdev *dev,
 			 enum rte_event_dev_xstats_mode mode,
 			 uint8_t queue_port_id,
 			 struct rte_event_dev_xstats_name *xstats_names,
-			 unsigned int *ids, unsigned int size);
+			 uint64_t *ids, unsigned int size);
 int dsw_xstats_get(const struct rte_eventdev *dev,
 		   enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		   const unsigned int ids[], uint64_t values[], unsigned int n);
+		   const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t dsw_xstats_get_by_name(const struct rte_eventdev *dev,
-				const char *name, unsigned int *id);
+				const char *name, uint64_t *id);

 static inline struct dsw_evdev *
 dsw_pmd_priv(const struct rte_eventdev *eventdev)
diff --git a/drivers/event/dsw/dsw_xstats.c b/drivers/event/dsw/dsw_xstats.c
index 4f7d4e3ff9..2a83a28b41 100644
--- a/drivers/event/dsw/dsw_xstats.c
+++ b/drivers/event/dsw/dsw_xstats.c
@@ -15,8 +15,8 @@
  */
 #define DSW_XSTATS_ID_PARAM_BITS (8)
 #define DSW_XSTATS_ID_STAT_BITS					\
-	(sizeof(unsigned int)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
-#define DSW_XSTATS_ID_STAT_MASK ((1 << DSW_XSTATS_ID_STAT_BITS) - 1)
+	(sizeof(uint64_t)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
+#define DSW_XSTATS_ID_STAT_MASK ((UINT64_C(1) << DSW_XSTATS_ID_STAT_BITS) - 1)

 #define DSW_XSTATS_ID_GET_PARAM(id)		\
 	((id)>>DSW_XSTATS_ID_STAT_BITS)
@@ -25,7 +25,7 @@
 	((id) & DSW_XSTATS_ID_STAT_MASK)

 #define DSW_XSTATS_ID_CREATE(id, param_value)			\
-	(((param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
+	((((uint64_t)param_value) << DSW_XSTATS_ID_STAT_BITS) | id)

 typedef
 uint64_t (*dsw_xstats_dev_get_value_fn)(struct dsw_evdev *dsw);
@@ -169,7 +169,7 @@ static struct dsw_xstats_port dsw_port_xstats[] = {
 typedef
 void (*dsw_xstats_foreach_fn)(const char *xstats_name,
 			      enum rte_event_dev_xstats_mode mode,
-			      uint8_t queue_port_id, unsigned int xstats_id,
+			      uint8_t queue_port_id, uint64_t xstats_id,
 			      void *data);

 static void
@@ -193,7 +193,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
 	     stat_idx < RTE_DIM(dsw_port_xstats);) {
 		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
 		char xstats_name[RTE_EVENT_DEV_XSTATS_NAME_SIZE];
-		unsigned int xstats_id;
+		uint64_t xstats_id;

 		if (xstat->per_queue) {
 			xstats_id = DSW_XSTATS_ID_CREATE(stat_idx, queue_id);
@@ -219,7 +219,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,

 struct store_ctx {
 	struct rte_event_dev_xstats_name *names;
-	unsigned int *ids;
+	uint64_t *ids;
 	unsigned int count;
 	unsigned int capacity;
 };
@@ -227,7 +227,7 @@ struct store_ctx {
 static void
 dsw_xstats_store_stat(const char *xstats_name,
 		      enum rte_event_dev_xstats_mode mode,
-		      uint8_t queue_port_id, unsigned int xstats_id,
+		      uint8_t queue_port_id, uint64_t xstats_id,
 		      void *data)
 {
 	struct store_ctx *ctx = data;
@@ -248,7 +248,7 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
 		     enum rte_event_dev_xstats_mode mode,
 		     uint8_t queue_port_id,
 		     struct rte_event_dev_xstats_name *xstats_names,
-		     unsigned int *ids, unsigned int capacity)
+		     uint64_t *ids, unsigned int capacity)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);

@@ -276,13 +276,13 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,

 static int
 dsw_xstats_dev_get(const struct rte_eventdev *dev,
-		   const unsigned int ids[], uint64_t values[], unsigned int n)
+		   const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	unsigned int i;

 	for (i = 0; i < n; i++) {
-		unsigned int id = ids[i];
+		uint64_t id = ids[i];
 		struct dsw_xstat_dev *xstat = &dsw_dev_xstats[id];
 		values[i] = xstat->get_value_fn(dsw);
 	}
@@ -291,13 +291,13 @@ dsw_xstats_dev_get(const struct rte_eventdev *dev,

 static int
 dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
-		    const unsigned int ids[], uint64_t values[], unsigned int n)
+		    const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	unsigned int i;

 	for (i = 0; i < n; i++) {
-		unsigned int id = ids[i];
+		uint64_t id = ids[i];
 		unsigned int stat_idx = DSW_XSTATS_ID_GET_STAT(id);
 		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
 		uint8_t queue_id = 0;
@@ -313,7 +313,7 @@ dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
 int
 dsw_xstats_get(const struct rte_eventdev *dev,
 	       enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-	       const unsigned int ids[], uint64_t values[], unsigned int n)
+	       const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	switch (mode) {
 	case RTE_EVENT_DEV_XSTATS_DEVICE:
@@ -332,14 +332,14 @@ dsw_xstats_get(const struct rte_eventdev *dev,
 struct find_ctx {
 	const struct rte_eventdev *dev;
 	const char *name;
-	unsigned int *id;
+	uint64_t *id;
 	uint64_t value;
 };

 static void
 dsw_xstats_find_stat(const char *xstats_name,
 		     enum rte_event_dev_xstats_mode mode,
-		     uint8_t queue_port_id, unsigned int xstats_id,
+		     uint8_t queue_port_id, uint64_t xstats_id,
 		     void *data)
 {
 	struct find_ctx *ctx = data;
@@ -354,7 +354,7 @@ dsw_xstats_find_stat(const char *xstats_name,

 uint64_t
 dsw_xstats_get_by_name(const struct rte_eventdev *dev, const char *name,
-		       unsigned int *id)
+		       uint64_t *id)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	uint16_t port_id;
diff --git a/drivers/event/opdl/opdl_evdev.h b/drivers/event/opdl/opdl_evdev.h
index 2dca0a8a98..1ca166b37c 100644
--- a/drivers/event/opdl/opdl_evdev.h
+++ b/drivers/event/opdl/opdl_evdev.h
@@ -289,16 +289,16 @@ int opdl_xstats_uninit(struct rte_eventdev *dev);
 int opdl_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);
 int opdl_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t opdl_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);
 int opdl_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);

 int opdl_add_event_handlers(struct rte_eventdev *dev);
diff --git a/drivers/event/opdl/opdl_evdev_xstats.c b/drivers/event/opdl/opdl_evdev_xstats.c
index 27b3d88023..b382f6619d 100644
--- a/drivers/event/opdl/opdl_evdev_xstats.c
+++ b/drivers/event/opdl/opdl_evdev_xstats.c
@@ -65,7 +65,7 @@ opdl_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);

@@ -99,7 +99,7 @@ int
 opdl_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		uint8_t queue_port_id,
-		const unsigned int ids[],
+		const uint64_t ids[],
 		uint64_t values[], unsigned int n)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
@@ -133,7 +133,7 @@ opdl_xstats_get(const struct rte_eventdev *dev,

 uint64_t
 opdl_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id)
+		const char *name, uint64_t *id)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);

@@ -161,7 +161,7 @@ opdl_xstats_get_by_name(const struct rte_eventdev *dev,
 int
 opdl_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
-		int16_t queue_port_id, const uint32_t ids[],
+		int16_t queue_port_id, const uint64_t ids[],
 		uint32_t nb_ids)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
index 3cbe2139ee..b69c4769dc 100644
--- a/drivers/event/opdl/opdl_test.c
+++ b/drivers/event/opdl/opdl_test.c
@@ -471,7 +471,7 @@ atomic_basic(struct test *t)
 	return 0;
 }
 static __rte_always_inline int
-check_qid_stats(uint32_t id[], int index)
+check_qid_stats(uint64_t id[], int index)
 {

 	if (index == 0) {
@@ -509,7 +509,7 @@ check_statistics(void)
 				0);
 		if (num_stats > 0) {

-			uint32_t id[num_stats];
+			uint64_t id[num_stats];
 			struct rte_event_dev_xstats_name names[num_stats];
 			uint64_t values[num_stats];

diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index 8542b7d34d..c7b943a72b 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -301,16 +301,16 @@ int sw_xstats_uninit(struct sw_evdev *dev);
 int sw_xstats_get_names(const struct rte_eventdev *dev,
 	enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 	struct rte_event_dev_xstats_name *xstats_names,
-	unsigned int *ids, unsigned int size);
+	uint64_t *ids, unsigned int size);
 int sw_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t sw_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);
 int sw_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);

 int test_sw_eventdev(void);
diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
index ed7ae6a685..62d66744f2 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -92,7 +92,7 @@ xstats_print(void)
 {
 	const uint32_t XSTATS_MAX = 1024;
 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];

@@ -310,15 +310,14 @@ static inline int
 test_event_dev_stats_get(int dev_id, struct test_event_dev_stats *stats)
 {
 	static uint32_t i;
-	static uint32_t total_ids[3]; /* rx, tx and drop */
-	static uint32_t port_rx_pkts_ids[MAX_PORTS];
-	static uint32_t port_rx_dropped_ids[MAX_PORTS];
-	static uint32_t port_inflight_ids[MAX_PORTS];
-	static uint32_t port_tx_pkts_ids[MAX_PORTS];
-	static uint32_t qid_rx_pkts_ids[MAX_QIDS];
-	static uint32_t qid_rx_dropped_ids[MAX_QIDS];
-	static uint32_t qid_tx_pkts_ids[MAX_QIDS];
-
+	static uint64_t total_ids[3]; /* rx, tx and drop */
+	static uint64_t port_rx_pkts_ids[MAX_PORTS];
+	static uint64_t port_rx_dropped_ids[MAX_PORTS];
+	static uint64_t port_inflight_ids[MAX_PORTS];
+	static uint64_t port_tx_pkts_ids[MAX_PORTS];
+	static uint64_t qid_rx_pkts_ids[MAX_QIDS];
+	static uint64_t qid_rx_dropped_ids[MAX_QIDS];
+	static uint64_t qid_tx_pkts_ids[MAX_QIDS];

 	stats->rx_pkts = rte_event_dev_xstats_by_name_get(dev_id,
 			"dev_rx", &total_ids[0]);
@@ -863,7 +862,7 @@ xstats_tests(struct test *t)
 	const uint32_t XSTATS_MAX = 1024;

 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];

@@ -963,11 +962,10 @@ xstats_tests(struct test *t)
 	static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4, 1};
 	for (i = 0; (signed int)i < ret; i++) {
 		if (expected[i] != values[i]) {
-			printf(
-				"%d Error xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], expected[i]);
+			printf("%d Error xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], expected[i]);
 			goto fail;
 		}
 	}
@@ -982,11 +980,10 @@ xstats_tests(struct test *t)
 					0, ids, values, num_stats);
 	for (i = 0; (signed int)i < ret; i++) {
 		if (expected_zero[i] != values[i]) {
-			printf(
-				"%d Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], expected_zero[i]);
+			printf("%d Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], expected_zero[i]);
 			goto fail;
 		}
 	}
@@ -1058,11 +1055,10 @@ xstats_tests(struct test *t)
 					0, ids, values, num_stats);
 	for (i = 0; (signed int)i < ret; i++) {
 		if (port_expected_zero[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], port_expected_zero[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], port_expected_zero[i]);
 			goto fail;
 		}
 	}
@@ -1095,11 +1091,10 @@ xstats_tests(struct test *t)
 	};
 	for (i = 0; (signed int)i < ret; i++) {
 		if (queue_expected[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], queue_expected[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], queue_expected[i]);
 			goto fail;
 		}
 	}
@@ -1129,11 +1124,10 @@ xstats_tests(struct test *t)
 	int fails = 0;
 	for (i = 0; (signed int)i < ret; i++) {
 		if (queue_expected_zero[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], queue_expected_zero[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], queue_expected_zero[i]);
 			fails++;
 		}
 	}
@@ -1160,7 +1154,7 @@ xstats_id_abuse_tests(struct test *t)
 	const uint32_t XSTATS_MAX = 1024;
 	const uint32_t link_port = 2;

-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];

 	/* Create instance with 4 ports */
@@ -1379,7 +1373,7 @@ xstats_brute_force(struct test *t)
 {
 	uint32_t i;
 	const uint32_t XSTATS_MAX = 1024;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];

@@ -1454,7 +1448,7 @@ xstats_id_reset_tests(struct test *t)
 #define XSTATS_MAX 1024
 	int ret;
 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];

@@ -1510,13 +1504,14 @@ xstats_id_reset_tests(struct test *t)
 	};
 	uint64_t dev_expected[] = {NPKTS, NPKTS, 0, 1, 0, 0, 4, 1};
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								dev_names[i],
 								&id);
 		if (id != i) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, dev_names[i], i, id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, dev_names[i], i, id);
 			goto fail;
 		}
 		if (val != dev_expected[i]) {
@@ -1631,20 +1626,20 @@ xstats_id_reset_tests(struct test *t)

 	int failed = 0;
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								port_names[i],
 								&id);
 		if (id != i + PORT_OFF) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, port_names[i], i+PORT_OFF,
-					id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, port_names[i], i + PORT_OFF, id);
 			failed = 1;
 		}
 		if (val != port_expected[i]) {
-			printf("%d: %s value incorrect, expected %"PRIu64
-				" got %d\n", __LINE__, port_names[i],
-				port_expected[i], id);
+			printf("%d: %s value incorrect, expected %" PRIu64
+			       " got %" PRIu64 "\n",
+			       __LINE__, port_names[i], port_expected[i], id);
 			failed = 1;
 		}
 		/* reset to zero */
@@ -1746,14 +1741,14 @@ xstats_id_reset_tests(struct test *t)

 	failed = 0;
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								queue_names[i],
 								&id);
 		if (id != i + QUEUE_OFF) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, queue_names[i], i+QUEUE_OFF,
-					id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, queue_names[i], i + QUEUE_OFF, id);
 			failed = 1;
 		}
 		if (val != queue_expected[i]) {
diff --git a/drivers/event/sw/sw_evdev_xstats.c b/drivers/event/sw/sw_evdev_xstats.c
index c2647d7da2..fbac8f3ab5 100644
--- a/drivers/event/sw/sw_evdev_xstats.c
+++ b/drivers/event/sw/sw_evdev_xstats.c
@@ -393,7 +393,7 @@ int
 sw_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
 	unsigned int i;
@@ -444,7 +444,7 @@ sw_xstats_get_names(const struct rte_eventdev *dev,

 static int
 sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n, const uint32_t reset,
 		const uint32_t ret_if_n_lt_nstats)
 {
@@ -509,7 +509,7 @@ sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
 int
 sw_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n)
+		const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct sw_evdev *sw = sw_pmd_priv(dev);
 	const uint32_t reset = 0;
@@ -520,7 +520,7 @@ sw_xstats_get(const struct rte_eventdev *dev,

 uint64_t
 sw_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id)
+		const char *name, uint64_t *id)
 {
 	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
 	unsigned int i;
@@ -556,7 +556,7 @@ sw_xstats_reset_range(struct sw_evdev *sw, uint32_t start, uint32_t num)

 static int
 sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	const uint32_t ret_n_lt_stats = 0;
@@ -577,7 +577,7 @@ sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,

 static int
 sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	const uint32_t ret_n_lt_stats = 0;
@@ -597,12 +597,12 @@ sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
 }

 static int
-sw_xstats_reset_dev(struct sw_evdev *sw, const uint32_t ids[], uint32_t nb_ids)
+sw_xstats_reset_dev(struct sw_evdev *sw, const uint64_t ids[], uint32_t nb_ids)
 {
 	uint32_t i;
 	if (ids) {
 		for (i = 0; i < nb_ids; i++) {
-			uint32_t id = ids[i];
+			uint64_t id = ids[i];
 			if (id >= sw->xstats_count_mode_dev)
 				return -EINVAL;
 			sw_xstats_reset_range(sw, id, 1);
@@ -619,7 +619,7 @@ int
 sw_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids)
 {
 	struct sw_evdev *sw = sw_pmd_priv(dev);
diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index e49ff23db5..aebab26852 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -529,7 +529,7 @@ typedef void (*eventdev_dump_t)(struct rte_eventdev *dev, FILE *f);
  */
 typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);

 /**
  * Resets the statistic values in xstats for the device, based on mode.
@@ -537,7 +537,7 @@ typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
 typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);

 /**
@@ -564,7 +564,7 @@ typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
 typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);

 /**
  * Get value of one stats and optionally return its id
@@ -582,7 +582,7 @@ typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
  *   if id pointer is non-NULL
  */
 typedef uint64_t (*eventdev_xstats_get_by_name)(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);


 /**
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 845f8dbb6e..b0414206d9 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -1161,7 +1161,7 @@ int
 rte_event_dev_xstats_names_get(uint8_t dev_id,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
 	const int cnt_expected_entries = xstats_get_count(dev_id, mode,
@@ -1183,7 +1183,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
 /* retrieve eventdev extended statistics */
 int
 rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
@@ -1198,11 +1198,11 @@ rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,

 uint64_t
 rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
-		unsigned int *id)
+		uint64_t *id)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
 	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
-	unsigned int temp = -1;
+	uint64_t temp = -1;

 	if (id != NULL)
 		*id = (unsigned int)-1;
@@ -1217,7 +1217,7 @@ rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,

 int rte_event_dev_xstats_reset(uint8_t dev_id,
 		enum rte_event_dev_xstats_mode mode, int16_t queue_port_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
 	struct rte_eventdev *dev = &rte_eventdevs[dev_id];
@@ -1658,7 +1658,7 @@ eventdev_build_telemetry_data(int dev_id,
 			      struct rte_tel_data *d)
 {
 	struct rte_event_dev_xstats_name *xstat_names;
-	unsigned int *ids;
+	uint64_t *ids;
 	uint64_t *values;
 	int i, ret, num_xstats;

diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 60e9043ac4..82e8976e57 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1784,7 +1784,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
 			       enum rte_event_dev_xstats_mode mode,
 			       uint8_t queue_port_id,
 			       struct rte_event_dev_xstats_name *xstats_names,
-			       unsigned int *ids,
+			       uint64_t *ids,
 			       unsigned int size);

 /**
@@ -1817,7 +1817,7 @@ int
 rte_event_dev_xstats_get(uint8_t dev_id,
 			 enum rte_event_dev_xstats_mode mode,
 			 uint8_t queue_port_id,
-			 const unsigned int ids[],
+			 const uint64_t ids[],
 			 uint64_t values[], unsigned int n);

 /**
@@ -1838,7 +1838,7 @@ rte_event_dev_xstats_get(uint8_t dev_id,
  */
 uint64_t
 rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
-				 unsigned int *id);
+				 uint64_t *id);

 /**
  * Reset the values of the xstats of the selected component in the device.
@@ -1864,7 +1864,7 @@ int
 rte_event_dev_xstats_reset(uint8_t dev_id,
 			   enum rte_event_dev_xstats_mode mode,
 			   int16_t queue_port_id,
-			   const uint32_t ids[],
+			   const uint64_t ids[],
 			   uint32_t nb_ids);

 /**
--
2.25.1


^ permalink raw reply	[relevance 1%]

* Re: [PATCH] eventdev: increase xstats ID width to 64 bits
  2022-10-13  9:23  2% [PATCH] eventdev: increase xstats ID width to 64 bits pbhagavatula
@ 2022-10-13 10:16  0% ` Mattias Rönnblom
  2022-10-13 11:35  1% ` [PATCH v2] " pbhagavatula
  1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-10-13 10:16 UTC (permalink / raw)
  To: pbhagavatula, mb, jerinj, thomas, Shijith Thotton,
	Timothy McDaniel, Liang Ma, Peter Mccarthy, Harry van Haaren
  Cc: dev

On 2022-10-13 11:23, pbhagavatula@marvell.com wrote:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> 
> Increase xstats ID width to 64bits from 32 bits, this also

"Increase xstats ID width from 32 to 64 bits. This /../"

Not that "unsigned int" is always 32, but anyways, I guess that's true 
for all platforms DPDK supports.

> fixes the xstats ID datatype discrepancy between reset and
> rest of the xstats family.
> 
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
>   doc/guides/rel_notes/release_22_11.rst   |   5 ++
>   drivers/event/cnxk/cnxk_eventdev.h       |   6 +-
>   drivers/event/cnxk/cnxk_eventdev_stats.c |   6 +-
>   drivers/event/dlb2/dlb2_priv.h           |   8 +-
>   drivers/event/dlb2/dlb2_xstats.c         |  18 ++--
>   drivers/event/dsw/dsw_evdev.h            |   6 +-
>   drivers/event/dsw/dsw_xstats.c           |  32 +++----
>   drivers/event/opdl/opdl_evdev.h          |   8 +-
>   drivers/event/opdl/opdl_evdev_xstats.c   |   8 +-
>   drivers/event/opdl/opdl_test.c           |   4 +-
>   drivers/event/sw/sw_evdev.h              |   8 +-
>   drivers/event/sw/sw_evdev_selftest.c     | 101 +++++++++++------------
>   drivers/event/sw/sw_evdev_xstats.c       |  18 ++--
>   lib/eventdev/eventdev_pmd.h              |   8 +-
>   lib/eventdev/rte_eventdev.c              |  12 +--
>   lib/eventdev/rte_eventdev.h              |   8 +-
>   16 files changed, 128 insertions(+), 128 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
> index 2da8bc9661..6b76ad5566 100644
> --- a/doc/guides/rel_notes/release_22_11.rst
> +++ b/doc/guides/rel_notes/release_22_11.rst
> @@ -454,6 +454,11 @@ API Changes
>   
>   * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
>   
> +* eventdev: The datatype of the ID parameter in the functions
> +  ``rte_event_dev_xstats_names_get``, ``rte_event_dev_xstats_get``,
> +  ``rte_event_dev_xstats_by_name_get`` and ``rte_event_dev_xstats_reset``
> +  is changed to ``uint64_t`` from ``unsigned int`` and ``uint32_t``.
> +
>   
>   ABI Changes
>   -----------
> diff --git a/drivers/event/cnxk/cnxk_eventdev.h b/drivers/event/cnxk/cnxk_eventdev.h
> index f68c2aee23..738e335ea4 100644
> --- a/drivers/event/cnxk/cnxk_eventdev.h
> +++ b/drivers/event/cnxk/cnxk_eventdev.h
> @@ -271,14 +271,14 @@ int cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
>   			      enum rte_event_dev_xstats_mode mode,
>   			      uint8_t queue_port_id,
>   			      struct rte_event_dev_xstats_name *xstats_names,
> -			      unsigned int *ids, unsigned int size);
> +			      uint64_t *ids, unsigned int size);
>   int cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>   			enum rte_event_dev_xstats_mode mode,
> -			uint8_t queue_port_id, const unsigned int ids[],
> +			uint8_t queue_port_id, const uint64_t ids[],
>   			uint64_t values[], unsigned int n);
>   int cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
>   			  enum rte_event_dev_xstats_mode mode,
> -			  int16_t queue_port_id, const uint32_t ids[],
> +			  int16_t queue_port_id, const uint64_t ids[],
>   			  uint32_t n);
>   
>   /* CN9K */
> diff --git a/drivers/event/cnxk/cnxk_eventdev_stats.c b/drivers/event/cnxk/cnxk_eventdev_stats.c
> index a3b548f462..715ca9cd8f 100644
> --- a/drivers/event/cnxk/cnxk_eventdev_stats.c
> +++ b/drivers/event/cnxk/cnxk_eventdev_stats.c
> @@ -103,7 +103,7 @@ static struct cnxk_sso_xstats_name sso_hwgrp_xstats[] = {
>   int
>   cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>   		    enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		    const unsigned int ids[], uint64_t values[], unsigned int n)
> +		    const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
>   	struct roc_sso_hwgrp_stats hwgrp_stats;
> @@ -170,7 +170,7 @@ cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
>   int
>   cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
>   		      enum rte_event_dev_xstats_mode mode,
> -		      int16_t queue_port_id, const uint32_t ids[], uint32_t n)
> +		      int16_t queue_port_id, const uint64_t ids[], uint32_t n)
>   {
>   	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
>   	struct roc_sso_hwgrp_stats hwgrp_stats;
> @@ -235,7 +235,7 @@ cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
>   			  enum rte_event_dev_xstats_mode mode,
>   			  uint8_t queue_port_id,
>   			  struct rte_event_dev_xstats_name *xstats_names,
> -			  unsigned int *ids, unsigned int size)
> +			  uint64_t *ids, unsigned int size)
>   {
>   	struct rte_event_dev_xstats_name xstats_names_copy[CNXK_SSO_NUM_XSTATS];
>   	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
> diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
> index 9ef5bcb901..52f0ab9935 100644
> --- a/drivers/event/dlb2/dlb2_priv.h
> +++ b/drivers/event/dlb2/dlb2_priv.h
> @@ -688,20 +688,20 @@ void dlb2_xstats_uninit(struct dlb2_eventdev *dlb2);
>   
>   int dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n);
> +		const uint64_t ids[], uint64_t values[], unsigned int n);
>   
>   int dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstat_names,
> -		unsigned int *ids, unsigned int size);
> +		uint64_t *ids, unsigned int size);
>   
>   uint64_t dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
> -					  const char *name, unsigned int *id);
> +					  const char *name, uint64_t *id);
>   
>   int dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		int16_t queue_port_id,
> -		const uint32_t ids[],
> +		const uint64_t ids[],
>   		uint32_t nb_ids);
>   
>   int test_dlb2_eventdev(void);
> diff --git a/drivers/event/dlb2/dlb2_xstats.c b/drivers/event/dlb2/dlb2_xstats.c
> index d4c8d99034..ff15271dda 100644
> --- a/drivers/event/dlb2/dlb2_xstats.c
> +++ b/drivers/event/dlb2/dlb2_xstats.c
> @@ -666,7 +666,7 @@ int
>   dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size)
> +		uint64_t *ids, unsigned int size)
>   {
>   	const struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>   	unsigned int i;
> @@ -717,7 +717,7 @@ dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
>   static int
>   dlb2_xstats_update(struct dlb2_eventdev *dlb2,
>   		enum rte_event_dev_xstats_mode mode,
> -		uint8_t queue_port_id, const unsigned int ids[],
> +		uint8_t queue_port_id, const uint64_t ids[],
>   		uint64_t values[], unsigned int n, const uint32_t reset)
>   {
>   	unsigned int i;
> @@ -791,7 +791,7 @@ dlb2_xstats_update(struct dlb2_eventdev *dlb2,
>   int
>   dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n)
> +		const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>   	const uint32_t reset = 0;
> @@ -802,7 +802,7 @@ dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
>   
>   uint64_t
>   dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
> -				 const char *name, unsigned int *id)
> +				 const char *name, uint64_t *id)
>   {
>   	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
>   	unsigned int i;
> @@ -876,7 +876,7 @@ dlb2_xstats_reset_range(struct dlb2_eventdev *dlb2, uint32_t start,
>   
>   static int
>   dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
> -			const uint32_t ids[], uint32_t nb_ids)
> +			const uint64_t ids[], uint32_t nb_ids)
>   {
>   	const uint32_t reset = 1;
>   
> @@ -898,7 +898,7 @@ dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
>   
>   static int
>   dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
> -		       const uint32_t ids[], uint32_t nb_ids)
> +		       const uint64_t ids[], uint32_t nb_ids)
>   {
>   	const uint32_t reset = 1;
>   	int offset = dlb2->xstats_offset_for_port[port_id];
> @@ -917,14 +917,14 @@ dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
>   }
>   
>   static int
> -dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint32_t ids[],
> +dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint64_t ids[],
>   		      uint32_t nb_ids)
>   {
>   	uint32_t i;
>   
>   	if (ids) {
>   		for (i = 0; i < nb_ids; i++) {
> -			uint32_t id = ids[i];
> +			uint64_t id = ids[i];
>   
>   			if (id >= dlb2->xstats_count_mode_dev)
>   				return -EINVAL;
> @@ -942,7 +942,7 @@ int
>   dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
>   			   enum rte_event_dev_xstats_mode mode,
>   			   int16_t queue_port_id,
> -			   const uint32_t ids[],
> +			   const uint64_t ids[],
>   			   uint32_t nb_ids)
>   {
>   	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
> diff --git a/drivers/event/dsw/dsw_evdev.h b/drivers/event/dsw/dsw_evdev.h
> index df7dcc5577..6416a8a898 100644
> --- a/drivers/event/dsw/dsw_evdev.h
> +++ b/drivers/event/dsw/dsw_evdev.h
> @@ -283,12 +283,12 @@ int dsw_xstats_get_names(const struct rte_eventdev *dev,
>   			 enum rte_event_dev_xstats_mode mode,
>   			 uint8_t queue_port_id,
>   			 struct rte_event_dev_xstats_name *xstats_names,
> -			 unsigned int *ids, unsigned int size);
> +			 uint64_t *ids, unsigned int size);
>   int dsw_xstats_get(const struct rte_eventdev *dev,
>   		   enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		   const unsigned int ids[], uint64_t values[], unsigned int n);
> +		   const uint64_t ids[], uint64_t values[], unsigned int n);
>   uint64_t dsw_xstats_get_by_name(const struct rte_eventdev *dev,
> -				const char *name, unsigned int *id);
> +				const char *name, uint64_t *id);
>   
>   static inline struct dsw_evdev *
>   dsw_pmd_priv(const struct rte_eventdev *eventdev)
> diff --git a/drivers/event/dsw/dsw_xstats.c b/drivers/event/dsw/dsw_xstats.c
> index 4f7d4e3ff9..2409de6adc 100644
> --- a/drivers/event/dsw/dsw_xstats.c
> +++ b/drivers/event/dsw/dsw_xstats.c
> @@ -15,8 +15,8 @@
>    */
>   #define DSW_XSTATS_ID_PARAM_BITS (8)
>   #define DSW_XSTATS_ID_STAT_BITS					\
> -	(sizeof(unsigned int)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
> -#define DSW_XSTATS_ID_STAT_MASK ((1 << DSW_XSTATS_ID_STAT_BITS) - 1)
> +	(sizeof(uint64_t)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
> +#define DSW_XSTATS_ID_STAT_MASK ((1UL << DSW_XSTATS_ID_STAT_BITS) - 1)

Use UINT64_C(1) instead.

>   
>   #define DSW_XSTATS_ID_GET_PARAM(id)		\
>   	((id)>>DSW_XSTATS_ID_STAT_BITS)
> @@ -25,7 +25,7 @@
>   	((id) & DSW_XSTATS_ID_STAT_MASK)
>   
>   #define DSW_XSTATS_ID_CREATE(id, param_value)			\
> -	(((param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
> +	((((uint64_t)param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
>   
>   typedef
>   uint64_t (*dsw_xstats_dev_get_value_fn)(struct dsw_evdev *dsw);
> @@ -169,7 +169,7 @@ static struct dsw_xstats_port dsw_port_xstats[] = {
>   typedef
>   void (*dsw_xstats_foreach_fn)(const char *xstats_name,
>   			      enum rte_event_dev_xstats_mode mode,
> -			      uint8_t queue_port_id, unsigned int xstats_id,
> +			      uint8_t queue_port_id, uint64_t xstats_id,
>   			      void *data);
>   
>   static void
> @@ -193,7 +193,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
>   	     stat_idx < RTE_DIM(dsw_port_xstats);) {
>   		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
>   		char xstats_name[RTE_EVENT_DEV_XSTATS_NAME_SIZE];
> -		unsigned int xstats_id;
> +		uint64_t xstats_id;
>   
>   		if (xstat->per_queue) {
>   			xstats_id = DSW_XSTATS_ID_CREATE(stat_idx, queue_id);
> @@ -219,7 +219,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
>   
>   struct store_ctx {
>   	struct rte_event_dev_xstats_name *names;
> -	unsigned int *ids;
> +	uint64_t *ids;
>   	unsigned int count;
>   	unsigned int capacity;
>   };
> @@ -227,7 +227,7 @@ struct store_ctx {
>   static void
>   dsw_xstats_store_stat(const char *xstats_name,
>   		      enum rte_event_dev_xstats_mode mode,
> -		      uint8_t queue_port_id, unsigned int xstats_id,
> +		      uint8_t queue_port_id, uint64_t xstats_id,
>   		      void *data)
>   {
>   	struct store_ctx *ctx = data;
> @@ -248,7 +248,7 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
>   		     enum rte_event_dev_xstats_mode mode,
>   		     uint8_t queue_port_id,
>   		     struct rte_event_dev_xstats_name *xstats_names,
> -		     unsigned int *ids, unsigned int capacity)
> +		     uint64_t *ids, unsigned int capacity)
>   {
>   	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>   
> @@ -276,13 +276,13 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
>   
>   static int
>   dsw_xstats_dev_get(const struct rte_eventdev *dev,
> -		   const unsigned int ids[], uint64_t values[], unsigned int n)
> +		   const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>   	unsigned int i;
>   
>   	for (i = 0; i < n; i++) {
> -		unsigned int id = ids[i];
> +		uint64_t id = ids[i];
>   		struct dsw_xstat_dev *xstat = &dsw_dev_xstats[id];
>   		values[i] = xstat->get_value_fn(dsw);
>   	}
> @@ -291,13 +291,13 @@ dsw_xstats_dev_get(const struct rte_eventdev *dev,
>   
>   static int
>   dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
> -		    const unsigned int ids[], uint64_t values[], unsigned int n)
> +		    const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>   	unsigned int i;
>   
>   	for (i = 0; i < n; i++) {
> -		unsigned int id = ids[i];
> +		uint64_t id = ids[i];
>   		unsigned int stat_idx = DSW_XSTATS_ID_GET_STAT(id);
>   		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
>   		uint8_t queue_id = 0;
> @@ -313,7 +313,7 @@ dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
>   int
>   dsw_xstats_get(const struct rte_eventdev *dev,
>   	       enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -	       const unsigned int ids[], uint64_t values[], unsigned int n)
> +	       const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	switch (mode) {
>   	case RTE_EVENT_DEV_XSTATS_DEVICE:
> @@ -332,14 +332,14 @@ dsw_xstats_get(const struct rte_eventdev *dev,
>   struct find_ctx {
>   	const struct rte_eventdev *dev;
>   	const char *name;
> -	unsigned int *id;
> +	uint64_t *id;
>   	uint64_t value;
>   };
>   
>   static void
>   dsw_xstats_find_stat(const char *xstats_name,
>   		     enum rte_event_dev_xstats_mode mode,
> -		     uint8_t queue_port_id, unsigned int xstats_id,
> +		     uint8_t queue_port_id, uint64_t xstats_id,
>   		     void *data)
>   {
>   	struct find_ctx *ctx = data;
> @@ -354,7 +354,7 @@ dsw_xstats_find_stat(const char *xstats_name,
>   
>   uint64_t
>   dsw_xstats_get_by_name(const struct rte_eventdev *dev, const char *name,
> -		       unsigned int *id)
> +		       uint64_t *id)
>   {
>   	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
>   	uint16_t port_id;
> diff --git a/drivers/event/opdl/opdl_evdev.h b/drivers/event/opdl/opdl_evdev.h
> index 2dca0a8a98..1ca166b37c 100644
> --- a/drivers/event/opdl/opdl_evdev.h
> +++ b/drivers/event/opdl/opdl_evdev.h
> @@ -289,16 +289,16 @@ int opdl_xstats_uninit(struct rte_eventdev *dev);
>   int opdl_xstats_get_names(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size);
> +		uint64_t *ids, unsigned int size);
>   int opdl_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n);
> +		const uint64_t ids[], uint64_t values[], unsigned int n);
>   uint64_t opdl_xstats_get_by_name(const struct rte_eventdev *dev,
> -		const char *name, unsigned int *id);
> +		const char *name, uint64_t *id);
>   int opdl_xstats_reset(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		int16_t queue_port_id,
> -		const uint32_t ids[],
> +		const uint64_t ids[],
>   		uint32_t nb_ids);
>   
>   int opdl_add_event_handlers(struct rte_eventdev *dev);
> diff --git a/drivers/event/opdl/opdl_evdev_xstats.c b/drivers/event/opdl/opdl_evdev_xstats.c
> index 27b3d88023..b382f6619d 100644
> --- a/drivers/event/opdl/opdl_evdev_xstats.c
> +++ b/drivers/event/opdl/opdl_evdev_xstats.c
> @@ -65,7 +65,7 @@ opdl_xstats_get_names(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size)
> +		uint64_t *ids, unsigned int size)
>   {
>   	struct opdl_evdev *device = opdl_pmd_priv(dev);
>   
> @@ -99,7 +99,7 @@ int
>   opdl_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		uint8_t queue_port_id,
> -		const unsigned int ids[],
> +		const uint64_t ids[],
>   		uint64_t values[], unsigned int n)
>   {
>   	struct opdl_evdev *device = opdl_pmd_priv(dev);
> @@ -133,7 +133,7 @@ opdl_xstats_get(const struct rte_eventdev *dev,
>   
>   uint64_t
>   opdl_xstats_get_by_name(const struct rte_eventdev *dev,
> -		const char *name, unsigned int *id)
> +		const char *name, uint64_t *id)
>   {
>   	struct opdl_evdev *device = opdl_pmd_priv(dev);
>   
> @@ -161,7 +161,7 @@ opdl_xstats_get_by_name(const struct rte_eventdev *dev,
>   int
>   opdl_xstats_reset(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
> -		int16_t queue_port_id, const uint32_t ids[],
> +		int16_t queue_port_id, const uint64_t ids[],
>   		uint32_t nb_ids)
>   {
>   	struct opdl_evdev *device = opdl_pmd_priv(dev);
> diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
> index 3cbe2139ee..b69c4769dc 100644
> --- a/drivers/event/opdl/opdl_test.c
> +++ b/drivers/event/opdl/opdl_test.c
> @@ -471,7 +471,7 @@ atomic_basic(struct test *t)
>   	return 0;
>   }
>   static __rte_always_inline int
> -check_qid_stats(uint32_t id[], int index)
> +check_qid_stats(uint64_t id[], int index)
>   {
>   
>   	if (index == 0) {
> @@ -509,7 +509,7 @@ check_statistics(void)
>   				0);
>   		if (num_stats > 0) {
>   
> -			uint32_t id[num_stats];
> +			uint64_t id[num_stats];
>   			struct rte_event_dev_xstats_name names[num_stats];
>   			uint64_t values[num_stats];
>   
> diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
> index 8542b7d34d..c7b943a72b 100644
> --- a/drivers/event/sw/sw_evdev.h
> +++ b/drivers/event/sw/sw_evdev.h
> @@ -301,16 +301,16 @@ int sw_xstats_uninit(struct sw_evdev *dev);
>   int sw_xstats_get_names(const struct rte_eventdev *dev,
>   	enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   	struct rte_event_dev_xstats_name *xstats_names,
> -	unsigned int *ids, unsigned int size);
> +	uint64_t *ids, unsigned int size);
>   int sw_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n);
> +		const uint64_t ids[], uint64_t values[], unsigned int n);
>   uint64_t sw_xstats_get_by_name(const struct rte_eventdev *dev,
> -		const char *name, unsigned int *id);
> +		const char *name, uint64_t *id);
>   int sw_xstats_reset(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		int16_t queue_port_id,
> -		const uint32_t ids[],
> +		const uint64_t ids[],
>   		uint32_t nb_ids);
>   
>   int test_sw_eventdev(void);
> diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
> index ed7ae6a685..62d66744f2 100644
> --- a/drivers/event/sw/sw_evdev_selftest.c
> +++ b/drivers/event/sw/sw_evdev_selftest.c
> @@ -92,7 +92,7 @@ xstats_print(void)
>   {
>   	const uint32_t XSTATS_MAX = 1024;
>   	uint32_t i;
> -	uint32_t ids[XSTATS_MAX];
> +	uint64_t ids[XSTATS_MAX];
>   	uint64_t values[XSTATS_MAX];
>   	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>   
> @@ -310,15 +310,14 @@ static inline int
>   test_event_dev_stats_get(int dev_id, struct test_event_dev_stats *stats)
>   {
>   	static uint32_t i;
> -	static uint32_t total_ids[3]; /* rx, tx and drop */
> -	static uint32_t port_rx_pkts_ids[MAX_PORTS];
> -	static uint32_t port_rx_dropped_ids[MAX_PORTS];
> -	static uint32_t port_inflight_ids[MAX_PORTS];
> -	static uint32_t port_tx_pkts_ids[MAX_PORTS];
> -	static uint32_t qid_rx_pkts_ids[MAX_QIDS];
> -	static uint32_t qid_rx_dropped_ids[MAX_QIDS];
> -	static uint32_t qid_tx_pkts_ids[MAX_QIDS];
> -
> +	static uint64_t total_ids[3]; /* rx, tx and drop */
> +	static uint64_t port_rx_pkts_ids[MAX_PORTS];
> +	static uint64_t port_rx_dropped_ids[MAX_PORTS];
> +	static uint64_t port_inflight_ids[MAX_PORTS];
> +	static uint64_t port_tx_pkts_ids[MAX_PORTS];
> +	static uint64_t qid_rx_pkts_ids[MAX_QIDS];
> +	static uint64_t qid_rx_dropped_ids[MAX_QIDS];
> +	static uint64_t qid_tx_pkts_ids[MAX_QIDS];
>   
>   	stats->rx_pkts = rte_event_dev_xstats_by_name_get(dev_id,
>   			"dev_rx", &total_ids[0]);
> @@ -863,7 +862,7 @@ xstats_tests(struct test *t)
>   	const uint32_t XSTATS_MAX = 1024;
>   
>   	uint32_t i;
> -	uint32_t ids[XSTATS_MAX];
> +	uint64_t ids[XSTATS_MAX];
>   	uint64_t values[XSTATS_MAX];
>   	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>   
> @@ -963,11 +962,10 @@ xstats_tests(struct test *t)
>   	static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4, 1};
>   	for (i = 0; (signed int)i < ret; i++) {
>   		if (expected[i] != values[i]) {
> -			printf(
> -				"%d Error xstat %d (id %d) %s : %"PRIu64
> -				", expect %"PRIu64"\n",
> -				__LINE__, i, ids[i], xstats_names[i].name,
> -				values[i], expected[i]);
> +			printf("%d Error xstat %d (id %" PRIu64
> +			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +			       __LINE__, i, ids[i], xstats_names[i].name,
> +			       values[i], expected[i]);
>   			goto fail;
>   		}
>   	}
> @@ -982,11 +980,10 @@ xstats_tests(struct test *t)
>   					0, ids, values, num_stats);
>   	for (i = 0; (signed int)i < ret; i++) {
>   		if (expected_zero[i] != values[i]) {
> -			printf(
> -				"%d Error, xstat %d (id %d) %s : %"PRIu64
> -				", expect %"PRIu64"\n",
> -				__LINE__, i, ids[i], xstats_names[i].name,
> -				values[i], expected_zero[i]);
> +			printf("%d Error, xstat %d (id %" PRIu64
> +			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +			       __LINE__, i, ids[i], xstats_names[i].name,
> +			       values[i], expected_zero[i]);
>   			goto fail;
>   		}
>   	}
> @@ -1058,11 +1055,10 @@ xstats_tests(struct test *t)
>   					0, ids, values, num_stats);
>   	for (i = 0; (signed int)i < ret; i++) {
>   		if (port_expected_zero[i] != values[i]) {
> -			printf(
> -				"%d, Error, xstat %d (id %d) %s : %"PRIu64
> -				", expect %"PRIu64"\n",
> -				__LINE__, i, ids[i], xstats_names[i].name,
> -				values[i], port_expected_zero[i]);
> +			printf("%d, Error, xstat %d (id %" PRIu64
> +			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +			       __LINE__, i, ids[i], xstats_names[i].name,
> +			       values[i], port_expected_zero[i]);
>   			goto fail;
>   		}
>   	}
> @@ -1095,11 +1091,10 @@ xstats_tests(struct test *t)
>   	};
>   	for (i = 0; (signed int)i < ret; i++) {
>   		if (queue_expected[i] != values[i]) {
> -			printf(
> -				"%d, Error, xstat %d (id %d) %s : %"PRIu64
> -				", expect %"PRIu64"\n",
> -				__LINE__, i, ids[i], xstats_names[i].name,
> -				values[i], queue_expected[i]);
> +			printf("%d, Error, xstat %d (id %" PRIu64
> +			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +			       __LINE__, i, ids[i], xstats_names[i].name,
> +			       values[i], queue_expected[i]);
>   			goto fail;
>   		}
>   	}
> @@ -1129,11 +1124,10 @@ xstats_tests(struct test *t)
>   	int fails = 0;
>   	for (i = 0; (signed int)i < ret; i++) {
>   		if (queue_expected_zero[i] != values[i]) {
> -			printf(
> -				"%d, Error, xstat %d (id %d) %s : %"PRIu64
> -				", expect %"PRIu64"\n",
> -				__LINE__, i, ids[i], xstats_names[i].name,
> -				values[i], queue_expected_zero[i]);
> +			printf("%d, Error, xstat %d (id %" PRIu64
> +			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
> +			       __LINE__, i, ids[i], xstats_names[i].name,
> +			       values[i], queue_expected_zero[i]);
>   			fails++;
>   		}
>   	}
> @@ -1160,7 +1154,7 @@ xstats_id_abuse_tests(struct test *t)
>   	const uint32_t XSTATS_MAX = 1024;
>   	const uint32_t link_port = 2;
>   
> -	uint32_t ids[XSTATS_MAX];
> +	uint64_t ids[XSTATS_MAX];
>   	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>   
>   	/* Create instance with 4 ports */
> @@ -1379,7 +1373,7 @@ xstats_brute_force(struct test *t)
>   {
>   	uint32_t i;
>   	const uint32_t XSTATS_MAX = 1024;
> -	uint32_t ids[XSTATS_MAX];
> +	uint64_t ids[XSTATS_MAX];
>   	uint64_t values[XSTATS_MAX];
>   	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>   
> @@ -1454,7 +1448,7 @@ xstats_id_reset_tests(struct test *t)
>   #define XSTATS_MAX 1024
>   	int ret;
>   	uint32_t i;
> -	uint32_t ids[XSTATS_MAX];
> +	uint64_t ids[XSTATS_MAX];
>   	uint64_t values[XSTATS_MAX];
>   	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
>   
> @@ -1510,13 +1504,14 @@ xstats_id_reset_tests(struct test *t)
>   	};
>   	uint64_t dev_expected[] = {NPKTS, NPKTS, 0, 1, 0, 0, 4, 1};
>   	for (i = 0; (int)i < ret; i++) {
> -		unsigned int id;
> +		uint64_t id;
>   		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>   								dev_names[i],
>   								&id);
>   		if (id != i) {
> -			printf("%d: %s id incorrect, expected %d got %d\n",
> -					__LINE__, dev_names[i], i, id);
> +			printf("%d: %s id incorrect, expected %d got %" PRIu64
> +			       "\n",
> +			       __LINE__, dev_names[i], i, id);
>   			goto fail;
>   		}
>   		if (val != dev_expected[i]) {
> @@ -1631,20 +1626,20 @@ xstats_id_reset_tests(struct test *t)
>   
>   	int failed = 0;
>   	for (i = 0; (int)i < ret; i++) {
> -		unsigned int id;
> +		uint64_t id;
>   		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>   								port_names[i],
>   								&id);
>   		if (id != i + PORT_OFF) {
> -			printf("%d: %s id incorrect, expected %d got %d\n",
> -					__LINE__, port_names[i], i+PORT_OFF,
> -					id);
> +			printf("%d: %s id incorrect, expected %d got %" PRIu64
> +			       "\n",
> +			       __LINE__, port_names[i], i + PORT_OFF, id);
>   			failed = 1;
>   		}
>   		if (val != port_expected[i]) {
> -			printf("%d: %s value incorrect, expected %"PRIu64
> -				" got %d\n", __LINE__, port_names[i],
> -				port_expected[i], id);
> +			printf("%d: %s value incorrect, expected %" PRIu64
> +			       " got %" PRIu64 "\n",
> +			       __LINE__, port_names[i], port_expected[i], id);
>   			failed = 1;
>   		}
>   		/* reset to zero */
> @@ -1746,14 +1741,14 @@ xstats_id_reset_tests(struct test *t)
>   
>   	failed = 0;
>   	for (i = 0; (int)i < ret; i++) {
> -		unsigned int id;
> +		uint64_t id;
>   		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
>   								queue_names[i],
>   								&id);
>   		if (id != i + QUEUE_OFF) {
> -			printf("%d: %s id incorrect, expected %d got %d\n",
> -					__LINE__, queue_names[i], i+QUEUE_OFF,
> -					id);
> +			printf("%d: %s id incorrect, expected %d got %" PRIu64
> +			       "\n",
> +			       __LINE__, queue_names[i], i + QUEUE_OFF, id);
>   			failed = 1;
>   		}
>   		if (val != queue_expected[i]) {
> diff --git a/drivers/event/sw/sw_evdev_xstats.c b/drivers/event/sw/sw_evdev_xstats.c
> index c2647d7da2..fbac8f3ab5 100644
> --- a/drivers/event/sw/sw_evdev_xstats.c
> +++ b/drivers/event/sw/sw_evdev_xstats.c
> @@ -393,7 +393,7 @@ int
>   sw_xstats_get_names(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size)
> +		uint64_t *ids, unsigned int size)
>   {
>   	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
>   	unsigned int i;
> @@ -444,7 +444,7 @@ sw_xstats_get_names(const struct rte_eventdev *dev,
>   
>   static int
>   sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
> -		uint8_t queue_port_id, const unsigned int ids[],
> +		uint8_t queue_port_id, const uint64_t ids[],
>   		uint64_t values[], unsigned int n, const uint32_t reset,
>   		const uint32_t ret_if_n_lt_nstats)
>   {
> @@ -509,7 +509,7 @@ sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
>   int
>   sw_xstats_get(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n)
> +		const uint64_t ids[], uint64_t values[], unsigned int n)
>   {
>   	struct sw_evdev *sw = sw_pmd_priv(dev);
>   	const uint32_t reset = 0;
> @@ -520,7 +520,7 @@ sw_xstats_get(const struct rte_eventdev *dev,
>   
>   uint64_t
>   sw_xstats_get_by_name(const struct rte_eventdev *dev,
> -		const char *name, unsigned int *id)
> +		const char *name, uint64_t *id)
>   {
>   	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
>   	unsigned int i;
> @@ -556,7 +556,7 @@ sw_xstats_reset_range(struct sw_evdev *sw, uint32_t start, uint32_t num)
>   
>   static int
>   sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
> -		const uint32_t ids[], uint32_t nb_ids)
> +		const uint64_t ids[], uint32_t nb_ids)
>   {
>   	const uint32_t reset = 1;
>   	const uint32_t ret_n_lt_stats = 0;
> @@ -577,7 +577,7 @@ sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
>   
>   static int
>   sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
> -		const uint32_t ids[], uint32_t nb_ids)
> +		const uint64_t ids[], uint32_t nb_ids)
>   {
>   	const uint32_t reset = 1;
>   	const uint32_t ret_n_lt_stats = 0;
> @@ -597,12 +597,12 @@ sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
>   }
>   
>   static int
> -sw_xstats_reset_dev(struct sw_evdev *sw, const uint32_t ids[], uint32_t nb_ids)
> +sw_xstats_reset_dev(struct sw_evdev *sw, const uint64_t ids[], uint32_t nb_ids)
>   {
>   	uint32_t i;
>   	if (ids) {
>   		for (i = 0; i < nb_ids; i++) {
> -			uint32_t id = ids[i];
> +			uint64_t id = ids[i];
>   			if (id >= sw->xstats_count_mode_dev)
>   				return -EINVAL;
>   			sw_xstats_reset_range(sw, id, 1);
> @@ -619,7 +619,7 @@ int
>   sw_xstats_reset(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		int16_t queue_port_id,
> -		const uint32_t ids[],
> +		const uint64_t ids[],
>   		uint32_t nb_ids)
>   {
>   	struct sw_evdev *sw = sw_pmd_priv(dev);
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index e49ff23db5..aebab26852 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -529,7 +529,7 @@ typedef void (*eventdev_dump_t)(struct rte_eventdev *dev, FILE *f);
>    */
>   typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
> -		const unsigned int ids[], uint64_t values[], unsigned int n);
> +		const uint64_t ids[], uint64_t values[], unsigned int n);
>   
>   /**
>    * Resets the statistic values in xstats for the device, based on mode.
> @@ -537,7 +537,7 @@ typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
>   typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode,
>   		int16_t queue_port_id,
> -		const uint32_t ids[],
> +		const uint64_t ids[],
>   		uint32_t nb_ids);
>   
>   /**
> @@ -564,7 +564,7 @@ typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
>   typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size);
> +		uint64_t *ids, unsigned int size);
>   
>   /**
>    * Get value of one stats and optionally return its id
> @@ -582,7 +582,7 @@ typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
>    *   if id pointer is non-NULL
>    */
>   typedef uint64_t (*eventdev_xstats_get_by_name)(const struct rte_eventdev *dev,
> -		const char *name, unsigned int *id);
> +		const char *name, uint64_t *id);
>   
>   
>   /**
> diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
> index 845f8dbb6e..b0414206d9 100644
> --- a/lib/eventdev/rte_eventdev.c
> +++ b/lib/eventdev/rte_eventdev.c
> @@ -1161,7 +1161,7 @@ int
>   rte_event_dev_xstats_names_get(uint8_t dev_id,
>   		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
>   		struct rte_event_dev_xstats_name *xstats_names,
> -		unsigned int *ids, unsigned int size)
> +		uint64_t *ids, unsigned int size)
>   {
>   	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
>   	const int cnt_expected_entries = xstats_get_count(dev_id, mode,
> @@ -1183,7 +1183,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
>   /* retrieve eventdev extended statistics */
>   int
>   rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
> -		uint8_t queue_port_id, const unsigned int ids[],
> +		uint8_t queue_port_id, const uint64_t ids[],
>   		uint64_t values[], unsigned int n)
>   {
>   	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
> @@ -1198,11 +1198,11 @@ rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
>   
>   uint64_t
>   rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
> -		unsigned int *id)
> +		uint64_t *id)
>   {
>   	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
>   	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> -	unsigned int temp = -1;
> +	uint64_t temp = -1;
>   
>   	if (id != NULL)
>   		*id = (unsigned int)-1;
> @@ -1217,7 +1217,7 @@ rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
>   
>   int rte_event_dev_xstats_reset(uint8_t dev_id,
>   		enum rte_event_dev_xstats_mode mode, int16_t queue_port_id,
> -		const uint32_t ids[], uint32_t nb_ids)
> +		const uint64_t ids[], uint32_t nb_ids)
>   {
>   	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
>   	struct rte_eventdev *dev = &rte_eventdevs[dev_id];
> @@ -1658,7 +1658,7 @@ eventdev_build_telemetry_data(int dev_id,
>   			      struct rte_tel_data *d)
>   {
>   	struct rte_event_dev_xstats_name *xstat_names;
> -	unsigned int *ids;
> +	uint64_t *ids;
>   	uint64_t *values;
>   	int i, ret, num_xstats;
>   
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 60e9043ac4..82e8976e57 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -1784,7 +1784,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
>   			       enum rte_event_dev_xstats_mode mode,
>   			       uint8_t queue_port_id,
>   			       struct rte_event_dev_xstats_name *xstats_names,
> -			       unsigned int *ids,
> +			       uint64_t *ids,
>   			       unsigned int size);
>   
>   /**
> @@ -1817,7 +1817,7 @@ int
>   rte_event_dev_xstats_get(uint8_t dev_id,
>   			 enum rte_event_dev_xstats_mode mode,
>   			 uint8_t queue_port_id,
> -			 const unsigned int ids[],
> +			 const uint64_t ids[],
>   			 uint64_t values[], unsigned int n);
>   
>   /**
> @@ -1838,7 +1838,7 @@ rte_event_dev_xstats_get(uint8_t dev_id,
>    */
>   uint64_t
>   rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
> -				 unsigned int *id);
> +				 uint64_t *id);
>   
>   /**
>    * Reset the values of the xstats of the selected component in the device.
> @@ -1864,7 +1864,7 @@ int
>   rte_event_dev_xstats_reset(uint8_t dev_id,
>   			   enum rte_event_dev_xstats_mode mode,
>   			   int16_t queue_port_id,
> -			   const uint32_t ids[],
> +			   const uint64_t ids[],
>   			   uint32_t nb_ids);
>   
>   /**

With the minor fixes:
Reviewed-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>



^ permalink raw reply	[relevance 0%]

* [PATCH] eventdev: increase xstats ID width to 64 bits
@ 2022-10-13  9:23  2% pbhagavatula
  2022-10-13 10:16  0% ` Mattias Rönnblom
  2022-10-13 11:35  1% ` [PATCH v2] " pbhagavatula
  0 siblings, 2 replies; 200+ results
From: pbhagavatula @ 2022-10-13  9:23 UTC (permalink / raw)
  To: mb, jerinj, thomas, Pavan Nikhilesh, Shijith Thotton,
	Timothy McDaniel, Mattias Ronnblom, Liang Ma, Peter Mccarthy,
	Harry van Haaren
  Cc: dev

From: Pavan Nikhilesh <pbhagavatula@marvell.com>

Increase xstats ID width to 64bits from 32 bits, this also
fixes the xstats ID datatype discrepancy between reset and
rest of the xstats family.

Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
 doc/guides/rel_notes/release_22_11.rst   |   5 ++
 drivers/event/cnxk/cnxk_eventdev.h       |   6 +-
 drivers/event/cnxk/cnxk_eventdev_stats.c |   6 +-
 drivers/event/dlb2/dlb2_priv.h           |   8 +-
 drivers/event/dlb2/dlb2_xstats.c         |  18 ++--
 drivers/event/dsw/dsw_evdev.h            |   6 +-
 drivers/event/dsw/dsw_xstats.c           |  32 +++----
 drivers/event/opdl/opdl_evdev.h          |   8 +-
 drivers/event/opdl/opdl_evdev_xstats.c   |   8 +-
 drivers/event/opdl/opdl_test.c           |   4 +-
 drivers/event/sw/sw_evdev.h              |   8 +-
 drivers/event/sw/sw_evdev_selftest.c     | 101 +++++++++++------------
 drivers/event/sw/sw_evdev_xstats.c       |  18 ++--
 lib/eventdev/eventdev_pmd.h              |   8 +-
 lib/eventdev/rte_eventdev.c              |  12 +--
 lib/eventdev/rte_eventdev.h              |   8 +-
 16 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
index 2da8bc9661..6b76ad5566 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -454,6 +454,11 @@ API Changes
 
 * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
 
+* eventdev: The datatype of the ID parameter in the functions
+  ``rte_event_dev_xstats_names_get``, ``rte_event_dev_xstats_get``,
+  ``rte_event_dev_xstats_by_name_get`` and ``rte_event_dev_xstats_reset``
+  is changed to ``uint64_t`` from ``unsigned int`` and ``uint32_t``.
+
 
 ABI Changes
 -----------
diff --git a/drivers/event/cnxk/cnxk_eventdev.h b/drivers/event/cnxk/cnxk_eventdev.h
index f68c2aee23..738e335ea4 100644
--- a/drivers/event/cnxk/cnxk_eventdev.h
+++ b/drivers/event/cnxk/cnxk_eventdev.h
@@ -271,14 +271,14 @@ int cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
 			      enum rte_event_dev_xstats_mode mode,
 			      uint8_t queue_port_id,
 			      struct rte_event_dev_xstats_name *xstats_names,
-			      unsigned int *ids, unsigned int size);
+			      uint64_t *ids, unsigned int size);
 int cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 			enum rte_event_dev_xstats_mode mode,
-			uint8_t queue_port_id, const unsigned int ids[],
+			uint8_t queue_port_id, const uint64_t ids[],
 			uint64_t values[], unsigned int n);
 int cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
 			  enum rte_event_dev_xstats_mode mode,
-			  int16_t queue_port_id, const uint32_t ids[],
+			  int16_t queue_port_id, const uint64_t ids[],
 			  uint32_t n);
 
 /* CN9K */
diff --git a/drivers/event/cnxk/cnxk_eventdev_stats.c b/drivers/event/cnxk/cnxk_eventdev_stats.c
index a3b548f462..715ca9cd8f 100644
--- a/drivers/event/cnxk/cnxk_eventdev_stats.c
+++ b/drivers/event/cnxk/cnxk_eventdev_stats.c
@@ -103,7 +103,7 @@ static struct cnxk_sso_xstats_name sso_hwgrp_xstats[] = {
 int
 cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 		    enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		    const unsigned int ids[], uint64_t values[], unsigned int n)
+		    const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
 	struct roc_sso_hwgrp_stats hwgrp_stats;
@@ -170,7 +170,7 @@ cnxk_sso_xstats_get(const struct rte_eventdev *event_dev,
 int
 cnxk_sso_xstats_reset(struct rte_eventdev *event_dev,
 		      enum rte_event_dev_xstats_mode mode,
-		      int16_t queue_port_id, const uint32_t ids[], uint32_t n)
+		      int16_t queue_port_id, const uint64_t ids[], uint32_t n)
 {
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
 	struct roc_sso_hwgrp_stats hwgrp_stats;
@@ -235,7 +235,7 @@ cnxk_sso_xstats_get_names(const struct rte_eventdev *event_dev,
 			  enum rte_event_dev_xstats_mode mode,
 			  uint8_t queue_port_id,
 			  struct rte_event_dev_xstats_name *xstats_names,
-			  unsigned int *ids, unsigned int size)
+			  uint64_t *ids, unsigned int size)
 {
 	struct rte_event_dev_xstats_name xstats_names_copy[CNXK_SSO_NUM_XSTATS];
 	struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index 9ef5bcb901..52f0ab9935 100644
--- a/drivers/event/dlb2/dlb2_priv.h
+++ b/drivers/event/dlb2/dlb2_priv.h
@@ -688,20 +688,20 @@ void dlb2_xstats_uninit(struct dlb2_eventdev *dlb2);
 
 int dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 
 int dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstat_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);
 
 uint64_t dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
-					  const char *name, unsigned int *id);
+					  const char *name, uint64_t *id);
 
 int dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);
 
 int test_dlb2_eventdev(void);
diff --git a/drivers/event/dlb2/dlb2_xstats.c b/drivers/event/dlb2/dlb2_xstats.c
index d4c8d99034..ff15271dda 100644
--- a/drivers/event/dlb2/dlb2_xstats.c
+++ b/drivers/event/dlb2/dlb2_xstats.c
@@ -666,7 +666,7 @@ int
 dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	const struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	unsigned int i;
@@ -717,7 +717,7 @@ dlb2_eventdev_xstats_get_names(const struct rte_eventdev *dev,
 static int
 dlb2_xstats_update(struct dlb2_eventdev *dlb2,
 		enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n, const uint32_t reset)
 {
 	unsigned int i;
@@ -791,7 +791,7 @@ dlb2_xstats_update(struct dlb2_eventdev *dlb2,
 int
 dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n)
+		const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	const uint32_t reset = 0;
@@ -802,7 +802,7 @@ dlb2_eventdev_xstats_get(const struct rte_eventdev *dev,
 
 uint64_t
 dlb2_eventdev_xstats_get_by_name(const struct rte_eventdev *dev,
-				 const char *name, unsigned int *id)
+				 const char *name, uint64_t *id)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
 	unsigned int i;
@@ -876,7 +876,7 @@ dlb2_xstats_reset_range(struct dlb2_eventdev *dlb2, uint32_t start,
 
 static int
 dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
-			const uint32_t ids[], uint32_t nb_ids)
+			const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 
@@ -898,7 +898,7 @@ dlb2_xstats_reset_queue(struct dlb2_eventdev *dlb2, uint8_t queue_id,
 
 static int
 dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
-		       const uint32_t ids[], uint32_t nb_ids)
+		       const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	int offset = dlb2->xstats_offset_for_port[port_id];
@@ -917,14 +917,14 @@ dlb2_xstats_reset_port(struct dlb2_eventdev *dlb2, uint8_t port_id,
 }
 
 static int
-dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint32_t ids[],
+dlb2_xstats_reset_dev(struct dlb2_eventdev *dlb2, const uint64_t ids[],
 		      uint32_t nb_ids)
 {
 	uint32_t i;
 
 	if (ids) {
 		for (i = 0; i < nb_ids; i++) {
-			uint32_t id = ids[i];
+			uint64_t id = ids[i];
 
 			if (id >= dlb2->xstats_count_mode_dev)
 				return -EINVAL;
@@ -942,7 +942,7 @@ int
 dlb2_eventdev_xstats_reset(struct rte_eventdev *dev,
 			   enum rte_event_dev_xstats_mode mode,
 			   int16_t queue_port_id,
-			   const uint32_t ids[],
+			   const uint64_t ids[],
 			   uint32_t nb_ids)
 {
 	struct dlb2_eventdev *dlb2 = dlb2_pmd_priv(dev);
diff --git a/drivers/event/dsw/dsw_evdev.h b/drivers/event/dsw/dsw_evdev.h
index df7dcc5577..6416a8a898 100644
--- a/drivers/event/dsw/dsw_evdev.h
+++ b/drivers/event/dsw/dsw_evdev.h
@@ -283,12 +283,12 @@ int dsw_xstats_get_names(const struct rte_eventdev *dev,
 			 enum rte_event_dev_xstats_mode mode,
 			 uint8_t queue_port_id,
 			 struct rte_event_dev_xstats_name *xstats_names,
-			 unsigned int *ids, unsigned int size);
+			 uint64_t *ids, unsigned int size);
 int dsw_xstats_get(const struct rte_eventdev *dev,
 		   enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		   const unsigned int ids[], uint64_t values[], unsigned int n);
+		   const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t dsw_xstats_get_by_name(const struct rte_eventdev *dev,
-				const char *name, unsigned int *id);
+				const char *name, uint64_t *id);
 
 static inline struct dsw_evdev *
 dsw_pmd_priv(const struct rte_eventdev *eventdev)
diff --git a/drivers/event/dsw/dsw_xstats.c b/drivers/event/dsw/dsw_xstats.c
index 4f7d4e3ff9..2409de6adc 100644
--- a/drivers/event/dsw/dsw_xstats.c
+++ b/drivers/event/dsw/dsw_xstats.c
@@ -15,8 +15,8 @@
  */
 #define DSW_XSTATS_ID_PARAM_BITS (8)
 #define DSW_XSTATS_ID_STAT_BITS					\
-	(sizeof(unsigned int)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
-#define DSW_XSTATS_ID_STAT_MASK ((1 << DSW_XSTATS_ID_STAT_BITS) - 1)
+	(sizeof(uint64_t)*CHAR_BIT - DSW_XSTATS_ID_PARAM_BITS)
+#define DSW_XSTATS_ID_STAT_MASK ((1UL << DSW_XSTATS_ID_STAT_BITS) - 1)
 
 #define DSW_XSTATS_ID_GET_PARAM(id)		\
 	((id)>>DSW_XSTATS_ID_STAT_BITS)
@@ -25,7 +25,7 @@
 	((id) & DSW_XSTATS_ID_STAT_MASK)
 
 #define DSW_XSTATS_ID_CREATE(id, param_value)			\
-	(((param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
+	((((uint64_t)param_value) << DSW_XSTATS_ID_STAT_BITS) | id)
 
 typedef
 uint64_t (*dsw_xstats_dev_get_value_fn)(struct dsw_evdev *dsw);
@@ -169,7 +169,7 @@ static struct dsw_xstats_port dsw_port_xstats[] = {
 typedef
 void (*dsw_xstats_foreach_fn)(const char *xstats_name,
 			      enum rte_event_dev_xstats_mode mode,
-			      uint8_t queue_port_id, unsigned int xstats_id,
+			      uint8_t queue_port_id, uint64_t xstats_id,
 			      void *data);
 
 static void
@@ -193,7 +193,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
 	     stat_idx < RTE_DIM(dsw_port_xstats);) {
 		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
 		char xstats_name[RTE_EVENT_DEV_XSTATS_NAME_SIZE];
-		unsigned int xstats_id;
+		uint64_t xstats_id;
 
 		if (xstat->per_queue) {
 			xstats_id = DSW_XSTATS_ID_CREATE(stat_idx, queue_id);
@@ -219,7 +219,7 @@ dsw_xstats_port_foreach(struct dsw_evdev *dsw, uint8_t port_id,
 
 struct store_ctx {
 	struct rte_event_dev_xstats_name *names;
-	unsigned int *ids;
+	uint64_t *ids;
 	unsigned int count;
 	unsigned int capacity;
 };
@@ -227,7 +227,7 @@ struct store_ctx {
 static void
 dsw_xstats_store_stat(const char *xstats_name,
 		      enum rte_event_dev_xstats_mode mode,
-		      uint8_t queue_port_id, unsigned int xstats_id,
+		      uint8_t queue_port_id, uint64_t xstats_id,
 		      void *data)
 {
 	struct store_ctx *ctx = data;
@@ -248,7 +248,7 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
 		     enum rte_event_dev_xstats_mode mode,
 		     uint8_t queue_port_id,
 		     struct rte_event_dev_xstats_name *xstats_names,
-		     unsigned int *ids, unsigned int capacity)
+		     uint64_t *ids, unsigned int capacity)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 
@@ -276,13 +276,13 @@ dsw_xstats_get_names(const struct rte_eventdev *dev,
 
 static int
 dsw_xstats_dev_get(const struct rte_eventdev *dev,
-		   const unsigned int ids[], uint64_t values[], unsigned int n)
+		   const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	unsigned int i;
 
 	for (i = 0; i < n; i++) {
-		unsigned int id = ids[i];
+		uint64_t id = ids[i];
 		struct dsw_xstat_dev *xstat = &dsw_dev_xstats[id];
 		values[i] = xstat->get_value_fn(dsw);
 	}
@@ -291,13 +291,13 @@ dsw_xstats_dev_get(const struct rte_eventdev *dev,
 
 static int
 dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
-		    const unsigned int ids[], uint64_t values[], unsigned int n)
+		    const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	unsigned int i;
 
 	for (i = 0; i < n; i++) {
-		unsigned int id = ids[i];
+		uint64_t id = ids[i];
 		unsigned int stat_idx = DSW_XSTATS_ID_GET_STAT(id);
 		struct dsw_xstats_port *xstat = &dsw_port_xstats[stat_idx];
 		uint8_t queue_id = 0;
@@ -313,7 +313,7 @@ dsw_xstats_port_get(const struct rte_eventdev *dev, uint8_t port_id,
 int
 dsw_xstats_get(const struct rte_eventdev *dev,
 	       enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-	       const unsigned int ids[], uint64_t values[], unsigned int n)
+	       const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	switch (mode) {
 	case RTE_EVENT_DEV_XSTATS_DEVICE:
@@ -332,14 +332,14 @@ dsw_xstats_get(const struct rte_eventdev *dev,
 struct find_ctx {
 	const struct rte_eventdev *dev;
 	const char *name;
-	unsigned int *id;
+	uint64_t *id;
 	uint64_t value;
 };
 
 static void
 dsw_xstats_find_stat(const char *xstats_name,
 		     enum rte_event_dev_xstats_mode mode,
-		     uint8_t queue_port_id, unsigned int xstats_id,
+		     uint8_t queue_port_id, uint64_t xstats_id,
 		     void *data)
 {
 	struct find_ctx *ctx = data;
@@ -354,7 +354,7 @@ dsw_xstats_find_stat(const char *xstats_name,
 
 uint64_t
 dsw_xstats_get_by_name(const struct rte_eventdev *dev, const char *name,
-		       unsigned int *id)
+		       uint64_t *id)
 {
 	struct dsw_evdev *dsw = dsw_pmd_priv(dev);
 	uint16_t port_id;
diff --git a/drivers/event/opdl/opdl_evdev.h b/drivers/event/opdl/opdl_evdev.h
index 2dca0a8a98..1ca166b37c 100644
--- a/drivers/event/opdl/opdl_evdev.h
+++ b/drivers/event/opdl/opdl_evdev.h
@@ -289,16 +289,16 @@ int opdl_xstats_uninit(struct rte_eventdev *dev);
 int opdl_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);
 int opdl_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t opdl_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);
 int opdl_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);
 
 int opdl_add_event_handlers(struct rte_eventdev *dev);
diff --git a/drivers/event/opdl/opdl_evdev_xstats.c b/drivers/event/opdl/opdl_evdev_xstats.c
index 27b3d88023..b382f6619d 100644
--- a/drivers/event/opdl/opdl_evdev_xstats.c
+++ b/drivers/event/opdl/opdl_evdev_xstats.c
@@ -65,7 +65,7 @@ opdl_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
 
@@ -99,7 +99,7 @@ int
 opdl_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		uint8_t queue_port_id,
-		const unsigned int ids[],
+		const uint64_t ids[],
 		uint64_t values[], unsigned int n)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
@@ -133,7 +133,7 @@ opdl_xstats_get(const struct rte_eventdev *dev,
 
 uint64_t
 opdl_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id)
+		const char *name, uint64_t *id)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
 
@@ -161,7 +161,7 @@ opdl_xstats_get_by_name(const struct rte_eventdev *dev,
 int
 opdl_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
-		int16_t queue_port_id, const uint32_t ids[],
+		int16_t queue_port_id, const uint64_t ids[],
 		uint32_t nb_ids)
 {
 	struct opdl_evdev *device = opdl_pmd_priv(dev);
diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
index 3cbe2139ee..b69c4769dc 100644
--- a/drivers/event/opdl/opdl_test.c
+++ b/drivers/event/opdl/opdl_test.c
@@ -471,7 +471,7 @@ atomic_basic(struct test *t)
 	return 0;
 }
 static __rte_always_inline int
-check_qid_stats(uint32_t id[], int index)
+check_qid_stats(uint64_t id[], int index)
 {
 
 	if (index == 0) {
@@ -509,7 +509,7 @@ check_statistics(void)
 				0);
 		if (num_stats > 0) {
 
-			uint32_t id[num_stats];
+			uint64_t id[num_stats];
 			struct rte_event_dev_xstats_name names[num_stats];
 			uint64_t values[num_stats];
 
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index 8542b7d34d..c7b943a72b 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -301,16 +301,16 @@ int sw_xstats_uninit(struct sw_evdev *dev);
 int sw_xstats_get_names(const struct rte_eventdev *dev,
 	enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 	struct rte_event_dev_xstats_name *xstats_names,
-	unsigned int *ids, unsigned int size);
+	uint64_t *ids, unsigned int size);
 int sw_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 uint64_t sw_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);
 int sw_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);
 
 int test_sw_eventdev(void);
diff --git a/drivers/event/sw/sw_evdev_selftest.c b/drivers/event/sw/sw_evdev_selftest.c
index ed7ae6a685..62d66744f2 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -92,7 +92,7 @@ xstats_print(void)
 {
 	const uint32_t XSTATS_MAX = 1024;
 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
 
@@ -310,15 +310,14 @@ static inline int
 test_event_dev_stats_get(int dev_id, struct test_event_dev_stats *stats)
 {
 	static uint32_t i;
-	static uint32_t total_ids[3]; /* rx, tx and drop */
-	static uint32_t port_rx_pkts_ids[MAX_PORTS];
-	static uint32_t port_rx_dropped_ids[MAX_PORTS];
-	static uint32_t port_inflight_ids[MAX_PORTS];
-	static uint32_t port_tx_pkts_ids[MAX_PORTS];
-	static uint32_t qid_rx_pkts_ids[MAX_QIDS];
-	static uint32_t qid_rx_dropped_ids[MAX_QIDS];
-	static uint32_t qid_tx_pkts_ids[MAX_QIDS];
-
+	static uint64_t total_ids[3]; /* rx, tx and drop */
+	static uint64_t port_rx_pkts_ids[MAX_PORTS];
+	static uint64_t port_rx_dropped_ids[MAX_PORTS];
+	static uint64_t port_inflight_ids[MAX_PORTS];
+	static uint64_t port_tx_pkts_ids[MAX_PORTS];
+	static uint64_t qid_rx_pkts_ids[MAX_QIDS];
+	static uint64_t qid_rx_dropped_ids[MAX_QIDS];
+	static uint64_t qid_tx_pkts_ids[MAX_QIDS];
 
 	stats->rx_pkts = rte_event_dev_xstats_by_name_get(dev_id,
 			"dev_rx", &total_ids[0]);
@@ -863,7 +862,7 @@ xstats_tests(struct test *t)
 	const uint32_t XSTATS_MAX = 1024;
 
 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
 
@@ -963,11 +962,10 @@ xstats_tests(struct test *t)
 	static const uint64_t expected[] = {3, 3, 0, 1, 0, 0, 4, 1};
 	for (i = 0; (signed int)i < ret; i++) {
 		if (expected[i] != values[i]) {
-			printf(
-				"%d Error xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], expected[i]);
+			printf("%d Error xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], expected[i]);
 			goto fail;
 		}
 	}
@@ -982,11 +980,10 @@ xstats_tests(struct test *t)
 					0, ids, values, num_stats);
 	for (i = 0; (signed int)i < ret; i++) {
 		if (expected_zero[i] != values[i]) {
-			printf(
-				"%d Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], expected_zero[i]);
+			printf("%d Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], expected_zero[i]);
 			goto fail;
 		}
 	}
@@ -1058,11 +1055,10 @@ xstats_tests(struct test *t)
 					0, ids, values, num_stats);
 	for (i = 0; (signed int)i < ret; i++) {
 		if (port_expected_zero[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], port_expected_zero[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], port_expected_zero[i]);
 			goto fail;
 		}
 	}
@@ -1095,11 +1091,10 @@ xstats_tests(struct test *t)
 	};
 	for (i = 0; (signed int)i < ret; i++) {
 		if (queue_expected[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], queue_expected[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], queue_expected[i]);
 			goto fail;
 		}
 	}
@@ -1129,11 +1124,10 @@ xstats_tests(struct test *t)
 	int fails = 0;
 	for (i = 0; (signed int)i < ret; i++) {
 		if (queue_expected_zero[i] != values[i]) {
-			printf(
-				"%d, Error, xstat %d (id %d) %s : %"PRIu64
-				", expect %"PRIu64"\n",
-				__LINE__, i, ids[i], xstats_names[i].name,
-				values[i], queue_expected_zero[i]);
+			printf("%d, Error, xstat %d (id %" PRIu64
+			       ") %s : %" PRIu64 ", expect %" PRIu64 "\n",
+			       __LINE__, i, ids[i], xstats_names[i].name,
+			       values[i], queue_expected_zero[i]);
 			fails++;
 		}
 	}
@@ -1160,7 +1154,7 @@ xstats_id_abuse_tests(struct test *t)
 	const uint32_t XSTATS_MAX = 1024;
 	const uint32_t link_port = 2;
 
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
 
 	/* Create instance with 4 ports */
@@ -1379,7 +1373,7 @@ xstats_brute_force(struct test *t)
 {
 	uint32_t i;
 	const uint32_t XSTATS_MAX = 1024;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
 
@@ -1454,7 +1448,7 @@ xstats_id_reset_tests(struct test *t)
 #define XSTATS_MAX 1024
 	int ret;
 	uint32_t i;
-	uint32_t ids[XSTATS_MAX];
+	uint64_t ids[XSTATS_MAX];
 	uint64_t values[XSTATS_MAX];
 	struct rte_event_dev_xstats_name xstats_names[XSTATS_MAX];
 
@@ -1510,13 +1504,14 @@ xstats_id_reset_tests(struct test *t)
 	};
 	uint64_t dev_expected[] = {NPKTS, NPKTS, 0, 1, 0, 0, 4, 1};
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								dev_names[i],
 								&id);
 		if (id != i) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, dev_names[i], i, id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, dev_names[i], i, id);
 			goto fail;
 		}
 		if (val != dev_expected[i]) {
@@ -1631,20 +1626,20 @@ xstats_id_reset_tests(struct test *t)
 
 	int failed = 0;
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								port_names[i],
 								&id);
 		if (id != i + PORT_OFF) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, port_names[i], i+PORT_OFF,
-					id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, port_names[i], i + PORT_OFF, id);
 			failed = 1;
 		}
 		if (val != port_expected[i]) {
-			printf("%d: %s value incorrect, expected %"PRIu64
-				" got %d\n", __LINE__, port_names[i],
-				port_expected[i], id);
+			printf("%d: %s value incorrect, expected %" PRIu64
+			       " got %" PRIu64 "\n",
+			       __LINE__, port_names[i], port_expected[i], id);
 			failed = 1;
 		}
 		/* reset to zero */
@@ -1746,14 +1741,14 @@ xstats_id_reset_tests(struct test *t)
 
 	failed = 0;
 	for (i = 0; (int)i < ret; i++) {
-		unsigned int id;
+		uint64_t id;
 		uint64_t val = rte_event_dev_xstats_by_name_get(evdev,
 								queue_names[i],
 								&id);
 		if (id != i + QUEUE_OFF) {
-			printf("%d: %s id incorrect, expected %d got %d\n",
-					__LINE__, queue_names[i], i+QUEUE_OFF,
-					id);
+			printf("%d: %s id incorrect, expected %d got %" PRIu64
+			       "\n",
+			       __LINE__, queue_names[i], i + QUEUE_OFF, id);
 			failed = 1;
 		}
 		if (val != queue_expected[i]) {
diff --git a/drivers/event/sw/sw_evdev_xstats.c b/drivers/event/sw/sw_evdev_xstats.c
index c2647d7da2..fbac8f3ab5 100644
--- a/drivers/event/sw/sw_evdev_xstats.c
+++ b/drivers/event/sw/sw_evdev_xstats.c
@@ -393,7 +393,7 @@ int
 sw_xstats_get_names(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
 	unsigned int i;
@@ -444,7 +444,7 @@ sw_xstats_get_names(const struct rte_eventdev *dev,
 
 static int
 sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n, const uint32_t reset,
 		const uint32_t ret_if_n_lt_nstats)
 {
@@ -509,7 +509,7 @@ sw_xstats_update(struct sw_evdev *sw, enum rte_event_dev_xstats_mode mode,
 int
 sw_xstats_get(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n)
+		const uint64_t ids[], uint64_t values[], unsigned int n)
 {
 	struct sw_evdev *sw = sw_pmd_priv(dev);
 	const uint32_t reset = 0;
@@ -520,7 +520,7 @@ sw_xstats_get(const struct rte_eventdev *dev,
 
 uint64_t
 sw_xstats_get_by_name(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id)
+		const char *name, uint64_t *id)
 {
 	const struct sw_evdev *sw = sw_pmd_priv_const(dev);
 	unsigned int i;
@@ -556,7 +556,7 @@ sw_xstats_reset_range(struct sw_evdev *sw, uint32_t start, uint32_t num)
 
 static int
 sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	const uint32_t ret_n_lt_stats = 0;
@@ -577,7 +577,7 @@ sw_xstats_reset_queue(struct sw_evdev *sw, uint8_t queue_id,
 
 static int
 sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	const uint32_t reset = 1;
 	const uint32_t ret_n_lt_stats = 0;
@@ -597,12 +597,12 @@ sw_xstats_reset_port(struct sw_evdev *sw, uint8_t port_id,
 }
 
 static int
-sw_xstats_reset_dev(struct sw_evdev *sw, const uint32_t ids[], uint32_t nb_ids)
+sw_xstats_reset_dev(struct sw_evdev *sw, const uint64_t ids[], uint32_t nb_ids)
 {
 	uint32_t i;
 	if (ids) {
 		for (i = 0; i < nb_ids; i++) {
-			uint32_t id = ids[i];
+			uint64_t id = ids[i];
 			if (id >= sw->xstats_count_mode_dev)
 				return -EINVAL;
 			sw_xstats_reset_range(sw, id, 1);
@@ -619,7 +619,7 @@ int
 sw_xstats_reset(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids)
 {
 	struct sw_evdev *sw = sw_pmd_priv(dev);
diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
index e49ff23db5..aebab26852 100644
--- a/lib/eventdev/eventdev_pmd.h
+++ b/lib/eventdev/eventdev_pmd.h
@@ -529,7 +529,7 @@ typedef void (*eventdev_dump_t)(struct rte_eventdev *dev, FILE *f);
  */
 typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
-		const unsigned int ids[], uint64_t values[], unsigned int n);
+		const uint64_t ids[], uint64_t values[], unsigned int n);
 
 /**
  * Resets the statistic values in xstats for the device, based on mode.
@@ -537,7 +537,7 @@ typedef int (*eventdev_xstats_get_t)(const struct rte_eventdev *dev,
 typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode,
 		int16_t queue_port_id,
-		const uint32_t ids[],
+		const uint64_t ids[],
 		uint32_t nb_ids);
 
 /**
@@ -564,7 +564,7 @@ typedef int (*eventdev_xstats_reset_t)(struct rte_eventdev *dev,
 typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size);
+		uint64_t *ids, unsigned int size);
 
 /**
  * Get value of one stats and optionally return its id
@@ -582,7 +582,7 @@ typedef int (*eventdev_xstats_get_names_t)(const struct rte_eventdev *dev,
  *   if id pointer is non-NULL
  */
 typedef uint64_t (*eventdev_xstats_get_by_name)(const struct rte_eventdev *dev,
-		const char *name, unsigned int *id);
+		const char *name, uint64_t *id);
 
 
 /**
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 845f8dbb6e..b0414206d9 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -1161,7 +1161,7 @@ int
 rte_event_dev_xstats_names_get(uint8_t dev_id,
 		enum rte_event_dev_xstats_mode mode, uint8_t queue_port_id,
 		struct rte_event_dev_xstats_name *xstats_names,
-		unsigned int *ids, unsigned int size)
+		uint64_t *ids, unsigned int size)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
 	const int cnt_expected_entries = xstats_get_count(dev_id, mode,
@@ -1183,7 +1183,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
 /* retrieve eventdev extended statistics */
 int
 rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
-		uint8_t queue_port_id, const unsigned int ids[],
+		uint8_t queue_port_id, const uint64_t ids[],
 		uint64_t values[], unsigned int n)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
@@ -1198,11 +1198,11 @@ rte_event_dev_xstats_get(uint8_t dev_id, enum rte_event_dev_xstats_mode mode,
 
 uint64_t
 rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
-		unsigned int *id)
+		uint64_t *id)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
 	const struct rte_eventdev *dev = &rte_eventdevs[dev_id];
-	unsigned int temp = -1;
+	uint64_t temp = -1;
 
 	if (id != NULL)
 		*id = (unsigned int)-1;
@@ -1217,7 +1217,7 @@ rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
 
 int rte_event_dev_xstats_reset(uint8_t dev_id,
 		enum rte_event_dev_xstats_mode mode, int16_t queue_port_id,
-		const uint32_t ids[], uint32_t nb_ids)
+		const uint64_t ids[], uint32_t nb_ids)
 {
 	RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
 	struct rte_eventdev *dev = &rte_eventdevs[dev_id];
@@ -1658,7 +1658,7 @@ eventdev_build_telemetry_data(int dev_id,
 			      struct rte_tel_data *d)
 {
 	struct rte_event_dev_xstats_name *xstat_names;
-	unsigned int *ids;
+	uint64_t *ids;
 	uint64_t *values;
 	int i, ret, num_xstats;
 
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 60e9043ac4..82e8976e57 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1784,7 +1784,7 @@ rte_event_dev_xstats_names_get(uint8_t dev_id,
 			       enum rte_event_dev_xstats_mode mode,
 			       uint8_t queue_port_id,
 			       struct rte_event_dev_xstats_name *xstats_names,
-			       unsigned int *ids,
+			       uint64_t *ids,
 			       unsigned int size);
 
 /**
@@ -1817,7 +1817,7 @@ int
 rte_event_dev_xstats_get(uint8_t dev_id,
 			 enum rte_event_dev_xstats_mode mode,
 			 uint8_t queue_port_id,
-			 const unsigned int ids[],
+			 const uint64_t ids[],
 			 uint64_t values[], unsigned int n);
 
 /**
@@ -1838,7 +1838,7 @@ rte_event_dev_xstats_get(uint8_t dev_id,
  */
 uint64_t
 rte_event_dev_xstats_by_name_get(uint8_t dev_id, const char *name,
-				 unsigned int *id);
+				 uint64_t *id);
 
 /**
  * Reset the values of the xstats of the selected component in the device.
@@ -1864,7 +1864,7 @@ int
 rte_event_dev_xstats_reset(uint8_t dev_id,
 			   enum rte_event_dev_xstats_mode mode,
 			   int16_t queue_port_id,
-			   const uint32_t ids[],
+			   const uint64_t ids[],
 			   uint32_t nb_ids);
 
 /**
-- 
2.25.1


^ permalink raw reply	[relevance 2%]

* [PATCH] eventdev: update release notes
@ 2022-10-13  9:15 10% pbhagavatula
  2022-10-19 13:00  0% ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: pbhagavatula @ 2022-10-13  9:15 UTC (permalink / raw)
  To: jerinj; +Cc: dev, Pavan Nikhilesh

From: Pavan Nikhilesh <pbhagavatula@marvell.com>

Update release notes for changes made in eventdev library.

Fixes: 5fa63911e43b ("eventdev: replace padding type in event vector")
Fixes: 0fbb55efa542 ("eventdev: add element offset to event vector")
Fixes: d986276f9b72 ("eventdev: add prefix to public symbol")

Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
 doc/guides/rel_notes/release_22_11.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
index 2da8bc9661..800dcf2b53 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -454,6 +454,9 @@ API Changes
 
 * raw/ifgpa: The function ``rte_pmd_ifpga_get_pci_bus`` has been removed.
 
+* eventdev: The function pointer definition ``eventdev_stop_flush_t`` is
+  renamed to ``rte_eventdev_stop_flush_t`` to avoid conflicts with application
+  symbols.
 
 ABI Changes
 -----------
@@ -496,6 +499,13 @@ ABI Changes
 * eventdev: Added ``weight`` and ``affinity`` fields
   to ``rte_event_queue_conf`` structure.
 
+* eventdev: The field ``*u64s`` in the structure ``rte_event_vector`` is replaced
+  with ``u64s`` as the field is supposed to hold array of uint64_t values.
+
+* eventdev: The structure ``rte_event_vector`` was updated to include a new bit
+  field ``elem_offset:12`` the bits are taken from the bitfield ``rsvd:15``.
+  The element offset defines the offset into the vector array at
+  which valid elements start.
 
 Known Issues
 ------------
-- 
2.25.1


^ permalink raw reply	[relevance 10%]

* RE: xstats id type
  2022-10-13  7:12  3%                   ` Pavan Nikhilesh Bhagavatula
  2022-10-13  8:26  0%                     ` Thomas Monjalon
@ 2022-10-13  8:59  0%                     ` Van Haaren, Harry
  1 sibling, 0 replies; 200+ results
From: Van Haaren, Harry @ 2022-10-13  8:59 UTC (permalink / raw)
  To: Pavan Nikhilesh Bhagavatula, Morten Brørup, Thomas Monjalon,
	Jerin Jacob, Sachin Saxena, Hemant Agrawal, Ori Kam, Liron Himi
  Cc: Jerin Jacob Kollanukkaran, dev, Li, WeiyuanX, Ferruh Yigit,
	Andrew Rybchenko, david.marchand

> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
> Sent: Thursday, October 13, 2022 8:13 AM
> To: Morten Brørup <mb@smartsharesystems.com>; Thomas Monjalon
> <thomas@monjalon.net>; Jerin Jacob <jerinjacobk@gmail.com>; Sachin Saxena
> <sachin.saxena@oss.nxp.com>; Hemant Agrawal <hemant.agrawal@nxp.com>; Ori
> Kam <orika@nvidia.com>; Liron Himi <lironh@marvell.com>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; dev@dpdk.org; Li, WeiyuanX <weiyuanx.li@intel.com>;
> Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; david.marchand@redhat.com
> Subject: RE: xstats id type
> 
> 
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Thursday, October 13, 2022 12:22 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob
> > <jerinjacobk@gmail.com>; Sachin Saxena <sachin.saxena@oss.nxp.com>;
> > Hemant Agrawal <hemant.agrawal@nxp.com>; Ori Kam
> > <orika@nvidia.com>; Liron Himi <lironh@marvell.com>
> > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Jerin Jacob
> > Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Li, WeiyuanX
> > <weiyuanx.li@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Andrew
> > Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > david.marchand@redhat.com
> > Subject: [EXT] xstats id type
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > +TO: rawdev maintainers, regexdev maintainers
> >
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Wednesday, 12 October 2022 22.44
> > >
> > > 12/10/2022 18:47, Jerin Jacob:
> > > > On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon
> > <thomas@monjalon.net>
> > > wrote:
> > > > >
> > > > > 12/10/2022 18:16, Jerin Jacob:
> > > > > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup
> > > <mb@smartsharesystems.com> wrote:
> > > > > > >
> > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > > > > >
> > > > > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > From: Van Haaren, Harry
> > > [mailto:harry.van.haaren@intel.com]
> > > > > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > > > > >
> > > > > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > > > > drivers/event/sw.
> > > > > > > > > > >
> > > > > > > > > > > Thanks Jerin.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > While looking into bug #1101 [1], I noticed a mix
> > > of unsigned
> > > > > > > > int
> > > > > > > > > > > and uint32_t in
> > > > > > > > > > > > the test code, which will fail on 64-bit big endian
> > > CPUs.
> > > > > > > > > > >
> > > > > > > > > > > Aha; that we can fix. I am curious why this isn't found
> > > in
> > > > > > > > CI/reported
> > > > > > > > > > > before.
> > > > > > > > > >
> > > > > > > > > > We probably don't test any 64-bit *big endian*
> > > architectures. Just
> > > > > > > > a guess.
> > > > > > > > >
> > > > > > > > > Seems so yes.
> > > > > > > > >
> > > > > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is
> > > called with the
> > > > > > > > "ids"
> > > > > > > > > > > parameter
> > > > > > > > > > > > pointing to an unsigned int [2], but that parameter
> > > is a
> > > > > > > > pointer to
> > > > > > > > > > > an uint32_t.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > > > > >
> > > > > > > > > > > In this case, we have the option to change the type of
> > > a variable
> > > > > > > > in a
> > > > > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > > > > >
> > > > > > > > > > Well.. yes, but I would phrase that last option: Change
> > > the
> > > > > > > > API/ABI, so related
> > > > > > > > > > functions consistently use the same type for the same
> > > variable,
> > > > > > > > instead of randomly
> > > > > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on
> > > function.
> > > > > > > > >
> > > > > > > > > Aah ok; I see your point now; there is inconsistent usage
> > > of
> > > > > > > > uint32_t/unsigned int
> > > > > > > > > between the Eventdev APIs itself. Agree this is sub-
> > > optimal, and
> > > > > > > > would have been
> > > > > > > > > nice to have spotted before the Eventdev API was
> > > stabilized.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Unfortunately, these functions are not marked
> > > experimental, so
> > > > > > > > breaking API/ABI is
> > > > > > > > > > hard to do. :-(
> > > > > > > > >
> > > > > > > > > Agreed again.
> > > > > > > >
> > > > > > > > 22.11 is a breaking release,
> > > > > > > > and changing type in the API is not much impactful,
> > > > > > > > so that's something you can change now,
> > > > > > > > or be quiet forever :)
> > > > > > >
> > > > > > > Question:
> > > > > > > 1. Only change the "xstats id" type in the one eventdev
> > > function, which deviates from other eventdev functions, or
> > > > > > > 2. Change the "xstats id" type for all xstats functions across
> > > all device types, for consistency across device types?
> > > > > > >
> > > > > > > If 2, then what would be a good type?
> > > > > >
> > > > > > +1 for second option and the type as uint32_t
> > > > > >
> > > > > > >
> > > > > > > Ethdev uses uint64_t for xstats id, and (speaking without
> > > knowledge about its internals) that seems like overkill to me. Arrays
> > > of these are being used, so size does matter.
> > > > >
> > > > > uint64_t is not overkill if you consider having stats per queue
> > > with a predictable scheme.
> > > > > That's an improvement I would like to work on,
> > > >
> > > > You mean to use a bitmask hence uint64_t.
> > > > Currently it is mapped as arrays so 2^64 stats may not be needed.
> > > >
> > > > No strong opinion, I was just curious to understand "stats per queue
> > > > with a predictable scheme" and how uint64_t helps with  that.
> > >
> > > Yes I mean some bits are used for the queue number.
> > > Something like in slide 11 of this presentation:
> > > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__fast.dpdk.org_events_slides_DPDK-2D2019-2D09-2DEthernet-
> > 5FStatistics.pdf&d=DwIFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh74
> > 5jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=ApdcbroZzSNlcY1t4c8iv9HZk6YSJOA
> > Hpg93zuyIEEWa6xkViBTdoCA3iir_FCtW&s=wEMA0lnyrTmxmmDINhzOagGvV
> > Z3TcIrzfK5NbJHafdM&e=
> >
> > With this presentation in mind, I strongly agree with Thomas that uint64_t is
> > the best choice of type for xstats id.
> >
> > A quick search shows that both eventdev and rawdev use "unsigned int",
> > except rte_event_dev_xstats_reset() and rte_rawdev_xstats_reset(), which
> > both use uint32_t. And regexdev uses uint16_t. Other device APIs don't have
> > xstats.
> 
> Harry,
> Are you working on a patch for this change? If not I will do it.

Please go ahead - I won't find time in the short term. Thanks Pavan.

> Thomas,
> Are you ok to break the ABI without deprication notice i.e. make ID as u64 for
> eventdev?
> 
> Thanks,
> Pavan.


^ permalink raw reply	[relevance 0%]

* RE: [EXT] Re: xstats id type
  2022-10-13  8:26  0%                     ` Thomas Monjalon
@ 2022-10-13  8:33  0%                       ` Pavan Nikhilesh Bhagavatula
  0 siblings, 0 replies; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2022-10-13  8:33 UTC (permalink / raw)
  To: Thomas Monjalon, Morten Brørup, Jerin Jacob, Sachin Saxena,
	Hemant Agrawal, Ori Kam, Liron Himi
  Cc: Van Haaren, Harry, Jerin Jacob Kollanukkaran, dev, Li, WeiyuanX,
	Ferruh Yigit, Andrew Rybchenko, david.marchand, techboard



> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, October 13, 2022 1:57 PM
> To: Morten Brørup <mb@smartsharesystems.com>; Jerin Jacob
> <jerinjacobk@gmail.com>; Sachin Saxena <sachin.saxena@oss.nxp.com>;
> Hemant Agrawal <hemant.agrawal@nxp.com>; Ori Kam
> <orika@nvidia.com>; Liron Himi <lironh@marvell.com>; Pavan Nikhilesh
> Bhagavatula <pbhagavatula@marvell.com>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Li, WeiyuanX
> <weiyuanx.li@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> david.marchand@redhat.com; techboard@dpdk.org
> Subject: [EXT] Re: xstats id type
> 
> External Email
> 
> ----------------------------------------------------------------------
> 13/10/2022 09:12, Pavan Nikhilesh Bhagavatula:
> > From: Morten Brørup <mb@smartsharesystems.com>
> > > +TO: rawdev maintainers, regexdev maintainers
> > >
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Wednesday, 12 October 2022 22.44
> > > >
> > > > 12/10/2022 18:47, Jerin Jacob:
> > > > > On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon
> > > <thomas@monjalon.net>
> > > > wrote:
> > > > > >
> > > > > > 12/10/2022 18:16, Jerin Jacob:
> > > > > > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup
> > > > <mb@smartsharesystems.com> wrote:
> > > > > > > >
> > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > > > > > >
> > > > > > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > > From: Van Haaren, Harry
> > > > [mailto:harry.van.haaren@intel.com]
> > > > > > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > > > > > >
> > > > > > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > > > > > drivers/event/sw.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks Jerin.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > While looking into bug #1101 [1], I noticed a mix
> > > > of unsigned
> > > > > > > > > int
> > > > > > > > > > > > and uint32_t in
> > > > > > > > > > > > > the test code, which will fail on 64-bit big endian
> > > > CPUs.
> > > > > > > > > > > >
> > > > > > > > > > > > Aha; that we can fix. I am curious why this isn't found
> > > > in
> > > > > > > > > CI/reported
> > > > > > > > > > > > before.
> > > > > > > > > > >
> > > > > > > > > > > We probably don't test any 64-bit *big endian*
> > > > architectures. Just
> > > > > > > > > a guess.
> > > > > > > > > >
> > > > > > > > > > Seems so yes.
> > > > > > > > > >
> > > > > > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is
> > > > called with the
> > > > > > > > > "ids"
> > > > > > > > > > > > parameter
> > > > > > > > > > > > > pointing to an unsigned int [2], but that parameter
> > > > is a
> > > > > > > > > pointer to
> > > > > > > > > > > > an uint32_t.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > > > > > >
> > > > > > > > > > > > In this case, we have the option to change the type of
> > > > a variable
> > > > > > > > > in a
> > > > > > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > > > > > >
> > > > > > > > > > > Well.. yes, but I would phrase that last option: Change
> > > > the
> > > > > > > > > API/ABI, so related
> > > > > > > > > > > functions consistently use the same type for the same
> > > > variable,
> > > > > > > > > instead of randomly
> > > > > > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on
> > > > function.
> > > > > > > > > >
> > > > > > > > > > Aah ok; I see your point now; there is inconsistent usage
> > > > of
> > > > > > > > > uint32_t/unsigned int
> > > > > > > > > > between the Eventdev APIs itself. Agree this is sub-
> > > > optimal, and
> > > > > > > > > would have been
> > > > > > > > > > nice to have spotted before the Eventdev API was
> > > > stabilized.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Unfortunately, these functions are not marked
> > > > experimental, so
> > > > > > > > > breaking API/ABI is
> > > > > > > > > > > hard to do. :-(
> > > > > > > > > >
> > > > > > > > > > Agreed again.
> > > > > > > > >
> > > > > > > > > 22.11 is a breaking release,
> > > > > > > > > and changing type in the API is not much impactful,
> > > > > > > > > so that's something you can change now,
> > > > > > > > > or be quiet forever :)
> > > > > > > >
> > > > > > > > Question:
> > > > > > > > 1. Only change the "xstats id" type in the one eventdev
> > > > function, which deviates from other eventdev functions, or
> > > > > > > > 2. Change the "xstats id" type for all xstats functions across
> > > > all device types, for consistency across device types?
> > > > > > > >
> > > > > > > > If 2, then what would be a good type?
> > > > > > >
> > > > > > > +1 for second option and the type as uint32_t
> > > > > > >
> > > > > > > >
> > > > > > > > Ethdev uses uint64_t for xstats id, and (speaking without
> > > > knowledge about its internals) that seems like overkill to me. Arrays
> > > > of these are being used, so size does matter.
> > > > > >
> > > > > > uint64_t is not overkill if you consider having stats per queue
> > > > with a predictable scheme.
> > > > > > That's an improvement I would like to work on,
> > > > >
> > > > > You mean to use a bitmask hence uint64_t.
> > > > > Currently it is mapped as arrays so 2^64 stats may not be needed.
> > > > >
> > > > > No strong opinion, I was just curious to understand "stats per queue
> > > > > with a predictable scheme" and how uint64_t helps with  that.
> > > >
> > > > Yes I mean some bits are used for the queue number.
> > > > Something like in slide 11 of this presentation:
> > > > https://urldefense.proofpoint.com/v2/url?u=http-
> > > 3A__fast.dpdk.org_events_slides_DPDK-2D2019-2D09-2DEthernet-
> > >
> 5FStatistics.pdf&d=DwIFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh74
> > >
> 5jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=ApdcbroZzSNlcY1t4c8iv9HZk6YSJOA
> > >
> Hpg93zuyIEEWa6xkViBTdoCA3iir_FCtW&s=wEMA0lnyrTmxmmDINhzOagGvV
> > > Z3TcIrzfK5NbJHafdM&e=
> > >
> > > With this presentation in mind, I strongly agree with Thomas that uint64_t
> is
> > > the best choice of type for xstats id.
> > >
> > > A quick search shows that both eventdev and rawdev use "unsigned int",
> > > except rte_event_dev_xstats_reset() and rte_rawdev_xstats_reset(),
> which
> > > both use uint32_t. And regexdev uses uint16_t. Other device APIs don't
> have
> > > xstats.
> >
> > Harry,
> > Are you working on a patch for this change? If not I will do it.
> >
> > Thomas,
> > Are you ok to break the ABI without deprication notice i.e. make ID as u64
> for eventdev?
> 
> Yes, it is only increasing size of function parameters, right?

Yes

> The only problematic part is that the application must pass
> a pointer of the right size, meaning some application code change.

Most likely they'll get a -Wincompatible-pointer-types not the end of the world.

> 
> It would be an exception in the process,
> so I am Cc'ing the techboard for more opinions.
> 


^ permalink raw reply	[relevance 0%]

* Re: xstats id type
  2022-10-13  7:12  3%                   ` Pavan Nikhilesh Bhagavatula
@ 2022-10-13  8:26  0%                     ` Thomas Monjalon
  2022-10-13  8:33  0%                       ` [EXT] " Pavan Nikhilesh Bhagavatula
  2022-10-13  8:59  0%                     ` Van Haaren, Harry
  1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-10-13  8:26 UTC (permalink / raw)
  To: Morten Brørup, Jerin Jacob, Sachin Saxena, Hemant Agrawal,
	Ori Kam, Liron Himi, Pavan Nikhilesh Bhagavatula
  Cc: Van Haaren, Harry, Jerin Jacob Kollanukkaran, dev, Li, WeiyuanX,
	Ferruh Yigit, Andrew Rybchenko, david.marchand, techboard

13/10/2022 09:12, Pavan Nikhilesh Bhagavatula:
> From: Morten Brørup <mb@smartsharesystems.com>
> > +TO: rawdev maintainers, regexdev maintainers
> > 
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Wednesday, 12 October 2022 22.44
> > >
> > > 12/10/2022 18:47, Jerin Jacob:
> > > > On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon
> > <thomas@monjalon.net>
> > > wrote:
> > > > >
> > > > > 12/10/2022 18:16, Jerin Jacob:
> > > > > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup
> > > <mb@smartsharesystems.com> wrote:
> > > > > > >
> > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > > > > >
> > > > > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > From: Van Haaren, Harry
> > > [mailto:harry.van.haaren@intel.com]
> > > > > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > > > > >
> > > > > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > > > > drivers/event/sw.
> > > > > > > > > > >
> > > > > > > > > > > Thanks Jerin.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > While looking into bug #1101 [1], I noticed a mix
> > > of unsigned
> > > > > > > > int
> > > > > > > > > > > and uint32_t in
> > > > > > > > > > > > the test code, which will fail on 64-bit big endian
> > > CPUs.
> > > > > > > > > > >
> > > > > > > > > > > Aha; that we can fix. I am curious why this isn't found
> > > in
> > > > > > > > CI/reported
> > > > > > > > > > > before.
> > > > > > > > > >
> > > > > > > > > > We probably don't test any 64-bit *big endian*
> > > architectures. Just
> > > > > > > > a guess.
> > > > > > > > >
> > > > > > > > > Seems so yes.
> > > > > > > > >
> > > > > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is
> > > called with the
> > > > > > > > "ids"
> > > > > > > > > > > parameter
> > > > > > > > > > > > pointing to an unsigned int [2], but that parameter
> > > is a
> > > > > > > > pointer to
> > > > > > > > > > > an uint32_t.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > > > > >
> > > > > > > > > > > In this case, we have the option to change the type of
> > > a variable
> > > > > > > > in a
> > > > > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > > > > >
> > > > > > > > > > Well.. yes, but I would phrase that last option: Change
> > > the
> > > > > > > > API/ABI, so related
> > > > > > > > > > functions consistently use the same type for the same
> > > variable,
> > > > > > > > instead of randomly
> > > > > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on
> > > function.
> > > > > > > > >
> > > > > > > > > Aah ok; I see your point now; there is inconsistent usage
> > > of
> > > > > > > > uint32_t/unsigned int
> > > > > > > > > between the Eventdev APIs itself. Agree this is sub-
> > > optimal, and
> > > > > > > > would have been
> > > > > > > > > nice to have spotted before the Eventdev API was
> > > stabilized.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Unfortunately, these functions are not marked
> > > experimental, so
> > > > > > > > breaking API/ABI is
> > > > > > > > > > hard to do. :-(
> > > > > > > > >
> > > > > > > > > Agreed again.
> > > > > > > >
> > > > > > > > 22.11 is a breaking release,
> > > > > > > > and changing type in the API is not much impactful,
> > > > > > > > so that's something you can change now,
> > > > > > > > or be quiet forever :)
> > > > > > >
> > > > > > > Question:
> > > > > > > 1. Only change the "xstats id" type in the one eventdev
> > > function, which deviates from other eventdev functions, or
> > > > > > > 2. Change the "xstats id" type for all xstats functions across
> > > all device types, for consistency across device types?
> > > > > > >
> > > > > > > If 2, then what would be a good type?
> > > > > >
> > > > > > +1 for second option and the type as uint32_t
> > > > > >
> > > > > > >
> > > > > > > Ethdev uses uint64_t for xstats id, and (speaking without
> > > knowledge about its internals) that seems like overkill to me. Arrays
> > > of these are being used, so size does matter.
> > > > >
> > > > > uint64_t is not overkill if you consider having stats per queue
> > > with a predictable scheme.
> > > > > That's an improvement I would like to work on,
> > > >
> > > > You mean to use a bitmask hence uint64_t.
> > > > Currently it is mapped as arrays so 2^64 stats may not be needed.
> > > >
> > > > No strong opinion, I was just curious to understand "stats per queue
> > > > with a predictable scheme" and how uint64_t helps with  that.
> > >
> > > Yes I mean some bits are used for the queue number.
> > > Something like in slide 11 of this presentation:
> > > https://urldefense.proofpoint.com/v2/url?u=http-
> > 3A__fast.dpdk.org_events_slides_DPDK-2D2019-2D09-2DEthernet-
> > 5FStatistics.pdf&d=DwIFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh74
> > 5jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=ApdcbroZzSNlcY1t4c8iv9HZk6YSJOA
> > Hpg93zuyIEEWa6xkViBTdoCA3iir_FCtW&s=wEMA0lnyrTmxmmDINhzOagGvV
> > Z3TcIrzfK5NbJHafdM&e=
> > 
> > With this presentation in mind, I strongly agree with Thomas that uint64_t is
> > the best choice of type for xstats id.
> > 
> > A quick search shows that both eventdev and rawdev use "unsigned int",
> > except rte_event_dev_xstats_reset() and rte_rawdev_xstats_reset(), which
> > both use uint32_t. And regexdev uses uint16_t. Other device APIs don't have
> > xstats.
> 
> Harry, 
> Are you working on a patch for this change? If not I will do it.
> 
> Thomas,
> Are you ok to break the ABI without deprication notice i.e. make ID as u64 for eventdev?

Yes, it is only increasing size of function parameters, right?
The only problematic part is that the application must pass
a pointer of the right size, meaning some application code change.

It would be an exception in the process,
so I am Cc'ing the techboard for more opinions.



^ permalink raw reply	[relevance 0%]

* RE: xstats id type
  2022-10-13  6:51  0%                 ` xstats " Morten Brørup
@ 2022-10-13  7:12  3%                   ` Pavan Nikhilesh Bhagavatula
  2022-10-13  8:26  0%                     ` Thomas Monjalon
  2022-10-13  8:59  0%                     ` Van Haaren, Harry
  0 siblings, 2 replies; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2022-10-13  7:12 UTC (permalink / raw)
  To: Morten Brørup, Thomas Monjalon, Jerin Jacob, Sachin Saxena,
	Hemant Agrawal, Ori Kam, Liron Himi
  Cc: Van Haaren, Harry, Jerin Jacob Kollanukkaran, dev, Li, WeiyuanX,
	Ferruh Yigit, Andrew Rybchenko, david.marchand



> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Thursday, October 13, 2022 12:22 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob
> <jerinjacobk@gmail.com>; Sachin Saxena <sachin.saxena@oss.nxp.com>;
> Hemant Agrawal <hemant.agrawal@nxp.com>; Ori Kam
> <orika@nvidia.com>; Liron Himi <lironh@marvell.com>
> Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org; Li, WeiyuanX
> <weiyuanx.li@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> david.marchand@redhat.com
> Subject: [EXT] xstats id type
> 
> External Email
> 
> ----------------------------------------------------------------------
> +TO: rawdev maintainers, regexdev maintainers
> 
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Wednesday, 12 October 2022 22.44
> >
> > 12/10/2022 18:47, Jerin Jacob:
> > > On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon
> <thomas@monjalon.net>
> > wrote:
> > > >
> > > > 12/10/2022 18:16, Jerin Jacob:
> > > > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup
> > <mb@smartsharesystems.com> wrote:
> > > > > >
> > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > > > >
> > > > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > From: Van Haaren, Harry
> > [mailto:harry.van.haaren@intel.com]
> > > > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > > > >
> > > > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > > > drivers/event/sw.
> > > > > > > > > >
> > > > > > > > > > Thanks Jerin.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > While looking into bug #1101 [1], I noticed a mix
> > of unsigned
> > > > > > > int
> > > > > > > > > > and uint32_t in
> > > > > > > > > > > the test code, which will fail on 64-bit big endian
> > CPUs.
> > > > > > > > > >
> > > > > > > > > > Aha; that we can fix. I am curious why this isn't found
> > in
> > > > > > > CI/reported
> > > > > > > > > > before.
> > > > > > > > >
> > > > > > > > > We probably don't test any 64-bit *big endian*
> > architectures. Just
> > > > > > > a guess.
> > > > > > > >
> > > > > > > > Seems so yes.
> > > > > > > >
> > > > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is
> > called with the
> > > > > > > "ids"
> > > > > > > > > > parameter
> > > > > > > > > > > pointing to an unsigned int [2], but that parameter
> > is a
> > > > > > > pointer to
> > > > > > > > > > an uint32_t.
> > > > > > > > > > > >
> > > > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > > > >
> > > > > > > > > > In this case, we have the option to change the type of
> > a variable
> > > > > > > in a
> > > > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > > > >
> > > > > > > > > Well.. yes, but I would phrase that last option: Change
> > the
> > > > > > > API/ABI, so related
> > > > > > > > > functions consistently use the same type for the same
> > variable,
> > > > > > > instead of randomly
> > > > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on
> > function.
> > > > > > > >
> > > > > > > > Aah ok; I see your point now; there is inconsistent usage
> > of
> > > > > > > uint32_t/unsigned int
> > > > > > > > between the Eventdev APIs itself. Agree this is sub-
> > optimal, and
> > > > > > > would have been
> > > > > > > > nice to have spotted before the Eventdev API was
> > stabilized.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Unfortunately, these functions are not marked
> > experimental, so
> > > > > > > breaking API/ABI is
> > > > > > > > > hard to do. :-(
> > > > > > > >
> > > > > > > > Agreed again.
> > > > > > >
> > > > > > > 22.11 is a breaking release,
> > > > > > > and changing type in the API is not much impactful,
> > > > > > > so that's something you can change now,
> > > > > > > or be quiet forever :)
> > > > > >
> > > > > > Question:
> > > > > > 1. Only change the "xstats id" type in the one eventdev
> > function, which deviates from other eventdev functions, or
> > > > > > 2. Change the "xstats id" type for all xstats functions across
> > all device types, for consistency across device types?
> > > > > >
> > > > > > If 2, then what would be a good type?
> > > > >
> > > > > +1 for second option and the type as uint32_t
> > > > >
> > > > > >
> > > > > > Ethdev uses uint64_t for xstats id, and (speaking without
> > knowledge about its internals) that seems like overkill to me. Arrays
> > of these are being used, so size does matter.
> > > >
> > > > uint64_t is not overkill if you consider having stats per queue
> > with a predictable scheme.
> > > > That's an improvement I would like to work on,
> > >
> > > You mean to use a bitmask hence uint64_t.
> > > Currently it is mapped as arrays so 2^64 stats may not be needed.
> > >
> > > No strong opinion, I was just curious to understand "stats per queue
> > > with a predictable scheme" and how uint64_t helps with  that.
> >
> > Yes I mean some bits are used for the queue number.
> > Something like in slide 11 of this presentation:
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__fast.dpdk.org_events_slides_DPDK-2D2019-2D09-2DEthernet-
> 5FStatistics.pdf&d=DwIFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=1cjuAHrGh74
> 5jHNmj2fD85sUMIJ2IPIDsIJzo6FN6Z0&m=ApdcbroZzSNlcY1t4c8iv9HZk6YSJOA
> Hpg93zuyIEEWa6xkViBTdoCA3iir_FCtW&s=wEMA0lnyrTmxmmDINhzOagGvV
> Z3TcIrzfK5NbJHafdM&e=
> 
> With this presentation in mind, I strongly agree with Thomas that uint64_t is
> the best choice of type for xstats id.
> 
> A quick search shows that both eventdev and rawdev use "unsigned int",
> except rte_event_dev_xstats_reset() and rte_rawdev_xstats_reset(), which
> both use uint32_t. And regexdev uses uint16_t. Other device APIs don't have
> xstats.

Harry, 
Are you working on a patch for this change? If not I will do it.

Thomas,
Are you ok to break the ABI without deprication notice i.e. make ID as u64 for eventdev?

Thanks,
Pavan.


^ permalink raw reply	[relevance 3%]

* xstats id type
  2022-10-12 20:44  0%               ` Thomas Monjalon
@ 2022-10-13  6:51  0%                 ` Morten Brørup
  2022-10-13  7:12  3%                   ` Pavan Nikhilesh Bhagavatula
  0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-10-13  6:51 UTC (permalink / raw)
  To: Thomas Monjalon, Jerin Jacob, Sachin Saxena, Hemant Agrawal,
	Ori Kam, Liron Himi
  Cc: Van Haaren, Harry, Jerin Jacob, dev, Li, WeiyuanX, Ferruh Yigit,
	Andrew Rybchenko, david.marchand

+TO: rawdev maintainers, regexdev maintainers

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, 12 October 2022 22.44
> 
> 12/10/2022 18:47, Jerin Jacob:
> > On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> > >
> > > 12/10/2022 18:16, Jerin Jacob:
> > > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup
> <mb@smartsharesystems.com> wrote:
> > > > >
> > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > > >
> > > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > From: Van Haaren, Harry
> [mailto:harry.van.haaren@intel.com]
> > > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > > >
> > > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > > drivers/event/sw.
> > > > > > > > >
> > > > > > > > > Thanks Jerin.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > While looking into bug #1101 [1], I noticed a mix
> of unsigned
> > > > > > int
> > > > > > > > > and uint32_t in
> > > > > > > > > > the test code, which will fail on 64-bit big endian
> CPUs.
> > > > > > > > >
> > > > > > > > > Aha; that we can fix. I am curious why this isn't found
> in
> > > > > > CI/reported
> > > > > > > > > before.
> > > > > > > >
> > > > > > > > We probably don't test any 64-bit *big endian*
> architectures. Just
> > > > > > a guess.
> > > > > > >
> > > > > > > Seems so yes.
> > > > > > >
> > > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is
> called with the
> > > > > > "ids"
> > > > > > > > > parameter
> > > > > > > > > > pointing to an unsigned int [2], but that parameter
> is a
> > > > > > pointer to
> > > > > > > > > an uint32_t.
> > > > > > > > > > >
> > > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > > >
> > > > > > > > > In this case, we have the option to change the type of
> a variable
> > > > > > in a
> > > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > > >
> > > > > > > > Well.. yes, but I would phrase that last option: Change
> the
> > > > > > API/ABI, so related
> > > > > > > > functions consistently use the same type for the same
> variable,
> > > > > > instead of randomly
> > > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on
> function.
> > > > > > >
> > > > > > > Aah ok; I see your point now; there is inconsistent usage
> of
> > > > > > uint32_t/unsigned int
> > > > > > > between the Eventdev APIs itself. Agree this is sub-
> optimal, and
> > > > > > would have been
> > > > > > > nice to have spotted before the Eventdev API was
> stabilized.
> > > > > > >
> > > > > > >
> > > > > > > > Unfortunately, these functions are not marked
> experimental, so
> > > > > > breaking API/ABI is
> > > > > > > > hard to do. :-(
> > > > > > >
> > > > > > > Agreed again.
> > > > > >
> > > > > > 22.11 is a breaking release,
> > > > > > and changing type in the API is not much impactful,
> > > > > > so that's something you can change now,
> > > > > > or be quiet forever :)
> > > > >
> > > > > Question:
> > > > > 1. Only change the "xstats id" type in the one eventdev
> function, which deviates from other eventdev functions, or
> > > > > 2. Change the "xstats id" type for all xstats functions across
> all device types, for consistency across device types?
> > > > >
> > > > > If 2, then what would be a good type?
> > > >
> > > > +1 for second option and the type as uint32_t
> > > >
> > > > >
> > > > > Ethdev uses uint64_t for xstats id, and (speaking without
> knowledge about its internals) that seems like overkill to me. Arrays
> of these are being used, so size does matter.
> > >
> > > uint64_t is not overkill if you consider having stats per queue
> with a predictable scheme.
> > > That's an improvement I would like to work on,
> >
> > You mean to use a bitmask hence uint64_t.
> > Currently it is mapped as arrays so 2^64 stats may not be needed.
> >
> > No strong opinion, I was just curious to understand "stats per queue
> > with a predictable scheme" and how uint64_t helps with  that.
> 
> Yes I mean some bits are used for the queue number.
> Something like in slide 11 of this presentation:
> http://fast.dpdk.org/events/slides/DPDK-2019-09-Ethernet_Statistics.pdf

With this presentation in mind, I strongly agree with Thomas that uint64_t is the best choice of type for xstats id.

A quick search shows that both eventdev and rawdev use "unsigned int", except rte_event_dev_xstats_reset() and rte_rawdev_xstats_reset(), which both use uint32_t. And regexdev uses uint16_t. Other device APIs don't have xstats.


^ permalink raw reply	[relevance 0%]

* RE: release candidate 22.11-rc1
  @ 2022-10-13  5:28  0% ` Jiang, YuX
  2022-10-20  5:24  0%   ` Jiang, YuX
  2022-10-24 13:12  0% ` David Marchand
  2022-10-27 21:00  0% ` Thinh Tran
  2 siblings, 1 reply; 200+ results
From: Jiang, YuX @ 2022-10-13  5:28 UTC (permalink / raw)
  To: Thomas Monjalon, dev
  Cc: Devlin, Michelle, Mcnamara, John, Chen, Zhaoyan, Peng, Yuan

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, October 11, 2022 9:50 AM
> To: announce@dpdk.org
> Subject: release candidate 22.11-rc1
> 
> A new DPDK release candidate is ready for testing:
> 	https://git.dpdk.org/dpdk/tag/?id=v22.11-rc1
> 
> There are 737 new patches in this snapshot, including many API/ABI
> compatibility breakages.
> This release won't be ABI-compatible with previous ones.
> 
> Release notes:
> 	https://doc.dpdk.org/guides/rel_notes/release_22_11.html
> 
> Highlights of 22.11-rc1:
> 	- LoongArch build
> 	- Intel uncore frequency control
> 	- multiple mbuf pools per Rx queue
> 	- Rx buffer split based on protocol
> 	- hardware congestion management
> 	- hairpin memory configuration
> 	- Rx/Tx descriptor dump
> 	- flow API extensions
> 	- MACsec processing offload
> 	- ShangMi crypto algorithms
> 	- baseband FFT operations
> 	- eventdev Tx queue start/stop
> 	- eventdev crypto vectorization
> 	- NitroSketch membership
> 
> Some work is in progress to optimize the mempool cache.
> Some patches are part of -rc1, and more could be merged in -rc2.
> Please measure the performance of this release candidate, and check these
> mempool patches:
> 	https://patches.dpdk.org/project/dpdk/list/?series=25063
> 
> Please test and report issues on bugs.dpdk.org.
> 
> DPDK 22.11-rc2 is expected in two weeks.
> 
> Thank you everyone
> 
Update the test status for Intel part. Till now dpdk22.11-rc1 test execution rate is 60%. Two critical issues are found. 
1, [22.11-rc1]iavf macfwd performance drop 40%, Intel dev is under investigating.
2, dpdk_vm_power_manger failed to start and coredumps:
  Fix patch: https://patches.dpdk.org/project/dpdk/patch/20221012123637.51640-1-markus.theil@tu-ilmenau.de/. but not verify yet.
# Basic Intel(R) NIC testing
* Build or compile:  
 *Build: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu20.04.5, Ubuntu22.04.1, Fedora36, RHEL8.6 etc.
  - All test passed.
 *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu22.04.1 and RHEL8.6.
  - All test passed.
* PF/VF(i40e, ixgbe): test scenarios including PF/VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. 
	- Execution rate is 80%. 
	- New bug: https://bugs.dpdk.org/show_bug.cgi?id=1101 [dpdk-22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed
		Bad commit is a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0 mempool: fix get objects from mempool with cache  
* PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
	- Execution rate is 80%. Find 5 new issues, Intel dev is under investigating.		
* Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, RFC2544 Zero packet loss performance test, etc.
	- Execution rate is 80%. Find one critical issue: [22.11-rc1]iavf macfwd performance drop 40%, Intel dev is under investigating.
* Power and IPsec: 
 * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc. 
	- Under testing. One critical issue is found: dpdk_vm_power_manger failed to start and coredumps.
 * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc.
	- Execution rate is 40%. Find one issue, Intel dev is under investigating.
# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u3, etc.
	- Execution rate is 80%. No new issue is found. 
	- Known issue's fix patch: http://patches.dpdk.org/project/dpdk/patch/20221011030803.16746-3-cheng1.jiang@intel.com/.
* Cryptodev: 
 *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
	- Under testing. Find one bug about FIPS tests are failing, Intel dev is under investigating.
 *Performance test: test scenarios including Throughput Performance /Cryptodev Latency, etc.
	- Under testing.

Best regards,
Yu Jiang

^ permalink raw reply	[relevance 0%]

* Re: rte_event_dev_xstats_reset id type
  2022-10-12 16:47  0%             ` Jerin Jacob
@ 2022-10-12 20:44  0%               ` Thomas Monjalon
  2022-10-13  6:51  0%                 ` xstats " Morten Brørup
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-10-12 20:44 UTC (permalink / raw)
  To: Jerin Jacob
  Cc: Morten Brørup, Van Haaren, Harry, Jerin Jacob, dev, Li,
	WeiyuanX, Ferruh Yigit, Andrew Rybchenko, david.marchand

12/10/2022 18:47, Jerin Jacob:
> On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 12/10/2022 18:16, Jerin Jacob:
> > > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > > >
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > Sent: Wednesday, 12 October 2022 17.13
> > > > >
> > > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > > >
> > > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > > drivers/event/sw.
> > > > > > > >
> > > > > > > > Thanks Jerin.
> > > > > > > >
> > > > > > > >
> > > > > > > > > > While looking into bug #1101 [1], I noticed a mix of unsigned
> > > > > int
> > > > > > > > and uint32_t in
> > > > > > > > > the test code, which will fail on 64-bit big endian CPUs.
> > > > > > > >
> > > > > > > > Aha; that we can fix. I am curious why this isn't found in
> > > > > CI/reported
> > > > > > > > before.
> > > > > > >
> > > > > > > We probably don't test any 64-bit *big endian* architectures. Just
> > > > > a guess.
> > > > > >
> > > > > > Seems so yes.
> > > > > >
> > > > > > > > > > Specifically, rte_event_dev_xstats_reset() is called with the
> > > > > "ids"
> > > > > > > > parameter
> > > > > > > > > pointing to an unsigned int [2], but that parameter is a
> > > > > pointer to
> > > > > > > > an uint32_t.
> > > > > > > > > >
> > > > > > > > > > I think the type of the ids array parameter to
> > > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > > rte_event_dev_xxx() functions.
> > > > > > > >
> > > > > > > > In this case, we have the option to change the type of a variable
> > > > > in a
> > > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > > >
> > > > > > > Well.. yes, but I would phrase that last option: Change the
> > > > > API/ABI, so related
> > > > > > > functions consistently use the same type for the same variable,
> > > > > instead of randomly
> > > > > > > mixing uint64_t, uint32_t and unsigned int, depending on function.
> > > > > >
> > > > > > Aah ok; I see your point now; there is inconsistent usage of
> > > > > uint32_t/unsigned int
> > > > > > between the Eventdev APIs itself. Agree this is sub-optimal, and
> > > > > would have been
> > > > > > nice to have spotted before the Eventdev API was stabilized.
> > > > > >
> > > > > >
> > > > > > > Unfortunately, these functions are not marked experimental, so
> > > > > breaking API/ABI is
> > > > > > > hard to do. :-(
> > > > > >
> > > > > > Agreed again.
> > > > >
> > > > > 22.11 is a breaking release,
> > > > > and changing type in the API is not much impactful,
> > > > > so that's something you can change now,
> > > > > or be quiet forever :)
> > > >
> > > > Question:
> > > > 1. Only change the "xstats id" type in the one eventdev function, which deviates from other eventdev functions, or
> > > > 2. Change the "xstats id" type for all xstats functions across all device types, for consistency across device types?
> > > >
> > > > If 2, then what would be a good type?
> > >
> > > +1 for second option and the type as uint32_t
> > >
> > > >
> > > > Ethdev uses uint64_t for xstats id, and (speaking without knowledge about its internals) that seems like overkill to me. Arrays of these are being used, so size does matter.
> >
> > uint64_t is not overkill if you consider having stats per queue with a predictable scheme.
> > That's an improvement I would like to work on,
> 
> You mean to use a bitmask hence uint64_t.
> Currently it is mapped as arrays so 2^64 stats may not be needed.
> 
> No strong opinion, I was just curious to understand "stats per queue
> with a predictable scheme" and how uint64_t helps with  that.

Yes I mean some bits are used for the queue number.
Something like in slide 11 of this presentation:
http://fast.dpdk.org/events/slides/DPDK-2019-09-Ethernet_Statistics.pdf



^ permalink raw reply	[relevance 0%]

* Re: rte_event_dev_xstats_reset id type
  2022-10-12 16:28  0%           ` Thomas Monjalon
@ 2022-10-12 16:47  0%             ` Jerin Jacob
  2022-10-12 20:44  0%               ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-10-12 16:47 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Morten Brørup, Van Haaren, Harry, Jerin Jacob, dev, Li,
	WeiyuanX, Ferruh Yigit, Andrew Rybchenko, david.marchand

On Wed, Oct 12, 2022 at 9:58 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 12/10/2022 18:16, Jerin Jacob:
> > On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> > >
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Wednesday, 12 October 2022 17.13
> > > >
> > > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > > >
> > > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > > >
> > > > > > > > + harry.van.haaren@intel.com as the changes in
> > > > drivers/event/sw.
> > > > > > >
> > > > > > > Thanks Jerin.
> > > > > > >
> > > > > > >
> > > > > > > > > While looking into bug #1101 [1], I noticed a mix of unsigned
> > > > int
> > > > > > > and uint32_t in
> > > > > > > > the test code, which will fail on 64-bit big endian CPUs.
> > > > > > >
> > > > > > > Aha; that we can fix. I am curious why this isn't found in
> > > > CI/reported
> > > > > > > before.
> > > > > >
> > > > > > We probably don't test any 64-bit *big endian* architectures. Just
> > > > a guess.
> > > > >
> > > > > Seems so yes.
> > > > >
> > > > > > > > > Specifically, rte_event_dev_xstats_reset() is called with the
> > > > "ids"
> > > > > > > parameter
> > > > > > > > pointing to an unsigned int [2], but that parameter is a
> > > > pointer to
> > > > > > > an uint32_t.
> > > > > > > > >
> > > > > > > > > I think the type of the ids array parameter to
> > > > > > > rte_event_dev_xstats_reset() should
> > > > > > > > be changed to unsigned int array, like in the other
> > > > > > > rte_event_dev_xxx() functions.
> > > > > > >
> > > > > > > In this case, we have the option to change the type of a variable
> > > > in a
> > > > > > > test-case, or change API and cause API/ABI breakage.
> > > > > >
> > > > > > Well.. yes, but I would phrase that last option: Change the
> > > > API/ABI, so related
> > > > > > functions consistently use the same type for the same variable,
> > > > instead of randomly
> > > > > > mixing uint64_t, uint32_t and unsigned int, depending on function.
> > > > >
> > > > > Aah ok; I see your point now; there is inconsistent usage of
> > > > uint32_t/unsigned int
> > > > > between the Eventdev APIs itself. Agree this is sub-optimal, and
> > > > would have been
> > > > > nice to have spotted before the Eventdev API was stabilized.
> > > > >
> > > > >
> > > > > > Unfortunately, these functions are not marked experimental, so
> > > > breaking API/ABI is
> > > > > > hard to do. :-(
> > > > >
> > > > > Agreed again.
> > > >
> > > > 22.11 is a breaking release,
> > > > and changing type in the API is not much impactful,
> > > > so that's something you can change now,
> > > > or be quiet forever :)
> > >
> > > Question:
> > > 1. Only change the "xstats id" type in the one eventdev function, which deviates from other eventdev functions, or
> > > 2. Change the "xstats id" type for all xstats functions across all device types, for consistency across device types?
> > >
> > > If 2, then what would be a good type?
> >
> > +1 for second option and the type as uint32_t
> >
> > >
> > > Ethdev uses uint64_t for xstats id, and (speaking without knowledge about its internals) that seems like overkill to me. Arrays of these are being used, so size does matter.
>
> uint64_t is not overkill if you consider having stats per queue with a predictable scheme.
> That's an improvement I would like to work on,

You mean to use a bitmask hence uint64_t.
Currently it is mapped as arrays so 2^64 stats may not be needed.

No strong opinion, I was just curious to understand "stats per queue
with a predictable scheme" and how uint64_t helps with  that.


> so I would like to keep uint64_t please.
>
>

^ permalink raw reply	[relevance 0%]

* [PATCH 2/2] ci: update to new API for step outputs in GHA
    2022-10-12 16:29  6% ` [PATCH 1/2] ci: bump versions of actions in GHA David Marchand
@ 2022-10-12 16:29 14% ` David Marchand
  1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-10-12 16:29 UTC (permalink / raw)
  To: dev; +Cc: Aaron Conole, Michael Santana

GitHub actions deprecated use of set-output, replaced with
GITHUB_OUTPUT.

Note: we still have some warnings, as of today, because of
actions/cache@v3 which did not migrate yet.

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 .github/workflows/build.yml | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 187fdef306..b32758ff6f 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -86,12 +86,9 @@ jobs:
     - name: Generate cache keys
       id: get_ref_keys
       run: |
-        echo -n '::set-output name=ccache::'
-        echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
-        echo -n '::set-output name=libabigail::'
-        echo 'libabigail-${{ matrix.config.os }}'
-        echo -n '::set-output name=abi::'
-        echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+        echo 'ccache=ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W) >> $GITHUB_OUTPUT
+        echo 'libabigail=libabigail-${{ matrix.config.os }}' >> $GITHUB_OUTPUT
+        echo 'abi=abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}' >> $GITHUB_OUTPUT
     - name: Retrieve ccache cache
       uses: actions/cache@v3
       with:
@@ -177,8 +174,7 @@ jobs:
     - name: Generate various keys
       id: get_keys
       run: |
-        echo -n '::set-output name=image::'
-        echo 'image-${{ matrix.config.image }}-'$(date -u +%Y-%m-%d)
+        echo 'image=image-${{ matrix.config.image }}-'$(date -u +%Y-%m-%d) >> $GITHUB_OUTPUT
     - name: Retrieve image cache
       id: image_cache
       uses: actions/cache@v3
@@ -239,12 +235,9 @@ jobs:
     - name: Generate various keys
       id: get_keys
       run: |
-        echo -n '::set-output name=ccache::'
-        echo 'ccache-${{ matrix.config.image }}-${{ matrix.config.compiler }}-'$(date -u +%Y-w%W)
-        echo -n '::set-output name=image::'
-        echo 'image-${{ matrix.config.image }}-'$(date -u +%Y-%m-%d)
-        echo -n '::set-output name=logs::'
-        echo 'meson-logs-${{ join(matrix.config.*, '-') }}' | tr -d ':'
+        echo 'ccache=ccache-${{ matrix.config.image }}-${{ matrix.config.compiler }}-'$(date -u +%Y-w%W) >> $GITHUB_OUTPUT
+        echo 'image=image-${{ matrix.config.image }}-'$(date -u +%Y-%m-%d) >> $GITHUB_OUTPUT
+        echo 'logs=meson-logs-${{ join(matrix.config.*, '-') }}' | tr -d ':' >> $GITHUB_OUTPUT
     - name: Retrieve image cache
       id: image_cache
       uses: actions/cache@v3
-- 
2.37.3


^ permalink raw reply	[relevance 14%]

* [PATCH 1/2] ci: bump versions of actions in GHA
  @ 2022-10-12 16:29  6% ` David Marchand
  2022-10-12 16:29 14% ` [PATCH 2/2] ci: update to new API for step outputs " David Marchand
  1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-10-12 16:29 UTC (permalink / raw)
  To: dev; +Cc: Aaron Conole, Michael Santana

GitHub started deprecating GHA actions based on Node 12 [1].
For now, only warnings are raised, but we might as well switch to v3
versions of the common actions, now.

1: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 .github/workflows/build.yml | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index bf17d2b278..187fdef306 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -82,7 +82,7 @@ jobs:
 
     steps:
     - name: Checkout sources
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
     - name: Generate cache keys
       id: get_ref_keys
       run: |
@@ -93,7 +93,7 @@ jobs:
         echo -n '::set-output name=abi::'
         echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
     - name: Retrieve ccache cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ~/.ccache
         key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
@@ -101,13 +101,13 @@ jobs:
           ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
     - name: Retrieve libabigail cache
       id: libabigail-cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       if: env.ABI_CHECKS == 'true'
       with:
         path: libabigail
         key: ${{ steps.get_ref_keys.outputs.libabigail }}
     - name: Retrieve ABI reference cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       if: env.ABI_CHECKS == 'true'
       with:
         path: reference
@@ -154,7 +154,7 @@ jobs:
       run: .ci/linux-build.sh
     - name: Upload logs on failure
       if: failure()
-      uses: actions/upload-artifact@v2
+      uses: actions/upload-artifact@v3
       with:
         name: meson-logs-${{ join(matrix.config.*, '-') }}
         path: |
@@ -181,7 +181,7 @@ jobs:
         echo 'image-${{ matrix.config.image }}-'$(date -u +%Y-%m-%d)
     - name: Retrieve image cache
       id: image_cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ~/.image
         key: ${{ steps.get_keys.outputs.image }}
@@ -235,7 +235,7 @@ jobs:
 
     steps:
     - name: Checkout sources
-      uses: actions/checkout@v2
+      uses: actions/checkout@v3
     - name: Generate various keys
       id: get_keys
       run: |
@@ -247,7 +247,7 @@ jobs:
         echo 'meson-logs-${{ join(matrix.config.*, '-') }}' | tr -d ':'
     - name: Retrieve image cache
       id: image_cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ~/.image
         key: ${{ steps.get_keys.outputs.image }}
@@ -257,7 +257,7 @@ jobs:
         echo 'Image ${{ matrix.config.image }} is not cached.'
         false
     - name: Retrieve ccache cache
-      uses: actions/cache@v2
+      uses: actions/cache@v3
       with:
         path: ~/.ccache
         key: ${{ steps.get_keys.outputs.ccache }}-${{ github.ref }}
@@ -294,7 +294,7 @@ jobs:
       run: docker kill dpdk
     - name: Upload logs on failure
       if: failure()
-      uses: actions/upload-artifact@v2
+      uses: actions/upload-artifact@v3
       with:
         name: ${{ steps.get_keys.outputs.logs }}
         path: |
-- 
2.37.3


^ permalink raw reply	[relevance 6%]

* Re: rte_event_dev_xstats_reset id type
  2022-10-12 16:16  0%         ` Jerin Jacob
@ 2022-10-12 16:28  0%           ` Thomas Monjalon
  2022-10-12 16:47  0%             ` Jerin Jacob
  0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-10-12 16:28 UTC (permalink / raw)
  To: Morten Brørup, Jerin Jacob
  Cc: Van Haaren, Harry, Jerin Jacob, dev, Li, WeiyuanX, Ferruh Yigit,
	Andrew Rybchenko, david.marchand

12/10/2022 18:16, Jerin Jacob:
> On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > Sent: Wednesday, 12 October 2022 17.13
> > >
> > > 12/10/2022 14:14, Van Haaren, Harry:
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > > >
> > > > > > > > Hi Jerin (eventdev maintainer),
> > > > > > >
> > > > > > > + harry.van.haaren@intel.com as the changes in
> > > drivers/event/sw.
> > > > > >
> > > > > > Thanks Jerin.
> > > > > >
> > > > > >
> > > > > > > > While looking into bug #1101 [1], I noticed a mix of unsigned
> > > int
> > > > > > and uint32_t in
> > > > > > > the test code, which will fail on 64-bit big endian CPUs.
> > > > > >
> > > > > > Aha; that we can fix. I am curious why this isn't found in
> > > CI/reported
> > > > > > before.
> > > > >
> > > > > We probably don't test any 64-bit *big endian* architectures. Just
> > > a guess.
> > > >
> > > > Seems so yes.
> > > >
> > > > > > > > Specifically, rte_event_dev_xstats_reset() is called with the
> > > "ids"
> > > > > > parameter
> > > > > > > pointing to an unsigned int [2], but that parameter is a
> > > pointer to
> > > > > > an uint32_t.
> > > > > > > >
> > > > > > > > I think the type of the ids array parameter to
> > > > > > rte_event_dev_xstats_reset() should
> > > > > > > be changed to unsigned int array, like in the other
> > > > > > rte_event_dev_xxx() functions.
> > > > > >
> > > > > > In this case, we have the option to change the type of a variable
> > > in a
> > > > > > test-case, or change API and cause API/ABI breakage.
> > > > >
> > > > > Well.. yes, but I would phrase that last option: Change the
> > > API/ABI, so related
> > > > > functions consistently use the same type for the same variable,
> > > instead of randomly
> > > > > mixing uint64_t, uint32_t and unsigned int, depending on function.
> > > >
> > > > Aah ok; I see your point now; there is inconsistent usage of
> > > uint32_t/unsigned int
> > > > between the Eventdev APIs itself. Agree this is sub-optimal, and
> > > would have been
> > > > nice to have spotted before the Eventdev API was stabilized.
> > > >
> > > >
> > > > > Unfortunately, these functions are not marked experimental, so
> > > breaking API/ABI is
> > > > > hard to do. :-(
> > > >
> > > > Agreed again.
> > >
> > > 22.11 is a breaking release,
> > > and changing type in the API is not much impactful,
> > > so that's something you can change now,
> > > or be quiet forever :)
> >
> > Question:
> > 1. Only change the "xstats id" type in the one eventdev function, which deviates from other eventdev functions, or
> > 2. Change the "xstats id" type for all xstats functions across all device types, for consistency across device types?
> >
> > If 2, then what would be a good type?
> 
> +1 for second option and the type as uint32_t
> 
> >
> > Ethdev uses uint64_t for xstats id, and (speaking without knowledge about its internals) that seems like overkill to me. Arrays of these are being used, so size does matter.

uint64_t is not overkill if you consider having stats per queue with a predictable scheme.
That's an improvement I would like to work on,
so I would like to keep uint64_t please.



^ permalink raw reply	[relevance 0%]

* Re: rte_event_dev_xstats_reset id type
  @ 2022-10-12 16:16  0%         ` Jerin Jacob
  2022-10-12 16:28  0%           ` Thomas Monjalon
  0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-10-12 16:16 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Thomas Monjalon, Van Haaren, Harry, Jerin Jacob, dev, Li,
	WeiyuanX, Ferruh Yigit, Andrew Rybchenko, david.marchand

On Wed, Oct 12, 2022 at 9:05 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Wednesday, 12 October 2022 17.13
> >
> > 12/10/2022 14:14, Van Haaren, Harry:
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > > > >
> > > > > > > Hi Jerin (eventdev maintainer),
> > > > > >
> > > > > > + harry.van.haaren@intel.com as the changes in
> > drivers/event/sw.
> > > > >
> > > > > Thanks Jerin.
> > > > >
> > > > >
> > > > > > > While looking into bug #1101 [1], I noticed a mix of unsigned
> > int
> > > > > and uint32_t in
> > > > > > the test code, which will fail on 64-bit big endian CPUs.
> > > > >
> > > > > Aha; that we can fix. I am curious why this isn't found in
> > CI/reported
> > > > > before.
> > > >
> > > > We probably don't test any 64-bit *big endian* architectures. Just
> > a guess.
> > >
> > > Seems so yes.
> > >
> > > > > > > Specifically, rte_event_dev_xstats_reset() is called with the
> > "ids"
> > > > > parameter
> > > > > > pointing to an unsigned int [2], but that parameter is a
> > pointer to
> > > > > an uint32_t.
> > > > > > >
> > > > > > > I think the type of the ids array parameter to
> > > > > rte_event_dev_xstats_reset() should
> > > > > > be changed to unsigned int array, like in the other
> > > > > rte_event_dev_xxx() functions.
> > > > >
> > > > > In this case, we have the option to change the type of a variable
> > in a
> > > > > test-case, or change API and cause API/ABI breakage.
> > > >
> > > > Well.. yes, but I would phrase that last option: Change the
> > API/ABI, so related
> > > > functions consistently use the same type for the same variable,
> > instead of randomly
> > > > mixing uint64_t, uint32_t and unsigned int, depending on function.
> > >
> > > Aah ok; I see your point now; there is inconsistent usage of
> > uint32_t/unsigned int
> > > between the Eventdev APIs itself. Agree this is sub-optimal, and
> > would have been
> > > nice to have spotted before the Eventdev API was stabilized.
> > >
> > >
> > > > Unfortunately, these functions are not marked experimental, so
> > breaking API/ABI is
> > > > hard to do. :-(
> > >
> > > Agreed again.
> >
> > 22.11 is a breaking release,
> > and changing type in the API is not much impactful,
> > so that's something you can change now,
> > or be quiet forever :)
>
> Question:
> 1. Only change the "xstats id" type in the one eventdev function, which deviates from other eventdev functions, or
> 2. Change the "xstats id" type for all xstats functions across all device types, for consistency across device types?
>
> If 2, then what would be a good type?

+1 for second option and the type as uint32_t

>
> Ethdev uses uint64_t for xstats id, and (speaking without knowledge about its internals) that seems like overkill to me. Arrays of these are being used, so size does matter.
>

^ permalink raw reply	[relevance 0%]

Results 1601-1800 of ~18000  next (older) | prev (newer) | reverse | sort options + mbox downloads above

-- links below jump to the message on this page --
2021-12-26 15:34     [RFC] mempool: rte_mempool_do_generic_get optimizations Morten Brørup
2022-10-09 13:37     ` [PATCH v6 0/4] mempool: fix mempool cache flushing algorithm Andrew Rybchenko
2022-10-09 13:37       ` [PATCH v6 3/4] mempool: fix " Andrew Rybchenko
2022-10-09 14:31         ` Morten Brørup
2022-10-09 14:51           ` Andrew Rybchenko
2022-10-09 15:08             ` Morten Brørup
2022-10-14 14:01  3%           ` Olivier Matz
2022-10-14 15:57  3%             ` Morten Brørup
2022-10-14 19:50  0%               ` Olivier Matz
2022-10-15  6:57  0%                 ` Morten Brørup
2022-10-18 16:32  0%                   ` Jerin Jacob
2022-04-19  9:01     [PATCH] doc: fix typos 'depreciated' instead of 'deprecated' Stephen Coleman
2022-04-19 15:44     ` Ray Kinsella
2022-11-15 16:13  0%   ` Thomas Monjalon
2022-04-20  8:16     [PATCH v1 0/5] Direct re-arming of buffers on receive side Feifei Wang
2023-01-04  7:30     ` [PATCH v3 0/3] " Feifei Wang
2023-01-04  7:30       ` [PATCH v3 1/3] ethdev: enable direct rearm with separate API Feifei Wang
2023-01-04  8:21         ` Morten Brørup
2023-01-04  8:51           ` 回复: " Feifei Wang
2023-01-04 10:11  4%         ` Morten Brørup
2022-09-15  8:26     [PATCH] cryptodev: add missing algorithm strings Volodymyr Fialko
2022-11-02 10:50  4% ` Kevin Traynor
2022-11-02 10:58  0%   ` [EXT] " Akhil Goyal
2022-11-02 12:13  4%     ` David Marchand
2022-11-02 12:31  0%       ` Akhil Goyal
2022-09-29 10:29     [PATCH v2 0/4] add trace points in ethdev library Ankur Dwivedi
2022-12-14 12:10     ` [PATCH v3 1/4] ethdev: add trace points Ferruh Yigit
2022-12-15  6:49       ` Jerin Jacob
2023-01-12  9:10         ` Thomas Monjalon
2023-01-12  9:43           ` trace point symbols Morten Brørup
2023-01-13 11:22  3%         ` Jerin Jacob
2022-10-10  6:08     [PATCH v2 00/24] add the basic rte_flow offload support of nfp PMD Chaoyong He
2022-10-10  6:08     ` [PATCH v2 03/24] net/nfp: add the flow APIs " Chaoyong He
2022-10-10 14:51       ` Ferruh Yigit
2022-10-19  3:00  3%     ` Chaoyong He
2022-10-19 11:11  3%       ` Ferruh Yigit
2022-10-19 11:30  0%         ` Chaoyong He
2022-10-19 11:38  0%           ` Ferruh Yigit
2022-10-10 10:17     [PATCH v5 1/8] net/gve/base: introduce GVE PMD base code Junfeng Guo
2022-10-20 10:36     ` [PATCH v6 0/8] introduce GVE PMD Junfeng Guo
2022-10-20 10:36       ` [PATCH v6 3/8] net/gve: add support for device initialization Junfeng Guo
2022-10-20 14:42  3%     ` Ferruh Yigit
2022-10-24  2:10  0%       ` Guo, Junfeng
2022-10-10 15:37     [PATCH] vhost: promote per-queue stats API to stable Maxime Coquelin
2022-10-17 13:22  0% ` David Marchand
2022-10-24  8:53  0% ` Xia, Chenbo
2022-10-26  9:31  0% ` Xia, Chenbo
2022-10-11  1:50     release candidate 22.11-rc1 Thomas Monjalon
2022-10-13  5:28  0% ` Jiang, YuX
2022-10-20  5:24  0%   ` Jiang, YuX
2022-10-24 13:12  0% ` David Marchand
2022-10-27 21:00  0% ` Thinh Tran
2022-10-12  8:10     rte_event_dev_xstats_reset id type Morten Brørup
2022-10-12 10:41     ` Morten Brørup
2022-10-12 12:14       ` Van Haaren, Harry
2022-10-12 15:13         ` Thomas Monjalon
2022-10-12 15:35           ` Morten Brørup
2022-10-12 16:16  0%         ` Jerin Jacob
2022-10-12 16:28  0%           ` Thomas Monjalon
2022-10-12 16:47  0%             ` Jerin Jacob
2022-10-12 20:44  0%               ` Thomas Monjalon
2022-10-13  6:51  0%                 ` xstats " Morten Brørup
2022-10-13  7:12  3%                   ` Pavan Nikhilesh Bhagavatula
2022-10-13  8:26  0%                     ` Thomas Monjalon
2022-10-13  8:33  0%                       ` [EXT] " Pavan Nikhilesh Bhagavatula
2022-10-13  8:59  0%                     ` Van Haaren, Harry
2022-10-12 16:29     [PATCH 0/2] GitHub Actions configuration fixes David Marchand
2022-10-12 16:29  6% ` [PATCH 1/2] ci: bump versions of actions in GHA David Marchand
2022-10-12 16:29 14% ` [PATCH 2/2] ci: update to new API for step outputs " David Marchand
2022-10-13  9:15 10% [PATCH] eventdev: update release notes pbhagavatula
2022-10-19 13:00  0% ` Jerin Jacob
2022-10-13  9:23  2% [PATCH] eventdev: increase xstats ID width to 64 bits pbhagavatula
2022-10-13 10:16  0% ` Mattias Rönnblom
2022-10-13 11:35  1% ` [PATCH v2] " pbhagavatula
2022-10-19 13:24  0%   ` Jerin Jacob
2022-10-17 14:07  3% [PATCH] ci: combine static and shared linking build tests David Marchand
2022-10-20 11:44  0% ` David Marchand
2022-10-20 15:34  0% ` Aaron Conole
2022-10-27 11:21  0%   ` David Marchand
2022-10-21  8:13     [PATCH] eventdev: fix event vector documentation typo Mattias Rönnblom
2022-10-21  9:42  8% ` Jerin Jacob
2022-10-26 14:26     [PATCH v6 0/4] mempool: fix mempool cache flushing algorithm Morten Brørup
2022-10-26 14:44     ` [PATCH] mempool: cache align mempool cache objects Morten Brørup
2022-10-27  8:34       ` Olivier Matz
2022-10-27  9:22         ` Morten Brørup
2022-10-27 11:42  3%       ` Olivier Matz
2022-10-27 12:11  0%         ` Morten Brørup
2022-10-27 15:20  0%           ` Olivier Matz
2022-10-30 11:54     [PATCH] mempool: split statistics from debug Morten Brørup
2022-10-31 11:26     ` [PATCH v2 1/3] " Morten Brørup
2022-10-31 11:26       ` [PATCH v2 3/3] mempool: use cache for frequently updated statistics Morten Brørup
2022-11-02  8:01  3%     ` Mattias Rönnblom
2022-11-02  9:29  4%       ` Morten Brørup
2022-11-02 17:55  0%         ` Mattias Rönnblom
2022-11-03 15:47  9% [PATCH 0/2] ABI check updates David Marchand
2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
2022-11-05 13:40     [RFC] mempool: zero-copy cache put bulk Morten Brørup
2022-11-05 23:11     ` Honnappa Nagarahalli
2022-11-06  6:57       ` Morten Brørup
2022-11-09 17:57  3%     ` Honnappa Nagarahalli
2022-11-09 20:36  0%       ` Morten Brørup
2022-11-09 22:45  0%         ` Honnappa Nagarahalli
2022-11-10 10:15  0%           ` Morten Brørup
2022-11-08 11:25     FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats Morten Brørup
2022-11-08 13:32     ` Thomas Monjalon
2022-11-08 14:30       ` Morten Brørup
2022-11-08 15:51         ` Thomas Monjalon
2022-11-08 15:59           ` Bruce Richardson
2022-11-08 17:38  3%         ` Konstantin Ananyev
2022-11-09  5:03  4%           ` Morten Brørup
2022-11-09  8:21  0%             ` Mattias Rönnblom
2022-11-09 10:19  4%               ` Konstantin Ananyev
2022-11-09 11:42  0%                 ` Morten Brørup
2022-11-17 13:58     Regarding User Data in DPDK ACL Library venkatesh bs
2022-11-17 22:52     ` Stephen Hemminger
2022-11-18 10:30  3%   ` Konstantin Ananyev
2022-11-19 13:13  0%     ` venkatesh bs
2022-11-21  5:40  0%     ` Honnappa Nagarahalli
2022-11-21 14:15  0%       ` Konstantin Ananyev
2022-11-21 16:56  0%         ` Honnappa Nagarahalli
2022-11-22 13:38  0%           ` Konstantin Ananyev
2022-11-22 15:53  0%             ` Honnappa Nagarahalli
2022-11-22 13:09  3% [PATCH] net/nfp: update descriptors logic Niklas Söderlund
2022-11-23 10:26     [RFC PATCH 0/4] lcore telemetry improvements Robin Jarry
2022-12-07 16:21     ` [PATCH " Robin Jarry
2022-12-07 16:21       ` [PATCH 2/4] eal: allow applications to report their cpu usage Robin Jarry
2022-12-13 15:49  3%     ` Robin Jarry
2022-12-13 16:39  0%       ` Morten Brørup
2022-12-13 17:45  0%       ` Tyler Retzlaff
2022-11-24 16:56  3% [PATCH v1] doc: update release notes for 22.11 John McNamara
2022-11-27 22:22  4% DPDK 22.11 released Thomas Monjalon
2022-11-28  8:33 11% [PATCH] version: 23.03-rc0 David Marchand
2022-12-01 15:37  0% ` Thomas Monjalon
2022-12-01 15:50  0%   ` David Marchand
2022-11-29 14:00     [PATCH] drivers: fix symbol exports when map is omitted David Marchand
2022-11-29 18:23  3% ` Ferruh Yigit
2022-11-30  7:13  4%   ` David Marchand
2022-11-30  8:27  0%     ` David Marchand
2022-11-30  9:19  0%       ` Ferruh Yigit
2022-12-02 11:09  3% ` [PATCH v4 1/2] " David Marchand
2022-12-02 13:39  0%   ` Aaron Conole
2022-12-05 10:23  3%     ` David Marchand
2022-12-05 10:43  0%       ` [EXT] " Akhil Goyal
2022-12-05 12:36  0%         ` David Marchand
2022-12-05 13:47  0%           ` Akhil Goyal
2022-12-05 15:37  0%             ` Thomas Monjalon
2022-12-05 16:26  0%               ` Akhil Goyal
2022-12-06 10:12  0%               ` Ferruh Yigit
2022-12-06 10:18                     ` David Marchand
2022-12-06 12:25                       ` Ferruh Yigit
2022-12-07 18:00  5%                     ` Patrick Robb
2022-12-08 13:22  3%                       ` Thomas Monjalon
2022-12-08 16:06  0%                         ` Patrick Robb
2022-11-30 22:54  4% help with pthread_t deprecation / api changes Tyler Retzlaff
2022-12-02  1:12  0% ` Tyler Retzlaff
2022-12-02  8:03  0%   ` Morten Brørup
2022-12-02 19:57         ` Tyler Retzlaff
2022-12-09  7:53           ` Thomas Monjalon
2022-12-09 16:48  3%         ` Stephen Hemminger
2022-12-09 20:06  0%           ` Tyler Retzlaff
2022-12-09 21:14  0%           ` Thomas Monjalon
2022-12-09 22:38  0%             ` Stephen Hemminger
2022-12-09 23:55  0%               ` Tyler Retzlaff
2022-12-01 19:01  3% DPDK Release Status Meeting 2022-12-01 Mcnamara, John
2022-12-02  9:46  4% DPDK 22.11.1 released David Marchand
2022-12-03 17:13  3% mbuf performance optimization Morten Brørup
2022-12-05 20:24     [PATCH 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-05 20:24     ` [PATCH 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-05 21:18       ` Stephen Hemminger
2022-12-06  0:24  3%     ` Tyler Retzlaff
2022-12-06 17:28     ` [PATCH v2 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-06 17:28       ` [PATCH v2 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-07  9:13         ` Mattias Rönnblom
2022-12-07 16:38  3%       ` Tyler Retzlaff
2022-12-08 21:59  0%         ` Mattias Rönnblom
2022-12-06  5:54     [RFC 2/2] ethdev: add API to set process to primary or secondary Stephen Hemminger
2022-12-21  9:00     ` [RFC v3 0/2] add API to set process to active or standby Rongwei Liu
2022-12-21  9:00       ` [RFC v3 2/2] ethdev: " Rongwei Liu
2022-12-21  9:12  4%     ` Jerin Jacob
2022-12-21  9:32  3%       ` Rongwei Liu
2022-12-21 10:59  5%         ` Jerin Jacob
2022-12-21 12:05  5%           ` Rongwei Liu
2022-12-21 12:44  0%             ` Jerin Jacob
2022-12-21 12:50  4%               ` Rongwei Liu
2022-12-21 13:12  0%                 ` Jerin Jacob
2022-12-21 14:33  3%                   ` Rongwei Liu
2022-12-26 16:44  4%                     ` Ori Kam
2023-01-15 22:46  0%                       ` Thomas Monjalon
2022-12-06 10:16  4% [PATCH] devtools: update Meson setup command Thomas Monjalon
2022-12-06 11:29  1% 21.11.3 patches review and test Kevin Traynor
2022-12-13 11:48  0% ` Christian Ehrhardt
2022-12-16  7:55  0% ` YangHang Liu
2022-12-06 12:23     [PATCH 1/2] devtools: document test meson script config options Ferruh Yigit
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
2022-12-08 18:14  7%   ` [EXT] " Akhil Goyal
2022-12-08 19:43  4%     ` Thomas Monjalon
2022-12-09  4:16  4%       ` Akhil Goyal
2022-12-09  8:22  8%   ` David Marchand
2022-12-09  8:44  4%     ` Ferruh Yigit
2022-12-09  9:02     ` [PATCH v2 1/2] devtools: document test meson script config options David Marchand
2022-12-09  9:02 13%   ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
2022-12-21 15:02  4%     ` David Marchand
2022-12-08  8:05     [PATCH 0/8] fix possible data truncation and conversion error Huisong Li
2022-12-09 11:04  3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-09 18:24  0%   ` Morten Brørup
2022-12-12  6:23  0%     ` lihuisong (C)
2022-12-11  9:02  0%   ` fengchengwen
2022-12-12  6:42  3% ` [PATCH V3 " Huisong Li
2022-12-12 10:31  0%   ` Bruce Richardson
2022-12-12 11:02  0%     ` Morten Brørup
2022-12-12 11:20  0%       ` Bruce Richardson
2022-12-12 12:03  3%         ` Morten Brørup
2022-12-12 12:16  3%           ` Bruce Richardson
2022-12-13 11:00  0%             ` Morten Brørup
2022-12-13 17:12  3%             ` Bruce Richardson
2022-12-13  3:02  0%           ` lihuisong (C)
2022-12-13 10:15  3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
2022-12-14 12:32  3% ` [PATCH V5 0/8] " Huisong Li
2022-12-15 10:31  3% ` [PATCH V6 " Huisong Li
2022-12-16  1:54  3% ` [PATCH V7 " Huisong Li
2022-12-19  7:06  3% ` [PATCH V8 " Huisong Li
2023-01-16 12:06  0%   ` lihuisong (C)
2022-12-12 15:10  2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13  7:31  0% ` Ruifeng Wang
2022-12-13  7:37  0% ` Anoob Joseph
2022-12-13  8:22  0% ` Power, Ciara
2022-12-14  9:32  0% ` Zhang, Fan
2023-01-04  6:18  2% ` [PATCH v2] " Akhil Goyal
2023-01-05 10:56  0%   ` Akhil Goyal
2022-12-13 15:07  3% [PATCH] ci: drop Travis configuration David Marchand
2022-12-13 18:27  4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
2022-12-13 18:27  3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
2022-12-13 18:27  3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
2022-12-13 20:19  3%   ` Morten Brørup
2022-12-14 17:53  0%     ` Tyler Retzlaff
2022-12-15  2:39  0%       ` lihuisong (C)
2022-12-14 17:38     ` [RFC PATCH 2/7] telemetry: add uint type as alias for u64 Tyler Retzlaff
2022-12-15  9:44       ` Bruce Richardson
2022-12-15 13:36         ` Thomas Monjalon
2022-12-15 13:58  4%       ` Bruce Richardson
2022-12-19 10:37  0%         ` Thomas Monjalon
2022-12-19 13:22  0%           ` Bruce Richardson
2023-01-12 10:58  4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 10:59  3%   ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 10:59  3%   ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-12 17:41  4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41  3%   ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 17:41  3%   ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-13 16:39  0%   ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2022-12-20 16:22  1% DPDK 21.11.3 released Kevin Traynor
2022-12-21 10:29     [RFC 0/5] add new port affinity item and affinity in Tx queue API Jiawei Wang
2022-12-21 10:29  2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
2023-01-11 16:47  0%   ` Ori Kam
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09  9:34 23% ` [PATCH v2] " Thomas Monjalon
2023-01-10 11:08  4%   ` Ferruh Yigit
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 14:10  4%   ` Bruce Richardson
2023-01-11 14:11  4%   ` David Marchand
2023-01-11 17:04  4%     ` Thomas Monjalon
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2023-01-12 10:53  4%   ` David Marchand
2023-01-12 14:14  4%     ` Ferruh Yigit
2023-01-09 22:56     RFC abstracting atomics Tyler Retzlaff
2023-01-10  9:16     ` Bruce Richardson
2023-01-10 20:10  3%   ` Tyler Retzlaff
2023-01-11 10:10  0%     ` Bruce Richardson
     [not found]     <20220825024425.10534-1-lihuisong@huawei.com>
2022-12-06  9:26     ` [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port Huisong Li
2023-01-10 16:51  3%   ` Ferruh Yigit
2023-01-11  0:53  0%     ` lihuisong (C)
2023-01-11 10:27  3%       ` Ferruh Yigit
2023-01-11 10:46  0%         ` Ferruh Yigit
2023-01-12  2:26  0%           ` lihuisong (C)
2023-01-13  5:03     [RFC] Remove Kernel Network Interface (KNI) Stephen Hemminger
2023-01-13  8:12     ` Thomas Monjalon
2023-01-13 17:13       ` Stephen Hemminger
2023-01-13 18:34         ` Thomas Monjalon
2023-01-13 23:25           ` Stephen Hemminger
2023-01-14 22:21  3%         ` Tyler Retzlaff
2023-01-16 15:37     [PATCH 0/5] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 15:37  3% ` [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-16 17:37     ` [PATCH v2 0/6] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 17:37  3%   ` [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-17 10:16  3% [RFC] Fix cryptodev socket id for devices on unknown NUMA node Didier Pallard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).