Re: [PATCH v2 1/3] lib: skip congestion management configuration
On Wed, Jan 25, 2023 at 1:03 PM Rakesh Kudurumalla wrote: > > Skip the congestion management configuration applied using > rte_eth_cman_config_set() API on the given ethdev Rx queue. 1) Add more comments. Also starts with ethdev: example, ethdev: introduce flow action to skip congestion management configuration Using rte_eth_cman_config_set() API the application can configure ethdev Rx queue's congestion mechanism. Introducing RTE_FLOW_ACTION_TYPE_SKIP_CMAN flow action to skip the congestion configuration applied to the given ethdev Rx queue. This feature helps to skip the congestion management processing based on per flow or the packet color identified by the rte_flow meter object. For example, If one Rx queue configured as RED congestion and application wants tobypass the RED congestion processing for all GREEN color packet can be expressed though RTE_FLOW_ACTION_TYPE_SKIP_CMAN flow action 2) Update doc/guides/prog_guide/rte_flow.rst for new action and 3/3 patch for doc/guides/nics/features/ pmd specific doc
RE: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
++ Ivan Malov and Andrew Rybchenko > -Original Message- > From: Ferruh Yigit > Sent: Tuesday, January 24, 2023 11:34 PM > To: Hanumanth Reddy Pothula ; Aman Singh > ; Yuying Zhang > Cc: dev@dpdk.org; andrew.rybche...@oktetlabs.ru; > viachesl...@nvidia.com; Jerin Jacob Kollanukkaran ; > Nithin Kumar Dabilpuram > Subject: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process > Rx metadata negotiation > > External Email > > -- > On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: > > Presently, Rx metadata is sent to PMD by default, leading to a > > performance drop as processing for the same in Rx path takes extra > > cycles. > > > > Hence, add new testpmd command, > > 'enable port nic_to_pmd_rx_metadata' > > > > This command helps in sending Rx metadata to PMD and thereby Rx > > metadata flow command requests are processed. > > > > Signed-off-by: Hanumanth Pothula > > Hi Hanumanth, > > I agree with Thomas for the patch. > > 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be > enabled, but at this stage if there is no flow rule for Rx metadata why it is > consuming extra cycles? > > Can you update driver code to process Rx metadata when it is enabled by > application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least > one flow rule for it? #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is always called by testpmd. We thought it was added so that when that metadata is not needed, application need not call this thereby saving cycles/bandwidth. #2 We use this API similar to Rx/Tx offload flags so that we can set things up before device is configured. We thought that is the purpose of having this negotiate API and avoid depleting offload flags. #3 Generally any new offloads added to DPDK would be in disabled state in testpmd and we would have an option to enable it. In this case, testpmd is by default calling this negotiation. We can update the driver if the purpose of this API is clear.
RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
Hi Jerin,
> -Original Message-
> From: Jerin Jacob
> Sent: Wednesday, January 25, 2023 9:42 AM
> To: Naga Harish K, S V
> Cc: jer...@marvell.com; Carrillo, Erik G ; Gujjar,
> Abhinandan S ; dev@dpdk.org;
> Jayatheerthan, Jay
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> wrote:
> >
> > Hi Jerin,
> >
> > > -Original Message-
> > > From: Jerin Jacob
> > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > To: Naga Harish K, S V
> > > Cc: jer...@marvell.com; Carrillo, Erik G
> > > ; Gujjar, Abhinandan S
> > > ; dev@dpdk.org; Jayatheerthan, Jay
> > >
> > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > wrote:
> > > >
> > > > The adapter configuration parameters defined in the ``struct
> > > > rte_event_eth_rx_adapter_runtime_params`` can be configured and
> > > > retrieved using ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > and ``rte_event_eth_tx_adapter_runtime_params_get`` respectively.
> > > >
> > > > Signed-off-by: Naga Harish K S V
> > >
> > > > diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > index 461eca566f..2207d6ffc3 100644
> > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > @@ -185,6 +185,26 @@ flags for handling received packets, event
> > > > queue identifier, scheduler type, event priority, polling
> > > > frequency of the receive queue and flow identifier in struct
> > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > >
> > > > +Set/Get adapter runtime configuration parameters
> > > > +
> > > > +
> > > > +The runtime configuration parameters of adapter can be set/read
> > > > +using ``rte_event_eth_rx_adapter_runtime_params_set()`` and
> > > > +``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > +The parameters that can be set/read are defined in ``struct
> > > rte_event_eth_rx_adapter_runtime_params``.
> > >
> > > Good.
> > >
> > > > +
> > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures the
> > > > +adapter with default value for maximum packets processed per
> > > > +request to
> > > 128.
> > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function allows
> > > > +to reconfigure maximum number of packets processed by adapter per
> > > > +service request. This is alternative to configuring the maximum
> > > > +packets processed per request by adapter by using
> > > > +``rte_event_eth_rx_adapter_create_ext()`` with parameter
> > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > >
> > > This paragraph is not needed IMO. As it is specific to a driver, and
> > > we can keep Doxygen comment only.
> > >
> > >
> > > > +
> > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > +retrieves the configuration parameters that are defined in
> > > > +``struct
> > > rte_event_eth_rx_adapter_runtime_params``.
> > >
> > > Good.
> > >
> > > > +
> > > > Getting and resetting Adapter queue stats
> > > > ~
> > > >
> > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > index 34aa87379e..d8f3e750b7 100644
> > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > @@ -35,6 +35,8 @@
> > > > #define MAX_VECTOR_NS 1E9
> > > > #define MIN_VECTOR_NS 1E5
> > > >
> > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > +
> > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN32
> > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN32
> > > >
> > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> dev_id,
> > > > }
> > > >
> > > > conf->event_port_id = port_id;
> > > > - conf->max_nb_rx = 128;
> > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > if (started)
> > > > ret = rte_event_dev_start(dev_id);
> > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > return -EINVAL;
> > > > }
> > >
> > > > +
> > > > +int
> > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > +*params) {
> > > > + struct event_eth_rx_adapter *rxa;
> > > > + int ret;
> > > > +
> > > > + if (params == NULL)
> > > > + return -EINVAL;
> > > > +
> > > > + if (rxa_memzone_lookup())
> > > > + return -ENOMEM;
> > >
> > > Introduce an adapter callback and move SW adapter related logic
> > > under callback handler.
> > >
> > >
> > Do you mean introducing
RE: [PATCH v2 1/2] mailmap: add contributor to list
Hi, Please provide comment for this patch. Regards, Mohammad Iqbal Ahmad -Original Message- From: Mohammad Iqbal Ahmad Sent: Monday, December 19, 2022 2:04 PM To: dev@dpdk.org; Thomas Monjalon Cc: Jerin Jacob Kollanukkaran ; Sunil Kumar Kori ; Satha Koteswara Rao Kottidi ; Pavan Nikhilesh Bhagavatula ; Kiran Kumar Kokkilagadda ; Satheesh Paul Antonysamy ; Ashwin Sekhar T K ; Anoob Joseph ; Akhil Goyal ; Harman Kalra ; Nithin Kumar Dabilpuram ; Mohammad Iqbal Ahmad Subject: [PATCH v2 1/2] mailmap: add contributor to list Add contributor to mailmap. Signed-off-by: Mohammad Iqbal Ahmad --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 75884b6fe2..464164765f 100644 --- a/.mailmap +++ b/.mailmap @@ -911,6 +911,7 @@ Mitch Williams Mit Matelske Mohamad Noor Alim Hussin Mohammad Abdul Awal +Mohammad Iqbal Ahmad Mohammed Gamal Mohsin Kazmi Mohsin Mazhar Shaikh -- 2.25.1
Re: TCP stack support on DPDK
Hi Liang, Thank you so much for your response. I would like to convert our in-house tool into a high performance traffic generator and it is written in Python. Is it possible to use any of the user space TCP stack by compiling into shared libraries and access it via Python using ctypes? Could you please let me know any viable solution to make use of user space TCP stack compatible with Python? Regards, Sam On Mon, Jan 23, 2023 at 3:48 PM Liang Ma wrote: > On Fri, Jan 20, 2023 at 01:41:56PM +0530, Sam Kirubakaran wrote: > > Hi team, > > > > My name is Sam and I am a Software Engineer. > > Currently, we are trying to improve the performance of proprietary > in-house > > tools by using DPDK but we are not sure whether DPDK has support for TCP > > stack. > > If yes, could you please point me to the link of apis alone. I will take > it > > from there. > > Could you please guide me on this? Your response would be highly > > appreciated! > DPDK itself has no TCP stack. However, there are some userspace TCP > stack project which support DPDK. TPDK/Seastar/fullstack etc. > > > > Regards, > > Sam >
[PATCH v3 1/1] app/test-flow-perf: fix division or module by zero
Fix division or module by zero reported by coverity scan.
Updated .mailmap
Coverity issue: 373870
Fixes: bf3688f1e816 ("app/flow-perf: add insertion rate calculation")
Signed-off-by: Mohammad Iqbal Ahmad
---
.mailmap | 1 +
app/test-flow-perf/main.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index a153c9ab93..ec9f419f53 100644
--- a/.mailmap
+++ b/.mailmap
@@ -912,6 +912,7 @@ Mitch Williams
Mit Matelske
Mohamad Noor Alim Hussin
Mohammad Abdul Awal
+Mohammad Iqbal Ahmad
Mohammed Gamal
Mohsin Kazmi
Mohsin Mazhar Shaikh
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 4a9206803a..0a542b0d87 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -848,7 +848,12 @@ args_parse(int argc, char **argv)
/* Control */
if (strcmp(lgopts[opt_idx].name,
"rules-batch") == 0) {
- rules_batch = atoi(optarg);
+ n = atoi(optarg);
+ if (n > 0)
+ rules_batch = n;
+ else
+ rte_exit(EXIT_FAILURE,
+ "flow rules_batch
should be > 0\n");
}
if (strcmp(lgopts[opt_idx].name,
"rules-count") == 0) {
--
2.25.1
DPDK Tech Board Meeting - Tomorrow 1/25/23 @ 7am PT/10am ET/1600h CET
Dear DPDK Community, Our biweekly tech board meeting will be held tomorrow, January 25, 2023 - 7am PT/10am ET/1600h CET. The agenda with discussion items will be posted here: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db To join the meeting follow this link: https://meet.jit.si/dpdk We look forward to seeing you there Many thanks, Nathan Nathan C. Southern, Project Coordinator Data Plane Development Kit The Linux Foundation 248.835.4812 (mobile) nsouth...@linuxfoundation.org
RE: dev Digest, Vol 440, Issue 47
> I would like to convert our in-house tool into a high performance traffic > generator and it is written in Python. > Is it possible to use any of the user space TCP stack by compiling into > shared libraries and access it via Python using ctypes? > Could you please let me know any viable solution to make use of user space > TCP stack compatible with Python? If you're looking for a high-performance L3-L7 traffic generator based on DPDK that you can automate with python, I'd recommend TRex: https://trex-tgn.cisco.com/ We use it extensively in fd.io and in other projects. Best ben
[PATCH 2/2] bus: add platform bus
Platform bus is a software bus under Linux that manages devices which
generally do not have built-in discovery mechanisms. Linux normally
learns about platform devices directly from device-tree during
boot-up phase.
Up to this point, whenever some userspace app needed control over
platform device or a range of thereof some sort of driver being
a mixture of vdev/rawdev was required.
In order to simplify this task, provide an auto-probe
experience and separate bus logic from the driver itself,
add platform bus support.
Currently devices backed up by vfio-platform kernel driver
are supported.
Signed-off-by: Tomasz Duszynski
---
MAINTAINERS| 4 +
doc/guides/rel_notes/release_23_03.rst | 5 +
drivers/bus/meson.build| 1 +
drivers/bus/platform/bus_platform_driver.h | 174 ++
drivers/bus/platform/meson.build | 16 +
drivers/bus/platform/platform.c| 604 +
drivers/bus/platform/platform_params.c | 70 +++
drivers/bus/platform/private.h | 48 ++
drivers/bus/platform/version.map | 10 +
9 files changed, 932 insertions(+)
create mode 100644 drivers/bus/platform/bus_platform_driver.h
create mode 100644 drivers/bus/platform/meson.build
create mode 100644 drivers/bus/platform/platform.c
create mode 100644 drivers/bus/platform/platform_params.c
create mode 100644 drivers/bus/platform/private.h
create mode 100644 drivers/bus/platform/version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a0f416d2e..b02666710c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -581,6 +581,10 @@ VDEV bus driver
F: drivers/bus/vdev/
F: app/test/test_vdev.c
+Platform bus driver
+M: Tomasz Duszynski
+F: drivers/bus/platform
+
VMBUS bus driver
M: Long Li
F: drivers/bus/vmbus/
diff --git a/doc/guides/rel_notes/release_23_03.rst
b/doc/guides/rel_notes/release_23_03.rst
index 84b112a8b1..74b2b1e3ff 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -57,6 +57,11 @@ New Features
* **Added multi-process support for axgbe PMD.**
+* **Added platform bus support.**
+
+ A platform bus provides a way to use Linux platform devices which
+ are compatible with vfio-platform kernel driver.
+
* **Updated Corigine nfp driver.**
* Added support for meter options.
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index 45eab5233d..6d2520c543 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -7,6 +7,7 @@ drivers = [
'fslmc',
'ifpga',
'pci',
+'platform',
'vdev',
'vmbus',
]
diff --git a/drivers/bus/platform/bus_platform_driver.h
b/drivers/bus/platform/bus_platform_driver.h
new file mode 100644
index 00..8291c7f3f6
--- /dev/null
+++ b/drivers/bus/platform/bus_platform_driver.h
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef _BUS_PLATFORM_DRIVER_H_
+#define _BUS_PLATFORM_DRIVER_H_
+
+/**
+ * @file
+ * Platform bus interface.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Forward declarations */
+struct rte_platform_bus;
+struct rte_platform_device;
+struct rte_platform_driver;
+
+/**
+ * Initialization function for the driver called during platform device
probing.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @return
+ * 0 on success, negative value otherwise.
+ */
+typedef int (rte_platform_probe_t)(struct rte_platform_device *pdev);
+
+/**
+ * Removal function for the driver called during platform device removal.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @return
+ * 0 on success, negative value otherwise.
+ */
+typedef int (rte_platform_remove_t)(struct rte_platform_device *pdev);
+
+/**
+ * Driver specific DMA mapping.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @param addr
+ * Starting virtual address of memory to be mapped.
+ * @param iova
+ * Starting IOVA address of memory to be mapped.
+ * @param len
+ * Length of memory segment being mapped.
+ * @return
+ * - 0 on success, negative value and rte_errno is set otherwise.
+ */
+typedef int (rte_platform_dma_map_t)(struct rte_platform_device *pdev, void
*addr, uint64_t iova,
+size_t len);
+
+/**
+ * Driver specific DMA unmapping.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @param addr
+ * Starting virtual address of memory to be mapped.
+ * @param iova
+ * Starting IOVA address of memory to be mapped.
+ * @param len
+ * Length of memory segment being mapped.
+ * @return
+ * - 0 on success, negative value and rte_errno is set otherwise.
+ */
+typedef int (rte_platform_dma_unmap_t)(struct rte_platform_device *pdev, void
*addr, uint64_t iova,
+ size_t len);
+
+/**
+ * A structure describing a platform devic
[PATCH 0/2] add platform bus
Platform bus is a bus under Linux which manages devices that do not have any discovery-mechanism built in. Linux learns about platform devices directly from device-tree during boot-up phase. Afterwards if userspace wants to use some particular device driver being usually a mixture of vdev/rawdev gets developed. In order to simplify that introduce a DPDK platform bus which provides auto-probe experience and separates a bus logic from the driver itself. Now only devices which are backed-by vfio-platform kernel driver are supported, though other options may be added if necessary. Tomasz Duszynski (2): lib: add helper to read strings from sysfs files bus: add platform bus MAINTAINERS| 4 + app/test/test_eal_fs.c | 108 +++- doc/guides/rel_notes/release_23_03.rst | 5 + drivers/bus/meson.build| 1 + drivers/bus/platform/bus_platform_driver.h | 174 ++ drivers/bus/platform/meson.build | 16 + drivers/bus/platform/platform.c| 604 + drivers/bus/platform/platform_params.c | 70 +++ drivers/bus/platform/private.h | 48 ++ drivers/bus/platform/version.map | 10 + lib/eal/common/eal_filesystem.h| 6 + lib/eal/unix/eal_filesystem.c | 24 +- lib/eal/version.map| 1 + 13 files changed, 1053 insertions(+), 18 deletions(-) create mode 100644 drivers/bus/platform/bus_platform_driver.h create mode 100644 drivers/bus/platform/meson.build create mode 100644 drivers/bus/platform/platform.c create mode 100644 drivers/bus/platform/platform_params.c create mode 100644 drivers/bus/platform/private.h create mode 100644 drivers/bus/platform/version.map -- 2.34.1
[PATCH 1/2] lib: add helper to read strings from sysfs files
Reading strings from sysfs files is a re-occurring pattern
hence add helper for doing that.
Signed-off-by: Tomasz Duszynski
---
app/test/test_eal_fs.c | 108
lib/eal/common/eal_filesystem.h | 6 ++
lib/eal/unix/eal_filesystem.c | 24 ---
lib/eal/version.map | 1 +
4 files changed, 121 insertions(+), 18 deletions(-)
diff --git a/app/test/test_eal_fs.c b/app/test/test_eal_fs.c
index b3686edcb4..6c373fc7f1 100644
--- a/app/test/test_eal_fs.c
+++ b/app/test/test_eal_fs.c
@@ -20,12 +20,33 @@ test_eal_fs(void)
#else
+static int
+temp_create(char *filename, size_t len)
+{
+ char file_template[] = "/tmp/eal_test_XX";
+ char proc_path[PATH_MAX];
+ int fd;
+
+ fd = mkstemp(file_template);
+ if (fd == -1) {
+ perror("mkstemp() failure");
+ return -1;
+ }
+
+ snprintf(proc_path, sizeof(proc_path), "/proc/self/fd/%d", fd);
+ if (readlink(proc_path, filename, len) < 0) {
+ perror("readlink() failure");
+ close(fd);
+ return -1;
+ }
+
+ return fd;
+}
+
static int
test_parse_sysfs_value(void)
{
char filename[PATH_MAX] = "";
- char proc_path[PATH_MAX];
- char file_template[] = "/tmp/eal_test_XX";
int tmp_file_handle = -1;
FILE *fd = NULL;
unsigned valid_number;
@@ -40,16 +61,10 @@ test_parse_sysfs_value(void)
/* get a temporary filename to use for all tests - create temp file
handle and then
* use /proc to get the actual file that we can open */
- tmp_file_handle = mkstemp(file_template);
- if (tmp_file_handle == -1) {
- perror("mkstemp() failure");
+ tmp_file_handle = temp_create(filename, sizeof(filename));
+ if (tmp_file_handle < 0)
goto error;
- }
- snprintf(proc_path, sizeof(proc_path), "/proc/self/fd/%d",
tmp_file_handle);
- if (readlink(proc_path, filename, sizeof(filename)) < 0) {
- perror("readlink() failure");
- goto error;
- }
+
printf("Temporary file is: %s\n", filename);
/* test we get an error value if we use file before it's created */
@@ -175,11 +190,82 @@ test_parse_sysfs_value(void)
return -1;
}
+static int
+test_parse_sysfs_string(void)
+{
+ const char *teststr = "the quick brown dog jumps over the lazy fox\n";
+ char filename[PATH_MAX] = "";
+ char buf[BUFSIZ] = { };
+ int tmp_file_handle;
+ FILE *fd = NULL;
+
+#ifdef RTE_EXEC_ENV_FREEBSD
+ /* BSD doesn't have /proc/pid/fd */
+ return 0;
+#endif
+ printf("Testing function eal_parse_sysfs_string()\n");
+
+ /* get a temporary filename to use for all tests - create temp file
handle and then
+* use /proc to get the actual file that we can open
+*/
+ tmp_file_handle = temp_create(filename, sizeof(filename));
+ if (tmp_file_handle < 0)
+ goto error;
+
+ printf("Temporary file is: %s\n", filename);
+
+ /* test we get an error value if we use file before it's created */
+ printf("Test reading a missing file ...\n");
+ if (eal_parse_sysfs_string("/dev/not-quite-null", buf, sizeof(buf)) ==
0) {
+ printf("Error with eal_parse_sysfs_string() - returned success
on reading empty file\n");
+ goto error;
+ }
+ printf("Confirmed return error when reading empty file\n");
+
+ /* test reading a string from file */
+ printf("Test reading string ...\n");
+ fd = fopen(filename, "w");
+ if (fd == NULL) {
+ printf("line %d, Error opening %s: %s\n", __LINE__, filename,
strerror(errno));
+ goto error;
+ }
+ fprintf(fd, "%s", teststr);
+ fclose(fd);
+ fd = NULL;
+ if (eal_parse_sysfs_string(filename, buf, sizeof(buf) - 1) < 0) {
+ printf("eal_parse_sysfs_string() returned error - test
failed\n");
+ goto error;
+ }
+ if (strcmp(teststr, buf)) {
+ printf("Invalid string read by eal_parse_sysfs_string() - test
failed\n");
+ goto error;
+ }
+ /* don't print newline */
+ buf[strlen(buf) - 1] = '\0';
+ printf("Read '%s\\n' ok\n", buf);
+
+ close(tmp_file_handle);
+ unlink(filename);
+ printf("eal_parse_sysfs_string() - OK\n");
+ return 0;
+
+error:
+ if (fd)
+ fclose(fd);
+ if (tmp_file_handle > 0)
+ close(tmp_file_handle);
+ if (filename[0] != '\0')
+ unlink(filename);
+ return -1;
+}
+
static int
test_eal_fs(void)
{
if (test_parse_sysfs_value() < 0)
return -1;
+ if (test_parse_sysfs_string() < 0)
+ return -1;
return 0;
}
diff --git a/lib/eal/common/eal_filesystem.h b/lib/eal/common/eal_filesystem.h
[PATCH 1/2] lib: add helper to read strings from sysfs files
Reading strings from sysfs files is a re-occurring pattern
hence add helper for doing that.
Signed-off-by: Tomasz Duszynski
---
app/test/test_eal_fs.c | 108
lib/eal/common/eal_filesystem.h | 6 ++
lib/eal/unix/eal_filesystem.c | 24 ---
lib/eal/version.map | 1 +
4 files changed, 121 insertions(+), 18 deletions(-)
diff --git a/app/test/test_eal_fs.c b/app/test/test_eal_fs.c
index b3686edcb4..6c373fc7f1 100644
--- a/app/test/test_eal_fs.c
+++ b/app/test/test_eal_fs.c
@@ -20,12 +20,33 @@ test_eal_fs(void)
#else
+static int
+temp_create(char *filename, size_t len)
+{
+ char file_template[] = "/tmp/eal_test_XX";
+ char proc_path[PATH_MAX];
+ int fd;
+
+ fd = mkstemp(file_template);
+ if (fd == -1) {
+ perror("mkstemp() failure");
+ return -1;
+ }
+
+ snprintf(proc_path, sizeof(proc_path), "/proc/self/fd/%d", fd);
+ if (readlink(proc_path, filename, len) < 0) {
+ perror("readlink() failure");
+ close(fd);
+ return -1;
+ }
+
+ return fd;
+}
+
static int
test_parse_sysfs_value(void)
{
char filename[PATH_MAX] = "";
- char proc_path[PATH_MAX];
- char file_template[] = "/tmp/eal_test_XX";
int tmp_file_handle = -1;
FILE *fd = NULL;
unsigned valid_number;
@@ -40,16 +61,10 @@ test_parse_sysfs_value(void)
/* get a temporary filename to use for all tests - create temp file
handle and then
* use /proc to get the actual file that we can open */
- tmp_file_handle = mkstemp(file_template);
- if (tmp_file_handle == -1) {
- perror("mkstemp() failure");
+ tmp_file_handle = temp_create(filename, sizeof(filename));
+ if (tmp_file_handle < 0)
goto error;
- }
- snprintf(proc_path, sizeof(proc_path), "/proc/self/fd/%d",
tmp_file_handle);
- if (readlink(proc_path, filename, sizeof(filename)) < 0) {
- perror("readlink() failure");
- goto error;
- }
+
printf("Temporary file is: %s\n", filename);
/* test we get an error value if we use file before it's created */
@@ -175,11 +190,82 @@ test_parse_sysfs_value(void)
return -1;
}
+static int
+test_parse_sysfs_string(void)
+{
+ const char *teststr = "the quick brown dog jumps over the lazy fox\n";
+ char filename[PATH_MAX] = "";
+ char buf[BUFSIZ] = { };
+ int tmp_file_handle;
+ FILE *fd = NULL;
+
+#ifdef RTE_EXEC_ENV_FREEBSD
+ /* BSD doesn't have /proc/pid/fd */
+ return 0;
+#endif
+ printf("Testing function eal_parse_sysfs_string()\n");
+
+ /* get a temporary filename to use for all tests - create temp file
handle and then
+* use /proc to get the actual file that we can open
+*/
+ tmp_file_handle = temp_create(filename, sizeof(filename));
+ if (tmp_file_handle < 0)
+ goto error;
+
+ printf("Temporary file is: %s\n", filename);
+
+ /* test we get an error value if we use file before it's created */
+ printf("Test reading a missing file ...\n");
+ if (eal_parse_sysfs_string("/dev/not-quite-null", buf, sizeof(buf)) ==
0) {
+ printf("Error with eal_parse_sysfs_string() - returned success
on reading empty file\n");
+ goto error;
+ }
+ printf("Confirmed return error when reading empty file\n");
+
+ /* test reading a string from file */
+ printf("Test reading string ...\n");
+ fd = fopen(filename, "w");
+ if (fd == NULL) {
+ printf("line %d, Error opening %s: %s\n", __LINE__, filename,
strerror(errno));
+ goto error;
+ }
+ fprintf(fd, "%s", teststr);
+ fclose(fd);
+ fd = NULL;
+ if (eal_parse_sysfs_string(filename, buf, sizeof(buf) - 1) < 0) {
+ printf("eal_parse_sysfs_string() returned error - test
failed\n");
+ goto error;
+ }
+ if (strcmp(teststr, buf)) {
+ printf("Invalid string read by eal_parse_sysfs_string() - test
failed\n");
+ goto error;
+ }
+ /* don't print newline */
+ buf[strlen(buf) - 1] = '\0';
+ printf("Read '%s\\n' ok\n", buf);
+
+ close(tmp_file_handle);
+ unlink(filename);
+ printf("eal_parse_sysfs_string() - OK\n");
+ return 0;
+
+error:
+ if (fd)
+ fclose(fd);
+ if (tmp_file_handle > 0)
+ close(tmp_file_handle);
+ if (filename[0] != '\0')
+ unlink(filename);
+ return -1;
+}
+
static int
test_eal_fs(void)
{
if (test_parse_sysfs_value() < 0)
return -1;
+ if (test_parse_sysfs_string() < 0)
+ return -1;
return 0;
}
diff --git a/lib/eal/common/eal_filesystem.h b/lib/eal/common/eal_filesystem.h
[PATCH 0/2] add platform bus
Platform bus is a bus under Linux which manages devices that do not have any discovery-mechanism built in. Linux learns about platform devices directly from device-tree during boot-up phase. Afterwards if userspace wants to use some particular device driver being usually a mixture of vdev/rawdev gets developed. In order to simplify that introduce a DPDK platform bus which provides auto-probe experience and separates a bus logic from the driver itself. Now only devices which are backed-by vfio-platform kernel driver are supported, though other options may be added if necessary. Tomasz Duszynski (2): lib: add helper to read strings from sysfs files bus: add platform bus MAINTAINERS| 4 + app/test/test_eal_fs.c | 108 +++- doc/guides/rel_notes/release_23_03.rst | 5 + drivers/bus/meson.build| 1 + drivers/bus/platform/bus_platform_driver.h | 174 ++ drivers/bus/platform/meson.build | 16 + drivers/bus/platform/platform.c| 604 + drivers/bus/platform/platform_params.c | 70 +++ drivers/bus/platform/private.h | 48 ++ drivers/bus/platform/version.map | 10 + lib/eal/common/eal_filesystem.h| 6 + lib/eal/unix/eal_filesystem.c | 24 +- lib/eal/version.map| 1 + 13 files changed, 1053 insertions(+), 18 deletions(-) create mode 100644 drivers/bus/platform/bus_platform_driver.h create mode 100644 drivers/bus/platform/meson.build create mode 100644 drivers/bus/platform/platform.c create mode 100644 drivers/bus/platform/platform_params.c create mode 100644 drivers/bus/platform/private.h create mode 100644 drivers/bus/platform/version.map -- 2.34.1
[PATCH 2/2] bus: add platform bus
Platform bus is a software bus under Linux that manages devices which
generally do not have built-in discovery mechanisms. Linux normally
learns about platform devices directly from device-tree during
boot-up phase.
Up to this point, whenever some userspace app needed control over
platform device or a range of thereof some sort of driver being
a mixture of vdev/rawdev was required.
In order to simplify this task, provide an auto-probe
experience and separate bus logic from the driver itself,
add platform bus support.
Currently devices backed up by vfio-platform kernel driver
are supported.
Signed-off-by: Tomasz Duszynski
---
MAINTAINERS| 4 +
doc/guides/rel_notes/release_23_03.rst | 5 +
drivers/bus/meson.build| 1 +
drivers/bus/platform/bus_platform_driver.h | 174 ++
drivers/bus/platform/meson.build | 16 +
drivers/bus/platform/platform.c| 604 +
drivers/bus/platform/platform_params.c | 70 +++
drivers/bus/platform/private.h | 48 ++
drivers/bus/platform/version.map | 10 +
9 files changed, 932 insertions(+)
create mode 100644 drivers/bus/platform/bus_platform_driver.h
create mode 100644 drivers/bus/platform/meson.build
create mode 100644 drivers/bus/platform/platform.c
create mode 100644 drivers/bus/platform/platform_params.c
create mode 100644 drivers/bus/platform/private.h
create mode 100644 drivers/bus/platform/version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a0f416d2e..b02666710c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -581,6 +581,10 @@ VDEV bus driver
F: drivers/bus/vdev/
F: app/test/test_vdev.c
+Platform bus driver
+M: Tomasz Duszynski
+F: drivers/bus/platform
+
VMBUS bus driver
M: Long Li
F: drivers/bus/vmbus/
diff --git a/doc/guides/rel_notes/release_23_03.rst
b/doc/guides/rel_notes/release_23_03.rst
index 84b112a8b1..74b2b1e3ff 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -57,6 +57,11 @@ New Features
* **Added multi-process support for axgbe PMD.**
+* **Added platform bus support.**
+
+ A platform bus provides a way to use Linux platform devices which
+ are compatible with vfio-platform kernel driver.
+
* **Updated Corigine nfp driver.**
* Added support for meter options.
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index 45eab5233d..6d2520c543 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -7,6 +7,7 @@ drivers = [
'fslmc',
'ifpga',
'pci',
+'platform',
'vdev',
'vmbus',
]
diff --git a/drivers/bus/platform/bus_platform_driver.h
b/drivers/bus/platform/bus_platform_driver.h
new file mode 100644
index 00..8291c7f3f6
--- /dev/null
+++ b/drivers/bus/platform/bus_platform_driver.h
@@ -0,0 +1,174 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#ifndef _BUS_PLATFORM_DRIVER_H_
+#define _BUS_PLATFORM_DRIVER_H_
+
+/**
+ * @file
+ * Platform bus interface.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Forward declarations */
+struct rte_platform_bus;
+struct rte_platform_device;
+struct rte_platform_driver;
+
+/**
+ * Initialization function for the driver called during platform device
probing.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @return
+ * 0 on success, negative value otherwise.
+ */
+typedef int (rte_platform_probe_t)(struct rte_platform_device *pdev);
+
+/**
+ * Removal function for the driver called during platform device removal.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @return
+ * 0 on success, negative value otherwise.
+ */
+typedef int (rte_platform_remove_t)(struct rte_platform_device *pdev);
+
+/**
+ * Driver specific DMA mapping.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @param addr
+ * Starting virtual address of memory to be mapped.
+ * @param iova
+ * Starting IOVA address of memory to be mapped.
+ * @param len
+ * Length of memory segment being mapped.
+ * @return
+ * - 0 on success, negative value and rte_errno is set otherwise.
+ */
+typedef int (rte_platform_dma_map_t)(struct rte_platform_device *pdev, void
*addr, uint64_t iova,
+size_t len);
+
+/**
+ * Driver specific DMA unmapping.
+ *
+ * @param pdev
+ * Pointer to the platform device.
+ * @param addr
+ * Starting virtual address of memory to be mapped.
+ * @param iova
+ * Starting IOVA address of memory to be mapped.
+ * @param len
+ * Length of memory segment being mapped.
+ * @return
+ * - 0 on success, negative value and rte_errno is set otherwise.
+ */
+typedef int (rte_platform_dma_unmap_t)(struct rte_platform_device *pdev, void
*addr, uint64_t iova,
+ size_t len);
+
+/**
+ * A structure describing a platform devic
Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V
wrote:
>
> Hi Jerin,
>
> > -Original Message-
> > From: Jerin Jacob
> > Sent: Wednesday, January 25, 2023 9:42 AM
> > To: Naga Harish K, S V
> > Cc: jer...@marvell.com; Carrillo, Erik G ;
> > Gujjar,
> > Abhinandan S ; dev@dpdk.org;
> > Jayatheerthan, Jay
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> > wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -Original Message-
> > > > From: Jerin Jacob
> > > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > > To: Naga Harish K, S V
> > > > Cc: jer...@marvell.com; Carrillo, Erik G
> > > > ; Gujjar, Abhinandan S
> > > > ; dev@dpdk.org; Jayatheerthan, Jay
> > > >
> > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > > wrote:
> > > > >
> > > > > The adapter configuration parameters defined in the ``struct
> > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured and
> > > > > retrieved using ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > > and ``rte_event_eth_tx_adapter_runtime_params_get`` respectively.
> > > > >
> > > > > Signed-off-by: Naga Harish K S V
> > > >
> > > > > diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > index 461eca566f..2207d6ffc3 100644
> > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > @@ -185,6 +185,26 @@ flags for handling received packets, event
> > > > > queue identifier, scheduler type, event priority, polling
> > > > > frequency of the receive queue and flow identifier in struct
> > > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > > >
> > > > > +Set/Get adapter runtime configuration parameters
> > > > > +
> > > > > +
> > > > > +The runtime configuration parameters of adapter can be set/read
> > > > > +using ``rte_event_eth_rx_adapter_runtime_params_set()`` and
> > > > > +``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > > +The parameters that can be set/read are defined in ``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures the
> > > > > +adapter with default value for maximum packets processed per
> > > > > +request to
> > > > 128.
> > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function allows
> > > > > +to reconfigure maximum number of packets processed by adapter per
> > > > > +service request. This is alternative to configuring the maximum
> > > > > +packets processed per request by adapter by using
> > > > > +``rte_event_eth_rx_adapter_create_ext()`` with parameter
> > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > > >
> > > > This paragraph is not needed IMO. As it is specific to a driver, and
> > > > we can keep Doxygen comment only.
> > > >
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > > +retrieves the configuration parameters that are defined in
> > > > > +``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > Getting and resetting Adapter queue stats
> > > > > ~
> > > > >
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > index 34aa87379e..d8f3e750b7 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > @@ -35,6 +35,8 @@
> > > > > #define MAX_VECTOR_NS 1E9
> > > > > #define MIN_VECTOR_NS 1E5
> > > > >
> > > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > > +
> > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN32
> > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN32
> > > > >
> > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> > dev_id,
> > > > > }
> > > > >
> > > > > conf->event_port_id = port_id;
> > > > > - conf->max_nb_rx = 128;
> > > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > > if (started)
> > > > > ret = rte_event_dev_start(dev_id);
> > > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > > return -EINVAL;
> > > > > }
> > > >
> > > > > +
> > > > > +int
> > > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > +*params) {
> > > > > + struct event_eth_rx_adapter *rxa;
> > > > > + int ret;
> > > > > +
> > >
Re: [PATCH 1/2] lib: add helper to read strings from sysfs files
25/01/2023 11:33, Tomasz Duszynski: > Reading strings from sysfs files is a re-occurring pattern > hence add helper for doing that. In general it would be to nice to clean sysfs parsing in libs and drivers, so they all use some functions from EAL.
RE: [PATCH 0/2] add platform bus
This was mistakenly appended to this thread - ignore it. I've just sent the series again. >-Original Message- >From: Tomasz Duszynski >Sent: Wednesday, January 25, 2023 11:33 AM >To: dev@dpdk.org >Cc: tho...@monjalon.net; Jerin Jacob Kollanukkaran ; >step...@networkplumber.org; chenbo@intel.com; Tomasz Duszynski > >Subject: [PATCH 0/2] add platform bus > >Platform bus is a bus under Linux which manages devices that do not have any >discovery-mechanism >built in. Linux learns about platform devices directly from device-tree during >boot-up phase. > >Afterwards if userspace wants to use some particular device driver being >usually a mixture of >vdev/rawdev gets developed. > >In order to simplify that introduce a DPDK platform bus which provides >auto-probe experience and >separates a bus logic from the driver itself. > >Now only devices which are backed-by vfio-platform kernel driver are >supported, though other >options may be added if necessary. > >Tomasz Duszynski (2): > lib: add helper to read strings from sysfs files > bus: add platform bus > > MAINTAINERS| 4 + > app/test/test_eal_fs.c | 108 +++- > doc/guides/rel_notes/release_23_03.rst | 5 + > drivers/bus/meson.build| 1 + > drivers/bus/platform/bus_platform_driver.h | 174 ++ > drivers/bus/platform/meson.build | 16 + > drivers/bus/platform/platform.c| 604 + > drivers/bus/platform/platform_params.c | 70 +++ > drivers/bus/platform/private.h | 48 ++ > drivers/bus/platform/version.map | 10 + > lib/eal/common/eal_filesystem.h| 6 + > lib/eal/unix/eal_filesystem.c | 24 +- > lib/eal/version.map| 1 + > 13 files changed, 1053 insertions(+), 18 deletions(-) create mode 100644 >drivers/bus/platform/bus_platform_driver.h > create mode 100644 drivers/bus/platform/meson.build create mode 100644 >drivers/bus/platform/platform.c create mode 100644 >drivers/bus/platform/platform_params.c > create mode 100644 drivers/bus/platform/private.h create mode 100644 >drivers/bus/platform/version.map > >-- >2.34.1
[PATCH v3 1/4] common/cnxk: restructure for cn10k datapath
Restructure for separate datapath functionality to reduce
recompilation time.
New *_dp.h are created to have macros, functions as required
for datapath.
Signed-off-by: Rahul Bhansali
---
Changes in v3: No change.
Changes in v2: Rebased to next-net-mrvl, No code changes.
drivers/common/cnxk/roc_api.h| 6 +--
drivers/common/cnxk/roc_nix_inl.h| 49
drivers/common/cnxk/roc_nix_inl_dp.h | 57
drivers/common/cnxk/roc_npa.h| 25
drivers/common/cnxk/roc_npa_dp.h | 34 +
drivers/common/cnxk/roc_sso.h| 25
drivers/common/cnxk/roc_sso_dp.h | 33
7 files changed, 127 insertions(+), 102 deletions(-)
create mode 100644 drivers/common/cnxk/roc_nix_inl_dp.h
create mode 100644 drivers/common/cnxk/roc_npa_dp.h
create mode 100644 drivers/common/cnxk/roc_sso_dp.h
diff --git a/drivers/common/cnxk/roc_api.h b/drivers/common/cnxk/roc_api.h
index 14a11321e0..9d7f5417c2 100644
--- a/drivers/common/cnxk/roc_api.h
+++ b/drivers/common/cnxk/roc_api.h
@@ -18,9 +18,6 @@
/* ROC Constants */
#include "roc_constants.h"
-/* Constants */
-#define PLT_ETHER_ADDR_LEN 6
-
/* Platform definition */
#include "roc_platform.h"
@@ -54,6 +51,7 @@
#include "roc_mbox.h"
/* NPA */
+#include "roc_npa_dp.h"
#include "roc_npa.h"
/* NPC */
@@ -63,6 +61,7 @@
#include "roc_nix.h"
/* SSO */
+#include "roc_sso_dp.h"
#include "roc_sso.h"
/* TIM */
@@ -105,6 +104,7 @@
#include "roc_hash.h"
/* NIX Inline dev */
+#include "roc_nix_inl_dp.h"
#include "roc_nix_inl.h"
#endif /* _ROC_API_H_ */
diff --git a/drivers/common/cnxk/roc_nix_inl.h
b/drivers/common/cnxk/roc_nix_inl.h
index 99d1281169..220663568e 100644
--- a/drivers/common/cnxk/roc_nix_inl.h
+++ b/drivers/common/cnxk/roc_nix_inl.h
@@ -40,27 +40,6 @@
(ROC_NIX_INL_ON_IPSEC_OUTB_HW_SZ + ROC_NIX_INL_ON_IPSEC_OUTB_SW_RSVD)
#define ROC_NIX_INL_ON_IPSEC_OUTB_SA_SZ_LOG2 9
-/* OT INB HW area */
-#define ROC_NIX_INL_OT_IPSEC_INB_HW_SZ
\
- PLT_ALIGN(sizeof(struct roc_ot_ipsec_inb_sa), ROC_ALIGN)
-/* OT INB SW reserved area */
-#define ROC_NIX_INL_OT_IPSEC_INB_SW_RSVD 128
-#define ROC_NIX_INL_OT_IPSEC_INB_SA_SZ
\
- (ROC_NIX_INL_OT_IPSEC_INB_HW_SZ + ROC_NIX_INL_OT_IPSEC_INB_SW_RSVD)
-#define ROC_NIX_INL_OT_IPSEC_INB_SA_SZ_LOG2 10
-
-/* OT OUTB HW area */
-#define ROC_NIX_INL_OT_IPSEC_OUTB_HW_SZ
\
- PLT_ALIGN(sizeof(struct roc_ot_ipsec_outb_sa), ROC_ALIGN)
-/* OT OUTB SW reserved area */
-#define ROC_NIX_INL_OT_IPSEC_OUTB_SW_RSVD 128
-#define ROC_NIX_INL_OT_IPSEC_OUTB_SA_SZ
\
- (ROC_NIX_INL_OT_IPSEC_OUTB_HW_SZ + ROC_NIX_INL_OT_IPSEC_OUTB_SW_RSVD)
-#define ROC_NIX_INL_OT_IPSEC_OUTB_SA_SZ_LOG2 9
-
-/* Alignment of SA Base */
-#define ROC_NIX_INL_SA_BASE_ALIGN BIT_ULL(16)
-
#define ROC_NIX_INL_SA_SOFT_EXP_ERR_MAX_POLL_COUNT 25
#define ROC_NIX_SOFT_EXP_ERR_RING_MAX_ENTRY_LOG2 16
@@ -135,34 +114,6 @@ roc_nix_inl_onf_ipsec_outb_sa_sw_rsvd(void *sa)
return PLT_PTR_ADD(sa, ROC_NIX_INL_ONF_IPSEC_OUTB_HW_SZ);
}
-static inline struct roc_ot_ipsec_inb_sa *
-roc_nix_inl_ot_ipsec_inb_sa(uintptr_t base, uint64_t idx)
-{
- uint64_t off = idx << ROC_NIX_INL_OT_IPSEC_INB_SA_SZ_LOG2;
-
- return PLT_PTR_ADD(base, off);
-}
-
-static inline struct roc_ot_ipsec_outb_sa *
-roc_nix_inl_ot_ipsec_outb_sa(uintptr_t base, uint64_t idx)
-{
- uint64_t off = idx << ROC_NIX_INL_OT_IPSEC_OUTB_SA_SZ_LOG2;
-
- return PLT_PTR_ADD(base, off);
-}
-
-static inline void *
-roc_nix_inl_ot_ipsec_inb_sa_sw_rsvd(void *sa)
-{
- return PLT_PTR_ADD(sa, ROC_NIX_INL_OT_IPSEC_INB_HW_SZ);
-}
-
-static inline void *
-roc_nix_inl_ot_ipsec_outb_sa_sw_rsvd(void *sa)
-{
- return PLT_PTR_ADD(sa, ROC_NIX_INL_OT_IPSEC_OUTB_HW_SZ);
-}
-
/* Inline device SSO Work callback */
typedef void (*roc_nix_inl_sso_work_cb_t)(uint64_t *gw, void *args,
uint32_t soft_exp_event);
diff --git a/drivers/common/cnxk/roc_nix_inl_dp.h
b/drivers/common/cnxk/roc_nix_inl_dp.h
new file mode 100644
index 00..a9d8e0a705
--- /dev/null
+++ b/drivers/common/cnxk/roc_nix_inl_dp.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2022 Marvell.
+ */
+#ifndef _ROC_NIX_INL_DP_H_
+#define _ROC_NIX_INL_DP_H_
+
+/* OT INB HW area */
+#define ROC_NIX_INL_OT_IPSEC_INB_HW_SZ
\
+ PLT_ALIGN(sizeof(struct roc_ot_ipsec_inb_sa), ROC_ALIGN)
+/* OT INB SW reserved area */
+#define ROC_NIX_INL_OT_IPSEC_INB_SW_RSVD 128
+#define ROC_NIX_INL_OT_IPSEC_INB_SA_SZ
\
+ (ROC_NIX_INL_OT_IPSEC_INB_HW_SZ + ROC_NIX_INL_OT_IPSEC_INB_SW_RSVD)
+#define ROC_NIX_INL_OT_IPSEC_INB_SA_SZ_LOG2 10
+
+/* OT OUTB HW area */
+#define ROC_NIX_INL_OT_IPSEC_OUTB_HW_SZ
[PATCH v3 2/4] crypto/cnxk: restructure for cn10k datapath
From: Anoob Joseph
Inclusion of roc_api.h in all files would mean any change in RoC API
would result in recompilation of all cnxk drivers. Address this issue in
crypto_cnxk drivers by including only the headers that are required.
Signed-off-by: Anoob Joseph
---
Changes in v3: Reorder patch in series for compilation fix.
Changes in v2: Updated git comment subject.
drivers/common/cnxk/cnxk_security.h | 3 +-
drivers/common/cnxk/hw/cpt.h | 30 +++
drivers/common/cnxk/roc_ae_fpm_tables.h | 2 +-
drivers/common/cnxk/roc_cpt.h | 6 +++-
drivers/common/cnxk/roc_ie_ot.h | 2 ++
drivers/common/cnxk/roc_io_generic.h | 2 ++
drivers/common/cnxk/roc_mbox.h| 35 ++-
drivers/common/cnxk/roc_model.h | 2 ++
drivers/common/cnxk/roc_npa.c | 2 +-
drivers/common/cnxk/roc_npa.h | 13 +
drivers/common/cnxk/roc_platform.h| 7 +
drivers/common/cnxk/roc_sso.h | 2 ++
drivers/common/cnxk/roc_tim.h | 2 ++
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 11 +--
drivers/crypto/cnxk/cn10k_ipsec.h | 3 +-
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 9 ++
drivers/crypto/cnxk/cn9k_ipsec_la_ops.h | 2 ++
drivers/crypto/cnxk/cnxk_ae.h | 3 +-
drivers/crypto/cnxk/cnxk_cryptodev.c | 1 +
drivers/crypto/cnxk/cnxk_cryptodev_ops.c | 2 ++
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 7 -
drivers/crypto/cnxk/cnxk_ipsec.h | 4 ++-
drivers/crypto/cnxk/cnxk_sg.h | 2 ++
drivers/event/cnxk/cnxk_eventdev.c| 2 ++
drivers/event/cnxk/cnxk_eventdev.h| 5 +++-
drivers/event/cnxk/cnxk_tim_evdev.c | 2 ++
drivers/event/cnxk/cnxk_tim_evdev.h | 5 +++-
drivers/event/cnxk/cnxk_worker.h | 6
drivers/net/octeon_ep/meson.build | 2 ++
29 files changed, 130 insertions(+), 44 deletions(-)
diff --git a/drivers/common/cnxk/cnxk_security.h
b/drivers/common/cnxk/cnxk_security.h
index 4e477ec53f..2277ce9144 100644
--- a/drivers/common/cnxk/cnxk_security.h
+++ b/drivers/common/cnxk/cnxk_security.h
@@ -7,7 +7,8 @@
#include
#include
-#include "roc_api.h"
+#include "roc_ie_on.h"
+#include "roc_ie_ot.h"
/* Response length calculation data */
struct cnxk_ipsec_outb_rlens {
diff --git a/drivers/common/cnxk/hw/cpt.h b/drivers/common/cnxk/hw/cpt.h
index 30f2af3cd9..d378a4eadd 100644
--- a/drivers/common/cnxk/hw/cpt.h
+++ b/drivers/common/cnxk/hw/cpt.h
@@ -5,6 +5,8 @@
#ifndef __CPT_HW_H__
#define __CPT_HW_H__
+#include "roc_platform.h"
+
/* Register offsets */
#define CPT_COMP_NOT_DONE (0x0ull)
@@ -47,8 +49,36 @@
#define CPT_AF_LFX_CTL(a) (0x27000ull | (uint64_t)(a) << 3)
#define CPT_AF_LFX_CTL2(a) (0x29000ull | (uint64_t)(a) << 3)
+enum cpt_eng_type {
+ CPT_ENG_TYPE_AE = 1,
+ CPT_ENG_TYPE_SE = 2,
+ CPT_ENG_TYPE_IE = 3,
+ CPT_MAX_ENG_TYPES,
+};
+
/* Structures definitions */
+/* CPT HW capabilities */
+union cpt_eng_caps {
+ uint64_t __io u;
+ struct {
+ uint64_t __io reserved_0_4 : 5;
+ uint64_t __io mul : 1;
+ uint64_t __io sha1_sha2 : 1;
+ uint64_t __io chacha20 : 1;
+ uint64_t __io zuc_snow3g : 1;
+ uint64_t __io sha3 : 1;
+ uint64_t __io aes : 1;
+ uint64_t __io kasumi : 1;
+ uint64_t __io des : 1;
+ uint64_t __io crc : 1;
+ uint64_t __io mmul : 1;
+ uint64_t __io reserved_15_33 : 19;
+ uint64_t __io pdcp_chain : 1;
+ uint64_t __io reserved_35_63 : 29;
+ };
+};
+
union cpt_lf_ctl {
uint64_t u;
struct cpt_lf_ctl_s {
diff --git a/drivers/common/cnxk/roc_ae_fpm_tables.h
b/drivers/common/cnxk/roc_ae_fpm_tables.h
index 1cc5b023f2..98b00bcf14 100644
--- a/drivers/common/cnxk/roc_ae_fpm_tables.h
+++ b/drivers/common/cnxk/roc_ae_fpm_tables.h
@@ -5,7 +5,7 @@
#ifndef _ROC_AE_FPM_TABLES_H_
#define _ROC_AE_FPM_TABLES_H_
-#include "roc_api.h"
+#include "roc_platform.h"
int __roc_api roc_ae_fpm_get(uint64_t *tbl);
void __roc_api roc_ae_fpm_put(void);
diff --git a/drivers/common/cnxk/roc_cpt.h b/drivers/common/cnxk/roc_cpt.h
index 96d066dee3..2fa1abad16 100644
--- a/drivers/common/cnxk/roc_cpt.h
+++ b/drivers/common/cnxk/roc_cpt.h
@@ -5,7 +5,11 @@
#ifndef _ROC_CPT_H_
#define _ROC_CPT_H_
-#include "roc_api.h"
+#include "hw/cpt.h"
+
+#include "roc_platform.h"
+
+struct nix_inline_ipsec_cfg;
#define ROC_AE_CPT_BLOCK_TYPE1 0
#define ROC_AE_CPT_BLOCK_TYPE2 1
diff --git a/drivers/common/cnxk/roc_ie_ot.h b/drivers/common/cnxk/roc_ie_ot.h
index e53ee28aff..b7fcdf9ba7 100644
--- a/drivers/common/cnxk/roc_ie_ot.h
+++ b/drivers/common/cnxk/roc_ie_ot.h
@@ -5,6 +5,8 @@
#ifndef __ROC_IE_OT_H__
#define __ROC_IE_OT_H__
+#include "roc_platform.h"
+
/* CN10K IPSEC opcodes */
#define ROC_IE_OT_MAJOR_OP_PROCESS_
[PATCH v3 3/4] net/cnxk: restructure for cn10k datapath
Restructure for separate cn10k datapath functionality to reduce
recompilation time in case of any changes in control path.
New cnxk_ethdev_dp.h and cn10k_rxtx.h files are created to have
macros, functions as required for datapath with minimal dependency
on roc changes.
Signed-off-by: Rahul Bhansali
---
Changes in v3: Reorder patch in series for compilation fix.
Changes in v2: No changes.
drivers/net/cnxk/cn10k_ethdev.h | 71 +---
drivers/net/cnxk/cn10k_rx.h | 5 +-
drivers/net/cnxk/cn10k_rxtx.h | 116
drivers/net/cnxk/cn10k_tx.h | 2 +-
drivers/net/cnxk/cnxk_ethdev.h| 157 +---
drivers/net/cnxk/cnxk_ethdev_dp.h | 167 ++
drivers/net/cnxk/rx/cn10k/rx_0_15.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_0_15_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_0_15_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_0_15_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_112_127.c| 5 +-
drivers/net/cnxk/rx/cn10k/rx_112_127_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_112_127_vec.c| 5 +-
.../net/cnxk/rx/cn10k/rx_112_127_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_16_31.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_16_31_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_16_31_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_16_31_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_32_47.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_32_47_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_32_47_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_32_47_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_48_63.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_48_63_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_48_63_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_48_63_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_64_79.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_64_79_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_64_79_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_64_79_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_80_95.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_80_95_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_80_95_vec.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_80_95_vec_mseg.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_96_111.c | 5 +-
drivers/net/cnxk/rx/cn10k/rx_96_111_mseg.c| 5 +-
drivers/net/cnxk/rx/cn10k/rx_96_111_vec.c | 5 +-
.../net/cnxk/rx/cn10k/rx_96_111_vec_mseg.c| 5 +-
drivers/net/cnxk/tx/cn10k/tx_0_15.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_0_15_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_0_15_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_0_15_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_112_127.c| 5 +-
drivers/net/cnxk/tx/cn10k/tx_112_127_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_112_127_vec.c| 5 +-
.../net/cnxk/tx/cn10k/tx_112_127_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_16_31.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_16_31_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_16_31_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_16_31_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_32_47.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_32_47_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_32_47_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_32_47_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_48_63.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_48_63_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_48_63_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_48_63_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_64_79.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_64_79_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_64_79_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_64_79_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_80_95.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_80_95_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_80_95_vec.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_80_95_vec_mseg.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_96_111.c | 5 +-
drivers/net/cnxk/tx/cn10k/tx_96_111_mseg.c| 5 +-
drivers/net/cnxk/tx/cn10k/tx_96_111_vec.c | 5 +-
.../net/cnxk/tx/cn10k/tx_96_111_vec_mseg.c| 5 +-
70 files changed, 545 insertions(+), 293 deletions(-)
create mode 100644 drivers/net/cnxk/cn10k_rxtx.h
create mode 100644 drivers/net/cnxk/cnxk_ethdev_dp.h
diff --git a/drivers/net/cnxk/cn10k_ethdev.h b/drivers/net/cnxk/cn10k_ethdev.h
index c843ba9881..55d7f88716 100644
--- a/drivers/net/cnxk/cn10k_ethdev.h
+++ b/drivers/net/cnxk/cn10k_ethdev.h
@@ -6,52 +6,7 @@
#include
#include
-
-struct cn10k_eth_txq {
- uint64_t send_hdr_w0;
- int64_t fc_cache_pkts;
- uint64_t *fc_mem;
- uintptr_t lmt_base;
- rte_iova_t io_addr;
- uint16_t sqes_per_sqb_log2;
- int16_t nb_sqb_bufs_adj;
- r
[PATCH v3 4/4] event/cnxk: restructure for cn10k datapath
Restructure for separate cn10k datapath functionality to reduce recompilation time in case of any changes in control path. New *_dp.h files are created to have macros, functions as required for datapath with minimal dependency on roc changes. Separates Tx and Rx datapath files to save recompilation time for independent changes. In case of Roc changes independent to datapath, the overall recompilation time is reduced from ~6 mins to ~17 secs. Signed-off-by: Rahul Bhansali --- Changes in v3: Reorder patch in series for compilation fix. Changes in v2: No changes. .../crypto/cnxk/cn10k_cryptodev_event_dp.h| 13 + drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 2 + drivers/crypto/cnxk/cn10k_cryptodev_ops.h | 4 - drivers/event/cnxk/cn10k_eventdev.c | 3 + drivers/event/cnxk/cn10k_eventdev.h | 28 ++ drivers/event/cnxk/cn10k_tx_worker.h | 254 ++ drivers/event/cnxk/cn10k_worker.c | 71 drivers/event/cnxk/cn10k_worker.h | 327 +- drivers/event/cnxk/cnxk_eventdev.c| 1 + drivers/event/cnxk/cnxk_eventdev.h| 44 +-- drivers/event/cnxk/cnxk_eventdev_dp.h | 33 ++ drivers/event/cnxk/cnxk_eventdev_selftest.c | 1 + drivers/event/cnxk/cnxk_eventdev_stats.c | 1 + drivers/event/cnxk/cnxk_worker.h | 3 +- drivers/event/cnxk/deq/cn10k/deq_0_15.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_0_15_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_0_15_ca.c| 6 +- .../event/cnxk/deq/cn10k/deq_0_15_ca_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_0_15_ca_seg.c| 6 +- .../cnxk/deq/cn10k/deq_0_15_ca_seg_burst.c| 6 +- .../event/cnxk/deq/cn10k/deq_0_15_ca_tmo.c| 6 +- .../cnxk/deq/cn10k/deq_0_15_ca_tmo_burst.c| 6 +- .../cnxk/deq/cn10k/deq_0_15_ca_tmo_seg.c | 6 +- .../deq/cn10k/deq_0_15_ca_tmo_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_0_15_dual.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_0_15_seg.c | 6 +- .../event/cnxk/deq/cn10k/deq_0_15_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_0_15_tmo.c | 6 +- .../event/cnxk/deq/cn10k/deq_0_15_tmo_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_0_15_tmo_seg.c | 6 +- .../cnxk/deq/cn10k/deq_0_15_tmo_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_112_127.c| 6 +- .../event/cnxk/deq/cn10k/deq_112_127_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_112_127_ca.c | 6 +- .../cnxk/deq/cn10k/deq_112_127_ca_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_112_127_ca_seg.c | 6 +- .../cnxk/deq/cn10k/deq_112_127_ca_seg_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_112_127_ca_tmo.c | 6 +- .../cnxk/deq/cn10k/deq_112_127_ca_tmo_burst.c | 6 +- .../cnxk/deq/cn10k/deq_112_127_ca_tmo_seg.c | 6 +- .../deq/cn10k/deq_112_127_ca_tmo_seg_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_112_127_dual.c | 6 +- .../event/cnxk/deq/cn10k/deq_112_127_seg.c| 6 +- .../cnxk/deq/cn10k/deq_112_127_seg_burst.c| 6 +- .../event/cnxk/deq/cn10k/deq_112_127_tmo.c| 6 +- .../cnxk/deq/cn10k/deq_112_127_tmo_burst.c| 6 +- .../cnxk/deq/cn10k/deq_112_127_tmo_seg.c | 6 +- .../deq/cn10k/deq_112_127_tmo_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_16_31.c | 6 +- .../event/cnxk/deq/cn10k/deq_16_31_burst.c| 6 +- drivers/event/cnxk/deq/cn10k/deq_16_31_ca.c | 6 +- .../event/cnxk/deq/cn10k/deq_16_31_ca_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_16_31_ca_seg.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_ca_seg_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_16_31_ca_tmo.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_ca_tmo_burst.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_ca_tmo_seg.c | 6 +- .../deq/cn10k/deq_16_31_ca_tmo_seg_burst.c| 6 +- drivers/event/cnxk/deq/cn10k/deq_16_31_dual.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_16_31_seg.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_16_31_tmo.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_tmo_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_16_31_tmo_seg.c | 6 +- .../cnxk/deq/cn10k/deq_16_31_tmo_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_32_47.c | 6 +- .../event/cnxk/deq/cn10k/deq_32_47_burst.c| 6 +- drivers/event/cnxk/deq/cn10k/deq_32_47_ca.c | 6 +- .../event/cnxk/deq/cn10k/deq_32_47_ca_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_32_47_ca_seg.c | 6 +- .../cnxk/deq/cn10k/deq_32_47_ca_seg_burst.c | 6 +- .../event/cnxk/deq/cn10k/deq_32_47_ca_tmo.c | 6 +- .../cnxk/deq/cn10k/deq_32_47_ca_tmo_burst.c | 6 +- .../cnxk/deq/cn10k/deq_32_47_ca_tmo_seg.c | 6 +- .../deq/cn10k/deq_32_47_ca_tmo_seg_burst.c| 6 +- drivers/event/cnxk/deq/cn10k/deq_32_47_dual.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_32_47_seg.c | 6 +- .../cnxk/deq/cn10k/deq_32_47_seg_burst.c | 6 +- drivers/event/cnxk/deq/cn10k/deq_
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
19/01/2023 11:33, Hanumanth Reddy Pothula: > From: Thomas Monjalon > > 21/12/2022 03:07, Hanumanth Pothula: > > > Presently, Rx metadata is sent to PMD by default, leading to a > > > performance drop as processing for the same in Rx path takes extra > > > cycles. > > > > > > Hence, add new testpmd command, > > > 'enable port nic_to_pmd_rx_metadata' > > > > > > This command helps in sending Rx metadata to PMD and thereby Rx > > > metadata flow command requests are processed. > > > > > > Signed-off-by: Hanumanth Pothula > > > > As said in previous versions, please don't add such option in testpmd. > > The problem is somewhere else, probably in your driver. > > You should make sure your driver is not sending metadata if not needed. > > By the way you didn't reply to the last comments on v3 in December. > > > I added following comment on V4, > - As per spec rte_eth_rx_metadata_negotiate() is processed only > when dev_configured is set. Not exactly. It is said " Invoke this API before the first rte_eth_dev_configure() invocation to let the PMD make preparations that are inconvenient to do later. " > Hence can't enable(Rx metadata negotiation) > automatically when a flow command requests metadata. This sentence does not make any sense. First you negotiate to prepare the feature. Later you enable per flow. > - Add new testpmd command to allow NIC to PMD Rx metadata negotiation. > > As we can't enable Rx metadata negotiation on fly, > introduced new testpmd command to enable Rx metadata negotiation > by resetting the ports. You can enable on the fly. Fix your driver.
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
25/01/2023 10:30, Hanumanth Reddy Pothula: > ++ Ivan Malov and Andrew Rybchenko > > From: Ferruh Yigit > > On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: > > > Presently, Rx metadata is sent to PMD by default, leading to a > > > performance drop as processing for the same in Rx path takes extra > > > cycles. > > > > > > Hence, add new testpmd command, > > > 'enable port nic_to_pmd_rx_metadata' > > > > > > This command helps in sending Rx metadata to PMD and thereby Rx > > > metadata flow command requests are processed. > > > > > > Signed-off-by: Hanumanth Pothula > > > > Hi Hanumanth, > > > > I agree with Thomas for the patch. > > > > 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be > > enabled, but at this stage if there is no flow rule for Rx metadata why it > > is > > consuming extra cycles? > > > > Can you update driver code to process Rx metadata when it is enabled by > > application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least > > one flow rule for it? > > #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is always > called by testpmd. > We thought it was added so that when that metadata is not needed, application > need not call this > thereby saving cycles/bandwidth. testpmd is for testing all features. That's why all is negotiated. Cycles should be saved if you don't enable it until a flow rule requires it. > #2 We use this API similar to Rx/Tx offload flags so that we can set things > up before device is > configured. We thought that is the purpose of having this negotiate API and > avoid depleting offload flags. It is just a configuration negotiation specific to metadata. > #3 Generally any new offloads added to DPDK would be in disabled state in > testpmd and we would have > an option to enable it. In this case, testpmd is by default calling this > negotiation. Negotiating is not enabling. > We can update the driver if the purpose of this API is clear. Please do.
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
On 1/25/2023 9:30 AM, Hanumanth Reddy Pothula wrote: > ++ Ivan Malov and Andrew Rybchenko > >> -Original Message- >> From: Ferruh Yigit >> Sent: Tuesday, January 24, 2023 11:34 PM >> To: Hanumanth Reddy Pothula ; Aman Singh >> ; Yuying Zhang >> Cc: dev@dpdk.org; andrew.rybche...@oktetlabs.ru; >> viachesl...@nvidia.com; Jerin Jacob Kollanukkaran ; >> Nithin Kumar Dabilpuram >> Subject: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process >> Rx metadata negotiation >> >> External Email >> >> -- >> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: >>> Presently, Rx metadata is sent to PMD by default, leading to a >>> performance drop as processing for the same in Rx path takes extra >>> cycles. >>> >>> Hence, add new testpmd command, >>> 'enable port nic_to_pmd_rx_metadata' >>> >>> This command helps in sending Rx metadata to PMD and thereby Rx >>> metadata flow command requests are processed. >>> >>> Signed-off-by: Hanumanth Pothula >> >> Hi Hanumanth, >> >> I agree with Thomas for the patch. >> >> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be >> enabled, but at this stage if there is no flow rule for Rx metadata why it is >> consuming extra cycles? >> >> Can you update driver code to process Rx metadata when it is enabled by >> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least >> one flow rule for it? > > #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is always > called by testpmd. > We thought it was added so that when that metadata is not needed, application > need not call this > thereby saving cycles/bandwidth. > Purpose looks like to 'negotiate', so it is both ways: a) To learn Rx Meta capability of HW b) To configure Rx Meta feature for HW So it is both to help application to learn what flow rule is supported and to help driver to improve performance. Before this API application assumed all Rx metadata flow rules are supported, so why enabling all causing performance drop, that was the default without this API. But other-way around can be true, to disable some offloads can improve driver performance. Looking again, > #2 We use this API similar to Rx/Tx offload flags so that we can set things > up before device is > configured. We thought that is the purpose of having this negotiate API and > avoid depleting offload flags. > > #3 Generally any new offloads added to DPDK would be in disabled state in > testpmd and we would have > an option to enable it. In this case, testpmd is by default calling this > negotiation. > > We can update the driver if the purpose of this API is clear. Hi Hanumanth, After looking the history of the API again, you may be right. One of the previous version commit log describes the intention better [1], because of negative performance impact of enabling Rx metadata offload by default and difficulty to switch configuration dynamically, there is a desire to learn application intention before configuration. Although I have some concerns with this API [2] it is already there as stable API. So it sounds reasonable to make this configurable for a test application, indeed intention of the API is to get this configuration from application and operate based on it. Next question is what should be the default value, I am not sure about it, there are only a few drivers impacted from this overall. For the Thomas' point, it helps to test the feature of its impact if it is enabled by default. Will it work to enable them all by default and add capability to disable it in testpmd, which helps to run performance tests also to verify the impact of the API? Thanks, ferruh [1] https://inbox.dpdk.org/dev/20210902142359.28138-2-ivan.ma...@oktetlabs.ru/ [2] API does two things: a) Learn Rx Meta capability of HW b) Configure Rx Meta feature for HW Functionality (a) conflicts with rest of the flow rules that capability checked via `rte_flow_validate()` API. Functionality (b) conflicts with configuring flow actions, this configuration should be controlled by flow rule not with a specific API, although I understand the reasoning behind the API. RSS_HASH offload seems given example in the discussions but it is still controlled via offload flag, there is no specific API to configure RSS hash functionality, same could be done here. [/2]
Re: [PATCH v3 0/4] implementation of ML common code
20/12/2022 18:52, Srikanth Yalavarthi: > Machine Learning common code > > > This patch series implements the common ML code that can be used by > ML drivers. Common code include functions to convert ML IO type to > string, IO format type to string, function get size of ML IO type, > and functions for converting data types from higher precision to > lower precision and vice-versa. I'm not sure about the path of this code. In general we implement drivers helper in the same directory as the driver and mark it as internal. Would it work here? > drivers/common/meson.build | 1 + > drivers/common/ml/meson.build | 25 + > drivers/common/ml/ml_utils.c| 118 > drivers/common/ml/ml_utils.h| 283 + > drivers/common/ml/ml_utils_neon.c | 873 > drivers/common/ml/ml_utils_scalar.c | 720 +++ > drivers/common/ml/version.map | 25 +
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
On 1/25/2023 1:17 PM, Ferruh Yigit wrote: > On 1/25/2023 9:30 AM, Hanumanth Reddy Pothula wrote: >> ++ Ivan Malov and Andrew Rybchenko >> >>> -Original Message- >>> From: Ferruh Yigit >>> Sent: Tuesday, January 24, 2023 11:34 PM >>> To: Hanumanth Reddy Pothula ; Aman Singh >>> ; Yuying Zhang >>> Cc: dev@dpdk.org; andrew.rybche...@oktetlabs.ru; >>> viachesl...@nvidia.com; Jerin Jacob Kollanukkaran ; >>> Nithin Kumar Dabilpuram >>> Subject: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process >>> Rx metadata negotiation >>> >>> External Email >>> >>> -- >>> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: Presently, Rx metadata is sent to PMD by default, leading to a performance drop as processing for the same in Rx path takes extra cycles. Hence, add new testpmd command, 'enable port nic_to_pmd_rx_metadata' This command helps in sending Rx metadata to PMD and thereby Rx metadata flow command requests are processed. Signed-off-by: Hanumanth Pothula >>> >>> Hi Hanumanth, >>> >>> I agree with Thomas for the patch. >>> >>> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be >>> enabled, but at this stage if there is no flow rule for Rx metadata why it >>> is >>> consuming extra cycles? >>> >>> Can you update driver code to process Rx metadata when it is enabled by >>> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least >>> one flow rule for it? >> >> #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is >> always called by testpmd. >> We thought it was added so that when that metadata is not needed, >> application need not call this >> thereby saving cycles/bandwidth. >> > > Purpose looks like to 'negotiate', so it is both ways: > a) To learn Rx Meta capability of HW > b) To configure Rx Meta feature for HW > > So it is both to help application to learn what flow rule is supported > and to help driver to improve performance. > > Before this API application assumed all Rx metadata flow rules are > supported, so why enabling all causing performance drop, that was the > default without this API. > > But other-way around can be true, to disable some offloads can improve > driver performance. > > Looking again, > please ignore this email, it has unfinished draft reply by mistake, I will send a new one. > >> #2 We use this API similar to Rx/Tx offload flags so that we can set things >> up before device is >> configured. We thought that is the purpose of having this negotiate API and >> avoid depleting offload flags. >> >> #3 Generally any new offloads added to DPDK would be in disabled state in >> testpmd and we would have >> an option to enable it. In this case, testpmd is by default calling this >> negotiation. >> >> We can update the driver if the purpose of this API is clear. > > > Hi Hanumanth, > > After looking the history of the API again, you may be right. > > One of the previous version commit log describes the intention better > [1], because of negative performance impact of enabling Rx metadata > offload by default and difficulty to switch configuration dynamically, > there is a desire to learn application intention before configuration. > > Although I have some concerns with this API [2] it is already there as > stable API. > > So it sounds reasonable to make this configurable for a test > application, indeed intention of the API is to get this configuration > from application and operate based on it. > > Next question is what should be the default value, I am not sure about > it, there are only a few drivers impacted from this overall. > For the Thomas' point, it helps to test the feature of its impact if it > is enabled by default. > > Will it work to enable them all by default and add capability to disable > it in testpmd, which helps to run performance tests also to verify the > impact of the API? > > Thanks, > ferruh > > > > [1] > https://inbox.dpdk.org/dev/20210902142359.28138-2-ivan.ma...@oktetlabs.ru/ > > > [2] > API does two things: > a) Learn Rx Meta capability of HW > b) Configure Rx Meta feature for HW > > Functionality (a) conflicts with rest of the flow rules that capability > checked via `rte_flow_validate()` API. > > Functionality (b) conflicts with configuring flow actions, this > configuration should be controlled by flow rule not with a specific API, > although I understand the reasoning behind the API. > > RSS_HASH offload seems given example in the discussions but it is still > controlled via offload flag, there is no specific API to configure RSS > hash functionality, same could be done here. > [/2]
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
On 1/25/2023 9:30 AM, Hanumanth Reddy Pothula wrote: > ++ Ivan Malov and Andrew Rybchenko > >> -Original Message- >> From: Ferruh Yigit >> Sent: Tuesday, January 24, 2023 11:34 PM >> To: Hanumanth Reddy Pothula ; Aman Singh >> ; Yuying Zhang >> Cc: dev@dpdk.org; andrew.rybche...@oktetlabs.ru; >> viachesl...@nvidia.com; Jerin Jacob Kollanukkaran ; >> Nithin Kumar Dabilpuram >> Subject: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process >> Rx metadata negotiation >> >> External Email >> >> -- >> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: >>> Presently, Rx metadata is sent to PMD by default, leading to a >>> performance drop as processing for the same in Rx path takes extra >>> cycles. >>> >>> Hence, add new testpmd command, >>> 'enable port nic_to_pmd_rx_metadata' >>> >>> This command helps in sending Rx metadata to PMD and thereby Rx >>> metadata flow command requests are processed. >>> >>> Signed-off-by: Hanumanth Pothula >> >> Hi Hanumanth, >> >> I agree with Thomas for the patch. >> >> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be >> enabled, but at this stage if there is no flow rule for Rx metadata why it is >> consuming extra cycles? >> >> Can you update driver code to process Rx metadata when it is enabled by >> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least >> one flow rule for it? > > #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is always > called by testpmd. > We thought it was added so that when that metadata is not needed, application > need not call this > thereby saving cycles/bandwidth. > > #2 We use this API similar to Rx/Tx offload flags so that we can set things > up before device is > configured. We thought that is the purpose of having this negotiate API and > avoid depleting offload flags. > > #3 Generally any new offloads added to DPDK would be in disabled state in > testpmd and we would have > an option to enable it. In this case, testpmd is by default calling this > negotiation. > > We can update the driver if the purpose of this API is clear. Hi Hanumanth, After looking the history of the API again, you may be right. One of the previous version commit log describes the intention better [1], because of negative performance impact of enabling Rx metadata offload by default and difficulty to switch configuration dynamically, there is a desire to learn application intention before configuration. Although I have some concerns with this API [2] it is already there as stable API. So it sounds reasonable to make this configurable for a test application, indeed intention of the API is to get this configuration from application and operate based on it. Next question is what should be the default value, I am not sure about it, there are only a few drivers impacted from this overall. For the Thomas' point, it helps to test the feature of its impact if it is enabled by default. Will it work to enable them all by default and add capability to disable it in testpmd, which helps to run performance tests also to verify the impact of the API? Thanks, ferruh [1] https://inbox.dpdk.org/dev/20210902142359.28138-2-ivan.ma...@oktetlabs.ru/ [2] API does two things: a) Learn Rx Meta capability of HW b) Configure Rx Meta feature for HW Functionality (a) conflicts with rest of the flow rules that capability checked via `rte_flow_validate()` API. Functionality (b) conflicts with configuring flow actions, this configuration should be controlled by flow rule not with a specific API, although I understand the reasoning behind the API. RSS_HASH offload seems given example in the discussions but it is still controlled via offload flag, there is no specific API to configure RSS hash functionality, same could be done here. [/2]
RE: [EXT] Re: [PATCH v3 0/4] implementation of ML common code
Hi, > -Original Message- > From: Thomas Monjalon > Sent: 25 January 2023 18:48 > To: Shivah Shankar Shankar Narayan Rao > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anup > Prabhu ; Srikanth Yalavarthi > ; ferruh.yi...@amd.com; > bruce.richard...@intel.com; david.march...@redhat.com > Subject: [EXT] Re: [PATCH v3 0/4] implementation of ML common code > > External Email > > -- > 20/12/2022 18:52, Srikanth Yalavarthi: > > Machine Learning common code > > > > > > This patch series implements the common ML code that can be used by ML > > drivers. Common code include functions to convert ML IO type to > > string, IO format type to string, function get size of ML IO type, and > > functions for converting data types from higher precision to lower > > precision and vice-versa. > > I'm not sure about the path of this code. > In general we implement drivers helper in the same directory as the driver > and mark it as internal. > Would it work here? We are planning to implement two different ML drivers, ml/cnxk driver (submitted for review) and a software only driver (part of ML roadmap and currently WIP). Both the drivers would be using these common functions for quantization and dequantization. Hence, placed the files in common/ml directory. Moreover, these functions are used to convert data from higher to lower precision or vice-versa and can also be used by future ML drivers for other platforms. > > > drivers/common/meson.build | 1 + > > drivers/common/ml/meson.build | 25 + > > drivers/common/ml/ml_utils.c| 118 > > drivers/common/ml/ml_utils.h| 283 + > > drivers/common/ml/ml_utils_neon.c | 873 > > > drivers/common/ml/ml_utils_scalar.c | 720 +++ > > drivers/common/ml/version.map | 25 + > >
RE: [RFC 0/8] gve PMD enhancement
Where is tx queue setup? And I believe that's also why patchwork is complaining code can't be applied. > -Original Message- > From: Guo, Junfeng > Sent: Wednesday, January 18, 2023 2:54 AM > To: Zhang, Qi Z ; Wu, Jingjing > ; ferruh.yi...@amd.com; Xing, Beilei > > Cc: dev@dpdk.org; Li, Xiaoyun ; Zhang, Helin > ; Guo, Junfeng > Subject: [RFC 0/8] gve PMD enhancement > > This patch set includs three main enhancements for gve PMD: > - support basic data path for DQO queue format > - support jumbo frame for GQI queue format > - add new AdminQ cmd to verify driver compatibility > > Junfeng Guo (8): > net/gve: add Rx queue setup for DQO > net/gve: support device start and close for DQO > net/gve: support queue release and stop for DQO > net/gve: support basic Tx data path for DQO > net/gve: support basic Rx data path for DQO > net/gve: support basic stats for DQO > net/gve: support jumbo frame for GQI > net/gve: add AdminQ command to verify driver compatibility > > drivers/net/gve/base/gve_adminq.c | 29 ++- > drivers/net/gve/base/gve_adminq.h | 48 + > drivers/net/gve/base/gve_osdep.h | 8 + > drivers/net/gve/gve_ethdev.c | 184 +++- > drivers/net/gve/gve_ethdev.h | 53 + > drivers/net/gve/gve_rx.c | 131 +--- > drivers/net/gve/gve_rx_dqo.c | 343 > ++ > drivers/net/gve/gve_tx.c | 3 + > drivers/net/gve/gve_tx_dqo.c | 202 ++ > drivers/net/gve/meson.build | 1 + > 10 files changed, 961 insertions(+), 41 deletions(-) create mode 100644 > drivers/net/gve/gve_rx_dqo.c > > -- > 2.34.1
Re: [dpdk-dev] [RFC PATCH 0/1] mldev: introduce machine learning device library
17/08/2022 08:58, Morten Brørup: > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > Sent: Wednesday, 17 August 2022 07.37 > > > > On Tue, Aug 16, 2022 at 9:15 PM Morten Brørup > > wrote: > > > > > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > > > Sent: Tuesday, 16 August 2022 15.13 > > > > > > > > On Wed, Aug 3, 2022 at 8:49 PM Stephen Hemminger > > > > wrote: > > > > > > > > > > On Wed, 3 Aug 2022 18:58:37 +0530 > > > > > wrote: > > > > > > > > > > > Roadmap > > > > > > --- > > > > > > 1) Address the comments for this RFC. > > > > > > 2) Common code for mldev > > > > > > 3) SW mldev driver based on TVM (https://tvm.apache.org/) > > > > > > > > > > Having a SW implementation is important because then it can be > > > > covered > > > > > by tests. > > > > > > > > Yes. That reason for adding TVM based SW driver as item (3). > > > > > > > > Is there any other high level or API level comments before > > proceeding > > > > with v1 and implementation. > > > > > > Have you seriously considered if the DPDK Project is the best home > > for this project? I can easily imagine the DPDK development process > > being a hindrance in many aspects for an evolving AI/ML library. Off > > the top of my head, it would probably be better off as a separate > > project, like SPDK. > > > > Yes. The reasons are following > > > > # AI/ML compiler libraries more focused on model creation and > > training etc (Thats where actual value addition the AI/ML libraries > > can offer) and minimal part for interference(It is just added for > > testing the model) > > # Considering the inference is the scope of the DPDK. DPDK is ideal > > place for following reasons > > > > a) Inference scope is very limited. > > b) Avoid memcpy of interference data (Use directly from network or > > other class of device like cryptodev, regexdev) > > c) Reuse highspeed IO interface like PCI backed driver etc > > d) Integration with other DPDK subsystems like eventdev etc for job > > completion. > > e) Also support more inline offloads by merging two device classes > > like rte_secuity. > > f) Run the inference model from different AI/ML compiler frameworks or > > abstract the inference usage. > > Similar concept is already applied to other DPDK device classes like > > 1) In Regexdev, The compiler generates the rule database which is out > > of scope of DPDK. DPDK API just loads the rule database > > 2) In Gpudev, The GPU kernel etc out of scope of DPDK.DPDK cares about > > IO interface. > > Thank you for the detailed reply, Jerin. > > These are good reasons for adding the new device class to the DPDK project - > especially the Regexdev comparison got me convinced. > > > > > > If all this stuff can be completely omitted at build time, I have no > > objections. > > > > Yes, It can be completely omitted at build time. > > Perfect. > > > Also no plan to > > integrate to testpmd and other existing application. Planning to add > > only app/test-mldev application. > > +1 to that > > > > > > > > > A small note about naming (not intending to start a flame war, so > > please feel free to ignore!): I haven't worked seriously with ML/AI > > since university three decades ago, so I'm quite rusty in the domain. > > However, I don't see any Machine Learning functions proposed by this > > API. The library provides an API to an Inference Engine - but nobody > > says the inference model stems from Machine Learning; it might as well > > be a hand crafted model. Do you plan to propose APIs for training the > > models? If not, the name of the library could confuse some potential > > users. > > > > No, scope is only inference and it is documented in the programing > > guide and API header file. I am trying to keep name similar to > > regexdev, gpudev etc which have similar scope. But I am open to other > > shortname/name if you have something in mind. > > The AI(Artificial Intelligence)/ML(Machine Learning)/IE(Inference Engine) > chip market still seems immature and fragmented, so I can't find any > consensus on generic names for such hardware accelerator devices. > > Some of the chip vendors represented on the DPDK mailing list offer AI/ML/IE > accelerator chips. Perhaps their marketing department could propose > alternatives to "Machine Learning Device"/"mldev" for inference engine > devices (with no acceleration for training the models). If not, the initially > proposed name is good enough. > > So: Everyone ask your marketing departments and speak up now, or the name > "mldev" will be set in stone. ;-) > > I'm thinking: While "Inference Engine Device"/iedev might be technically more > correct, it doesn't have same value as "Machine Learning Device"/"mldev" on a > marketing scale. And we should choose a name that we expect might become > industry standard consensus. I don't why but I like mldev and dislike iedev. I could be OK with aidev as well.
Re: [dpdk-dev] [RFC PATCH 0/1] mldev: introduce machine learning device library
17/08/2022 16:53, Jerin Jacob: > On Tue, Aug 16, 2022 at 10:04 PM Honnappa Nagarahalli > wrote: > > > > > > > > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > > > Sent: Tuesday, 16 August 2022 15.13 > > > > > > > > On Wed, Aug 3, 2022 at 8:49 PM Stephen Hemminger > > > > wrote: > > > > > > > > > > On Wed, 3 Aug 2022 18:58:37 +0530 > > > > > wrote: > > > > > > > > > > > Roadmap > > > > > > --- > > > > > > 1) Address the comments for this RFC. > > > > > > 2) Common code for mldev > > > > > > 3) SW mldev driver based on TVM (https://tvm.apache.org/) > > > > > > > > > > Having a SW implementation is important because then it can be > > > > covered > > > > > by tests. > > > > > > > > Yes. That reason for adding TVM based SW driver as item (3). > > > > > > > > Is there any other high level or API level comments before proceeding > > > > with v1 and implementation. > > > > > > Have you seriously considered if the DPDK Project is the best home for > > > this > > > project? I can easily imagine the DPDK development process being a > > > hindrance > > > in many aspects for an evolving AI/ML library. Off the top of my head, it > > > would > > > probably be better off as a separate project, like SPDK. > > There is a lot of talk about using ML in networking workloads. Although, I > > am not very sure on how the use case looks like. For ex: is the inference > > engine going to be inline (i.e. the packet goes through the inference > > engine before coming to the CPU and provide some data (what sort of > > data?)), look aside (does it require the packets to be sent to the > > inference engine or is it some other data?), what would be an end to end > > use case? A sample application using these APIs would be helpful. > > Simple application for the inference usage is added in the cover letter. > > Regarding the use cases, There are many like firewall, intrusion > detection etc. Most of the use cases are driven by product > requirements and SW IP vendors try to keep it to themselves as a > product differentiate factor. > That is the prime reason for DPDK scope only for inference where IO is > involved. Model creation and training etc will heavily vary based on > use case but not the inference model. > > > > > IMO, if we need to share the packets with the inference engine, then it > > fits into DPDK. > > Yes. Yes for networking or ORAN use cases the interface data comes > over wire and result can go over wire. > > > > > As I understand, there are many mature open source projects for > > ML/inference outside of DPDK. Does it make sense for DPDK to adopt those > > projects rather than inventing our own? > > # AI/ML compiler libraries more focused on model creation and > training etc (Thats where actual value addition the AI/ML libraries > can offer) and > minimal part for inference (It is just added for testing the model) > # Considering the inference is the scope of the DPDK. DPDK is ideal > place for following reasons > > a) Inference scope is very limited. > b) Avoid memcpy of inference data (Use directly from network or > other class of device like cryptodev, regexdev) > c) Reuse highspeed IO interface like PCI backed driver etc > d) Integration with other DPDK subsystems like eventdev etc for job > completion. > e) Also support more inline offloads by merging two device classes > like rte_secuity. > f) Run the inference model from different AI/ML compiler frameworks or > abstract the inference usage. > Similar concept is already applied to other DPDK device classes like > 1) In Regexdev, The compiler generates the rule database which is out > of scope of DPDK. DPDK API just loads the rule database > 2) In Gpudev, The GPU kernel etc out of scope of DPDK.DPDK cares about > IO interface. I think Honnappa was thinking about linking an existing inference library. What are the similar libraries?
Re: [PATCH 0/6] Testpmd code cleanup
David Marchand, Jan 24, 2023 at 11:47: Here is a series to reduce code duplication in testpmd. This work started from looking at Robin series on reporting lcore busy cycles in telemetry, which is then added in testpmd [1]. While looking at the forward engines code, I saw way too much duplicated code. Warning: this is only compile tested. 1: https://patchwork.dpdk.org/project/dpdk/patch/20230119150656.418404-5-rja...@redhat.com/ Hi David, The code looks good to me. I have made some basic testing, it seems not to break obvious things. Reviewed-by: Robin Jarry
Re: [dpdk-dev] [RFC PATCH 0/1] mldev: introduce machine learning device library
On Wed, Jan 25, 2023 at 7:17 PM Thomas Monjalon wrote: > > 17/08/2022 16:53, Jerin Jacob: > > On Tue, Aug 16, 2022 at 10:04 PM Honnappa Nagarahalli > > wrote: > > > > > > > > > > > > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > > > > Sent: Tuesday, 16 August 2022 15.13 > > > > > > > > > > On Wed, Aug 3, 2022 at 8:49 PM Stephen Hemminger > > > > > wrote: > > > > > > > > > > > > On Wed, 3 Aug 2022 18:58:37 +0530 > > > > > > wrote: > > > > > > > > > > > > > Roadmap > > > > > > > --- > > > > > > > 1) Address the comments for this RFC. > > > > > > > 2) Common code for mldev > > > > > > > 3) SW mldev driver based on TVM (https://tvm.apache.org/) > > > > > > > > > > > > Having a SW implementation is important because then it can be > > > > > covered > > > > > > by tests. > > > > > > > > > > Yes. That reason for adding TVM based SW driver as item (3). > > > > > > > > > > Is there any other high level or API level comments before proceeding > > > > > with v1 and implementation. > > > > > > > > Have you seriously considered if the DPDK Project is the best home for > > > > this > > > > project? I can easily imagine the DPDK development process being a > > > > hindrance > > > > in many aspects for an evolving AI/ML library. Off the top of my head, > > > > it would > > > > probably be better off as a separate project, like SPDK. > > > There is a lot of talk about using ML in networking workloads. Although, > > > I am not very sure on how the use case looks like. For ex: is the > > > inference engine going to be inline (i.e. the packet goes through the > > > inference engine before coming to the CPU and provide some data (what > > > sort of data?)), look aside (does it require the packets to be sent to > > > the inference engine or is it some other data?), what would be an end to > > > end use case? A sample application using these APIs would be helpful. > > > > Simple application for the inference usage is added in the cover letter. > > > > Regarding the use cases, There are many like firewall, intrusion > > detection etc. Most of the use cases are driven by product > > requirements and SW IP vendors try to keep it to themselves as a > > product differentiate factor. > > That is the prime reason for DPDK scope only for inference where IO is > > involved. Model creation and training etc will heavily vary based on > > use case but not the inference model. > > > > > > > > IMO, if we need to share the packets with the inference engine, then it > > > fits into DPDK. > > > > Yes. Yes for networking or ORAN use cases the interface data comes > > over wire and result can go over wire. > > > > > > > > As I understand, there are many mature open source projects for > > > ML/inference outside of DPDK. Does it make sense for DPDK to adopt those > > > projects rather than inventing our own? > > > > # AI/ML compiler libraries more focused on model creation and > > training etc (Thats where actual value addition the AI/ML libraries > > can offer) and > > minimal part for inference (It is just added for testing the model) > > # Considering the inference is the scope of the DPDK. DPDK is ideal > > place for following reasons > > > > a) Inference scope is very limited. > > b) Avoid memcpy of inference data (Use directly from network or > > other class of device like cryptodev, regexdev) > > c) Reuse highspeed IO interface like PCI backed driver etc > > d) Integration with other DPDK subsystems like eventdev etc for job > > completion. > > e) Also support more inline offloads by merging two device classes > > like rte_secuity. > > f) Run the inference model from different AI/ML compiler frameworks or > > abstract the inference usage. > > Similar concept is already applied to other DPDK device classes like > > 1) In Regexdev, The compiler generates the rule database which is out > > of scope of DPDK. DPDK API just loads the rule database > > 2) In Gpudev, The GPU kernel etc out of scope of DPDK.DPDK cares about > > IO interface. > > I think Honnappa was thinking about linking an existing inference library. > What are the similar libraries? Not sure. Honnappa can tell if any which meets (a) to (f). > >
Re: [EXT] Re: [PATCH v3 0/4] implementation of ML common code
25/01/2023 14:25, Srikanth Yalavarthi: > From: Thomas Monjalon > > 20/12/2022 18:52, Srikanth Yalavarthi: > > > This patch series implements the common ML code that can be used by ML > > > drivers. Common code include functions to convert ML IO type to > > > string, IO format type to string, function get size of ML IO type, and > > > functions for converting data types from higher precision to lower > > > precision and vice-versa. > > > > I'm not sure about the path of this code. > > In general we implement drivers helper in the same directory as the driver > > and mark it as internal. > > Would it work here? > > We are planning to implement two different ML drivers, ml/cnxk driver > (submitted for review) and a software only driver (part of ML roadmap and > currently WIP). Both the drivers would be using these common functions for > quantization and dequantization. Hence, placed the files in common/ml > directory. > > Moreover, these functions are used to convert data from higher to lower > precision or vice-versa and can also be used by future ML drivers for other > platforms. I understand, and what you say does not contradict with having this code in lib/mldev/. So would you agree to move?
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
On 1/25/2023 12:55 PM, Thomas Monjalon wrote: > 25/01/2023 10:30, Hanumanth Reddy Pothula: >> ++ Ivan Malov and Andrew Rybchenko >> >> From: Ferruh Yigit >>> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: Presently, Rx metadata is sent to PMD by default, leading to a performance drop as processing for the same in Rx path takes extra cycles. Hence, add new testpmd command, 'enable port nic_to_pmd_rx_metadata' This command helps in sending Rx metadata to PMD and thereby Rx metadata flow command requests are processed. Signed-off-by: Hanumanth Pothula >>> >>> Hi Hanumanth, >>> >>> I agree with Thomas for the patch. >>> >>> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be >>> enabled, but at this stage if there is no flow rule for Rx metadata why it >>> is >>> consuming extra cycles? >>> >>> Can you update driver code to process Rx metadata when it is enabled by >>> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least >>> one flow rule for it? >> >> #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is >> always called by testpmd. >> We thought it was added so that when that metadata is not needed, >> application need not call this >> thereby saving cycles/bandwidth. > > testpmd is for testing all features. That's why all is negotiated. > Cycles should be saved if you don't enable it until a flow rule requires it. > Hi Thomas, Not just for saving cycles, but from testing perspective too, do you think does it work if a way to disable these Rx metadata added by keeping default behavior as it is? And new command can be in a consistent command syntax like: "port config ..." >> #2 We use this API similar to Rx/Tx offload flags so that we can set things >> up before device is >> configured. We thought that is the purpose of having this negotiate API and >> avoid depleting offload flags. > > It is just a configuration negotiation specific to metadata. > >> #3 Generally any new offloads added to DPDK would be in disabled state in >> testpmd and we would have >> an option to enable it. In this case, testpmd is by default calling this >> negotiation. > > Negotiating is not enabling. > >> We can update the driver if the purpose of this API is clear. > > Please do. > Is following understanding correct? APIFlow Rule Result - EnableNo Rule Feature Disabled EnableRule exist Feature Enabled Disable X Feature Disabled
DTS WG roadmap for 23.02
Hello, The following patches have been submitted for 23.02 release. 1) Add docker file for creating DTS dev environment and for CI http://patches.dpdk.org/project/dpdk/patch/20221103134633.446646-1-juraj.lin...@pantheon.tech/ 2) Add code needed to run the HelloWorld testcase http://patches.dpdk.org/project/dpdk/cover/20230117154906.860916-1-juraj.lin...@pantheon.tech/ Appreciate review comments from the community. Thank you, Honnappa
Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
25/01/2023 14:55, Ferruh Yigit: > On 1/25/2023 12:55 PM, Thomas Monjalon wrote: > > 25/01/2023 10:30, Hanumanth Reddy Pothula: > >> ++ Ivan Malov and Andrew Rybchenko > >> > >> From: Ferruh Yigit > >>> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: > Presently, Rx metadata is sent to PMD by default, leading to a > performance drop as processing for the same in Rx path takes extra > cycles. > > Hence, add new testpmd command, > 'enable port nic_to_pmd_rx_metadata' > > This command helps in sending Rx metadata to PMD and thereby Rx > metadata flow command requests are processed. > > Signed-off-by: Hanumanth Pothula > >>> > >>> Hi Hanumanth, > >>> > >>> I agree with Thomas for the patch. > >>> > >>> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be > >>> enabled, but at this stage if there is no flow rule for Rx metadata why > >>> it is > >>> consuming extra cycles? > >>> > >>> Can you update driver code to process Rx metadata when it is enabled by > >>> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least > >>> one flow rule for it? > >> > >> #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is > >> always called by testpmd. > >> We thought it was added so that when that metadata is not needed, > >> application need not call this > >> thereby saving cycles/bandwidth. > > > > testpmd is for testing all features. That's why all is negotiated. > > Cycles should be saved if you don't enable it until a flow rule requires it. > > > > Hi Thomas, > > Not just for saving cycles, but from testing perspective too, do you > think does it work if a way to disable these Rx metadata added by > keeping default behavior as it is? > > And new command can be in a consistent command syntax like: > "port config ..." Yes I agree it would be good to have a way to test different values. And it would allow to completely disable metadata I suppose. Note: I don't understand why we don't have RTE_FLOW_ACTION_TYPE_SET_TAG and RTE_FLOW_ACTION_TYPE_SET_META negotiated in this function. Probably something to add. > >> #2 We use this API similar to Rx/Tx offload flags so that we can set > >> things up before device is > >> configured. We thought that is the purpose of having this negotiate API > >> and avoid depleting offload flags. > > > > It is just a configuration negotiation specific to metadata. > > > >> #3 Generally any new offloads added to DPDK would be in disabled state in > >> testpmd and we would have > >> an option to enable it. In this case, testpmd is by default calling this > >> negotiation. > > > > Negotiating is not enabling. > > > >> We can update the driver if the purpose of this API is clear. > > > > Please do. > > Is following understanding correct? > > APIFlow Rule Result > - > EnableNo RuleFeature Disabled > EnableRule exist Feature Enabled > Disable X Feature Disabled In the API column, you should say "negotiated" instead of "Enable".
Re: [dpdk-dev] [PATCH v1 00/12] mldev: introduce machine learning device library
14/11/2022 13:02, jer...@marvell.com: > From: Jerin Jacob > > Machine learning inference library > == > > Definition of machine learning inference > > Inference in machine learning is the process of making an output prediction > based on new input data using a pre-trained machine learning model. > > The scope of the RFC would include only inferencing with pre-trained machine > learning models, > training and building/compiling the ML models is out of scope for this RFC or > DPDK mldev API. Use existing machine learning compiler frameworks for model > creation. > > Motivation for the new library > -- > Multiple semiconductor vendors are offering accelerator products such as DPU > (often called Smart-NIC), FPGA, GPU, etc., which have ML inferencing > capabilities > integrated as part of the product. Use of ML inferencing is increasing in the > domain > of packet processing for flow classification, intrusion, malware and anomaly > detection. > > Lack of inferencing support through DPDK APIs will involve complexities and > increased latency from moving data across frameworks (i.e, dataplane to > non dataplane ML frameworks and vice-versa). Having a standardized DPDK APIs > for ML > inferencing would enable the dataplane solutions to harness the benefit of > inline > inferencing supported by the hardware. > > Contents > --- > > A) API specification for: > > 1) Discovery of ML capabilities (e.g., device specific features) in a vendor > independent fashion > 2) Definition of functions to handle ML devices, which includes probing, > initialization and termination of the devices. > 3) Definition of functions to handle ML models used to perform inference > operations. > 4) Definition of function to handle quantize and dequantize operations > > B) Common code for above specification Can we compare this library with WinML? https://learn.microsoft.com/en-us/windows/ai/windows-ml/api-reference Is there things we can learn from it? > ML Model: An ML model is an algorithm trained over a dataset. A model > consists of > procedure/algorithm and data/pattern required to make predictions on live > data. > Once the model is created and trained outside of the DPDK scope, the model > can be loaded > via rte_ml_model_load() and then start it using rte_ml_model_start() API. > The rte_ml_model_params_update() can be used to update the model parameters > such as weight > and bias without unloading the model using rte_ml_model_unload(). The fact that the model is prepared outside means the model format is free and probably different per mldev driver. I think it is OK but it requires a lot of documentation effort to explain how to bind the model and its parameters with the DPDK API. Also we may need to pass some metadata from the model builder to the inference engine in order to enable optimizations prepared in the model. And the other way, we may need inference capabilities in order to generate an optimized model which can run in the inference engine. [...] > Typical application utilisation of the ML API will follow the following > programming flow. > > - rte_ml_dev_configure() > - rte_ml_dev_queue_pair_setup() > - rte_ml_model_load() > - rte_ml_model_start() > - rte_ml_model_info() > - rte_ml_dev_start() > - rte_ml_enqueue_burst() > - rte_ml_dequeue_burst() > - rte_ml_model_stop() > - rte_ml_model_unload() > - rte_ml_dev_stop() > - rte_ml_dev_close() Where is parameters update in this flow? Should we update all parameters at once or can it be done more fine-grain? Question about the memory used by mldev: Can we manage where the memory is allocated (host, device, mix, etc)?
DTS WG MoM 2023 link
Hello, The DTS WG MoM for 2023 are captured at [1]. Thank you, Honnappa [1] https://docs.google.com/document/d/1Ej1QyqSPH3ae2nPwG4oZ5Bteb26uH61RmrsZSAECXLU/edit?usp=sharing
RE: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation
> >Will it work to enable them all by default and add capability to disable > >it in testpmd, which helps to run performance tests also to verify the > > impact of the API? The spirit of the negotiating features/Rx/Tx offloads upfront is to have it disabled by default and enable the feature only when needed. Having the features enabled by default is probably against that spirit. We understand the concerns with drivers that didn't not implement that API. Why not disable it by default(like other offloads) and modify rte_flow action creation in testpmd to check for if !ENOSUP and feature disabled and add print to enable. So for the PMD's that won't support rte_eth_rx_metadata_negotiate(), there won't be any difference and for very few PMD's that support this API, they need to enable it before using RTE_FLOW with MARK/FLAG. Behavior change would be seen only with two PMD's(cnxk, sfc). > Note: I don't understand why we don't have > RTE_FLOW_ACTION_TYPE_SET_TAG and RTE_FLOW_ACTION_TYPE_SET_META > negotiated in this function. Probably something to add. The purpose of negotiate is to tell the PMD upfront so that PMD can prepare HW appropriately. Having these new actions would be very late to inform PMD and I think won't solve the purpose. > -Original Message- > From: Thomas Monjalon > Sent: Wednesday, January 25, 2023 7:30 PM > To: Aman Singh ; Yuying Zhang > ; > Ivan Malov ; Andrew Rybchenko > ; dev@dpdk.org; Hanumanth Reddy Pothula > ; Ferruh Yigit > Cc: viachesl...@nvidia.com; Jerin Jacob Kollanukkaran ; > Nithin Kumar > Dabilpuram ; david.march...@redhat.com > Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx > metadata > negotiation > > 25/01/2023 14:55, Ferruh Yigit: > > On 1/25/2023 12:55 PM, Thomas Monjalon wrote: > > > 25/01/2023 10:30, Hanumanth Reddy Pothula: > > >> ++ Ivan Malov and Andrew Rybchenko > > >> > > >> From: Ferruh Yigit > > >>> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote: > > Presently, Rx metadata is sent to PMD by default, leading to a > > performance drop as processing for the same in Rx path takes extra > > cycles. > > > > Hence, add new testpmd command, > > 'enable port nic_to_pmd_rx_metadata' > > > > This command helps in sending Rx metadata to PMD and thereby Rx > > metadata flow command requests are processed. > > > > Signed-off-by: Hanumanth Pothula > > >>> > > >>> Hi Hanumanth, > > >>> > > >>> I agree with Thomas for the patch. > > >>> > > >>> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be > > >>> enabled, but at this stage if there is no flow rule for Rx metadata why > > >>> it is > > >>> consuming extra cycles? > > >>> > > >>> Can you update driver code to process Rx metadata when it is enabled by > > >>> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at > > >>> least > > >>> one flow rule for it? > > >> > > >> #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is > > >> always called by > testpmd. > > >> We thought it was added so that when that metadata is not needed, > > >> application need > not call this > > >> thereby saving cycles/bandwidth. > > > > > > testpmd is for testing all features. That's why all is negotiated. > > > Cycles should be saved if you don't enable it until a flow rule requires > > > it. > > > > > > > Hi Thomas, > > > > Not just for saving cycles, but from testing perspective too, do you > > think does it work if a way to disable these Rx metadata added by > > keeping default behavior as it is? > > > > And new command can be in a consistent command syntax like: > > "port config ..." > > Yes I agree it would be good to have a way to test different values. > And it would allow to completely disable metadata I suppose. > > Note: I don't understand why we don't have > RTE_FLOW_ACTION_TYPE_SET_TAG and RTE_FLOW_ACTION_TYPE_SET_META > negotiated in this function. Probably something to add. > > > > >> #2 We use this API similar to Rx/Tx offload flags so that we can set > > >> things up before > device is > > >> configured. We thought that is the purpose of having this negotiate API > > >> and avoid > depleting offload flags. > > > > > > It is just a configuration negotiation specific to metadata. > > > > > >> #3 Generally any new offloads added to DPDK would be in disabled state > > >> in testpmd > and we would have > > >> an option to enable it. In this case, testpmd is by default calling this > > >> negotiation. > > > > > > Negotiating is not enabling. > > > > > >> We can update the driver if the purpose of this API is clear. > > > > > > Please do. > > > > Is following understanding correct? > > > > APIFlow Rule Result > > - > > EnableNo Rule Feature Disabled > > EnableRule exist Feature Enabled > > Disable X Feature Disabled > > In the API column, you should
Re: [PATCH] eventdev/timer: fix overflow issue
On Wed, 25 Jan 2023 10:37:16 +0530 Jerin Jacob wrote: > Looks like Stephan replied to v1 hence comment is not showing up here > https://patches.dpdk.org/project/dpdk/patch/20230124204555.3022361-1-erik.g.carri...@intel.com/ > @Erik Gabriel Carrillo Can be following moved to slow path ? > + cycles_per_nsec = (double)rte_get_timer_hz() / NSECPERSEC; Best solution is to use rte_reciprocal
RE: [EXT] Re: [PATCH v3 0/4] implementation of ML common code
> -Original Message- > From: Thomas Monjalon > Sent: 25 January 2023 19:25 > To: Shivah Shankar Shankar Narayan Rao ; > Srikanth Yalavarthi > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Anup > Prabhu ; ferruh.yi...@amd.com; > bruce.richard...@intel.com; david.march...@redhat.com; Srikanth > Yalavarthi > Subject: Re: [EXT] Re: [PATCH v3 0/4] implementation of ML common code > > 25/01/2023 14:25, Srikanth Yalavarthi: > > From: Thomas Monjalon > > > 20/12/2022 18:52, Srikanth Yalavarthi: > > > > This patch series implements the common ML code that can be used > > > > by ML drivers. Common code include functions to convert ML IO type > > > > to string, IO format type to string, function get size of ML IO > > > > type, and functions for converting data types from higher > > > > precision to lower precision and vice-versa. > > > > > > I'm not sure about the path of this code. > > > In general we implement drivers helper in the same directory as the > > > driver and mark it as internal. > > > Would it work here? > > > > We are planning to implement two different ML drivers, ml/cnxk driver > (submitted for review) and a software only driver (part of ML roadmap and > currently WIP). Both the drivers would be using these common functions for > quantization and dequantization. Hence, placed the files in common/ml > directory. > > > > Moreover, these functions are used to convert data from higher to lower > precision or vice-versa and can also be used by future ML drivers for other > platforms. > > I understand, and what you say does not contradict with having this code in > lib/mldev/. > So would you agree to move? > These common functions do not have an rte_ml_dev_ prefix. Is it ok to have non-RTE code in lib/mldev. If yes, we can move to lib/mldev.
RE: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
>-Original Message-
>From: Ferruh Yigit
>Sent: Monday, January 23, 2023 10:58 PM
>To: Ankur Dwivedi ; dev@dpdk.org
>Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
>or...@nvidia.com; ch...@att.com; humi...@huawei.com;
>linvi...@tuxdriver.com; ciara.lof...@intel.com; qi.z.zh...@intel.com;
>m...@semihalf.com; m...@semihalf.com; shaib...@amazon.com;
>evge...@amazon.com; igo...@amazon.com; cha...@amd.com; Igor
>Russkikh ; shepard.sie...@atomicrules.com;
>ed.cz...@atomicrules.com; john.mil...@atomicrules.com;
>ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Jerin Jacob
>Kollanukkaran ; Maciej Czekaj [C]
>; Shijith Thotton ;
>Srisivasubramanian Srinivasan ; Harman Kalra
>; rahul.lakkire...@chelsio.com; johnd...@cisco.com;
>hyon...@cisco.com; liudongdo...@huawei.com;
>yisen.zhu...@huawei.com; xuanziya...@huawei.com;
>cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com;
>simei...@intel.com; wenjun1...@intel.com; qiming.y...@intel.com;
>yuying.zh...@intel.com; beilei.x...@intel.com; xiao.w.w...@intel.com;
>jingjing...@intel.com; junfeng@intel.com; rosen...@intel.com; Nithin
>Kumar Dabilpuram ; Kiran Kumar Kokkilagadda
>; Sunil Kumar Kori ; Satha
>Koteswara Rao Kottidi ; Liron Himi
>; z...@semihalf.com; Radha Chintakuntla
>; Veerasenareddy Burru ;
>Sathesh B Edara ; ma...@nvidia.com;
>viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
>chaoyong...@corigine.com; niklas.soderl...@corigine.com;
>hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
>apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
>Rasesh Mody ; Shahed Shaikh
>; Devendra Singh Rawat
>; andrew.rybche...@oktetlabs.ru;
>jiawe...@trustnetic.com; jianw...@trustnetic.com;
>jbehr...@vmware.com; maxime.coque...@redhat.com;
>chenbo@intel.com; steven.webs...@windriver.com;
>matt.pet...@windriver.com; bruce.richard...@intel.com;
>mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
>cristian.dumitre...@intel.com; jgraj...@cisco.com;
>m...@smartsharesystems.com
>Subject: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
>
>External Email
>
>--
>On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>> Adds a trace point emit function for capturing a blob. The blob
>> captures the length passed by the application followed by the array.
>>
>> The maximum blob bytes which can be captured is bounded by
>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro is
>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>> are set to zero.
>>
>> This patch also adds test case for emit blob tracepoint function.
>>
>> Signed-off-by: Ankur Dwivedi
>> ---
>> app/test/test_trace.c | 11
>> doc/guides/prog_guide/trace_lib.rst| 12
>> lib/eal/common/eal_common_trace_points.c | 2 ++
>> lib/eal/include/rte_eal_trace.h| 6
>> lib/eal/include/rte_trace_point.h | 32 ++
>> lib/eal/include/rte_trace_point_register.h | 9 ++
>> lib/eal/version.map| 3 ++
>> 7 files changed, 75 insertions(+)
>>
>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>> 6bedf14024..ad4a394a29 100644
>> --- a/app/test/test_trace.c
>> +++ b/app/test/test_trace.c
>> @@ -4,6 +4,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>>
>> #include "test.h"
>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>> test_generic_trace_points(void)
>> {
>> +uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>> int tmp;
>> +int i;
>> +
>> +for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>> +arr[i] = i;
>>
>> rte_eal_trace_generic_void();
>> rte_eal_trace_generic_u64(0x10);
>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>> rte_eal_trace_generic_ptr(&tmp);
>> rte_eal_trace_generic_str("my string");
>> rte_eal_trace_generic_size_t(sizeof(void *));
>> +rte_eal_trace_generic_blob(arr, 0);
>> +rte_eal_trace_generic_blob(arr, 17);
>> +rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>> +rte_eal_trace_generic_blob(arr, rte_rand() %
>> +RTE_TRACE_BLOB_LEN_MAX);
>> RTE_EAL_TRACE_GENERIC_FUNC;
>>
>> return TEST_SUCCESS;
>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>> b/doc/guides/prog_guide/trace_lib.rst
>> index 9a8f38073d..3e0ea5835c 100644
>> --- a/doc/guides/prog_guide/trace_lib.rst
>> +++ b/doc/guides/prog_guide/trace_lib.rst
>> @@ -352,3 +352,15 @@ event ID.
>> The ``packet.header`` and ``packet.context`` will be written in the
>> slow path at the time of trace memory creation. The ``trace.header``
>> and trace payload will be emitted when the tracepoint function is invoked.
>> +
>> +Limitations
>> +---
>> +
>> +- The ``rte_trace_point_emit_blob()`` function can capture a maximum
>> +blob of
>> + length ``RTE_TRACE_
Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>
>>
>> --
>> On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>>> Adds a trace point emit function for capturing a blob. The blob
>>> captures the length passed by the application followed by the array.
>>>
>>> The maximum blob bytes which can be captured is bounded by
>>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro is
>>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>>> are set to zero.
>>>
>>> This patch also adds test case for emit blob tracepoint function.
>>>
>>> Signed-off-by: Ankur Dwivedi
>>> ---
>>> app/test/test_trace.c | 11
>>> doc/guides/prog_guide/trace_lib.rst| 12
>>> lib/eal/common/eal_common_trace_points.c | 2 ++
>>> lib/eal/include/rte_eal_trace.h| 6
>>> lib/eal/include/rte_trace_point.h | 32 ++
>>> lib/eal/include/rte_trace_point_register.h | 9 ++
>>> lib/eal/version.map| 3 ++
>>> 7 files changed, 75 insertions(+)
>>>
>>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>>> 6bedf14024..ad4a394a29 100644
>>> --- a/app/test/test_trace.c
>>> +++ b/app/test/test_trace.c
>>> @@ -4,6 +4,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include "test.h"
>>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>>> test_generic_trace_points(void)
>>> {
>>> + uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>>> int tmp;
>>> + int i;
>>> +
>>> + for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>>> + arr[i] = i;
>>>
>>> rte_eal_trace_generic_void();
>>> rte_eal_trace_generic_u64(0x10);
>>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>>> rte_eal_trace_generic_ptr(&tmp);
>>> rte_eal_trace_generic_str("my string");
>>> rte_eal_trace_generic_size_t(sizeof(void *));
>>> + rte_eal_trace_generic_blob(arr, 0);
>>> + rte_eal_trace_generic_blob(arr, 17);
>>> + rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>>> + rte_eal_trace_generic_blob(arr, rte_rand() %
>>> + RTE_TRACE_BLOB_LEN_MAX);
>>> RTE_EAL_TRACE_GENERIC_FUNC;
>>>
>>> return TEST_SUCCESS;
>>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>>> b/doc/guides/prog_guide/trace_lib.rst
>>> index 9a8f38073d..3e0ea5835c 100644
>>> --- a/doc/guides/prog_guide/trace_lib.rst
>>> +++ b/doc/guides/prog_guide/trace_lib.rst
>>> @@ -352,3 +352,15 @@ event ID.
>>> The ``packet.header`` and ``packet.context`` will be written in the
>>> slow path at the time of trace memory creation. The ``trace.header``
>>> and trace payload will be emitted when the tracepoint function is invoked.
>>> +
>>> +Limitations
>>> +---
>>> +
>>> +- The ``rte_trace_point_emit_blob()`` function can capture a maximum
>>> +blob of
>>> + length ``RTE_TRACE_BLOB_LEN_MAX`` bytes. The application can call
>>> + ``rte_trace_point_emit_blob()`` multiple times with length less
>>> +than or equal to
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, if it needs to capture more than
>>> +``RTE_TRACE_BLOB_LEN_MAX``
>>> + bytes.
>>> +- If the length passed to the ``rte_trace_point_emit_blob()`` is less
>>> +than
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, then the trailing
>>> +``(RTE_TRACE_BLOB_LEN_MAX - len)``
>>> + bytes in the trace are set to zero.
>>> diff --git a/lib/eal/common/eal_common_trace_points.c
>>> b/lib/eal/common/eal_common_trace_points.c
>>> index 0b0b254615..051f89809c 100644
>>> --- a/lib/eal/common/eal_common_trace_points.c
>>> +++ b/lib/eal/common/eal_common_trace_points.c
>>> @@ -40,6 +40,8 @@
>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_size_t,
>>> lib.eal.generic.size_t)
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func,
>>> lib.eal.generic.func)
>>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_blob,
>>> + lib.eal.generic.blob)
>>>
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set,
>>> lib.eal.alarm.set)
>>> diff --git a/lib/eal/include/rte_eal_trace.h
>>> b/lib/eal/include/rte_eal_trace.h index 5ef4398230..e0b836eb2f 100644
>>> --- a/lib/eal/include/rte_eal_trace.h
>>> +++ b/lib/eal/include/rte_eal_trace.h
>>> @@ -143,6 +143,12 @@ RTE_TRACE_POINT(
>>> rte_trace_point_emit_string(func);
>>> )
>>>
>>> +RTE_TRACE_POINT(
>>> + rte_eal_trace_generic_blob,
>>> + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
>>> + rte_trace_point_emit_blob(in, len);
>>> +)
>>> +
>>> #define RTE_EAL_TRACE_GENERIC_FUNC
>>> rte_eal_trace_generic_func(__func__)
>>>
>>> /* Interrupt */
>>> diff --git a/lib/eal/include/rte_trace_point.h
>>> b/lib/eal/include/rte_trace_point.h
>>> index 0f8700974f..aca8344dbf 100644
>>> --- a/lib/eal/include/rte_trace_point.h
>>> +++ b/lib/eal/include/rte_trace_point.h
>>> @@ -144,6 +144,16 @@ _tp _args \
>>> #define rte_trace_point_emit_ptr(val)
>>> /** Tracepoint function payload for string datatype
Re: [PATCH 1/2] lib: add helper to read strings from sysfs files
On Wed, Jan 25, 2023 at 11:39:30AM +0100, Thomas Monjalon wrote: > 25/01/2023 11:33, Tomasz Duszynski: > > Reading strings from sysfs files is a re-occurring pattern > > hence add helper for doing that. > > In general it would be to nice to clean sysfs parsing in libs and drivers, > so they all use some functions from EAL. maybe there should be a general utility library for dealing with sysfs separate from the core EAL that drivers / platform specific libs can share?
RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> -Original Message- > From: Jerin Jacob > Sent: Wednesday, January 25, 2023 4:08 PM > To: Naga Harish K, S V > Cc: jer...@marvell.com; Carrillo, Erik G ; Gujjar, > Abhinandan S ; dev@dpdk.org; > Jayatheerthan, Jay > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs > > On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V > wrote: > > > > Hi Jerin, > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Wednesday, January 25, 2023 9:42 AM > > > To: Naga Harish K, S V > > > Cc: jer...@marvell.com; Carrillo, Erik G > > > ; Gujjar, Abhinandan S > > > ; dev@dpdk.org; Jayatheerthan, Jay > > > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs > > > > > > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V > > > wrote: > > > > > > > > Hi Jerin, > > > > > > > > > -Original Message- > > > > > From: Jerin Jacob > > > > > Sent: Tuesday, January 24, 2023 10:00 AM > > > > > To: Naga Harish K, S V > > > > > Cc: jer...@marvell.com; Carrillo, Erik G > > > > > ; Gujjar, Abhinandan S > > > > > ; dev@dpdk.org; Jayatheerthan, Jay > > > > > > > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get > > > > > APIs > > > > > > > > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V > > > > > wrote: > > > > > > > > > > > > The adapter configuration parameters defined in the ``struct > > > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured > > > > > > and retrieved using > > > > > > ``rte_event_eth_rx_adapter_runtime_params_set`` > > > > > > and ``rte_event_eth_tx_adapter_runtime_params_get`` > respectively. > > > > > > > > > > > > Signed-off-by: Naga Harish K S V > > > > > > > > > > > diff --git > > > > > > a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst > > > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst > > > > > > index 461eca566f..2207d6ffc3 100644 > > > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst > > > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst > > > > > > @@ -185,6 +185,26 @@ flags for handling received packets, > > > > > > event queue identifier, scheduler type, event priority, > > > > > > polling frequency of the receive queue and flow identifier in > > > > > > struct > > > > > ``rte_event_eth_rx_adapter_queue_conf``. > > > > > > > > > > > > +Set/Get adapter runtime configuration parameters > > > > > > + > > > > > > + > > > > > > +The runtime configuration parameters of adapter can be > > > > > > +set/read using > > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` and > ``rte_event_eth_rx_adapter_runtime_params_get()`` respectively. > > > > > > +The parameters that can be set/read are defined in ``struct > > > > > rte_event_eth_rx_adapter_runtime_params``. > > > > > > > > > > Good. > > > > > > > > > > > + > > > > > > +``rte_event_eth_rx_adapter_create()`` or > > > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures > > > > > > +the adapter with default value for maximum packets processed > > > > > > +per request to > > > > > 128. > > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function > > > > > > +allows to reconfigure maximum number of packets processed by > > > > > > +adapter per service request. This is alternative to > > > > > > +configuring the maximum packets processed per request by > > > > > > +adapter by using ``rte_event_eth_rx_adapter_create_ext()`` > > > > > > +with parameter > > > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``. > > > > > > > > > > This paragraph is not needed IMO. As it is specific to a driver, > > > > > and we can keep Doxygen comment only. > > > > > > > > > > > > > > > > + > > > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function > > > > > > +retrieves the configuration parameters that are defined in > > > > > > +``struct > > > > > rte_event_eth_rx_adapter_runtime_params``. > > > > > > > > > > Good. > > > > > > > > > > > + > > > > > > Getting and resetting Adapter queue stats > > > > > > ~ > > > > > > > > > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c > > > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c > > > > > > index 34aa87379e..d8f3e750b7 100644 > > > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c > > > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c > > > > > > @@ -35,6 +35,8 @@ > > > > > > #define MAX_VECTOR_NS 1E9 > > > > > > #define MIN_VECTOR_NS 1E5 > > > > > > > > > > > > +#define RXA_NB_RX_WORK_DEFAULT 128 > > > > > > + > > > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN32 > > > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN32 > > > > > > > > > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t > > > dev_id, > > > > > > } > > > > > > > > > > > > conf->event_port_id = port_id; > > > > > > - conf->max_nb_rx = 128; > > > > > > + conf->max_nb_rx = RXA_NB_RX_WO
Re: [PATCH v2] net/af_xdp: AF_XDP PMD CNI Integration
On 12/14/2022 3:41 PM, Shibin Koikkara Reeny wrote: Integrate support for the AF_XDP CNI and device plugin [1] so that the DPDK AF_XDP PMD can work in an unprivileged container environment. Part of the AF_XDP PMD initialization process involves loading an eBPF program onto the given netdev. This operation requires privileges, which prevents the PMD from being able to work in an unprivileged container (without root access). The plugin CNI handles the program loading. CNI open Unix Domain Socket (UDS) and waits listening for a client to make requests over that UDS. The client(DPDK) connects and a "handshake" occurs, then the File Descriptor which points to the XSKMAP associated with the loaded eBPF program is handed over to the client. The client can then proceed with creating an AF_XDP socket and inserting the socket into the XSKMAP pointed to by the FD received on the UDS. A new vdev arg "use_cni" is created to indicate user wishes to run the PMD in unprivileged mode and to receive the XSKMAP FD from the CNI. When this flag is set, the XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD libbpf flag should be used when creating the socket, which tells libbpf not to load the default libbpf program on the netdev. We tell libbpf not to do this because the loading is handled by the CNI in this scenario. [1]: https://github.com/intel/afxdp-plugins-for-kubernetes Signed-off-by: Shibin Koikkara Reeny --- Tested-by: Anatoly Burakov The testing setup is a bit involved, but everything seems to work once all the pieces fall into place. -- Thanks, Anatoly
RE: [PATCH 1/4] net/mlx5/hws: definitions for Hash Split/Linear Lookup tbls
Hi, > -Original Message- > From: Yevgeny Kliteynik > Sent: Thursday, January 12, 2023 3:49 PM > To: Yevgeny Kliteynik ; Slava Ovsiienko > ; NBU-Contact-Thomas Monjalon (EXTERNAL) > ; Suanming Mou ; > Matan Azrad > Cc: dev@dpdk.org; Ori Kam > Subject: [PATCH 1/4] net/mlx5/hws: definitions for Hash Split/Linear Lookup > tbls > > Added PRM bits for new RTC types: Hash Split and Linear Lookup tables, > as well as for HASH_RESULT field that contains hash result of the > Hash Split table calculation. > > Signed-off-by: Yevgeny Kliteynik Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
[PATCH v9] testpmd: cleanup cleanly from signal
Do a clean shutdown of testpmd when a signal is received; instead of
having testpmd kill itself. This fixes the problem where a signal could
be received in the middle of a PMD and then the signal handler would
call PMD's close routine leading to locking problems.
An added benefit is it gets rid of some Windows specific code.
Fixes: d9a191a00e81 ("app/testpmd: fix quitting in container")
Signed-off-by: Stephen Hemminger
---
v9 - also handle the interactive case.
use cmdine_poll() rather than signals and atexit
app/test-pmd/cmdline.c | 28 +--
app/test-pmd/testpmd.c | 77 --
app/test-pmd/testpmd.h | 1 +
3 files changed, 46 insertions(+), 60 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd445..fbe9ad694dee 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -65,7 +65,6 @@
#include "cmdline_tm.h"
#include "bpf_cmd.h"
-static struct cmdline *testpmd_cl;
static cmdline_parse_ctx_t *main_ctx;
static TAILQ_HEAD(, testpmd_driver_commands) driver_commands_head =
TAILQ_HEAD_INITIALIZER(driver_commands_head);
@@ -12921,28 +12920,19 @@ cmdline_read_from_file(const char *filename)
void
prompt(void)
{
- int ret;
+ struct cmdline *cl;
- testpmd_cl = cmdline_stdin_new(main_ctx, "testpmd> ");
- if (testpmd_cl == NULL)
+ cl = cmdline_stdin_new(main_ctx, "testpmd> ");
+ if (cl == NULL)
return;
- ret = atexit(prompt_exit);
- if (ret != 0)
- fprintf(stderr, "Cannot set exit function for cmdline\n");
-
- cmdline_interact(testpmd_cl);
- if (ret != 0)
- cmdline_stdin_exit(testpmd_cl);
-}
-
-void
-prompt_exit(void)
-{
- if (testpmd_cl != NULL) {
- cmdline_quit(testpmd_cl);
- cmdline_stdin_exit(testpmd_cl);
+ while (f_quit == 0 && cl_quit == 0) {
+ if (cmdline_poll(cl) < 0)
+ break;
}
+
+ cmdline_quit(cl);
+ cmdline_stdin_exit(cl);
}
void
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 134d79a55547..d01b6105b7de 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -11,6 +11,7 @@
#include
#ifndef RTE_EXEC_ENV_WINDOWS
#include
+#include
#endif
#include
#include
@@ -231,7 +232,7 @@ unsigned int xstats_display_num; /**< Size of extended
statistics to show */
* In container, it cannot terminate the process which running with
'stats-period'
* option. Set flag to exit stats period loop after received SIGINT/SIGTERM.
*/
-static volatile uint8_t f_quit;
+volatile uint8_t f_quit;
uint8_t cl_quit; /* Quit testpmd from cmdline. */
/*
@@ -4315,13 +4316,6 @@ init_port(void)
memset(txring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
}
-static void
-force_quit(void)
-{
- pmd_test_exit();
- prompt_exit();
-}
-
static void
print_stats(void)
{
@@ -4340,28 +4334,9 @@ print_stats(void)
}
static void
-signal_handler(int signum)
+signal_handler(int signum __rte_unused)
{
- if (signum == SIGINT || signum == SIGTERM) {
- fprintf(stderr, "\nSignal %d received, preparing to exit...\n",
- signum);
-#ifdef RTE_LIB_PDUMP
- /* uninitialize packet capture framework */
- rte_pdump_uninit();
-#endif
-#ifdef RTE_LIB_LATENCYSTATS
- if (latencystats_enabled != 0)
- rte_latencystats_uninit();
-#endif
- force_quit();
- /* Set flag to indicate the force termination. */
- f_quit = 1;
- /* exit with the expected status */
-#ifndef RTE_EXEC_ENV_WINDOWS
- signal(signum, SIG_DFL);
- kill(getpid(), signum);
-#endif
- }
+ f_quit = 1;
}
int
@@ -4536,15 +4511,9 @@ main(int argc, char** argv)
start_packet_forwarding(0);
}
prompt();
- pmd_test_exit();
} else
#endif
{
- char c;
- int rc;
-
- f_quit = 0;
-
printf("No commandline core given, start packet forwarding\n");
start_packet_forwarding(tx_first);
if (stats_period != 0) {
@@ -4567,15 +4536,41 @@ main(int argc, char** argv)
prev_time = cur_time;
rte_delay_us_sleep(US_PER_S);
}
- }
+ } else {
+ char c;
+ fd_set fds;
+
+ printf("Press enter to exit\n");
- printf("Press enter to exit\n");
- rc = read(0, &c, 1);
- pmd_test_exit();
- if (rc < 0)
- return 1;
+ FD_ZERO(&fds);
+ FD_SET(0, &fds);
+
+ /* wait for signa
Re: [PATCH 2/2] app/testpmd: add disable-flow-flush parameter
On 1/23/2023 3:01 PM, Singh, Aman Deep wrote:
>
> On 12/15/2022 7:11 AM, Chengwen Feng wrote:
>> This patch adds "--disable-flow-flush" parameter, which could used to
>> disable port flow flush when stop port. It allows testing keep flow
>> rules or shared flow objects across restart.
>>
>> Signed-off-by: Chengwen Feng
>> ---
>> app/test-pmd/parameters.c | 4
>> app/test-pmd/testpmd.c| 7 ++-
>> app/test-pmd/testpmd.h| 1 +
>> doc/guides/testpmd_app_ug/run_app.rst | 5 +
>> 4 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
>> index d597c209ba..e734ad9a02 100644
>> --- a/app/test-pmd/parameters.c
>> +++ b/app/test-pmd/parameters.c
>> @@ -175,6 +175,7 @@ usage(char* progname)
>> "disable print of designated event or all of them.\n");
>> printf(" --flow-isolate-all: "
>> "requests flow API isolated mode on all ports at initialization
>> time.\n");
>> +printf(" --disable-flow-flush: disable port flow flush when stop
>> port.\n");
>> printf(" --tx-offloads=0x: hexadecimal bitmask of TX queue
>> offloads\n");
>> printf(" --rx-offloads=0x: hexadecimal bitmask of RX queue
>> offloads\n");
>> printf(" --hot-plug: enable hot plug for device.\n");
>> @@ -667,6 +668,7 @@ launch_args_parse(int argc, char** argv)
>> { "rxfreet",1, 0, 0 },
>> { "no-flush-rx",0, 0, 0 },
>> { "flow-isolate-all", 0, 0, 0 },
>> +{ "disable-flow-flush", 0, 0, 0 },
>> { "rxoffs", 1, 0, 0 },
>> { "rxpkts", 1, 0, 0 },
>> { "rxhdrs", 1, 0, 0 },
>> @@ -1330,6 +1332,8 @@ launch_args_parse(int argc, char** argv)
>> rmv_interrupt = 0;
>> if (!strcmp(lgopts[opt_idx].name, "flow-isolate-all"))
>> flow_isolate_all = 1;
>> +if (!strcmp(lgopts[opt_idx].name, "disable-flow-flush"))
>> +no_flow_flush = 1;
>> if (!strcmp(lgopts[opt_idx].name, "tx-offloads")) {
>> char *end = NULL;
>> n = strtoull(optarg, &end, 16);
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
>> index 134d79a555..ea78f8982d 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -383,6 +383,11 @@ uint8_t no_flush_rx = 0; /* flush by default */
>> */
>> uint8_t flow_isolate_all;
>>
>> +/*
>> + * Disable port flow flush when stop port.
>> + */
>> +uint8_t no_flow_flush = 0; /* do flow flush by default */
>> +
>> /*
>> * Avoids to check link status when starting/stopping a port.
>> */
>> @@ -3246,7 +3251,7 @@ stop_port(portid_t pid)
>> }
>> }
>>
>> -if (port->flow_list)
>> +if (port->flow_list && !no_flow_flush)
>> port_flow_flush(pi);
>
> In case stop_port() is called through pmd_test_exit(), should the flag
> be disabled for flush to happen.
>
In case of 'pmd_test_exit()', 'close_port()' will be called after port
stop which will make port unusable anyway.
As long as there is no memory leak in that path, I think no need to for
flow flush.
@Chengwen, can you please check and confirm there won't be any resource
leak in case of 'no_flow_flush' is set and testpmd terminated via
'pmd_test_exit()' call?
And rest looks good to me.
>>
>> ret = eth_dev_stop_mp(pi);
>> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
>> index 7d24d25970..ab4733522d 100644
>> --- a/app/test-pmd/testpmd.h
>> +++ b/app/test-pmd/testpmd.h
>> @@ -476,6 +476,7 @@ extern uint8_t numa_support; /**< set by "--numa"
>> parameter */
>> extern uint16_t port_topology; /**< set by "--port-topology" parameter */
>> extern uint8_t no_flush_rx; /**> extern uint8_t flow_isolate_all; /**< set by "--flow-isolate-all */
>> +extern uint8_t no_flow_flush; /**< set by "--disable-flow-flush" parameter
>> */
>> extern uint8_t mp_alloc_type;
>> /**< set by "--mp-anon" or "--mp-alloc" parameter */
>> extern uint32_t eth_link_speed;
>> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
>> b/doc/guides/testpmd_app_ug/run_app.rst
>> index 074f910fc9..3ec3d4f5e6 100644
>> --- a/doc/guides/testpmd_app_ug/run_app.rst
>> +++ b/doc/guides/testpmd_app_ug/run_app.rst
>> @@ -436,6 +436,11 @@ The command line options are:
>>
>> Ports that do not support this mode are automatically discarded.
>>
>> +* ``--disable-flow-flush``
>> +
>> +Disable port flow flush when stop port. This allows testing keep flow
>> rules
>> +or shared flow objects across restart.
>> +
>> * ``--tx-offloads=0x``
>>
>> Set the hexadecimal bitmask of TX queue offloads.
Re: [PATCH 2/2] app/testpmd: add disable-flow-flush parameter
On 12/15/2022 1:41 AM, Chengwen Feng wrote:
> This patch adds "--disable-flow-flush" parameter, which could used to
> disable port flow flush when stop port. It allows testing keep flow
> rules or shared flow objects across restart.
>
> Signed-off-by: Chengwen Feng
+cc Ori
I am for proceeding with this patch unless there is objection from Aman
& Ori.
> ---
> app/test-pmd/parameters.c | 4
> app/test-pmd/testpmd.c| 7 ++-
> app/test-pmd/testpmd.h| 1 +
> doc/guides/testpmd_app_ug/run_app.rst | 5 +
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> index d597c209ba..e734ad9a02 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -175,6 +175,7 @@ usage(char* progname)
> "disable print of designated event or all of them.\n");
> printf(" --flow-isolate-all: "
> "requests flow API isolated mode on all ports at initialization
> time.\n");
> + printf(" --disable-flow-flush: disable port flow flush when stop
> port.\n");
> printf(" --tx-offloads=0x: hexadecimal bitmask of TX queue
> offloads\n");
> printf(" --rx-offloads=0x: hexadecimal bitmask of RX queue
> offloads\n");
> printf(" --hot-plug: enable hot plug for device.\n");
> @@ -667,6 +668,7 @@ launch_args_parse(int argc, char** argv)
> { "rxfreet",1, 0, 0 },
> { "no-flush-rx",0, 0, 0 },
> { "flow-isolate-all", 0, 0, 0 },
> + { "disable-flow-flush", 0, 0, 0 },
> { "rxoffs", 1, 0, 0 },
> { "rxpkts", 1, 0, 0 },
> { "rxhdrs", 1, 0, 0 },
> @@ -1330,6 +1332,8 @@ launch_args_parse(int argc, char** argv)
> rmv_interrupt = 0;
> if (!strcmp(lgopts[opt_idx].name, "flow-isolate-all"))
> flow_isolate_all = 1;
> + if (!strcmp(lgopts[opt_idx].name, "disable-flow-flush"))
> + no_flow_flush = 1;
> if (!strcmp(lgopts[opt_idx].name, "tx-offloads")) {
> char *end = NULL;
> n = strtoull(optarg, &end, 16);
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 134d79a555..ea78f8982d 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -383,6 +383,11 @@ uint8_t no_flush_rx = 0; /* flush by default */
> */
> uint8_t flow_isolate_all;
>
> +/*
> + * Disable port flow flush when stop port.
> + */
> +uint8_t no_flow_flush = 0; /* do flow flush by default */
> +
> /*
> * Avoids to check link status when starting/stopping a port.
> */
> @@ -3246,7 +3251,7 @@ stop_port(portid_t pid)
> }
> }
>
> - if (port->flow_list)
> + if (port->flow_list && !no_flow_flush)
> port_flow_flush(pi);
>
> ret = eth_dev_stop_mp(pi);
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
> index 7d24d25970..ab4733522d 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -476,6 +476,7 @@ extern uint8_t numa_support; /**< set by "--numa"
> parameter */
> extern uint16_t port_topology; /**< set by "--port-topology" parameter */
> extern uint8_t no_flush_rx; /** extern uint8_t flow_isolate_all; /**< set by "--flow-isolate-all */
> +extern uint8_t no_flow_flush; /**< set by "--disable-flow-flush" parameter */
> extern uint8_t mp_alloc_type;
> /**< set by "--mp-anon" or "--mp-alloc" parameter */
> extern uint32_t eth_link_speed;
> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
> b/doc/guides/testpmd_app_ug/run_app.rst
> index 074f910fc9..3ec3d4f5e6 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -436,6 +436,11 @@ The command line options are:
>
> Ports that do not support this mode are automatically discarded.
>
> +* ``--disable-flow-flush``
> +
> +Disable port flow flush when stop port. This allows testing keep flow
> rules
> +or shared flow objects across restart.
> +
> * ``--tx-offloads=0x``
>
> Set the hexadecimal bitmask of TX queue offloads.
Re: [dpdk-dev] [PATCH v1 00/12] mldev: introduce machine learning device library
On Wed, Jan 25, 2023 at 7:50 PM Thomas Monjalon wrote: > > 14/11/2022 13:02, jer...@marvell.com: > > From: Jerin Jacob > > > > Machine learning inference library > > == > > > > Definition of machine learning inference > > > > Inference in machine learning is the process of making an output prediction > > based on new input data using a pre-trained machine learning model. > > > > The scope of the RFC would include only inferencing with pre-trained > > machine learning models, > > training and building/compiling the ML models is out of scope for this RFC > > or > > DPDK mldev API. Use existing machine learning compiler frameworks for model > > creation. > > > > Motivation for the new library > > -- > > Multiple semiconductor vendors are offering accelerator products such as DPU > > (often called Smart-NIC), FPGA, GPU, etc., which have ML inferencing > > capabilities > > integrated as part of the product. Use of ML inferencing is increasing in > > the domain > > of packet processing for flow classification, intrusion, malware and > > anomaly detection. > > > > Lack of inferencing support through DPDK APIs will involve complexities and > > increased latency from moving data across frameworks (i.e, dataplane to > > non dataplane ML frameworks and vice-versa). Having a standardized DPDK > > APIs for ML > > inferencing would enable the dataplane solutions to harness the benefit of > > inline > > inferencing supported by the hardware. > > > > Contents > > --- > > > > A) API specification for: > > > > 1) Discovery of ML capabilities (e.g., device specific features) in a vendor > > independent fashion > > 2) Definition of functions to handle ML devices, which includes probing, > > initialization and termination of the devices. > > 3) Definition of functions to handle ML models used to perform inference > > operations. > > 4) Definition of function to handle quantize and dequantize operations > > > > B) Common code for above specification Thanks for the review. > > Can we compare this library with WinML? > https://learn.microsoft.com/en-us/windows/ai/windows-ml/api-reference Proposed DPDK library supports only inferencing with pre-trained models. > Is there things we can learn from it? Comparing to winML, API provide functionality similar to "LearningModel*" classes provides. Support related to handling custom operators and Native APIs like winML is provided through this API. There may more features which we can add where there are drivers which supports it. > > > > ML Model: An ML model is an algorithm trained over a dataset. A model > > consists of > > procedure/algorithm and data/pattern required to make predictions on live > > data. > > Once the model is created and trained outside of the DPDK scope, the model > > can be loaded > > via rte_ml_model_load() and then start it using rte_ml_model_start() API. > > The rte_ml_model_params_update() can be used to update the model parameters > > such as weight > > and bias without unloading the model using rte_ml_model_unload(). > > The fact that the model is prepared outside means the model format is free > and probably different per mldev driver. > I think it is OK but it requires a lot of documentation effort to explain > how to bind the model and its parameters with the DPDK API. > Also we may need to pass some metadata from the model builder > to the inference engine in order to enable optimizations prepared in the > model. > And the other way, we may need inference capabilities in order to generate > an optimized model which can run in the inference engine. The base API specification kept absolute minimum. Currently, weight and biases parameters updated through rte_ml_model_params_update(). It can be extended when there are drivers supports it or if you have any specific parameter you would like to add it in rte_ml_model_params_update(). Other metadata data like batch, shapes, formats queried using rte_ml_io_info(). > > > [...] > > Typical application utilisation of the ML API will follow the following > > programming flow. > > > > - rte_ml_dev_configure() > > - rte_ml_dev_queue_pair_setup() > > - rte_ml_model_load() > > - rte_ml_model_start() > > - rte_ml_model_info() > > - rte_ml_dev_start() > > - rte_ml_enqueue_burst() > > - rte_ml_dequeue_burst() > > - rte_ml_model_stop() > > - rte_ml_model_unload() > > - rte_ml_dev_stop() > > - rte_ml_dev_close() > > Where is parameters update in this flow? Added the mandatory APIs in the top level flow doc. rte_ml_model_params_update() used to update the parameters. > Should we update all parameters at once or can it be done more fine-grain? Currently, rte_ml_model_params_update() can be used to update weight and bias via buffer when device is in stop state and without unloading the model. > > > Question about the memory used by mldev: > Can we manage where the memory is allocated (hos
[PATCH 0/3] unblock the use of the MSVC compiler
Introduce minimum changes to the build system to allow use of the MSVC compiler. This change is intended to enable a phased approach to allowing DPDK to built with MSVC. Building with MSVC removes barriers to enterprise customers use of DPDK who have constraints around security policy, compliance and functional requirements. Tyler Retzlaff (3): build: unblock the use of the MSVC compiler build: determine execution environment at config time build: limit what is built when using MSVC compiler buildtools/meson.build | 10 +++--- config/meson.build | 29 ++--- config/x86/meson.build | 8 +--- lib/eal/meson.build| 8 lib/meson.build| 20 +--- meson.build| 13 + 6 files changed, 60 insertions(+), 28 deletions(-) -- 1.8.3.1
[PATCH 3/3] build: limit what is built when using MSVC compiler
Build only kvargs and telemetry when is_ms_compiler.
Signed-off-by: Tyler Retzlaff
---
lib/meson.build | 7 +++
meson.build | 13 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/lib/meson.build b/lib/meson.build
index 82e4666..8e99e21 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -65,6 +65,13 @@ libraries = [
'node',
]
+if is_ms_compiler
+libraries = [
+'kvargs',
+'telemetry',
+]
+endif
+
optional_libs = [
'bitratestats',
'cfgfile',
diff --git a/meson.build b/meson.build
index f91d652..e095192 100644
--- a/meson.build
+++ b/meson.build
@@ -76,11 +76,16 @@ subdir('config')
# build libs and drivers
subdir('lib')
-subdir('drivers')
-# build binaries and installable tools
-subdir('usertools')
-subdir('app')
+if is_ms_compiler
+enabled_apps = []
+else
+subdir('drivers')
+
+# build binaries and installable tools
+subdir('usertools')
+subdir('app')
+endif
# build docs
subdir('doc')
--
1.8.3.1
[PATCH 2/3] build: determine execution environment at config time
Move execution environment determination and definitions to config. The
RTE_EXEC_ENV macros are actually used by libraries built before EAL.
Currently it does not matter that this is determined in lib/eal since
the definitions are consumed before anything is built including libs
built before lib/eal. By moving this logic to config it allows kvargs
and telemetry to be built without EAL.
No functional change intended.
Signed-off-by: Tyler Retzlaff
---
config/meson.build | 8
lib/eal/meson.build | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/config/meson.build b/config/meson.build
index 898b743..e0b9e4e 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -14,6 +14,14 @@ foreach env:supported_exec_envs
set_variable('is_' + env, exec_env == env)
endforeach
+exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2}
+foreach env, id:exec_envs
+dpdk_conf.set('RTE_ENV_' + env.to_upper(), id)
+dpdk_conf.set10('RTE_EXEC_ENV_IS_' + env.to_upper(), (exec_env == env))
+endforeach
+dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env])
+dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
+
# MS linker requires special treatment.
# TODO: use cc.get_linker_id() with Meson >= 0.54
is_ms_compiler = is_windows and (cc.get_id() == 'msvc')
diff --git a/lib/eal/meson.build b/lib/eal/meson.build
index 056beb9..26c638f 100644
--- a/lib/eal/meson.build
+++ b/lib/eal/meson.build
@@ -10,14 +10,6 @@ if not is_windows
subdir('unix')
endif
-exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2}
-foreach env, id:exec_envs
-dpdk_conf.set('RTE_ENV_' + env.to_upper(), id)
-dpdk_conf.set10('RTE_EXEC_ENV_IS_' + env.to_upper(), (exec_env == env))
-endforeach
-dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env])
-
-dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
subdir(exec_env)
subdir(arch_subdir)
--
1.8.3.1
[PATCH 1/3] build: unblock the use of the MSVC compiler
Detect when MSVC toolset is available and tweak toolchain arguments
where the meson build system offers no abstraction.
Signed-off-by: Tyler Retzlaff
---
buildtools/meson.build | 10 +++---
config/meson.build | 21 ++---
config/x86/meson.build | 8 +---
lib/meson.build| 13 ++---
4 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/buildtools/meson.build b/buildtools/meson.build
index e1c600e..838c39f 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -4,7 +4,9 @@
pkgconf = find_program('pkg-config', 'pkgconf', required: false)
check_symbols = find_program('check-symbols.sh')
ldflags_ibverbs_static = find_program('options-ibverbs-static.sh')
-objdump = find_program('objdump', 'llvm-objdump')
+if cc.get_id() != 'msvc'
+objdump = find_program('objdump', 'llvm-objdump')
+endif
python3 = import('python').find_installation(required: false)
if python3.found()
@@ -18,8 +20,10 @@ map_to_win_cmd = py3 + files('map_to_win.py')
sphinx_wrapper = py3 + files('call-sphinx-build.py')
get_cpu_count_cmd = py3 + files('get-cpu-count.py')
get_numa_count_cmd = py3 + files('get-numa-count.py')
-binutils_avx512_check = (py3 + files('binutils-avx512-check.py') +
-[objdump] + cc.cmd_array())
+if cc.get_id() != 'msvc'
+binutils_avx512_check = (py3 + files('binutils-avx512-check.py') +
+[objdump] + cc.cmd_array())
+endif
# select library and object file format
pmdinfo = py3 + files('gen-pmdinfo-cfile.py') + [meson.current_build_dir()]
diff --git a/config/meson.build b/config/meson.build
index 6d9ffd4..898b743 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -16,7 +16,8 @@ endforeach
# MS linker requires special treatment.
# TODO: use cc.get_linker_id() with Meson >= 0.54
-is_ms_linker = is_windows and (cc.get_id() == 'clang')
+is_ms_compiler = is_windows and (cc.get_id() == 'msvc')
+is_ms_linker = is_windows and (cc.get_id() == 'clang' or is_ms_compiler)
# set the major version, which might be used by drivers and libraries
# depending on the configuration options
@@ -130,11 +131,13 @@ dpdk_conf.set('RTE_MACHINE', cpu_instruction_set)
machine_args = []
# ppc64 does not support -march= at all, use -mcpu and -mtune for that
-if host_machine.cpu_family().startswith('ppc')
-machine_args += '-mcpu=' + cpu_instruction_set
-machine_args += '-mtune=' + cpu_instruction_set
-else
-machine_args += '-march=' + cpu_instruction_set
+if not is_ms_compiler
+if host_machine.cpu_family().startswith('ppc')
+machine_args += '-mcpu=' + cpu_instruction_set
+machine_args += '-mtune=' + cpu_instruction_set
+else
+machine_args += '-march=' + cpu_instruction_set
+endif
endif
toolchain = cc.get_id()
@@ -252,7 +255,11 @@ if cc.get_id() == 'clang' and dpdk_conf.get('RTE_ARCH_64')
== false
endif
# add -include rte_config to cflags
-add_project_arguments('-include', 'rte_config.h', language: 'c')
+if is_ms_compiler
+add_project_arguments('/FI', 'rte_config.h', language: 'c')
+else
+add_project_arguments('-include', 'rte_config.h', language: 'c')
+endif
# enable extra warnings and disable any unwanted warnings
# -Wall is added by default at warning level 1, and -Wextra
diff --git a/config/x86/meson.build b/config/x86/meson.build
index 54345c4..11f0bcc 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -25,9 +25,11 @@ if cc.has_argument('-mavx512f')
endif
# we require SSE4.2 for DPDK
-if cc.get_define('__SSE4_2__', args: machine_args) == ''
-message('SSE 4.2 not enabled by default, explicitly enabling')
-machine_args += '-msse4'
+if not is_ms_compiler
+if cc.get_define('__SSE4_2__', args: machine_args) == ''
+message('SSE 4.2 not enabled by default, explicitly enabling')
+machine_args += '-msse4'
+endif
endif
base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
diff --git a/lib/meson.build b/lib/meson.build
index a90fee3..82e4666 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -235,9 +235,16 @@ foreach l:libraries
output: '@0@_exports.def'.format(libname))
lk_deps += [def_file]
-lk_args = ['-Wl,/def:' + def_file.full_path()]
-if meson.version().version_compare('<0.54.0')
-lk_args += ['-Wl,/implib:lib\\librte_' + l + '.dll.a']
+if is_ms_compiler
+lk_args = ['/def:' + def_file.full_path()]
+if meson.version().version_compare('<0.54.0')
+lk_args += ['/implib:lib\\librte_' + l + '.dll.a']
+endif
+else
+lk_args = ['-Wl,/def:' + def_file.full_path()]
+if meson.version().version_compare('<0.54.0')
+lk_args += ['-Wl,/implib:lib\\librte_' + l + '.dll.a']
+endif
endif
else
if is_windows
--
1.8.3.1
deprecation notice process / clarification
hi, i'm looking for some guidance when cleaning up / removing the remaining shim functions for pthread in windows and i'm not sure how our deprecation notice / policies apply. windows has been providing lib/eal/windows/include/pthread.h shim that allowed applications to use e.g. pthread_xxx functions on windows. these shim functions were all being provided as inline functions and were not part of the EAL api but on windows they were implicitly part of the api surface exposed (to windows only). on posix platforms applications did not rely on EAL for pthread abi or api (obviously). recently we introduced a set of platform agnostic thread api in the EAL. the functions were marked __rte_experimental as a part of new API addition policy. what's the most appropriate way to remove the pthread_xxx shim inline functions from lib/eal/windows/include/pthread.h? do we have to wait the full deprecation notice period which can't be started until we make the new functions stable? also keeping in mind we can't actually mark inline functions __rte_deprecated. is this a special case where we can just rip them out and break compilation? input is appreciated, particularly from any consumers of the windows port who might be unhappy. thanks
[PATCH] app/testpmd: expand noisy neighbour forward mode support
Previously the noisy neighbour vnf simulation would only operate in io
mode, forwarding packets as is. However, this limited the usefulness of
noisy neighbour simulation.
This feature has now been expanded into all forwarding modes except for
ieee1588, where it isn't relevant; and iofwd, which would otherwise be
duplicative of noisy mode.
Additionally, the calls to rte_rand in noisy's memory simulation were
replaced with a simple function as the calls to rte_rand incured a
level of overhead and variance that significantly overshadowed the
memory activity that this feature was designed to exercise.
Signed-off-by: Mike Pattrick
---
app/test-pmd/5tswap.c | 29 ++
app/test-pmd/csumonly.c | 36 ++-
app/test-pmd/flowgen.c| 24 +
app/test-pmd/icmpecho.c | 28 +-
app/test-pmd/macfwd.c | 27 +-
app/test-pmd/macswap.c| 28 +-
app/test-pmd/noisy_vnf.c | 134 --
app/test-pmd/testpmd.c| 6 ++
app/test-pmd/txonly.c | 38 ++--
doc/guides/testpmd_app_ug/run_app.rst | 19 ++--
10 files changed, 134 insertions(+), 235 deletions(-)
diff --git a/app/test-pmd/5tswap.c b/app/test-pmd/5tswap.c
index f041a5e1d5..d66f520efa 100644
--- a/app/test-pmd/5tswap.c
+++ b/app/test-pmd/5tswap.c
@@ -19,6 +19,7 @@
#include "macswap_common.h"
#include "testpmd.h"
+#include "noisy_vnf.h"
static inline void
@@ -91,8 +92,6 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
uint64_t ol_flags;
uint16_t proto;
uint16_t nb_rx;
- uint16_t nb_tx;
- uint32_t retry;
int i;
union {
@@ -116,7 +115,7 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
nb_pkt_per_burst);
inc_rx_burst_stats(fs, nb_rx);
if (unlikely(nb_rx == 0))
- return;
+ goto flush;
fs->rx_packets += nb_rx;
txp = &ports[fs->tx_port];
@@ -162,26 +161,10 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
}
mbuf_field_set(mb, ol_flags);
}
- nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, nb_rx);
- /*
-* Retry if necessary
-*/
- if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
- retry = 0;
- while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
- rte_delay_us(burst_tx_delay_time);
- nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
- &pkts_burst[nb_tx], nb_rx - nb_tx);
- }
- }
- fs->tx_packets += nb_tx;
- inc_tx_burst_stats(fs, nb_tx);
- if (unlikely(nb_tx < nb_rx)) {
- fs->fwd_dropped += (nb_rx - nb_tx);
- do {
- rte_pktmbuf_free(pkts_burst[nb_tx]);
- } while (++nb_tx < nb_rx);
- }
+
+flush:
+ noisy_eth_tx_burst(fs, nb_rx, pkts_burst);
+
get_end_cycles(fs, start_tsc);
}
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 1c24598515..5feb9a9c07 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -48,6 +48,7 @@
#include
#include "testpmd.h"
+#include "noisy_vnf.h"
#define IP_DEFTTL 64 /* from RFC 1340. */
@@ -847,12 +848,10 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint8_t gro_enable;
#endif
uint16_t nb_rx;
- uint16_t nb_tx;
uint16_t nb_prep;
uint16_t i;
uint64_t rx_ol_flags, tx_ol_flags;
uint64_t tx_offloads;
- uint32_t retry;
uint32_t rx_bad_ip_csum;
uint32_t rx_bad_l4_csum;
uint32_t rx_bad_outer_l4_csum;
@@ -867,8 +866,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
nb_rx = rte_eth_rx_burst(fs->rx_port, fs->rx_queue, pkts_burst,
nb_pkt_per_burst);
inc_rx_burst_stats(fs, nb_rx);
- if (unlikely(nb_rx == 0))
- return;
+ if (unlikely(nb_rx == 0)) {
+ // May still need to flush some packets
+ nb_prep = 0;
+ tx_pkts_burst = pkts_burst;
+ goto flush;
+ }
+
fs->rx_packets += nb_rx;
rx_bad_ip_csum = 0;
@@ -1173,33 +1177,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
"Preparing packet burst to transmit failed: %s\n",
rte_strerror(rte_errno));
- nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, tx_pkts_burst,
- nb_prep);
-
- /*
-* Retry if necessary
-*/
- if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
- retry = 0;
- while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
- rte_delay_us(burst_tx_delay_time);
- nb_tx += rte_eth_tx_burst(fs-
Re: [PATCH] app/testpmd: expand noisy neighbour forward mode support
On Wed, 25 Jan 2023 17:45:31 -0500
Mike Pattrick wrote:
> + if (unlikely(nb_rx == 0)) {
> + // May still need to flush some packet
DPDK style is to only use C style comments
Re: [PATCH] app/testpmd: expand noisy neighbour forward mode support
On Wed, 25 Jan 2023 17:45:31 -0500
Mike Pattrick wrote:
> +
> +static uint64_t rnd(void)
> +{
> + RTE_PER_LCORE(seed) = 1103515245U * RTE_PER_LCORE(seed) + 12345U;
> +
> + return RTE_PER_LCORE(seed);
> +}
> +
Strong NAK
don't add another random generator.
[PATCH v2] app/testpmd: expand noisy neighbour forward mode support
Previously the noisy neighbour vnf simulation would only operate in io
mode, forwarding packets as is. However, this limited the usefulness of
noisy neighbour simulation.
This feature has now been expanded into all forwarding modes except for
ieee1588, where it isn't relevant; and iofwd, which would otherwise be
duplicative of noisy mode.
Signed-off-by: Mike Pattrick
---
v2:
- Included header that was incorrectly excluded from v1
- Restored calls to rte_rand()
---
app/test-pmd/5tswap.c | 29 ++-
app/test-pmd/csumonly.c | 36 +++-
app/test-pmd/flowgen.c| 24 +-
app/test-pmd/icmpecho.c | 28 +-
app/test-pmd/macfwd.c | 27 +-
app/test-pmd/macswap.c| 28 ++
app/test-pmd/noisy_vnf.c | 118 --
app/test-pmd/noisy_vnf.h | 48 +++
app/test-pmd/testpmd.c| 6 ++
app/test-pmd/txonly.c | 38 ++---
doc/guides/testpmd_app_ug/run_app.rst | 19 +++--
11 files changed, 172 insertions(+), 229 deletions(-)
create mode 100644 app/test-pmd/noisy_vnf.h
diff --git a/app/test-pmd/5tswap.c b/app/test-pmd/5tswap.c
index f041a5e1d5..d66f520efa 100644
--- a/app/test-pmd/5tswap.c
+++ b/app/test-pmd/5tswap.c
@@ -19,6 +19,7 @@
#include "macswap_common.h"
#include "testpmd.h"
+#include "noisy_vnf.h"
static inline void
@@ -91,8 +92,6 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
uint64_t ol_flags;
uint16_t proto;
uint16_t nb_rx;
- uint16_t nb_tx;
- uint32_t retry;
int i;
union {
@@ -116,7 +115,7 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
nb_pkt_per_burst);
inc_rx_burst_stats(fs, nb_rx);
if (unlikely(nb_rx == 0))
- return;
+ goto flush;
fs->rx_packets += nb_rx;
txp = &ports[fs->tx_port];
@@ -162,26 +161,10 @@ pkt_burst_5tuple_swap(struct fwd_stream *fs)
}
mbuf_field_set(mb, ol_flags);
}
- nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, nb_rx);
- /*
-* Retry if necessary
-*/
- if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
- retry = 0;
- while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
- rte_delay_us(burst_tx_delay_time);
- nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
- &pkts_burst[nb_tx], nb_rx - nb_tx);
- }
- }
- fs->tx_packets += nb_tx;
- inc_tx_burst_stats(fs, nb_tx);
- if (unlikely(nb_tx < nb_rx)) {
- fs->fwd_dropped += (nb_rx - nb_tx);
- do {
- rte_pktmbuf_free(pkts_burst[nb_tx]);
- } while (++nb_tx < nb_rx);
- }
+
+flush:
+ noisy_eth_tx_burst(fs, nb_rx, pkts_burst);
+
get_end_cycles(fs, start_tsc);
}
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 1c24598515..2a6cf07adb 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -48,6 +48,7 @@
#include
#include "testpmd.h"
+#include "noisy_vnf.h"
#define IP_DEFTTL 64 /* from RFC 1340. */
@@ -847,12 +848,10 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
uint8_t gro_enable;
#endif
uint16_t nb_rx;
- uint16_t nb_tx;
uint16_t nb_prep;
uint16_t i;
uint64_t rx_ol_flags, tx_ol_flags;
uint64_t tx_offloads;
- uint32_t retry;
uint32_t rx_bad_ip_csum;
uint32_t rx_bad_l4_csum;
uint32_t rx_bad_outer_l4_csum;
@@ -867,8 +866,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
nb_rx = rte_eth_rx_burst(fs->rx_port, fs->rx_queue, pkts_burst,
nb_pkt_per_burst);
inc_rx_burst_stats(fs, nb_rx);
- if (unlikely(nb_rx == 0))
- return;
+ if (unlikely(nb_rx == 0)) {
+ /* May still need to flush some packets */
+ nb_prep = 0;
+ tx_pkts_burst = pkts_burst;
+ goto flush;
+ }
+
fs->rx_packets += nb_rx;
rx_bad_ip_csum = 0;
@@ -1173,33 +1177,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
"Preparing packet burst to transmit failed: %s\n",
rte_strerror(rte_errno));
- nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, tx_pkts_burst,
- nb_prep);
-
- /*
-* Retry if necessary
-*/
- if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
- retry = 0;
- while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
- rte_delay_us(burst_tx_delay_time);
- nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
-
[Bug 1158] Mac address configuration on bonded device in 8023ad mode is not propagated to slave devices
https://bugs.dpdk.org/show_bug.cgi?id=1158 Bug ID: 1158 Summary: Mac address configuration on bonded device in 8023ad mode is not propagated to slave devices Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: k...@cesnet.cz Target Milestone: --- When you try to change the default mac address on a bonded device in 8023ad mode, the new mac address is not propagated to slave devices so packets with this new mac address are not delivered because they are dropped on the slave device. Steps to Reproduce in testpmd: dpdk-testpmd --log-level=pmd.net.bonding:debug -a :3b:00.0 -c 0x0f -n 4 --vdev 'net_bonding0,slave=:3b:00.0,mode=4,agg_mode=count' -- -i --port-topology=chained testpmd> port stop all testpmd> show bonding config 1 testpmd> set promisc 1 off testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> port stop all testpmd> set bonding mac_addr 1 00:11:22:33:44:55 testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 00:11:22:33:44:55 ... For comparison, the same steps for the bonded device in mode 0 (round-robin): dpdk-testpmd --log-level=pmd.net.bonding:debug -a :3b:00.1 -c 0x0f -n 4 --vdev 'net_bonding0,slave=:3b:00.1,mode=0' -- -i --port-topology=chained testpmd> port stop all testpmd> show bonding config 1 testpmd> set promisc 1 off testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:85 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 04:3F:72:C7:B8:85 ... testpmd> port stop all testpmd> set bonding mac_addr 00:11:22:33:44:55 testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 00:11:22:33:44:55 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 00:11:22:33:44:55 ... For comparison, configuring a bond device in 802.3ad mode using NMCLI: sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad" sudo nmcli connection modify bond0 ipv4.dhcp-timeout infinity sudo nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname ens1f0np0 master bond0 sudo ip address show bond0 11: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 04:3f:72:c7:b8:84 brd ff:ff:ff:ff:ff:ff ... sudo ip link show ens1f0np0 6: ens1f0np0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 04:3f:72:c7:b8:84 brd ff:ff:ff:ff:ff:ff ... sudo ip link set dev bond0 address 00:11:22:33:44:55 sudo ip link show bond0 11: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff ... sudo ip link show ens1f0np0 6: ens1f0np0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff permaddr 04:3f:72:c7:b8:84 ... [DPDK version] commit f262f16087ea6a77357a915cf4c0d10ddc7b6562 (HEAD, tag: v22.11, origin/releases) Author: Thomas Monjalon Date: Sun Nov 27 11:36:36 2022 +0100 version: 22.11.0 Signed-off-by: Thomas Monjalon [OS version] Operating System: Oracle Linux Server 8.7 Kernel: Linux 4.18.0-348.12.2.el8_5.x86_64 Architecture: x86-64 [Network devices] :3b:00.0 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f0np0 drv=mlx5_core (802.3ad with LACP) :3b:00.1 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f1np1 drv=mlx5_core -- You are receiving this mail because: You are the assignee for the bug.
