Re: [RFC] random: use per lcore state
On 2023-09-07 01:00, Stephen Hemminger wrote: On Wed, 6 Sep 2023 22:02:54 +0200 Mattias Rönnblom wrote: On 2023-09-06 19:20, Stephen Hemminger wrote: Move the random number state into thread local storage. Me and Morten discussed TLS versus other alternatives in some other thread. The downside of TLS that Morten pointed out, from what I recall, is that lazy initialization is *required* (since the number of threads is open-ended), and the data ends up in non-huge page memory. It was also unclear to me what the memory footprint implications would be, would large per-lcore data structures be put in TLS. More specifically, if they would be duplicated across all threads, even non-lcore threads. But current method is unsafe on non-lcore threads. Two non-lcore threads calling rte_rand() will clash on state without any locking protection. Sure, just like the API docs say, although the documentation use more precise terminology. If you want to extend the API MT safety guarantees, it should come with an argument to why this change is needed. Is this to save the application from calling rte_thread_register() in control plane threads? For convenience? Or for being generally less error prone? Another reason might be that the application have many threads (more than RTE_LCORE_MAX), so it will run out of lcore ids. Also, right now the array is sized at 129 entries to allow for the maximum number of lcores. When the maximum is increased to 512 or 1024 the problem will get worse. Using TLS will penalize every thread in the process, not only EAL threads and registered non-EAL threads, and worse: not only threads that are using the API in question. Every thread will carry the TLS memory around, increasing the process memory footprint. Thread creation will be slower, since TLS memory is allocated *and initialized*, lazy user code-level initialization or not. On my particular Linux x86_64 system, pthread creation overhead looks something like: 8 us w/o any user code-level use of TLS 11 us w/ 16 kB of TLS 314 us w/ 2 MB of TLS. So, whatever you put into TLS, it needs to be small. Putting a large amount of data into TLS will effectively prevent the DPDK libraries from being linked into a heavily multi-threaded app, regardless if those threads calls into DPDK or not. Again, this doesn't much affect rte_random.c, but does disqualify TLS as a plug-in replacement for the current pattern with a statically allocated lcore id-indexed array.
Re: Troubleshooting DPDK in Intel Ethernet NIC
Hello, On Fri, Sep 8, 2023 at 8:42 AM Antón Rey Villaverde wrote: > > Hi, > I have a problem while trying to manage my physical Ethernet interface from > DPDK (latest version compiled from source). > I have a: > NIC: :00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection > (13) I219-LM (rev 20) > > which belongs to the list of supported NICs in DPDK. > > Also, I have bound my NICto vfio-pci, not the kernel: > > dpdk-23.07$ usertools/dpdk-devbind.py --status > Network devices using DPDK-compatible driver > :00:1f.6 'Ethernet > Connection (13) I219-LM 15fb' drv=vfio-pci unused=e1000e > > I also enabled hugepages (2G). > > when I enter "sudo build/app/dpdk-testpmd -c7 -- -i" I get: > EAL: Detected CPU lcores: 8 > EAL: Detected NUMA nodes: 1 > EAL: Detected static linkage of DPDK > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > EAL: Selected IOVA mode 'VA' > EAL: VFIO support initialized > TELEMETRY: No legacy callbacks, legacy socket not created > testpmd: No probed ethernet devices > Interactive-mode selected > testpmd: create a new mbuf pool : n=163456, size=2176, socket=0 > testpmd: preferred mempool ops selected: ring_mp_mc > Done > testpmd> > > When I enter "show port info all" in the testpmd CLI I get nothing (no ports). > > When I start testpmd with "-a :00:1f.6" (the address of the ethernet NIC > I want to manage from DPDK), The same happens (no ports). Afaics, this nic is not supported by DPDK drivers. You will have to find some other nic, or run on another server with supported nics. Some details below. For a statically linked DPDK application (which is the default for testpmd), you can check with dpdk-pmd-info.py which PCI devices are supported. Example: $ ./usertools/dpdk-pmdinfo.py build/app/dpdk-testpmd | grep -i 15fb > > If I try to start testpmd with "-d build/drivers/librte_net_e1000.so" (the > shared library of the driver of that device), I get a crash: > > dpdk-23.07$ sudo build/app/dpdk-testpmd -c7 -a :00:1f.6 -d > build/drivers/librte_net_e1000.so -- -i > EAL: Detected CPU lcores: 8 > EAL: Detected NUMA nodes: 1 > EAL: Detected static linkage of DPDK Your testpmd binary has been statically linked (as I said above, this is the default) and you can see the log message confirming it. > EAL: UIO_RESOURCE_LIST tailq is already registered PANIC in > tailqinitfn_rte_uio_tailq(): Cannot initialize tailq: UIO_RESOURCE_LIST > 0: build/app/dpdk-testpmd (rte_dump_stack+0x32) [55be1839afe2] > 1: build/app/dpdk-testpmd (__rte_panic+0xf1) [55be18369e68] > 2: /home/anton/tdr/dpdk-23.07/build/drivers/librte_bus_pci.so.23 > (7f52153f6000+0x5d86) [7f52153fbd86] > 3: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x11b9a) [7f5215fa1b9a] > 4: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x11ca1) [7f5215fa1ca1] > 5: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0xe5) [7f5215970985] > 6: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x160cf) [7f5215fa60cf] > 7: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x88) [7f5215970928] > 8: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x1560a) [7f5215fa560a] > 9: /lib/x86_64-linux-gnu/libdl.so.2 (7f5215e15000+0x134c) [7f5215e1634c] > 10: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x88) [7f5215970928] > 11: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x33) [7f52159709f3] > 12: /lib/x86_64-linux-gnu/libdl.so.2 (7f5215e15000+0x1b59) [7f5215e16b59] > 13: /lib/x86_64-linux-gnu/libdl.so.2 (dlopen+0x4a) [7f5215e163da] > 14: build/app/dpdk-testpmd (55be17b79000+0x8013ee) [55be1837a3ee] > 15: build/app/dpdk-testpmd (eal_plugins_init+0x14f) [55be1837a6d8] > 16: build/app/dpdk-testpmd (rte_eal_init+0x1af) [55be1839ec21] > 17: build/app/dpdk-testpmd (main+0xde) [55be17da108b] > 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [7f5215834083] > 19: build/app/dpdk-testpmd (_start+0x2e) [55be17cef1fe] > Aborted This is not a crash, EAL willingly aborts because initialising UIO shared tailq has been requested twice and this is not something supported. This happened as you requested to load a driver that is embedded in the testpmd binary and has already been initialised. -- David Marchand
Re: quick thread in DLB2
On 2023-09-08 00:09, Sevincer, Abdullah wrote: Hi Stephen, It is probing ports for best CPU. Yes it collects cycles. We may rework in the future. Best, in what sense? Is this some kind of topology exploration? One DLB port being closer to (cheaper to access for) certain cores? Open to suggestions. -Original Message- From: Stephen Hemminger Sent: Wednesday, September 6, 2023 12:45 PM To: Thomas Monjalon Cc: Sevincer, Abdullah ; dev@dpdk.org; Tyler Retzlaff Subject: Re: quick thread in DLB2 On Fri, 01 Sep 2023 16:08:48 +0200 Thomas Monjalon wrote: Hello Abdullah, In the DLB2 code, I see a thread is created for a single operation: In drivers/event/dlb2/pf/base/dlb2_resource.c pthread_create(&pthread, NULL, &dlb2_pp_profile_func, &dlb2_thread_data[i]); and just after: pthread_join(pthread, NULL); Can we avoid creating this thread? I guess no, because it must spawn on a specific CPU. The per thread data seems to break lots of expectations in EAL. It all seems to be about capturing the number of cycles on different cores. Looks like a mess.
Re: [PATCH 3/5] app/proc-info: fix never show RSS info
Hi, Pattan, Reshma On 2023/9/6 0:29, Pattan, Reshma wrote: -Original Message- + uint8_t *rss_key; Instead of pointer can you just take key of type below, so u no need to do dynamic memory allocation using malloc and free . Ex: uint8_t hash_key[RSS_HASH_KEY_LENGTH]; And then do below ? rss_conf.rss_key = hash_key; . Thanks for your review, will fix it in next version. Thanks, Jie Hai
Re: [PATCH 5/5] app/proc-info: support querying RSS hash algorithm
Hi, Pattan, Reshma
On 2023/9/6 1:07, Pattan, Reshma wrote:
Instead of above function you can declare const array of strings as below to
map hash function names.
static const char * const hf_names[] = {
[RTE_ETH_HASH_FUNCTION_SIMPLE_XOR] = " simple_xor ",
[RTE_ETH_HASH_FUNCTION_TOEPLITZ] = " toeplitz ",
[RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ] = " symmetric_toeplitz ",
[RTE_ETH_HASH_FUNCTION_DEFAULT] = "default"
};
+ printf("\t -- hash algorithm : %s\n",
+ rss_func_to_str(rss_conf.func));
}
And then print as below ?
printf("\t -- hash algorithm : %s\n", hf_names [rss_conf.func]);
.
Thanks for your review, that sounds better, will fix it.
Thanks,
Jie Hai
[PATCH v4 0/7] support setting and querying RSS algorithms
This patchset is to support setting and querying RSS algorithms. -- v4: 1. recomment some definitions related to RSS. 2. allocate static memory for rss_key instead of dynamic. 3. use array of strings to get the name of rss algorithm. 4. add display of rss algorithm with testpmd. v3: 1. fix commit log for PATCH [1/5]. 2. make RSS ABI changes description to start the actual text at the margin. 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h. 4. fix some comment codes. v2: 1. return error if "func" is invalid. 2. modify the comments of the "func" field. 3. modify commit log of patch [3/5]. 4. use malloc instead of rte_malloc. 5. adjust display format of RSS info. 6. remove the string display of rss_hf. Huisong Li (1): net/hns3: support setting and querying RSS hash function Jie Hai (6): ethdev: recomment some definitions related to RSS ethdev: support setting and querying RSS algorithm app/proc-info: fix never show RSS info app/proc-info: adjust the display format of RSS info app/proc-info: support querying RSS hash algorithm app/testpmd: add RSS hash algorithms display app/proc-info/main.c | 31 +++- app/test-pmd/cmdline.c | 29 --- app/test-pmd/config.c | 36 +-- app/test-pmd/testpmd.h | 2 +- doc/guides/rel_notes/release_23_11.rst | 2 ++ drivers/net/hns3/hns3_rss.c| 47 +--- lib/ethdev/rte_ethdev.c| 17 + lib/ethdev/rte_ethdev.h| 49 ++ lib/ethdev/rte_flow.c | 1 - lib/ethdev/rte_flow.h | 18 ++ 10 files changed, 146 insertions(+), 86 deletions(-) -- 2.30.0
[PATCH v4 1/7] ethdev: recomment some definitions related to RSS
1. Recomment fields of 'rte_eth_rss_conf'.
2. Add comments for RTE_ETH_HASH_FUNCTION_DEFAULT.
Signed-off-by: Jie Hai
---
lib/ethdev/rte_ethdev.h | 28 +---
lib/ethdev/rte_flow.h | 4
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 04a2564f222a..40cfbb7efddd 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -448,24 +448,22 @@ struct rte_vlan_filter_conf {
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
- * If not NULL, the *rss_key* pointer of the *rss_conf* structure points
- * to an array holding the RSS key to use for hashing specific header
- * fields of received packets. The length of this array should be indicated
- * by *rss_key_len* below. Otherwise, a default random hash key is used by
- * the device driver.
- *
- * The *rss_key_len* field of the *rss_conf* structure indicates the length
- * in bytes of the array pointed by *rss_key*. To be compatible, this length
- * will be checked in i40e only. Others assume 40 bytes to be used as before.
- *
- * The *rss_hf* field of the *rss_conf* structure indicates the different
- * types of IPv4/IPv6 packets to which the RSS hashing must be applied.
- * Supplying an *rss_hf* equal to zero disables the RSS feature.
*/
struct rte_eth_rss_conf {
- uint8_t *rss_key;/**< If not NULL, 40-byte hash key. */
+ /**
+* If not NULL, 40-byte hash key to use for hashing specific header
+* fields of received packets. The size of rss_key should be indicated
+* by *rss_key_len* below.
+* Otherwise, a default random hash key is used by the device driver.
+*/
+ uint8_t *rss_key;
uint8_t rss_key_len; /**< hash key length in bytes. */
- uint64_t rss_hf; /**< Hash functions to apply - see below. */
+ /**
+* The different types of packets to which the RSS hashing must be
+* applied, may be combined with SRC/DST_ONLY, see below.
+* Supplying an *rss_hf* equal to zero disables the RSS feature.
+*/
+ uint64_t rss_hf;
};
/*
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 2ebb76dbc083..3bd0dc64fbe2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3187,6 +3187,10 @@ struct rte_flow_query_count {
* Hash function types.
*/
enum rte_eth_hash_function {
+ /**
+* DEFAULT means that conformance to a specific hash algorithm is
+* uncared to the caller. The driver can pick the one it deems optimal.
+*/
RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
--
2.30.0
[PATCH v4 2/7] ethdev: support setting and querying RSS algorithm
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "func". This represents the RSS algorithms to apply. The
following API will be affected:
- rte_eth_dev_configure
- rte_eth_dev_rss_hash_update
- rte_eth_dev_rss_hash_conf_get
If the value of "func" used for configuration is a gibberish
value, report the error and return. Do the same for
rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
To check whether the drivers report the "func" field, it is set
to default value before querying.
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
doc/guides/rel_notes/release_23_11.rst | 2 ++
lib/ethdev/rte_ethdev.c| 17 +
lib/ethdev/rte_ethdev.h| 21 +
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 22 ++
5 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst
b/doc/guides/rel_notes/release_23_11.rst
index 333e1d95a283..deb019fbe4c1 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -129,6 +129,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
===
+* ethdev: Added "func" field to ``rte_eth_rss_conf`` structure for RSS hash
+ algorithm.
Known Issues
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 0840d2b5942a..4cbcdb344cac 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1445,6 +1445,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t
nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ if (dev_conf->rx_adv_conf.rss_conf.func >= RTE_ETH_HASH_FUNCTION_MAX) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid rss hash function (%u)\n",
+ port_id, dev_conf->rx_adv_conf.rss_conf.func);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/* Check if Rx RSS distribution is disabled but RSS hash is enabled. */
if (((dev_conf->rxmode.mq_mode & RTE_ETH_MQ_RX_RSS_FLAG) == 0) &&
(dev_conf->rxmode.offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)) {
@@ -4630,6 +4638,13 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -ENOTSUP;
}
+ if (rss_conf->func >= RTE_ETH_HASH_FUNCTION_MAX) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid rss hash function (%u)\n",
+ port_id, rss_conf->func);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4657,6 +4672,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->func = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 40cfbb7efddd..33cec3570f85 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,26 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /**
+* DEFAULT means that conformance to a specific hash algorithm is
+* uncared to the caller. The driver can pick the one it deems optimal.
+*/
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+* Symmetric Toeplitz: src, dst will be replaced by
+* xor(src, dst). For the case with src/dst only,
+* src or dst address will xor with zero pair.
+*/
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -464,6 +484,7 @@ struct rte_eth_rss_conf {
* Supplying an *rss_hf* equal to zero disables the RSS feature.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function func;/**< Hash algorithm. */
};
/*
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 271d854f7807..d3f2d466d841 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 3bd0dc64fbe2..a7578b1d2eff 100644
--- a/lib/ethdev/rte_fl
[PATCH v4 3/7] net/hns3: support setting and querying RSS hash function
From: Huisong Li
Support setting and querying RSS hash function by ethdev ops.
Signed-off-by: Huisong Li
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_rss.c | 47 +
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c
index 6126512bd780..c8346d43d15c 100644
--- a/drivers/net/hns3/hns3_rss.c
+++ b/drivers/net/hns3/hns3_rss.c
@@ -646,14 +646,14 @@ hns3_dev_rss_hash_update(struct rte_eth_dev *dev,
if (ret)
goto set_tuple_fail;
- if (key) {
- ret = hns3_rss_set_algo_key(hw, hw->rss_info.hash_algo,
- key, hw->rss_key_size);
- if (ret)
- goto set_algo_key_fail;
- /* Update the shadow RSS key with user specified */
+ ret = hns3_update_rss_algo_key(hw, rss_conf->func, key, key_len);
+ if (ret != 0)
+ goto set_algo_key_fail;
+
+ if (rss_conf->func != RTE_ETH_HASH_FUNCTION_DEFAULT)
+ hw->rss_info.hash_algo = hns3_hash_func_map[rss_conf->func];
+ if (key != NULL)
memcpy(hw->rss_info.key, key, hw->rss_key_size);
- }
hw->rss_info.rss_hf = rss_hf;
rte_spinlock_unlock(&hw->lock);
@@ -769,7 +769,13 @@ int
hns3_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf)
{
+ const uint8_t hash_func_map[] = {
+ [HNS3_RSS_HASH_ALGO_TOEPLITZ] = RTE_ETH_HASH_FUNCTION_TOEPLITZ,
+ [HNS3_RSS_HASH_ALGO_SIMPLE] = RTE_ETH_HASH_FUNCTION_SIMPLE_XOR,
+ [HNS3_RSS_HASH_ALGO_SYMMETRIC_TOEP] =
RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ };
struct hns3_adapter *hns = dev->data->dev_private;
+ uint8_t rss_key[HNS3_RSS_KEY_SIZE_MAX] = {0};
struct hns3_hw *hw = &hns->hw;
uint8_t hash_algo;
int ret;
@@ -777,26 +783,27 @@ hns3_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
rte_spinlock_lock(&hw->lock);
ret = hns3_rss_hash_get_rss_hf(hw, &rss_conf->rss_hf);
if (ret != 0) {
+ rte_spinlock_unlock(&hw->lock);
hns3_err(hw, "obtain hash tuples failed, ret = %d", ret);
- goto out;
+ return ret;
+ }
+
+ ret = hns3_rss_get_algo_key(hw, &hash_algo, rss_key, hw->rss_key_size);
+ if (ret != 0) {
+ rte_spinlock_unlock(&hw->lock);
+ hns3_err(hw, "obtain hash algo and key failed, ret = %d", ret);
+ return ret;
}
+ rte_spinlock_unlock(&hw->lock);
- /* Get the RSS Key required by the user */
+ /* Get the RSS Key if user required. */
if (rss_conf->rss_key && rss_conf->rss_key_len >= hw->rss_key_size) {
- ret = hns3_rss_get_algo_key(hw, &hash_algo, rss_conf->rss_key,
- hw->rss_key_size);
- if (ret != 0) {
- hns3_err(hw, "obtain hash algo and key failed, ret =
%d",
-ret);
- goto out;
- }
+ memcpy(rss_conf->rss_key, rss_key, hw->rss_key_size);
rss_conf->rss_key_len = hw->rss_key_size;
}
+ rss_conf->func = hash_func_map[hash_algo];
-out:
- rte_spinlock_unlock(&hw->lock);
-
- return ret;
+ return 0;
}
/*
--
2.30.0
[PATCH v4 4/7] app/proc-info: fix never show RSS info
Command show-port should show RSS info (rss_key, len and rss_hf),
However, the information is shown only when rss_conf.rss_key is not
NULL. Since no memory is allocated for rss_conf.rss_key, rss_key
will always be NULL and the rss_info will never show. This patch
allocates memory for rss_conf.rss_key and makes it possible to show
RSS info.
Fixes: 8a37f37fc243 ("app/procinfo: add --show-port")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
app/proc-info/main.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 88cee0ca487b..95dd4514b3c9 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -152,6 +152,8 @@ struct desc_param {
static struct desc_param rx_desc_param;
static struct desc_param tx_desc_param;
+#define RSS_HASH_KEY_SIZE 64
+
/* display usage */
static void
proc_info_usage(const char *prgname)
@@ -1013,6 +1015,7 @@ show_port(void)
struct rte_eth_fc_conf fc_conf;
struct rte_ether_addr mac;
struct rte_eth_dev_owner owner;
+ uint8_t rss_key[RSS_HASH_KEY_SIZE];
/* Skip if port is not in mask */
if ((enabled_port_mask & (1ul << i)) == 0)
@@ -1171,17 +1174,17 @@ show_port(void)
printf("\n");
}
+ rss_conf.rss_key = rss_key;
+ rss_conf.rss_key_len = dev_info.hash_key_size;
ret = rte_eth_dev_rss_hash_conf_get(i, &rss_conf);
if (ret == 0) {
- if (rss_conf.rss_key) {
- printf(" - RSS\n");
- printf("\t -- RSS len %u key (hex):",
- rss_conf.rss_key_len);
- for (k = 0; k < rss_conf.rss_key_len; k++)
- printf(" %x", rss_conf.rss_key[k]);
- printf("\t -- hf 0x%"PRIx64"\n",
- rss_conf.rss_hf);
- }
+ printf(" - RSS\n");
+ printf("\t -- RSS len %u key (hex):",
+ rss_conf.rss_key_len);
+ for (k = 0; k < rss_conf.rss_key_len; k++)
+ printf(" %x", rss_conf.rss_key[k]);
+ printf("\t -- hf 0x%"PRIx64"\n",
+ rss_conf.rss_hf);
}
#ifdef RTE_LIB_SECURITY
--
2.30.0
[PATCH v4 5/7] app/proc-info: adjust the display format of RSS info
This patch splits the length and value of RSS key into two parts,
removes spaces between RSS keys, and adds line breaks between RSS
key and RSS hf.
Before the adjustment, RSS info is shown as:
- RSS
-- RSS len 40 key (hex): 6d 5a 56 da 25 5b e c2 41 67 \
25 3d 43 a3 8f b0 d0 ca 2b cb ae 7b 30 b4 77 cb 2d \
a3 80 30 f2 c 6a 42 b7 3b be ac 1 fa -- hf 0x0
and after:
- RSS info
-- key len : 40
-- key (hex) : 6d5a56da255b0ec24167253d43a38fb0d0c \
a2bcbae7b30b477cb2da38030f20c6a42b73bbeac01fa
-- hf : 0x0
Fixes: 8a37f37fc243 ("app/procinfo: add --show-port")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
app/proc-info/main.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 95dd4514b3c9..735cfd5249ab 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -1178,12 +1178,13 @@ show_port(void)
rss_conf.rss_key_len = dev_info.hash_key_size;
ret = rte_eth_dev_rss_hash_conf_get(i, &rss_conf);
if (ret == 0) {
- printf(" - RSS\n");
- printf("\t -- RSS len %u key (hex):",
+ printf(" - RSS info\n");
+ printf("\t -- key len : %u\n",
rss_conf.rss_key_len);
+ printf("\t -- key (hex) : ");
for (k = 0; k < rss_conf.rss_key_len; k++)
- printf(" %x", rss_conf.rss_key[k]);
- printf("\t -- hf 0x%"PRIx64"\n",
+ printf("%02x", rss_conf.rss_key[k]);
+ printf("\n\t -- hf : 0x%"PRIx64"\n",
rss_conf.rss_hf);
}
--
2.30.0
[PATCH v4 7/7] app/testpmd: add RSS hash algorithms display
Add the command "show port X rss-hash func" to display the RSS hash
algorithms of port X. An example is shown:
testpmd> show port 0 rss-hash func
RSS algorithms:
toeplitz
Signed-off-by: Jie Hai
---
app/test-pmd/cmdline.c | 29 -
app/test-pmd/config.c | 36 +---
app/test-pmd/testpmd.h | 2 +-
3 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0d0723f6596e..91bb5ac3c091 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -174,8 +174,8 @@ static void cmd_help_long_parsed(void *parsed_result,
" by masks on port X. size is used to indicate the"
" hardware supported reta size\n\n"
- "show port (port_id) rss-hash [key]\n"
- "Display the RSS hash functions and RSS hash key of
port\n\n"
+ "show port (port_id) rss-hash [key | func]\n"
+ "Display the RSS hash functions, RSS hash key and
RSS hash algorithms of port\n\n"
"clear port (info|stats|xstats|fdir) (port_id|all)\n"
"Clear information for port_id, or all.\n\n"
@@ -3017,15 +3017,17 @@ struct cmd_showport_rss_hash {
cmdline_fixed_string_t rss_hash;
cmdline_fixed_string_t rss_type;
cmdline_fixed_string_t key; /* optional argument */
+ cmdline_fixed_string_t func; /* optional argument */
};
static void cmd_showport_rss_hash_parsed(void *parsed_result,
__rte_unused struct cmdline *cl,
- void *show_rss_key)
+ __rte_unused void *data)
{
struct cmd_showport_rss_hash *res = parsed_result;
- port_rss_hash_conf_show(res->port_id, show_rss_key != NULL);
+ port_rss_hash_conf_show(res->port_id,
+ !strcmp(res->key, "key"), !strcmp(res->func, "func"));
}
static cmdline_parse_token_string_t cmd_showport_rss_hash_show =
@@ -3040,6 +3042,8 @@ static cmdline_parse_token_string_t
cmd_showport_rss_hash_rss_hash =
"rss-hash");
static cmdline_parse_token_string_t cmd_showport_rss_hash_rss_key =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, key, "key");
+static cmdline_parse_token_string_t cmd_showport_rss_hash_rss_func =
+ TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, func, "func");
static cmdline_parse_inst_t cmd_showport_rss_hash = {
.f = cmd_showport_rss_hash_parsed,
@@ -3056,7 +3060,7 @@ static cmdline_parse_inst_t cmd_showport_rss_hash = {
static cmdline_parse_inst_t cmd_showport_rss_hash_key = {
.f = cmd_showport_rss_hash_parsed,
- .data = (void *)1,
+ .data = NULL,
.help_str = "show port rss-hash key",
.tokens = {
(void *)&cmd_showport_rss_hash_show,
@@ -3068,6 +3072,20 @@ static cmdline_parse_inst_t cmd_showport_rss_hash_key = {
},
};
+static cmdline_parse_inst_t cmd_showport_rss_hash_func = {
+ .f = cmd_showport_rss_hash_parsed,
+ .data = NULL,
+ .help_str = "show port rss-hash func",
+ .tokens = {
+ (void *)&cmd_showport_rss_hash_show,
+ (void *)&cmd_showport_rss_hash_port,
+ (void *)&cmd_showport_rss_hash_port_id,
+ (void *)&cmd_showport_rss_hash_rss_hash,
+ (void *)&cmd_showport_rss_hash_rss_func,
+ NULL,
+ },
+};
+
/* *** Configure DCB *** */
struct cmd_config_dcb {
cmdline_fixed_string_t port;
@@ -12905,6 +12923,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_tunnel_udp_config,
(cmdline_parse_inst_t *)&cmd_showport_rss_hash,
(cmdline_parse_inst_t *)&cmd_showport_rss_hash_key,
+ (cmdline_parse_inst_t *)&cmd_showport_rss_hash_func,
(cmdline_parse_inst_t *)&cmd_config_rss_hash_key,
(cmdline_parse_inst_t *)&cmd_cleanup_txq_mbufs,
(cmdline_parse_inst_t *)&cmd_dump,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 11f3a2204839..1af55185d2b2 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1485,6 +1485,14 @@ rss_types_display(uint64_t rss_types, uint16_t
char_num_per_line)
printf("\n");
}
+static const char * const rss_hash_algos[] = {
+ [RTE_ETH_HASH_FUNCTION_SIMPLE_XOR] = "simple_xor",
+ [RTE_ETH_HASH_FUNCTION_TOEPLITZ] = "toeplitz",
+ [RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ] = "symmetric_toeplitz",
+ [RTE_ETH_HASH_FUNCTION_DEFAULT] = "default",
+ [RTE_ETH_HASH_FUNCTION_MAX] = "Unknown function"
+};
+
static void
rss_config_display(struct rte_flow_action_rss *rss_conf)
{
@@ -1503,24 +1511,7 @@ rss_config_display(struct rte_flow_action_rss *rss_conf)
printf(" %d", rss_conf->queue[i]);
printf("\n");
- printf
[PATCH v4 6/7] app/proc-info: support querying RSS hash algorithm
Display RSS hash algorithm with command show-port as below.
- RSS info
-- hash algorithm : toeplitz
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
app/proc-info/main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 735cfd5249ab..3da63a4821f2 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -153,6 +153,13 @@ static struct desc_param rx_desc_param;
static struct desc_param tx_desc_param;
#define RSS_HASH_KEY_SIZE 64
+static const char * const rss_hash_algos[] = {
+ [RTE_ETH_HASH_FUNCTION_SIMPLE_XOR] = "simple_xor",
+ [RTE_ETH_HASH_FUNCTION_TOEPLITZ] = "toeplitz",
+ [RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ] = "symmetric_toeplitz",
+ [RTE_ETH_HASH_FUNCTION_DEFAULT] = "default",
+ [RTE_ETH_HASH_FUNCTION_MAX] = "unknown"
+};
/* display usage */
static void
@@ -1186,6 +1193,8 @@ show_port(void)
printf("%02x", rss_conf.rss_key[k]);
printf("\n\t -- hf : 0x%"PRIx64"\n",
rss_conf.rss_hf);
+ printf("\t -- hash algorithm : %s\n",
+ rss_hash_algos[rss_conf.func]);
}
#ifdef RTE_LIB_SECURITY
--
2.30.0
Re: [PATCH v2 1/5] ethdev: support setting and querying RSS algorithm
Hi, Thomas
Thanks for your review.
On 2023/9/4 15:45, Thomas Monjalon wrote:
04/09/2023 09:10, Jie Hai:
On 2023/8/30 19:46, Thomas Monjalon wrote:
26/08/2023 09:46, Jie Hai:
>> + * The *func* field of the *rss_conf* structure indicates the hash
algorithm
+ * applied by the RSS hashing. Passing RTE_ETH_HASH_FUNCTION_DEFAULT allows
+ * the PMD to use its best-effort algorithm rather than a specific one.
*/
I don't like commenting a field on top of the structure.
By the way, the first sentence does not look helpful.
RTE_ETH_HASH_FUNCTION_DEFAULT may be explained in the enum.
Other fields above the structure 'rte_eth_rss_conf' have comments.
If the new fields 'func' do not have comments, it may be misleading.
Unless all the comments above are removed. I'm not sure whether to
delete them or not.
You should explain RTE_ETH_HASH_FUNCTION_DEFAULT in its enum.
The rest of the explanation can be on the struct field.
I'm OK to have another patch moving old explanations from the struct
to the fields.
Fixed in V4, please check it.
struct rte_eth_rss_conf {
uint8_t *rss_key;/**< If not NULL, 40-byte hash key. */
uint8_t rss_key_len; /**< hash key length in bytes. */
uint64_t rss_hf; /**< Hash functions to apply - see below. */
+ enum rte_eth_hash_function func;/**< Hash algorithm to apply. */
You can drop "to apply" words.
Fixed in V3.
How the algorithms support combinations in rss_hf?
The rss_hf defines the input of the RSS hash algorithms.
For example, rss_hf = RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_IPV4,
these two kinds of packets can be dispatched to different queues
according to their tuple field value.
For ipv4-tcp packets, src-ip, dst-ip, src-port, dst-port are used as
parameters of RSS hash algorithms to compute hash value.
For ipv4 packets src-ip, dst-ip are used.
If rss_hf = RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_L4_SRC_ONLY, for
ipv4-tcp packets, src-port is used as parameters of RSS hash algorithms
to compute hash value.
I know what is rss_hf.
My question is about the algorithms.
Do they all support any combination in rss_hf?
I don't know about all vendors' hardware implementations,
so here's just my simple opinion.
Theoretically, I think that all algorithms should support all
combinations in rss_hf, The reasons are as follows.
1. The rss_hf and algorithms are independent. For different algorithms
and the same packets and hash key, the input parameters for different
algorithms should be the same, which depends on implemetation of hardware.
2. As long as hardware and driver support, all packet types defined by
rss_hf could generate the the input parameters for the algorithm to compute.
Thanks,
Jie Hai
.
Re: Troubleshooting DPDK in Intel Ethernet NIC
Hi, thanks for the quick response and the feedback. *> Afaics, this nic is not supported by DPDK drivers.* Indeed there is nothing about "15fb" (the PCI ID of my NIC) in the output of ./usertools/dpdk-pmdinfo.py build/app/dpdk-testpmd , so I guess it is not supported. On the other hand, I do see that the* I219* family of my NIC (I219-LM) is present in the list https://core.dpdk.org/supported/nics/intel/ under e1000e category. Is this a contradiction or am I missing something? Regards On Fri, Sep 8, 2023 at 9:11 AM David Marchand wrote: > Hello, > > On Fri, Sep 8, 2023 at 8:42 AM Antón Rey Villaverde > wrote: > > > > Hi, > > I have a problem while trying to manage my physical Ethernet interface > from DPDK (latest version compiled from source). > > I have a: > > NIC: :00:1f.6 Ethernet controller: Intel Corporation Ethernet > Connection (13) I219-LM (rev 20) > > > > which belongs to the list of supported NICs in DPDK. > > > > Also, I have bound my NICto vfio-pci, not the kernel: > > > > dpdk-23.07$ usertools/dpdk-devbind.py --status > > Network devices using DPDK-compatible driver > :00:1f.6 'Ethernet > Connection (13) I219-LM 15fb' drv=vfio-pci unused=e1000e > > > > I also enabled hugepages (2G). > > > > when I enter "sudo build/app/dpdk-testpmd -c7 -- -i" I get: > > EAL: Detected CPU lcores: 8 > > EAL: Detected NUMA nodes: 1 > > EAL: Detected static linkage of DPDK > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > EAL: Selected IOVA mode 'VA' > > EAL: VFIO support initialized > > TELEMETRY: No legacy callbacks, legacy socket not created > > testpmd: No probed ethernet devices > > Interactive-mode selected > > testpmd: create a new mbuf pool : n=163456, size=2176, > socket=0 > > testpmd: preferred mempool ops selected: ring_mp_mc > > Done > > testpmd> > > > > When I enter "show port info all" in the testpmd CLI I get nothing (no > ports). > > > > When I start testpmd with "-a :00:1f.6" (the address of the ethernet > NIC I want to manage from DPDK), The same happens (no ports). > > Afaics, this nic is not supported by DPDK drivers. > You will have to find some other nic, or run on another server with > supported nics. > Some details below. > > > For a statically linked DPDK application (which is the default for > testpmd), you can check with dpdk-pmd-info.py which PCI devices are > supported. > Example: > $ ./usertools/dpdk-pmdinfo.py build/app/dpdk-testpmd | grep -i 15fb > > > > > > If I try to start testpmd with "-d build/drivers/librte_net_e1000.so" > (the shared library of the driver of that device), I get a crash: > > > > dpdk-23.07$ sudo build/app/dpdk-testpmd -c7 -a :00:1f.6 -d > build/drivers/librte_net_e1000.so -- -i > > EAL: Detected CPU lcores: 8 > > EAL: Detected NUMA nodes: 1 > > EAL: Detected static linkage of DPDK > > Your testpmd binary has been statically linked (as I said above, this > is the default) and you can see the log message confirming it. > > > > EAL: UIO_RESOURCE_LIST tailq is already registered PANIC in > tailqinitfn_rte_uio_tailq(): Cannot initialize tailq: UIO_RESOURCE_LIST > > 0: build/app/dpdk-testpmd (rte_dump_stack+0x32) [55be1839afe2] > > 1: build/app/dpdk-testpmd (__rte_panic+0xf1) [55be18369e68] > > 2: /home/anton/tdr/dpdk-23.07/build/drivers/librte_bus_pci.so.23 > (7f52153f6000+0x5d86) [7f52153fbd86] > > 3: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x11b9a) [7f5215fa1b9a] > > 4: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x11ca1) [7f5215fa1ca1] > > 5: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0xe5) > [7f5215970985] > > 6: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x160cf) [7f5215fa60cf] > > 7: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x88) > [7f5215970928] > > 8: /lib64/ld-linux-x86-64.so.2 (7f5215f9+0x1560a) [7f5215fa560a] > > 9: /lib/x86_64-linux-gnu/libdl.so.2 (7f5215e15000+0x134c) [7f5215e1634c] > > 10: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x88) > [7f5215970928] > > 11: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x33) [7f52159709f3] > > 12: /lib/x86_64-linux-gnu/libdl.so.2 (7f5215e15000+0x1b59) [7f5215e16b59] > > 13: /lib/x86_64-linux-gnu/libdl.so.2 (dlopen+0x4a) [7f5215e163da] > > 14: build/app/dpdk-testpmd (55be17b79000+0x8013ee) [55be1837a3ee] > > 15: build/app/dpdk-testpmd (eal_plugins_init+0x14f) [55be1837a6d8] > > 16: build/app/dpdk-testpmd (rte_eal_init+0x1af) [55be1839ec21] > > 17: build/app/dpdk-testpmd (main+0xde) [55be17da108b] > > 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) > [7f5215834083] > > 19: build/app/dpdk-testpmd (_start+0x2e) [55be17cef1fe] > > Aborted > > This is not a crash, EAL willingly aborts because initialising UIO > shared tailq has been requested twice and this is not something > supported. > This happened as you requested to load a driver that is embedded in > the testpmd binary and has already been initialised. > > > -- > David Marchand > >
Re: Troubleshooting DPDK in Intel Ethernet NIC
On Fri, Sep 8, 2023 at 11:05 AM Antón Rey Villaverde
wrote:
> > Afaics, this nic is not supported by DPDK drivers.
>
> Indeed there is nothing about "15fb" (the PCI ID of my NIC) in the output of
> ./usertools/dpdk-pmdinfo.py build/app/dpdk-testpmd , so I guess it is not
> supported.
>
> On the other hand, I do see that the I219 family of my NIC (I219-LM) is
> present in the list https://core.dpdk.org/supported/nics/intel/ under e1000e
> category.
>
> Is this a contradiction or am I missing something?
I reached the point where I can't help :-).
Some I219 nics support has been added ealier this year (commit
a33e1a5bcd3f ("net/e1000: support more I219 devices")).
Maybe adding support for your nic is a simple matter, but passing the
ball to Intel maintainers who are the right people to answer.
--
David Marchand
[PATCH 0/3] net/mlx5: extend send to kernel action support
The send to kernel action was supported in NIC and FDB tables, Currently[1], the send to kernel action is created in NIC RX only. With some TC rules (example: roce packets, redirects into rep ports) and DPDK RTE rules for the rest of the traffic. Then it needs the specific rule to re-route the packets into the kernel through the FDB table. This patchset adds the FDB and NIC-TX tables support for sending to the kernel action, also updates the documentation. [1] https://patchwork.dpdk.org/project/dpdk/list/?series=25318 Jiawei Wang (3): net/mlx5: extend send to kernel action support net/mlx5: extend hws send to kernel action support doc: adds the description for send to kernel doc/guides/nics/mlx5.rst | 7 + doc/guides/prog_guide/rte_flow.rst | 9 ++ drivers/net/mlx5/linux/mlx5_os.c | 25 ++--- drivers/net/mlx5/mlx5.h| 6 ++-- drivers/net/mlx5/mlx5_flow.h | 1 + drivers/net/mlx5/mlx5_flow_dv.c| 17 +++ drivers/net/mlx5/mlx5_flow_hw.c| 45 +- lib/ethdev/rte_flow.h | 1 - 8 files changed, 79 insertions(+), 32 deletions(-) -- 2.18.1
[PATCH 1/3] net/mlx5: extend send to kernel action support
The send to kernel action was supported in NIC and FDB tables,
Currently, the send to kernel action is created in NIC RX only.
With some TC rules (example: roce packets, redirects into rep ports)
and DPDK RTE rules for the rest of the traffic. Then it needs the
specific rule to re-route the packets into the kernel through the FDB
table.
This patch adds the FDB and NIC-TX tables support for sending to the kernel
action.
Signed-off-by: Jiawei Wang
---
drivers/net/mlx5/linux/mlx5_os.c | 25 +++--
drivers/net/mlx5/mlx5.h | 4 +++-
drivers/net/mlx5/mlx5_flow.h | 1 +
drivers/net/mlx5/mlx5_flow_dv.c | 17 +++--
4 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index d8f1adfe3d..38572eb652 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -675,6 +675,9 @@ void
mlx5_os_free_shared_dr(struct mlx5_priv *priv)
{
struct mlx5_dev_ctx_shared *sh = priv->sh;
+#ifdef HAVE_MLX5DV_DR
+ int i;
+#endif
MLX5_ASSERT(sh && sh->refcnt);
if (sh->refcnt > 1)
@@ -703,18 +706,20 @@ mlx5_os_free_shared_dr(struct mlx5_priv *priv)
mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
sh->pop_vlan_action = NULL;
}
- if (sh->send_to_kernel_action.action) {
- void *action = sh->send_to_kernel_action.action;
+ for (i = 0; i < MLX5DR_TABLE_TYPE_MAX; i++) {
+ if (sh->send_to_kernel_action[i].action) {
+ void *action = sh->send_to_kernel_action[i].action;
- mlx5_glue->destroy_flow_action(action);
- sh->send_to_kernel_action.action = NULL;
- }
- if (sh->send_to_kernel_action.tbl) {
- struct mlx5_flow_tbl_resource *tbl =
- sh->send_to_kernel_action.tbl;
+ mlx5_glue->destroy_flow_action(action);
+ sh->send_to_kernel_action[i].action = NULL;
+ }
+ if (sh->send_to_kernel_action[i].tbl) {
+ struct mlx5_flow_tbl_resource *tbl =
+ sh->send_to_kernel_action[i].tbl;
- flow_dv_tbl_resource_release(sh, tbl);
- sh->send_to_kernel_action.tbl = NULL;
+ flow_dv_tbl_resource_release(sh, tbl);
+ sh->send_to_kernel_action[i].tbl = NULL;
+ }
}
#endif /* HAVE_MLX5DV_DR */
if (sh->default_miss_action)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 3785103308..6960a07d40 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1432,7 +1432,9 @@ struct mlx5_dev_ctx_shared {
/* Direct Rules tables for FDB, NIC TX+RX */
void *dr_drop_action; /* Pointer to DR drop action, any domain. */
void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
- struct mlx5_send_to_kernel_action send_to_kernel_action;
+#if defined(HAVE_IBV_FLOW_DV_SUPPORT) || !defined(HAVE_INFINIBAND_VERBS_H)
+ struct mlx5_send_to_kernel_action
send_to_kernel_action[MLX5DR_TABLE_TYPE_MAX];
+#endif
struct mlx5_hlist *encaps_decaps; /* Encap/decap action hash list. */
struct mlx5_hlist *modify_cmds;
struct mlx5_hlist *tag_table;
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 3a97975d69..6beac3902c 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -331,6 +331,7 @@ enum mlx5_feature_name {
#define MLX5_FLOW_FATE_ESWITCH_ACTIONS \
(MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_PORT_ID | \
+MLX5_FLOW_ACTION_SEND_TO_KERNEL | \
MLX5_FLOW_ACTION_JUMP | MLX5_FLOW_ACTION_METER_WITH_TERMINATED_POLICY)
#define MLX5_FLOW_MODIFY_HDR_ACTIONS (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index a8dd9920e6..fe0814a2eb 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -12724,17 +12724,22 @@ flow_dv_translate_action_sample(struct rte_eth_dev
*dev,
static void *
flow_dv_translate_action_send_to_kernel(struct rte_eth_dev *dev,
+ const struct rte_flow_attr *attr,
struct rte_flow_error *error)
{
struct mlx5_flow_tbl_resource *tbl;
struct mlx5_dev_ctx_shared *sh;
uint32_t priority;
void *action;
+ int ft_type;
int ret;
sh = MLX5_SH(dev);
- if (sh->send_to_kernel_action.action)
- return sh->send_to_kernel_action.action;
+ ft_type = (attr->ingress) ? MLX5DR_TABLE_TYPE_NIC_RX :
+ ((attr->transfer) ? MLX5DR_TABLE_TYPE_FDB :
+ MLX5DR_TABLE_TYPE_NIC_TX);
+ if (sh->send_to_kernel_action[ft_type].action)
+ return sh->
[PATCH 2/3] net/mlx5: extend hws send to kernel action support
The hws send to kernel action was supported in NIC and FDB tables,
Currently, the send to kernel action is created in NIC RX only.
This patch adds the FDB and NIC-TX tables support for sending to the kernel
action for HWS.
Signed-off-by: Jiawei Wang
---
drivers/net/mlx5/mlx5.h | 2 +-
drivers/net/mlx5/mlx5_flow_hw.c | 45 +++--
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 6960a07d40..d49b81a360 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -1858,7 +1858,7 @@ struct mlx5_priv {
/* HW steering global tag action. */
struct mlx5dr_action *hw_tag[2];
/* HW steering global send to kernel action. */
- struct mlx5dr_action *hw_send_to_kernel;
+ struct mlx5dr_action *hw_send_to_kernel[MLX5DR_TABLE_TYPE_MAX];
/* HW steering create ongoing rte flow table list header. */
LIST_HEAD(flow_hw_tbl_ongo, rte_flow_template_table) flow_hw_tbl_ongo;
struct mlx5_indexed_pool *acts_ipool; /* Action data indexed pool. */
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 92a5c92669..84d869a686 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -1439,6 +1439,7 @@ __flow_hw_actions_translate(struct rte_eth_dev *dev,
uint32_t ct_idx;
int err;
uint32_t target_grp = 0;
+ int table_type;
flow_hw_modify_field_init(&mhdr, at);
if (attr->transfer)
@@ -1635,7 +1636,10 @@ __flow_hw_actions_translate(struct rte_eth_dev *dev,
"Send to kernel action on root
table is not supported in HW steering mode");
}
action_pos = at->actions_off[actions - at->actions];
- acts->rule_acts[action_pos].action =
priv->hw_send_to_kernel;
+ table_type = attr->ingress ? MLX5DR_TABLE_TYPE_NIC_RX :
+((attr->egress) ? MLX5DR_TABLE_TYPE_NIC_TX
:
+MLX5DR_TABLE_TYPE_FDB);
+ acts->rule_acts[action_pos].action =
priv->hw_send_to_kernel[table_type];
break;
case RTE_FLOW_ACTION_TYPE_MODIFY_FIELD:
err = flow_hw_modify_field_compile(dev, attr,
action_start,
@@ -4345,8 +4349,11 @@ mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
const struct rte_flow_action_count *count_mask = NULL;
bool fixed_cnt = false;
uint64_t action_flags = 0;
- uint16_t i;
bool actions_end = false;
+#ifdef HAVE_MLX5DV_DR_ACTION_CREATE_DEST_ROOT_TABLE
+ int table_type;
+#endif
+ uint16_t i;
int ret;
/* FDB actions are only valid to proxy port. */
@@ -4397,7 +4404,10 @@ mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
RTE_FLOW_ERROR_TYPE_ACTION,
action,
"action not supported
in guest port");
- if (!priv->hw_send_to_kernel)
+ table_type = attr->ingress ? MLX5DR_TABLE_TYPE_NIC_RX :
+((attr->egress) ? MLX5DR_TABLE_TYPE_NIC_TX
:
+MLX5DR_TABLE_TYPE_FDB);
+ if (!priv->hw_send_to_kernel[table_type])
return rte_flow_error_set(error, ENOTSUP,
RTE_FLOW_ERROR_TYPE_ACTION,
action,
@@ -5955,13 +5965,19 @@ static void
flow_hw_create_send_to_kernel_actions(struct mlx5_priv *priv __rte_unused)
{
#ifdef HAVE_MLX5DV_DR_ACTION_CREATE_DEST_ROOT_TABLE
- priv->hw_send_to_kernel =
- mlx5dr_action_create_dest_root(priv->dr_ctx,
- MLX5_HW_LOWEST_PRIO_ROOT,
-
MLX5DR_ACTION_FLAG_HWS_RX);
- if (!priv->hw_send_to_kernel) {
- DRV_LOG(WARNING, "Unable to create HWS send to kernel action");
- return;
+ int action_flag;
+ int i;
+
+ for (i = MLX5DR_TABLE_TYPE_NIC_RX; i < MLX5DR_TABLE_TYPE_MAX; i++) {
+ action_flag = mlx5_hw_act_flag[1][i];
+ priv->hw_send_to_kernel[i] =
+ mlx5dr_action_create_dest_root(priv->dr_ctx,
+
MLX5_HW_LOWEST_PRIO_ROOT,
+ action_flag);
+ if (!priv->hw_send_to_kernel[i]) {
+ DRV_LOG(WARNING, "Unable to create HWS send to kernel
action");
+ return;
+ }
[PATCH 3/3] doc: adds the description for send to kernel
This patch adds the description for send to kernel action support.
Signed-off-by: Jiawei Wang
Acked-by: Ori Kam
---
doc/guides/nics/mlx5.rst | 7 +++
doc/guides/prog_guide/rte_flow.rst | 9 +
lib/ethdev/rte_flow.h | 1 -
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index eac67a7864..7bee57d9dd 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -165,6 +165,7 @@ Features
- Sub-Function.
- Matching on represented port.
- Matching on aggregated affinity.
+- Send to kernel.
Limitations
@@ -720,6 +721,12 @@ Limitations
The flow engine of a process cannot move from active to standby mode
if preceding active application rules are still present and vice versa.
+- Send to kernel action (``RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL``):
+
+ - Supports on non-root table.
+ - Supports on isolated mode.
+ - In HW steering (``dv_flow_en`` = 2):
+- not supported on guest port.
Statistics
--
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 5bc998a433..f8c130bc8b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3490,6 +3490,15 @@ The ``quota`` value is reduced according to ``mode``
setting.
| ``RTE_FLOW_QUOTA_MODE_L3`` | Count packet bytes starting from L3 |
+--++
+Action: ``SEND_TO_KERNEL``
+^^
+
+Send packets to the kernel, without going to userspace at all.
+
+The packets will be received by the kernel driver sharing the
+same device as the DPDK port on which this action is configured.
+
+
Negative types
~~
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 2ebb76dbc0..23addb4382 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2931,7 +2931,6 @@ enum rte_flow_action_type {
* The packets will be received by the kernel driver sharing
* the same device as the DPDK port on which this action is configured.
* This action mostly suits bifurcated driver model.
-* This is an ingress non-transfer action only.
*
* No associated configuration structure.
*/
--
2.18.1
Re: [PATCH v2 1/5] ethdev: support setting and querying RSS algorithm
Hi, Stephen Hemminger On 2023/9/6 23:10, Stephen Hemminger wrote: On Sat, 26 Aug 2023 15:46:03 +0800 Jie Hai wrote: Currently, rte_eth_rss_conf supports configuring and querying rss hash functions, rss key and it's length, but not rss hash algorithm. The structure ``rte_eth_rss_conf`` is extended by adding a new field "func". This represents the RSS algorithms to apply. The following API is affected: - rte_eth_dev_configure - rte_eth_dev_rss_hash_update - rte_eth_dev_rss_hash_conf_get If the value of "func" used for configuration is a gibberish value, report the error and return. Do the same for rte_eth_dev_rss_hash_update and rte_eth_dev_configure. To check whether the drivers report the "func" field, it is set to default value before querying. Signed-off-by: Jie Hai Signed-off-by: Dongdong Liu This is unannounced API/ABI change. Thanks for pointing that. I'm sorry I didn't pay attention to this before. What should I do with this set of patches? Is it feasible to send annouce now? . Thanks, Jie Hai
RE: [PATCH 1/3] net/mlx5: extend send to kernel action support
> -Original Message-
> From: Jiawei(Jonny) Wang
> Sent: Friday, September 8, 2023 5:21 PM
> To: Suanming Mou ; Ori Kam ;
> NBU-Contact-Thomas Monjalon (EXTERNAL)
> Cc: dev@dpdk.org; Raslan Darawsheh
> Subject: [PATCH 1/3] net/mlx5: extend send to kernel action support
>
> The send to kernel action was supported in NIC and FDB tables, Currently, the
> send to kernel action is created in NIC RX only.
>
> With some TC rules (example: roce packets, redirects into rep ports) and DPDK
> RTE rules for the rest of the traffic. Then it needs the specific rule to
> re-route the
> packets into the kernel through the FDB table.
>
> This patch adds the FDB and NIC-TX tables support for sending to the kernel
> action.
>
> Signed-off-by: Jiawei Wang
Acked-by: Suanming Mou
> ---
> drivers/net/mlx5/linux/mlx5_os.c | 25 +++--
> drivers/net/mlx5/mlx5.h | 4 +++-
> drivers/net/mlx5/mlx5_flow.h | 1 +
> drivers/net/mlx5/mlx5_flow_dv.c | 17 +++--
> 4 files changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/mlx5/linux/mlx5_os.c
> b/drivers/net/mlx5/linux/mlx5_os.c
> index d8f1adfe3d..38572eb652 100644
> --- a/drivers/net/mlx5/linux/mlx5_os.c
> +++ b/drivers/net/mlx5/linux/mlx5_os.c
> @@ -675,6 +675,9 @@ void
> mlx5_os_free_shared_dr(struct mlx5_priv *priv) {
> struct mlx5_dev_ctx_shared *sh = priv->sh;
> +#ifdef HAVE_MLX5DV_DR
> + int i;
> +#endif
>
> MLX5_ASSERT(sh && sh->refcnt);
> if (sh->refcnt > 1)
> @@ -703,18 +706,20 @@ mlx5_os_free_shared_dr(struct mlx5_priv *priv)
> mlx5_glue->destroy_flow_action(sh->pop_vlan_action);
> sh->pop_vlan_action = NULL;
> }
> - if (sh->send_to_kernel_action.action) {
> - void *action = sh->send_to_kernel_action.action;
> + for (i = 0; i < MLX5DR_TABLE_TYPE_MAX; i++) {
> + if (sh->send_to_kernel_action[i].action) {
> + void *action = sh->send_to_kernel_action[i].action;
>
> - mlx5_glue->destroy_flow_action(action);
> - sh->send_to_kernel_action.action = NULL;
> - }
> - if (sh->send_to_kernel_action.tbl) {
> - struct mlx5_flow_tbl_resource *tbl =
> - sh->send_to_kernel_action.tbl;
> + mlx5_glue->destroy_flow_action(action);
> + sh->send_to_kernel_action[i].action = NULL;
> + }
> + if (sh->send_to_kernel_action[i].tbl) {
> + struct mlx5_flow_tbl_resource *tbl =
> + sh->send_to_kernel_action[i].tbl;
>
> - flow_dv_tbl_resource_release(sh, tbl);
> - sh->send_to_kernel_action.tbl = NULL;
> + flow_dv_tbl_resource_release(sh, tbl);
> + sh->send_to_kernel_action[i].tbl = NULL;
> + }
> }
> #endif /* HAVE_MLX5DV_DR */
> if (sh->default_miss_action)
> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> 3785103308..6960a07d40 100644
> --- a/drivers/net/mlx5/mlx5.h
> +++ b/drivers/net/mlx5/mlx5.h
> @@ -1432,7 +1432,9 @@ struct mlx5_dev_ctx_shared {
> /* Direct Rules tables for FDB, NIC TX+RX */
> void *dr_drop_action; /* Pointer to DR drop action, any domain. */
> void *pop_vlan_action; /* Pointer to DR pop VLAN action. */
> - struct mlx5_send_to_kernel_action send_to_kernel_action;
> +#if defined(HAVE_IBV_FLOW_DV_SUPPORT)
> || !defined(HAVE_INFINIBAND_VERBS_H)
> + struct mlx5_send_to_kernel_action
> +send_to_kernel_action[MLX5DR_TABLE_TYPE_MAX];
> +#endif
> struct mlx5_hlist *encaps_decaps; /* Encap/decap action hash list. */
> struct mlx5_hlist *modify_cmds;
> struct mlx5_hlist *tag_table;
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h index
> 3a97975d69..6beac3902c 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -331,6 +331,7 @@ enum mlx5_feature_name {
>
> #define MLX5_FLOW_FATE_ESWITCH_ACTIONS \
> (MLX5_FLOW_ACTION_DROP | MLX5_FLOW_ACTION_PORT_ID | \
> + MLX5_FLOW_ACTION_SEND_TO_KERNEL | \
>MLX5_FLOW_ACTION_JUMP |
> MLX5_FLOW_ACTION_METER_WITH_TERMINATED_POLICY)
>
> #define MLX5_FLOW_MODIFY_HDR_ACTIONS
> (MLX5_FLOW_ACTION_SET_IPV4_SRC | \ diff --git
> a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c index
> a8dd9920e6..fe0814a2eb 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -12724,17 +12724,22 @@ flow_dv_translate_action_sample(struct
> rte_eth_dev *dev,
>
> static void *
> flow_dv_translate_action_send_to_kernel(struct rte_eth_dev *dev,
> + const struct rte_flow_attr *attr,
> struct rte_flow_error *error)
> {
> struct mlx5_flow_tbl_resource *tbl;
> struct mlx5_dev_ctx_shared *sh;
> uint32_t priority;
> void
RE: [PATCH 2/3] net/mlx5: extend hws send to kernel action support
> -Original Message-
> From: Jiawei(Jonny) Wang
> Sent: Friday, September 8, 2023 5:21 PM
> To: Suanming Mou ; Ori Kam ;
> NBU-Contact-Thomas Monjalon (EXTERNAL)
> Cc: dev@dpdk.org; Raslan Darawsheh
> Subject: [PATCH 2/3] net/mlx5: extend hws send to kernel action support
>
> The hws send to kernel action was supported in NIC and FDB tables, Currently,
> the send to kernel action is created in NIC RX only.
>
> This patch adds the FDB and NIC-TX tables support for sending to the kernel
> action for HWS.
>
> Signed-off-by: Jiawei Wang
Acked-by: Suanming Mou
> ---
> drivers/net/mlx5/mlx5.h | 2 +-
> drivers/net/mlx5/mlx5_flow_hw.c | 45 +++--
> 2 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> 6960a07d40..d49b81a360 100644
> --- a/drivers/net/mlx5/mlx5.h
> +++ b/drivers/net/mlx5/mlx5.h
> @@ -1858,7 +1858,7 @@ struct mlx5_priv {
> /* HW steering global tag action. */
> struct mlx5dr_action *hw_tag[2];
> /* HW steering global send to kernel action. */
> - struct mlx5dr_action *hw_send_to_kernel;
> + struct mlx5dr_action *hw_send_to_kernel[MLX5DR_TABLE_TYPE_MAX];
> /* HW steering create ongoing rte flow table list header. */
> LIST_HEAD(flow_hw_tbl_ongo, rte_flow_template_table)
> flow_hw_tbl_ongo;
> struct mlx5_indexed_pool *acts_ipool; /* Action data indexed pool. */
> diff --git a/drivers/net/mlx5/mlx5_flow_hw.c
> b/drivers/net/mlx5/mlx5_flow_hw.c index 92a5c92669..84d869a686 100644
> --- a/drivers/net/mlx5/mlx5_flow_hw.c
> +++ b/drivers/net/mlx5/mlx5_flow_hw.c
> @@ -1439,6 +1439,7 @@ __flow_hw_actions_translate(struct rte_eth_dev
> *dev,
> uint32_t ct_idx;
> int err;
> uint32_t target_grp = 0;
> + int table_type;
>
> flow_hw_modify_field_init(&mhdr, at);
> if (attr->transfer)
> @@ -1635,7 +1636,10 @@ __flow_hw_actions_translate(struct rte_eth_dev
> *dev,
> "Send to kernel action on root
> table is not supported in HW steering mode");
> }
> action_pos = at->actions_off[actions - at->actions];
> - acts->rule_acts[action_pos].action = priv-
> >hw_send_to_kernel;
> + table_type = attr->ingress ?
> MLX5DR_TABLE_TYPE_NIC_RX :
> + ((attr->egress) ?
> MLX5DR_TABLE_TYPE_NIC_TX :
> + MLX5DR_TABLE_TYPE_FDB);
> + acts->rule_acts[action_pos].action =
> +priv->hw_send_to_kernel[table_type];
> break;
> case RTE_FLOW_ACTION_TYPE_MODIFY_FIELD:
> err = flow_hw_modify_field_compile(dev, attr,
> action_start, @@ -4345,8 +4349,11 @@ mlx5_flow_hw_actions_validate(struct
> rte_eth_dev *dev,
> const struct rte_flow_action_count *count_mask = NULL;
> bool fixed_cnt = false;
> uint64_t action_flags = 0;
> - uint16_t i;
> bool actions_end = false;
> +#ifdef HAVE_MLX5DV_DR_ACTION_CREATE_DEST_ROOT_TABLE
> + int table_type;
> +#endif
> + uint16_t i;
> int ret;
>
> /* FDB actions are only valid to proxy port. */ @@ -4397,7 +4404,10
> @@ mlx5_flow_hw_actions_validate(struct rte_eth_dev *dev,
>
> RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> "action not supported
> in guest port");
> - if (!priv->hw_send_to_kernel)
> + table_type = attr->ingress ?
> MLX5DR_TABLE_TYPE_NIC_RX :
> + ((attr->egress) ?
> MLX5DR_TABLE_TYPE_NIC_TX :
> + MLX5DR_TABLE_TYPE_FDB);
> + if (!priv->hw_send_to_kernel[table_type])
> return rte_flow_error_set(error, ENOTSUP,
>
> RTE_FLOW_ERROR_TYPE_ACTION,
> action,
> @@ -5955,13 +5965,19 @@ static void
> flow_hw_create_send_to_kernel_actions(struct mlx5_priv *priv __rte_unused)
> { #ifdef HAVE_MLX5DV_DR_ACTION_CREATE_DEST_ROOT_TABLE
> - priv->hw_send_to_kernel =
> - mlx5dr_action_create_dest_root(priv->dr_ctx,
> -
> MLX5_HW_LOWEST_PRIO_ROOT,
> -
> MLX5DR_ACTION_FLAG_HWS_RX);
> - if (!priv->hw_send_to_kernel) {
> - DRV_LOG(WARNING, "Unable to create HWS send to kernel
> action");
> - return;
> + int action_flag;
> + int i;
> +
> + for (i = MLX5DR_TABLE_TYPE_NIC_RX; i < MLX5DR_TABLE_TYPE_MAX;
> i++) {
> + action_flag = mlx5_hw_act_flag[1][i];
> + priv->hw_send_to_kernel[i] =
> + mlx5dr_action_create_dest_root(priv->dr_ctx,
> +
> MLX5_HW_LOWEST_PRIO_ROOT,
> + action_flag);
> + if (!priv->hw_send_to_k
[PATCH v3] common/idpf: refactor single queue Tx function
This patch replaces flex Tx descriptor with base Tx descriptor to align
with kernel driver practice.
Signed-off-by: Simei Su
---
v3:
* Change context TSO descriptor from base mode to flex mode.
v2:
* Refine commit title and commit log.
* Remove redundant definition.
* Modify base mode context TSO descriptor.
drivers/common/idpf/idpf_common_rxtx.c| 39 +--
drivers/common/idpf/idpf_common_rxtx.h| 2 +-
drivers/common/idpf/idpf_common_rxtx_avx512.c | 37 +-
drivers/net/idpf/idpf_rxtx.c | 2 +-
4 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/drivers/common/idpf/idpf_common_rxtx.c
b/drivers/common/idpf/idpf_common_rxtx.c
index fc87e3e243..e6d2486272 100644
--- a/drivers/common/idpf/idpf_common_rxtx.c
+++ b/drivers/common/idpf/idpf_common_rxtx.c
@@ -276,14 +276,14 @@ idpf_qc_single_tx_queue_reset(struct idpf_tx_queue *txq)
}
txe = txq->sw_ring;
- size = sizeof(struct idpf_flex_tx_desc) * txq->nb_tx_desc;
+ size = sizeof(struct idpf_base_tx_desc) * txq->nb_tx_desc;
for (i = 0; i < size; i++)
((volatile char *)txq->tx_ring)[i] = 0;
prev = (uint16_t)(txq->nb_tx_desc - 1);
for (i = 0; i < txq->nb_tx_desc; i++) {
- txq->tx_ring[i].qw1.cmd_dtype =
- rte_cpu_to_le_16(IDPF_TX_DESC_DTYPE_DESC_DONE);
+ txq->tx_ring[i].qw1 =
+ rte_cpu_to_le_64(IDPF_TX_DESC_DTYPE_DESC_DONE);
txe[i].mbuf = NULL;
txe[i].last_id = i;
txe[prev].next_id = i;
@@ -1307,17 +1307,16 @@ idpf_xmit_cleanup(struct idpf_tx_queue *txq)
uint16_t nb_tx_to_clean;
uint16_t i;
- volatile struct idpf_flex_tx_desc *txd = txq->tx_ring;
+ volatile struct idpf_base_tx_desc *txd = txq->tx_ring;
desc_to_clean_to = (uint16_t)(last_desc_cleaned + txq->rs_thresh);
if (desc_to_clean_to >= nb_tx_desc)
desc_to_clean_to = (uint16_t)(desc_to_clean_to - nb_tx_desc);
desc_to_clean_to = sw_ring[desc_to_clean_to].last_id;
- /* In the writeback Tx desccriptor, the only significant fields are the
4-bit DTYPE */
- if ((txd[desc_to_clean_to].qw1.cmd_dtype &
-rte_cpu_to_le_16(IDPF_TXD_QW1_DTYPE_M)) !=
- rte_cpu_to_le_16(IDPF_TX_DESC_DTYPE_DESC_DONE)) {
+ if ((txd[desc_to_clean_to].qw1 &
+rte_cpu_to_le_64(IDPF_TXD_QW1_DTYPE_M)) !=
+ rte_cpu_to_le_64(IDPF_TX_DESC_DTYPE_DESC_DONE)) {
TX_LOG(DEBUG, "TX descriptor %4u is not done "
"(port=%d queue=%d)", desc_to_clean_to,
txq->port_id, txq->queue_id);
@@ -1331,10 +1330,7 @@ idpf_xmit_cleanup(struct idpf_tx_queue *txq)
nb_tx_to_clean = (uint16_t)(desc_to_clean_to -
last_desc_cleaned);
- txd[desc_to_clean_to].qw1.cmd_dtype = 0;
- txd[desc_to_clean_to].qw1.buf_size = 0;
- for (i = 0; i < RTE_DIM(txd[desc_to_clean_to].qw1.flex.raw); i++)
- txd[desc_to_clean_to].qw1.flex.raw[i] = 0;
+ txd[desc_to_clean_to].qw1 = 0;
txq->last_desc_cleaned = desc_to_clean_to;
txq->nb_free = (uint16_t)(txq->nb_free + nb_tx_to_clean);
@@ -1347,8 +1343,8 @@ uint16_t
idpf_dp_singleq_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
{
- volatile struct idpf_flex_tx_desc *txd;
- volatile struct idpf_flex_tx_desc *txr;
+ volatile struct idpf_base_tx_desc *txd;
+ volatile struct idpf_base_tx_desc *txr;
union idpf_tx_offload tx_offload = {0};
struct idpf_tx_entry *txe, *txn;
struct idpf_tx_entry *sw_ring;
@@ -1356,6 +1352,7 @@ idpf_dp_singleq_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
struct rte_mbuf *tx_pkt;
struct rte_mbuf *m_seg;
uint64_t buf_dma_addr;
+ uint32_t td_offset;
uint64_t ol_flags;
uint16_t tx_last;
uint16_t nb_used;
@@ -1382,6 +1379,7 @@ idpf_dp_singleq_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
td_cmd = 0;
+ td_offset = 0;
tx_pkt = *tx_pkts++;
RTE_MBUF_PREFETCH_TO_FREE(txe->mbuf);
@@ -1462,9 +1460,10 @@ idpf_dp_singleq_xmit_pkts(void *tx_queue, struct
rte_mbuf **tx_pkts,
slen = m_seg->data_len;
buf_dma_addr = rte_mbuf_data_iova(m_seg);
txd->buf_addr = rte_cpu_to_le_64(buf_dma_addr);
- txd->qw1.buf_size = slen;
- txd->qw1.cmd_dtype =
rte_cpu_to_le_16(IDPF_TX_DESC_DTYPE_FLEX_DATA <<
-
IDPF_FLEX_TXD_QW1_DTYPE_S);
+ txd->qw1 = rte_cpu_to_le_64(IDPF_TX_DESC_DTYPE_DATA |
+
RE: [PATCH 1/4] security: remove redundant cast
> -Original Message- > From: Anoob Joseph > Sent: Friday, September 8, 2023 6:40 AM > To: Akhil Goyal ; Power, Ciara > Cc: Jerin Jacob ; dev@dpdk.org > Subject: [PATCH 1/4] security: remove redundant cast > > The API 'rte_cryptodev_get_sec_ctx' returns void *. Type cast is not required. > > Signed-off-by: Anoob Joseph > --- > lib/security/rte_security.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Hi Anoob, Series-Acked-by: Ciara Power
[PATCH v3 1/1] app/graph: add example for different usecases
From: Sunil Kumar Kori
Current l3fwd-graph application only validates l3fwd use case.
To scale up this, new application will be added with a framework
to run as user's provided usecases.
Required configuration and use cases details are fetched via a
static .cli file which will be used to create a graph for
requested uscases.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Rakesh Kudurumalla
---
MAINTAINERS | 7 +
app/graph/cli.c | 208 ++
app/graph/cli.h | 48 ++
app/graph/cli_priv.h | 19 +
app/graph/conn.c | 284 +
app/graph/conn.h | 46 ++
app/graph/ethdev.c | 632 +++
app/graph/ethdev.h | 28 +
app/graph/ethdev_priv.h | 46 ++
app/graph/ethdev_rx.c| 139
app/graph/ethdev_rx.h| 32 +
app/graph/ethdev_rx_priv.h | 23 +
app/graph/examples/l3fwd.cli | 87 +++
app/graph/graph.c| 383 +++
app/graph/graph.h| 11 +
app/graph/graph_priv.h | 32 +
app/graph/ip4_route.c| 146 +
app/graph/ip6_route.c| 154 +
app/graph/l3fwd.c| 152 +
app/graph/l3fwd.h| 11 +
app/graph/main.c | 201 ++
app/graph/mempool.c | 134
app/graph/mempool.h | 18 +
app/graph/mempool_priv.h | 16 +
app/graph/meson.build| 25 +
app/graph/module_api.h | 33 +
app/graph/neigh.c| 269
app/graph/neigh.h| 11 +
app/graph/neigh_priv.h | 22 +
app/graph/route.h| 30 +
app/graph/utils.c| 155 +
app/graph/utils.h| 14 +
app/meson.build | 1 +
doc/guides/tools/graph.rst | 171 +
doc/guides/tools/img/graph-usecase-l3fwd.svg | 210 ++
doc/guides/tools/index.rst | 1 +
36 files changed, 3799 insertions(+)
create mode 100644 app/graph/cli.c
create mode 100644 app/graph/cli.h
create mode 100644 app/graph/cli_priv.h
create mode 100644 app/graph/conn.c
create mode 100644 app/graph/conn.h
create mode 100644 app/graph/ethdev.c
create mode 100644 app/graph/ethdev.h
create mode 100644 app/graph/ethdev_priv.h
create mode 100644 app/graph/ethdev_rx.c
create mode 100644 app/graph/ethdev_rx.h
create mode 100644 app/graph/ethdev_rx_priv.h
create mode 100644 app/graph/examples/l3fwd.cli
create mode 100644 app/graph/graph.c
create mode 100644 app/graph/graph.h
create mode 100644 app/graph/graph_priv.h
create mode 100644 app/graph/ip4_route.c
create mode 100644 app/graph/ip6_route.c
create mode 100644 app/graph/l3fwd.c
create mode 100644 app/graph/l3fwd.h
create mode 100644 app/graph/main.c
create mode 100644 app/graph/mempool.c
create mode 100644 app/graph/mempool.h
create mode 100644 app/graph/mempool_priv.h
create mode 100644 app/graph/meson.build
create mode 100644 app/graph/module_api.h
create mode 100644 app/graph/neigh.c
create mode 100644 app/graph/neigh.h
create mode 100644 app/graph/neigh_priv.h
create mode 100644 app/graph/route.h
create mode 100644 app/graph/utils.c
create mode 100644 app/graph/utils.h
create mode 100644 doc/guides/tools/graph.rst
create mode 100644 doc/guides/tools/img/graph-usecase-l3fwd.svg
diff --git a/MAINTAINERS b/MAINTAINERS
index 698608cdb2..7f149bd060 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1806,6 +1806,13 @@ F: dts/
F: devtools/dts-check-format.sh
F: doc/guides/tools/dts.rst
+Graph application
+M: Sunil Kumar Kori
+M: Rakesh Kudurumalla
+F: app/graph/
+F: doc/guides/tools/graph.rst
+F: doc/guides/tools/img/graph-usecase-l3fwd.svg
+
Other Example Applications
--
diff --git a/app/graph/cli.c b/app/graph/cli.c
new file mode 100644
index 00..237fa8008f
--- /dev/null
+++ b/app/graph/cli.c
@@ -0,0 +1,208 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 Marvell.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "cli_priv.h"
+#include "module_api.h"
+
+#define CMD_MAX_TOKENS 256
+#define MAX_LINE_SIZE 2048
+
+static struct cli_node_head module_list = STAILQ_HEAD_INITIALIZER(module_list);
+
+#define PARSE_DELIMITER " \f\n\r\t\v"
+
+static int
+tokenize_string_parse(char *string, char *tokens[], uint32_t *n_tokens)
+{
+ uint32_t i;
+
+ if ((string == NULL) ||
+
RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application
Hello everyone, As per proposed CLIs to configure graph for different use cases, v3 is implemented under the following request: https://patches.dpdk.org/project/dpdk/patch/20230908104907.4060511-1-sk...@marvell.com/ Please take look on and provide feedback. Regards Sunil Kumar Kori > -Original Message- > From: Rakesh Kudurumalla > Sent: Friday, July 21, 2023 1:09 PM > To: Sunil Kumar Kori ; Jerin Jacob > ; dev@dpdk.org > Cc: Vamsi Krishna Attunuru ; Yan, Zhirun > ; tho...@monjalon.net; Jerin Jacob Kollanukkaran > ; Nithin Kumar Dabilpuram > ; Liang, Cunming ; > Wang, Haiyue > Subject: RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application > > > > > -Original Message- > > From: Sunil Kumar Kori > > Sent: Friday, July 21, 2023 12:31 PM > > To: Jerin Jacob ; Rakesh Kudurumalla > > > > Cc: Vamsi Krishna Attunuru ; dev@dpdk.org; > Yan, > > Zhirun ; tho...@monjalon.net; Jerin Jacob > > Kollanukkaran ; Nithin Kumar Dabilpuram > > ; Liang, Cunming ; > > Wang, Haiyue > > Subject: RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph application > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Friday, July 21, 2023 12:18 PM > > > To: Rakesh Kudurumalla > > > Cc: Vamsi Krishna Attunuru ; dev@dpdk.org; > > Yan, > > > Zhirun ; tho...@monjalon.net; Jerin Jacob > > > Kollanukkaran ; Nithin Kumar Dabilpuram > > > ; Liang, Cunming > ; > > > Wang, Haiyue ; Sunil Kumar Kori > > > > > > Subject: Re: [EXT] Re: [PATCH v2 4/4] app: add testgraph application > > > > > > On Thu, Jul 20, 2023 at 9:22 PM Rakesh Kudurumalla > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Vamsi Krishna Attunuru > > > > > Sent: Thursday, June 1, 2023 8:14 AM > > > > > To: Jerin Jacob > > > > > Cc: Yan, Zhirun ; dev@dpdk.org; > > > > > tho...@monjalon.net; Jerin Jacob Kollanukkaran > > > > > ; Nithin Kumar Dabilpuram > > > > > ; Liang, Cunming > > > > > ; Wang, Haiyue > ; > > > > > Sunil Kumar Kori > > > > > Subject: RE: [EXT] Re: [PATCH v2 4/4] app: add testgraph > > > > > application > > > > > > > > > > > > > > > > > > > > Example use case: l3fwd > > > > > > > > ;Configure usecase > > > > graph l3fwd default 0xff > > > > > > > > ;global specific configuration > > > > mempool mempool0 size 2046 buffers 32000 cache 256 cpu 0 ethdev > > > > 0002:02:00.0 rxq 1 txq 1 mempool0 promiscuous off ethdev > > > > 0002:03:00.0 rxq 1 txq 1 mempool0 promiscuous off > > > > ip4 addr add 10.0.2.1/24 0002:02:00.0 > > > > ip4 addr add 10.0.3.1/24 0002:03:00.0 neigh add ipv4 10.0.2.2 > > > > 52:20:DA:4F:68:70 neigh add ipv4 10.0.2.5 > > > > 62:20:DA:4F:68:70 neigh add ipv4 10.0.3.2 72:20:DA:4F:68:70 neigh > > > > add > > > > ipv4 10.0.3.5 82:20:DA:4F:68:70 > > > > > > > > ;node specific configuration > > > > route add ipv4 ipv4_lookup 10.0.2.0 netmask 255.255.255.0 via > > > > 10.0.2.1 route add ipv4 ipv4_lookup 10.0.3.0 netmask 255.255.255.0 > > > > via > > > > 10.0.3.1 > > > > > > I prefer to use node name first. > > > > > Ack. > > > > > > > > > > > > > > map ethdev_rx port 0002:02:00.0 queue 0 core 6 map ethdev_rx port > > > > 0002:03:00.0 queue 1 core 5 > > > > > > I prefer to use node name first. > > > > > Ack. > > > > > Rest looks good to me. > > > > > > > > > > > ;Run usecase > > > > graph start > > Addressed comments and updated specification > > Graph application Interface file > Configure Use cases > = > This section consists of which use cases are needed to be configured and > model to be used along with number of coremask > to run graph on that. Following is the exposed syntax to configure given use > case. > > Syntax: > > graph [usecase specific configuration] [model specific > configuration] > > Where: > > usecases: It is comma separated list defining the requested use cases. > Example values are - > l3fwd > ipsec > usecase specific configuration: It defines following usecase specific > configuration - > burst size (bsz) > timeout (tmo) > coremask > model: It defines the model for dequeuing packets. Example models are - > run to completion (rtc) > multi core dispatch (mcd) > Global specific configuration > == > This section consists of device specific configuration which are needed to > make a DPDK port usable such as number > > of Rx/TX queues, MTU, mempool etc. Along with it consists global network > table configuration required for each use case > > such as configure IP address to device, arp entries for given IP etc. > Supported > hardware offloads to be used by > this use case is also added under this configuration. Graph is created for > this > use case at the end of this configuration. > > Syntax: > > mempool size buffers cache > > Where: > > mempool_name : Name of the mempool used for further pool operations. > size : Size of each element in mempool > buffers: Number of elements in mempool > cache : Size of the per-core object cache > : Socket id
[PATCH 00/36] fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state,
for example,
[1] 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding"
[2] 141a520b35f7 ("app/testpmd: fix primary process not polling all queues")
Therefore, the drivers need to modify the queue state in time
according to the actual situation, especially when dev_start
and dev_stop are called. see [3] for more information.
[3] https://inbox.dpdk.org/dev/20230721160422.3848154-1-ferruh.yi...@amd.com/
This patchset also resubmit the patch [2] and makes some fixes on the patch.
Jie Hai (36):
net/axgbe: fix Rx and Tx queue state
net/af_packet: fix Rx and Tx queue state
net/af_xdp: fix Rx and Tx queue state
net/avp: fix Rx and Tx queue state
net/bnx2x: fix Rx and Tx queue state
net/bnxt: fix Rx and Tx queue state
net/bonding: fix Rx and Tx queue state
net/cxgbe: fix Rx and Tx queue state
net/dpaa: fix Rx and Tx queue state
net/dpaa2: fix Rx and Tx queue state
net/e1000: fix Rx and Tx queue state
net/ena: fix Rx and Tx queue state
net/enetc: fix Rx and Tx queue state
net/enic: fix Rx and Tx queue state
net/hinic: fix Rx and Tx queue state
net/ipn3ke: fix Rx and Tx queue state
net/memif: fix Rx and Tx queue state
net/mana: fix Rx and Tx queue state
net/mlx4: fix Rx and Tx queue state
net/mvneta: fix Rx and Tx queue state
net/mvpp2: fix Rx and Tx queue state
net/netvsc: fix Rx and Tx queue state
net/nfp: fix Rx and Tx queue state
net/ngbe: fix Rx and Tx queue state
net/null: fix Rx and Tx queue state
net/octeon_ep: fix Rx and Tx queue state
net/octeontx: fix Rx and Tx queue state
net/pfe: fix Rx and Tx queue state
net/ring: fix Rx and Tx queue state
net/sfc: fix Rx and Tx queue state
net/softnic: fix Rx and Tx queue state
net/txgbe: fix Rx and Tx queue state
net/vhost: fix Rx and Tx queue state
net/virtio: fix Rx and Tx queue state
net/vmxnet3: fix Rx and Tx queue state
app/testpmd: fix primary process not polling all queues
app/test-pmd/testpmd.c| 25 +++
drivers/net/af_packet/rte_eth_af_packet.c | 9 +++
drivers/net/af_xdp/rte_eth_af_xdp.c | 13 ++
drivers/net/avp/avp_ethdev.c | 12 +
drivers/net/axgbe/axgbe_ethdev.c | 7 ++
drivers/net/axgbe/axgbe_rxtx.c| 2 ++
drivers/net/bnx2x/bnx2x_ethdev.c | 12 +
drivers/net/bnxt/bnxt_ethdev.c| 6 +
drivers/net/bonding/rte_eth_bond_pmd.c| 10
drivers/net/cxgbe/cxgbe_ethdev.c | 6 +
drivers/net/dpaa/dpaa_ethdev.c| 12 +
drivers/net/dpaa2/dpaa2_ethdev.c | 11
drivers/net/e1000/em_rxtx.c | 8 ++
drivers/net/e1000/igb_rxtx.c | 4 +++
drivers/net/ena/ena_ethdev.c | 12 +
drivers/net/enetc/enetc_ethdev.c | 12 +
drivers/net/enic/enic_ethdev.c| 6 +
drivers/net/hinic/hinic_pmd_ethdev.c | 12 +
drivers/net/ipn3ke/ipn3ke_representor.c | 12 +
drivers/net/mana/rx.c | 3 +++
drivers/net/mana/tx.c | 4 +++
drivers/net/memif/rte_eth_memif.c | 16
drivers/net/mlx4/mlx4.c | 13 ++
drivers/net/mvneta/mvneta_ethdev.c| 12 +
drivers/net/mvpp2/mrvl_ethdev.c | 10
drivers/net/netvsc/hn_ethdev.c| 12 +
drivers/net/nfp/flower/nfp_flower.c | 8 ++
.../net/nfp/flower/nfp_flower_representor.c | 12 +
drivers/net/nfp/nfp_common.c | 2 ++
drivers/net/nfp/nfp_ethdev.c | 6 +
drivers/net/nfp/nfp_ethdev_vf.c | 6 +
drivers/net/ngbe/ngbe_rxtx.c | 2 ++
drivers/net/null/rte_eth_null.c | 15 +++
drivers/net/octeon_ep/otx_ep_ethdev.c | 11
drivers/net/octeontx/octeontx_ethdev.c| 11
drivers/net/pfe/pfe_ethdev.c | 11
drivers/net/ring/rte_eth_ring.c | 15 +++
drivers/net/sfc/sfc_repr.c| 12 +
drivers/net/softnic/rte_eth_softnic.c | 12 +
drivers/net/txgbe/txgbe_rxtx.c| 8 ++
drivers/net/vhost/rte_eth_vhost.c | 12 +
drivers/net/virtio/virtio_ethdev.c| 11
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +
43 files changed, 422 insertions(+), 5 deletions(-)
--
2.30.0
[PATCH 02/36] net/af_packet: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/af_packet/rte_eth_af_packet.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index c13a0942aa1d..397a32db5886 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -313,7 +313,14 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
static int
eth_dev_start(struct rte_eth_dev *dev)
{
+ struct pmd_internals *internals = dev->data->dev_private;
+ uint16_t i;
+
dev->data->dev_link.link_status = RTE_ETH_LINK_UP;
+ for (i = 0; i < internals->nb_queues; i++) {
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ }
return 0;
}
@@ -341,6 +348,8 @@ eth_dev_stop(struct rte_eth_dev *dev)
internals->rx_queue[i].sockfd = -1;
internals->tx_queue[i].sockfd = -1;
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
--
2.30.0
[PATCH 03/36] net/af_xdp: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index c7786cc53a5e..0cc51223ba32 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -694,7 +694,13 @@ eth_af_xdp_tx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
static int
eth_dev_start(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
dev->data->dev_link.link_status = RTE_ETH_LINK_UP;
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ }
return 0;
}
@@ -703,7 +709,14 @@ eth_dev_start(struct rte_eth_dev *dev)
static int
eth_dev_stop(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ }
+
return 0;
}
--
2.30.0
[PATCH 01/36] net/axgbe: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/axgbe/axgbe_ethdev.c | 7 +++
drivers/net/axgbe/axgbe_rxtx.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/net/axgbe/axgbe_ethdev.c b/drivers/net/axgbe/axgbe_ethdev.c
index 48714eebe699..f378fd570e3a 100644
--- a/drivers/net/axgbe/axgbe_ethdev.c
+++ b/drivers/net/axgbe/axgbe_ethdev.c
@@ -352,6 +352,7 @@ static int
axgbe_dev_start(struct rte_eth_dev *dev)
{
struct axgbe_port *pdata = dev->data->dev_private;
+ uint16_t i;
int ret;
dev->dev_ops = &axgbe_eth_dev_ops;
@@ -388,6 +389,12 @@ axgbe_dev_start(struct rte_eth_dev *dev)
axgbe_set_rx_function(dev);
axgbe_set_tx_function(dev);
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
diff --git a/drivers/net/axgbe/axgbe_rxtx.c b/drivers/net/axgbe/axgbe_rxtx.c
index 625a92109baf..a9ff291cef3d 100644
--- a/drivers/net/axgbe/axgbe_rxtx.c
+++ b/drivers/net/axgbe/axgbe_rxtx.c
@@ -1124,6 +1124,7 @@ void axgbe_dev_clear_queues(struct rte_eth_dev *dev)
axgbe_rx_queue_release(rxq);
dev->data->rx_queues[i] = NULL;
}
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
for (i = 0; i < dev->data->nb_tx_queues; i++) {
@@ -1133,6 +1134,7 @@ void axgbe_dev_clear_queues(struct rte_eth_dev *dev)
axgbe_tx_queue_release(txq);
dev->data->tx_queues[i] = NULL;
}
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
}
--
2.30.0
[PATCH 05/36] net/bnx2x: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/bnx2x/bnx2x_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 4448cf2de2d7..1327cbe912ae 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -211,6 +211,7 @@ bnx2x_dev_start(struct rte_eth_dev *dev)
{
struct bnx2x_softc *sc = dev->data->dev_private;
int ret = 0;
+ uint16_t i;
PMD_INIT_FUNC_TRACE(sc);
@@ -244,6 +245,11 @@ bnx2x_dev_start(struct rte_eth_dev *dev)
bnx2x_print_device_info(sc);
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return ret;
}
@@ -252,6 +258,7 @@ bnx2x_dev_stop(struct rte_eth_dev *dev)
{
struct bnx2x_softc *sc = dev->data->dev_private;
int ret = 0;
+ uint16_t i;
PMD_INIT_FUNC_TRACE(sc);
@@ -277,6 +284,11 @@ bnx2x_dev_stop(struct rte_eth_dev *dev)
return ret;
}
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 04/36] net/avp: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/avp/avp_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index b2a08f563542..53d9e38c939b 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -2036,6 +2036,7 @@ static int
avp_dev_start(struct rte_eth_dev *eth_dev)
{
struct avp_dev *avp = AVP_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ uint16_t i;
int ret;
rte_spinlock_lock(&avp->lock);
@@ -2056,6 +2057,11 @@ avp_dev_start(struct rte_eth_dev *eth_dev)
/* remember current link state */
avp->flags |= AVP_F_LINKUP;
+ for (i = 0; i < avp->num_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < avp->num_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
ret = 0;
unlock:
@@ -2067,6 +2073,7 @@ static int
avp_dev_stop(struct rte_eth_dev *eth_dev)
{
struct avp_dev *avp = AVP_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ uint16_t i;
int ret;
rte_spinlock_lock(&avp->lock);
@@ -2086,6 +2093,11 @@ avp_dev_stop(struct rte_eth_dev *eth_dev)
ret);
}
+ for (i = 0; i < avp->num_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < avp->num_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
unlock:
rte_spinlock_unlock(&avp->lock);
return ret;
--
2.30.0
[PATCH 06/36] net/bnxt: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/bnxt/bnxt_ethdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index ee1552452a11..7120d54d382e 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1507,6 +1507,7 @@ static int bnxt_dev_stop(struct rte_eth_dev *eth_dev)
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
struct rte_eth_link link;
+ uint16_t i;
int ret;
eth_dev->data->dev_started = 0;
@@ -1567,6 +1568,11 @@ static int bnxt_dev_stop(struct rte_eth_dev *eth_dev)
eth_dev->data->scattered_rx = 0;
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 08/36] net/cxgbe: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/cxgbe/cxgbe_ethdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 45bbeaef0ceb..8cc3d9f257a0 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -414,6 +414,7 @@ int cxgbe_dev_stop(struct rte_eth_dev *eth_dev)
{
struct port_info *pi = eth_dev->data->dev_private;
struct adapter *adapter = pi->adapter;
+ uint16_t i;
CXGBE_FUNC_TRACE();
@@ -429,6 +430,11 @@ int cxgbe_dev_stop(struct rte_eth_dev *eth_dev)
t4_sge_eth_clear_queues(pi);
eth_dev->data->scattered_rx = 0;
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 07/36] net/bonding: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 73205f78f4e2..ede953c06301 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2089,6 +2089,11 @@ bond_ethdev_start(struct rte_eth_dev *eth_dev)
internals->mode == BONDING_MODE_ALB)
bond_tlb_enable(internals);
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
out_err:
@@ -2174,6 +2179,11 @@ bond_ethdev_stop(struct rte_eth_dev *eth_dev)
deactivate_slave(eth_dev, slave_id);
}
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 10/36] net/dpaa2: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/dpaa2/dpaa2_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 679f33ae1a08..8e610b6bba30 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -1278,6 +1278,11 @@ dpaa2_dev_start(struct rte_eth_dev *dev)
if (priv->en_ordered)
dev->tx_pkt_burst = dpaa2_dev_tx_ordered;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -1295,6 +1300,7 @@ dpaa2_dev_stop(struct rte_eth_dev *dev)
struct rte_device *rdev = dev->device;
struct rte_intr_handle *intr_handle;
struct rte_dpaa2_device *dpaa2_dev;
+ uint16_t i;
dpaa2_dev = container_of(rdev, struct rte_dpaa2_device, device);
intr_handle = dpaa2_dev->intr_handle;
@@ -1329,6 +1335,11 @@ dpaa2_dev_stop(struct rte_eth_dev *dev)
memset(&link, 0, sizeof(link));
rte_eth_linkstatus_set(dev, &link);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 09/36] net/dpaa: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/dpaa/dpaa_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index a6c86113d125..ef4c06db6a4d 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -399,6 +399,7 @@ static void dpaa_interrupt_handler(void *param)
static int dpaa_eth_dev_start(struct rte_eth_dev *dev)
{
struct dpaa_if *dpaa_intf = dev->data->dev_private;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
@@ -413,12 +414,18 @@ static int dpaa_eth_dev_start(struct rte_eth_dev *dev)
fman_if_enable_rx(dev->process_private);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
static int dpaa_eth_dev_stop(struct rte_eth_dev *dev)
{
struct fman_if *fif = dev->process_private;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
dev->data->dev_started = 0;
@@ -427,6 +434,11 @@ static int dpaa_eth_dev_stop(struct rte_eth_dev *dev)
fman_if_disable_rx(fif);
dev->tx_pkt_burst = dpaa_eth_tx_drop_all;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 13/36] net/enetc: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/enetc/enetc_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/enetc/enetc_ethdev.c b/drivers/net/enetc/enetc_ethdev.c
index 1b4337bc488c..c9352f074683 100644
--- a/drivers/net/enetc/enetc_ethdev.c
+++ b/drivers/net/enetc/enetc_ethdev.c
@@ -17,6 +17,7 @@ enetc_dev_start(struct rte_eth_dev *dev)
ENETC_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct enetc_hw *enetc_hw = &hw->hw;
uint32_t val;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
if (hw->device_id == ENETC_DEV_ID_VF)
@@ -45,6 +46,11 @@ enetc_dev_start(struct rte_eth_dev *dev)
ENETC_PM0_IFM_XGMII);
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -55,6 +61,7 @@ enetc_dev_stop(struct rte_eth_dev *dev)
ENETC_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct enetc_hw *enetc_hw = &hw->hw;
uint32_t val;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
dev->data->dev_started = 0;
@@ -69,6 +76,11 @@ enetc_dev_stop(struct rte_eth_dev *dev)
enetc_port_wr(enetc_hw, ENETC_PM0_CMD_CFG,
val & (~(ENETC_PM0_TX_EN | ENETC_PM0_RX_EN)));
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 12/36] net/ena: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/ena/ena_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index efcb163027c8..7345e480f880 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1171,6 +1171,7 @@ static int ena_start(struct rte_eth_dev *dev)
struct ena_adapter *adapter = dev->data->dev_private;
uint64_t ticks;
int rc = 0;
+ uint16_t i;
/* Cannot allocate memory in secondary process */
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
@@ -1208,6 +1209,11 @@ static int ena_start(struct rte_eth_dev *dev)
++adapter->dev_stats.dev_start;
adapter->state = ENA_ADAPTER_STATE_RUNNING;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
err_rss_init:
@@ -1223,6 +1229,7 @@ static int ena_stop(struct rte_eth_dev *dev)
struct ena_com_dev *ena_dev = &adapter->ena_dev;
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
+ uint16_t i;
int rc;
/* Cannot free memory in secondary process */
@@ -1254,6 +1261,11 @@ static int ena_stop(struct rte_eth_dev *dev)
adapter->state = ENA_ADAPTER_STATE_STOPPED;
dev->data->dev_started = 0;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 16/36] net/ipn3ke: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/ipn3ke/ipn3ke_representor.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ipn3ke/ipn3ke_representor.c
b/drivers/net/ipn3ke/ipn3ke_representor.c
index c82f8b533370..d904d3f251e3 100644
--- a/drivers/net/ipn3ke/ipn3ke_representor.c
+++ b/drivers/net/ipn3ke/ipn3ke_representor.c
@@ -120,6 +120,7 @@ ipn3ke_rpst_dev_start(struct rte_eth_dev *dev)
uint64_t base_mac;
uint32_t val;
char attr_name[IPN3KE_RAWDEV_ATTR_LEN_MAX];
+ uint16_t i;
rawdev = hw->rawdev;
@@ -190,6 +191,11 @@ ipn3ke_rpst_dev_start(struct rte_eth_dev *dev)
ipn3ke_rpst_link_update(dev, 0);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -198,6 +204,7 @@ ipn3ke_rpst_dev_stop(struct rte_eth_dev *dev)
{
struct ipn3ke_hw *hw = IPN3KE_DEV_PRIVATE_TO_HW(dev);
struct ipn3ke_rpst *rpst = IPN3KE_DEV_PRIVATE_TO_RPST(dev);
+ uint16_t i;
if (hw->retimer.mac_type == IFPGA_RAWDEV_RETIMER_MAC_TYPE_10GE_XFI) {
/* Disable the TX path */
@@ -207,6 +214,11 @@ ipn3ke_rpst_dev_stop(struct rte_eth_dev *dev)
ipn3ke_xmac_rx_disable(hw, rpst->port_id, 0);
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 14/36] net/enic: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/enic/enic_ethdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index cdf091559196..a487256fa154 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -368,6 +368,7 @@ static int enicpmd_dev_stop(struct rte_eth_dev *eth_dev)
{
struct rte_eth_link link;
struct enic *enic = pmd_priv(eth_dev);
+ uint16_t i;
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -378,6 +379,11 @@ static int enicpmd_dev_stop(struct rte_eth_dev *eth_dev)
memset(&link, 0, sizeof(link));
rte_eth_linkstatus_set(eth_dev, &link);
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 17/36] net/memif: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/memif/rte_eth_memif.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/memif/rte_eth_memif.c
b/drivers/net/memif/rte_eth_memif.c
index 6a8ff5b4eb65..636c8a4af345 100644
--- a/drivers/net/memif/rte_eth_memif.c
+++ b/drivers/net/memif/rte_eth_memif.c
@@ -1358,6 +1358,7 @@ memif_dev_start(struct rte_eth_dev *dev)
{
struct pmd_internals *pmd = dev->data->dev_private;
int ret = 0;
+ uint16_t i;
switch (pmd->role) {
case MEMIF_ROLE_CLIENT:
@@ -1372,13 +1373,28 @@ memif_dev_start(struct rte_eth_dev *dev)
break;
}
+ if (ret == 0) {
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STARTED;
+ }
+
return ret;
}
static int
memif_dev_stop(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
memif_disconnect(dev);
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 11/36] net/e1000: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/e1000/em_rxtx.c | 8
drivers/net/e1000/igb_rxtx.c | 4
2 files changed, 12 insertions(+)
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index cb5ce2307b3b..df5fbb782361 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -1576,6 +1576,8 @@ em_dev_clear_queues(struct rte_eth_dev *dev)
em_tx_queue_release_mbufs(txq);
em_reset_tx_queue(txq);
}
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -1584,6 +1586,8 @@ em_dev_clear_queues(struct rte_eth_dev *dev)
em_rx_queue_release_mbufs(rxq);
em_reset_rx_queue(rxq);
}
+
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
}
@@ -1812,6 +1816,8 @@ eth_em_rx_init(struct rte_eth_dev *dev)
rxdctl |= E1000_RXDCTL_GRAN;
E1000_WRITE_REG(hw, E1000_RXDCTL(i), rxdctl);
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
/*
* Due to EM devices not having any sort of hardware
* limit for packet length, jumbo frame of any size
@@ -1946,6 +1952,8 @@ eth_em_tx_init(struct rte_eth_dev *dev)
txdctl |= (txq->wthresh & 0x3F) << 16;
txdctl |= E1000_TXDCTL_GRAN;
E1000_WRITE_REG(hw, E1000_TXDCTL(i), txdctl);
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
}
/* Program the Transmit Control Register. */
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 61c6394310b3..448c4b7d9d0f 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -2745,6 +2745,8 @@ eth_igbvf_rx_init(struct rte_eth_dev *dev)
else
rxdctl |= ((rxq->wthresh & 0x1F) << 16);
E1000_WRITE_REG(hw, E1000_RXDCTL(i), rxdctl);
+
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
}
if (dev->data->dev_conf.rxmode.offloads & RTE_ETH_RX_OFFLOAD_SCATTER) {
@@ -2816,6 +2818,8 @@ eth_igbvf_tx_init(struct rte_eth_dev *dev)
txdctl |= ((txq->wthresh & 0x1F) << 16);
txdctl |= E1000_TXDCTL_QUEUE_ENABLE;
E1000_WRITE_REG(hw, E1000_TXDCTL(i), txdctl);
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
}
}
--
2.30.0
[PATCH 15/36] net/hinic: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/hinic/hinic_pmd_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/hinic/hinic_pmd_ethdev.c
b/drivers/net/hinic/hinic_pmd_ethdev.c
index 7aa5e7d8e929..adc9f75c81aa 100644
--- a/drivers/net/hinic/hinic_pmd_ethdev.c
+++ b/drivers/net/hinic/hinic_pmd_ethdev.c
@@ -980,6 +980,7 @@ static int hinic_dev_start(struct rte_eth_dev *dev)
int rc;
char *name;
struct hinic_nic_dev *nic_dev;
+ uint16_t i;
nic_dev = HINIC_ETH_DEV_TO_PRIVATE_NIC_DEV(dev);
name = dev->data->name;
@@ -1047,6 +1048,11 @@ static int hinic_dev_start(struct rte_eth_dev *dev)
rte_bit_relaxed_set32(HINIC_DEV_START, &nic_dev->dev_status);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
en_port_fail:
@@ -1169,6 +1175,7 @@ static int hinic_dev_stop(struct rte_eth_dev *dev)
uint16_t port_id;
struct hinic_nic_dev *nic_dev;
struct rte_eth_link link;
+ uint16_t i;
nic_dev = HINIC_ETH_DEV_TO_PRIVATE_NIC_DEV(dev);
name = dev->data->name;
@@ -1215,6 +1222,11 @@ static int hinic_dev_stop(struct rte_eth_dev *dev)
hinic_free_all_rx_mbuf(dev);
hinic_free_all_tx_mbuf(dev);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 21/36] net/mvpp2: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/mvpp2/mrvl_ethdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/mvpp2/mrvl_ethdev.c b/drivers/net/mvpp2/mrvl_ethdev.c
index 89c83f1c1f82..79d5afe2b3c5 100644
--- a/drivers/net/mvpp2/mrvl_ethdev.c
+++ b/drivers/net/mvpp2/mrvl_ethdev.c
@@ -951,6 +951,9 @@ mrvl_dev_start(struct rte_eth_dev *dev)
goto out;
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
mrvl_flow_init(dev);
mrvl_mtr_init(dev);
mrvl_set_tx_function(dev);
@@ -1076,6 +1079,13 @@ mrvl_flush_bpool(struct rte_eth_dev *dev)
static int
mrvl_dev_stop(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return mrvl_dev_set_link_down(dev);
}
--
2.30.0
[PATCH 22/36] net/netvsc: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/netvsc/hn_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index d0bbc0a4c0c0..f778e3c64649 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -990,6 +990,7 @@ static int
hn_dev_start(struct rte_eth_dev *dev)
{
struct hn_data *hv = dev->data->dev_private;
+ uint16_t i;
int error;
PMD_INIT_FUNC_TRACE();
@@ -1017,6 +1018,11 @@ hn_dev_start(struct rte_eth_dev *dev)
if (error == 0)
hn_dev_link_update(dev, 0);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return error;
}
@@ -1024,10 +1030,16 @@ static int
hn_dev_stop(struct rte_eth_dev *dev)
{
struct hn_data *hv = dev->data->dev_private;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
dev->data->dev_started = 0;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
rte_dev_event_callback_unregister(NULL, netvsc_hotadd_callback, hv);
hn_rndis_set_rxfilter(hv, 0);
return hn_vf_stop(dev);
--
2.30.0
[PATCH 20/36] net/mvneta: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/mvneta/mvneta_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/mvneta/mvneta_ethdev.c
b/drivers/net/mvneta/mvneta_ethdev.c
index d7953ac7cbac..ad27b3e663ec 100644
--- a/drivers/net/mvneta/mvneta_ethdev.c
+++ b/drivers/net/mvneta/mvneta_ethdev.c
@@ -376,6 +376,10 @@ mvneta_dev_start(struct rte_eth_dev *dev)
goto out;
}
+ /* start rx queues */
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
/* start tx queues */
for (i = 0; i < dev->data->nb_tx_queues; i++)
dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
@@ -412,6 +416,14 @@ mvneta_dev_stop(struct rte_eth_dev *dev)
priv->ppio = NULL;
+ /* stop rx queues */
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
+ /* stop tx queues */
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 23/36] net/nfp: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/nfp/flower/nfp_flower.c | 8
drivers/net/nfp/flower/nfp_flower_representor.c | 12
drivers/net/nfp/nfp_common.c| 2 ++
drivers/net/nfp/nfp_ethdev.c| 6 ++
drivers/net/nfp/nfp_ethdev_vf.c | 6 ++
5 files changed, 34 insertions(+)
diff --git a/drivers/net/nfp/flower/nfp_flower.c
b/drivers/net/nfp/flower/nfp_flower.c
index 77dab864f319..eb7b40a6eb25 100644
--- a/drivers/net/nfp/flower/nfp_flower.c
+++ b/drivers/net/nfp/flower/nfp_flower.c
@@ -85,6 +85,7 @@ int
nfp_flower_pf_start(struct rte_eth_dev *dev)
{
int ret;
+ uint16_t i;
uint32_t new_ctrl;
uint32_t update = 0;
struct nfp_net_hw *hw;
@@ -137,6 +138,11 @@ nfp_flower_pf_start(struct rte_eth_dev *dev)
return -EIO;
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -159,11 +165,13 @@ nfp_flower_pf_stop(struct rte_eth_dev *dev)
for (i = 0; i < dev->data->nb_tx_queues; i++) {
this_tx_q = dev->data->tx_queues[i];
nfp_net_reset_tx_queue(this_tx_q);
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
this_rx_q = dev->data->rx_queues[i];
nfp_net_reset_rx_queue(this_rx_q);
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
if (rte_eal_process_type() == RTE_PROC_PRIMARY)
diff --git a/drivers/net/nfp/flower/nfp_flower_representor.c
b/drivers/net/nfp/flower/nfp_flower_representor.c
index 5f94d20f1b0c..3f97bc9f8a39 100644
--- a/drivers/net/nfp/flower/nfp_flower_representor.c
+++ b/drivers/net/nfp/flower/nfp_flower_representor.c
@@ -303,6 +303,7 @@ nfp_flower_repr_dev_start(struct rte_eth_dev *dev)
{
struct nfp_flower_representor *repr;
struct nfp_app_fw_flower *app_fw_flower;
+ uint16_t i;
repr = dev->data->dev_private;
app_fw_flower = repr->app_fw_flower;
@@ -314,6 +315,11 @@ nfp_flower_repr_dev_start(struct rte_eth_dev *dev)
nfp_flower_cmsg_port_mod(app_fw_flower, repr->port_id, true);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -322,6 +328,7 @@ nfp_flower_repr_dev_stop(struct rte_eth_dev *dev)
{
struct nfp_flower_representor *repr;
struct nfp_app_fw_flower *app_fw_flower;
+ uint16_t i;
repr = dev->data->dev_private;
app_fw_flower = repr->app_fw_flower;
@@ -333,6 +340,11 @@ nfp_flower_repr_dev_stop(struct rte_eth_dev *dev)
repr->nfp_idx, 0);
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index 5092e5869de4..c0d4708f2b3e 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -1927,6 +1927,7 @@ nfp_net_stop_rx_queue(struct rte_eth_dev *dev)
for (i = 0; i < dev->data->nb_rx_queues; i++) {
this_rx_q = dev->data->rx_queues[i];
nfp_net_reset_rx_queue(this_rx_q);
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
}
@@ -1952,6 +1953,7 @@ nfp_net_stop_tx_queue(struct rte_eth_dev *dev)
for (i = 0; i < dev->data->nb_tx_queues; i++) {
this_tx_q = dev->data->tx_queues[i];
nfp_net_reset_tx_queue(this_tx_q);
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
}
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index e3ff3d80873d..bdfd5530c55f 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -65,6 +65,7 @@ nfp_net_start(struct rte_eth_dev *dev)
struct rte_eth_conf *dev_conf;
[PATCH 24/36] net/ngbe: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/ngbe/ngbe_rxtx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ngbe/ngbe_rxtx.c b/drivers/net/ngbe/ngbe_rxtx.c
index f31906cc2fe3..ec353a30b1de 100644
--- a/drivers/net/ngbe/ngbe_rxtx.c
+++ b/drivers/net/ngbe/ngbe_rxtx.c
@@ -2415,6 +2415,7 @@ ngbe_dev_clear_queues(struct rte_eth_dev *dev)
if (txq != NULL) {
txq->ops->release_mbufs(txq);
txq->ops->reset(txq);
+ dev->data->tx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STOPPED;
}
}
@@ -2424,6 +2425,7 @@ ngbe_dev_clear_queues(struct rte_eth_dev *dev)
if (rxq != NULL) {
ngbe_rx_queue_release_mbufs(rxq);
ngbe_reset_rx_queue(adapter, rxq);
+ dev->data->rx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STOPPED;
}
}
}
--
2.30.0
[PATCH 25/36] net/null: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/null/rte_eth_null.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 31081af79752..d742bc415c8c 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -192,21 +192,36 @@ eth_dev_configure(struct rte_eth_dev *dev __rte_unused)
static int
eth_dev_start(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
if (dev == NULL)
return -EINVAL;
dev->data->dev_link.link_status = RTE_ETH_LINK_UP;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
static int
eth_dev_stop(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
if (dev == NULL)
return 0;
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 18/36] net/mana: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/mana/rx.c | 3 +++
drivers/net/mana/tx.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/net/mana/rx.c b/drivers/net/mana/rx.c
index 14d908580185..9da7133005a4 100644
--- a/drivers/net/mana/rx.c
+++ b/drivers/net/mana/rx.c
@@ -190,6 +190,8 @@ mana_stop_rx_queues(struct rte_eth_dev *dev)
memset(&rxq->gdma_rq, 0, sizeof(rxq->gdma_rq));
memset(&rxq->gdma_cq, 0, sizeof(rxq->gdma_cq));
+
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
return 0;
}
@@ -252,6 +254,7 @@ mana_start_rx_queues(struct rte_eth_dev *dev)
}
ind_tbl[i] = rxq->wq;
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
}
struct ibv_rwq_ind_table_init_attr ind_table_attr = {
diff --git a/drivers/net/mana/tx.c b/drivers/net/mana/tx.c
index 11ba2ee1ac58..fb474e73ec1f 100644
--- a/drivers/net/mana/tx.c
+++ b/drivers/net/mana/tx.c
@@ -51,6 +51,8 @@ mana_stop_tx_queues(struct rte_eth_dev *dev)
memset(&txq->gdma_sq, 0, sizeof(txq->gdma_sq));
memset(&txq->gdma_cq, 0, sizeof(txq->gdma_cq));
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
return 0;
@@ -142,6 +144,8 @@ mana_start_tx_queues(struct rte_eth_dev *dev)
txq->gdma_cq.id, txq->gdma_cq.buffer,
txq->gdma_cq.count, txq->gdma_cq.size,
txq->gdma_cq.head);
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
}
return 0;
--
2.30.0
[PATCH 19/36] net/mlx4: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/mlx4/mlx4.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index a54016f4a235..1389b606ccb1 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -292,6 +292,7 @@ mlx4_dev_start(struct rte_eth_dev *dev)
{
struct mlx4_priv *priv = dev->data->dev_private;
struct rte_flow_error error;
+ uint16_t i;
int ret;
if (priv->started)
@@ -327,6 +328,12 @@ mlx4_dev_start(struct rte_eth_dev *dev)
dev->rx_pkt_burst = mlx4_rx_burst;
/* Enable datapath on secondary process. */
mlx4_mp_req_start_rxtx(dev);
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
err:
mlx4_dev_stop(dev);
@@ -345,6 +352,7 @@ static int
mlx4_dev_stop(struct rte_eth_dev *dev)
{
struct mlx4_priv *priv = dev->data->dev_private;
+ uint16_t i;
if (!priv->started)
return 0;
@@ -359,6 +367,11 @@ mlx4_dev_stop(struct rte_eth_dev *dev)
mlx4_rxq_intr_disable(priv);
mlx4_rss_deinit(priv);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 27/36] net/octeontx: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/octeontx/octeontx_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/octeontx/octeontx_ethdev.c
b/drivers/net/octeontx/octeontx_ethdev.c
index a6ae51a42c4e..2a8378a33ea2 100644
--- a/drivers/net/octeontx/octeontx_ethdev.c
+++ b/drivers/net/octeontx/octeontx_ethdev.c
@@ -732,6 +732,11 @@ octeontx_dev_start(struct rte_eth_dev *dev)
}
/* Success */
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return ret;
pki_port_stop_error:
@@ -746,6 +751,7 @@ static int
octeontx_dev_stop(struct rte_eth_dev *dev)
{
struct octeontx_nic *nic = octeontx_pmd_priv(dev);
+ uint16_t i;
int ret;
PMD_INIT_FUNC_TRACE();
@@ -772,6 +778,11 @@ octeontx_dev_stop(struct rte_eth_dev *dev)
return ret;
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 28/36] net/pfe: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/pfe/pfe_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/pfe/pfe_ethdev.c b/drivers/net/pfe/pfe_ethdev.c
index 0352a5795096..551f3cf193e3 100644
--- a/drivers/net/pfe/pfe_ethdev.c
+++ b/drivers/net/pfe/pfe_ethdev.c
@@ -241,6 +241,7 @@ pfe_eth_open(struct rte_eth_dev *dev)
struct pfe_eth_priv_s *priv = dev->data->dev_private;
struct hif_client_s *client;
struct hif_shm *hif_shm;
+ uint16_t i;
int rc;
/* Register client driver with HIF */
@@ -318,6 +319,10 @@ pfe_eth_open(struct rte_eth_dev *dev)
PFE_PMD_INFO("PFE INTERRUPT Mode enabled");
}
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
err0:
return rc;
@@ -361,6 +366,7 @@ static int
pfe_eth_stop(struct rte_eth_dev *dev/*, int wake*/)
{
struct pfe_eth_priv_s *priv = dev->data->dev_private;
+ uint16_t i;
dev->data->dev_started = 0;
@@ -370,6 +376,11 @@ pfe_eth_stop(struct rte_eth_dev *dev/*, int wake*/)
dev->rx_pkt_burst = rte_eth_pkt_burst_dummy;
dev->tx_pkt_burst = rte_eth_pkt_burst_dummy;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 26/36] net/octeon_ep: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/octeon_ep/otx_ep_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/octeon_ep/otx_ep_ethdev.c
b/drivers/net/octeon_ep/otx_ep_ethdev.c
index 57b965ad0670..970372bbd791 100644
--- a/drivers/net/octeon_ep/otx_ep_ethdev.c
+++ b/drivers/net/octeon_ep/otx_ep_ethdev.c
@@ -156,6 +156,11 @@ otx_ep_dev_start(struct rte_eth_dev *eth_dev)
otx_ep_dev_link_update(eth_dev, 0);
otx_ep_info("dev started\n");
+ for (q = 0; q < eth_dev->data->nb_rx_queues; q++)
+ eth_dev->data->rx_queue_state[q] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (q = 0; q < eth_dev->data->nb_tx_queues; q++)
+ eth_dev->data->tx_queue_state[q] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -164,9 +169,15 @@ static int
otx_ep_dev_stop(struct rte_eth_dev *eth_dev)
{
struct otx_ep_device *otx_epvf = OTX_EP_DEV(eth_dev);
+ uint16_t i;
otx_epvf->fn_list.disable_io_queues(otx_epvf);
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 29/36] net/ring: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/ring/rte_eth_ring.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index c43dccea7ffe..48953dd7a059 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -113,15 +113,30 @@ eth_dev_start(struct rte_eth_dev *dev)
static int
eth_dev_stop(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
dev->data->dev_started = 0;
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
return 0;
}
static int
eth_dev_set_link_down(struct rte_eth_dev *dev)
{
+ uint16_t i;
+
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 34/36] net/virtio: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/virtio/virtio_ethdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 2c23f1c00e25..3ab56ef769c9 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -2417,6 +2417,11 @@ virtio_dev_start(struct rte_eth_dev *dev)
set_rxtx_funcs(dev);
hw->started = 1;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
/* Initialize Link state */
virtio_dev_link_update(dev, 0);
@@ -2506,6 +2511,7 @@ virtio_dev_stop(struct rte_eth_dev *dev)
struct virtio_hw *hw = dev->data->dev_private;
struct rte_eth_link link;
struct rte_eth_intr_conf *intr_conf = &dev->data->dev_conf.intr_conf;
+ uint16_t i;
PMD_INIT_LOG(DEBUG, "stop");
dev->data->dev_started = 0;
@@ -2533,6 +2539,11 @@ virtio_dev_stop(struct rte_eth_dev *dev)
out_unlock:
rte_spinlock_unlock(&hw->state_lock);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 30/36] net/sfc: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/sfc/sfc_repr.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/sfc/sfc_repr.c b/drivers/net/sfc/sfc_repr.c
index 6c7727d56980..278e37477530 100644
--- a/drivers/net/sfc/sfc_repr.c
+++ b/drivers/net/sfc/sfc_repr.c
@@ -263,6 +263,7 @@ static int
sfc_repr_dev_start(struct rte_eth_dev *dev)
{
struct sfc_repr *sr = sfc_repr_by_eth_dev(dev);
+ uint16_t i;
int ret;
sfcr_info(sr, "entry");
@@ -274,6 +275,11 @@ sfc_repr_dev_start(struct rte_eth_dev *dev)
if (ret != 0)
goto fail_start;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
sfcr_info(sr, "done");
return 0;
@@ -338,6 +344,7 @@ static int
sfc_repr_dev_stop(struct rte_eth_dev *dev)
{
struct sfc_repr *sr = sfc_repr_by_eth_dev(dev);
+ uint16_t i;
int ret;
sfcr_info(sr, "entry");
@@ -352,6 +359,11 @@ sfc_repr_dev_stop(struct rte_eth_dev *dev)
sfc_repr_unlock(sr);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
sfcr_info(sr, "done");
return 0;
--
2.30.0
[PATCH 31/36] net/softnic: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/softnic/rte_eth_softnic.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/softnic/rte_eth_softnic.c
b/drivers/net/softnic/rte_eth_softnic.c
index bcf6664460a1..1b90cf7a21ee 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -134,6 +134,7 @@ pmd_dev_start(struct rte_eth_dev *dev)
{
struct pmd_internals *p = dev->data->dev_private;
int status;
+ uint16_t i;
/* Firmware */
status = softnic_cli_script_process(p,
@@ -146,6 +147,11 @@ pmd_dev_start(struct rte_eth_dev *dev)
/* Link UP */
dev->data->dev_link.link_status = RTE_ETH_LINK_UP;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -153,6 +159,7 @@ static int
pmd_dev_stop(struct rte_eth_dev *dev)
{
struct pmd_internals *p = dev->data->dev_private;
+ uint16_t i;
/* Link DOWN */
dev->data->dev_link.link_status = RTE_ETH_LINK_DOWN;
@@ -163,6 +170,11 @@ pmd_dev_stop(struct rte_eth_dev *dev)
softnic_softnic_swq_free_keep_rxq_txq(p);
softnic_mempool_free(p);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 32/36] net/txgbe: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/txgbe/txgbe_rxtx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/txgbe/txgbe_rxtx.c b/drivers/net/txgbe/txgbe_rxtx.c
index 427f8b82ac80..f4be2bb91c78 100644
--- a/drivers/net/txgbe/txgbe_rxtx.c
+++ b/drivers/net/txgbe/txgbe_rxtx.c
@@ -2805,6 +2805,8 @@ txgbe_dev_clear_queues(struct rte_eth_dev *dev)
txq->ops->release_mbufs(txq);
txq->ops->reset(txq);
}
+
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -2814,6 +2816,8 @@ txgbe_dev_clear_queues(struct rte_eth_dev *dev)
txgbe_rx_queue_release_mbufs(rxq);
txgbe_reset_rx_queue(adapter, rxq);
}
+
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
}
}
@@ -5004,6 +5008,8 @@ txgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
} while (--poll_ms && !(txdctl & TXGBE_TXCFG_ENA));
if (!poll_ms)
PMD_INIT_LOG(ERR, "Could not enable Tx Queue %d", i);
+ else
+ dev->data->tx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STARTED;
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
rxq = dev->data->rx_queues[i];
@@ -5018,6 +5024,8 @@ txgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
} while (--poll_ms && !(rxdctl & TXGBE_RXCFG_ENA));
if (!poll_ms)
PMD_INIT_LOG(ERR, "Could not enable Rx Queue %d", i);
+ else
+ dev->data->rx_queue_state[i] =
RTE_ETH_QUEUE_STATE_STARTED;
rte_wmb();
wr32(hw, TXGBE_RXWP(i), rxq->nb_rx_desc - 1);
}
--
2.30.0
[PATCH 35/36] net/vmxnet3: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 76e80e302519..e49191718aea 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1048,6 +1048,7 @@ vmxnet3_dev_start(struct rte_eth_dev *dev)
{
int ret;
struct vmxnet3_hw *hw = dev->data->dev_private;
+ uint16_t i;
PMD_INIT_FUNC_TRACE();
@@ -1151,6 +1152,11 @@ vmxnet3_dev_start(struct rte_eth_dev *dev)
*/
__vmxnet3_dev_link_update(dev, 0);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return VMXNET3_SUCCESS;
}
@@ -1163,6 +1169,7 @@ vmxnet3_dev_stop(struct rte_eth_dev *dev)
struct rte_eth_link link;
struct vmxnet3_hw *hw = dev->data->dev_private;
struct rte_intr_handle *intr_handle = dev->intr_handle;
+ uint16_t i;
int ret;
PMD_INIT_FUNC_TRACE();
@@ -1218,6 +1225,11 @@ vmxnet3_dev_stop(struct rte_eth_dev *dev)
hw->adapter_stopped = 1;
dev->data->dev_started = 0;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 33/36] net/vhost: fix Rx and Tx queue state
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/vhost/rte_eth_vhost.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 8d37ec977545..d53b8c2cd1fc 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1135,6 +1135,7 @@ eth_dev_start(struct rte_eth_dev *eth_dev)
{
struct pmd_internal *internal = eth_dev->data->dev_private;
struct rte_eth_conf *dev_conf = ð_dev->data->dev_conf;
+ uint16_t i;
eth_vhost_uninstall_intr(eth_dev);
if (dev_conf->intr_conf.rxq && eth_vhost_install_intr(eth_dev) < 0) {
@@ -1150,6 +1151,11 @@ eth_dev_start(struct rte_eth_dev *eth_dev)
rte_atomic32_set(&internal->started, 1);
update_queuing_status(eth_dev, false);
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++)
+ eth_dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < eth_dev->data->nb_tx_queues; i++)
+ eth_dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
return 0;
}
@@ -1157,11 +1163,17 @@ static int
eth_dev_stop(struct rte_eth_dev *dev)
{
struct pmd_internal *internal = dev->data->dev_private;
+ uint16_t i;
dev->data->dev_started = 0;
rte_atomic32_set(&internal->started, 0);
update_queuing_status(dev, true);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
return 0;
}
--
2.30.0
[PATCH 36/36] app/testpmd: fix primary process not polling all queues
Here's how the problem arises.
step1: Start the app.
dpdk-testpmd -a :35:00.0 -l 0-3 -- -i --rxq=10 --txq=10
step2: Perform the following steps and send traffic. As expected,
queue 7 does not send or receive packets, and other queues do.
port 0 rxq 7 stop
port 0 txq 7 stop
set fwd mac
start
step3: Perform the following steps and send traffic. All queues
are expected to send and receive packets normally, but that's not
the case for queue 7.
stop
port stop all
port start all
start
show port xstats all
In fact, only the value of rx_q7_packets for queue 7 is not zero,
which means queue 7 is enabled for the driver but is not involved
in packet receiving and forwarding by software. If we check queue
state by command 'show rxq info 0 7' and 'show txq info 0 7',
we see queue 7 is started as other queues are.
Rx queue state: started
Tx queue state: started
The queue 7 is started but cannot forward. That's the problem.
We know that each stream has a read-only "disabled" field that
control if this stream should be used to forward. This field
depends on testpmd local queue state, please see
commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
DPDK framework maintains ethdev queue state that drivers reported,
which indicates the real state of queues.
There are commands that update these two kind queue state such as
'port X rxq|txq start|stop'. But these operations take effect only
in one stop-start round. In the following stop-start round, the
preceding operations do not take effect anymore. However, only
the ethdev queue state is updated, causing the testpmd and ethdev
state information to diverge and causing unexpected side effects
as above problem.
There was a similar problem for the secondary process, please see
commit 5028f207a4fa ("app/testpmd: fix secondary process packet
forwarding").
This patch applies its workaround with some difference to the
primary process. Not all PMDs implement rte_eth_rx_queue_info_get and
rte_eth_tx_queue_info_get, however they may support deferred_start
with primary process. To not break their behavior, retain the original
testpmd local queue state for those PMDs.
Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Acked-by: Ferruh Yigit
---
app/test-pmd/testpmd.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 938ca035d4f8..079ef3392014 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2424,6 +2424,13 @@ update_rx_queue_state(uint16_t port_id, uint16_t
queue_id)
ports[port_id].rxq[queue_id].state =
rx_qinfo.queue_state;
} else if (rc == -ENOTSUP) {
+ /*
+* Do not change the rxq state for primary process
+* to ensure that the PMDs do not implement
+* rte_eth_rx_queue_info_get can forward as before.
+*/
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ return;
/*
* Set the rxq state to RTE_ETH_QUEUE_STATE_STARTED
* to ensure that the PMDs do not implement
@@ -2449,6 +2456,13 @@ update_tx_queue_state(uint16_t port_id, uint16_t
queue_id)
ports[port_id].txq[queue_id].state =
tx_qinfo.queue_state;
} else if (rc == -ENOTSUP) {
+ /*
+* Do not change the txq state for primary process
+* to ensure that the PMDs do not implement
+* rte_eth_tx_queue_info_get can forward as before.
+*/
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ return;
/*
* Set the txq state to RTE_ETH_QUEUE_STATE_STARTED
* to ensure that the PMDs do not implement
@@ -2463,12 +2477,15 @@ update_tx_queue_state(uint16_t port_id, uint16_t
queue_id)
}
static void
-update_queue_state(void)
+update_queue_state(portid_t pid)
{
portid_t pi;
queueid_t qi;
RTE_ETH_FOREACH_DEV(pi) {
+ if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
+ continue;
+
for (qi = 0; qi < nb_rxq; qi++)
update_rx_queue_state(pi, qi);
for (qi = 0; qi < nb_txq; qi++)
@@ -2516,8 +2533,7 @@ start_packet_forwarding(int with_tx_first)
return;
if (stream_init != NULL) {
- if (rte_eal_process_type() == RTE_PROC_SECONDARY)
- update_queue_state();
+ update_queue_state(RTE_PORT_ALL);
for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
stream_init(fwd_streams[i]);
}
@@ -3280,8 +3296,7 @@ start_port(portid_t pid)
pl[cfg_pi++] = pi;
}
-
Re: [PATCH 00/36] fix Rx and Tx queue state
On Fri, Sep 8, 2023 at 1:32 PM Jie Hai wrote:
>
> The DPDK framework reports the queue state, which is stored in
> dev->data->tx_queue_state and dev->data->rx_queue_state. The
> state is maintained by the driver. Users may determine whether
> a queue participates in packet forwarding based on the state,
> for example,
The driver is maintaining this state in dev_start / dev_stop and per
queue start/stop handlers.
>
> [1] 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding"
> [2] 141a520b35f7 ("app/testpmd: fix primary process not polling all queues")
>
> Therefore, the drivers need to modify the queue state in time
> according to the actual situation, especially when dev_start
> and dev_stop are called. see [3] for more information.
>
> [3] https://inbox.dpdk.org/dev/20230721160422.3848154-1-ferruh.yi...@amd.com/
>
> This patchset also resubmit the patch [2] and makes some fixes on the patch.
I just had a quick look at some patches and I wonder if a better fix
would be at the ethdev level, rather than fixing all drivers.
--
David Marchand
[PATCH 1/3] pdcp: add support for SDAP header
SDAP header when enabled needs to be authenticated but not encrypted.
Signed-off-by: Aakash Sasidharan
---
lib/pdcp/pdcp_entity.h | 2 ++
lib/pdcp/pdcp_process.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/lib/pdcp/pdcp_entity.h b/lib/pdcp/pdcp_entity.h
index 9f74b5d0e5..4fc6342a5c 100644
--- a/lib/pdcp/pdcp_entity.h
+++ b/lib/pdcp/pdcp_entity.h
@@ -171,6 +171,8 @@ struct entity_priv {
uint8_t hdr_sz;
/** PDCP AAD size. For AES-CMAC, additional message is prepended for
the operation. */
uint8_t aad_sz;
+ /** PDCP cipher skip size. When enabled, SDAP header needs to be
skipped from ciphering */
+ uint8_t cipher_skip_sz;
/** Device ID of the device to be used for offload. */
uint8_t dev_id;
};
diff --git a/lib/pdcp/pdcp_process.c b/lib/pdcp/pdcp_process.c
index c2f28d4d77..9b9b881124 100644
--- a/lib/pdcp/pdcp_process.c
+++ b/lib/pdcp/pdcp_process.c
@@ -391,7 +391,7 @@ pdcp_pre_process_uplane_sn_12_ul(const struct
rte_pdcp_entity *entity, struct rt
uint8_t *mac_i;
int i;
- const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
const int is_null_auth = en_priv->flags.is_null_auth;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
@@ -477,7 +477,7 @@ pdcp_pre_process_uplane_sn_18_ul(const struct
rte_pdcp_entity *entity, struct rt
uint8_t *mac_i;
int i;
- const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
const int is_null_auth = en_priv->flags.is_null_auth;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
@@ -540,7 +540,7 @@ pdcp_pre_process_cplane_sn_12_ul(const struct
rte_pdcp_entity *entity, struct rt
int i;
const uint8_t hdr_sz = en_priv->hdr_sz;
- const uint8_t data_offset = hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
const int is_null_auth = en_priv->flags.is_null_auth;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
@@ -658,7 +658,7 @@ pdcp_pre_process_uplane_sn_12_dl_flags(const struct
rte_pdcp_entity *entity,
uint32_t count;
int i;
- const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
num);
@@ -727,7 +727,7 @@ pdcp_pre_process_uplane_sn_18_dl_flags(const struct
rte_pdcp_entity *entity,
uint32_t count;
int i;
- const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
num);
@@ -795,7 +795,7 @@ pdcp_pre_process_cplane_sn_12_dl(const struct
rte_pdcp_entity *entity, struct rt
int32_t rsn;
int i;
- const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz;
+ const uint8_t data_offset = en_priv->hdr_sz + en_priv->aad_sz +
en_priv->cipher_skip_sz;
nb_cop = rte_crypto_op_bulk_alloc(en_priv->cop_pool,
RTE_CRYPTO_OP_TYPE_SYMMETRIC, cop,
num);
@@ -1202,6 +1202,16 @@ pdcp_entity_priv_populate(struct entity_priv *en_priv,
const struct rte_pdcp_ent
else
en_priv->aad_sz = 0;
+ /**
+* cipher_skip_sz
+*
+* When SDAP protocol is enabled for the PDCP entity, skip the SDAP
header from ciphering.
+*/
+ if (conf->pdcp_xfrm.sdap_enabled)
+ en_priv->cipher_skip_sz = 1;
+ else
+ en_priv->cipher_skip_sz = 0;
+
return 0;
}
--
2.25.1
[PATCH 2/3] test/pdcp: add SDAP test cases
Add PDCP SDAP test cases.
Signed-off-by: Aakash Sasidharan
---
app/test/test_pdcp.c | 438 +++
1 file changed, 397 insertions(+), 41 deletions(-)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index 6c73c1db36..9c9e7a51fc 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -15,6 +15,7 @@
#include "test.h"
#include "test_cryptodev.h"
+#include "test_cryptodev_security_pdcp_sdap_test_vectors.h"
#include "test_cryptodev_security_pdcp_test_vectors.h"
#define NSECPERSEC 1E9
@@ -23,7 +24,8 @@
#define TEST_EV_QUEUE_ID 0
#define TEST_EV_PORT_ID 0
#define CDEV_INVALID_ID UINT8_MAX
-#define NB_TESTS RTE_DIM(pdcp_test_params)
+#define NB_BASIC_TESTS RTE_DIM(pdcp_test_params)
+#define NB_SDAP_TESTS RTE_DIM(list_pdcp_sdap_tests)
#define PDCP_IV_LEN 16
/* Assert that condition is true, or goto the mark */
@@ -72,24 +74,71 @@ struct pdcp_test_conf {
uint32_t output_len;
};
-static int create_test_conf_from_index(const int index, struct pdcp_test_conf
*conf);
+enum pdcp_test_suite_type {
+ PDCP_TEST_SUITE_TY_BASIC,
+ PDCP_TEST_SUITE_TY_SDAP,
+};
+
+static int create_test_conf_from_index(const int index, struct pdcp_test_conf
*conf,
+ enum pdcp_test_suite_type suite_type);
typedef int (*test_with_conf_t)(struct pdcp_test_conf *conf);
+static uint32_t
+nb_tests_get(enum pdcp_test_suite_type type)
+{
+ uint32_t ret;
+
+ switch (type) {
+ case PDCP_TEST_SUITE_TY_BASIC:
+ ret = NB_BASIC_TESTS;
+ break;
+ case PDCP_TEST_SUITE_TY_SDAP:
+ ret = NB_SDAP_TESTS;
+ break;
+ default:
+ return 0;
+ }
+
+ return ret;
+}
+
+static const char*
+pdcp_test_name_get(enum pdcp_test_suite_type type, int idx)
+{
+ const char *test_name = NULL;
+
+ switch (type) {
+ case PDCP_TEST_SUITE_TY_BASIC:
+ test_name = pdcp_test_params[idx].name;
+ break;
+ case PDCP_TEST_SUITE_TY_SDAP:
+ test_name = list_pdcp_sdap_tests[idx].param.name;
+ break;
+ default:
+ return NULL;
+ }
+
+ return test_name;
+}
+
static int
-run_test_foreach_known_vec(test_with_conf_t test, bool stop_on_first_pass)
+run_test_foreach_known_vec(test_with_conf_t test, bool stop_on_first_pass,
+ enum pdcp_test_suite_type suite_type)
{
struct pdcp_test_conf test_conf;
bool all_tests_skipped = true;
+ uint32_t nb_tests = nb_tests_get(suite_type);
uint32_t i;
int ret;
- for (i = 0; i < NB_TESTS; i++) {
- create_test_conf_from_index(i, &test_conf);
+ for (i = 0; i < nb_tests; i++) {
+ create_test_conf_from_index(i, &test_conf, suite_type);
ret = test(&test_conf);
if (ret == TEST_FAILED) {
- printf("[%03i] - %s - failed\n", i,
pdcp_test_params[i].name);
+ printf("[%03i] - %s - failed\n", i,
+ pdcp_test_name_get(suite_type, i));
return TEST_FAILED;
}
@@ -113,7 +162,17 @@ run_test_with_all_known_vec(const void *args)
{
test_with_conf_t test = args;
- return run_test_foreach_known_vec(test, false);
+ return run_test_foreach_known_vec(test, false,
+ PDCP_TEST_SUITE_TY_BASIC);
+}
+
+static int
+run_test_with_all_sdap_known_vec(const void *args)
+{
+ test_with_conf_t test = args;
+
+ return run_test_foreach_known_vec(test, false,
+ PDCP_TEST_SUITE_TY_SDAP);
}
static int
@@ -121,7 +180,8 @@ run_test_with_all_known_vec_until_first_pass(const void
*args)
{
test_with_conf_t test = args;
- return run_test_foreach_known_vec(test, true);
+ return run_test_foreach_known_vec(test, true,
+ PDCP_TEST_SUITE_TY_BASIC);
}
static inline uint32_t
@@ -522,13 +582,296 @@ pdcp_sn_to_raw_set(void *data, uint32_t sn, int size)
}
}
+static uint8_t
+pdcp_test_bearer_get(enum pdcp_test_suite_type suite_type, const int index)
+{
+ uint8_t ret;
+
+ switch (suite_type) {
+ case PDCP_TEST_SUITE_TY_BASIC:
+ ret = pdcp_test_bearer[index];
+ break;
+ case PDCP_TEST_SUITE_TY_SDAP:
+ ret = list_pdcp_sdap_tests[index].bearer;
+ break;
+ default:
+ RTE_LOG(ERR, USER1, "Invalid suite_type: %d\n", suite_type);
+ ret = -1;
+
+ }
+
+ return ret;
+}
+
+static enum rte_security_pdcp_domain
+pdcp_test_param_domain_get(enum pdcp_test_suite_type suite_type, const int
index)
+{
+ enum rte_security_pdcp_domain ret;
+
+ switch (suite_type) {
+ case PDCP_TEST_SUITE_TY_BASIC:
+
[PATCH 3/3] test/pdcp: add SDAP combined mode tests
Add PDCP SDAP combined mode tests.
Signed-off-by: Aakash Sasidharan
---
app/test/test_pdcp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/app/test/test_pdcp.c b/app/test/test_pdcp.c
index 9c9e7a51fc..5f8ec08e32 100644
--- a/app/test/test_pdcp.c
+++ b/app/test/test_pdcp.c
@@ -2275,6 +2275,9 @@ static struct unit_test_suite sdap_test_cases = {
TEST_CASE_NAMED_WITH_DATA("SDAP Known vector cases",
ut_setup_pdcp, ut_teardown_pdcp,
run_test_with_all_sdap_known_vec, test_attempt_single),
+ TEST_CASE_NAMED_WITH_DATA("SDAP combined mode",
+ ut_setup_pdcp, ut_teardown_pdcp,
+ run_test_with_all_sdap_known_vec, test_combined),
TEST_CASES_END() /**< NULL terminate unit test array */
}
};
--
2.25.1
Re: [PATCH 30/36] net/sfc: fix Rx and Tx queue state
On 9/8/23 14:28, Jie Hai wrote:
The DPDK framework reports the queue state, which is stored in
dev->data->tx_queue_state and dev->data->rx_queue_state. The
state is maintained by the driver. Users may determine whether
a queue participates in packet forwarding based on the state.
Therefore, the driver needs to modify the queue state in time
according to the actual situation.
Fixes: 9ad9ff476cac ("ethdev: add queue state in queried queue information")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
---
drivers/net/sfc/sfc_repr.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/sfc/sfc_repr.c b/drivers/net/sfc/sfc_repr.c
index 6c7727d56980..278e37477530 100644
--- a/drivers/net/sfc/sfc_repr.c
+++ b/drivers/net/sfc/sfc_repr.c
@@ -263,6 +263,7 @@ static int
sfc_repr_dev_start(struct rte_eth_dev *dev)
{
struct sfc_repr *sr = sfc_repr_by_eth_dev(dev);
+ uint16_t i;
int ret;
sfcr_info(sr, "entry");
@@ -274,6 +275,11 @@ sfc_repr_dev_start(struct rte_eth_dev *dev)
if (ret != 0)
goto fail_start;
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
May be I miss something, but the driver does when queue is
really started in sfc_rx_qstart() and sfc_tx_qstart().
Also the patch is wrong in general in the case of deferred
start queues.
Same for stop.
+
sfcr_info(sr, "done");
return 0;
@@ -338,6 +344,7 @@ static int
sfc_repr_dev_stop(struct rte_eth_dev *dev)
{
struct sfc_repr *sr = sfc_repr_by_eth_dev(dev);
+ uint16_t i;
int ret;
sfcr_info(sr, "entry");
@@ -352,6 +359,11 @@ sfc_repr_dev_stop(struct rte_eth_dev *dev)
sfc_repr_unlock(sr);
+ for (i = 0; i < dev->data->nb_rx_queues; i++)
+ dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+ for (i = 0; i < dev->data->nb_tx_queues; i++)
+ dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED;
+
sfcr_info(sr, "done");
return 0;
[PATCH v4 0/2] fix memory initialization deadlock
The issue arose due to the change in the DPDK read-write lock implementation. That change added a new flag, RTE_RWLOCK_WAIT, designed to prevent new read locks while a write lock is in the queue. However, this change has led to a scenario where a recursive read lock, where a lock is acquired twice by the same execution thread, can initiate a sequence of events resulting in a deadlock: Process 1 takes the first read lock. Process 2 attempts to take a write lock, triggering RTE_RWLOCK_WAIT due to the presence of a read lock. This makes process 2 enter a wait loop until the read lock is released. Process 1 tries to take a second read lock. However, since a write lock is waiting (due to RTE_RWLOCK_WAIT), it also enters a wait loop until the write lock is acquired and then released. Both processes end up in a blocked state, unable to proceed, resulting in a deadlock scenario. Following these changes, the RW-lock no longer supports recursion, implying that a single thread shouldn't obtain a read lock if it already possesses one. The problem arises during initialization: the rte_eal_init() function acquires the memory_hotplug_lock, and later on, there are sequences of calls leading to rte_memseg_list_walk() which acquires it again without releasing it. This scenario introduces the risk of a potential deadlock when concurrent write locks are applied to the same memory_hotplug_lock. To address this we resolved the issue by replacing rte_memseg_list_walk() with rte_memseg_list_walk_thread_unsafe(). Implementing a lock annotation for rte_memseg_list_walk() to proactively identify bugs similar to this one during compile time. Artemy Kovalyov (2): eal: fix memory initialization deadlock eal: annotate rte_memseg_list_walk() lib/eal/common/eal_common_dynmem.c | 5 - lib/eal/common/eal_memalloc.h | 3 ++- lib/eal/common/eal_private.h | 3 ++- lib/eal/include/generic/rte_rwlock.h | 4 lib/eal/include/rte_lock_annotations.h | 5 + lib/eal/include/rte_memory.h | 4 +++- lib/eal/linux/eal_memalloc.c | 7 +-- 7 files changed, 25 insertions(+), 6 deletions(-) -- 1.8.3.1
[PATCH v4 1/2] eal: fix memory initialization deadlock
The issue arose due to changes in the DPDK read-write lock
implementation. Following these changes, the RW-lock no longer supports
recursion, implying that a single thread shouldn't obtain a read lock if
it already possesses one. The problem arises during initialization: the
rte_eal_init() function acquires the memory_hotplug_lock, and later on,
there are sequences of calls that acquire it again without releasing it.
* rte_eal_memory_init() -> eal_memalloc_init() -> rte_memseg_list_walk()
* rte_eal_memory_init() -> rte_eal_hugepage_init() ->
eal_dynmem_hugepage_init() -> rte_memseg_list_walk()
This scenario introduces the risk of a potential deadlock when concurrent
write locks are applied to the same memory_hotplug_lock. To address this
locally, we resolved the issue by replacing rte_memseg_list_walk() with
rte_memseg_list_walk_thread_unsafe().
Bugzilla ID: 1277
Fixes: 832cecc03d77 ("rwlock: prevent readers from starving writers")
Cc: sta...@dpdk.org
Signed-off-by: Artemy Kovalyov
---
lib/eal/common/eal_common_dynmem.c | 5 -
lib/eal/include/generic/rte_rwlock.h | 4
lib/eal/linux/eal_memalloc.c | 7 +--
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/eal/common/eal_common_dynmem.c
b/lib/eal/common/eal_common_dynmem.c
index bdbbe23..95da55d 100644
--- a/lib/eal/common/eal_common_dynmem.c
+++ b/lib/eal/common/eal_common_dynmem.c
@@ -251,7 +251,10 @@
*/
memset(&dummy, 0, sizeof(dummy));
dummy.hugepage_sz = hpi->hugepage_sz;
- if (rte_memseg_list_walk(hugepage_count_walk, &dummy) < 0)
+ /* memory_hotplug_lock is held during initialization, so it's
+* safe to call thread-unsafe version.
+*/
+ if (rte_memseg_list_walk_thread_unsafe(hugepage_count_walk,
&dummy) < 0)
return -1;
for (i = 0; i < RTE_DIM(dummy.num_pages); i++) {
diff --git a/lib/eal/include/generic/rte_rwlock.h
b/lib/eal/include/generic/rte_rwlock.h
index 9e083bb..c98fc7d 100644
--- a/lib/eal/include/generic/rte_rwlock.h
+++ b/lib/eal/include/generic/rte_rwlock.h
@@ -80,6 +80,10 @@
/**
* Take a read lock. Loop until the lock is held.
*
+ * @note The RW lock isn't recursive, so calling this function on the same
+ * lock twice without releasing it could potentially result in a deadlock
+ * scenario when a write lock is involved.
+ *
* @param rwl
* A pointer to a rwlock structure.
*/
diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index f8b1588..9853ec7 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -1740,7 +1740,10 @@ struct rte_memseg *
eal_get_internal_configuration();
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
- if (rte_memseg_list_walk(secondary_msl_create_walk, NULL) < 0)
+ /* memory_hotplug_lock is held during initialization, so it's
+* safe to call thread-unsafe version.
+*/
+ if
(rte_memseg_list_walk_thread_unsafe(secondary_msl_create_walk, NULL) < 0)
return -1;
if (rte_eal_process_type() == RTE_PROC_PRIMARY &&
internal_conf->in_memory) {
@@ -1778,7 +1781,7 @@ struct rte_memseg *
}
/* initialize all of the fd lists */
- if (rte_memseg_list_walk(fd_list_create_walk, NULL))
+ if (rte_memseg_list_walk_thread_unsafe(fd_list_create_walk, NULL))
return -1;
return 0;
}
--
1.8.3.1
[PATCH v4 2/2] eal: annotate rte_memseg_list_walk()
Implementing a lock annotation for rte_memseg_list_walk() to
proactively identify bugs similar to memory_hotplug_lock deadlock during
initialization during compile time.
Bugzilla ID: 1277
Signed-off-by: Artemy Kovalyov
---
lib/eal/common/eal_memalloc.h | 3 ++-
lib/eal/common/eal_private.h | 3 ++-
lib/eal/include/rte_lock_annotations.h | 5 +
lib/eal/include/rte_memory.h | 4 +++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/lib/eal/common/eal_memalloc.h b/lib/eal/common/eal_memalloc.h
index ebc3a6f..286ffb7 100644
--- a/lib/eal/common/eal_memalloc.h
+++ b/lib/eal/common/eal_memalloc.h
@@ -91,7 +91,8 @@ struct rte_memseg *
eal_memalloc_get_seg_fd_offset(int list_idx, int seg_idx, size_t *offset);
int
-eal_memalloc_init(void);
+eal_memalloc_init(void)
+ __rte_shared_locks_required(rte_mcfg_mem_get_lock());
int
eal_memalloc_cleanup(void);
diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h
index 5eadba4..ebd496b 100644
--- a/lib/eal/common/eal_private.h
+++ b/lib/eal/common/eal_private.h
@@ -115,7 +115,8 @@ struct rte_config {
* @return
* 0 on success, negative on error
*/
-int rte_eal_memory_init(void);
+int rte_eal_memory_init(void)
+ __rte_shared_locks_required(rte_mcfg_mem_get_lock());
/**
* Configure timers
diff --git a/lib/eal/include/rte_lock_annotations.h
b/lib/eal/include/rte_lock_annotations.h
index 9fc5008..2456a69 100644
--- a/lib/eal/include/rte_lock_annotations.h
+++ b/lib/eal/include/rte_lock_annotations.h
@@ -40,6 +40,9 @@
#define __rte_unlock_function(...) \
__attribute__((unlock_function(__VA_ARGS__)))
+#define __rte_locks_excluded(...) \
+ __attribute__((locks_excluded(__VA_ARGS__)))
+
#define __rte_no_thread_safety_analysis \
__attribute__((no_thread_safety_analysis))
@@ -62,6 +65,8 @@
#define __rte_unlock_function(...)
+#define __rte_locks_excluded(...)
+
#define __rte_no_thread_safety_analysis
#endif /* RTE_ANNOTATE_LOCKS */
diff --git a/lib/eal/include/rte_memory.h b/lib/eal/include/rte_memory.h
index 3a1c607..842362d 100644
--- a/lib/eal/include/rte_memory.h
+++ b/lib/eal/include/rte_memory.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#define RTE_PGSIZE_4K (1ULL << 12)
@@ -250,7 +251,8 @@ typedef int (*rte_memseg_list_walk_t)(const struct
rte_memseg_list *msl,
* -1 if user function reported error
*/
int
-rte_memseg_list_walk(rte_memseg_list_walk_t func, void *arg);
+rte_memseg_list_walk(rte_memseg_list_walk_t func, void *arg)
+ __rte_locks_excluded(rte_mcfg_mem_get_lock());
/**
* Walk list of all memsegs without performing any locking.
--
1.8.3.1
RE: [PATCH 2/2] event/sw: fix ordering corruption with op release
> -Original Message- > From: Richardson, Bruce > Sent: Monday, September 4, 2023 5:38 PM > To: Van Haaren, Harry > Cc: dev@dpdk.org > Subject: Re: [PATCH 2/2] event/sw: fix ordering corruption with op release > > drivers/event/sw/sw_evdev_scheduler.c | 45 --- > > 1 file changed, 27 insertions(+), 18 deletions(-) > > > Hi Harry, > > wondering if this fix might work as well, and offer a simpler alternative. > We can instead zero all unspecified hist-list entries on write. Ah, interesting approach. Will investigate and spin a v2 (with order inverted) if this approach proves to be a better fit.
Re: [PATCH v2 2/2] random: make rte_rand() thread safe for non-EAL threads
On 2023-09-07 17:24, Stephen Hemminger wrote:
Add missing locking so that if two non-EAL threads call rte_rand()
they will not corrupt the per-thread state.
Fixes: 3f002f069612 ("eal: replace libc-based random generation with LFSR")
The API documentation clearly states that no MT safety guarantees are
given for unregistered non-EAL threads. So this patch doesn't fix anything.
rte_rand() is MT safe for *registered* non-EAL threads.
Signed-off-by: Stephen Hemminger
---
lib/eal/common/rte_random.c | 54 -
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
index 812e5b4757b5..02b6b6b97bc0 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
struct rte_rand_state {
@@ -21,6 +22,9 @@ struct rte_rand_state {
uint64_t z5;
} __rte_cache_aligned;
+/* Used for thread safety for non EAL threads. */
+static rte_spinlock_t rte_rand_lock = RTE_SPINLOCK_INITIALIZER;
+
/* One instance each for every lcore id-equipped thread, and one
* additional instance to be shared by all others threads (i.e., all
* unregistered non-EAL threads).
@@ -124,20 +128,32 @@ struct rte_rand_state *__rte_rand_get_state(void)
idx = rte_lcore_id();
/* last instance reserved for unregistered non-EAL threads */
- if (unlikely(idx == LCORE_ID_ANY))
+ if (unlikely(idx == LCORE_ID_ANY)) {
idx = RTE_MAX_LCORE;
+ rte_spinlock_lock(&rte_rand_lock);
Non-EAL threads are very likely to be "regular" threads, which won't
have a dedicated core all for themselves, and thus may well be preempted
by the kernel. Such threads should not use spinlocks.
If a lock is to be added to achieve MT safety for parallel calls from
unregistered non-EAL threads, it should be a regular mutex.
+ }
return &rand_states[idx];
}
+static __rte_always_inline
+void __rte_rand_put_state(struct rte_rand_state *state)
+{
+ if (state == &rand_states[RTE_MAX_LCORE])
+ rte_spinlock_unlock(&rte_rand_lock);
+}
+
uint64_t
rte_rand(void)
{
struct rte_rand_state *state;
+ uint64_t res;
state = __rte_rand_get_state();
+ res = __rte_rand_lfsr258(state);
+ __rte_rand_put_state(state);
- return __rte_rand_lfsr258(state);
+ return res;
}
uint64_t
@@ -159,22 +175,24 @@ rte_rand_max(uint64_t upper_bound)
/* Handle power-of-2 upper_bound as a special case, since it
* has no bias issues.
*/
- if (unlikely(ones == 1))
- return __rte_rand_lfsr258(state) & (upper_bound - 1);
-
- /* The approach to avoiding bias is to create a mask that
-* stretches beyond the request value range, and up to the
-* next power-of-2. In case the masked generated random value
-* is equal to or greater than the upper bound, just discard
-* the value and generate a new one.
-*/
-
- leading_zeros = rte_clz64(upper_bound);
- mask >>= leading_zeros;
-
- do {
- res = __rte_rand_lfsr258(state) & mask;
- } while (unlikely(res >= upper_bound));
+ if (unlikely(ones == 1)) {
+ res = __rte_rand_lfsr258(state) & (upper_bound - 1);
+ } else {
+ /* The approach to avoiding bias is to create a mask that
+* stretches beyond the request value range, and up to the
+* next power-of-2. In case the masked generated random value
+* is equal to or greater than the upper bound, just discard
+* the value and generate a new one.
+*/
+
+ leading_zeros = rte_clz64(upper_bound);
+ mask >>= leading_zeros;
+
+ do {
+ res = __rte_rand_lfsr258(state) & mask;
+ } while (unlikely(res >= upper_bound));
+ }
+ __rte_rand_put_state(state);
return res;
}
Re: [PATCH v2 2/2] random: make rte_rand() thread safe for non-EAL threads
On Fri, 8 Sep 2023 22:48:54 +0200
Mattias Rönnblom wrote:
> On 2023-09-07 17:24, Stephen Hemminger wrote:
> > Add missing locking so that if two non-EAL threads call rte_rand()
> > they will not corrupt the per-thread state.
> >
> > Fixes: 3f002f069612 ("eal: replace libc-based random generation with LFSR")
> >
>
> The API documentation clearly states that no MT safety guarantees are
> given for unregistered non-EAL threads. So this patch doesn't fix anything.
>
> rte_rand() is MT safe for *registered* non-EAL threads.
Reading the documentation, it only guarantees safety if registered.
We should add an otherwise clause rather than leaving case as undefined.
Re: [PATCH v2 1/5] ethdev: support setting and querying RSS algorithm
On Fri, 8 Sep 2023 17:28:08 +0800 Jie Hai wrote: > Hi, Stephen Hemminger > > On 2023/9/6 23:10, Stephen Hemminger wrote: > > On Sat, 26 Aug 2023 15:46:03 +0800 > > Jie Hai wrote: > > > >> Currently, rte_eth_rss_conf supports configuring and querying > >> rss hash functions, rss key and it's length, but not rss hash > >> algorithm. > >> > >> The structure ``rte_eth_rss_conf`` is extended by adding a new > >> field "func". This represents the RSS algorithms to apply. The > >> following API is affected: > >>- rte_eth_dev_configure > >>- rte_eth_dev_rss_hash_update > >>- rte_eth_dev_rss_hash_conf_get > >> > >> If the value of "func" used for configuration is a gibberish > >> value, report the error and return. Do the same for > >> rte_eth_dev_rss_hash_update and rte_eth_dev_configure. > >> > >> To check whether the drivers report the "func" field, it is set > >> to default value before querying. > >> > >> Signed-off-by: Jie Hai > >> Signed-off-by: Dongdong Liu > > > > This is unannounced API/ABI change. > Thanks for pointing that. I'm sorry I didn't pay attention to this before. > What should I do with this set of patches? > Is it feasible to send annouce now? Since this API/ABI breaking release, I am ok taking it. But will need a release note. Also you should treat 0 as "no change" case to allow for code that does hash_update without setting the value.
Re: [PATCH v2 1/5] ethdev: support setting and querying RSS algorithm
On Fri, Sep 8, 2023 at 1:44 AM Jie Hai wrote:
>
> Hi, Thomas
> Thanks for your review.
>
> On 2023/9/4 15:45, Thomas Monjalon wrote:
> > 04/09/2023 09:10, Jie Hai:
> >> On 2023/8/30 19:46, Thomas Monjalon wrote:
> >>> 26/08/2023 09:46, Jie Hai:
> > >> + * The *func* field of the *rss_conf* structure indicates the hash
> > algorithm
> + * applied by the RSS hashing. Passing RTE_ETH_HASH_FUNCTION_DEFAULT
> allows
> + * the PMD to use its best-effort algorithm rather than a specific one.
> */
> >>>
> >>> I don't like commenting a field on top of the structure.
> >>> By the way, the first sentence does not look helpful.
> >>> RTE_ETH_HASH_FUNCTION_DEFAULT may be explained in the enum.
> >>>
> >> Other fields above the structure 'rte_eth_rss_conf' have comments.
> >> If the new fields 'func' do not have comments, it may be misleading.
> >> Unless all the comments above are removed. I'm not sure whether to
> >> delete them or not.
> >
> > You should explain RTE_ETH_HASH_FUNCTION_DEFAULT in its enum.
> > The rest of the explanation can be on the struct field.
> > I'm OK to have another patch moving old explanations from the struct
> > to the fields.
> Fixed in V4, please check it.
> >
> struct rte_eth_rss_conf {
> uint8_t *rss_key;/**< If not NULL, 40-byte hash key. */
> uint8_t rss_key_len; /**< hash key length in bytes. */
> uint64_t rss_hf; /**< Hash functions to apply - see
> below. */
> + enum rte_eth_hash_function func;/**< Hash algorithm to apply.
> */
> >>>
> >>> You can drop "to apply" words.
> >> Fixed in V3.
> >>>
> >>> How the algorithms support combinations in rss_hf?
> >>>
> >> The rss_hf defines the input of the RSS hash algorithms.
> >> For example, rss_hf = RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_IPV4,
> >> these two kinds of packets can be dispatched to different queues
> >> according to their tuple field value.
> >> For ipv4-tcp packets, src-ip, dst-ip, src-port, dst-port are used as
> >> parameters of RSS hash algorithms to compute hash value.
> >> For ipv4 packets src-ip, dst-ip are used.
> >>
> >> If rss_hf = RTE_ETH_RSS_NONFRAG_IPV4_TCP | RTE_ETH_RSS_L4_SRC_ONLY, for
> >> ipv4-tcp packets, src-port is used as parameters of RSS hash algorithms
> >> to compute hash value.
> >
> > I know what is rss_hf.
> > My question is about the algorithms.
> > Do they all support any combination in rss_hf?
> >
> >
> I don't know about all vendors' hardware implementations,
> so here's just my simple opinion.
>
> Theoretically, I think that all algorithms should support all
> combinations in rss_hf, The reasons are as follows.
Leave it to the driver and hardware to decide what combinations can be
supported.
>
> 1. The rss_hf and algorithms are independent. For different algorithms
> and the same packets and hash key, the input parameters for different
> algorithms should be the same, which depends on implemetation of hardware.
>
> 2. As long as hardware and driver support, all packet types defined by
> rss_hf could generate the the input parameters for the algorithm to compute.
>
> Thanks,
> Jie Hai
> > .
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [RFC] random: use per lcore state
06/09/2023 21:02, Mattias Rönnblom пишет:
On 2023-09-06 19:20, Stephen Hemminger wrote:
Move the random number state into thread local storage.
Me and Morten discussed TLS versus other alternatives in some other
thread. The downside of TLS that Morten pointed out, from what I recall,
is that lazy initialization is *required* (since the number of threads
is open-ended), and the data ends up in non-huge page memory.
Hmm.. correct me if I am wrong, but with current implementation,
rand state is also in non-huge memory:
static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1];
It was
also unclear to me what the memory footprint implications would be,h
would large per-lcore data structures be put in TLS. More specifically,
if they would be duplicated across all threads, even non-lcore threads.
None of these issues affect rte_random.c's potential usage of TLS
(except lazy [re-]initialization makes things more complicated).
Preferably, there should be one pattern that is usable across all or at
least most DPDK modules requiring per-lcore state.
This has a several benefits.
- no false cache sharing from cpu prefetching
- fixes initialization of random state for non-DPDK threads
This seems like a non-reason to me. That bug is easily fixed, if it
isn't already.
- fixes unsafe usage of random state by non-DPDK threads
"Makes random number generation MT safe from all threads (including
unregistered non-EAL threads)."
With current API semantics you may still register an non-EAL thread, to
get MT safe access to this API, so I guess it's more about being more
convenient and less error prone, than anything else.
I understand that we never guaranteed MT safety for non-EAL threads here,
but as a user of rte_rand() - it would be much more convenient, if I can
use it
from any thread wthout worring is it a EAL thread or not.
About TlS usage and re-seeding - can we use some sort of middle-ground:
extend rte_rand_state with some gen-counter.
Make a 'master' copy of rte_rand_state that will be updated by rte_srand(),
and TLS copies of rte_rand_state, so rte_rand() can fist compare
its gen-counter value with master copy to decide,
does it need to copy new state from master or not.
The new MT safety guarantees should be in the API docs as well.
Yes, it is an extension to the current API, not a fix.
The initialization of random number state is done by the
lcore (lazy initialization).
Signed-off-by: Stephen Hemminger
---
lib/eal/common/rte_random.c | 38 +++--
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
index 53636331a27b..9657adf6ad3b 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -19,13 +19,14 @@ struct rte_rand_state {
uint64_t z3;
uint64_t z4;
uint64_t z5;
-} __rte_cache_aligned;
+ uint64_t seed;
+};
-/* One instance each for every lcore id-equipped thread, and one
- * additional instance to be shared by all others threads (i.e., all
- * unregistered non-EAL threads).
- */
-static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1];
+/* Global random seed */
+static uint64_t rte_rand_seed;
+
+/* Per lcore random state. */
+static RTE_DEFINE_PER_LCORE(struct rte_rand_state, rte_rand_state);
static uint32_t
__rte_rand_lcg32(uint32_t *seed)
@@ -81,11 +82,7 @@ __rte_srand_lfsr258(uint64_t seed, struct
rte_rand_state *state)
void
rte_srand(uint64_t seed)
{
- unsigned int lcore_id;
-
- /* add lcore_id to seed to avoid having the same sequence */
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
- __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
+ __atomic_store_n(&rte_rand_seed, seed, __ATOMIC_RELAXED);
}
static __rte_always_inline uint64_t
@@ -119,15 +116,18 @@ __rte_rand_lfsr258(struct rte_rand_state *state)
static __rte_always_inline
struct rte_rand_state *__rte_rand_get_state(void)
{
- unsigned int idx;
+ struct rte_rand_state *rand_state = &RTE_PER_LCORE(rte_rand_state);
There should really be a RTE_PER_THREAD, an alias to RTE_PER_LCORE, to
cover this usage. Or just use __thread (or _Thread_local?).
+ uint64_t seed;
- idx = rte_lcore_id();
+ seed = __atomic_load_n(&rte_rand_seed, __ATOMIC_RELAXED);
+ if (unlikely(seed != rand_state->seed)) {
+ rand_state->seed = seed;
Re-seeding should restart the series, on all lcores. There's nothing
preventing the user from re-seeding the machinery repeatedly, with the
same seed. Seems like an unusual, but still valid, use case, if you run
repeated tests of some sort.
Use a seqlock? :) I guess you need a seed generation number as well
(e.g., is this the first time you seed with X, or the second one, etc.)
- /* last instance reserved for unregistered non-EAL threads */
- if (unlikely(idx == LCORE_ID_ANY))
- idx = RTE_MAX_LCORE;
+ seed += rte_thread
RE: [EXT] [PATCH v3 1/1] app/graph: add example for different usecases
Please see inline. > -Original Message- > From: sk...@marvell.com > Sent: Friday, September 8, 2023 4:19 PM > To: Thomas Monjalon ; Sunil Kumar Kori > ; > Rakesh Kudurumalla > Cc: dev@dpdk.org > Subject: [EXT] [PATCH v3 1/1] app/graph: add example for different usecases > > External Email > > -- > From: Sunil Kumar Kori > > Current l3fwd-graph application only validates l3fwd use case. > To scale up this, new application will be added with a framework > to run as user's provided usecases. > > Required configuration and use cases details are fetched via a > static .cli file which will be used to create a graph for > requested uscases. > > Signed-off-by: Sunil Kumar Kori > Signed-off-by: Rakesh Kudurumalla > --- > MAINTAINERS | 7 + > app/graph/cli.c | 208 ++ > app/graph/cli.h | 48 ++ > app/graph/cli_priv.h | 19 + > app/graph/conn.c | 284 + > app/graph/conn.h | 46 ++ > app/graph/ethdev.c | 632 +++ > app/graph/ethdev.h | 28 + > app/graph/ethdev_priv.h | 46 ++ > app/graph/ethdev_rx.c| 139 > app/graph/ethdev_rx.h| 32 + > app/graph/ethdev_rx_priv.h | 23 + > app/graph/examples/l3fwd.cli | 87 +++ > app/graph/graph.c| 383 +++ > app/graph/graph.h| 11 + > app/graph/graph_priv.h | 32 + > app/graph/ip4_route.c| 146 + > app/graph/ip6_route.c| 154 + > app/graph/l3fwd.c| 152 + > app/graph/l3fwd.h| 11 + > app/graph/main.c | 201 ++ > app/graph/mempool.c | 134 > app/graph/mempool.h | 18 + > app/graph/mempool_priv.h | 16 + > app/graph/meson.build| 25 + > app/graph/module_api.h | 33 + > app/graph/neigh.c| 269 > app/graph/neigh.h| 11 + > app/graph/neigh_priv.h | 22 + > app/graph/route.h| 30 + > app/graph/utils.c| 155 + > app/graph/utils.h| 14 + > app/meson.build | 1 + > doc/guides/tools/graph.rst | 171 + > doc/guides/tools/img/graph-usecase-l3fwd.svg | 210 ++ > doc/guides/tools/index.rst | 1 + > 36 files changed, 3799 insertions(+) > create mode 100644 app/graph/cli.c > create mode 100644 app/graph/cli.h > create mode 100644 app/graph/cli_priv.h > create mode 100644 app/graph/conn.c > create mode 100644 app/graph/conn.h > create mode 100644 app/graph/ethdev.c > create mode 100644 app/graph/ethdev.h > create mode 100644 app/graph/ethdev_priv.h > create mode 100644 app/graph/ethdev_rx.c > create mode 100644 app/graph/ethdev_rx.h > create mode 100644 app/graph/ethdev_rx_priv.h > create mode 100644 app/graph/examples/l3fwd.cli > create mode 100644 app/graph/graph.c > create mode 100644 app/graph/graph.h > create mode 100644 app/graph/graph_priv.h > create mode 100644 app/graph/ip4_route.c > create mode 100644 app/graph/ip6_route.c > create mode 100644 app/graph/l3fwd.c > create mode 100644 app/graph/l3fwd.h > create mode 100644 app/graph/main.c > create mode 100644 app/graph/mempool.c > create mode 100644 app/graph/mempool.h > create mode 100644 app/graph/mempool_priv.h > create mode 100644 app/graph/meson.build > create mode 100644 app/graph/module_api.h > create mode 100644 app/graph/neigh.c > create mode 100644 app/graph/neigh.h > create mode 100644 app/graph/neigh_priv.h > create mode 100644 app/graph/route.h > create mode 100644 app/graph/utils.c > create mode 100644 app/graph/utils.h > create mode 100644 doc/guides/tools/graph.rst > create mode 100644 doc/guides/tools/img/graph-usecase-l3fwd.svg > [Nithin] Split to multiple smaller patches > diff --git a/MAINTAINERS b/MAINTAINERS > index 698608cdb2..7f149bd060 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1806,6 +1806,13 @@ F: dts/ > F: devtools/dts-check-format.sh > F: doc/guides/tools/dts.rst > > +Graph application > +M: Sunil Kumar Kori > +M: Rakesh Kudurumalla > +F: app/graph/ > +F: doc/guides/tools/graph.rst > +F: doc/guides/tools/img/graph-usecase-l3fwd.svg > + > > Other Example Applications > -- > diff --git a/app/graph/cli.c b/app/graph/cli.c > new file mode 100644 > index 00..237fa8008f > --- /de
RE: [PATCH v4 02/10] net/cpfl: introduce interface structure
> -Original Message-
> From: Xing, Beilei
> Sent: Friday, September 8, 2023 7:17 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
> ; Zhang, Qi Z
> Subject: [PATCH v4 02/10] net/cpfl: introduce interface structure
>
> From: Beilei Xing
>
> Introduce cplf interface structure to distinguish vport and port
> representor.
>
> Signed-off-by: Qi Zhang
> Signed-off-by: Beilei Xing
> ---
> drivers/net/cpfl/cpfl_ethdev.c | 3 +++
> drivers/net/cpfl/cpfl_ethdev.h | 16
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/net/cpfl/cpfl_ethdev.c b/drivers/net/cpfl/cpfl_ethdev.c
> index 46b3a52e49..92fe92c00f 100644
> --- a/drivers/net/cpfl/cpfl_ethdev.c
> +++ b/drivers/net/cpfl/cpfl_ethdev.c
> @@ -1803,6 +1803,9 @@ cpfl_dev_vport_init(struct rte_eth_dev *dev, void
> *init_params)
> goto err;
> }
>
> + cpfl_vport->itf.type = CPFL_ITF_TYPE_VPORT;
> + cpfl_vport->itf.adapter = adapter;
> + cpfl_vport->itf.data = dev->data;
> adapter->vports[param->idx] = cpfl_vport;
> adapter->cur_vports |= RTE_BIT32(param->devarg_id);
> adapter->cur_vport_nb++;
> diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
> index b637bf2e45..53e45035e8 100644
> --- a/drivers/net/cpfl/cpfl_ethdev.h
> +++ b/drivers/net/cpfl/cpfl_ethdev.h
> @@ -86,7 +86,19 @@ struct p2p_queue_chunks_info {
> uint32_t rx_buf_qtail_spacing;
> };
>
> +enum cpfl_itf_type {
> + CPFL_ITF_TYPE_VPORT,
> + CPFL_ITF_TYPE_REPRESENTOR
Defined but not used in this patch, how about move CPFL_ITF_TYPE_REPRESENTOR to
the patch that uses it?
> +};
> +
> +struct cpfl_itf {
> + enum cpfl_itf_type type;
> + struct cpfl_adapter_ext *adapter;
> + void *data;
> +};
> +
> struct cpfl_vport {
> + struct cpfl_itf itf;
> struct idpf_vport base;
> struct p2p_queue_chunks_info *p2p_q_chunks_info;
>
> @@ -124,5 +136,9 @@ TAILQ_HEAD(cpfl_adapter_list, cpfl_adapter_ext);
> RTE_DEV_TO_PCI((eth_dev)->device)
> #define CPFL_ADAPTER_TO_EXT(p) \
> container_of((p), struct cpfl_adapter_ext, base)
> +#define CPFL_DEV_TO_VPORT(dev) \
> + ((struct cpfl_vport *)((dev)->data->dev_private))
> +#define CPFL_DEV_TO_ITF(dev) \
> + ((struct cpfl_itf *)((dev)->data->dev_private))
>
> #endif /* _CPFL_ETHDEV_H_ */
> --
> 2.34.1
RE: [PATCH v4 03/10] net/cpfl: refine handle virtual channel message
> -static struct idpf_vport *
> +static struct cpfl_vport *
> cpfl_find_vport(struct cpfl_adapter_ext *adapter, uint32_t vport_id)
> {
> - struct idpf_vport *vport = NULL;
> + struct cpfl_vport *vport = NULL;
> int i;
>
> for (i = 0; i < adapter->cur_vport_nb; i++) {
> - vport = &adapter->vports[i]->base;
> - if (vport->vport_id != vport_id)
> + vport = adapter->vports[i];
> + if (vport->base.vport_id != vport_id)
Check if vport is NULL to ensure the structure access?
> continue;
> else
> return vport;
> }
>
> - return vport;
> + return NULL;
> }
RE: [PATCH v4 08/10] net/cpfl: support vport list/info get
> -Original Message- > From: Xing, Beilei > Sent: Friday, September 8, 2023 7:17 PM > To: Wu, Jingjing > Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei > > Subject: [PATCH v4 08/10] net/cpfl: support vport list/info get > > From: Beilei Xing > > Support cp channel ops CPCHNL2_OP_CPF_GET_VPORT_LIST and > CPCHNL2_OP_CPF_GET_VPORT_INFO. > > Signed-off-by: Beilei Xing Can we merge this patch to previous cpchnl handle one or move ahead before representor is introduced?
RE: [PATCH v4 09/10] net/cpfl: create port representor
> + /* warning if no match vport detected */ > + if (!matched) > + PMD_INIT_LOG(WARNING, "No matched vport for > representor %s " > + "creation will be deferred when > vport is detected", > + name); > + If vport info is responded successfully, what is the case that matched is false? And I did not find the defer process. > + rte_spinlock_unlock(&adapter->vport_map_lock); > + } > + > +err: > + rte_spinlock_unlock(&adapter->repr_lock); > + rte_free(vlist_resp); > + return ret; > +}
RE: [PATCH v4 10/10] net/cpfl: support link update for representor
> -Original Message-
> From: Xing, Beilei
> Sent: Friday, September 8, 2023 7:17 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Liu, Mingxia ; Xing, Beilei
>
> Subject: [PATCH v4 10/10] net/cpfl: support link update for representor
>
> From: Beilei Xing
>
> Add link update ops for representor.
>
> Signed-off-by: Jingjing Wu
> Signed-off-by: Beilei Xing
> ---
> drivers/net/cpfl/cpfl_ethdev.h | 1 +
> drivers/net/cpfl/cpfl_representor.c | 21 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
> index 4937d2c6e3..0dd9d4e7f9 100644
> --- a/drivers/net/cpfl/cpfl_ethdev.h
> +++ b/drivers/net/cpfl/cpfl_ethdev.h
> @@ -162,6 +162,7 @@ struct cpfl_repr {
> struct cpfl_repr_id repr_id;
> struct rte_ether_addr mac_addr;
> struct cpfl_vport_info *vport_info;
> + bool func_up; /* If the represented function is up */
> };
>
> struct cpfl_adapter_ext {
> diff --git a/drivers/net/cpfl/cpfl_representor.c
> b/drivers/net/cpfl/cpfl_representor.c
> index 0cd92b1351..3c0fa957de 100644
> --- a/drivers/net/cpfl/cpfl_representor.c
> +++ b/drivers/net/cpfl/cpfl_representor.c
> @@ -308,6 +308,23 @@ cpfl_repr_tx_queue_setup(__rte_unused struct
> rte_eth_dev *dev,
> return 0;
> }
>
> +static int
> +cpfl_repr_link_update(struct rte_eth_dev *ethdev,
> + __rte_unused int wait_to_complete)
> +{
> + struct cpfl_repr *repr = CPFL_DEV_TO_REPR(ethdev);
> + struct rte_eth_link *dev_link = ðdev->data->dev_link;
> +
> + if (!(ethdev->data->dev_flags & RTE_ETH_DEV_REPRESENTOR)) {
> + PMD_INIT_LOG(ERR, "This ethdev is not representor.");
> + return -EINVAL;
> + }
> + dev_link->link_status = repr->func_up ?
> + RTE_ETH_LINK_UP : RTE_ETH_LINK_DOWN;
> +
> + return 0;
> +}
> +
> static const struct eth_dev_ops cpfl_repr_dev_ops = {
> .dev_start = cpfl_repr_dev_start,
> .dev_stop = cpfl_repr_dev_stop,
> @@ -317,6 +334,8 @@ static const struct eth_dev_ops cpfl_repr_dev_ops = {
>
> .rx_queue_setup = cpfl_repr_rx_queue_setup,
> .tx_queue_setup = cpfl_repr_tx_queue_setup,
> +
> + .link_update= cpfl_repr_link_update,
> };
>
> static int
> @@ -331,6 +350,8 @@ cpfl_repr_init(struct rte_eth_dev *eth_dev, void
> *init_param)
> repr->itf.type = CPFL_ITF_TYPE_REPRESENTOR;
> repr->itf.adapter = adapter;
> repr->itf.data = eth_dev->data;
> + if (repr->vport_info->vport_info.vport_status ==
> CPCHNL2_VPORT_STATUS_ENABLED)
> + repr->func_up = true;
>
Now event process? Think about the vsi status changes?
> eth_dev->dev_ops = &cpfl_repr_dev_ops;
>
> --
> 2.34.1
Re: [RFC] random: use per lcore state
On 2023-09-09 02:13, Konstantin Ananyev wrote:
06/09/2023 21:02, Mattias Rönnblom пишет:
On 2023-09-06 19:20, Stephen Hemminger wrote:
Move the random number state into thread local storage.
Me and Morten discussed TLS versus other alternatives in some other
thread. The downside of TLS that Morten pointed out, from what I
recall, is that lazy initialization is *required* (since the number of
threads is open-ended), and the data ends up in non-huge page memory.
Hmm.. correct me if I am wrong, but with current implementation,
rand state is also in non-huge memory:
static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1];
Yes. The current pattern is certainly not perfect.
It was also unclear to me what the memory footprint implications would
be,h would large per-lcore data structures be put in TLS. More
specifically, if they would be duplicated across all threads, even
non-lcore threads.
None of these issues affect rte_random.c's potential usage of TLS
(except lazy [re-]initialization makes things more complicated).
Preferably, there should be one pattern that is usable across all or
at least most DPDK modules requiring per-lcore state.
This has a several benefits.
- no false cache sharing from cpu prefetching
- fixes initialization of random state for non-DPDK threads
This seems like a non-reason to me. That bug is easily fixed, if it
isn't already.
- fixes unsafe usage of random state by non-DPDK threads
"Makes random number generation MT safe from all threads (including
unregistered non-EAL threads)."
With current API semantics you may still register an non-EAL thread,
to get MT safe access to this API, so I guess it's more about being
more convenient and less error prone, than anything else.
I understand that we never guaranteed MT safety for non-EAL threads here,
Registered non-EAL threads have a lcore id and thus may safely call
rte_rand(). Multiple unregistered non-EAL threads may not do so, in
parallel.
but as a user of rte_rand() - it would be much more convenient, if I can
use it
from any thread wthout worring is it a EAL thread or not.
Sure, especially if it comes for free. The for-free solution has yet to
reveal itself though.
About TlS usage and re-seeding - can we use some sort of middle-ground:
extend rte_rand_state with some gen-counter.
Make a 'master' copy of rte_rand_state that will be updated by rte_srand(),
and TLS copies of rte_rand_state, so rte_rand() can fist compare
its gen-counter value with master copy to decide,
does it need to copy new state from master or not.
Calling threads shouldn't all produce the same sequence. That would be
silly and not very random. The generation number should be tied to the seed.
The new MT safety guarantees should be in the API docs as well.
Yes, it is an extension to the current API, not a fix.
The initialization of random number state is done by the
lcore (lazy initialization).
Signed-off-by: Stephen Hemminger
---
lib/eal/common/rte_random.c | 38 +++--
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
index 53636331a27b..9657adf6ad3b 100644
--- a/lib/eal/common/rte_random.c
+++ b/lib/eal/common/rte_random.c
@@ -19,13 +19,14 @@ struct rte_rand_state {
uint64_t z3;
uint64_t z4;
uint64_t z5;
-} __rte_cache_aligned;
+ uint64_t seed;
+};
-/* One instance each for every lcore id-equipped thread, and one
- * additional instance to be shared by all others threads (i.e., all
- * unregistered non-EAL threads).
- */
-static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1];
+/* Global random seed */
+static uint64_t rte_rand_seed;
+
+/* Per lcore random state. */
+static RTE_DEFINE_PER_LCORE(struct rte_rand_state, rte_rand_state);
static uint32_t
__rte_rand_lcg32(uint32_t *seed)
@@ -81,11 +82,7 @@ __rte_srand_lfsr258(uint64_t seed, struct
rte_rand_state *state)
void
rte_srand(uint64_t seed)
{
- unsigned int lcore_id;
-
- /* add lcore_id to seed to avoid having the same sequence */
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
- __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
+ __atomic_store_n(&rte_rand_seed, seed, __ATOMIC_RELAXED);
}
static __rte_always_inline uint64_t
@@ -119,15 +116,18 @@ __rte_rand_lfsr258(struct rte_rand_state *state)
static __rte_always_inline
struct rte_rand_state *__rte_rand_get_state(void)
{
- unsigned int idx;
+ struct rte_rand_state *rand_state = &RTE_PER_LCORE(rte_rand_state);
There should really be a RTE_PER_THREAD, an alias to RTE_PER_LCORE, to
cover this usage. Or just use __thread (or _Thread_local?).
+ uint64_t seed;
- idx = rte_lcore_id();
+ seed = __atomic_load_n(&rte_rand_seed, __ATOMIC_RELAXED);
+ if (unlikely(seed != rand_state->seed)) {
+ rand_state->seed = seed;
Re-seeding should restart the series, on al
