[PATCH v2] app/test-crypto-perf: add missed resubmission fix
Currently, after enqueue_burst, there may be ops_unused ops
left for next round enqueue. And in next round preparation,
only ops_needed ops will be added. But if in the final round
the left ops is less than ops_needed, there will be invalid
ops between the new needed ops and previous unused ops. The
previous unused ops should be moved front after the needed
ops.
In the commit[1], an resubmission fix was added to throughput
test, and the fix was missed for verify.
This commit adds the missed resubmission fix for verify.
[1]
commit 44e2980b70d1 ("app/crypto-perf: fix crypto operation resubmission")
Fixes: f8be1786b1b8 ("app/crypto-perf: introduce performance test application")
Cc: sta...@dpdk.org
Signed-off-by: Suanming Mou
Acked-by: Anoob Joseph
---
v2: code-style update.
---
app/test-crypto-perf/cperf_test_verify.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/app/test-crypto-perf/cperf_test_verify.c
b/app/test-crypto-perf/cperf_test_verify.c
index 2b0d3f142b..10172a53a0 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -275,7 +275,6 @@ cperf_verify_test_runner(void *test_ctx)
ops_needed, ctx->sess, ctx->options,
ctx->test_vector, iv_offset, &imix_idx, NULL);
-
/* Populate the mbuf with the test vector, for verification */
for (i = 0; i < ops_needed; i++)
cperf_mbuf_set(ops[i]->sym->m_src,
@@ -293,6 +292,17 @@ cperf_verify_test_runner(void *test_ctx)
}
#endif /* CPERF_LINEARIZATION_ENABLE */
+ /**
+* When ops_needed is smaller than ops_enqd, the
+* unused ops need to be moved to the front for
+* next round use.
+*/
+ if (unlikely(ops_enqd > ops_needed)) {
+ size_t nb_b_to_mov = ops_unused * sizeof(struct
rte_crypto_op *);
+
+ memmove(&ops[ops_needed], &ops[ops_enqd], nb_b_to_mov);
+ }
+
/* Enqueue burst of ops on crypto device */
ops_enqd = rte_cryptodev_enqueue_burst(ctx->dev_id, ctx->qp_id,
ops, burst_size);
--
2.34.1
Re: [PATCH] bus/uacce: introduce UACCE bus
Hi chengwen,
lgtm,
with below to changes,
Acked-by: Huisong Li
在 2023/12/8 14:18, Chengwen Feng 写道:
UACCE (Unified/User-space-access-intended Accelerator Framework) was
upstream to Linux kernel version 5.7, and it targets to provide Shared
Virtual Addressing (SVA) between accelerators and processes. So
accelerator can access any data structure of the main cpu. [1] for more
information.
This commit introduces UACCE bus, so that the accelerator devices could
seen at DPDK and could be further registered as a compress, crypto, dma
and ethdev device.
[1] https://docs.kernel.org/misc-devices/uacce.html
Signed-off-by: Chengwen Feng
---
MAINTAINERS | 4 +
drivers/bus/meson.build | 1 +
drivers/bus/uacce/bus_uacce_driver.h | 254 ++
drivers/bus/uacce/meson.build| 12 +
drivers/bus/uacce/uacce.c| 702 +++
drivers/bus/uacce/version.map| 15 +
6 files changed, 988 insertions(+)
create mode 100644 drivers/bus/uacce/bus_uacce_driver.h
create mode 100644 drivers/bus/uacce/meson.build
create mode 100644 drivers/bus/uacce/uacce.c
create mode 100644 drivers/bus/uacce/version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..89711029d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -604,6 +604,10 @@ Platform bus driver
M: Tomasz Duszynski
F: drivers/bus/platform/
+UACCE bus driver
+M: Chengwen Feng
+F: drivers/bus/uacce/
+
VDEV bus driver
F: drivers/bus/vdev/
F: app/test/test_vdev.c
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index a78b4283bf..d67db8576b 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -9,6 +9,7 @@ drivers = [
'ifpga',
'pci',
'platform',
+'uacce',
'vdev',
'vmbus',
]
diff --git a/drivers/bus/uacce/bus_uacce_driver.h
b/drivers/bus/uacce/bus_uacce_driver.h
new file mode 100644
index 00..0276154658
--- /dev/null
+++ b/drivers/bus/uacce/bus_uacce_driver.h
@@ -0,0 +1,254 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 HiSilicon Limited
+ */
+
+#ifndef BUS_UACCE_DRIVER_H
+#define BUS_UACCE_DRIVER_H
+
+/**
+ * @file
+ *
+ * HiSilicon UACCE bus interface.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define RTE_UACCE_DEV_PATH_SIZE256
+#define RTE_UACCE_API_NAME_SIZE64
+#define RTE_UACCE_ALGS_NAME_SIZE 384
+#define RTE_UACCE_ATTR_MAX_SIZE384
+
+/*
+ * Definition for queue file region type.
+ */
+enum rte_uacce_qfrt {
+ RTE_UACCE_QFRT_MMIO = 0, /**< Device mmio region. */
+ RTE_UACCE_QFRT_DUS, /**< Device user share region. */
+ RTE_UACCE_QFRT_BUTT
+};
+
+struct rte_uacce_driver;
+
+/**
+ * A structure describing a UACCE device.
+ */
+struct rte_uacce_device {
+ RTE_TAILQ_ENTRY(rte_uacce_device) next; /**< Next in device list. */
+ struct rte_device device;/**< Inherit core device. */
+ struct rte_uacce_driver *driver; /**< Driver used in probing. */
+ char name[RTE_DEV_NAME_MAX_LEN]; /**< Device name. */
+ char dev_root[RTE_UACCE_DEV_PATH_SIZE]; /**< Sysfs path with device
name. */
+ char cdev_path[RTE_UACCE_DEV_PATH_SIZE]; /**< Device path in devfs. */
+ char api[RTE_UACCE_API_NAME_SIZE]; /**< Device context type. */
+ char algs[RTE_UACCE_ALGS_NAME_SIZE]; /**< Device supported
algorithms. */
+ uint32_t flags; /**< Device flags. */
+ int numa_node; /**< NUMA node connection, -1
if unknown. */
+ uint32_t qfrt_sz[RTE_UACCE_QFRT_BUTT]; /**< Queue file region type's
size. */
+};
+
+/**
+ * @internal
+ * Helper macro for drivers that need to convert to struct rte_uacce_device.
+ */
+#define RTE_DEV_TO_UACCE_DEV(ptr) \
+ container_of(ptr, struct rte_uacce_device, device)
+
+#define RTE_DEV_TO_UACCE_DEV_CONST(ptr) \
+ container_of(ptr, const struct rte_uacce_device, device)
+
+/**
+ * A structure describing an ID for a UACCE driver. Each driver provides a
+ * table of these IDs for each device that it supports.
+ */
+struct rte_uacce_id {
+ const char *dev_api; /**< Device context type. */
+ /** Device algorithm.
+* If this field is NULL, only dev_api is matched. Otherwise, in
+* addition to match dev_api, dev_alg must be a subset of device's
+* algs.
+*/
+ const char *dev_alg;
+};
+
+/**
+ * Initialization function for the driver called during probing.
+ */
+typedef int (rte_uacce_probe_t)(struct rte_uacce_driver *, struct
rte_uacce_device *);
+
+/**
+ * Uninitialization function for the driver called during hotplugging.
+ */
+typedef int (rte_uacce_remove_t)(struct rte_uacce_device *);
+
+/**
+ * A structure describing a UACCE driver.
+ */
+struct
RE: [PATCH v2 2/3] ethdev: add compare item
Hi,
> -Original Message-
> From: Andrew Rybchenko
> Sent: Friday, January 12, 2024 4:11 PM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Ferruh Yigit
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2 2/3] ethdev: add compare item
>
> On 12/19/23 04:33, Suanming Mou wrote:
> > The new item type is added for the case user wants to match traffic
> > based on packet field compare result with other fields or immediate
> > value.
> >
> > e.g. take advantage the compare item user will be able to accumulate a
> > IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag
> > register, then compare the tag register with IPv4 header total length
> > to understand the packet has payload or not.
> >
> > The supported operations can be as below:
> > - RTE_FLOW_ITEM_COMPARE_EQ (equal)
> > - RTE_FLOW_ITEM_COMPARE_NE (not equal)
> > - RTE_FLOW_ITEM_COMPARE_LT (less than)
> > - RTE_FLOW_ITEM_COMPARE_LE (less than or equal)
> > - RTE_FLOW_ITEM_COMPARE_GT (great than)
> > - RTE_FLOW_ITEM_COMPARE_GE (great than or equal)
> >
> > Signed-off-by: Suanming Mou
>
> Just one nit below, anyway
> Acked-by: Andrew Rybchenko
>
> I dislike that many line of code are moved, but it looks like it is better
> than keeping
> them in place and break order in the file.
These only change once but will keep the file be clean for the coming days.
Anyway, if there are others suggest that as well, I will change. Thanks.
>
> > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index 447e28e694..220b396295 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -3841,6 +3841,12 @@ This section lists supported pattern items and their
> attributes, if any.
> >
> > - ``packet_type {unsigned}``: packet type.
> >
> > +- ``compare``: match the comparison result between packet fields or value.
> > +
> > +- ``op {string}``: comparison operation type.
> > +- ``a_type {string}``: compared field.
> > +- ``b_type {string}``: comparator field.
> > +- ``width {unsigned}``: comparison width.
>
> Missing one more empty line before the next section.
Thanks, will update.
>
> >
> > Actions list
> >
>
> [snip]
[dpdk-dev] [PATCH] eal: refactor rte_eal_init into sub-functions
From: Rahul Gupta In continuation to the following email, I am sending this patch. https://inbox.dpdk.org/dev/20231110172523.ga17...@microsoft.com/ (Apologies for delay in sending the patch) Initialization requires rte_eal_init + rte_pktmbuf_pool_create which can consume a total time of 500-600 ms: a) For many devices FLR may take a significant chunk of time (200-250 ms in our use-case), this FLR is triggered during device probe in rte_eal_init(). b) rte_pktmbuf_pool_create() can consume up to 300-350 ms for applications that require huge memory. This cost is incurred on each restart (which happens in our use-case during binary updates for servicing). This patch provides an optimization using pthreads that applications can use and which can save 200-230ms. In this patch, rte_eal_init() is refactored into two parts- a) 1st part is dependent code ie- it’s a perquisite of the FLR and mempool creation. So this code needs to be executed before any pthreads. Its named as rte_eal_init_setup() b) 2nd part of code is independent code ie- it can execute in parallel to mempool creation in a pthread. Its named as rte_eal_init_async(). Existing applications requires to just call- rte_eal_init_wait_async_complete() after rte_eal_init() unless they wish to leverage the optimization. If the application wants to leverage this optimization, then it should create a thread using rte_eal_remote_launch() to schedule a task it would like todo in parallel rte_eal_init_async(), this task can be a mbuf pool creation using- rte_pktmbuf_pool_create() After both the above tasks, if next operations require completion of above thread a), then user can use rte_eal_init_wait_async_complete(), or if user wants to just check status of that thread, then use- rte_eal_init_async_done() Signed-off-by: Rahul Gupta Signed-off-by: Rahul Gupta --- app/test-pmd/testpmd.c| 20 +++ lib/eal/include/rte_eal.h | 48 lib/eal/linux/eal.c | 52 --- lib/eal/version.map | 6 + 4 files changed, 123 insertions(+), 3 deletions(-) diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index 9e4e99e53b..94d667eb77 100644 --- a/app/test-pmd/testpmd.c +++ b/app/test-pmd/testpmd.c @@ -4531,6 +4531,7 @@ main(int argc, char** argv) portid_t port_id; uint16_t count; int ret; + int lcore_id; #ifdef RTE_EXEC_ENV_WINDOWS signal(SIGINT, signal_handler); @@ -4555,6 +4556,25 @@ main(int argc, char** argv) rte_exit(EXIT_FAILURE, "Cannot init EAL: %s\n", rte_strerror(rte_errno)); + lcore_id = rte_lcore_id(); + lcore_id = rte_get_next_lcore(lcore_id, 0, 1); + /* Gives status of rte_eal_init_async() */ + while (rte_eal_init_async_done(lcore_id) == 0) + ; + + /* +* Use rte_eal_init_wait_async_complete() to get return value of +* rte_eal_init_async(). +* Or +* if testpmd application dont want to know progress/status of +* rte_eal_init_async() and just want to wait till it finishes +* then use following function. +*/ + ret = rte_eal_init_wait_async_complete(); + if (ret < 0) + rte_exit(EXIT_FAILURE, "Cannot init EAL: " +"rte_eal_init_async() failed: %s\n", +strerror(ret)); /* allocate port structures, and init them */ init_port(); diff --git a/lib/eal/include/rte_eal.h b/lib/eal/include/rte_eal.h index c2256f832e..cd976c8758 100644 --- a/lib/eal/include/rte_eal.h +++ b/lib/eal/include/rte_eal.h @@ -111,6 +111,54 @@ int rte_eal_iopl_init(void); */ int rte_eal_init(int argc, char **argv); +/** + * Initialize the Environment Abstraction Layer (EAL): Initial setup + * + * Its called from rte_eal_init() on MASTER lcore only and must NOT be directly + * called by user application. + * The driver dependent code is present in this function, ie before calling any other + * function eal library function this function must be complete successfully. + * + * return value is same as rte_eal_init(). + */ +__rte_experimental int rte_eal_init_setup(int argc, char **argv); + +/** + * Initialize the Environment Abstraction Layer (EAL): FLR and probe device + * + * Its thread is forked by rte_eal_init() and must NOT be directly called by user application. + * Launched on next available slave lcore. + * In this function initialisation needed for memory pool creation is completed, + * so this code can be executed in parallel to non device related operations + * like mbuf pool creation. + * + * return value is same as rte_eal_init(). + */ +__rte_experimental int rte_eal_init_async(__attribute__((unused)) void *arg); + +/** + * Initialize the Environment Abstraction Layer (EAL): Indication of rte_eal_init() completion + * + * It waits for rte_eal_init_async() to finish. It MUST be called f
Re: [PATCH] build: fix linker warnings about undefined symbols
On Fri, Jan 12, 2024 at 9:49 PM Morten Brørup
wrote:
> > you can use symver in combination with visibility default
> >
> > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> >
> > anyway just food for thought, it would get me out of having to hack &
> > enhance the .def from .map generation and unfortunately even with that
> > there are going to be cases where i still have to annotate the actual
> > symbol export in code (for windows).
Versioning a symbol means you are exporting it, is it not that simple?
So I don't see the need for annotating about symbol visibility.
> >
> > just thought a more unified approach for all might appeal.
>
> Assuming that we truly want DPDK to support Windows, a more unified approach
> is a reasonable ask.
>
> If we can eliminate the technical obstacles, we should pursue it.
IIUC, we still need a "default" version script, as the linker needs
one to declare version nodes, and so we have a catch all for
unversioned symbols.
$ cat symver.c
__attribute__ ((__symver__ ("api1@DPDK_23")))
int old_api1(void) { return 0; }
__attribute__ ((__symver__ ("api1@@DPDK_24")))
int api1(void) { return 0; }
__attribute__ ((__symver__ ("api2@@DPDK_24")))
int api2(void) { return 0; }
int api3(void) { return 0; }
$ cat symver.map
DPDK_23 { };
DPDK_24 { };
EXPERIMENTAL { };
INTERNAL {
local: *;
};
$ gcc -o symver.o -fPIC -Wall -Werror -c symver.c && gcc -o
libsymver.so -shared -fPIC -Wl,--version-script symver.map symver.o &&
readelf -s libsymver.so | grep api
5: 110411 FUNCGLOBAL DEFAULT 13 api1@@DPDK_24
7: 10f911 FUNCGLOBAL DEFAULT 13 api1@DPDK_23
9: 110f11 FUNCGLOBAL DEFAULT 13 api2@@DPDK_24
13: 10f911 FUNCLOCAL DEFAULT 13 old_api1
15: 110411 FUNCLOCAL DEFAULT 13 api1
16: 111a11 FUNCLOCAL DEFAULT 13 api3
19: 110f11 FUNCLOCAL DEFAULT 13 api2
24: 110411 FUNCGLOBAL DEFAULT 13 api1@@DPDK_24
29: 10f911 FUNCGLOBAL DEFAULT 13 api1@DPDK_23
31: 110f11 FUNCGLOBAL DEFAULT 13 api2@@DPDK_24
>
> We may have to sacrifice some "nice to have" advantages of the version.map
> files along the way, such as having easy access to the list of experimental
> functions in the version.map file.
Developers lose the single location for versioning information, but we
already have some scripts to help list symbols from a given version.
We may have to enhance them.
But I don't think we would lose features.
The devil is probably in the details, though :-).
--
David Marchand
[PATCH v3 0/3] ethdev: add RTE_FLOW_ITEM_TYPE_COMPARE
The new item type is added for the case user wants to match traffic based on packet field compare result with other fields or immediate value. e.g. take advantage the compare item user will be able to accumulate a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag register, then compare the tag register with IPv4 header total length to understand the packet has payload or not. The supported operations can be as below: - RTE_FLOW_ITEM_COMPARE_EQ (equal) - RTE_FLOW_ITEM_COMPARE_NE (not equal) - RTE_FLOW_ITEM_COMPARE_LT (less than) - RTE_FLOW_ITEM_COMPARE_LE (less than or equal) - RTE_FLOW_ITEM_COMPARE_GT (great than) - RTE_FLOW_ITEM_COMPARE_GE (great than or equal) V3: - fix code style missing empty line in rte_flow.rst. - fix missing the ABI change release notes. V2: - Since modify field data struct is experiment, rename modify field data directly instead of adding new flow field struct. Suanming Mou (3): ethdev: rename action modify field data structure ethdev: add compare item net/mlx5: add compare item support app/test-pmd/cmdline_flow.c | 416 +++- doc/guides/nics/features/default.ini| 1 + doc/guides/nics/features/mlx5.ini | 1 + doc/guides/nics/mlx5.rst| 7 + doc/guides/prog_guide/rte_flow.rst | 9 +- doc/guides/rel_notes/release_24_03.rst | 8 +- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 + drivers/net/mlx5/mlx5_flow.c| 4 +- drivers/net/mlx5/mlx5_flow.h| 9 +- drivers/net/mlx5/mlx5_flow_dv.c | 10 +- drivers/net/mlx5/mlx5_flow_hw.c | 73 lib/ethdev/rte_flow.c | 1 + lib/ethdev/rte_flow.h | 326 --- 13 files changed, 703 insertions(+), 169 deletions(-) -- 2.34.1
[PATCH v3 1/3] ethdev: rename action modify field data structure
Current rte_flow_action_modify_data struct describes the pkt
field perfectly and is used only in action.
It is planned to be used for item as well. This commit renames
it to "rte_flow_field_data" making it compatible to be used by item.
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
Acked-by: Andrew Rybchenko
---
app/test-pmd/cmdline_flow.c| 2 +-
doc/guides/prog_guide/rte_flow.rst | 2 +-
doc/guides/rel_notes/release_24_03.rst | 1 +
drivers/net/mlx5/mlx5_flow.c | 4 ++--
drivers/net/mlx5/mlx5_flow.h | 6 +++---
drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
lib/ethdev/rte_flow.h | 8
7 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index ce71818705..3725e955c7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -740,7 +740,7 @@ enum index {
#define ITEM_RAW_SIZE \
(sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
-/** Maximum size for external pattern in struct rte_flow_action_modify_data. */
+/** Maximum size for external pattern in struct rte_flow_field_data. */
#define ACTION_MODIFY_PATTERN_SIZE 32
/** Storage size for struct rte_flow_action_modify_field including pattern. */
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 627b845bfb..bf25c849fb 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3171,7 +3171,7 @@ destination offset as ``48``, and provide immediate value
``0x85XX``.
| ``width`` | number of bits to use |
+---+-+
-.. _table_rte_flow_action_modify_data:
+.. _table_rte_flow_field_data:
.. table:: destination/source field definition
diff --git a/doc/guides/rel_notes/release_24_03.rst
b/doc/guides/rel_notes/release_24_03.rst
index 2c0e2930cc..a691e794f4 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -106,6 +106,7 @@ ABI Changes
* No ABI change that would break compatibility with 23.11.
+* ethdev: Rename the experimental ``struct rte_flow_action_modify_data`` to be
``struct rte_flow_field_data``
Known Issues
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 85e8c77c81..5788a7fb57 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2493,7 +2493,7 @@ mlx5_validate_action_ct(struct rte_eth_dev *dev,
* Validate the level value for modify field action.
*
* @param[in] data
- * Pointer to the rte_flow_action_modify_data structure either src or dst.
+ * Pointer to the rte_flow_field_data structure either src or dst.
* @param[out] error
* Pointer to error structure.
*
@@ -2501,7 +2501,7 @@ mlx5_validate_action_ct(struct rte_eth_dev *dev,
* 0 on success, a negative errno value otherwise and rte_errno is set.
*/
int
-flow_validate_modify_field_level(const struct rte_flow_action_modify_data
*data,
+flow_validate_modify_field_level(const struct rte_flow_field_data *data,
struct rte_flow_error *error)
{
if (data->level == 0)
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 120609c595..8e2034473c 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1121,7 +1121,7 @@ flow_items_to_tunnel(const struct rte_flow_item items[])
* Tag array index.
*/
static inline uint8_t
-flow_tag_index_get(const struct rte_flow_action_modify_data *data)
+flow_tag_index_get(const struct rte_flow_field_data *data)
{
return data->tag_index ? data->tag_index : data->level;
}
@@ -2523,7 +2523,7 @@ int mlx5_flow_validate_action_default_miss(uint64_t
action_flags,
const struct rte_flow_attr *attr,
struct rte_flow_error *error);
int flow_validate_modify_field_level
- (const struct rte_flow_action_modify_data *data,
+ (const struct rte_flow_field_data *data,
struct rte_flow_error *error);
int mlx5_flow_item_acceptable(const struct rte_flow_item *item,
const uint8_t *mask,
@@ -2828,7 +2828,7 @@ size_t flow_dv_get_item_hdr_len(const enum
rte_flow_item_type item_type);
int flow_dv_convert_encap_data(const struct rte_flow_item *items, uint8_t *buf,
size_t *size, struct rte_flow_error *error);
void mlx5_flow_field_id_to_modify_info
- (const struct rte_flow_action_modify_data *data,
+ (const struct rte_flow_field_data *data,
struct field_modify_info *info, uint32_t *mask,
uint32_t width, struct rte_eth_dev *dev,
const struct rte_flow_attr *attr, struct rte_flow_error
*error);
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
[PATCH v3 3/3] net/mlx5: add compare item support
The compare item allows adding flow match with comparison
result. This commit adds compare item support to the PMD
code.
Due to HW limitation:
- Only HWS supported.
- Only 32-bit comparison is supported.
- Only single compare flow is supported in the flow table.
- Only match with compare result between packet fields is
supported.
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
---
doc/guides/nics/features/mlx5.ini | 1 +
doc/guides/nics/mlx5.rst | 7 +++
doc/guides/rel_notes/release_24_03.rst | 2 +-
drivers/net/mlx5/mlx5_flow.h | 3 ++
drivers/net/mlx5/mlx5_flow_hw.c| 73 ++
5 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/doc/guides/nics/features/mlx5.ini
b/doc/guides/nics/features/mlx5.ini
index 0739fe9d63..00e9348fc6 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -56,6 +56,7 @@ Usage doc= Y
[rte_flow items]
aggr_affinity= Y
+compare = Y
conntrack= Y
ecpri= Y
esp = Y
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 7bfd6c6aeb..1bb7d0665d 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -780,6 +780,13 @@ Limitations
The flow engine of a process cannot move from active to standby mode
if preceding active application rules are still present and vice versa.
+- Match with compare result item (``RTE_FLOW_ITEM_TYPE_COMPARE``):
+
+ - Only supported in HW steering(``dv_flow_en`` = 2) mode.
+ - Only single flow is supported to the flow table.
+ - Only 32-bit comparison is supported.
+ - Only match with compare result between packet fields is supported.
+
Statistics
--
diff --git a/doc/guides/rel_notes/release_24_03.rst
b/doc/guides/rel_notes/release_24_03.rst
index 8c8c661218..ef9c5d55a1 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -63,7 +63,7 @@ New Features
* **Updated NVIDIA mlx5 driver.**
* Added support for accumulating from src field to dst field.
-
+ * Added support for comparing result between packet fields or value.
Removed Items
-
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 8e2034473c..6698de2a3e 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -277,6 +277,9 @@ enum mlx5_feature_name {
/* NSH ITEM */
#define MLX5_FLOW_ITEM_NSH (1ull << 53)
+/* COMPARE ITEM */
+#define MLX5_FLOW_ITEM_COMPARE (1ull << 54)
+
/* Outer Masks. */
#define MLX5_FLOW_LAYER_OUTER_L3 \
(MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index c4a90a3690..82d7fa006f 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -426,6 +426,9 @@ flow_hw_matching_item_flags_get(const struct rte_flow_item
items[])
case RTE_FLOW_ITEM_TYPE_GTP:
last_item = MLX5_FLOW_LAYER_GTP;
break;
+ case RTE_FLOW_ITEM_TYPE_COMPARE:
+ last_item = MLX5_FLOW_ITEM_COMPARE;
+ break;
default:
break;
}
@@ -4390,6 +4393,8 @@ flow_hw_table_create(struct rte_eth_dev *dev,
rte_errno = EINVAL;
goto it_error;
}
+ if (item_templates[i]->item_flags & MLX5_FLOW_ITEM_COMPARE)
+ matcher_attr.mode = MLX5DR_MATCHER_RESOURCE_MODE_HTABLE;
ret = __atomic_fetch_add(&item_templates[i]->refcnt, 1,
__ATOMIC_RELAXED) + 1;
if (ret <= 1) {
@@ -6670,6 +6675,66 @@ flow_hw_prepend_item(const struct rte_flow_item *items,
return copied_items;
}
+static inline bool
+flow_hw_item_compare_field_supported(enum rte_flow_field_id field)
+{
+ switch (field) {
+ case RTE_FLOW_FIELD_TAG:
+ case RTE_FLOW_FIELD_META:
+ case RTE_FLOW_FIELD_VALUE:
+ return true;
+ default:
+ break;
+ }
+ return false;
+}
+
+static int
+flow_hw_validate_item_compare(const struct rte_flow_item *item,
+ struct rte_flow_error *error)
+{
+ const struct rte_flow_item_compare *comp_m = item->mask;
+ const struct rte_flow_item_compare *comp_v = item->spec;
+
+ if (unlikely(!comp_m))
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL,
+ "compare item mask is missing");
+ if (comp_m->width != UINT32_MAX)
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+
[PATCH v3 2/3] ethdev: add compare item
The new item type is added for the case user wants to match traffic
based on packet field compare result with other fields or immediate
value.
e.g. take advantage the compare item user will be able to accumulate
a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag
register, then compare the tag register with IPv4 header total length
to understand the packet has payload or not.
The supported operations can be as below:
- RTE_FLOW_ITEM_COMPARE_EQ (equal)
- RTE_FLOW_ITEM_COMPARE_NE (not equal)
- RTE_FLOW_ITEM_COMPARE_LT (less than)
- RTE_FLOW_ITEM_COMPARE_LE (less than or equal)
- RTE_FLOW_ITEM_COMPARE_GT (great than)
- RTE_FLOW_ITEM_COMPARE_GE (great than or equal)
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
Acked-by: Andrew Rybchenko
---
app/test-pmd/cmdline_flow.c | 414 +++-
doc/guides/nics/features/default.ini| 1 +
doc/guides/prog_guide/rte_flow.rst | 7 +
doc/guides/rel_notes/release_24_03.rst | 5 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 322 ---
7 files changed, 603 insertions(+), 154 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 3725e955c7..4f448ff8ec 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -543,6 +543,28 @@ enum index {
ITEM_PTYPE,
ITEM_PTYPE_VALUE,
ITEM_NSH,
+ ITEM_COMPARE,
+ ITEM_COMPARE_OP,
+ ITEM_COMPARE_OP_VALUE,
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_A_TYPE_VALUE,
+ ITEM_COMPARE_FIELD_A_LEVEL,
+ ITEM_COMPARE_FIELD_A_LEVEL_VALUE,
+ ITEM_COMPARE_FIELD_A_TAG_INDEX,
+ ITEM_COMPARE_FIELD_A_TYPE_ID,
+ ITEM_COMPARE_FIELD_A_CLASS_ID,
+ ITEM_COMPARE_FIELD_A_OFFSET,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_COMPARE_FIELD_B_TYPE_VALUE,
+ ITEM_COMPARE_FIELD_B_LEVEL,
+ ITEM_COMPARE_FIELD_B_LEVEL_VALUE,
+ ITEM_COMPARE_FIELD_B_TAG_INDEX,
+ ITEM_COMPARE_FIELD_B_TYPE_ID,
+ ITEM_COMPARE_FIELD_B_CLASS_ID,
+ ITEM_COMPARE_FIELD_B_OFFSET,
+ ITEM_COMPARE_FIELD_B_VALUE,
+ ITEM_COMPARE_FIELD_B_POINTER,
+ ITEM_COMPARE_FIELD_WIDTH,
/* Validate/create actions. */
ACTIONS,
@@ -740,13 +762,17 @@ enum index {
#define ITEM_RAW_SIZE \
(sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
+static const char *const compare_ops[] = {
+ "eq", "ne", "lt", "le", "gt", "ge", NULL
+};
+
/** Maximum size for external pattern in struct rte_flow_field_data. */
-#define ACTION_MODIFY_PATTERN_SIZE 32
+#define FLOW_FIELD_PATTERN_SIZE 32
/** Storage size for struct rte_flow_action_modify_field including pattern. */
#define ACTION_MODIFY_SIZE \
(sizeof(struct rte_flow_action_modify_field) + \
- ACTION_MODIFY_PATTERN_SIZE)
+ FLOW_FIELD_PATTERN_SIZE)
/** Maximum number of queue indices in struct rte_flow_action_rss. */
#define ACTION_RSS_QUEUE_NUM 128
@@ -940,7 +966,7 @@ static const char *const modify_field_ops[] = {
"set", "add", "sub", NULL
};
-static const char *const modify_field_ids[] = {
+static const char *const flow_field_ids[] = {
"start", "mac_dst", "mac_src",
"vlan_type", "vlan_id", "mac_type",
"ipv4_dscp", "ipv4_ttl", "ipv4_src", "ipv4_dst",
@@ -1590,6 +1616,7 @@ static const enum index next_item[] = {
ITEM_IB_BTH,
ITEM_PTYPE,
ITEM_NSH,
+ ITEM_COMPARE,
END_SET,
ZERO,
};
@@ -2121,6 +2148,38 @@ static const enum index item_nsh[] = {
ZERO,
};
+static const enum index item_compare_field[] = {
+ ITEM_COMPARE_OP,
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index compare_field_a[] = {
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_A_LEVEL,
+ ITEM_COMPARE_FIELD_A_TAG_INDEX,
+ ITEM_COMPARE_FIELD_A_TYPE_ID,
+ ITEM_COMPARE_FIELD_A_CLASS_ID,
+ ITEM_COMPARE_FIELD_A_OFFSET,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ZERO,
+};
+
+static const enum index compare_field_b[] = {
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_COMPARE_FIELD_B_LEVEL,
+ ITEM_COMPARE_FIELD_B_TAG_INDEX,
+ ITEM_COMPARE_FIELD_B_TYPE_ID,
+ ITEM_COMPARE_FIELD_B_CLASS_ID,
+ ITEM_COMPARE_FIELD_B_OFFSET,
+ ITEM_COMPARE_FIELD_B_VALUE,
+ ITEM_COMPARE_FIELD_B_POINTER,
+ ITEM_COMPARE_FIELD_WIDTH,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -2863,6 +2922,24 @@ comp_quota_update_name(struct context *ctx, const struct
token *token,
static int
comp_qu_mode_name(struct context *ctx, const struct token *token,
unsigned int ent, char *buf, unsigned int size);
+static int
+comp_set_compare_field_id(struct context *ctx, const struct t
Re: [PATCH v3] dts: add Dockerfile
On Fri, Jan 12, 2024 at 3:59 PM Jeremy Spewock wrote:
>
>
>
> On Fri, Jan 12, 2024 at 5:23 AM Juraj Linkeš
> wrote:
>>
>> > diff --git a/dts/.devcontainer/devcontainer.json
>> > b/dts/.devcontainer/devcontainer.json
>> > new file mode 100644
>> > index 00..6313cd3ded
>> > --- /dev/null
>> > +++ b/dts/.devcontainer/devcontainer.json
>> > @@ -0,0 +1,33 @@
>> > +// For format details, see https://aka.ms/devcontainer.json. For config
>> > options, see the README at:
>> > +//
>> > https://github.com/microsoft/vscode-dev-containers/tree/v0.241.1/containers/docker-existing-dockerfile
>> > +{
>> > + "name": "Existing Dockerfile",
>> > +
>> > + // Sets the run context to one level up instead of the
>> > .devcontainer folder.
>> > + "context": "..",
>> > +
>> > + // Update the 'dockerFile' property if you aren't using the
>> > standard 'Dockerfile' filename.
>> > + "dockerFile": "../Dockerfile",
>> > +
>> > + // Use 'forwardPorts' to make a list of ports inside the container
>> > available locally.
>> > + // "forwardPorts": [],
>> > +
>> > + // Uncomment the next line to run commands after the container is
>> > created - for example installing curl.
>>
>> The next line is uncommented, we should update or remove the comment.
>
>
> Good catch, I'll change this.
>
>>
>>
>> > + "postCreateCommand": "poetry install --no-root",
>> > +
>> > + "extensions": [
>> > + "ms-python.vscode-pylance",
>> > + ]
>> > +
>> > + // Uncomment when using a ptrace-based debugger like C++, Go, and
>> > Rust
>> > + // "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt",
>> > "seccomp=unconfined" ],
>> > +
>> > + // Uncomment to use the Docker CLI from inside the container. See
>> > https://aka.ms/vscode-remote/samples/docker-from-docker.
>> > + // "mounts": [
>> > "source=/var/run/docker.sock,target=/var/run/docker.sock,type=bind" ],
>> > +
>> > + // Uncomment to mount your SSH keys into the devcontainer used by
>> > vscode.
>> > + // "mounts":
>> > ["source=${localEnv:HOME}/.ssh,destination=/root/.ssh,type=bind,readonly"]
>>
>> Should this SSH key correspond to the user below?
>
>
> On one hand I agree it would be better to unify the two options, but on the
> other we don't make a remote user in the docker image so the option below
> can't be used anyway. I would be more in favor of just removing the
> remoteUser option and leaving this the way it is as that would line up better
> with what you can actually do with the container image we provide.
>
> Leaving it as a stub for something that could be done isn't a bad either
> though, or I could also add the remote user to the container, but I don't
> really see the need for a non-root user for running DTS currently.
>
Thanks for the explanation. As there is no need for it and adding
things that could be done (in other tools) seems out of scope to me,
let's remove it.
>>
>>
>> > +
>> > + // Uncomment to connect as a non-root user if you've added one.
>> > See https://aka.ms/vscode-remote/containers/non-root.
>> > + // "remoteUser": "vscode"
>> > +}
>>
>>
>>
>> > diff --git a/dts/README.md b/dts/README.md
>> > new file mode 100644
>> > index 00..dc88ec585e
>> > --- /dev/null
>> > +++ b/dts/README.md
>> > @@ -0,0 +1,70 @@
>>
>> > + Start docker container with SSH keys
>> > +
>> > +```shell
>> > +docker build --target dev -t dpdk-dts .
>> > +docker run -v $(pwd)/..:/dpdk -v /home/dtsuser/.ssh:/root/.ssh:ro -it
>> > dpdk-dts bash
>>
>> We talked about possibly baking the key into the image, but this seems
>> safer and pretty easy to use.
>> I understand this is tailored to the lab and I'm thinking about other
>> possible use cases, but it seems there would only be convoluted ones
>> (possibly with some extra security considerations, which is generally
>> not needed for testing purposes) where this doesn't do what we want it
>> to. I'd say this is good enough.
>>
>>
>> > +$ poetry install
>> > +$ poetry shell
>> > +```
>> > +
Re: [PATCH] dts: improve documentation
On Fri, Jan 12, 2024 at 6:16 PM Luca Vizzarro wrote: > > Hi Juraj, > > Thank you for your review! > > On 12/01/2024 13:24, Juraj Linkeš wrote: > > I have two extra suggestions apart from the comments below: > > There's a typo inside the "How To Write a Test Suite" section: > > In that case, nothing will happen when they're is executed. > > > > And Mypy is missing from the list of linters in the "DTS Developer > > Tools" section, could you please add it? > > Ack. > > > Just out of curiosity, is this generated from the schema? It's a > > pretty neat format, but maintaining it could be a nightmare without a > > script that would always produce the same format. > > I originally found only one tool that would generate rst. The generated > output was quite messy though. Only after hacking its few configuration > options and the schema, it produced something decent. But as it is only > available on pip and it would have to become a DPDK docs requirement to > generate them, it wouldn't be acceptable. > This wouldn't need to be a hard requirement. It could just be a tool that submitters could use as a starting point (which they would optionally install and use). > Unless someone comes up with a good tool that could match our needs, > unfortunately manual work is the only solution for the time being...and > I won't deny it took me a bit of time to format it. The only major > problem is all the extra whitespaces and the alignment of the columns > needed to make sphinx happy. Once most of the work is done though – as > it is in this case, changing it from there shouldn't be too bad. > Alright, I hope people won't be too frustrated with it. :-) But it's likely the section is not going to be changed that much so it's not a big deal. > > The section names look to be taken from the schema and all of the > > terminology is taken from the schema. Would it make sense to use YAML > > terminology here, since people will try to use this information in > > YAML files? Or maybe explain what we mean by definitions, properties, > > objects, arrays or maybe some other things which YAML doesn't specify. > > I understand your point of view. I had a quick look at the YAML glossary > and I think it may be a lot more confusing than using generic software > engineering terminology. Also we may not want to be constrained to YAML. > > The YAML glossary refers to what we would call dictionary in Python and > objects in JSON as mappings. And arrays and lists as sequences. Maybe > changing array to list could be a good idea. Objects instead is > something I don't personally like either. I took it from the JSON schema > to rst generator tool, as I am not sure what fits best here. > I like mappings [0] and sequences [1], as that is the standard Python terminology. [0] https://docs.python.org/3/library/stdtypes.html#mapping-types-dict [1] https://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range > I welcome suggestions to change specific terms. On the other hand, I am > not so sure about explaining them as it is out of scope. Moreover, the > configuration template should cover all of the scenarios, so one can > also infer usage from there. > One more thing to like about mappings and sequences, we don't (or shouldn't) have to explain those. I think those would work fine on both fronts. > > We should update "amount" (uncountable) to something that's countable, > > such as count or number. > > Ack. > > > Of note here is that some traffic generators (to which the port config > > also applies) won't be using os_driver_for_dpdk (such as Scapy), but > > rather os_driver, so the use is broader. > > Ack. Thanks for the explanation, makes sense. > > > The last newline is missing. > > Ack. > > > Let's keep the note that the skip_smoke_tests flag is optional > > Ack. > > > The traffic generator may need this core configuration. However, since > > it's not required for all traffic generators (such as Scapy), we could > > just move to the traffic_generator section. That would require some > > code modifications though, but even the removal of lcores and > > use_first_core should be addressed in the configuration classes as > > well. Have you tried running DTS with these changes? > > Please correct me if I'm wrong. At the current state of DTS it seems > that these two properties are only used with DPDK. If this is correct, > it may be misleading to the user to add them for the traffic generator > node, hinting that they may make a difference when they don't. > That's right, it's only used in DPDK. > It would definitely makes sense to have dedicated properties for DPDK > and for the traffic generators, instead of common ones. The dedicated DPDK/TG properties look like the way to go, it just makes sense. > But this is > possibly more of a concern when and if support for other traffic > generators will be added in the future. > We'll need to add support for at least one traffic generator that's suitable for performance testing
[Bug 1365] DTS: add support for externally compiled DPDK
https://bugs.dpdk.org/show_bug.cgi?id=1365 Bug ID: 1365 Summary: DTS: add support for externally compiled DPDK Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: dts Assignee: dev@dpdk.org Reporter: juraj.lin...@pantheon.tech CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu Target Milestone: --- We currently accept either a DPDK tarball with sources or a git refspec. Both of these approaches result in DTS compiling DPDK on the SUT node. What we're missing is accepting a pre-compiled DPDK tree. In that case, we won't do any compilation on the SUT node, we'll just copy the DPDK tree to the SUT node. -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH v4 2/4] baseband/fpga_5gnr_fec: add Vista Creek variant
On 1/5/24 22:15, Hernan Vargas wrote: Create a new file vc_5gnr_pmd.h to store structures and macros specific to Vista Creek 5G FPGA implementation and rename functions specific to the Vista Creek variant. Signed-off-by: Hernan Vargas --- .../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 183 ++- .../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 475 +- drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h | 140 ++ 3 files changed, 398 insertions(+), 400 deletions(-) create mode 100644 drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h Reviewed-by: Maxime Coquelin Thanks, Maxime
Re: [PATCH] bus/uacce: introduce UACCE bus
Hi Huisong,
On 2024/1/15 16:14, lihuisong (C) wrote:
> Hi chengwen,
>
> lgtm,
> with below to changes,
> Acked-by: Huisong Li
>
>
> 在 2023/12/8 14:18, Chengwen Feng 写道:
>> UACCE (Unified/User-space-access-intended Accelerator Framework) was
>> upstream to Linux kernel version 5.7, and it targets to provide Shared
>> Virtual Addressing (SVA) between accelerators and processes. So
>> accelerator can access any data structure of the main cpu. [1] for more
>> information.
>>
>> This commit introduces UACCE bus, so that the accelerator devices could
>> seen at DPDK and could be further registered as a compress, crypto, dma
>> and ethdev device.
>>
>> [1] https://docs.kernel.org/misc-devices/uacce.html
>>
>> Signed-off-by: Chengwen Feng
>> ---
>> MAINTAINERS | 4 +
>> drivers/bus/meson.build | 1 +
>> drivers/bus/uacce/bus_uacce_driver.h | 254 ++
>> drivers/bus/uacce/meson.build | 12 +
>> drivers/bus/uacce/uacce.c | 702 +++
>> drivers/bus/uacce/version.map | 15 +
>> 6 files changed, 988 insertions(+)
>> create mode 100644 drivers/bus/uacce/bus_uacce_driver.h
>> create mode 100644 drivers/bus/uacce/meson.build
>> create mode 100644 drivers/bus/uacce/uacce.c
>> create mode 100644 drivers/bus/uacce/version.map
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0d1c8126e3..89711029d5 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -604,6 +604,10 @@ Platform bus driver
>> M: Tomasz Duszynski
>> F: drivers/bus/platform/
>> +UACCE bus driver
>> +M: Chengwen Feng
>> +F: drivers/bus/uacce/
>> +
>> VDEV bus driver
>> F: drivers/bus/vdev/
>> F: app/test/test_vdev.c
>> diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
>> index a78b4283bf..d67db8576b 100644
>> --- a/drivers/bus/meson.build
>> +++ b/drivers/bus/meson.build
>> @@ -9,6 +9,7 @@ drivers = [
>> 'ifpga',
>> 'pci',
>> 'platform',
>> + 'uacce',
>> 'vdev',
>> 'vmbus',
>> ]
>> diff --git a/drivers/bus/uacce/bus_uacce_driver.h
>> b/drivers/bus/uacce/bus_uacce_driver.h
>> new file mode 100644
>> index 00..0276154658
>> --- /dev/null
>> +++ b/drivers/bus/uacce/bus_uacce_driver.h
>> @@ -0,0 +1,254 @@
>> +/* SPDX-License-Identifier: BSD-3-Clause
>> + * Copyright(c) 2023 HiSilicon Limited
>> + */
>> +
>> +#ifndef BUS_UACCE_DRIVER_H
>> +#define BUS_UACCE_DRIVER_H
>> +
>> +/**
>> + * @file
>> + *
>> + * HiSilicon UACCE bus interface.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif /* __cplusplus */
>> +
>> +#define RTE_UACCE_DEV_PATH_SIZE 256
>> +#define RTE_UACCE_API_NAME_SIZE 64
>> +#define RTE_UACCE_ALGS_NAME_SIZE 384
>> +#define RTE_UACCE_ATTR_MAX_SIZE 384
>> +
>> +/*
>> + * Definition for queue file region type.
>> + */
>> +enum rte_uacce_qfrt {
>> + RTE_UACCE_QFRT_MMIO = 0, /**< Device mmio region. */
>> + RTE_UACCE_QFRT_DUS, /**< Device user share region. */
>> + RTE_UACCE_QFRT_BUTT
>> +};
>> +
>> +struct rte_uacce_driver;
>> +
>> +/**
>> + * A structure describing a UACCE device.
>> + */
>> +struct rte_uacce_device {
>> + RTE_TAILQ_ENTRY(rte_uacce_device) next; /**< Next in device list. */
>> + struct rte_device device; /**< Inherit core device. */
>> + struct rte_uacce_driver *driver; /**< Driver used in probing. */
>> + char name[RTE_DEV_NAME_MAX_LEN]; /**< Device name. */
>> + char dev_root[RTE_UACCE_DEV_PATH_SIZE]; /**< Sysfs path with device
>> name. */
>> + char cdev_path[RTE_UACCE_DEV_PATH_SIZE]; /**< Device path in devfs. */
>> + char api[RTE_UACCE_API_NAME_SIZE]; /**< Device context type. */
>> + char algs[RTE_UACCE_ALGS_NAME_SIZE]; /**< Device supported
>> algorithms. */
>> + uint32_t flags; /**< Device flags. */
>> + int numa_node; /**< NUMA node connection, -1
>> if unknown. */
>> + uint32_t qfrt_sz[RTE_UACCE_QFRT_BUTT]; /**< Queue file region type's
>> size. */
>> +};
>> +
>> +/**
>> + * @internal
>> + * Helper macro for drivers that need to convert to struct rte_uacce_device.
>> + */
>> +#define RTE_DEV_TO_UACCE_DEV(ptr) \
>> + container_of(ptr, struct rte_uacce_device, device)
>> +
>> +#define RTE_DEV_TO_UACCE_DEV_CONST(ptr) \
>> + container_of(ptr, const struct rte_uacce_device, device)
>> +
>> +/**
>> + * A structure describing an ID for a UACCE driver. Each driver provides a
>> + * table of these IDs for each device that it supports.
>> + */
>> +struct rte_uacce_id {
>> + const char *dev_api; /**< Device context type. */
>> + /** Device algorithm.
>> + * If this field is NULL, only dev_api is matched. Otherwise, in
>> + * addition to match dev_api, dev_alg must be a subset of device's
>> + * algs.
>> + */
>> + const
Re: [PATCH] dts: improve documentation
On 15/01/2024 09:36, Juraj Linkeš wrote: This wouldn't need to be a hard requirement. It could just be a tool that submitters could use as a starting point (which they would optionally install and use). Sorry, forgot to mention that the tool is actually a sphinx plugin, which is used through directives in the doc pages. It doesn't actually generate rst, but rather renders tables when running sphinx-build. Otherwise, yeah, it would have been feasible. I like mappings [0] and sequences [1], as that is the standard Python terminology. Ack. Sounds good to me. I could also add these links for reference. One more thing to like about mappings and sequences, we don't (or shouldn't) have to explain those. I think those would work fine on both fronts.
[PATCH] net/mlx5/hws: fix ESP matching validation
The "mlx5dr_definer_conv_item_esp()" function validates first whether
"ipsec_offload" PRM flag is on, if the flag is off the function returns
error.
The "ipsec_offload" PRM flag indicates whether IPsec encrypt/decrypt is
supported, IPsec matching may be supported even when this flag is off.
This patch removes this validation.
Fixes: 81cf20a25abf ("net/mlx5/hws: support match on ESP item")
Cc: hamd...@nvidia.com
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Hamdan Igbaria
Acked-by: Matan Azrad
---
drivers/net/mlx5/hws/mlx5dr_definer.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 0b60479406..7bd4ea560e 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -2240,11 +2240,6 @@ mlx5dr_definer_conv_item_esp(struct
mlx5dr_definer_conv_data *cd,
const struct rte_flow_item_esp *m = item->mask;
struct mlx5dr_definer_fc *fc;
- if (!cd->ctx->caps->ipsec_offload) {
- rte_errno = ENOTSUP;
- return rte_errno;
- }
-
if (!m)
return 0;
if (m->hdr.spi) {
--
2.25.1
[PATCH] net/mlx5: fix GENEVE TLV option management
In SW steering, the GENEVE TLV option matching flows must be created
using a translation function.
This function checks whether this option has already created a DevX
object for the matching and either creates the objects or updates the
reference counter.
After translation, a flag in flow structure is turned on indicating the
destroy function to release this DevX object.
When the flow rule has meter, the rule may be split, and call translate
function more than once per flow causing object reference counter to
increase each time without updating the flow flag accordingly.
This patch uses this flag as a reference counter which is increased
every translation and indicates the destroy function how many destroy
DevX to do.
Fixes: f15f0c3806d0 ("net/mlx5: create GENEVE TLV option management")
Fixes: e440d6cf589e ("net/mlx5: add GENEVE TLV option flow translation")
Cc: shi...@nvidia.com
Cc: sta...@dpdk.org
Signed-off-by: Michael Baum
Acked-by: Matan Azrad
---
drivers/net/mlx5/mlx5_flow_dv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 97f55003c3..7cc1729145 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -14318,7 +14318,7 @@ flow_dv_translate_items_sws(struct rte_eth_dev *dev,
* Avoid be overwritten by other sub mlx5_flows.
*/
if (wks.geneve_tlv_option)
- dev_flow->flow->geneve_tlv_option = wks.geneve_tlv_option;
+ dev_flow->flow->geneve_tlv_option += wks.geneve_tlv_option;
return 0;
}
@@ -15922,9 +15922,9 @@ flow_dv_destroy(struct rte_eth_dev *dev, struct
rte_flow *flow)
flow_dv_aso_ct_release(dev, flow->ct, NULL);
else if (flow->age)
flow_dv_aso_age_release(dev, flow->age);
- if (flow->geneve_tlv_option) {
+ while (flow->geneve_tlv_option) {
flow_dev_geneve_tlv_option_resource_release(priv->sh);
- flow->geneve_tlv_option = 0;
+ flow->geneve_tlv_option--;
}
while (flow->dev_handles) {
uint32_t tmp_idx = flow->dev_handles;
--
2.25.1
[Bug 1366] mlx5 secondary testpmd process crash when calling rte_eth_stats_get
https://bugs.dpdk.org/show_bug.cgi?id=1366 Bug ID: 1366 Summary: mlx5 secondary testpmd process crash when calling rte_eth_stats_get Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: Normal Component: eventdev Assignee: dev@dpdk.org Reporter: ai...@peralex.com Target Milestone: --- Created attachment 271 --> https://bugs.dpdk.org/attachment.cgi?id=271&action=edit Secondary lldb process output Linux: AlmaLinux 9.3 Kernel: 5.14.0-362.8.1.el9_3.x86_64 Software version: rdma-core-48.0-1.el9.x86_64 dpdk-v22.11(tested on git branch v23.11-rc4 as well) Hardware: Mellanox Technologies MT27800 Family [ConnectX-5] Running two testpmd processes at the same time causes the secondary process to crash with a segmentation fault from the libmlx5.so library. Two ports on a Mellanox MT27800 card are configured to be used by both testpmd apps. The two separate instances are launched: 1. dpdk-testpmd --proc-type=primary 2. dpdk-testpmd --proc-type=secondary I am not sure if this is a rdma-core issue which contains the libmlx5.so library where segmentation fault is thrown from. The primary dpdk process runs without any issues and there are no segfaults. The rte_eth_stats_get function only throws an error on the secondary process, not on the primary process. Attached is the lldb output when running a debug build secondary process with lldb. Running dmesg also shows that there is a segfault: dpdk-testpmd[67695]: segfault at b077f90 ip 7f1ae42069e4 sp 7ffcd49903b8 error 4 in libmlx5.so.1.24.48.0[7f1ae41b5000+5a000] likely on CPU 0 (core 0, socket 0) Code: 77 90 0f b6 d2 48 8d 05 7a a3 00 00 44 0f be 24 10 e9 7c ff ff ff e8 fb f3 fa ff 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <48> 8b 07 49 89 d2 4c 8d 0d 4f 88 01 00 48 8b 10 48 8b 92 98 02 00 -- You are receiving this mail because: You are the assignee for the bug.
DPDK 21.11.6 released
Hi all, Here is a new stable release: https://fast.dpdk.org/rel/dpdk-21.11.6.tar.xz The git tree is at: https://dpdk.org/browse/dpdk-stable/?h=21.11 This LTS release contains ~200 fixes from main branch up to DPDK 23.11. Thanks to the authors who helped with backports and to the following who helped with validation: Nvidia, Red Hat and Intel. Kevin --- .mailmap | 14 +- VERSION|2 +- app/dumpcap/main.c | 28 +- app/proc-info/main.c | 42 +- app/test-bbdev/meson.build |2 +- app/test-bbdev/test-bbdev.py | 29 +- app/test-bbdev/test_bbdev.c|3 +- app/test-pipeline/main.c | 14 + app/test-pipeline/main.h |2 + app/test-pipeline/pipeline_acl.c |6 +- app/test-pipeline/pipeline_hash.c | 106 +- app/test-pipeline/pipeline_lpm.c |6 +- app/test-pipeline/pipeline_lpm_ipv6.c |6 +- app/test-pipeline/pipeline_stub.c |6 +- app/test-pipeline/runtime.c| 126 +- app/test-pmd/cmdline.c | 112 +- app/test-pmd/testpmd.c | 25 +- app/test/test_cryptodev.c |6 + app/test/test_cryptodev_asym.c |4 +- app/test/test_cryptodev_mixed_test_vectors.h |8 +- app/test/test_event_crypto_adapter.c |7 +- app/test/test_hash_readwrite.c |2 +- app/test/test_link_bonding.c |3 +- app/test/test_link_bonding_mode4.c |3 +- app/test/test_link_bonding_rssconf.c |2 +- config/arm/meson.build | 40 +- doc/guides/nics/hns3.rst | 55 +- doc/guides/nics/i40e.rst | 15 +- doc/guides/nics/ice.rst| 11 +- doc/guides/nics/ixgbe.rst |2 - doc/guides/nics/mlx5.rst |8 +- doc/guides/nics/virtio.rst | 12 + doc/guides/platform/cnxk.rst |3 + .../generic_segmentation_offload_lib.rst |2 +- doc/guides/prog_guide/rte_security.rst | 65 +- doc/guides/rel_notes/release_21_11.rst | 358 +++ doc/guides/sample_app_ug/vdpa.rst |3 +- drivers/baseband/acc100/rte_acc100_pmd.c |2 +- drivers/bus/dpaa/base/qbman/qman.c |5 +- drivers/bus/pci/pci_common.c |2 +- drivers/common/cnxk/cnxk_security_ar.h |2 +- drivers/common/cnxk/hw/nix.h |1 + drivers/common/cnxk/meson.build|1 - drivers/common/cnxk/roc_dpi.c |6 +- drivers/common/cnxk/roc_mbox.h |2 +- drivers/common/cnxk/roc_npa.c |8 +- drivers/common/cnxk/roc_npc.c | 17 +- drivers/common/cnxk/roc_npc_mcam_dump.c|4 + drivers/common/mlx5/linux/mlx5_common_os.c |5 +- drivers/crypto/ipsec_mb/meson.build|5 + drivers/crypto/nitrox/nitrox_sym_reqmgr.c | 21 +- drivers/crypto/qat/qat_sym.c |6 +- drivers/crypto/qat/qat_sym.h |2 + drivers/crypto/qat/qat_sym_hw_dp.c | 42 +- drivers/crypto/qat/qat_sym_pmd.c |5 + drivers/dma/cnxk/cnxk_dmadev.c |8 +- drivers/event/cnxk/cn10k_eventdev.c| 12 +- drivers/event/cnxk/cn9k_eventdev.c | 16 +- drivers/event/cnxk/cnxk_eventdev.c |2 +- drivers/event/cnxk/cnxk_eventdev.h |6 +- drivers/event/dlb2/dlb2.c |1 + drivers/event/dlb2/dlb2_selftest.c |4 +- drivers/event/dlb2/pf/dlb2_main.c | 27 + drivers/event/dpaa/dpaa_eventdev.c |6 +- drivers/event/dpaa2/dpaa2_eventdev.c |6 +- drivers/event/dsw/dsw_evdev.c |2 +- drivers/event/octeontx/ssovf_evdev.c |2 +- drivers/event/opdl/opdl_evdev.c|2 +- drivers/event/skeleton/skeleton_eventdev.c |6 +- drivers/event/sw/sw_evdev.c|2 +- drivers/event/sw/sw_evdev_scheduler.c | 19 +- drivers/mempool/cnxk/cn10k_mempool_ops.c |6 + drivers/net/af_packet/rte_eth_af_packet.c |9 + drivers/net/af_xdp/meson.build |8 + drivers/net/af_xdp/rte_eth_af_xdp.c
[PATCH v2 0/1] multiple representors in one device
Following series adds support to enable creation of multiple representors under one base device. There may be scenarios where port representors for multiple PFs or VFs under PF are required and all these representor ports created under a single pci device. Marvell CNXK port representor solution is designed around this scenario where all representors are backed by a single switch device. Earlier this change was implemented as part of the Marvell CNXK port representor series but after suggestions from Thomas we would like to propose these changes in common code. https://patches.dpdk.org/project/dpdk/patch/20231219174003.72901-25-hka...@marvell.com/#166785 V2: - Updated the multiple representor devarg pattern to list i.e. representor=[pf[0-1],pf2vf[1,2-3],[4-5]] - Introduced size of array as third argument to rte_eth_devargs_parse() to avoid array corruption - Squashed separate document patch Harman Kalra (1): ethdev: parsing multiple representor devargs string doc/guides/prog_guide/poll_mode_drv.rst | 4 +- .../prog_guide/switch_representation.rst | 1 + drivers/net/bnxt/bnxt_ethdev.c| 4 +- drivers/net/enic/enic_ethdev.c| 4 +- drivers/net/i40e/i40e_ethdev.c| 4 +- drivers/net/ice/ice_dcf_ethdev.c | 4 +- drivers/net/ixgbe/ixgbe_ethdev.c | 4 +- drivers/net/mlx5/linux/mlx5_os.c | 8 +- .../net/nfp/flower/nfp_flower_representor.c | 4 +- drivers/net/sfc/sfc_ethdev.c | 4 +- lib/ethdev/ethdev_driver.c| 105 +++--- lib/ethdev/ethdev_driver.h| 9 +- 12 files changed, 119 insertions(+), 36 deletions(-) -- 2.18.0
[PATCH v2 1/1] ethdev: parsing multiple representor devargs string
Adding support for parsing multiple representor devargs strings
passed to a PCI BDF. There may be scenario where port representors
for various PFs or VFs under PFs are required and all these are
representor ports shall be backed by single pci device. In such
case port representors can be created using devargs string:
,representor=[pf[0-1],pf2vf[1,2-3],[4-5]]
Signed-off-by: Harman Kalra
---
doc/guides/prog_guide/poll_mode_drv.rst | 4 +-
.../prog_guide/switch_representation.rst | 1 +
drivers/net/bnxt/bnxt_ethdev.c| 4 +-
drivers/net/enic/enic_ethdev.c| 4 +-
drivers/net/i40e/i40e_ethdev.c| 4 +-
drivers/net/ice/ice_dcf_ethdev.c | 4 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
drivers/net/mlx5/linux/mlx5_os.c | 8 +-
.../net/nfp/flower/nfp_flower_representor.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 4 +-
lib/ethdev/ethdev_driver.c| 105 +++---
lib/ethdev/ethdev_driver.h| 9 +-
12 files changed, 119 insertions(+), 36 deletions(-)
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
b/doc/guides/prog_guide/poll_mode_drv.rst
index c145a9066c..5008b41c60 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -376,7 +376,7 @@ parameters to those ports.
* ``representor`` for a device which supports the creation of representor ports
this argument allows user to specify which switch ports to enable port
- representors for. Multiple representors in one device argument is invalid::
+ representors for::
-a DBDF,representor=vf0
-a DBDF,representor=vf[0,4,6,9]
@@ -389,6 +389,8 @@ parameters to those ports.
-a DBDF,representor=pf1vf0
-a DBDF,representor=pf[0-1]sf[0-127]
-a DBDF,representor=pf1
+ -a DBDF,representor=[pf[0-1],pf2vf[0-2],pf3[3,5-8]]
+ (Multiple representors in one device argument can be represented as a list)
Note: PMDs are not required to support the standard device arguments and users
should consult the relevant PMD documentation to see support devargs.
diff --git a/doc/guides/prog_guide/switch_representation.rst
b/doc/guides/prog_guide/switch_representation.rst
index 6fd7b98bdc..46e0ca85a5 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -77,6 +77,7 @@ thought as a software "patch panel" front-end for
applications.
-a pci:dbdf,representor=sf1
-a pci:dbdf,representor=sf[0-1023]
-a pci:dbdf,representor=sf[0,2-1023]
+ -a pci:dbdf,representor=[pf[0-1],pf2vf[0-2],pf3[3,5]]
- As virtual devices, they may be more limited than their physical
counterparts, for instance by exposing only a subset of device
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index acf7e6e46e..5d4f599044 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -6383,8 +6383,8 @@ static int bnxt_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
if (pci_dev->device.devargs) {
ret = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (ret)
+ ð_da, 1);
+ if (ret < 0)
return ret;
}
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index b04b6c9aa1..33d96ec07a 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -1317,8 +1317,8 @@ static int eth_enic_pci_probe(struct rte_pci_driver
*pci_drv __rte_unused,
ENICPMD_FUNC_TRACE();
if (pci_dev->device.devargs) {
retval = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (retval)
+ ð_da, 1);
+ if (retval < 0)
return retval;
}
if (eth_da.nb_representor_ports > 0 &&
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 3ca226156b..4d21341382 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -646,8 +646,8 @@ eth_i40e_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
if (pci_dev->device.devargs) {
retval = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (retval)
+ ð_da, 1);
+ if (retval < 0)
return retval;
}
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 5d845bba31..0e991fe4b8 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -2041,8 +2041,8 @@ eth_ice_dcf_pci_probe(__rte_unused struct rte_pci_driver
*pci_drv,
if (!ice_devargs_check(pci_dev->devic
RE: [EXT] Re: [PATCH 1/2] ethdev: parsing multiple representor devargs string
Hi David Thanks for review Please find responses inline > -Original Message- > From: David Marchand > Sent: Friday, January 12, 2024 6:12 PM > To: Harman Kalra > Cc: Ajit Khaparde ; Somnath Kotur > ; John Daley ; > Hyong Youb Kim ; Yuying Zhang > ; Beilei Xing ; Qiming Yang > ; Qi Zhang ; Wenjun Wu > ; Dariusz Sosnowski ; > Viacheslav Ovsiienko ; Ori Kam > ; Suanming Mou ; Matan > Azrad ; Chaoyong He ; > Andrew Rybchenko ; Thomas Monjalon > ; Ferruh Yigit ; > dev@dpdk.org > Subject: [EXT] Re: [PATCH 1/2] ethdev: parsing multiple representor devargs > string > > External Email > > -- > On Thu, Jan 11, 2024 at 7:45 AM Harman Kalra > wrote: > > > > Adding support for parsing multiple representor devargs strings passed > > to a PCI BDF. There may be scenario where port representors for > > various PFs or VFs under PFs are required and all these are > > representor ports shall be backed by single pci device. In such case > > port representors can be created using devargs string: > > > BDF>,representor=pf[0-1],representor=pf2vf[1,2-3],representor=[4-5] > > Is it possible to make the representor devargs value a list? > Like: ,representor=[pf[0-1],pf2vf[1,2-3],[4-5]] Thanks for suggestion, even I was not so happy with repeated representor keywork. Please review the changes: https://patches.dpdk.org/project/dpdk/patch/20240115155715.54-2-hka...@marvell.com/ Thanks Harman > > > -- > David Marchand
RE: [EXT] Re: [PATCH 2/2] doc: multiple representors in one device
> -Original Message- > From: Andrew Rybchenko > Sent: Friday, January 12, 2024 12:56 PM > To: Harman Kalra ; Thomas Monjalon > ; Ferruh Yigit > Cc: dev@dpdk.org > Subject: [EXT] Re: [PATCH 2/2] doc: multiple representors in one device > > External Email > > -- > On 1/11/24 09:44, Harman Kalra wrote: > > Updating the documentation with the pattern format for enabling > > multiple representors in one device > > > > Signed-off-by: Harman Kalra > > IMHO it should be squashed into previous patch. Done, kindly review V2
Re: [PATCH] build: fix linker warnings about undefined symbols
On Mon, Jan 15, 2024 at 09:56:45AM +0100, David Marchand wrote:
> On Fri, Jan 12, 2024 at 9:49 PM Morten Brørup
> wrote:
> > > you can use symver in combination with visibility default
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> > >
> > > anyway just food for thought, it would get me out of having to hack &
> > > enhance the .def from .map generation and unfortunately even with that
> > > there are going to be cases where i still have to annotate the actual
> > > symbol export in code (for windows).
>
> Versioning a symbol means you are exporting it, is it not that simple?
> So I don't see the need for annotating about symbol visibility.
>
>
> > >
> > > just thought a more unified approach for all might appeal.
> >
> > Assuming that we truly want DPDK to support Windows, a more unified
> > approach is a reasonable ask.
> >
> > If we can eliminate the technical obstacles, we should pursue it.
>
> IIUC, we still need a "default" version script, as the linker needs
> one to declare version nodes, and so we have a catch all for
> unversioned symbols.
>
> $ cat symver.c
> __attribute__ ((__symver__ ("api1@DPDK_23")))
> int old_api1(void) { return 0; }
>
> __attribute__ ((__symver__ ("api1@@DPDK_24")))
> int api1(void) { return 0; }
>
> __attribute__ ((__symver__ ("api2@@DPDK_24")))
> int api2(void) { return 0; }
>
> int api3(void) { return 0; }
>
> $ cat symver.map
> DPDK_23 { };
> DPDK_24 { };
> EXPERIMENTAL { };
> INTERNAL {
> local: *;
> };
>
> $ gcc -o symver.o -fPIC -Wall -Werror -c symver.c && gcc -o
> libsymver.so -shared -fPIC -Wl,--version-script symver.map symver.o &&
> readelf -s libsymver.so | grep api
> 5: 110411 FUNCGLOBAL DEFAULT 13 api1@@DPDK_24
> 7: 10f911 FUNCGLOBAL DEFAULT 13 api1@DPDK_23
> 9: 110f11 FUNCGLOBAL DEFAULT 13 api2@@DPDK_24
> 13: 10f911 FUNCLOCAL DEFAULT 13 old_api1
> 15: 110411 FUNCLOCAL DEFAULT 13 api1
> 16: 111a11 FUNCLOCAL DEFAULT 13 api3
> 19: 110f11 FUNCLOCAL DEFAULT 13 api2
> 24: 110411 FUNCGLOBAL DEFAULT 13 api1@@DPDK_24
> 29: 10f911 FUNCGLOBAL DEFAULT 13 api1@DPDK_23
> 31: 110f11 FUNCGLOBAL DEFAULT 13 api2@@DPDK_24
>
>
> >
> > We may have to sacrifice some "nice to have" advantages of the version.map
> > files along the way, such as having easy access to the list of experimental
> > functions in the version.map file.
>
> Developers lose the single location for versioning information, but we
> already have some scripts to help list symbols from a given version.
> We may have to enhance them.
> But I don't think we would lose features.
>
> The devil is probably in the details, though :-).
so my mention of using visibility was more about changes that need to be
made to handle windows dso/dll and wondering if a macro based approach
would result in something unified for both windows and unix targets.
today as you know we use a .map as an authoritative source for the
exported symbols and translate the contents of the .map to a .def for
the windows linker.
going forward to fix dso/dll on windows i'll need to do 2 things.
* exclusive export of a subset of symbols for windows only
* annotation of certain data symbols with type information
since the .map is authoritative i can't just plant either of the above
into the .map in order to pass it through to the generated .def file.
* we could maintain a mostly duplicated copy of .def and stop generating
it allowing the above additions for windows only.
* we could go hybrid approach where some of the windows symbols are
listed in the .map and some of them are macros in the code.
* we could move to some single authoritative source that isn't just
defacto default of a toolchain and generate both .map and .def
* we could move to visibility and symbol marking with macros in the code
for all symbols, of course the expansion is still conditional but
you could reasonably grep the tree to generate a full set of exported
names.
if the suggestion to use visibility and macros for both isn't popular
i'm most likely to look at the hybrid approach since i don't have a lot
of interest in trying to mangle things into comments of the .map for
.def generation and don't think inventing a new common/authoritative
format and maintaining a .map and .def generator is interesting.
i'm open to input, so just fishing for others who have stronger
opinions.
ty
>
> --
> David Marchand
Re: [PATCH v4 3/4] baseband/fpga_5gnr_fec: add AGX100 support
On 1/5/24 22:15, Hernan Vargas wrote: Add support for new FPGA variant AGX100 (on Arrow Creek N6000). Signed-off-by: Hernan Vargas --- doc/guides/bbdevs/fpga_5gnr_fec.rst | 76 +- drivers/baseband/fpga_5gnr_fec/agx100_pmd.h | 273 .../baseband/fpga_5gnr_fec/fpga_5gnr_fec.h| 12 +- .../fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1230 +++-- drivers/baseband/fpga_5gnr_fec/vc_5gnr_pmd.h |1 - 5 files changed, 1459 insertions(+), 133 deletions(-) create mode 100644 drivers/baseband/fpga_5gnr_fec/agx100_pmd.h diff --git a/doc/guides/bbdevs/fpga_5gnr_fec.rst b/doc/guides/bbdevs/fpga_5gnr_fec.rst index 956dd6bed560..1ae192a86b25 100644 --- a/doc/guides/bbdevs/fpga_5gnr_fec.rst +++ b/doc/guides/bbdevs/fpga_5gnr_fec.rst @@ -6,12 +6,13 @@ Intel(R) FPGA 5GNR FEC Poll Mode Driver The BBDEV FPGA 5GNR FEC poll mode driver (PMD) supports an FPGA implementation of a VRAN LDPC Encode / Decode 5GNR wireless acceleration function, using Intel's PCI-e and FPGA -based Vista Creek device. +based Vista Creek (N3000, referred to as VC_5GNR in the code) as well as Arrow Creek (N6000, +referred to as AGX100 in the code). Features -FPGA 5GNR FEC PMD supports the following features: +FPGA 5GNR FEC PMD supports the following BBDEV capabilities: - LDPC Encode in the DL - LDPC Decode in the UL @@ -67,10 +68,18 @@ Initialization When the device first powers up, its PCI Physical Functions (PF) can be listed through this command: +Vista Creek (N3000) + .. code-block:: console sudo lspci -vd8086:0d8f +Arrow Creek (N6000) + +.. code-block:: console + + sudo lspci -vd8086:5799 + The physical and virtual functions are compatible with Linux UIO drivers: ``vfio_pci`` and ``igb_uio``. However, in order to work the FPGA 5GNR FEC device firstly needs to be bound to one of these linux drivers through DPDK. @@ -78,6 +87,7 @@ to be bound to one of these linux drivers through DPDK. For more details on how to bind the PF device and create VF devices, see :ref:`linux_gsg_binding_kernel`. + Configure the VFs through PF @@ -100,7 +110,6 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: uint8_t dl_bandwidth; uint8_t ul_load_balance; uint8_t dl_load_balance; - uint16_t flr_time_out; }; - ``pf_mode_en``: identifies whether only PF is to be used, or the VFs. PF and @@ -111,12 +120,12 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: - ``vf_*l_queues_number``: defines the hardware queue mapping for every VF. -- ``*l_bandwidth``: in case of congestion on PCIe interface. The device - allocates different bandwidth to UL and DL. The weight is configured by this - setting. The unit of weight is 3 code blocks. For example, if the code block - cbps (code block per second) ratio between UL and DL is 12:1, then the - configuration value should be set to 36:3. The schedule algorithm is based - on code block regardless the length of each block. +- ``*l_bandwidth``: Only used for the Vista Creek schedule algorithm in case of + congestion on PCIe interface. The device allocates different bandwidth to UL + and DL. The weight is configured by this setting. The unit of weight is 3 code + blocks. For example, if the code block cbps (code block per second) ratio between + UL and DL is 12:1, then the configuration value should be set to 36:3. + The schedule algorithm is based on code block regardless the length of each block. - ``*l_load_balance``: hardware queues are load-balanced in a round-robin fashion. Queues get filled first-in first-out until they reach a pre-defined @@ -126,10 +135,6 @@ parameters defined in ``rte_fpga_5gnr_fec_conf`` structure: If all hardware queues exceeds the watermark, no code blocks will be streamed in from UL/DL code block FIFO. -- ``flr_time_out``: specifies how many 16.384us to be FLR time out. The - time_out = flr_time_out x 16.384us. For instance, if you want to set 10ms for - the FLR time out then set this setting to 0x262=610. - This change sounds unrelated. It should be in a dedicated patch with Fixes tag set, as it seems it was already not in fpga_5gnr driver before this series. An example configuration code calling the function ``rte_fpga_5gnr_fec_configure()`` is shown below: @@ -154,7 +159,7 @@ below: /* setup FPGA PF */ ret = rte_fpga_5gnr_fec_configure(info->dev_name, &conf); TEST_ASSERT_SUCCESS(ret, - "Failed to configure 4G FPGA PF for bbdev %s", + "Failed to configure 5GNR FPGA PF for bbdev %s", Ditto info->dev_name);
Re: [dpdk-dev] [PATCH] eal: refactor rte_eal_init into sub-functions
On Mon, 15 Jan 2024 00:50:10 -0800 Rahul Gupta wrote: > + /* running on a slave lcore */ NAK Do not add slave terminology back anywhere in DPDK
[PATCH v2] bus/uacce: introduce UACCE bus
UACCE (Unified/User-space-access-intended Accelerator Framework) was
upstream to Linux kernel version 5.7, and it targets to provide Shared
Virtual Addressing (SVA) between accelerators and processes. So
accelerator can access any data structure of the main cpu. [1] for more
information.
This commit introduces UACCE bus, so that the accelerator devices could
seen at DPDK and could be further registered such as a compress, crypto,
dma and ethdev device.
[1] https://docs.kernel.org/misc-devices/uacce.html
Signed-off-by: Chengwen Feng
Acked-by: Zhangfei Gao
Acked-by: Huisong Li
---
v2: Address Huisong's comments.
Replace mmap/munmap with rte_mem_map/rte_mem_unmap.
Refine rte_uacce_avail_queues()'s return value descriptor.
Refine impl of removing last new line character.
Adjust copyright start with 2024.
---
MAINTAINERS| 4 +
doc/guides/rel_notes/release_24_03.rst | 6 +
drivers/bus/meson.build| 1 +
drivers/bus/uacce/bus_uacce_driver.h | 254 +
drivers/bus/uacce/meson.build | 12 +
drivers/bus/uacce/uacce.c | 701 +
drivers/bus/uacce/version.map | 15 +
7 files changed, 993 insertions(+)
create mode 100644 drivers/bus/uacce/bus_uacce_driver.h
create mode 100644 drivers/bus/uacce/meson.build
create mode 100644 drivers/bus/uacce/uacce.c
create mode 100644 drivers/bus/uacce/version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..89711029d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -604,6 +604,10 @@ Platform bus driver
M: Tomasz Duszynski
F: drivers/bus/platform/
+UACCE bus driver
+M: Chengwen Feng
+F: drivers/bus/uacce/
+
VDEV bus driver
F: drivers/bus/vdev/
F: app/test/test_vdev.c
diff --git a/doc/guides/rel_notes/release_24_03.rst
b/doc/guides/rel_notes/release_24_03.rst
index 6f8ad27808..96ecaec150 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -55,6 +55,12 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Added HiSilicon UACCE bus support.**
+
+ UACCE (Unified/User-space-access-intended Accelerator Framework) bus driver
+ has been added, so that the accelerator devices could seen at DPDK and could
+ be further registered such as a compress, crypto, dma and ethdev device.
+
Removed Items
-
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index a78b4283bf..d67db8576b 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -9,6 +9,7 @@ drivers = [
'ifpga',
'pci',
'platform',
+'uacce',
'vdev',
'vmbus',
]
diff --git a/drivers/bus/uacce/bus_uacce_driver.h
b/drivers/bus/uacce/bus_uacce_driver.h
new file mode 100644
index 00..c8e177d44f
--- /dev/null
+++ b/drivers/bus/uacce/bus_uacce_driver.h
@@ -0,0 +1,254 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2024 HiSilicon Limited
+ */
+
+#ifndef BUS_UACCE_DRIVER_H
+#define BUS_UACCE_DRIVER_H
+
+/**
+ * @file
+ *
+ * HiSilicon UACCE bus interface.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define RTE_UACCE_DEV_PATH_SIZE256
+#define RTE_UACCE_API_NAME_SIZE64
+#define RTE_UACCE_ALGS_NAME_SIZE 384
+#define RTE_UACCE_ATTR_MAX_SIZE384
+
+/*
+ * Definition for queue file region type.
+ */
+enum rte_uacce_qfrt {
+ RTE_UACCE_QFRT_MMIO = 0, /**< Device mmio region. */
+ RTE_UACCE_QFRT_DUS, /**< Device user share region. */
+ RTE_UACCE_QFRT_BUTT
+};
+
+struct rte_uacce_driver;
+
+/**
+ * A structure describing a UACCE device.
+ */
+struct rte_uacce_device {
+ RTE_TAILQ_ENTRY(rte_uacce_device) next; /**< Next in device list. */
+ struct rte_device device;/**< Inherit core device. */
+ struct rte_uacce_driver *driver; /**< Driver used in probing. */
+ char name[RTE_DEV_NAME_MAX_LEN]; /**< Device name. */
+ char dev_root[RTE_UACCE_DEV_PATH_SIZE]; /**< Sysfs path with device
name. */
+ char cdev_path[RTE_UACCE_DEV_PATH_SIZE]; /**< Device path in devfs. */
+ char api[RTE_UACCE_API_NAME_SIZE]; /**< Device context type. */
+ char algs[RTE_UACCE_ALGS_NAME_SIZE]; /**< Device supported
algorithms. */
+ uint32_t flags; /**< Device flags. */
+ int numa_node; /**< NUMA node connection, -1
if unknown. */
+ uint32_t qfrt_sz[RTE_UACCE_QFRT_BUTT]; /**< Queue file region type's
size. */
+};
+
+/**
+ * @internal
+ * Helper macro for drivers that need to convert to struct rte_uacce_device.
+ */
+#define RTE_DEV_TO_UACCE_DEV(ptr) \
+ container_of(ptr, struct rte_uacce_device, device)
+
+#define RTE_DEV_TO_UACCE_DEV_CONS
[PATCH] maintainers: update for i40e/iavf/idpf/cpfl
From: Beilei Xing Remove myself from maintainers. Signed-off-by: Beilei Xing --- MAINTAINERS | 4 1 file changed, 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0d1c8126e3..5f37a53ac3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -759,7 +759,6 @@ F: doc/guides/nics/features/ixgbe*.ini Intel i40e M: Yuying Zhang -M: Beilei Xing T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/i40e/ F: doc/guides/nics/i40e.rst @@ -776,7 +775,6 @@ F: doc/guides/nics/features/fm10k*.ini Intel iavf M: Jingjing Wu -M: Beilei Xing T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/iavf/ F: drivers/common/iavf/ @@ -792,7 +790,6 @@ F: doc/guides/nics/features/ice.ini Intel idpf M: Jingjing Wu -M: Beilei Xing T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/idpf/ F: drivers/common/idpf/ @@ -801,7 +798,6 @@ F: doc/guides/nics/features/idpf.ini Intel cpfl - EXPERIMENTAL M: Yuying Zhang -M: Beilei Xing T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/cpfl/ F: doc/guides/nics/cpfl.rst -- 2.34.1
RE: [External] : Re: [PATCH] net/tap: Modified TAP BPF program as per the Kernel-version upgrade requirements.
Hi Stephen, Yes, I found that the Kernel we use has more Verification added for safe execution: https://blogs.oracle.com/linux/post/bpf-in-depth-the-bpf-bytecode-and-the-bpf-verifier Here they mentioned about SKB pointer direct access, math on pointer and array with undefined access is denied on BPF code. Thanks, Madhuker. -Original Message- From: Stephen Hemminger Sent: 13 January 2024 23:36 To: Madhuker Mythri Cc: dev@dpdk.org; ferruh.yi...@amd.com Subject: Re: [External] : Re: [PATCH] net/tap: Modified TAP BPF program as per the Kernel-version upgrade requirements. On Sat, 13 Jan 2024 17:52:34 + Madhuker Mythri wrote: > That's true, SKB pointer access denied and throws error. > So, I have to replace with this BPF helper functions. It does not for me using current Debian kernel. You may have enabled something else.
Re: [PATCH] net/gve: Enable stats reporting for GQ format
On Fri, Jan 12, 2024 at 8:36 PM Ferruh Yigit wrote:
> On 12/22/2023 3:39 PM, Rushil Gupta wrote:
> > Read from shared region to retrieve imissed statistics for GQ from
> device.
> > Tested using `show port xstats ` in interactive mode.
> > This metric can be triggered by using queues > cores.
> >
>
> Looks good but please check following comments:
>
> Checkpatch gives warning on the patch title, and this patch adds
> 'imissed' support so it can be added to the patch title, something like:
> "net/gve: enable imissed stats for GQ format"
>
> <...>
>
> > +static int gve_alloc_stats_report(struct gve_priv *priv,
> > + uint16_t nb_tx_queues, uint16_t nb_rx_queues)
> > +{
> > + char z_name[RTE_MEMZONE_NAMESIZE];
> > + int tx_stats_cnt;
> > + int rx_stats_cnt;
> > +
> > + tx_stats_cnt = (GVE_TX_STATS_REPORT_NUM + NIC_TX_STATS_REPORT_NUM)
> *
> > + nb_tx_queues;
> > + rx_stats_cnt = (GVE_RX_STATS_REPORT_NUM + NIC_RX_STATS_REPORT_NUM)
> *
> > + nb_rx_queues;
> > + priv->stats_report_len = sizeof(struct gve_stats_report) +
> > + sizeof(struct stats) * (tx_stats_cnt + rx_stats_cnt);
> > +
> > + snprintf(z_name, sizeof(z_name), "stats_report_%s", priv->pci_dev->
> device.name);
> >
>
> Can you please add 'gve_' prefix to the memzone name, to prevent any
> possible collision.
>
Done.
>
> <...>
>
> > +static void gve_free_stats_report(struct rte_eth_dev *dev)
> > +{
> > + struct gve_priv *priv = dev->data->dev_private;
> > + rte_memzone_free(priv->stats_report_mem);
> >
>
> What will happen if user asks stats/xstats after port stopped?
>
Good catch. I have added a null check so that the driver doesn't try to
read stats from memory region that doesn't exist.
>
> <...>
>
> > gve_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> > {
> > uint16_t i;
> > + if (gve_is_gqi(dev->data->dev_private))
> > + gve_get_imissed_from_nic(dev);
> >
>
> This updates imissed in RxQ struct for all queues for basic stats, but
> what if user only calls xstats, I guess in that case stat won't be updated.
>
Yes; that is expected. Since imissed is a member of rte_eth_stats; calling
gve_dev_stats_get is the right way to get this stat.
[PATCH] maintainers: update for e1000/ixgbe
Remove myself from maintainers. Signed-off-by: Wenjun Wu --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0d1c8126e3..a094de0e35 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -740,7 +740,6 @@ F: doc/guides/nics/features/hinic.ini Intel e1000 M: Simei Su -M: Wenjun Wu T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/e1000/ F: doc/guides/nics/e1000em.rst @@ -750,7 +749,6 @@ F: doc/guides/nics/features/igb*.ini Intel ixgbe M: Qiming Yang -M: Wenjun Wu T: git://dpdk.org/next/dpdk-next-net-intel F: drivers/net/ixgbe/ F: doc/guides/nics/ixgbe.rst -- 2.34.1
Re: [dpdk-dev] [v1] ethdev: support Tx queue used count
On Fri, Jan 12, 2024 at 6:03 PM Konstantin Ananyev
wrote:
>
> Hi Jerin,
Hi Konstantin,
>
> > Introduce a new API to retrieve the number of used descriptors
> > in a Tx queue. Applications can leverage this API in the fast path to
> > inspect the Tx queue occupancy and take appropriate actions based on the
> > available free descriptors.
> >
> > A notable use case could be implementing Random Early Discard (RED)
> > in software based on Tx queue occupancy.
> >
> > Signed-off-by: Jerin Jacob
> > @@ -6803,6 +6803,80 @@ rte_eth_recycle_mbufs(uint16_t rx_port_id, uint16_t
> > rx_queue_id,
> > __rte_experimental
> > int rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id,
> > uint32_t *ptypes, int num);
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change, or be removed, without prior
> > notice
> > + *
> > + * Get the number of used descriptors of a Tx queue
> > + *
> > + * This function retrieves the number of used descriptors of a transmit
> > queue.
> > + * Applications can use this API in the fast path to inspect Tx queue
> > occupancy and take
> > + * appropriate actions based on the available free descriptors.
> > + * An example action could be implementing the Random Early Discard (RED).
>
> Sorry, I probably misunderstood your previous mails, but wouldn't it be more
> convenient
> for user to have rte_eth_tx_queue_free_count(...) as fast-op, and
> have rte_eth_tx_queue_count(...) { queue_txd_num -
> rte_eth_tx_queue_free_count(...);}
> as a slow-path function in rte_ethdev.c?
The general feedback is to align with the Rx queue API, specifically
rte_eth_rx_queue_count,
and it's noted that there is no equivalent rte_eth_rx_queue_free_count.
Given that the free count can be obtained by subtracting the used
count from queue_txd_num,
it is considered that either approach is acceptable.
The application configures queue_txd_num with tx_queue_setup(), and
the application can store that value in its structure.
This would enable fast-path usage for both base cases (whether the
application needs information about free or used descriptors)
with just one API(rte_eth_tx_queue_count())
> Konstantin
[v2] net/gve: enable imissed stats for GQ format
Read from shared region to retrieve imissed statistics for GQ from device.
Tested using `show port xstats ` in interactive mode.
Signed-off-by: Rushil Gupta
Reviewed-by: Joshua Washington
---
drivers/net/gve/base/gve_adminq.h | 11
drivers/net/gve/gve_ethdev.c | 100 ++
drivers/net/gve/gve_ethdev.h | 6 ++
3 files changed, 117 insertions(+)
diff --git a/drivers/net/gve/base/gve_adminq.h
b/drivers/net/gve/base/gve_adminq.h
index e30b184913..f05362f85f 100644
--- a/drivers/net/gve/base/gve_adminq.h
+++ b/drivers/net/gve/base/gve_adminq.h
@@ -314,6 +314,17 @@ struct gve_stats_report {
GVE_CHECK_STRUCT_LEN(8, gve_stats_report);
+/* Numbers of gve tx/rx stats in stats report. */
+#define GVE_TX_STATS_REPORT_NUM6
+#define GVE_RX_STATS_REPORT_NUM2
+
+/* Interval to schedule a stats report update, 2ms. */
+#define GVE_STATS_REPORT_TIMER_PERIOD 2
+
+/* Numbers of NIC tx/rx stats in stats report. */
+#define NIC_TX_STATS_REPORT_NUM0
+#define NIC_RX_STATS_REPORT_NUM4
+
enum gve_stat_names {
/* stats from gve */
TX_WAKE_CNT = 1,
diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c
index ecd37ff37f..fe91e790bc 100644
--- a/drivers/net/gve/gve_ethdev.c
+++ b/drivers/net/gve/gve_ethdev.c
@@ -125,6 +125,78 @@ gve_link_update(struct rte_eth_dev *dev, __rte_unused int
wait_to_complete)
return rte_eth_linkstatus_set(dev, &link);
}
+static int
+gve_alloc_stats_report(struct gve_priv *priv,
+ uint16_t nb_tx_queues, uint16_t nb_rx_queues)
+{
+ char z_name[RTE_MEMZONE_NAMESIZE];
+ int tx_stats_cnt;
+ int rx_stats_cnt;
+
+ tx_stats_cnt = (GVE_TX_STATS_REPORT_NUM + NIC_TX_STATS_REPORT_NUM) *
+ nb_tx_queues;
+ rx_stats_cnt = (GVE_RX_STATS_REPORT_NUM + NIC_RX_STATS_REPORT_NUM) *
+ nb_rx_queues;
+ priv->stats_report_len = sizeof(struct gve_stats_report) +
+ sizeof(struct stats) * (tx_stats_cnt + rx_stats_cnt);
+
+ snprintf(z_name, sizeof(z_name), "stats_report_%s",
priv->pci_dev->device.name);
+ priv->gve_stats_report_mem = rte_memzone_reserve_aligned(z_name,
+ priv->stats_report_len,
+ rte_socket_id(),
+ RTE_MEMZONE_IOVA_CONTIG, PAGE_SIZE);
+
+ if (!priv->gve_stats_report_mem)
+ return -ENOMEM;
+
+ /* offset by skipping stats written by gve. */
+ priv->stats_start_idx = (GVE_TX_STATS_REPORT_NUM * nb_tx_queues) +
+ (GVE_RX_STATS_REPORT_NUM * nb_rx_queues);
+ priv->stats_end_idx = priv->stats_start_idx +
+ (NIC_TX_STATS_REPORT_NUM * nb_tx_queues) +
+ (NIC_RX_STATS_REPORT_NUM * nb_rx_queues) - 1;
+
+ return 0;
+}
+
+static void
+gve_free_stats_report(struct rte_eth_dev *dev)
+{
+ struct gve_priv *priv = dev->data->dev_private;
+ rte_memzone_free(priv->gve_stats_report_mem);
+ priv->gve_stats_report_mem = NULL;
+}
+
+/* Read Rx NIC stats from shared region */
+static void
+gve_get_imissed_from_nic(struct rte_eth_dev *dev)
+{
+ struct gve_stats_report *stats_report;
+ struct gve_rx_queue *rxq;
+ struct gve_priv *priv;
+ struct stats stat;
+ int queue_id;
+ int stat_id;
+ int i;
+
+ priv = dev->data->dev_private;
+ if (!priv->gve_stats_report_mem)
+ return;
+ stats_report = (struct gve_stats_report *)
+ priv->gve_stats_report_mem->addr;
+ for (i = priv->stats_start_idx; i <= priv->stats_end_idx; i++) {
+ stat = stats_report->stats[i];
+ queue_id = cpu_to_be32(stat.queue_id);
+ rxq = dev->data->rx_queues[queue_id];
+ if (rxq == NULL)
+ continue;
+ stat_id = cpu_to_be32(stat.stat_name);
+ /* Update imissed. */
+ if (stat_id == RX_NO_BUFFERS_POSTED)
+ rxq->stats.imissed = cpu_to_be64(stat.value);
+ }
+}
+
static int
gve_start_queues(struct rte_eth_dev *dev)
{
@@ -176,6 +248,7 @@ gve_start_queues(struct rte_eth_dev *dev)
static int
gve_dev_start(struct rte_eth_dev *dev)
{
+ struct gve_priv *priv;
int ret;
ret = gve_start_queues(dev);
@@ -187,6 +260,26 @@ gve_dev_start(struct rte_eth_dev *dev)
dev->data->dev_started = 1;
gve_link_update(dev, 0);
+ priv = dev->data->dev_private;
+ /* No stats available yet for Dqo. */
+ if (gve_is_gqi(priv)) {
+ ret = gve_alloc_stats_report(priv,
+ dev->data->nb_tx_queues,
+ dev->data->nb_rx_queues);
+ if (ret != 0) {
+ PMD_DRV_LOG(ERR,
+ "Failed to allocate region for stats
reporting.");
+ return ret;
+
