RE: [PATCH v3] net/igc: move the initialization of data path into dev_init
> -Original Message- > From: Zeng, ZhichaoX > Sent: Tuesday, June 28, 2022 2:21 PM > To: dev@dpdk.org > Cc: sta...@dpdk.org; Yang, Qiming ; Zhang, Qi Z > ; Zeng, ZhichaoX ; > alvinx.zh...@intel.com; Guo, Junfeng ; Su, Simei > ; Ferruh Yigit > Subject: [PATCH v3] net/igc: move the initialization of data path into > dev_init > > From: Zhichao Zeng > > The upper-layer application usually call the common interface "dev_init" > to initialize the data path, but in the igc driver, the initialization of > data path is in > "igc_rx_init" and "eth_igc_tx_queue_setup", while in other drivers it is in > "dev_init". So when upper-layer application calling these function pointers > will > occur segmentation faults. NO, for most intel PMD e.g.: i40e and ice, we don't initialize data path in dev_init. > > This patch moves the initialization of data path into "eth_igc_dev_init" > to avoid segmentation faults, which is consistent with other drivers. I saw dev->rx_pkt_burst can be overwritten in igc_rx_init, I assume the issue still be exist.
Re: [PATCH] crypto/qat: fix docsis segmentation fault
On Mon, Jun 27, 2022 at 6:45 PM Rebecca Troy wrote: > > Currently if AES or DES algorithms fail for Docsis test suite, > a segmentation fault occurs when cryptodev_qat_autotest is ran. > > This is due to a duplicate call of EVP_CIPHER_CTX_free for the > session context. Ctx is freed firstly in the bpi_cipher_ctx_init > function and then again at the end of qat_sym_session_configure_cipher > function. > > This commit fixes this bug by removing the first instance > of EVP_CIPHER_CTX_free, leaving just the dedicated function in > the upper level to free the ctx. This is awkward. This helper should let *ctx alone until everything succeeded. -- David Marchand
RE: [PATCH] common/iavf: replace zero-length arrays with flexible ones
> -Original Message- > From: 835703...@qq.com <835703...@qq.com> > Sent: Thursday, June 16, 2022 1:26 AM > To: Wu, Jingjing > Cc: dev@dpdk.org; Shiqi Liu <835703...@qq.com> > Subject: [PATCH] common/iavf: replace zero-length arrays with flexible ones > > From: Shiqi Liu <835703...@qq.com> > > This patch replaces instances of zero-sized arrays i.e. those at the > end of structures with "[0]" with the more standard syntax of "[]". > Replacement was done using coccinelle script, with some revert and > cleanup of whitespace afterwards. > > Signed-off-by: Shiqi Liu <835703...@qq.com> Nacked for compile issue reported in patchwork https://patchwork.dpdk.org/project/dpdk/patch/tencent_7d3a7a9d44570652650b9d5ed095956c4...@qq.com/
[PATCH v1] example/fips_validation: handle empty payload
Allocate atleast onebyte to handle empty payload in a test vector
when defined.
Fixes: 3d0fad56b74 ("examples/fips_validation: add crypto FIPS application")
Cc: sta...@dpdk.org
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 94e31abf83..324abccb14 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -630,7 +630,7 @@ parse_uint8_hex_str(const char *key, char *src, struct
fips_val *val)
val->val = NULL;
}
- val->val = rte_zmalloc(NULL, len, 0);
+ val->val = rte_zmalloc(NULL, len + 1, 0);
if (!val->val)
return -ENOMEM;
--
2.25.1
[PATCH v1] examples/fips_validation: add parsing for xts
Added function to parse algorithm for AES XTS test.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation.c| 4 +-
examples/fips_validation/fips_validation.h| 17 ++-
.../fips_validation/fips_validation_xts.c | 126 ++
examples/fips_validation/main.c | 5 +
4 files changed, 150 insertions(+), 2 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 324abccb14..f181363ef7 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -463,7 +463,9 @@ fips_test_parse_one_json_vector_set(void)
else if (strstr(algo_str, "CMAC"))
info.algo = FIPS_TEST_ALGO_AES_CMAC;
else if (strstr(algo_str, "AES-CBC"))
- info.algo = FIPS_TEST_ALGO_AES;
+ info.algo = FIPS_TEST_ALGO_AES_CBC;
+ else if (strstr(algo_str, "AES-XTS"))
+ info.algo = FIPS_TEST_ALGO_AES_XTS;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 69d738b718..8ae849c46f 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -34,13 +34,14 @@
enum fips_test_algorithms {
FIPS_TEST_ALGO_AES = 0,
+ FIPS_TEST_ALGO_AES_CBC,
FIPS_TEST_ALGO_AES_GCM,
FIPS_TEST_ALGO_AES_CMAC,
FIPS_TEST_ALGO_AES_CCM,
+ FIPS_TEST_ALGO_AES_XTS,
FIPS_TEST_ALGO_HMAC,
FIPS_TEST_ALGO_TDES,
FIPS_TEST_ALGO_SHA,
- FIPS_TEST_ALGO_AES_XTS,
FIPS_TEST_ALGO_MAX
};
@@ -170,7 +171,17 @@ struct gcm_interim_data {
uint8_t gen_iv;
};
+
#ifdef USE_JANSSON
+enum xts_tweak_modes {
+ XTS_TWEAK_MODE_HEX = 0,
+ XTS_TWEAK_MODE_NUMBER
+};
+
+struct xts_interim_data {
+ enum xts_tweak_modes tweak_mode;
+};
+
struct fips_test_json_info {
/* Information used for reading from json */
json_t *json_root;
@@ -207,6 +218,7 @@ struct fips_test_interim_info {
struct ccm_interim_data ccm_data;
struct sha_interim_data sha_data;
struct gcm_interim_data gcm_data;
+ struct xts_interim_data xts_data;
} interim_info;
enum fips_test_op op;
@@ -266,6 +278,9 @@ parse_test_cmac_json_init(void);
int
parse_test_aes_json_init(void);
+
+int
+parse_test_xts_json_init(void);
#endif /* USE_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_xts.c
b/examples/fips_validation/fips_validation_xts.c
index 5bb1966f6c..2de852c1fc 100644
--- a/examples/fips_validation/fips_validation_xts.c
+++ b/examples/fips_validation/fips_validation_xts.c
@@ -24,6 +24,22 @@
#define OP_ENC_STR "ENCRYPT"
#define OP_DEC_STR "DECRYPT"
+#define ALGO_JSON_STR "algorithm"
+#define TESTTYPE_JSON_STR "testType"
+#define DIR_JSON_STR "direction"
+#define KEYLEN_JSON_STR"keyLen"
+#define TWEAKMODE_JSON_STR "tweakMode"
+
+#define KEY_JSON_STR "key"
+#define DATAUNITLEN_JSON_STR "dataUnitLen"
+#define PAYLOADLEN_JSON_STR"payloadLen"
+#define TWEAKVALUE_JSON_STR"tweakValue"
+#define PT_JSON_STR"pt"
+#define CT_JSON_STR"ct"
+
+#define OP_ENC_JSON_STR"encrypt"
+#define OP_DEC_JSON_STR"decrypt"
+
static int
parse_interim_xts_enc_dec(const char *key,
__rte_unused char *text,
@@ -62,6 +78,116 @@ struct fips_test_callback xts_writeback_callbacks[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef RTE_HAS_JANSSON
+static int
+parser_xts_read_keylen(const char *key, char *src, struct fips_val *val)
+{
+ int ret;
+
+ ret = parser_read_uint32_bit_val(key, src, val);
+ if (ret < 0)
+ return ret;
+
+ val->len *= 2;
+ return 0;
+}
+
+struct fips_test_callback xts_dec_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {TWEAKVALUE_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {CT_JSON_STR, parse_uint8_hex_str, &vec.ct},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback xts_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_xts_read_keylen, &vec.cipher_auth.key},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback xts_enc_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {TWEAKVALUE_JSON_STR, parse_uint8_hex_str, &vec.iv},
+ {PT_JSON_STR, parse_uint8_hex_str, &vec.pt},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+static int
+parse_test_xts_json_writeback(struct fips_val *val)
+{
+ struct fips_val tm
Re: [PATCH] examples/distributor: update dynamic configuration
Hi Ömer,
On 27/06/2022 17:28, Omer Yamac wrote:
Hi David,
Thank you for your review. I have two questions. The first one is
about new release. As I remember new DPDK realize will be published in
a short time and my previous fix in that release. Therefore, Should I
wait for that release to submit patch?
Yes, You can wait, or you can submit to the mailing list now and mark
the patch as "Deferred" in patchwork. Once 22.07 is released it will get
marked as "New", and under consideration for 22.11.
The other question is below,
On 27.06.2022 18:51, Hunt, David wrote:
Hi Ömer,
I've a few comments:
On 21/06/2022 21:15, Abdullah Ömer Yamaç wrote:
In this patch,
* It is possible to switch the running mode of the distributor
using the command line argument.
* With "-c" parameter, you can run RX and Distributor
on the same core.
* Without "-c" parameter, you can run RX and Distributor
on the different core.
* Syntax error of the single RX and distributor core is fixed.
* When "-c" parameter is active, the wasted distributor core is
also deactivated in the main function.
Fixes: 4a7f40c0ff9a ("examples/distributor: add dedicated core")
Cc: sta...@dpdk.org
Signed-off-by: Abdullah Ömer Yamaç
---
--snip--
"1 lcore for stats (can be core 0)\n"
@@ -733,6 +808,15 @@ main(int argc, char *argv[])
"1 lcore for packet TX\n"
"and at least 1 lcore for worker threads\n");
+ if (rte_lcore_count() < 4 && enable_lcore_rx_distributor)
+ rte_exit(EXIT_FAILURE, "Error, This application needs at "
+ "least 4 logical cores to run:\n"
+ "1 lcore for stats (can be core 0)\n"
+ "1 lcore for packet RX and distribution\n"
+ "1 lcore for packet TX\n"
+ "and at least 1 lcore for worker threads\n");
+
the two checks above could be replaced with something like:
min_cores = 4 + enable_lcore_rx_distributor;
if (rte_lcore_count() < min_cores)
rte_exit(EXIT_FAILURE, "Error, This application needs
at "
"least %d logical cores to run:\n"
"1 lcore for stats (can be core 0)\n"
"1 lcore for packet RX\n"
"1 lcore for distribution\n"
"1 lcore for packet TX\n"
"and at least 1 lcore for worker
threads\n",
min_cores);
Is it okay, if I change the error string such that:
"1 or 2 lcore for packet RX and distribution"
Sure, that's fine.
--snip--
Thanks,
Dave.
RE: [dpdk-dev] [PATCH v5] examples/ipsec-secgw: support more flow patterns and actions
> > From: Satheesh Paul > > > > Added support to create flow rules with count, mark and > > security actions and mark pattern. > > > > Signed-off-by: Satheesh Paul > > --- > Acked-by: Fan Zhang Acked-by: Akhil Goyal Applied to dpdk-next-crypto
RE: [PATCH v3] app/test: add event inline security tests
> Enable ability to run inline security tests using event > API(rte_event_eth_tx_adapter_enqueue/rte_event_dequeue_burst). > New test command - event_inline_ipsec_autotest will run same list of > test cases as inline_ipsec_autotest, but packets will go through eventdev. > > Signed-off-by: Volodymyr Fialko > --- > v2: > * Fixed compilation with mingw. > v3: > * Fixed struct zero initialization for gcc 4.* Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks.
RE: [PATCH] examples/ipsec-secgw: fix Tx checksum offload flag
> > For the inline crypto path set the Tx checksum offload flag
> > only if the device supports it.
> >
> > Fixes: d24471e5786b ("examples/ipsec-secgw: disable Tx checksum for inline")
> > Cc: ndabilpu...@marvell.com
> >
> > Signed-off-by: Radu Nicolau
> > ---
> Acked-by: Fan Zhang
Acked-by: Akhil Goyal
Applied to dpdk-next-crypto
Thanks.
RE: [EXT] Re: [PATCH v3 1/2] examples/l3fwd: common packet group functionality
> 23/06/2022 10:38, Rahul Bhansali пишет: > > This will make the packet grouping function common, so > > that other examples can utilize as per need. > > > > For each architecture sse/neon/altivec, port group > > headers will be created under examples/common/. > > > > Signed-off-by: Rahul Bhansali > > --- > > Changes in v3: Created common port-group headers for > > architectures sse/neon/altivec as suggested by Konstantin. > > > > Changes in v2: New patch to address review comment. > > > > > Tested-by: Konstantin Ananyev > Acked-by: Konstantin Ananyev Series Applied to dpdk-next-crypto Thanks.
RE: [PATCH] test/crypto: fix authentication IV for zuc SGL
> >
> > The wireless operation for ZUC SGL tests was being passed NULL instead of a
> > pointer to the test data authentication IV, and IV length 0.
> > This is now corrected to use the IV from the test data.
> >
> > Fixes: 11c5485bb276 ("test/crypto: add scatter-gather tests for IP and OOP")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Ciara Power
>
> Acked-by: Pablo de Lara
Applied to dpdk-next-crypto
Thanks.
Re: [PATCH v2] vdpa/sfc: handle sync issue between qemu and vhost-user
On 6/28/22 08:29, abhimanyu.sa...@xilinx.com wrote:
From: Abhimanyu Saini
When DPDK app is running in the VF, it sometimes rings the doorbell
before dev_config has had a chance to complete and hence it misses
the event. As workaround, ring the doorbell when vDPA reports the
notify_area to QEMU.
Fixes: 630be406dcbf ("vdpa/sfc: get queue notify area info")
Cc: sta...@dpdk.org
Signed-off-by: Vijay Kumar Srivastava
Signed-off-by: Abhimanyu Saini
Acked-by: Andrew Rybchenko
RE: [EXT] [PATCH 0/2] fix wireless algorithm IVs
> Some of the ZUC and Snow3G test vectors did not follow > the specification for the cipher and authentication IVs. > > Ciara Power (2): > test/crypto: fix zuc test vector IV format > test/crypto: fix snow3g test vector IV format > > app/test/test_cryptodev_snow3g_test_vectors.h | 142 +- > app/test/test_cryptodev_zuc_test_vectors.h| 54 +++ > 2 files changed, 98 insertions(+), 98 deletions(-) > Series applied to dpdk-next-crypto Thanks.
[Bug 1043] [dpdk-22.07]vm2vm_virtio_net_perf_cbdma/vm2vm_split_ring_iperf_with_tso_and_cbdma_enable: iperf test no data between 2 VMs
https://bugs.dpdk.org/show_bug.cgi?id=1043 Bug ID: 1043 Summary: [dpdk-22.07]vm2vm_virtio_net_perf_cbdma/vm2vm_split_ri ng_iperf_with_tso_and_cbdma_enable: iperf test no data between 2 VMs Product: DPDK Version: 22.03 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: weix.l...@intel.com Target Milestone: --- [Environment] DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads commit 7cac53f205ebd04d8ebd3ee6a9dd84f698d4ada3 (HEAD -> main, tag: v22.07-rc2, origin/main, origin/HEAD) Author: Thomas Monjalon Date: Mon Jun 27 04:03:44 2022 +0200version: 22.07-rc2 Signed-off-by: Thomas Monjalon Other software versions: QEMU-7.0.0 OS: Ubuntu 22.04 LTS/Linux 5.15.45-051545-generic Compiler: gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1) Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz NIC hardware: N/A NIC firmware: N/A [Test Setup] Steps to reproduce List the steps to reproduce the issue. 1. Bind 2 CBDMA channels to vfio-pci: dpdk-devbind.py --force --bind=vfio-pci :80:04.0 :80:04.1 2. Start vhost-tetpmd: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 28-36 -n 4 -a :80:04.0 -a :80:04.1 --file-prefix=vhost_247798_20220628141037 --vdev 'net_vhost0,iface=vhost-net0,queues=1,tso=1,dmas=[txq0;rxq0]' --vdev 'net_vhost1,iface=vhost-net1,queues=1,tso=1,dmas=[txq0;rxq0]' --iova=va -- -i --nb-cores=2 --txd=1024 --rxd=1024 --txq=1 --rxq=1 --lcore-dma=[lcore29@:80:04.0,lcore30@:80:04.1] start 3. Start VM0: taskset -c 20,21,22,23,24,25,26,27 /home/QEMU/qemu-7.0.0/bin/qemu-system-x86_64 -name vm0 -enable-kvm -pidfile /tmp/.vm0.pid -daemonize -monitor unix:/tmp/vm0_monitor.sock,server,nowait -netdev user,id=nttsip1,hostfwd=tcp:10.239.252.220:6000-:22 -device e1000,netdev=nttsip1 -chardev socket,id=char0,path=/root/dpdk/vhost-net0 -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce,queues=1 -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,csum=on,guest_csum=on,host_tso4=on,guest_tso4=on,guest_ecn=on -cpu host -smp 8 -m 16384 -object memory-backend-file,id=mem,size=16384M,mem-path=/mnt/huge,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 -device virtio-serial -device virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 -vnc :4 -drive file=/home/image/ubuntu2004.img 4. Start VM1: taskset -c 48,49,50,51,52,53,54,55 /home/QEMU/qemu-7.0.0/bin/qemu-system-x86_64 -name vm1 -enable-kvm -pidfile /tmp/.vm1.pid -daemonize -monitor unix:/tmp/vm1_monitor.sock,server,nowait -device e1000,netdev=nttsip1 -netdev user,id=nttsip1,hostfwd=tcp:10.239.252.220:6001-:22 -chardev socket,id=char0,path=/root/dpdk/vhost-net1 -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce,queues=1 -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:02,disable-modern=false,mrg_rxbuf=on,csum=on,guest_csum=on,host_tso4=on,guest_tso4=on,guest_ecn=on -cpu host -smp 8 -m 16384 -object memory-backend-file,id=mem,size=16384M,mem-path=/mnt/huge,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,path=/tmp/vm1_qga0.sock,server,nowait,id=vm1_qga0 -device virtio-serial -device virtserialport,chardev=vm1_qga0,name=org.qemu.guest_agent.0 -vnc :5 -drive file=/home/image/ubuntu2004_2.img 5. SSH login VM0 and VM1 to config IP: [VM0] ssh root@10.239.252.220 -p 6000 ifconfig ens4 1.1.1.1 [VM1] ssh root@10.239.252.220 -p 6001 ifconfig ens4 1.1.1.2 6. Use iperf test tool to test between 2 VMs [VM0] iperf -s -i 1 [VM1] iperf -c 1.1.1.1 -i 1 -t 60 Show the output from the previous commands. There is no any data. [Expected Result] Explain what is the expected result in text or as an example output: root@virtiovm:~# iperf -c 1.1.1.1 -i 1 -t 60 Client connecting to 1.1.1.1, TCP port 5001 TCP window size: 85.0 KByte (default) [ 1] local 1.1.1.2 port 42240 connected with 1.1.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.-1. sec 2.45 GBytes 21.0 Gbits/sec [ 1] 1.-2. sec 2.42 GBytes 20.8 Gbits/sec [ 1] 2.-3. sec 2.39 GBytes 20.6 Gbits/sec [ 1] 3.-4. sec 2.41 GBytes 20.7 Gbits/sec [ 1] 4.-5. sec 2.33 GBytes 20.0 Gbits/sec [ 1] 5.-6. sec 2.40 GBytes 20.6 Gbits/sec [ 1] 6.-7. sec 2.39 GBytes 20.6 Gbits/sec [ 1] 7.-8. sec 2.41 GBytes 20.7 Gbits/sec [ 1] 8.-9. sec 2.35 GBytes 20.2 Gbits/sec [ 1] 9.-10. sec 2.40 GBytes 20.6 Gbits/sec [ 1] 10.-11. sec 2.37 GBytes 20.4 Gbits/sec [ 1] 11.-12. sec 2.41 GBytes 20.7 G
Re: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0
On 6/27/22 18:24, Loftus, Ciara wrote: On 6/27/22 17:17, Loftus, Ciara wrote: On 6/24/22 13:23, Ciara Loftus wrote: libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, use the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach and bpf_xdp_detach which are available to use since libbpf v0.7.0. Also prevent linking with libbpf versions > v0.8.0. Signed-off-by: Ciara Loftus --- doc/guides/nics/af_xdp.rst | 3 ++- drivers/net/af_xdp/compat.h | 36 - drivers/net/af_xdp/meson.build | 7 ++ drivers/net/af_xdp/rte_eth_af_xdp.c | 19 +++ 4 files changed, 42 insertions(+), 23 deletions(-) Don't we need to mention these changes in release notes? diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst index 56681c8365..9edb48df67 100644 --- a/doc/guides/nics/af_xdp.rst +++ b/doc/guides/nics/af_xdp.rst @@ -43,7 +43,8 @@ Prerequisites This is a Linux-specific PMD, thus the following prerequisites apply: * A Linux Kernel (version > v4.18) with XDP sockets configuration enabled; -* Both libxdp >=v1.2.2 and libbpf libraries installed, or, libbpf <=v0.6.0 +* Both libxdp >=v1.2.2 and libbpf <=v0.8.0 libraries installed, or, libbpf + <=v0.6.0. * If using libxdp, it requires an environment variable called LIBXDP_OBJECT_PATH to be set to the location of where libxdp placed its bpf object files. This is usually in /usr/local/lib/bpf or /usr/local/lib64/bpf. diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h index 28ea64aeaa..8f4ac8b5ea 100644 --- a/drivers/net/af_xdp/compat.h +++ b/drivers/net/af_xdp/compat.h @@ -60,7 +60,7 @@ tx_syscall_needed(struct xsk_ring_prod *q __rte_unused) } #endif -#ifdef RTE_NET_AF_XDP_LIBBPF_OBJ_OPEN +#ifdef RTE_NET_AF_XDP_LIBBPF_V070 Typically version-based checks are considered as bad. Isn't it better use feature-based checks/defines? Hi Andrew, Thank you for the feedback. Is the feature-based checking something that we can push to the next release? We are already using the pkg-config version-check method for other libraries/features in the meson.build file: * libxdp >= v1.2.2 # earliest compatible libxdp release * libbpf >= v0.7.0 # bpf_object__* functions * libbpf >= v0.2.0 # shared umem feature If we change to your suggested method I think we should change them all in one patch. IMO it's probably too close to the release to change them all right now. What do you think? Thanks, Ciara Hi Ciara, yes, ideally we should avoid usage of version-based check everywhere, but I don't think that it is critical to switch at once. We can use it for new checks right now and rewrite old/existing checks a bit later in the next release. Please, note that my notes are related to review notes from Thomas who asked by file_library() method is removed. Yes, it is confusing and it is better to avoid it. Usage of feature-based checks would allow to preserve find_library() as well. Thank you for the explanation. In this case we want to check that the libbpf library is <=v0.8.0. At this moment in time v0.8.0 is the latest version of libbpf so we cannot check for a symbol that tells us the library is > v0.8.0. Can you think of a way to approach this without using the pkg-config version check method? I've introduced this check to future-proof the PMD and ensure we only ever link with versions of libbpf that we've validated to be compatible with the PMD. When say v0.9.0 is released we can patch the PMD allowing for libbpf <= v0.9.0 and make any necessary API changes as part of that patch. This should hopefully help avoid the scenario Thomas encountered. Personally I'd consider such checks which limit version as a drawback. I think checks on build should not be used to reject future versions. Otherwise, introduction of any further even minor version would require a patch to allow it. Documentation is the place for information about validated versions. Build should not enforce it.
[PATCH] net/vhost: fix compliant offloading flag
From: Xuan Ding
This patch fixes the check to set compliant offloading flag.
Compliant offloading flag should be set when the
'legacy-ol-flags' is true.
Fixes: 3a6ee8dafb21("net/vhost: enable compliant offloading mode")
Signed-off-by: Xuan Ding
---
drivers/net/vhost/rte_eth_vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index d75d256040..24049df58a 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1735,7 +1735,7 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
goto out_free;
}
- if (legacy_ol_flags == 0)
+ if (legacy_ol_flags == 1)
flags |= RTE_VHOST_USER_NET_COMPLIANT_OL_FLAGS;
if (dev->device.numa_node == SOCKET_ID_ANY)
--
2.17.1
Re: [PATCH] net/vhost: fix compliant offloading flag
On 6/28/22 11:42, xuan.d...@intel.com wrote:
From: Xuan Ding
This patch fixes the check to set compliant offloading flag.
Compliant offloading flag should be set when the
'legacy-ol-flags' is true.
Fixes: 3a6ee8dafb21("net/vhost: enable compliant offloading mode")
Signed-off-by: Xuan Ding
---
drivers/net/vhost/rte_eth_vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index d75d256040..24049df58a 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1735,7 +1735,7 @@ rte_pmd_vhost_probe(struct rte_vdev_device *dev)
goto out_free;
}
- if (legacy_ol_flags == 0)
+ if (legacy_ol_flags == 1)
flags |= RTE_VHOST_USER_NET_COMPLIANT_OL_FLAGS;
if (dev->device.numa_node == SOCKET_ID_ANY)
Nack, legacy OL flags is NOT compliant. So current implementation is
good.
Regards,
Maxime
Re: [PATCH v2] baseband/turbo_sw: Remove flexran_sdk meson option
27/06/2022 22:29, Nicolas Chautru: > Hi Thomas, > This is change you requested earlier this year. This is targeting 22.11. OK thanks. > Basically we no longer pass a specific option but rely on pkgconfig. > There is small change to generate the .pc files that Intel will make > available by end of year. Still the related change in DPDK is available now. It means we depend on a future version of Flexran? Please could you document the minimum version? Note: I think you messed tab indents in the meson file.
RE: [PATCH] net/af_xdp: make compatible with libbpf v0.8.0
> > On 6/24/22 13:23, Ciara Loftus wrote: > > libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and > >> bpf_set_link_xdp_fd > > functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, > use > > the recommended replacement functions bpf_xdp_query_id, > bpf_xdp_attach > > and bpf_xdp_detach which are available to use since libbpf v0.7.0. > > > > Also prevent linking with libbpf versions > v0.8.0. > > > > Signed-off-by: Ciara Loftus > > --- > > doc/guides/nics/af_xdp.rst | 3 ++- > > drivers/net/af_xdp/compat.h | 36 > - > > drivers/net/af_xdp/meson.build | 7 ++ > > drivers/net/af_xdp/rte_eth_af_xdp.c | 19 +++ > > 4 files changed, 42 insertions(+), 23 deletions(-) > > Don't we need to mention these changes in release notes? > > > > > diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst > > index 56681c8365..9edb48df67 100644 > > --- a/doc/guides/nics/af_xdp.rst > > +++ b/doc/guides/nics/af_xdp.rst > > @@ -43,7 +43,8 @@ Prerequisites > > This is a Linux-specific PMD, thus the following prerequisites > > apply: > > > > * A Linux Kernel (version > v4.18) with XDP sockets configuration > >> enabled; > > -* Both libxdp >=v1.2.2 and libbpf libraries installed, or, libbpf > <=v0.6.0 > > +* Both libxdp >=v1.2.2 and libbpf <=v0.8.0 libraries installed, or, > libbpf > > + <=v0.6.0. > > * If using libxdp, it requires an environment variable called > >LIBXDP_OBJECT_PATH to be set to the location of where libxdp > >> placed its > bpf > >object files. This is usually in /usr/local/lib/bpf or > /usr/local/lib64/bpf. > > diff --git a/drivers/net/af_xdp/compat.h > >> b/drivers/net/af_xdp/compat.h > > index 28ea64aeaa..8f4ac8b5ea 100644 > > --- a/drivers/net/af_xdp/compat.h > > +++ b/drivers/net/af_xdp/compat.h > > @@ -60,7 +60,7 @@ tx_syscall_needed(struct xsk_ring_prod *q > __rte_unused) > > } > > #endif > > > > -#ifdef RTE_NET_AF_XDP_LIBBPF_OBJ_OPEN > > +#ifdef RTE_NET_AF_XDP_LIBBPF_V070 > > Typically version-based checks are considered as bad. Isn't it > better use feature-based checks/defines? > >>> > >>> Hi Andrew, > >>> > >>> Thank you for the feedback. Is the feature-based checking something > that > >> we can push to the next release? > >>> > >>> We are already using the pkg-config version-check method for other > >> libraries/features in the meson.build file: > >>> * libxdp >= v1.2.2 # earliest compatible libxdp release > >>> * libbpf >= v0.7.0 # bpf_object__* functions > >>> * libbpf >= v0.2.0 # shared umem feature > >>> > >>> If we change to your suggested method I think we should change them > all > >> in one patch. IMO it's probably too close to the release to change them all > >> right now. What do you think? > >>> > >>> Thanks, > >>> Ciara > >> > >> Hi Ciara, > >> > >> yes, ideally we should avoid usage of version-based check everywhere, > >> but I don't think that it is critical to switch at once. We can use it > >> for new checks right now and rewrite old/existing checks a bit later in > >> the next release. > >> > >> Please, note that my notes are related to review notes from Thomas who > >> asked by file_library() method is removed. Yes, it is confusing and it > >> is better to avoid it. Usage of feature-based checks would allow to > >> preserve find_library() as well. > > > > Thank you for the explanation. > > In this case we want to check that the libbpf library is <=v0.8.0. At this > moment in time v0.8.0 is the latest version of libbpf so we cannot check for a > symbol that tells us the library is > v0.8.0. Can you think of a way to > approach > this without using the pkg-config version check method? > > > > I've introduced this check to future-proof the PMD and ensure we only > ever link with versions of libbpf that we've validated to be compatible with > the PMD. When say v0.9.0 is released we can patch the PMD allowing for > libbpf <= v0.9.0 and make any necessary API changes as part of that patch. > This should hopefully help avoid the scenario Thomas encountered. > > Personally I'd consider such checks which limit version as a drawback. > I think checks on build should not be used to reject future versions. > Otherwise, introduction of any further even minor version would require > a patch to allow it. Documentation is the place for information about > validated versions. Build should not enforce it. Got it. I'll submit a v2 which removes the version-limiting and reinstates the cc.find_library() method. I'll update the documentation to indicate only versions up to v0.8.0 are supported and add a note to the release notes. Although if it's too late in the release cycle we can postpone this patch until after, and simply
RE: [PATCH] net/vhost: fix compliant offloading flag
> -Original Message-
> From: Maxime Coquelin
> Sent: Tuesday, June 28, 2022 5:57 PM
> To: Ding, Xuan ; Xia, Chenbo
> Cc: dev@dpdk.org; Ling, WeiX
> Subject: Re: [PATCH] net/vhost: fix compliant offloading flag
>
>
>
> On 6/28/22 11:42, xuan.d...@intel.com wrote:
> > From: Xuan Ding
> >
> > This patch fixes the check to set compliant offloading flag.
> > Compliant offloading flag should be set when the 'legacy-ol-flags' is
> > true.
> >
> > Fixes: 3a6ee8dafb21("net/vhost: enable compliant offloading mode")
> >
> > Signed-off-by: Xuan Ding
> > ---
> > drivers/net/vhost/rte_eth_vhost.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/vhost/rte_eth_vhost.c
> > b/drivers/net/vhost/rte_eth_vhost.c
> > index d75d256040..24049df58a 100644
> > --- a/drivers/net/vhost/rte_eth_vhost.c
> > +++ b/drivers/net/vhost/rte_eth_vhost.c
> > @@ -1735,7 +1735,7 @@ rte_pmd_vhost_probe(struct rte_vdev_device
> *dev)
> > goto out_free;
> > }
> >
> > - if (legacy_ol_flags == 0)
> > + if (legacy_ol_flags == 1)
> > flags |= RTE_VHOST_USER_NET_COMPLIANT_OL_FLAGS;
> >
> > if (dev->device.numa_node == SOCKET_ID_ANY)
>
> Nack, legacy OL flags is NOT compliant. So current implementation is good.
Sorry, it's a wrong fix, the compliant mode is enabled by default.
Regards,
Xuan
>
> Regards,
> Maxime
Re: [PATCH] crypto/qat: fix docsis segmentation fault
> On Mon, Jun 27, 2022 at 6:45 PM Rebecca Troy > wrote: > > > > Currently if AES or DES algorithms fail for Docsis test suite, a > > segmentation fault occurs when cryptodev_qat_autotest is ran. > > > > This is due to a duplicate call of EVP_CIPHER_CTX_free for the session > > context. Ctx is freed firstly in the bpi_cipher_ctx_init function and > > then again at the end of qat_sym_session_configure_cipher function. > > > > This commit fixes this bug by removing the first instance of > > EVP_CIPHER_CTX_free, leaving just the dedicated function in the upper > > level to free the ctx. > > This is awkward. > This helper should let *ctx alone until everything succeeded. > > -- > David Marchand Hi David, This bug was found under unusual circumstances. Unit tests failed due to no legacy algorithm support on the system, which caused a segmentation fault rather than the expected 'Tests failed' result. When these unit tests fail, the current error handling directs that the *ctx be freed twice - once prematurely (which is the instance this patch is removing) and then again after the tests have registered as failed, causing the segmentation fault. I agree that the *ctx shouldn't have been freed prematurely, so this patch fixes the incorrect error handling here by removing that first instance of *ctx freeing. Hope this clears things up. Rebecca Troy.
RE: [PATCH] net/vhost: fix compliant offloading flag
> -Original Message-
> From: Ding, Xuan
> Sent: Tuesday, June 28, 2022 6:29 PM
> To: Maxime Coquelin ; Xia, Chenbo
>
> Cc: dev@dpdk.org; Ling, WeiX
> Subject: RE: [PATCH] net/vhost: fix compliant offloading flag
>
>
>
> > -Original Message-
> > From: Maxime Coquelin
> > Sent: Tuesday, June 28, 2022 5:57 PM
> > To: Ding, Xuan ; Xia, Chenbo
> >
> > Cc: dev@dpdk.org; Ling, WeiX
> > Subject: Re: [PATCH] net/vhost: fix compliant offloading flag
> >
> >
> >
> > On 6/28/22 11:42, xuan.d...@intel.com wrote:
> > > From: Xuan Ding
> > >
> > > This patch fixes the check to set compliant offloading flag.
> > > Compliant offloading flag should be set when the 'legacy-ol-flags'
> > > is true.
> > >
> > > Fixes: 3a6ee8dafb21("net/vhost: enable compliant offloading mode")
> > >
> > > Signed-off-by: Xuan Ding
> > > ---
Tested-by: Wei Ling
Re: [PATCH] examples/distributor: update dynamic configuration
Hi David,
I have one more question. When I was working on new patch, I just want
to make sure what we are doing.
On 27.06.2022 18:51, Hunt, David wrote:
Hi Ömer,
I've a few comments:
On 21/06/2022 21:15, Abdullah Ömer Yamaç wrote:
--clipped--
@@ -39,6 +39,7 @@ volatile uint8_t quit_signal_rx;
volatile uint8_t quit_signal_dist;
volatile uint8_t quit_signal_work;
unsigned int power_lib_initialised;
+bool enable_lcore_rx_distributor;
static volatile struct app_stats {
struct {
--clipped--
@@ -724,7 +794,12 @@ main(int argc, char *argv[])
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid distributor parameters\n");
- if (rte_lcore_count() < 5)
+ if (enable_lcore_rx_distributor)
+ num_workers = rte_lcore_count() - 3;
+ else
+ num_workers = rte_lcore_count() - 4;
+
This could be "num_workers = rte_lcore_count() - (4 -
enable_lcore_rx_distributor)".
For the "if-else" case of enable_lcore_rx_distributor, we will reduce
the line of codes; but I am not sure about that change. Because the type
of the variable is bool and we are using arithmetic operation on that
variable. I think it is a little bit harder for people to understand
operation. Am I right? I can suggest one more solution. We may change
the data type to "unsigned int" or Is it okay to leave as before?
--clipped--
Re: [PATCH] crypto/qat: fix docsis segmentation fault
On Tue, Jun 28, 2022 at 12:32 PM Troy, Rebecca wrote:
>
> > On Mon, Jun 27, 2022 at 6:45 PM Rebecca Troy
> > wrote:
> > >
> > > Currently if AES or DES algorithms fail for Docsis test suite, a
> > > segmentation fault occurs when cryptodev_qat_autotest is ran.
> > >
> > > This is due to a duplicate call of EVP_CIPHER_CTX_free for the session
> > > context. Ctx is freed firstly in the bpi_cipher_ctx_init function and
> > > then again at the end of qat_sym_session_configure_cipher function.
> > >
> > > This commit fixes this bug by removing the first instance of
> > > EVP_CIPHER_CTX_free, leaving just the dedicated function in the upper
> > > level to free the ctx.
> >
> > This is awkward.
> > This helper should let *ctx alone until everything succeeded.
> >
> > --
> > David Marchand
>
> Hi David,
>
> This bug was found under unusual circumstances. Unit tests failed due to no
> legacy algorithm support on the system, which caused a segmentation fault
> rather than the expected 'Tests failed' result.
>
> When these unit tests fail, the current error handling directs that the *ctx
> be freed twice - once prematurely (which is the instance this patch is
> removing) and then again after the tests have registered as failed, causing
> the segmentation fault. I agree that the *ctx shouldn't have been freed
> prematurely, so this patch fixes the incorrect error handling here by
> removing that first instance of *ctx freeing.
My point is that bpi_cipher_ctx_init should not return an allocated
object on failure and hope that the caller would free it.
This is counter intuitive.
If someone starts using this helper somewhere else in the code and
does not free the ctx on failure, we will have a leak.
I see two alternatives to fix the issue in a cleaner way:
- either set *ctx to NULL on free,
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index e40c042ba9..b30396487e 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -136,8 +136,10 @@ bpi_cipher_ctx_init(enum
rte_crypto_cipher_algorithm cryptodev_algo,
return 0;
ctx_init_err:
- if (*ctx != NULL)
+ if (*ctx != NULL) {
EVP_CIPHER_CTX_free(*ctx);
+ *ctx = NULL;
+ }
return ret;
}
- or use a temp variable for the allocated cipher ctx object and store
it to *ctx only before returning 0, which was what I meant with my
initial comment.
--
David Marchand
Re: [PATCH] examples/distributor: update dynamic configuration
On 28/06/2022 12:06, Omer Yamac wrote:
Hi David,
I have one more question. When I was working on new patch, I just want
to make sure what we are doing.
On 27.06.2022 18:51, Hunt, David wrote:
Hi Ömer,
I've a few comments:
On 21/06/2022 21:15, Abdullah Ömer Yamaç wrote:
--clipped--
@@ -39,6 +39,7 @@ volatile uint8_t quit_signal_rx;
volatile uint8_t quit_signal_dist;
volatile uint8_t quit_signal_work;
unsigned int power_lib_initialised;
+bool enable_lcore_rx_distributor;
static volatile struct app_stats {
struct {
--clipped--
@@ -724,7 +794,12 @@ main(int argc, char *argv[])
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid distributor parameters\n");
- if (rte_lcore_count() < 5)
+ if (enable_lcore_rx_distributor)
+ num_workers = rte_lcore_count() - 3;
+ else
+ num_workers = rte_lcore_count() - 4;
+
This could be "num_workers = rte_lcore_count() - (4 -
enable_lcore_rx_distributor)".
For the "if-else" case of enable_lcore_rx_distributor, we will reduce
the line of codes; but I am not sure about that change. Because the
type of the variable is bool and we are using arithmetic operation on
that variable. I think it is a little bit harder for people to
understand operation. Am I right? I can suggest one more solution. We
may change the data type to "unsigned int" or Is it okay to leave as
before?
--clipped--
Hi Ömer,
You raise a good point about readability. Let's leave it as you had
it originally. Maybe just add a couple of one-line comments? "rx and
distributor combined, 3 fixed function cores" and "separate rx and
distributor, 4 fixed function cores?
Rgds,
Dave.
[PATCH] doc: announce changes to event vector structure
From: Pavan Nikhilesh The structure ``rte_event_vector`` will be modified to include ``elem_offset:12`` bits taken from ``rsvd:15``. The ``elem_offset`` defines the offset into the vector array from which valid elements are present. Signed-off-by: Pavan Nikhilesh --- doc/guides/rel_notes/deprecation.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..d7933629f2 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,10 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* eventdev: The structure ``rte_event_vector`` will be modified to include + ``elem_offset:12`` bits taken from ``rsvd:15``. The ``elem_offset`` defines + the offset into the vector array from which valid elements are present. + The difference between ``rte_event_vector::nb_elem`` and + ``rte_event_vector::elem_offset`` gives the number of valid elements left to + process from the ``rte_event_vector::elem_offset``. -- 2.25.1
Re: [PATCH v1] examples/fips_validation: add parsing for xts
On Tue, Jun 28, 2022 at 9:59 AM Gowrishankar Muthukrishnan
wrote:
>
> Added function to parse algorithm for AES XTS test.
>
> Signed-off-by: Gowrishankar Muthukrishnan
> ---
> examples/fips_validation/fips_validation.c| 4 +-
> examples/fips_validation/fips_validation.h| 17 ++-
> .../fips_validation/fips_validation_xts.c | 126 ++
> examples/fips_validation/main.c | 5 +
> 4 files changed, 150 insertions(+), 2 deletions(-)
>
> diff --git a/examples/fips_validation/fips_validation.c
> b/examples/fips_validation/fips_validation.c
> index 324abccb14..f181363ef7 100644
> --- a/examples/fips_validation/fips_validation.c
> +++ b/examples/fips_validation/fips_validation.c
> @@ -463,7 +463,9 @@ fips_test_parse_one_json_vector_set(void)
> else if (strstr(algo_str, "CMAC"))
> info.algo = FIPS_TEST_ALGO_AES_CMAC;
> else if (strstr(algo_str, "AES-CBC"))
> - info.algo = FIPS_TEST_ALGO_AES;
> + info.algo = FIPS_TEST_ALGO_AES_CBC;
Is this part related to adding xts support?
It looks more like a fix.
> + else if (strstr(algo_str, "AES-XTS"))
> + info.algo = FIPS_TEST_ALGO_AES_XTS;
> else
> return -EINVAL;
>
> diff --git a/examples/fips_validation/fips_validation.h
> b/examples/fips_validation/fips_validation.h
> index 69d738b718..8ae849c46f 100644
> --- a/examples/fips_validation/fips_validation.h
> +++ b/examples/fips_validation/fips_validation.h
> @@ -34,13 +34,14 @@
>
> enum fips_test_algorithms {
> FIPS_TEST_ALGO_AES = 0,
> + FIPS_TEST_ALGO_AES_CBC,
> FIPS_TEST_ALGO_AES_GCM,
> FIPS_TEST_ALGO_AES_CMAC,
> FIPS_TEST_ALGO_AES_CCM,
> + FIPS_TEST_ALGO_AES_XTS,
> FIPS_TEST_ALGO_HMAC,
> FIPS_TEST_ALGO_TDES,
> FIPS_TEST_ALGO_SHA,
> - FIPS_TEST_ALGO_AES_XTS,
> FIPS_TEST_ALGO_MAX
> };
>
> @@ -170,7 +171,17 @@ struct gcm_interim_data {
> uint8_t gen_iv;
> };
>
> +
No need for another blank line.
> #ifdef USE_JANSSON
> +enum xts_tweak_modes {
> + XTS_TWEAK_MODE_HEX = 0,
> + XTS_TWEAK_MODE_NUMBER
> +};
> +
> +struct xts_interim_data {
> + enum xts_tweak_modes tweak_mode;
> +};
> +
> struct fips_test_json_info {
> /* Information used for reading from json */
> json_t *json_root;
> @@ -207,6 +218,7 @@ struct fips_test_interim_info {
> struct ccm_interim_data ccm_data;
> struct sha_interim_data sha_data;
> struct gcm_interim_data gcm_data;
> + struct xts_interim_data xts_data;
> } interim_info;
>
> enum fips_test_op op;
> @@ -266,6 +278,9 @@ parse_test_cmac_json_init(void);
>
> int
> parse_test_aes_json_init(void);
> +
> +int
> +parse_test_xts_json_init(void);
> #endif /* USE_JANSSON */
>
> int
> diff --git a/examples/fips_validation/fips_validation_xts.c
> b/examples/fips_validation/fips_validation_xts.c
> index 5bb1966f6c..2de852c1fc 100644
> --- a/examples/fips_validation/fips_validation_xts.c
> +++ b/examples/fips_validation/fips_validation_xts.c
> @@ -24,6 +24,22 @@
> #define OP_ENC_STR "ENCRYPT"
> #define OP_DEC_STR "DECRYPT"
>
> +#define ALGO_JSON_STR "algorithm"
> +#define TESTTYPE_JSON_STR "testType"
> +#define DIR_JSON_STR "direction"
> +#define KEYLEN_JSON_STR"keyLen"
> +#define TWEAKMODE_JSON_STR "tweakMode"
> +
> +#define KEY_JSON_STR "key"
> +#define DATAUNITLEN_JSON_STR "dataUnitLen"
> +#define PAYLOADLEN_JSON_STR"payloadLen"
> +#define TWEAKVALUE_JSON_STR"tweakValue"
> +#define PT_JSON_STR"pt"
> +#define CT_JSON_STR"ct"
> +
> +#define OP_ENC_JSON_STR"encrypt"
> +#define OP_DEC_JSON_STR"decrypt"
> +
> static int
> parse_interim_xts_enc_dec(const char *key,
> __rte_unused char *text,
> @@ -62,6 +78,116 @@ struct fips_test_callback xts_writeback_callbacks[] = {
> {NULL, NULL, NULL} /**< end pointer */
> };
>
> +#ifdef RTE_HAS_JANSSON
Code in examples can't rely on internal RTE_HAS_JANSSON.
--
David Marchand
Re: [PATCH] examples/distributor: update dynamic configuration
Hi,
Here is the final version. If it is ok, I will test the code and
publish.
if (enable_lcore_rx_distributor){
// rx and distributor combined, 3 fixed function cores (stat, TX, at
least 1 worker)
min_cores = 4;
num_workers = rte_lcore_count() - 3;
}
else{
// separate rx and distributor, 3 fixed function cores (stat, TX, at
least 1 worker)
min_cores = 5;
num_workers = rte_lcore_count() - 4;
}
On 28.06.2022 14:25, Hunt, David wrote:
On 28/06/2022 12:06, Omer Yamac wrote:
Hi David,
I have one more question. When I was working on new patch, I just want
to make sure what we are doing.
On 27.06.2022 18:51, Hunt, David wrote:
Hi Ömer,
I've a few comments:
On 21/06/2022 21:15, Abdullah Ömer Yamaç wrote:
--clipped--
@@ -39,6 +39,7 @@ volatile uint8_t quit_signal_rx;
volatile uint8_t quit_signal_dist;
volatile uint8_t quit_signal_work;
unsigned int power_lib_initialised;
+bool enable_lcore_rx_distributor;
static volatile struct app_stats {
struct {
--clipped--
@@ -724,7 +794,12 @@ main(int argc, char *argv[])
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid distributor
parameters\n");
- if (rte_lcore_count() < 5)
+ if (enable_lcore_rx_distributor)
+ num_workers = rte_lcore_count() - 3;
+ else
+ num_workers = rte_lcore_count() - 4;
+
This could be "num_workers = rte_lcore_count() - (4 -
enable_lcore_rx_distributor)".
For the "if-else" case of enable_lcore_rx_distributor, we will reduce
the line of codes; but I am not sure about that change. Because the
type of the variable is bool and we are using arithmetic operation on
that variable. I think it is a little bit harder for people to
understand operation. Am I right? I can suggest one more solution. We
may change the data type to "unsigned int" or Is it okay to leave as
before?
--clipped--
Hi Ömer,
You raise a good point about readability. Let's leave it as you had
it originally. Maybe just add a couple of one-line comments? "rx and
distributor combined, 3 fixed function cores" and "separate rx and
distributor, 4 fixed function cores?
Rgds,
Dave.
RE: [PATCH v4] app/test: add additional stream cipher tests
> -Original Message- > From: Tejasree Kondoj > Sent: Thursday 23 June 2022 19:20 > To: Akhil Goyal ; Power, Ciara ; > Zhang, Roy Fan > Cc: Anoob Joseph ; Ankur Dwivedi > ; dev@dpdk.org > Subject: [PATCH v4] app/test: add additional stream cipher tests > > Adding zuc, snow3g and aes-ctr-cmac auth-cipher test vectors with same auth > and cipher offsets and total digest data encrypted. > Existing tests have different cipher and auth offsets and partial or no digest > encrypted. > > Signed-off-by: Tejasree Kondoj > --- > v4: > * Set last 3 bytes of IV to zero in each 8 byte block > > v3: > * Modified IV of test vectors as per specification > > v2: > * Removed cn9k PMD checks > > app/test/test_cryptodev.c | 270 ++ > app/test/test_cryptodev_mixed_test_vectors.h | 194 + > app/test/test_cryptodev_snow3g_test_vectors.h | 67 + > app/test/test_cryptodev_zuc_test_vectors.h| 77 + > 4 files changed, 608 insertions(+) Thanks for updating those vectors to match spec. Acked-by: Ciara Power
[PATCH] doc: announce change in crypto adapter queue add
The function `rte_event_crypto_adapter_queue_pair_add` will accept `rte_event_crypto_adapter_queue_conf` argument instead of `rte_event`. Signed-off-by: Volodymyr Fialko --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..63a6459f17 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,9 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* eventdev: The function ``rte_event_crypto_adapter_queue_pair_add`` will + accept configuration of type ``rte_event_crypto_adapter_queue_conf`` instead + of ``rte_event``, similar to ``rte_event_eth_rx_adapter_queue_add`` signature. + Event will be one of the configuration fields, together with additional + vector parameters. -- 2.25.1
RE: [PATCH v4] app/test: add additional stream cipher tests
> > Adding zuc, snow3g and aes-ctr-cmac auth-cipher test vectors with same auth > > and cipher offsets and total digest data encrypted. > > Existing tests have different cipher and auth offsets and partial or no > > digest > > encrypted. > > > > Signed-off-by: Tejasree Kondoj > > --- > Thanks for updating those vectors to match spec. > > Acked-by: Ciara Power Applied to dpdk-next-crypto Thanks.
RE: [EXT] [PATCH v1] baseband/acc100: remove file prefix for internal file
> File renamed to avoid the rte_ file prefix since rte_acc100_pmd.h > is actually internal only. > > Signed-off-by: Nicolas Chautru Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks.
[PATCH v2] net/af_xdp: make compatible with libbpf v0.8.0
libbpf v0.8.0 deprecates the bpf_get_link_xdp_id and bpf_set_link_xdp_fd
functions. Use meson to detect if libbpf >= v0.7.0 is linked and if so, use
the recommended replacement functions bpf_xdp_query_id, bpf_xdp_attach
and bpf_xdp_detach which are available to use since libbpf v0.7.0.
Signed-off-by: Ciara Loftus
---
v2:
* Updated release notes
* Removed version limiting to libbpf v0.8.0
---
doc/guides/nics/af_xdp.rst | 3 ++-
doc/guides/rel_notes/release_22_07.rst | 4 +++
drivers/net/af_xdp/compat.h| 36 +-
drivers/net/af_xdp/meson.build | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c| 19 +++---
5 files changed, 45 insertions(+), 19 deletions(-)
diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index d42e0f1f79..ca23940e22 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -45,7 +45,8 @@ Prerequisites
This is a Linux-specific PMD, thus the following prerequisites apply:
* A Linux Kernel (version > v4.18) with XDP sockets configuration enabled;
-* Both libxdp >=v1.2.2 and libbpf libraries installed, or, libbpf <=v0.6.0
+* Both libxdp >=v1.2.2 and libbpf <=v0.8.0 libraries installed, or, libbpf
+ <=v0.6.0.
* If using libxdp, it requires an environment variable called
LIBXDP_OBJECT_PATH to be set to the location of where libxdp placed its bpf
object files. This is usually in /usr/local/lib/bpf or /usr/local/lib64/bpf.
diff --git a/doc/guides/rel_notes/release_22_07.rst
b/doc/guides/rel_notes/release_22_07.rst
index 6365800313..562d12abb2 100644
--- a/doc/guides/rel_notes/release_22_07.rst
+++ b/doc/guides/rel_notes/release_22_07.rst
@@ -125,6 +125,10 @@ New Features
* Added new devargs option ``max_conf_threads``
defining the number of management threads for parallel configurations.
+* **Updated AF_XDP PMD.**
+
+ * Made compatible with libbpf v0.8.0 (when used with libxdp).
+
* **Updated Amazon ena driver.**
The new driver version (v2.7.0) includes:
diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h
index 28ea64aeaa..8f4ac8b5ea 100644
--- a/drivers/net/af_xdp/compat.h
+++ b/drivers/net/af_xdp/compat.h
@@ -60,7 +60,7 @@ tx_syscall_needed(struct xsk_ring_prod *q __rte_unused)
}
#endif
-#ifdef RTE_NET_AF_XDP_LIBBPF_OBJ_OPEN
+#ifdef RTE_NET_AF_XDP_LIBBPF_V070
static int load_program(const char *prog_path, struct bpf_object **obj)
{
struct bpf_program *prog;
@@ -85,6 +85,23 @@ static int load_program(const char *prog_path, struct
bpf_object **obj)
bpf_object__close(*obj);
return -1;
}
+
+static int
+remove_xdp_program(int ifindex)
+{
+ uint32_t curr_prog_id = 0;
+
+ if (bpf_xdp_query_id(ifindex, XDP_FLAGS_UPDATE_IF_NOEXIST,
+ &curr_prog_id))
+ return -1;
+
+ return bpf_xdp_detach(ifindex, XDP_FLAGS_UPDATE_IF_NOEXIST, NULL);
+}
+
+static int link_xdp_prog_with_dev(int ifindex, int fd, __u32 flags)
+{
+ return bpf_xdp_attach(ifindex, fd, flags, NULL);
+}
#else
static int load_program(const char *prog_path, struct bpf_object **obj)
{
@@ -96,4 +113,21 @@ static int load_program(const char *prog_path, struct
bpf_object **obj)
return prog_fd;
}
+
+static int
+remove_xdp_program(int ifindex)
+{
+ uint32_t curr_prog_id = 0;
+
+ if (bpf_get_link_xdp_id(ifindex, &curr_prog_id,
+ XDP_FLAGS_UPDATE_IF_NOEXIST))
+ return -1;
+
+ return bpf_set_link_xdp_fd(ifindex, -1, XDP_FLAGS_UPDATE_IF_NOEXIST);
+}
+
+static int link_xdp_prog_with_dev(int ifindex, int fd, __u32 flags)
+{
+ return bpf_set_link_xdp_fd(ifindex, fd, flags);
+}
#endif
diff --git a/drivers/net/af_xdp/meson.build b/drivers/net/af_xdp/meson.build
index 1e0de23705..6075a69c00 100644
--- a/drivers/net/af_xdp/meson.build
+++ b/drivers/net/af_xdp/meson.build
@@ -25,7 +25,7 @@ if cc.has_header('linux/if_xdp.h')
bpf_ver_dep = dependency('libbpf', version : '>=0.7.0',
required: false, method: 'pkg-config')
if bpf_ver_dep.found()
-cflags += ['-DRTE_NET_AF_XDP_LIBBPF_OBJ_OPEN']
+cflags += ['-DRTE_NET_AF_XDP_LIBBPF_V070']
endif
else
build = false
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index fce649c2a1..355130087a 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -866,20 +866,6 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
-static void
-remove_xdp_program(struct pmd_internals *internals)
-{
- uint32_t curr_prog_id = 0;
-
- if (bpf_get_link_xdp_id(internals->if_index, &curr_prog_id,
- XDP_FLAGS_UPDATE_IF_NOEXIST)) {
- AF_XDP_LOG(ERR, "bpf_get_link_xdp_id failed\n");
- return;
- }
- bpf_set_link_xdp_fd(internal
RE: [PATCH] crypto/cnxk: predecrement esn value to be used in session
> ESN provided in the session would be the next sequence number to be > used. Hence predecrement the value, so that in datapath, incremented > value will be as expected. > > Signed-off-by: Anoob Joseph Applied to dpdk-next-crypto Thanks.
Re: [PATCH] examples/distributor: update dynamic configuration
On 28/06/2022 13:06, Omer Yamac wrote:
Hi,
Here is the final version. If it is ok, I will test the code and publish.
if (enable_lcore_rx_distributor){
// rx and distributor combined, 3 fixed function cores (stat, TX, at
least 1 worker)
min_cores = 4;
num_workers = rte_lcore_count() - 3;
}
else{
// separate rx and distributor, 3 fixed function cores (stat, TX, at
least 1 worker)
min_cores = 5;
num_workers = rte_lcore_count() - 4;
}
Hi Ömer,
Please use standard comment formatting (look elsewhere for examples).
I'm not sure you need min_cores any more.
Rgds,
Dave.
--snip--
RE: [PATCH] doc: announce change in crypto adapter queue add
> Subject: [PATCH] doc: announce change in crypto adapter queue add > > The function `rte_event_crypto_adapter_queue_pair_add` will accept > `rte_event_crypto_adapter_queue_conf` argument instead of `rte_event`. > > Signed-off-by: Volodymyr Fialko Acked-by: Akhil Goyal
[PATCH v2] example/fips_validation: handle empty payload
Allocate at least onebyte to handle empty payload in a test vector
when defined.
Fixes: 3d0fad56b74 ("examples/fips_validation: add crypto FIPS application")
Cc: sta...@dpdk.org
Signed-off-by: Gowrishankar Muthukrishnan
---
v2:
- commit message corrections.
---
examples/fips_validation/fips_validation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 94e31abf83..324abccb14 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -630,7 +630,7 @@ parse_uint8_hex_str(const char *key, char *src, struct
fips_val *val)
val->val = NULL;
}
- val->val = rte_zmalloc(NULL, len, 0);
+ val->val = rte_zmalloc(NULL, len + 1, 0);
if (!val->val)
return -ENOMEM;
--
2.25.1
[PATCH v2] examples/fips_validation: add parsing for xts
Added function to parse algorithm for AES XTS test.
Signed-off-by: Gowrishankar Muthukrishnan
---
v2:
- build failure fixed if no jansson lib available.
---
examples/fips_validation/fips_validation.c| 4 +-
examples/fips_validation/fips_validation.h| 16 +-
.../fips_validation/fips_validation_xts.c | 141 ++
examples/fips_validation/main.c | 5 +
4 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 324abccb14..f181363ef7 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -463,7 +463,9 @@ fips_test_parse_one_json_vector_set(void)
else if (strstr(algo_str, "CMAC"))
info.algo = FIPS_TEST_ALGO_AES_CMAC;
else if (strstr(algo_str, "AES-CBC"))
- info.algo = FIPS_TEST_ALGO_AES;
+ info.algo = FIPS_TEST_ALGO_AES_CBC;
+ else if (strstr(algo_str, "AES-XTS"))
+ info.algo = FIPS_TEST_ALGO_AES_XTS;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index 69d738b718..d716b198c6 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -34,13 +34,14 @@
enum fips_test_algorithms {
FIPS_TEST_ALGO_AES = 0,
+ FIPS_TEST_ALGO_AES_CBC,
FIPS_TEST_ALGO_AES_GCM,
FIPS_TEST_ALGO_AES_CMAC,
FIPS_TEST_ALGO_AES_CCM,
+ FIPS_TEST_ALGO_AES_XTS,
FIPS_TEST_ALGO_HMAC,
FIPS_TEST_ALGO_TDES,
FIPS_TEST_ALGO_SHA,
- FIPS_TEST_ALGO_AES_XTS,
FIPS_TEST_ALGO_MAX
};
@@ -170,6 +171,15 @@ struct gcm_interim_data {
uint8_t gen_iv;
};
+enum xts_tweak_modes {
+ XTS_TWEAK_MODE_HEX = 0,
+ XTS_TWEAK_MODE_NUMBER
+};
+
+struct xts_interim_data {
+ enum xts_tweak_modes tweak_mode;
+};
+
#ifdef USE_JANSSON
struct fips_test_json_info {
/* Information used for reading from json */
@@ -207,6 +217,7 @@ struct fips_test_interim_info {
struct ccm_interim_data ccm_data;
struct sha_interim_data sha_data;
struct gcm_interim_data gcm_data;
+ struct xts_interim_data xts_data;
} interim_info;
enum fips_test_op op;
@@ -266,6 +277,9 @@ parse_test_cmac_json_init(void);
int
parse_test_aes_json_init(void);
+
+int
+parse_test_xts_json_init(void);
#endif /* USE_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_xts.c
b/examples/fips_validation/fips_validation_xts.c
index 5bb1966f6c..531e3c688e 100644
--- a/examples/fips_validation/fips_validation_xts.c
+++ b/examples/fips_validation/fips_validation_xts.c
@@ -24,6 +24,22 @@
#define OP_ENC_STR "ENCRYPT"
#define OP_DEC_STR "DECRYPT"
+#define ALGO_JSON_STR "algorithm"
+#define TESTTYPE_JSON_STR "testType"
+#define DIR_JSON_STR "direction"
+#define KEYLEN_JSON_STR"keyLen"
+#define TWEAKMODE_JSON_STR "tweakMode"
+
+#define KEY_JSON_STR "key"
+#define DATAUNITLEN_JSON_STR "dataUnitLen"
+#define PAYLOADLEN_JSON_STR"payloadLen"
+#define TWEAKVALUE_JSON_STR"tweakValue"
+#define PT_JSON_STR"pt"
+#define CT_JSON_STR"ct"
+
+#define OP_ENC_JSON_STR"encrypt"
+#define OP_DEC_JSON_STR"decrypt"
+
static int
parse_interim_xts_enc_dec(const char *key,
__rte_unused char *text,
@@ -62,6 +78,131 @@ struct fips_test_callback xts_writeback_callbacks[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef USE_JANSSON
+static int
+parser_xts_read_keylen(const char *key, char *src, struct fips_val *val)
+{
+ int ret;
+
+ ret = parser_read_uint32_bit_val(key, src, val);
+ if (ret < 0)
+ return ret;
+
+ val->len *= 2;
+ return 0;
+}
+
+static int
+parser_xts_read_tweakval(const char *key, char *src, struct fips_val *val)
+{
+ int ret;
+
+ if (info.interim_info.xts_data.tweak_mode == XTS_TWEAK_MODE_HEX)
+ ret = parse_uint8_hex_str(key, src, val);
+ else if (info.interim_info.xts_data.tweak_mode == XTS_TWEAK_MODE_NUMBER)
+ ret = parser_read_uint32_bit_val(key, src, val);
+ else
+ ret = -1;
+
+ return ret;
+}
+
+struct fips_test_callback xts_dec_json_vectors[] = {
+ {KEY_JSON_STR, parse_uint8_known_len_hex_str,
&vec.cipher_auth.key},
+ {TWEAKVALUE_JSON_STR, parser_xts_read_tweakval, &vec.iv},
+ {CT_JSON_STR, parse_uint8_hex_str, &vec.ct},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+
+struct fips_test_callback xts_interim_json_vectors[] = {
+ {KEYLEN_JSON_STR, parser_xts_read_keylen, &vec.cipher_aut
[PATCH v1] examples/fips_validation: add parsing for sha
Added function to parse algorithm for SHA test. Verified with SHA 1 and 256
vectors. SHA 384 and 512 has some issues with the way jansson objects are
created, which could be addressed separately.
Signed-off-by: Gowrishankar Muthukrishnan
---
examples/fips_validation/fips_validation.c| 2 +
examples/fips_validation/fips_validation.h| 10 +
.../fips_validation/fips_validation_sha.c | 188 ++
examples/fips_validation/main.c | 37 +++-
4 files changed, 226 insertions(+), 11 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index f181363ef7..12b9b03f56 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -466,6 +466,8 @@ fips_test_parse_one_json_vector_set(void)
info.algo = FIPS_TEST_ALGO_AES_CBC;
else if (strstr(algo_str, "AES-XTS"))
info.algo = FIPS_TEST_ALGO_AES_XTS;
+ else if (strstr(algo_str, "SHA"))
+ info.algo = FIPS_TEST_ALGO_SHA;
else
return -EINVAL;
diff --git a/examples/fips_validation/fips_validation.h
b/examples/fips_validation/fips_validation.h
index d716b198c6..5c1abcbd91 100644
--- a/examples/fips_validation/fips_validation.h
+++ b/examples/fips_validation/fips_validation.h
@@ -133,6 +133,7 @@ enum fips_ccm_test_types {
enum fips_sha_test_types {
SHA_KAT = 0,
+ SHA_AFT,
SHA_MCT
};
@@ -280,6 +281,15 @@ parse_test_aes_json_init(void);
int
parse_test_xts_json_init(void);
+
+int
+parse_test_sha_json_init(void);
+
+int
+parse_test_sha_json_algorithm(void);
+
+int
+parse_test_sha_json_test_type(void);
#endif /* USE_JANSSON */
int
diff --git a/examples/fips_validation/fips_validation_sha.c
b/examples/fips_validation/fips_validation_sha.c
index 34c364c75a..a2928618d7 100644
--- a/examples/fips_validation/fips_validation_sha.c
+++ b/examples/fips_validation/fips_validation_sha.c
@@ -17,6 +17,11 @@
#define SEED_STR "Seed = "
#define MCT_STR"Monte"
+#define ALGO_JSON_STR "algorithm"
+#define TESTTYPE_JSON_STR "testType"
+
+#define PT_JSON_STR"msg"
+
struct plain_hash_size_conversion {
const char *str;
enum rte_crypto_auth_algorithm algo;
@@ -62,6 +67,32 @@ struct fips_test_callback sha_tests_interim_vectors[] = {
{NULL, NULL, NULL} /**< end pointer */
};
+#ifdef USE_JANSSON
+static struct {
+ uint32_t type;
+ const char *desc;
+} sha_test_types[] = {
+ {SHA_MCT, "MCT"},
+ {SHA_AFT, "AFT"},
+};
+
+static struct plain_hash_algorithms {
+ const char *str;
+ enum rte_crypto_auth_algorithm algo;
+} json_algorithms[] = {
+ {"SHA-1", RTE_CRYPTO_AUTH_SHA1},
+ {"SHA2-224", RTE_CRYPTO_AUTH_SHA224},
+ {"SHA2-256", RTE_CRYPTO_AUTH_SHA256},
+ {"SHA2-384", RTE_CRYPTO_AUTH_SHA384},
+ {"SHA2-512", RTE_CRYPTO_AUTH_SHA512},
+};
+
+struct fips_test_callback sha_tests_json_vectors[] = {
+ {PT_JSON_STR, parse_uint8_hex_str, &vec.pt},
+ {NULL, NULL, NULL} /**< end pointer */
+};
+#endif /* USE_JANSSON */
+
static int
parse_test_sha_writeback(struct fips_val *val) // !
{
@@ -108,3 +139,160 @@ parse_test_sha_init(void)
info.kat_check = rsp_test_sha_check;
return 0;
}
+
+#ifdef USE_JANSSON
+static int
+parse_test_sha_json_writeback(struct fips_val *val)
+{
+ struct fips_val val_local;
+ json_t *tcId, *md;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+
+ json_info.json_write_case = json_object();
+ json_object_set_new(json_info.json_write_case, "tcId", tcId);
+
+ val_local.val = val->val + vec.pt.len;
+ val_local.len = vec.cipher_auth.digest.len;
+
+ writeback_hex_str("", info.one_line_text, &val_local);
+ md = json_string(info.one_line_text);
+ json_object_set_new(json_info.json_write_case, "md", md);
+
+ return 0;
+}
+
+static int
+parse_test_sha_mct_json_writeback(struct fips_val *val)
+{
+ json_t *tcId, *msg, *md, *resArr, *res;
+ struct fips_val val_local;
+
+ tcId = json_object_get(json_info.json_test_case, "tcId");
+ if (json_info.json_write_case) {
+ json_t *wcId;
+
+ wcId = json_object_get(json_info.json_write_case, "tcId");
+ if (!json_equal(tcId, wcId)) {
+ json_info.json_write_case = json_object();
+ json_object_set_new(json_info.json_write_case, "tcId",
tcId);
+ json_object_set_new(json_info.json_write_case,
"resultsArray",
+ json_array());
+ }
+ } else {
+ json_info.json_write_case = json_object();
+ json_object_set_new(json_info.json_write_case, "tcId", tcId);
+
Re: [PATCH V5 2/7] app/testpmd: unify the name of L2 payload offload
On 6/25/2022 3:12 AM, lihuisong (C) wrote:
在 2022/6/24 21:53, Ferruh Yigit 写道:
On 6/24/2022 8:23 AM, Huisong Li wrote:
Currently, the "port config all rss xx" command uses 'ether' name to
match
and to set 'RTE_ETH_RSS_L2_PAYLOAD' offload. However, others RSS
command,
such as, "port config rss-hash-key" and "show port
rss-hash key", use 'l2-payload' to represent this offload. So this patch
unifies the name of 'RTE_ETH_RSS_L2_PAYLOAD' offload.
Signed-off-by: Huisong Li
ack
But I wonder if we should continue to support 'ether' with an
exception to not break the interface, at least for a while like to
next LTS.
It's supposed to have a very small impact, and it is just an optional input
of this command in testpmd. What's more, patch 3/7 has to use
"l2-payload" to
match. This shouldn't affect the optimization progress of "port config
all rss xx"
command, right?
Yes, impact is small, OK to rename. But can you please add a release
note update to inform any possible user. A brief, one line update is
good to say "testpmd RSS type 'ether' renamed to 'l2-payload'"
---
app/test-pmd/cmdline.c | 6 +++---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9a7fd5fc35..a701bac953 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -694,7 +694,7 @@ static void cmd_help_long_parsed(void
*parsed_result,
"receive buffers available.\n\n"
"port config all rss (all|default|ip|tcp|udp|sctp|"
-
"ether|port|vxlan|geneve|nvgre|vxlan-gpe|ecpri|mpls|ipv4-chksum|l2tpv2|"
+
"l2-payload|port|vxlan|geneve|nvgre|vxlan-gpe|ecpri|mpls|ipv4-chksum|l2tpv2|"
"none|level-default|level-outer|level-inner|)\n"
" Set the RSS mode.\n\n"
@@ -2080,7 +2080,7 @@ cmd_config_rss_parsed(void *parsed_result,
rss_conf.rss_hf = RTE_ETH_RSS_TCP;
else if (!strcmp(res->value, "sctp"))
rss_conf.rss_hf = RTE_ETH_RSS_SCTP;
- else if (!strcmp(res->value, "ether"))
+ else if (!strcmp(res->value, "l2_payload"))
rss_conf.rss_hf = RTE_ETH_RSS_L2_PAYLOAD;
else if (!strcmp(res->value, "port"))
rss_conf.rss_hf = RTE_ETH_RSS_PORT;
@@ -2203,7 +2203,7 @@ static cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
.help_str = "port config all rss "
- "all|default|eth|vlan|ip|tcp|udp|sctp|ether|port|vxlan|geneve|"
+ "all|default|eth|vlan|ip|tcp|udp|sctp|l2-payload|port|vxlan|geneve|"
"nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|ipv4-chksum|l2tpv2|"
"none|level-default|level-outer|level-inner|",
.tokens = {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 0b7a53fdf1..cc299cff6c 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -2144,7 +2144,7 @@ port config - RSS
Set the RSS (Receive Side Scaling) mode on or off::
- testpmd> port config all rss
(all|default|eth|vlan|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|l2tpv2|none)
+ testpmd> port config all rss
(all|default|eth|vlan|ip|tcp|udp|sctp|l2-payload|port|vxlan|geneve|nvgre|vxlan-gpe|l2tpv3|esp|ah|pfcp|ecpri|mpls|l2tpv2|none)
RSS is on by default.
.
Re: [PATCH V5 1/7] app/testpmd: fix supported RSS offload display
On 6/25/2022 3:12 AM, lihuisong (C) wrote:
在 2022/6/24 21:01, Ferruh Yigit 写道:
On 6/24/2022 8:23 AM, Huisong Li wrote:
The rte_eth_dev_info.flow_type_rss_offloads is populated in terms of
RTE_ETH_RSS_* bits. If PMD sets RTE_ETH_RSS_L3_SRC_ONLY to
dev_info->flow_type_rss_offloads. testpmd will display "user defined 63"
when run 'show port info 0'. Because testpmd use flowtype_to_str()
to display the supported RSS offload of PMD. In fact, the function is
used to display flow type in FDIR commands for i40e or ixgbe. This patch
uses the RTE_ETH_RSS_* bits to display supported RSS offload of PMD.
In addition, offloads that are not in rss_type_table[] should be
displayed
as "unknown offload xxx", instead of "user defined 63". So this patch
fixes
it.
There is something as "user defined" RSS type, so please keep it as it
is.
For more details please check:
Commit 8b94c81e3341 ("app/testpmd: port info prints dynamically mapped
flow types")
Commit 5a4806d304e0 ("app/testpmd: support updating pctype mapping")
Simply this is to allow doing RSS on user defined protocols, supported
by plugging like Intel DDP.
All right.
Fixes: b12964f621dc ("ethdev: unification of RSS offload types")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Ferruh Yigit
---
app/test-pmd/config.c | 40 ++--
app/test-pmd/testpmd.h | 2 ++
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 62833fe97c..36a828307c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -66,8 +66,6 @@
#define NS_PER_SEC 1E9
-static char *flowtype_to_str(uint16_t flow_type);
-
static const struct {
enum tx_pkt_split split;
const char *name;
@@ -675,6 +673,19 @@ print_dev_capabilities(uint64_t capabilities)
}
}
+const char *
+rsstypes_to_str(uint64_t rss_type)
+{
+ uint16_t i;
+
+ for (i = 0; rss_type_table[i].str != NULL; i++) {
+ if (rss_type_table[i].rss_type == rss_type)
+ return rss_type_table[i].str;
+ }
+
+ return NULL;
+}
+
void
port_infos_display(portid_t port_id)
{
@@ -779,19 +790,20 @@ port_infos_display(portid_t port_id)
if (!dev_info.flow_type_rss_offloads)
printf("No RSS offload flow type is supported.\n");
else {
+ uint64_t rss_offload_types =
dev_info.flow_type_rss_offloads;
uint16_t i;
- char *p;
printf("Supported RSS offload flow types:\n");
- for (i = RTE_ETH_FLOW_UNKNOWN + 1;
- i < sizeof(dev_info.flow_type_rss_offloads) *
CHAR_BIT; i++) {
- if (!(dev_info.flow_type_rss_offloads & (1ULL
<< i)))
- continue;
- p = flowtype_to_str(i);
- if (p)
- printf(" %s\n", p);
- else
- printf(" user defined %d\n", i);
+ for (i = 0; i < sizeof(rss_offload_types) * CHAR_BIT;
i++) {
+ uint64_t rss_offload = RTE_BIT64(i);
This logic is wrong, as we talked before some RSS types can be
multiple bit, with about logic you can't catch them.
The logic in the V2 of this set [1] is correct, which walks through
'rss_type_table[]' array and check if any value in that array exists
in 'flow_type_rss_offloads'.
[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220425092523.52338-2-lihuis...@huawei.com/
Here is what I think. They have different purposes. The logic of current
patch
is to retain the original display behavior that is single bit offload and
"user defined xx". However, the logic in the V2 has changed the behavior.
I don't think this patch should change its original behavior. And it is
better
to print offload by single bit. In this way, the parsed offload
capability is
more accurate and convenient to use.
OK, lets keep original behavior.
Since 'rss_type_table[]' array has both single bit and combined bit
entries, same array can work for both purposes.
+ if ((rss_offload_types & rss_offload) != 0) {
+ const char *p =
rsstypes_to_str(rss_offload);
+ if (p)
+ printf(" %s\n", p);
+ else
+ printf("
unknown_offload(BIT(%u))\n",
+ i);
+ }
}
}
@@ -5604,6 +5616,8 @@ set_record_burst_stats(uint8_t on_off)
record_burst_stats = on_off;
}
+#if defined(RTE_NET_I40E) || defined(RTE_NET_IXGBE)
+
static char*
flowtype_to_str(uint16_t flow_type)
{
@@ -5647,8 +5661,6 @@ flowtype_to_str(uint16_t flow_type)
return NULL;
}
-#if defined(RTE_NET_I40E) || defin
Re: [PATCH V5 5/7] app/testpmd: compact RSS types output in some commands
On 6/25/2022 3:13 AM, lihuisong (C) wrote:
在 2022/6/24 22:04, Ferruh Yigit 写道:
On 6/24/2022 8:23 AM, Huisong Li wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
From: Ferruh Yigit
In port info command output, 'show port info all', supported RSS offload
types printed one type per line, and although this information is not
most important part of the command it takes big part of the command
output.
In port RSS hash and flow RSS command output, 'show port 0 rss-hash',
and 'flow query 0 0 rss', all enabled RSS types are printed on one line.
If there are many types, the print will be very long.
Compacting these RSS offloads and types output by fixing the length
of the
character string printed on each line, instead of one per line or one
line.
Output becomes as following:
Supported RSS offload flow types:
ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other
ipv6-frag ipv6-tcp ipv6-udp ipv6-sctp ipv6-other
l4-dst-only l4-src-only l3-dst-only l3-src-only
Signed-off-by: Ferruh Yigit
Signed-off-by: Huisong Li
---
app/test-pmd/config.c | 68 +++---
app/test-pmd/testpmd.h | 2 ++
2 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index a0a5f12c71..b3cb68003c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -699,6 +699,38 @@ rsstypes_to_str(uint64_t rss_type)
return NULL;
}
+static void
+rss_offload_types_display(uint64_t offload_types, uint16_t
char_num_per_line)
+{
+ uint16_t unknown_offload_str_len;
+ uint16_t total_len = 0;
+ uint16_t str_len = 0;
+ uint64_t rss_offload;
+ uint16_t i;
+
+ for (i = 0; i < sizeof(offload_types) * CHAR_BIT; i++) {
+ rss_offload = RTE_BIT64(i);
+ if ((offload_types & rss_offload) != 0) {
+ const char *p = rsstypes_to_str(rss_offload);
+
+ unknown_offload_str_len =
+ strlen("unknown_offload(BIT())") + (i
/ 10 + 1);
+ str_len = p ? strlen(p) :
unknown_offload_str_len;
+ str_len += 2; /* add two spaces */
+ if (total_len + str_len >= char_num_per_line) {
+ total_len = 0;
+ printf("\n");
+ }
+
+ if (p)
+ printf(" %s", p);
+ else
+ printf(" unknown_offload(BIT(%u))", i);
+ total_len += str_len;
+ }
+ }
+}
+
void
port_infos_display(portid_t port_id)
{
@@ -803,21 +835,10 @@ port_infos_display(portid_t port_id)
if (!dev_info.flow_type_rss_offloads)
printf("No RSS offload flow type is supported.\n");
else {
- uint64_t rss_offload_types =
dev_info.flow_type_rss_offloads;
- uint16_t i;
-
printf("Supported RSS offload flow types:\n");
- for (i = 0; i < sizeof(rss_offload_types) * CHAR_BIT;
i++) {
- uint64_t rss_offload = RTE_BIT64(i);
- if ((rss_offload_types & rss_offload) != 0) {
- const char *p =
rsstypes_to_str(rss_offload);
- if (p)
- printf(" %s\n", p);
- else
- printf("
unknown_offload(BIT(%u))\n",
- i);
- }
- }
+ rss_offload_types_display(dev_info.flow_type_rss_offloads,
+ TESTPMD_RSS_TYPES_CHAR_NUM_PER_LINE);
+ printf("\n");
Why 'rss_types_display()' is not reused, but new function
'rss_offload_types_display()' created?
As mentioned in the 1/7 patch reply, there are different purposes.
OK. Lets continue as it is.
Re: [PATCH V5 0/7] app/testpmd: fix RSS and flow type
On 6/25/2022 2:09 AM, lihuisong (C) wrote: 在 2022/6/24 18:44, Ferruh Yigit 写道: On 6/24/2022 10:54 AM, lihuisong (C) wrote: CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. Hi David, 在 2022/6/24 16:59, David Marchand 写道: On Fri, Jun 24, 2022 at 10:55 AM lihuisong (C) wrote: Hi Ferruh, This patchset has been sent. However, a merge conflict is displayed on the CI. In fact, I'm do it based on the latest mainline, and there are nothing conflict. Can you help me re-trigger the build? There may be different reasons why (likely on your side), but patchwork does not see the patches you sent as a single series. For example, patch 4 is seen as part of the v2 series. The CI tools rely on patchwork. So the various CI won't be able to apply them. Please resend. Thanks. It's the patchwork problem. This patchset are assigned to two series. As shown in the link below: http://patches.dpdk.org/project/dpdk/list/?series=&submitter=2085&state=&q=&archive=&delegate= If I resend, but this patchset hasn't changed. Do I need to change the version number of this patchset? Hi Huisong, I think both are OK, but just to clarify which one is latest, I think there is no harm to increase the version. Get it. V6 will be sent. Thank you.
[PATCH] app/testpmd: fix memory leak for dscp table
This patch fixes memory leak reported by coverity.
Coverity issue: 379220
Fixes: 9f5488e326d3 ("app/testpmd: support different input color method")
Cc: sta...@dpdk.org
Signed-off-by: Jasvinder Singh
---
app/test-pmd/cmdline_mtr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index b92e66cedb..833273da0d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -131,8 +131,10 @@ parse_input_color_table_entries(char *str, enum rte_color
**dscp_table,
/* Allocate memory for vlan table */
vlan = (enum rte_color *)malloc(MAX_VLAN_TABLE_ENTRIES *
sizeof(enum rte_color));
- if (vlan == NULL)
+ if (vlan == NULL) {
+ free(*dscp_table);
return -1;
+ }
i = 0;
while (1) {
@@ -144,6 +146,7 @@ parse_input_color_table_entries(char *str, enum rte_color
**dscp_table,
vlan[i++] = RTE_COLOR_RED;
else {
free(vlan);
+ free(*dscp_table);
return -1;
}
if (i == MAX_VLAN_TABLE_ENTRIES)
@@ -152,6 +155,7 @@ parse_input_color_table_entries(char *str, enum rte_color
**dscp_table,
token = strtok_r(str, PARSE_DELIMITER, &str);
if (token == NULL) {
free(vlan);
+ free(*dscp_table);
return -1;
}
}
--
2.34.3
[PATCH 2/2] bus/pci: support region based device mapping
From: Sunil Kumar Kori
This commit allows driver to define a list of sparse memory
regions to map for a given device instead mapping the whole BAR.
To do that, a driver must register itself with following information:
* rte_pci_driver::drv_flags - RTE_PCI_DRV_NEED_REGION_MAPPING must be set.
* rte_pci_driver::regions - It contains list of regions. Region
information are explained below.
* rte_pci_driver::valid_bars: It contains information about BARs for which
entries are mentioned in rte_pci_driver::regions.
Each entry in region map specifies a particular area in given BAR to map
into the virtual space assigned for given device. Regions may lie within
the same BAR or in different BARs.
It results a sparse virtual memory reservation with only valid areas in
it being defined by the region tables.
Example:
If user wishes to map BAR 2 region at offset 0x200 of length
0x200 and BAR 4 region at offset 0x400 of length 0x1
then following information need to be set in driver while registering:
static struct rte_pci_region_map xyz_pci_nic_regions[] = {
{0x200, 0x200, 2, false},
{0x400, 0x1, 4, false},
{0x0, 0x0, 0x0, false},
};
static struct rte_pci_driver xyz_pci_nic = {
.valid_bars = {false, false, true, false, true, false},
.regions = xyz_pci_nic_regions,
.drv_flags = RTE_PCI_DRV_NEED_REGION_MAPPINGA | RTE_PCI_DRV_XYZ
}
And resultant mapping will be reflected as given below:
* (X + 0x200) to (X + 0x200 + 0x200)
* (Y + 0x400) to (Y + 0x400 + 0x1)
Signed-off-by: Sunil Kumar Kori
---
drivers/bus/pci/linux/pci.c | 30 +++-
drivers/bus/pci/linux/pci_vfio.c | 117 ++-
drivers/bus/pci/pci_common.c | 4 +-
drivers/bus/pci/private.h| 5 ++
drivers/bus/pci/rte_bus_pci.h| 25 +++
lib/pci/rte_pci.h| 15
6 files changed, 176 insertions(+), 20 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index e521459870..e6eb172e92 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -173,7 +173,7 @@ pci_parse_sysfs_resource(const char *filename, struct
rte_pci_device *dev)
{
FILE *f;
char buf[BUFSIZ];
- int i;
+ int i, j;
uint64_t phys_addr, end_addr, flags;
f = fopen(filename, "r");
@@ -198,6 +198,14 @@ pci_parse_sysfs_resource(const char *filename, struct
rte_pci_device *dev)
dev->mem_resource[i].len = end_addr - phys_addr + 1;
/* not mapped for now */
dev->mem_resource[i].addr = NULL;
+
+ /* update the same in regions too */
+ for (j = 0; j < PCI_MAX_REGION_PER_RESOURCE; j++) {
+ dev->regions[i][j].phys_addr = phys_addr;
+ dev->regions[i][j].len = end_addr - phys_addr +
1;
+ /* not mapped for now */
+ dev->regions[i][j].addr = NULL;
+ }
}
}
fclose(f);
@@ -640,6 +648,26 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
return iova_mode;
}
+bool
+pci_device_get_region_info(const struct rte_pci_driver *drv,
+ uint32_t bar_idx, uint64_t *offset, uint64_t *size)
+{
+ struct rte_pci_region_map *region;
+ bool is_present = false;
+
+ for (region = drv->regions; region->size != 0; region++) {
+ if ((region->bar_idx == bar_idx) && (region->mapped == false)) {
+ *offset = region->offset;
+ *size = region->size;
+ region->mapped = true;
+ is_present = true;
+ break;
+ }
+ }
+
+ return is_present;
+}
+
/* Read PCI config space. */
int rte_pci_read_config(const struct rte_pci_device *device,
void *buf, size_t len, off_t offset)
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index cd0d0b1670..90cbfbd699 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -509,21 +509,28 @@ pci_rte_vfio_setup_device(struct rte_pci_device *dev, int
vfio_dev_fd)
static int
pci_vfio_mmap_bar(int vfio_dev_fd, struct mapped_pci_resource *vfio_res,
- int bar_index, int additional_flags)
+ int bar_index, int reg_idx, bool map_reg, int additional_flags)
{
struct memreg {
uint64_t offset;
size_t size;
} memreg[2] = {};
- void *bar_addr;
+ void *bar_addr = NULL;
+ struct pci_map *region = &vfio_res->regions[bar_index][reg_idx];
struct pci_msix_table *msix_table = &vfio_res->msix_table;
struct pci_map *bar = &vfio_res->maps[bar_index];
- if (ba
[PATCH 1/2] doc: announce region based device mapping support
From: Sunil Kumar Kori Adding region based device mapping support, which enables pci device to map only required memory region instead of mapping full BAR. Signed-off-by: Sunil Kumar Kori --- doc/guides/rel_notes/deprecation.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..8800a3eb41 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,16 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* pci: Update ``rte_pci_device`` and ``rte_pci_driver`` to add region based + memory mapping support. There could be a requirement to mmap specific memory + region only. Using this mechanism, pci device can be mapped for + a given BAR at a given offset of given size. + + ``rte_pci_device`` will be added with following field + ``regions[PCI_MAX_RESOURCE][PCI_MAX_REGION_PER_RESOURCE];``. This field will + specify the regions which are mapped for a given BAR. + + ``rte_pci_driver`` will be added with ``rte_pci_region_map *regions`` and + ``valid_bars[PCI_MAX_RESOURCE]``. Using these fields, driver can propagate + its region information which are required to be mmap. -- 2.25.1
[PATCH] net/octeontx_ep: support basic stats
Added functionality to fetch and reset ethdev stats.
Signed-off-by: Sathesh Edara
---
doc/guides/nics/features/octeontx_ep.ini | 1 +
drivers/net/octeontx_ep/otx_ep_ethdev.c | 52
2 files changed, 53 insertions(+)
diff --git a/doc/guides/nics/features/octeontx_ep.ini
b/doc/guides/nics/features/octeontx_ep.ini
index d1453f5bee..e0c469676e 100644
--- a/doc/guides/nics/features/octeontx_ep.ini
+++ b/doc/guides/nics/features/octeontx_ep.ini
@@ -8,4 +8,5 @@ Speed capabilities = P
SR-IOV = Y
Linux= Y
x86-64 = Y
+Basic stats = Y
Usage doc= Y
diff --git a/drivers/net/octeontx_ep/otx_ep_ethdev.c
b/drivers/net/octeontx_ep/otx_ep_ethdev.c
index 806add246b..cb45bd7a8a 100644
--- a/drivers/net/octeontx_ep/otx_ep_ethdev.c
+++ b/drivers/net/octeontx_ep/otx_ep_ethdev.c
@@ -337,6 +337,56 @@ otx_ep_tx_queue_release(struct rte_eth_dev *dev, uint16_t
q_no)
otx_ep_delete_iqs(tq->otx_ep_dev, tq->q_no);
}
+static int
+otx_ep_dev_stats_reset(struct rte_eth_dev *dev)
+{
+ struct otx_ep_device *otx_epvf = OTX_EP_DEV(dev);
+ uint32_t i;
+
+ for (i = 0; i < otx_epvf->nb_tx_queues; i++)
+ memset(&otx_epvf->instr_queue[i]->stats, 0,
+ sizeof(struct otx_ep_iq_stats));
+
+ for (i = 0; i < otx_epvf->nb_rx_queues; i++)
+ memset(&otx_epvf->droq[i]->stats, 0,
+ sizeof(struct otx_ep_droq_stats));
+
+ return 0;
+}
+
+static int
+otx_ep_dev_stats_get(struct rte_eth_dev *eth_dev,
+ struct rte_eth_stats *stats)
+{
+ struct otx_ep_device *otx_epvf = OTX_EP_DEV(eth_dev);
+ struct otx_ep_iq_stats *ostats;
+ struct otx_ep_droq_stats *istats;
+ uint32_t i;
+
+ memset(stats, 0, sizeof(struct rte_eth_stats));
+
+ for (i = 0; i < otx_epvf->nb_tx_queues; i++) {
+ ostats = &otx_epvf->instr_queue[i]->stats;
+ stats->q_opackets[i] = ostats->tx_pkts;
+ stats->q_obytes[i] = ostats->tx_bytes;
+ stats->opackets += ostats->tx_pkts;
+ stats->obytes += ostats->tx_bytes;
+ stats->oerrors += ostats->instr_dropped;
+ }
+ for (i = 0; i < otx_epvf->nb_rx_queues; i++) {
+ istats = &otx_epvf->droq[i]->stats;
+ stats->q_ipackets[i] = istats->pkts_received;
+ stats->q_ibytes[i] = istats->bytes_received;
+ stats->q_errors[i] = istats->rx_err;
+ stats->ipackets += istats->pkts_received;
+ stats->ibytes += istats->bytes_received;
+ stats->imissed += istats->rx_alloc_failure;
+ stats->ierrors += istats->rx_err;
+ stats->rx_nombuf += istats->rx_alloc_failure;
+ }
+ return 0;
+}
+
/* Define our ethernet definitions */
static const struct eth_dev_ops otx_ep_eth_dev_ops = {
.dev_configure = otx_ep_dev_configure,
@@ -347,6 +397,8 @@ static const struct eth_dev_ops otx_ep_eth_dev_ops = {
.tx_queue_setup = otx_ep_tx_queue_setup,
.tx_queue_release = otx_ep_tx_queue_release,
.dev_infos_get = otx_ep_dev_info_get,
+ .stats_get = otx_ep_dev_stats_get,
+ .stats_reset= otx_ep_dev_stats_reset,
};
static int
--
2.36.1
[RFC PATCH 00/11] Bus cleanup for 22.11
This is a PoC for hiding the rte_bus object and mark associated API as internal. A good amount of the patches are preparation work on rte_bus.h, rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies between them. This is something I had in store for some time, maybe I should have dropped it from the PoC, but I think those cleanups are worth it in any case. The last two patches do the actual job: add accessors and make the rte_bus object opaque to non internal users. Disclaimer: this series is a bit rushed (I brute forced compilation tests in GHA so that it passes between patches, but there still may be something broken...). Not surprisingly, the ABI check in the CI is expected to fail. Comments welcome. I also hope we can do the same work on other generic objects (rte_driver, rte_device), but this is another story. -- David Marchand David Marchand (11): common/mlx5: rework check on driver registration raw/ifpga: remove PCI bus accessor dev: hide debug messages in device iterator dev: move unrelated macros from header devargs: remove dependency on bus header bus: remove unneded inclusion of bus header bus: move IOVA definition from header drivers/bus: remove back reference to bus objects drivers/bus: hide specific structures bus: introduce accessors bus: hide bus object app/test-compress-perf/comp_perf_options.h| 2 + app/test-pmd/config.c | 10 +- app/test-pmd/testpmd.c| 4 +- app/test-pmd/testpmd.h| 5 +- app/test/test_devargs.c | 6 +- app/test/test_kni.c | 7 +- app/test/test_vdev.c | 1 + drivers/bus/auxiliary/auxiliary_common.c | 2 - drivers/bus/auxiliary/linux/auxiliary.c | 1 - drivers/bus/auxiliary/private.h | 30 +- drivers/bus/auxiliary/rte_bus_auxiliary.h | 5 - drivers/bus/dpaa/dpaa_bus.c | 20 +- drivers/bus/dpaa/rte_dpaa_bus.h | 14 - drivers/bus/fslmc/fslmc_bus.c | 11 +- drivers/bus/fslmc/fslmc_vfio.c| 2 +- drivers/bus/fslmc/portal/dpaa2_hw_dprc.c | 1 + drivers/bus/fslmc/private.h | 27 ++ drivers/bus/fslmc/rte_fslmc.h | 21 -- drivers/bus/ifpga/ifpga_bus.c | 2 +- drivers/bus/ifpga/ifpga_common.c | 1 - drivers/bus/ifpga/rte_bus_ifpga.h | 1 - drivers/bus/pci/bsd/pci.c | 2 - drivers/bus/pci/linux/pci.c | 3 - drivers/bus/pci/pci_common.c | 2 - drivers/bus/pci/private.h | 18 +- drivers/bus/pci/rte_bus_pci.h | 23 -- drivers/bus/pci/windows/pci.c | 1 + drivers/bus/pci/windows/pci_netuio.c | 1 + drivers/bus/vdev/vdev.c | 2 +- drivers/bus/vdev/vdev_params.c| 1 - drivers/bus/vmbus/linux/vmbus_uio.c | 1 - drivers/bus/vmbus/private.h | 18 ++ drivers/bus/vmbus/rte_bus_vmbus.h | 21 -- drivers/bus/vmbus/vmbus_bufring.c | 1 - drivers/bus/vmbus/vmbus_channel.c | 1 - drivers/bus/vmbus/vmbus_common.c | 3 - drivers/bus/vmbus/vmbus_common_uio.c | 1 - .../common/mlx5/linux/mlx5_common_auxiliary.c | 10 +- drivers/common/mlx5/mlx5_common_pci.c | 3 +- drivers/common/qat/qat_device.c | 1 + drivers/compress/qat/qat_comp_pmd.c | 1 + drivers/compress/zlib/zlib_pmd_ops.c | 1 + .../scheduler/rte_cryptodev_scheduler.c | 1 + drivers/crypto/virtio/virtio_pci.c| 1 - drivers/dma/cnxk/cnxk_dmadev.c| 1 - drivers/dma/idxd/idxd_bus.c | 2 +- drivers/net/bonding/rte_eth_bond_args.c | 1 + drivers/net/failsafe/failsafe.c | 3 +- drivers/net/failsafe/failsafe_eal.c | 3 +- drivers/net/ixgbe/rte_pmd_ixgbe.c | 1 + drivers/net/liquidio/lio_ethdev.c | 1 + drivers/net/mlx5/linux/mlx5_os.c | 3 +- drivers/net/netvsc/hn_ethdev.c| 5 +- drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +- drivers/raw/ifpga/ifpga_rawdev.c | 7 +- drivers/raw/ifpga/ifpga_rawdev.h | 1 - drivers/raw/ifpga/rte_pmd_ifpga.c | 6 - drivers/raw/ifpga/rte_pmd_ifpga.h | 10 - drivers/raw/ifpga/version.map | 1 - examples/ethtool/lib/rte_ethtool.c| 4 +- examples/ip_pipeline/kni.c| 3 +- examples/multi_process/hotplug_mp/commands.c | 6 +- lib/compressdev/rte_compressdev.c | 2 + lib/compressdev/rte_compressdev_pmd.c | 1 + lib/cryptodev/cryptodev_pmd.c | 2 + lib/dmadev/rte_dmadev.c | 1 +
[RFC PATCH 01/11] common/mlx5: rework check on driver registration
Rely on a local flag rather than dereference a bus object.
This will help next commits.
Signed-off-by: David Marchand
---
drivers/common/mlx5/linux/mlx5_common_auxiliary.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/common/mlx5/linux/mlx5_common_auxiliary.c
b/drivers/common/mlx5/linux/mlx5_common_auxiliary.c
index 6584aeb18e..a182a8bdde 100644
--- a/drivers/common/mlx5/linux/mlx5_common_auxiliary.c
+++ b/drivers/common/mlx5/linux/mlx5_common_auxiliary.c
@@ -179,14 +179,20 @@ static struct rte_auxiliary_driver mlx5_auxiliary_driver
= {
.dma_unmap = mlx5_common_auxiliary_dma_unmap,
};
+static bool mlx5_common_auxiliary_initialized;
+
void mlx5_common_auxiliary_init(void)
{
- if (mlx5_auxiliary_driver.bus == NULL)
+ if (!mlx5_common_auxiliary_initialized) {
rte_auxiliary_register(&mlx5_auxiliary_driver);
+ mlx5_common_auxiliary_initialized = true;
+ }
}
RTE_FINI(mlx5_common_auxiliary_driver_finish)
{
- if (mlx5_auxiliary_driver.bus != NULL)
+ if (mlx5_common_auxiliary_initialized) {
rte_auxiliary_unregister(&mlx5_auxiliary_driver);
+ mlx5_common_auxiliary_initialized = false;
+ }
}
--
2.36.1
[RFC PATCH 02/11] raw/ifpga: remove PCI bus accessor
There is no in-tree user for this accessor that returns the PCI bus
object.
On the other hand, a bus object can be retrieved by name using
rte_bus_find_by_name.
We can remove driver specific API.
Signed-off-by: David Marchand
---
drivers/raw/ifpga/ifpga_rawdev.c | 7 +--
drivers/raw/ifpga/ifpga_rawdev.h | 1 -
drivers/raw/ifpga/rte_pmd_ifpga.c | 6 --
drivers/raw/ifpga/rte_pmd_ifpga.h | 10 --
drivers/raw/ifpga/version.map | 1 -
5 files changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/raw/ifpga/ifpga_rawdev.c b/drivers/raw/ifpga/ifpga_rawdev.c
index 8c05302a65..78a7123528 100644
--- a/drivers/raw/ifpga/ifpga_rawdev.c
+++ b/drivers/raw/ifpga/ifpga_rawdev.c
@@ -10,8 +10,8 @@
#include
#include
#include
+
#include
-#include
#include
#include
#include
@@ -1888,11 +1888,6 @@ RTE_PMD_REGISTER_PARAM_STRING(ifpga_rawdev_cfg,
"port= "
"afu_bts=");
-struct rte_pci_bus *ifpga_get_pci_bus(void)
-{
- return rte_ifpga_rawdev_pmd.bus;
-}
-
int ifpga_rawdev_partial_reconfigure(struct rte_rawdev *dev, int port,
const char *file)
{
diff --git a/drivers/raw/ifpga/ifpga_rawdev.h b/drivers/raw/ifpga/ifpga_rawdev.h
index 4c191190ca..0fb66cbaae 100644
--- a/drivers/raw/ifpga/ifpga_rawdev.h
+++ b/drivers/raw/ifpga/ifpga_rawdev.h
@@ -91,7 +91,6 @@ int
ifpga_unregister_msix_irq(struct ifpga_rawdev *dev, enum ifpga_irq_type type,
int vec_start, rte_intr_callback_fn handler, void *arg);
-struct rte_pci_bus *ifpga_get_pci_bus(void);
int ifpga_rawdev_partial_reconfigure(struct rte_rawdev *dev, int port,
const char *file);
void ifpga_rawdev_cleanup(void);
diff --git a/drivers/raw/ifpga/rte_pmd_ifpga.c
b/drivers/raw/ifpga/rte_pmd_ifpga.c
index 23146432c2..1ca248123b 100644
--- a/drivers/raw/ifpga/rte_pmd_ifpga.c
+++ b/drivers/raw/ifpga/rte_pmd_ifpga.c
@@ -402,12 +402,6 @@ rte_pmd_ifpga_reload(uint16_t dev_id, int type, int page)
return opae_mgr_reload(adapter->mgr, type, page);
}
-const struct rte_pci_bus *
-rte_pmd_ifpga_get_pci_bus(void)
-{
- return ifpga_get_pci_bus();
-}
-
int
rte_pmd_ifpga_partial_reconfigure(uint16_t dev_id, int port, const char *file)
{
diff --git a/drivers/raw/ifpga/rte_pmd_ifpga.h
b/drivers/raw/ifpga/rte_pmd_ifpga.h
index 3fa5d3435a..791543f2cd 100644
--- a/drivers/raw/ifpga/rte_pmd_ifpga.h
+++ b/drivers/raw/ifpga/rte_pmd_ifpga.h
@@ -220,16 +220,6 @@ rte_pmd_ifpga_reboot_try(uint16_t dev_id);
int
rte_pmd_ifpga_reload(uint16_t dev_id, int type, int page);
-/**
- * Get PCI bus the Intel FPGA driver register to
- *
- * @return
- * - (valid pointer) if successful.
- * - (NULL) if the Intel FPGA driver is not registered to any PCI bus.
- */
-const struct rte_pci_bus *
-rte_pmd_ifpga_get_pci_bus(void);
-
/**
* Perform PR (partial reconfiguration) on specified Intel FPGA device
*
diff --git a/drivers/raw/ifpga/version.map b/drivers/raw/ifpga/version.map
index ff71a453e2..340d8eb3c7 100644
--- a/drivers/raw/ifpga/version.map
+++ b/drivers/raw/ifpga/version.map
@@ -10,7 +10,6 @@ DPDK_22 {
rte_pmd_ifpga_stop_update;
rte_pmd_ifpga_reboot_try;
rte_pmd_ifpga_reload;
- rte_pmd_ifpga_get_pci_bus;
rte_pmd_ifpga_partial_reconfigure;
rte_pmd_ifpga_cleanup;
--
2.36.1
[RFC PATCH 03/11] dev: hide debug messages in device iterator
For any bus that does not support device iteration, rte_dev_iterator_init
both returned an error code and logged an error message.
An application (like testpmd) that only wants to list devices, would have
no choice but to inspect a bus object to avoid spewing error logs.
Make those log messages debug level, and remove the check in testpmd.
Signed-off-by: David Marchand
---
app/test-pmd/config.c | 4
lib/eal/common/eal_common_dev.c | 7 +++
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 62833fe97c..82db14f3a6 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -612,10 +612,6 @@ device_infos_display(const char *identifier)
if (identifier && da.bus != next)
continue;
- /* Skip buses that don't have iterate method */
- if (!next->dev_iterate)
- continue;
-
snprintf(devstr, sizeof(devstr), "bus=%s", next->name);
RTE_DEV_FOREACH(dev, devstr, &dev_iter) {
diff --git a/lib/eal/common/eal_common_dev.c b/lib/eal/common/eal_common_dev.c
index 9d913e5478..b6f0392f30 100644
--- a/lib/eal/common/eal_common_dev.c
+++ b/lib/eal/common/eal_common_dev.c
@@ -592,18 +592,17 @@ rte_dev_iterator_init(struct rte_dev_iterator *it,
* one layer specified.
*/
if (bus == NULL && cls == NULL) {
- RTE_LOG(ERR, EAL,
- "Either bus or class must be specified.\n");
+ RTE_LOG(DEBUG, EAL, "Either bus or class must be specified.\n");
rte_errno = EINVAL;
goto get_out;
}
if (bus != NULL && bus->dev_iterate == NULL) {
- RTE_LOG(ERR, EAL, "Bus %s not supported\n", bus->name);
+ RTE_LOG(DEBUG, EAL, "Bus %s not supported\n", bus->name);
rte_errno = ENOTSUP;
goto get_out;
}
if (cls != NULL && cls->dev_iterate == NULL) {
- RTE_LOG(ERR, EAL, "Class %s not supported\n", cls->name);
+ RTE_LOG(DEBUG, EAL, "Class %s not supported\n", cls->name);
rte_errno = ENOTSUP;
goto get_out;
}
--
2.36.1
[RFC PATCH 04/11] dev: move unrelated macros from header
RTE_FUNC_PTR_OR_* macros have nothing to do with the rte_device object
and associated API.
Move them to rte_common.h and include it where needed.
Signed-off-by: David Marchand
---
drivers/common/qat/qat_device.c| 1 +
drivers/compress/qat/qat_comp_pmd.c| 1 +
drivers/crypto/scheduler/rte_cryptodev_scheduler.c | 1 +
drivers/net/ixgbe/rte_pmd_ixgbe.c | 1 +
drivers/net/liquidio/lio_ethdev.c | 1 +
lib/compressdev/rte_compressdev.c | 1 +
lib/dmadev/rte_dmadev.c| 1 +
lib/eal/include/rte_common.h | 11 +++
lib/eal/include/rte_dev.h | 11 ---
lib/ethdev/ethdev_driver.c | 1 +
lib/ethdev/ethdev_pci.h| 1 +
lib/mempool/rte_mempool_ops.c | 1 +
lib/regexdev/rte_regexdev.c| 1 +
lib/security/rte_security.c| 1 +
lib/vhost/vdpa.c | 1 +
15 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/common/qat/qat_device.c b/drivers/common/qat/qat_device.c
index db4b087d2b..6583cf0554 100644
--- a/drivers/common/qat/qat_device.c
+++ b/drivers/common/qat/qat_device.c
@@ -2,6 +2,7 @@
* Copyright(c) 2018-2022 Intel Corporation
*/
+#include
#include
#include
#include
diff --git a/drivers/compress/qat/qat_comp_pmd.c
b/drivers/compress/qat/qat_comp_pmd.c
index dc8db84a68..e4cac159be 100644
--- a/drivers/compress/qat/qat_comp_pmd.c
+++ b/drivers/compress/qat/qat_comp_pmd.c
@@ -2,6 +2,7 @@
* Copyright(c) 2015-2022 Intel Corporation
*/
+#include
#include
#include "qat_comp.h"
diff --git a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
index 1e0c4fe464..88c9b21cd8 100644
--- a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
+++ b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2017 Intel Corporation
*/
+#include
#include
#include
#include
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.c
b/drivers/net/ixgbe/rte_pmd_ixgbe.c
index 9729f8575f..8ae4d9b39a 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.c
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.c
@@ -2,6 +2,7 @@
* Copyright(c) 2010-2017 Intel Corporation
*/
+#include
#include
#include "base/ixgbe_api.h"
diff --git a/drivers/net/liquidio/lio_ethdev.c
b/drivers/net/liquidio/lio_ethdev.c
index 90ffe31b9f..ccbd0ff849 100644
--- a/drivers/net/liquidio/lio_ethdev.c
+++ b/drivers/net/liquidio/lio_ethdev.c
@@ -2,6 +2,7 @@
* Copyright(c) 2017 Cavium, Inc
*/
+#include
#include
#include
#include
diff --git a/lib/compressdev/rte_compressdev.c
b/lib/compressdev/rte_compressdev.c
index 22c438f2dd..12469042f7 100644
--- a/lib/compressdev/rte_compressdev.c
+++ b/lib/compressdev/rte_compressdev.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 174d4c40ae..e199b888c8 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -5,6 +5,7 @@
#include
+#include
#include
#include
#include
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index a96cc2a138..1617b5ed14 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -861,6 +861,17 @@ rte_log2_u64(uint64_t v)
/** Number of elements in the array. */
#defineRTE_DIM(a) (sizeof (a) / sizeof ((a)[0]))
+/* Macros to check for invalid function pointers */
+#define RTE_FUNC_PTR_OR_ERR_RET(func, retval) do { \
+ if ((func) == NULL) \
+ return retval; \
+} while (0)
+
+#define RTE_FUNC_PTR_OR_RET(func) do { \
+ if ((func) == NULL) \
+ return; \
+} while (0)
+
/**
* Converts a numeric string to the equivalent uint64_t value.
* As well as straight number conversion, also recognises the suffixes
diff --git a/lib/eal/include/rte_dev.h b/lib/eal/include/rte_dev.h
index e6ff1218f9..24f9122558 100644
--- a/lib/eal/include/rte_dev.h
+++ b/lib/eal/include/rte_dev.h
@@ -36,17 +36,6 @@ typedef void (*rte_dev_event_cb_fn)(const char *device_name,
enum rte_dev_event_type event,
void *cb_arg);
-/* Macros to check for invalid function pointers */
-#define RTE_FUNC_PTR_OR_ERR_RET(func, retval) do { \
- if ((func) == NULL) \
- return retval; \
-} while (0)
-
-#define RTE_FUNC_PTR_OR_RET(func) do { \
- if ((func) == NULL) \
- return; \
-} while (0)
-
/**
* Device policies.
*/
diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
index a285f213f0..86f5a37874 100644
--- a/lib/ethdev/ethdev_driver.c
+++ b/lib/ethdev/ethdev_driver.c
@@ -2,6 +2,7 @@
* Copyright(c)
[RFC PATCH 05/11] devargs: remove dependency on bus header
We don't need to include rte_bus.h.
Only a forward declaration of rte_bus and an inclusion of rte_dev.h are
needed.
Signed-off-by: David Marchand
---
app/test/test_vdev.c | 1 +
lib/eal/include/rte_devargs.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/app/test/test_vdev.c b/app/test/test_vdev.c
index 720722c363..5eeff3106d 100644
--- a/app/test/test_vdev.c
+++ b/app/test/test_vdev.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include "test.h"
diff --git a/lib/eal/include/rte_devargs.h b/lib/eal/include/rte_devargs.h
index 37a0f042ab..38dee2f288 100644
--- a/lib/eal/include/rte_devargs.h
+++ b/lib/eal/include/rte_devargs.h
@@ -22,7 +22,9 @@ extern "C" {
#include
#include
-#include
+#include
+
+struct rte_bus;
/**
* Bus type key in global devargs syntax.
--
2.36.1
[RFC PATCH 06/11] bus: remove unneeded inclusion of bus header
Those files don't need to include rte_bus.h.
Signed-off-by: David Marchand
---
drivers/bus/auxiliary/linux/auxiliary.c | 1 -
drivers/bus/ifpga/ifpga_common.c| 1 -
drivers/bus/ifpga/rte_bus_ifpga.h | 1 -
drivers/bus/vdev/vdev_params.c | 1 -
drivers/bus/vmbus/linux/vmbus_uio.c | 1 -
drivers/bus/vmbus/vmbus_bufring.c | 1 -
drivers/bus/vmbus/vmbus_channel.c | 1 -
drivers/bus/vmbus/vmbus_common_uio.c| 1 -
drivers/crypto/virtio/virtio_pci.c | 1 -
drivers/dma/cnxk/cnxk_dmadev.c | 1 -
10 files changed, 10 deletions(-)
diff --git a/drivers/bus/auxiliary/linux/auxiliary.c
b/drivers/bus/auxiliary/linux/auxiliary.c
index 9bd4ee3295..28092e31c4 100644
--- a/drivers/bus/auxiliary/linux/auxiliary.c
+++ b/drivers/bus/auxiliary/linux/auxiliary.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/bus/ifpga/ifpga_common.c b/drivers/bus/ifpga/ifpga_common.c
index 78e2eaee4e..223660d6ff 100644
--- a/drivers/bus/ifpga/ifpga_common.c
+++ b/drivers/bus/ifpga/ifpga_common.c
@@ -14,7 +14,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
b/drivers/bus/ifpga/rte_bus_ifpga.h
index 007ad19875..682d565891 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga.h
+++ b/drivers/bus/ifpga/rte_bus_ifpga.h
@@ -15,7 +15,6 @@
extern "C" {
#endif /* __cplusplus */
-#include
#include
#include
#include
diff --git a/drivers/bus/vdev/vdev_params.c b/drivers/bus/vdev/vdev_params.c
index 3969faf16d..2c72614776 100644
--- a/drivers/bus/vdev/vdev_params.c
+++ b/drivers/bus/vdev/vdev_params.c
@@ -5,7 +5,6 @@
#include
#include
-#include
#include
#include
diff --git a/drivers/bus/vmbus/linux/vmbus_uio.c
b/drivers/bus/vmbus/linux/vmbus_uio.c
index 5db70f8e0d..26edef342d 100644
--- a/drivers/bus/vmbus/linux/vmbus_uio.c
+++ b/drivers/bus/vmbus/linux/vmbus_uio.c
@@ -13,7 +13,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/bus/vmbus/vmbus_bufring.c
b/drivers/bus/vmbus/vmbus_bufring.c
index c4aa07b307..c78619dc44 100644
--- a/drivers/bus/vmbus/vmbus_bufring.c
+++ b/drivers/bus/vmbus/vmbus_bufring.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/bus/vmbus/vmbus_channel.c
b/drivers/bus/vmbus/vmbus_channel.c
index 119b9b367e..8d9f32270e 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/bus/vmbus/vmbus_common_uio.c
b/drivers/bus/vmbus/vmbus_common_uio.c
index 882a24f869..4d4613513c 100644
--- a/drivers/bus/vmbus/vmbus_common_uio.c
+++ b/drivers/bus/vmbus/vmbus_common_uio.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include "private.h"
diff --git a/drivers/crypto/virtio/virtio_pci.c
b/drivers/crypto/virtio/virtio_pci.c
index ae069794a6..95a43c8801 100644
--- a/drivers/crypto/virtio/virtio_pci.c
+++ b/drivers/crypto/virtio/virtio_pci.c
@@ -10,7 +10,6 @@
#endif
#include
-#include
#include "virtio_pci.h"
#include "virtqueue.h"
diff --git a/drivers/dma/cnxk/cnxk_dmadev.c b/drivers/dma/cnxk/cnxk_dmadev.c
index 2824c1b44f..3e8c15d617 100644
--- a/drivers/dma/cnxk/cnxk_dmadev.c
+++ b/drivers/dma/cnxk/cnxk_dmadev.c
@@ -5,7 +5,6 @@
#include
#include
-#include
#include
#include
#include
--
2.36.1
[RFC PATCH 07/11] bus: move IOVA definition from header
iova enum definition does not need to be defined as part of the bus API.
Move it to rte_eal.h.
With this step, rte_eal.h does not depend on rte_bus.h and rte_dev.h.
Fix existing code that was relying on these implicit inclusions.
Signed-off-by: David Marchand
---
app/test-compress-perf/comp_perf_options.h | 2 ++
drivers/bus/vmbus/rte_bus_vmbus.h| 1 +
drivers/compress/zlib/zlib_pmd_ops.c | 1 +
drivers/net/failsafe/failsafe.c | 1 +
drivers/net/failsafe/failsafe_eal.c | 1 +
examples/multi_process/hotplug_mp/commands.c | 2 ++
lib/compressdev/rte_compressdev.c| 1 +
lib/compressdev/rte_compressdev_pmd.c| 1 +
lib/cryptodev/cryptodev_pmd.c| 2 ++
lib/eal/common/eal_thread.h | 1 +
lib/eal/common/hotplug_mp.c | 1 +
lib/eal/include/rte_bus.h| 18 ++
lib/eal/include/rte_eal.h| 15 ++-
lib/eal/include/rte_lcore.h | 2 ++
lib/eal/windows/eal.c| 1 +
lib/ethdev/rte_ethdev.c | 1 +
lib/pcapng/rte_pcapng.c | 1 +
17 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/app/test-compress-perf/comp_perf_options.h
b/app/test-compress-perf/comp_perf_options.h
index 0b777521c5..57dd146330 100644
--- a/app/test-compress-perf/comp_perf_options.h
+++ b/app/test-compress-perf/comp_perf_options.h
@@ -5,6 +5,8 @@
#ifndef _COMP_PERF_OPS_
#define _COMP_PERF_OPS_
+#include
+
#define MAX_LIST 32
#define MIN_COMPRESSED_BUF_SIZE 8
#define EXPANSE_RATIO 1.1
diff --git a/drivers/bus/vmbus/rte_bus_vmbus.h
b/drivers/bus/vmbus/rte_bus_vmbus.h
index a24bad831d..4421326fe8 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus.h
+++ b/drivers/bus/vmbus/rte_bus_vmbus.h
@@ -23,6 +23,7 @@ extern "C" {
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/compress/zlib/zlib_pmd_ops.c
b/drivers/compress/zlib/zlib_pmd_ops.c
index 0a73aed949..7d657d81bc 100644
--- a/drivers/compress/zlib/zlib_pmd_ops.c
+++ b/drivers/compress/zlib/zlib_pmd_ops.c
@@ -4,6 +4,7 @@
#include
+#include
#include
#include
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index 05cf533896..3eb7d32b76 100644
--- a/drivers/net/failsafe/failsafe.c
+++ b/drivers/net/failsafe/failsafe.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "failsafe_private.h"
diff --git a/drivers/net/failsafe/failsafe_eal.c
b/drivers/net/failsafe/failsafe_eal.c
index cb4a2abc02..130344dce2 100644
--- a/drivers/net/failsafe/failsafe_eal.c
+++ b/drivers/net/failsafe/failsafe_eal.c
@@ -3,6 +3,7 @@
* Copyright 2017 Mellanox Technologies, Ltd
*/
+#include
#include
#include
diff --git a/examples/multi_process/hotplug_mp/commands.c
b/examples/multi_process/hotplug_mp/commands.c
index 41ea265e45..da8b5e5924 100644
--- a/examples/multi_process/hotplug_mp/commands.c
+++ b/examples/multi_process/hotplug_mp/commands.c
@@ -8,6 +8,8 @@
#include
#include
#include
+
+#include
#include
/**/
diff --git a/lib/compressdev/rte_compressdev.c
b/lib/compressdev/rte_compressdev.c
index 12469042f7..7f6dedbc52 100644
--- a/lib/compressdev/rte_compressdev.c
+++ b/lib/compressdev/rte_compressdev.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/lib/compressdev/rte_compressdev_pmd.c
b/lib/compressdev/rte_compressdev_pmd.c
index 7f500d76d4..9bfae077db 100644
--- a/lib/compressdev/rte_compressdev_pmd.c
+++ b/lib/compressdev/rte_compressdev_pmd.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include "rte_compressdev_internal.h"
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 1903ade388..75d0075b86 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -3,6 +3,8 @@
*/
#include
+
+#include
#include
#include
#include
diff --git a/lib/eal/common/eal_thread.h b/lib/eal/common/eal_thread.h
index ca3378d463..e0240ccc60 100644
--- a/lib/eal/common/eal_thread.h
+++ b/lib/eal/common/eal_thread.h
@@ -5,6 +5,7 @@
#ifndef EAL_THREAD_H
#define EAL_THREAD_H
+#include
#include
/**
diff --git a/lib/eal/common/hotplug_mp.c b/lib/eal/common/hotplug_mp.c
index bde0de196e..1614a57752 100644
--- a/lib/eal/common/hotplug_mp.c
+++ b/lib/eal/common/hotplug_mp.c
@@ -3,6 +3,7 @@
*/
#include
+#include
#include
#include
#include
diff --git a/lib/eal/include/rte_bus.h b/lib/eal/include/rte_bus.h
index 6efd28..17edaa37c9 100644
--- a/lib/eal/include/rte_bus.h
+++ b/lib/eal/include/rte_bus.h
@@ -20,27 +20,13 @@ extern "C" {
#include
-#include
#include
+#include
+#include
/** Double linked list of buses */
RTE_TAILQ_HEAD(rte_bus_list, rte_bus);
-
-/**
- * IOVA mapping mode.
[RFC PATCH 08/11] drivers/bus: remove back reference to bus objects
There is no need for a back reference to a singleton object in the bus
driver objects: each function is contextually aware of which bus object
it should manipulate.
Signed-off-by: David Marchand
---
drivers/bus/auxiliary/auxiliary_common.c | 2 --
drivers/bus/auxiliary/rte_bus_auxiliary.h | 2 --
drivers/bus/dpaa/dpaa_bus.c | 10 +-
drivers/bus/dpaa/rte_dpaa_bus.h | 1 -
drivers/bus/fslmc/fslmc_bus.c | 10 +-
drivers/bus/fslmc/rte_fslmc.h | 1 -
drivers/bus/pci/pci_common.c | 2 --
drivers/bus/pci/rte_bus_pci.h | 1 -
drivers/bus/vmbus/rte_bus_vmbus.h | 2 --
drivers/bus/vmbus/vmbus_common.c | 2 --
10 files changed, 2 insertions(+), 31 deletions(-)
diff --git a/drivers/bus/auxiliary/auxiliary_common.c
b/drivers/bus/auxiliary/auxiliary_common.c
index 2cf8fe672d..0b212f2d64 100644
--- a/drivers/bus/auxiliary/auxiliary_common.c
+++ b/drivers/bus/auxiliary/auxiliary_common.c
@@ -259,7 +259,6 @@ void
rte_auxiliary_register(struct rte_auxiliary_driver *driver)
{
TAILQ_INSERT_TAIL(&auxiliary_bus.driver_list, driver, next);
- driver->bus = &auxiliary_bus;
}
/* Unregister a driver */
@@ -267,7 +266,6 @@ void
rte_auxiliary_unregister(struct rte_auxiliary_driver *driver)
{
TAILQ_REMOVE(&auxiliary_bus.driver_list, driver, next);
- driver->bus = NULL;
}
/* Add a device to auxiliary bus */
diff --git a/drivers/bus/auxiliary/rte_bus_auxiliary.h
b/drivers/bus/auxiliary/rte_bus_auxiliary.h
index 93b266daf7..b19696e5e6 100644
--- a/drivers/bus/auxiliary/rte_bus_auxiliary.h
+++ b/drivers/bus/auxiliary/rte_bus_auxiliary.h
@@ -32,7 +32,6 @@ extern "C" {
/* Forward declarations */
struct rte_auxiliary_driver;
-struct rte_auxiliary_bus;
struct rte_auxiliary_device;
/**
@@ -125,7 +124,6 @@ struct rte_auxiliary_device {
struct rte_auxiliary_driver {
RTE_TAILQ_ENTRY(rte_auxiliary_driver) next; /**< Next in list. */
struct rte_driver driver; /**< Inherit core driver. */
- struct rte_auxiliary_bus *bus;/**< Auxiliary bus reference. */
rte_auxiliary_match_t *match; /**< Device match function. */
rte_auxiliary_probe_t *probe; /**< Device probe function. */
rte_auxiliary_remove_t *remove; /**< Device remove function. */
diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index e442bc4c33..2c286d5817 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -520,23 +520,15 @@ rte_dpaa_driver_register(struct rte_dpaa_driver *driver)
BUS_INIT_FUNC_TRACE();
TAILQ_INSERT_TAIL(&rte_dpaa_bus.driver_list, driver, next);
- /* Update Bus references */
- driver->dpaa_bus = &rte_dpaa_bus;
}
/* un-register a dpaa bus based dpaa driver */
void
rte_dpaa_driver_unregister(struct rte_dpaa_driver *driver)
{
- struct rte_dpaa_bus *dpaa_bus;
-
BUS_INIT_FUNC_TRACE();
- dpaa_bus = driver->dpaa_bus;
-
- TAILQ_REMOVE(&dpaa_bus->driver_list, driver, next);
- /* Update Bus references */
- driver->dpaa_bus = NULL;
+ TAILQ_REMOVE(&rte_dpaa_bus.driver_list, driver, next);
}
static int
diff --git a/drivers/bus/dpaa/rte_dpaa_bus.h b/drivers/bus/dpaa/rte_dpaa_bus.h
index 1f04d9ebd3..5e8f32dfbf 100644
--- a/drivers/bus/dpaa/rte_dpaa_bus.h
+++ b/drivers/bus/dpaa/rte_dpaa_bus.h
@@ -119,7 +119,6 @@ typedef int (*rte_dpaa_remove_t)(struct rte_dpaa_device
*dpaa_dev);
struct rte_dpaa_driver {
TAILQ_ENTRY(rte_dpaa_driver) next;
struct rte_driver driver;
- struct rte_dpaa_bus *dpaa_bus;
enum rte_dpaa_type drv_type;
rte_dpaa_probe_t probe;
rte_dpaa_remove_t remove;
diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
index e9edc27e0a..f112d2afeb 100644
--- a/drivers/bus/fslmc/fslmc_bus.c
+++ b/drivers/bus/fslmc/fslmc_bus.c
@@ -530,27 +530,19 @@ rte_fslmc_driver_register(struct rte_dpaa2_driver *driver)
RTE_VERIFY(driver);
TAILQ_INSERT_TAIL(&rte_fslmc_bus.driver_list, driver, next);
- /* Update Bus references */
- driver->fslmc_bus = &rte_fslmc_bus;
}
/*un-register a fslmc bus based dpaa2 driver */
void
rte_fslmc_driver_unregister(struct rte_dpaa2_driver *driver)
{
- struct rte_fslmc_bus *fslmc_bus;
-
- fslmc_bus = driver->fslmc_bus;
-
/* Cleanup the PA->VA Translation table; From wherever this function
* is called from.
*/
if (rte_eal_iova_mode() == RTE_IOVA_PA)
dpaax_iova_table_depopulate();
- TAILQ_REMOVE(&fslmc_bus->driver_list, driver, next);
- /* Update Bus references */
- driver->fslmc_bus = NULL;
+ TAILQ_REMOVE(&rte_fslmc_bus.driver_list, driver, next);
}
/*
diff --git a/drivers/bus/fslmc/rte_fslmc.h b/drivers/bus/fslmc/rte_fslmc.h
index 8c67bfba55..9c3791635c 100644
--- a/drivers/bus/fslmc/rte_fsl
[RFC PATCH 09/11] drivers/bus: hide specific structures
Now that there is no bus specific object referenced in the driver
objects, we can hide rte_dpaa_bus, rte_fslmc_bus, rte_pci_bus,
rte_vmbus_bus specific structures into their bus code.
While at it:
- move enumerators only used in the bus code itself,
- remove unneeded list head structure type,
- reorder the definitions and macro manipulating the bus singleton object,
- remove inclusion of rte_bus.h and update code that relied on it,
Signed-off-by: David Marchand
---
app/test-pmd/testpmd.h| 1 +
app/test/test_kni.c | 1 +
drivers/bus/auxiliary/private.h | 30 +++
drivers/bus/auxiliary/rte_bus_auxiliary.h | 3 ---
drivers/bus/dpaa/dpaa_bus.c | 8 ++
drivers/bus/dpaa/rte_dpaa_bus.h | 13 --
drivers/bus/fslmc/fslmc_bus.c | 1 +
drivers/bus/fslmc/fslmc_vfio.c| 2 +-
drivers/bus/fslmc/portal/dpaa2_hw_dprc.c | 1 +
drivers/bus/fslmc/private.h | 27
drivers/bus/fslmc/rte_fslmc.h | 20 ---
drivers/bus/pci/bsd/pci.c | 2 --
drivers/bus/pci/linux/pci.c | 3 ---
drivers/bus/pci/private.h | 18 +-
drivers/bus/pci/rte_bus_pci.h | 22 -
drivers/bus/pci/windows/pci.c | 1 +
drivers/bus/pci/windows/pci_netuio.c | 1 +
drivers/bus/vmbus/private.h | 18 ++
drivers/bus/vmbus/rte_bus_vmbus.h | 20 ---
drivers/bus/vmbus/vmbus_common.c | 1 -
drivers/common/mlx5/mlx5_common_pci.c | 1 +
drivers/net/bonding/rte_eth_bond_args.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 1 +
drivers/net/netvsc/hn_ethdev.c| 1 +
examples/ethtool/lib/rte_ethtool.c| 1 +
examples/ip_pipeline/kni.c| 1 +
26 files changed, 98 insertions(+), 101 deletions(-)
create mode 100644 drivers/bus/fslmc/private.h
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index eeefb5e70f..34bdccef71 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#ifdef RTE_LIB_GRO
#include
diff --git a/app/test/test_kni.c b/app/test/test_kni.c
index 622315c8b1..9d76b6253e 100644
--- a/app/test/test_kni.c
+++ b/app/test/test_kni.c
@@ -25,6 +25,7 @@ test_kni(void)
#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/bus/auxiliary/private.h b/drivers/bus/auxiliary/private.h
index d22e83cf7a..06a920114c 100644
--- a/drivers/bus/auxiliary/private.h
+++ b/drivers/bus/auxiliary/private.h
@@ -9,9 +9,10 @@
#include
#include
+#include
+
#include "rte_bus_auxiliary.h"
-extern struct rte_auxiliary_bus auxiliary_bus;
extern int auxiliary_bus_logtype;
#define AUXILIARY_LOG(level, ...) \
@@ -19,27 +20,26 @@ extern int auxiliary_bus_logtype;
RTE_FMT("auxiliary bus: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
RTE_FMT_TAIL(__VA_ARGS__,)))
-/* Auxiliary bus iterators */
-#define FOREACH_DEVICE_ON_AUXILIARY_BUS(p) \
- TAILQ_FOREACH(p, &(auxiliary_bus.device_list), next)
-
-#define FOREACH_DRIVER_ON_AUXILIARY_BUS(p) \
- TAILQ_FOREACH(p, &(auxiliary_bus.driver_list), next)
-
-/* List of auxiliary devices. */
-TAILQ_HEAD(rte_auxiliary_device_list, rte_auxiliary_device);
-/* List of auxiliary drivers. */
-TAILQ_HEAD(rte_auxiliary_driver_list, rte_auxiliary_driver);
-
/*
* Structure describing the auxiliary bus
*/
struct rte_auxiliary_bus {
struct rte_bus bus; /* Inherit the generic class */
- struct rte_auxiliary_device_list device_list; /* List of devices */
- struct rte_auxiliary_driver_list driver_list; /* List of drivers */
+ TAILQ_HEAD(, rte_auxiliary_device) device_list; /* List of devices */
+ TAILQ_HEAD(, rte_auxiliary_driver) driver_list; /* List of drivers */
};
+#define RTE_BUS_AUXILIARY_NAME "auxiliary"
+
+extern struct rte_auxiliary_bus auxiliary_bus;
+
+/* Auxiliary bus iterators */
+#define FOREACH_DEVICE_ON_AUXILIARY_BUS(p) \
+ TAILQ_FOREACH(p, &(auxiliary_bus.device_list), next)
+
+#define FOREACH_DRIVER_ON_AUXILIARY_BUS(p) \
+ TAILQ_FOREACH(p, &(auxiliary_bus.driver_list), next)
+
/*
* Test whether the auxiliary device exist.
*/
diff --git a/drivers/bus/auxiliary/rte_bus_auxiliary.h
b/drivers/bus/auxiliary/rte_bus_auxiliary.h
index b19696e5e6..23eefe2360 100644
--- a/drivers/bus/auxiliary/rte_bus_auxiliary.h
+++ b/drivers/bus/auxiliary/rte_bus_auxiliary.h
@@ -25,11 +25,8 @@ extern "C" {
#include
#include
#include
-#include
#include
-#define RTE_BUS_AUXILIARY_NAME "auxiliary"
-
/* Forward declarations */
struct rte_auxiliary_driver;
struct rte_auxiliary_device;
diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index 2c286d5817..ad4ea156a6 100644
--- a/dri
[RFC PATCH 10/11] bus: introduce accessors
Prepare for making the bus object opaque by adding one accessor.
Update existing users.
Signed-off-by: David Marchand
---
app/test-pmd/config.c| 6 ++---
app/test-pmd/testpmd.c | 4 +--
app/test-pmd/testpmd.h | 4 +--
app/test/test_devargs.c | 4 +--
app/test/test_kni.c | 6 ++---
drivers/common/mlx5/mlx5_common_pci.c| 2 +-
drivers/net/failsafe/failsafe.c | 2 +-
drivers/net/failsafe/failsafe_eal.c | 2 +-
drivers/net/mlx5/linux/mlx5_os.c | 2 +-
drivers/net/netvsc/hn_ethdev.c | 4 +--
examples/ethtool/lib/rte_ethtool.c | 3 ++-
examples/ip_pipeline/kni.c | 2 +-
examples/multi_process/hotplug_mp/commands.c | 4 +--
lib/eal/common/eal_common_bus.c | 26
lib/eal/common/eal_common_dev.c | 8 +++---
lib/eal/common/eal_common_devargs.c | 12 -
lib/eal/common/hotplug_mp.c | 8 +++---
lib/eal/include/rte_bus.h| 13 ++
lib/eal/version.map | 3 +++
lib/ethdev/rte_ethdev.c | 10
lib/pcapng/rte_pcapng.c | 2 +-
21 files changed, 75 insertions(+), 52 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 82db14f3a6..3c027701e3 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -612,7 +612,7 @@ device_infos_display(const char *identifier)
if (identifier && da.bus != next)
continue;
- snprintf(devstr, sizeof(devstr), "bus=%s", next->name);
+ snprintf(devstr, sizeof(devstr), "bus=%s", rte_bus_name(next));
RTE_DEV_FOREACH(dev, devstr, &dev_iter) {
if (!dev->driver)
@@ -623,7 +623,7 @@ device_infos_display(const char *identifier)
continue;
printf("\n%s Infos for device %s %s\n",
info_border, dev->name, info_border);
- printf("Bus name: %s", dev->bus->name);
+ printf("Bus name: %s", rte_bus_name(dev->bus));
printf("\nDriver name: %s", dev->driver->name);
printf("\nDevargs: %s",
dev->devargs ? dev->devargs->args : "");
@@ -1076,7 +1076,7 @@ port_reg_off_is_invalid(portid_t port_id, uint32_t
reg_off)
}
bus = rte_bus_find_by_device(ports[port_id].dev_info.device);
- if (bus && !strcmp(bus->name, "pci")) {
+ if (bus && !strcmp(rte_bus_name(bus), "pci")) {
pci_dev = RTE_DEV_TO_PCI(ports[port_id].dev_info.device);
} else {
fprintf(stderr, "Not a PCI device\n");
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index addcbcac85..51c2488b45 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3507,9 +3507,9 @@ detach_devargs(char *identifier)
}
}
- if (rte_eal_hotplug_remove(da.bus->name, da.name) != 0) {
+ if (rte_eal_hotplug_remove(rte_bus_name(da.bus), da.name) != 0) {
TESTPMD_LOG(ERR, "Failed to detach device %s(%s)\n",
- da.name, da.bus->name);
+ da.name, rte_bus_name(da.bus));
rte_devargs_reset(&da);
return;
}
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 34bdccef71..ea242de34c 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -817,7 +817,7 @@ port_pci_reg_read(struct rte_port *port, uint32_t reg_off)
}
bus = rte_bus_find_by_device(port->dev_info.device);
- if (bus && !strcmp(bus->name, "pci")) {
+ if (bus && !strcmp(rte_bus_name(bus), "pci")) {
pci_dev = RTE_DEV_TO_PCI(port->dev_info.device);
} else {
fprintf(stderr, "Not a PCI device\n");
@@ -845,7 +845,7 @@ port_pci_reg_write(struct rte_port *port, uint32_t reg_off,
uint32_t reg_v)
}
bus = rte_bus_find_by_device(port->dev_info.device);
- if (bus && !strcmp(bus->name, "pci")) {
+ if (bus && !strcmp(rte_bus_name(bus), "pci")) {
pci_dev = RTE_DEV_TO_PCI(port->dev_info.device);
} else {
fprintf(stderr, "Not a PCI device\n");
diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c
index 16621285d2..ac5bc34c18 100644
--- a/app/test/test_devargs.c
+++ b/app/test/test_devargs.c
@@ -98,9 +98,9 @@ test_valid_devargs_cases(const struct devargs_case *list,
size_t n)
list[i].bus_kv) != 0)
goto fail;
if (list[i].bus != NULL &&
- strcmp(da.bus->name, list[i].bus) != 0) {
+ strcmp(rte_bus_name(da.bus), list[i]
[RFC PATCH 11/11] bus: hide bus object
Make rte_bus opaque for non internal users. This will make extending this object possible without breaking the ABI. Introduce a new driver header and move rte_bus definition and helpers. Signed-off-by: David Marchand --- app/test/test_devargs.c | 2 +- app/test/test_vdev.c| 2 +- drivers/bus/auxiliary/private.h | 2 +- drivers/bus/dpaa/dpaa_bus.c | 2 +- drivers/bus/fslmc/private.h | 2 +- drivers/bus/ifpga/ifpga_bus.c | 2 +- drivers/bus/pci/private.h | 2 +- drivers/bus/vdev/vdev.c | 2 +- drivers/bus/vmbus/private.h | 2 +- drivers/dma/idxd/idxd_bus.c | 2 +- drivers/net/bonding/rte_eth_bond_args.c | 2 +- drivers/net/vdev_netvsc/vdev_netvsc.c | 2 +- lib/eal/common/eal_common_bus.c | 2 +- lib/eal/common/eal_common_dev.c | 2 +- lib/eal/common/eal_common_devargs.c | 2 +- lib/eal/common/hotplug_mp.c | 2 +- lib/eal/include/bus_driver.h| 295 lib/eal/include/meson.build | 4 + lib/eal/include/rte_bus.h | 275 +- lib/eal/linux/eal_dev.c | 2 +- lib/eal/version.map | 4 +- lib/ethdev/rte_ethdev.c | 2 +- 22 files changed, 322 insertions(+), 292 deletions(-) create mode 100644 lib/eal/include/bus_driver.h diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c index ac5bc34c18..0a4c34a1ad 100644 --- a/app/test/test_devargs.c +++ b/app/test/test_devargs.c @@ -9,7 +9,7 @@ #include #include #include -#include +#include #include #include "test.h" diff --git a/app/test/test_vdev.c b/app/test/test_vdev.c index 5eeff3106d..1904e76e44 100644 --- a/app/test/test_vdev.c +++ b/app/test/test_vdev.c @@ -8,7 +8,7 @@ #include #include -#include +#include #include #include "test.h" diff --git a/drivers/bus/auxiliary/private.h b/drivers/bus/auxiliary/private.h index 06a920114c..7e8ae8c2f9 100644 --- a/drivers/bus/auxiliary/private.h +++ b/drivers/bus/auxiliary/private.h @@ -9,7 +9,7 @@ #include #include -#include +#include #include "rte_bus_auxiliary.h" diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c index ad4ea156a6..4f12944470 100644 --- a/drivers/bus/dpaa/dpaa_bus.c +++ b/drivers/bus/dpaa/dpaa_bus.c @@ -29,7 +29,7 @@ #include #include #include -#include +#include #include #include diff --git a/drivers/bus/fslmc/private.h b/drivers/bus/fslmc/private.h index 80d4673ca8..f08dc7716b 100644 --- a/drivers/bus/fslmc/private.h +++ b/drivers/bus/fslmc/private.h @@ -5,7 +5,7 @@ #ifndef __PRIVATE_H__ #define __PRIVATE_H__ -#include +#include #include diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c index e005f2cb70..a2c2f13cf7 100644 --- a/drivers/bus/ifpga/ifpga_bus.c +++ b/drivers/bus/ifpga/ifpga_bus.c @@ -14,7 +14,7 @@ #include #include -#include +#include #include #include #include diff --git a/drivers/bus/pci/private.h b/drivers/bus/pci/private.h index 6ccec15655..0cefed5edf 100644 --- a/drivers/bus/pci/private.h +++ b/drivers/bus/pci/private.h @@ -8,7 +8,7 @@ #include #include -#include +#include #include #include diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c index a8d8b2327e..dd4e931687 100644 --- a/drivers/bus/vdev/vdev.c +++ b/drivers/bus/vdev/vdev.c @@ -12,7 +12,7 @@ #include #include -#include +#include #include #include #include diff --git a/drivers/bus/vmbus/private.h b/drivers/bus/vmbus/private.h index 732cb6d583..5205e17a3f 100644 --- a/drivers/bus/vmbus/private.h +++ b/drivers/bus/vmbus/private.h @@ -9,7 +9,7 @@ #include #include -#include +#include #include #include #include diff --git a/drivers/dma/idxd/idxd_bus.c b/drivers/dma/idxd/idxd_bus.c index 13cb967f6d..e30dcfc281 100644 --- a/drivers/dma/idxd/idxd_bus.c +++ b/drivers/dma/idxd/idxd_bus.c @@ -8,7 +8,7 @@ #include #include -#include +#include #include #include #include diff --git a/drivers/net/bonding/rte_eth_bond_args.c b/drivers/net/bonding/rte_eth_bond_args.c index b90757756a..f461bf9207 100644 --- a/drivers/net/bonding/rte_eth_bond_args.c +++ b/drivers/net/bonding/rte_eth_bond_args.c @@ -4,7 +4,7 @@ #include #include -#include +#include #include #include diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c index 2587195168..24edf9f3c4 100644 --- a/drivers/net/vdev_netvsc/vdev_netvsc.c +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c @@ -24,7 +24,7 @@ #include #include -#include +#include #include #include #include diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c index cbf382f967..be64d31b0f 100644 --- a/lib/eal/common/eal_common_bus.c +++ b/lib/eal/common/eal_common_bus.c @@ -6,7 +6,7 @@ #include #include -#incl
[PATCH v3 0/2] net/mlx5: external RxQ tests
Recently [1] mlx5 PMD added support for external queues, in the following patches add internal tests for in Testpmd application. [1] https://patchwork.dpdk.org/project/dpdk/cover/20220224232511.3238707-1-michae...@nvidia.com/ v1: Initial commit. v2: Fix typos in documentation. Move mlx5 specific tests to mlx5 library. Change socket style SOCK_DGRAM -> SOCK_SEQPACKET. v3: Move all these tests to mlx5 library. Add mlx5 prefix to mlx5 specific tests. Improve documentation. Michael Baum (2): net/mlx5: add test for remote PD and CTX net/mlx5: add test for external Rx queue doc/guides/nics/mlx5.rst| 66 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 + drivers/net/mlx5/mlx5_testpmd.c | 383 3 files changed, 451 insertions(+) -- 2.25.1
[PATCH v3 1/2] net/mlx5: add test for remote PD and CTX
Add mlx5 internal option in testpmd similar to run-time function
"port attach" which adds another parameter named "socket" for attaching
port and add 2 devargs before.
The arguments are "cmd_fd" and "pd_handle" using to import device
created out of PMD. Testpmd application import it using IPC, and updates
the devargs list before attaching.
These arguments was added in this commit [1].
The syntax is:
testpmd > mlx5 port attach (identifier) socket=(path)
Where "path" is the IPC socket path agreed on the remote process.
[1]
http://patches.dpdk.org/project/dpdk/patch/20220224232511.3238707-4-michae...@nvidia.com/
Signed-off-by: Michael Baum
Reviewed-by: Thomas Monjalon
Acked-by: Matan Azrad
---
doc/guides/nics/mlx5.rst| 47 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +
drivers/net/mlx5/mlx5_testpmd.c | 220
3 files changed, 269 insertions(+)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index bc2bd2c8a6..cd3a613640 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1793,3 +1793,50 @@ and disables ``avail_thresh_triggered``.
.. code-block:: console
testpmd> mlx5 set port 1 host_shaper avail_thresh_triggered 0 rate 50
+
+
+Testpmd
+---
+
+port attach with socket path
+
+
+It is possible to allocate a port with ``libibverbs`` from external
application.
+For importing the external port with extra device arguments,
+there is a specific testpmd command
+similar to :ref:`port attach command `::
+
+ testpmd> mlx5 port attach (identifier) socket=(path)
+
+where:
+
+* ``identifier``: device identifier with optional parameters
+ as same as :ref:`port attach command `.
+* ``path``: path to IPC server socket created by the external application.
+
+This command performs:
+
+#. Open IPC client socket using the given path, and connect it.
+
+#. Import ibverbs context and ibverbs protection domain.
+
+#. Add two device arguments for context (``cmd_fd``)
+ and protection domain (``pd_handle``) to the device identifier.
+ See :ref:`mlx5 driver options ` for more
+ information about these device arguments.
+
+#. Call the regular ``port attach`` function with updated identifier.
+
+For example, to attach a port whose PCI address is ``:0a:00.0``
+and its socket path is ``/var/run/import_ipc_socket``:
+
+.. code-block:: console
+
+ testpmd> mlx5 port attach :0a:00.0 socket=/var/run/import_ipc_socket
+ testpmd: MLX5 socket path is /var/run/import_ipc_socket
+ testpmd: Attach port with extra devargs :0a:00.0,cmd_fd=40,pd_handle=1
+ Attaching a new port...
+ EAL: Probe PCI driver: mlx5_pci (15b3:101d) device: :0a:00.0 (socket 0)
+ Port 0 is attached. Now total ports is 1
+ Done
+
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f716ea2797..c0965cd3b9 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1882,6 +1882,8 @@ The following sections show functions for configuring
ports.
Port configuration changes only become active when forwarding is
started/restarted.
+.. _port_attach:
+
port attach
~~~
diff --git a/drivers/net/mlx5/mlx5_testpmd.c b/drivers/net/mlx5/mlx5_testpmd.c
index 4f9826496d..463ee8e764 100644
--- a/drivers/net/mlx5/mlx5_testpmd.c
+++ b/drivers/net/mlx5/mlx5_testpmd.c
@@ -6,6 +6,11 @@
#include
#include
#include
+#include
+#ifndef RTE_EXEC_ENV_WINDOWS
+#include
+#include
+#endif
#include
#include
@@ -14,6 +19,7 @@
#include
#include
#include
+
#include "mlx5_testpmd.h"
#include "testpmd.h"
@@ -111,6 +117,162 @@ mlx5_test_set_port_host_shaper(uint16_t port_id, uint16_t
avail_thresh_triggered
return 0;
}
+#ifndef RTE_EXEC_ENV_WINDOWS
+static const char*
+mlx5_test_get_socket_path(char *extend)
+{
+ if (strstr(extend, "socket=") == extend) {
+ const char *socket_path = strchr(extend, '=') + 1;
+
+ TESTPMD_LOG(DEBUG, "MLX5 socket path is %s\n", socket_path);
+ return socket_path;
+ }
+
+ TESTPMD_LOG(ERR, "Failed to extract a valid socket path from %s\n",
+ extend);
+ return NULL;
+}
+
+static int
+mlx5_test_extend_devargs(char *identifier, char *extend)
+{
+ struct sockaddr_un un = {
+ .sun_family = AF_UNIX,
+ };
+ int cmd_fd;
+ int pd_handle;
+ struct iovec iov = {
+ .iov_base = &pd_handle,
+ .iov_len = sizeof(int),
+ };
+ union {
+ char buf[CMSG_SPACE(sizeof(int))];
+ struct cmsghdr align;
+ } control;
+ struct msghdr msgh = {
+ .msg_iov = NULL,
+ .msg_iovlen = 0,
+ };
+ struct cmsghdr *cmsg;
+ const char *path = mlx5_test_get_socket_path(extend + 1);
+ size_t len = 1;
+ int socket_fd;
+
[PATCH v3 2/2] net/mlx5: add test for external Rx queue
Add mlx5 internal test for map and unmap external RxQs.
This patch adds to Testpmd app a runtime function to test the mapping
API.
For insert mapping use this command:
testpmd> mlx5 port (port_id) ext_rxq map (sw_queue_id) (hw_queue_id)
For insert mapping use this command:
testpmd> mlx5 port (port_id) ext_rxq unmap (sw_queue_id)
Signed-off-by: Michael Baum
Reviewed-by: Thomas Monjalon
Acked-by: Matan Azrad
---
doc/guides/nics/mlx5.rst| 19
drivers/net/mlx5/mlx5_testpmd.c | 163
2 files changed, 182 insertions(+)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index cd3a613640..9f2832e284 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1840,3 +1840,22 @@ and its socket path is ``/var/run/import_ipc_socket``:
Port 0 is attached. Now total ports is 1
Done
+
+port map external Rx queue
+~~
+
+External Rx queue indexes mapping management.
+
+Map HW queue index (32-bit) to ethdev queue index (16-bit) for external Rx
queue::
+
+ testpmd> mlx5 port (port_id) ext_rxq map (sw_queue_id) (hw_queue_id)
+
+Unmap external Rx queue::
+
+ testpmd> mlx5 port (port_id) ext_rxq unmap (sw_queue_id)
+
+where:
+
+* ``sw_queue_id``: queue index in range [64536, 65535].
+ This range is the highest 1000 numbers.
+* ``hw_queue_id``: queue index given by HW in queue creation.
diff --git a/drivers/net/mlx5/mlx5_testpmd.c b/drivers/net/mlx5/mlx5_testpmd.c
index 463ee8e764..ed845834aa 100644
--- a/drivers/net/mlx5/mlx5_testpmd.c
+++ b/drivers/net/mlx5/mlx5_testpmd.c
@@ -401,6 +401,158 @@ static cmdline_parse_inst_t mlx5_cmd_operate_attach_port
= {
};
#endif
+/* Map HW queue index to rte queue index. */
+struct mlx5_cmd_map_ext_rxq {
+ cmdline_fixed_string_t mlx5;
+ cmdline_fixed_string_t port;
+ portid_t port_id;
+ cmdline_fixed_string_t ext_rxq;
+ cmdline_fixed_string_t map;
+ uint16_t sw_queue_id;
+ uint32_t hw_queue_id;
+};
+
+cmdline_parse_token_string_t mlx5_cmd_map_ext_rxq_mlx5 =
+ TOKEN_STRING_INITIALIZER(struct mlx5_cmd_map_ext_rxq, mlx5, "mlx5");
+cmdline_parse_token_string_t mlx5_cmd_map_ext_rxq_port =
+ TOKEN_STRING_INITIALIZER(struct mlx5_cmd_map_ext_rxq, port, "port");
+cmdline_parse_token_num_t mlx5_cmd_map_ext_rxq_port_id =
+ TOKEN_NUM_INITIALIZER(struct mlx5_cmd_map_ext_rxq, port_id, RTE_UINT16);
+cmdline_parse_token_string_t mlx5_cmd_map_ext_rxq_ext_rxq =
+ TOKEN_STRING_INITIALIZER(struct mlx5_cmd_map_ext_rxq, ext_rxq,
+"ext_rxq");
+cmdline_parse_token_string_t mlx5_cmd_map_ext_rxq_map =
+ TOKEN_STRING_INITIALIZER(struct mlx5_cmd_map_ext_rxq, map, "map");
+cmdline_parse_token_num_t mlx5_cmd_map_ext_rxq_sw_queue_id =
+ TOKEN_NUM_INITIALIZER(struct mlx5_cmd_map_ext_rxq, sw_queue_id,
+ RTE_UINT16);
+cmdline_parse_token_num_t mlx5_cmd_map_ext_rxq_hw_queue_id =
+ TOKEN_NUM_INITIALIZER(struct mlx5_cmd_map_ext_rxq, hw_queue_id,
+ RTE_UINT32);
+
+static void
+mlx5_cmd_map_ext_rxq_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct mlx5_cmd_map_ext_rxq *res = parsed_result;
+ int ret;
+
+ if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+ return;
+ ret = rte_pmd_mlx5_external_rx_queue_id_map(res->port_id,
+ res->sw_queue_id,
+ res->hw_queue_id);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ fprintf(stderr, "invalid ethdev index (%u), out of range\n",
+ res->sw_queue_id);
+ break;
+ case -ENODEV:
+ fprintf(stderr, "invalid port_id %u\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ fprintf(stderr, "function not implemented or supported\n");
+ break;
+ case -EEXIST:
+ fprintf(stderr, "mapping with index %u already exists\n",
+ res->sw_queue_id);
+ break;
+ default:
+ fprintf(stderr, "programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t mlx5_cmd_map_ext_rxq = {
+ .f = mlx5_cmd_map_ext_rxq_parsed,
+ .data = NULL,
+ .help_str = "mlx5 port ext_rxq map
",
+ .tokens = {
+ (void *)&mlx5_cmd_map_ext_rxq_mlx5,
+ (void *)&mlx5_cmd_map_ext_rxq_port,
+ (void *)&mlx5_cmd_map_ext_rxq_port_id,
+ (void *)&mlx5_cmd_map_ext_rxq_ext_rxq,
+ (void *)&mlx5_cmd_map_ext_rxq_map,
+ (void *)&mlx5_cmd_map_ext_rxq_sw_queue_id,
+ (void *)&mlx5_cmd_map_ext_rxq_hw_queue_id,
+ NULL,
+ }
+};
+
+/* Unmap HW queue
RE: Service core statistics MT safety
> >> > >>> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > >>> Sent: Monday, 27 June 2022 13.06 > >>> > >>> Hi. > >>> > >>> Is it safe to enable stats on MT safe services? > >>> > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > 313273af > >>> - > >> 4 > >>> 5444731-6096fdb16385f88f&q=1&e=27b94605-d1e2-40b6- > af6d- > >> 9ebc54d > >>> > >> > 5db18&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain% > >> 2Flib > >>> %2Feal%2Fcommon%2Frte_service.c%23 > >>> L3 > >>> 6 > >>> 6 > >>> > >>> It seems to me this would have to be an __atomic_add for this > >>> code to produce deterministic results. > >> > >> I agree. The same goes for the 'calls' field. > > The calling function does the locking. > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- > >> 454 > > 44731-5ce419f8bf9f9b76&q=1&e=27b94605-d1e2-40b6-af6d- > >> 9ebc54d5db1 > > > >> > 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib > >> %2Feal > > %2Fcommon%2Frte_service.c%23L3 > > 98 > > > > For more information you can look at: > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- > >> 454 > > 44731-ba0d1416f08856f0&q=1&e=27b94605-d1e2-40b6-af6d- > >> 9ebc54d5db1 > > > >> > 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib > >> %2Feal > > %2Finclude%2Frte_service.h%23L > > 120 > > > > What about the > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- > >> 4544 > 4731-b64334addc78c264&q=1&e=27b94605-d1e2-40b6-af6d- > >> 9ebc54d5db18& > > >> > u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib%2 > >> Feal%2F > common%2Frte_service.c%23L404 > call (for MT safe services)? > > There's no lock held there. > >>> Good point. > >>> This is the case where the service running in service cores is MT > >>> safe. However, > >> the stats are incremented outside of the MT Safety mechanism employed > >> by the service. So, yes, this and other updates in the function > >> 'service_runner_do_callback' need to be updated atomically. > >> > >> Maybe a better solution would be to move this to the core_state > >> struct (and eliminate the "calls" field since the same information is > >> already in the core_state struct). The contention on these cache > >> lines will be pretty crazy for services with short run time (say a > >> thousand cycles or less per call), assuming they are mapped to many cores. > > That's one option, the structures are internal as well. With this option > > stats > need to be aggregated which will not give an accurate view. But, that is the > nature of the statistics. > > > > Per-core counters is a very common pattern. Used for Linux MIB counters, for > example. I'm not sure I think it's much less accurate. I mean, you just load > in > quick succession what's globally visible for the different per-lcore > counters. If > you do a relaxed store on an ARM, how long time does it take until it's seen > by > someone doing a relaxed load on a different core? Roughly. I think my explanation of the problem is not clear. If a service is running on more than one core and the stats are per core, when we aggregate, the resulting statistics is not atomic. By making the stats per core, we will be taking out that feature which is present currently (even though it is implemented incorrectly). As we agree, the proposed change is a common pattern and taking away the atomicity of the stats might not be a problem. > > > I am also wondering if these stats are of any use other than for debugging. > Adding a capability to disable stats might help as well. > > > > They could be used as a crude tool to determine service core utilization. > Comparing utilization between different services running on the same core > should be straight-forward, but lcore utilization is harder in absolute > terms. If > you just look at "cycles", a completely idle core would look like it's very > busy > (basically rdtsc latency added for every loop). I assume you'd have to do some > heuristic based on both "calls" and "cycles" to get an estimate. > > I think service core utilization would be very useful, although that would > require > some changes in the service function signature, so the service can report > back if > it did some useful work for a particular call. > > That would make for a DPDK 'top'. Just like 'top', it can't impose any serious > performance degradation when used, to be really useful, I think. > > Sure, it should be possible to turn it on and off. I thought that was the case > already? Thanks, yes, this exists already. Though the 'loops' counter is out of the stats enable check, looks like it is considered as an attribute for some reason. > > >> > >> Idle service cores will basically do nothing else than stall waiting > >> for these lines, I s
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> Make rte_bus opaque for non internal users.
> This will make extending this object possible without breaking the ABI.
>
> Introduce a new driver header and move rte_bus definition and helpers.
>
> Signed-off-by: David Marchand
> ---
... snip ...
> -struct rte_bus {
> - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> - const char *name;/**< Name of the bus */
> - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> - rte_bus_probe_t probe; /**< Probe devices on bus */
> - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> - rte_bus_plug_t plug; /**< Probe single device for drivers */
> - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> - rte_bus_parse_t parse; /**< Parse a device name */
> - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> - struct rte_bus_conf conf;/**< Bus configuration */
> - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> - /**< handle hot-unplug failure on the bus */
> - rte_bus_sigbus_handler_t sigbus_handler;
> - /**< handle sigbus error on the bus */
> -
> -};
since we're overhauling anyway we could follow suit with a number of the
lessons from posix apis e.g. pthread and eliminate typed pointers for a
little extra value.
> +struct rte_bus;
> +struct rte_device;
to avoid people tripping over mishandling pointers in/out of the api
surface taking the opaque object you could declare opaque handle for the
api to operate on instead. it would force the use of a cast in the
implementation but would avoid accidental void * of the wrong thing that
got cached being passed in. if the cast was really undesirable just
whack it under an inline / internal function.
e.g. make the opaque object an explicit type.
struct {
uintptr_t opaque;
} rte_bus_handle_t;
// implementation
rte_bus_handle_t
rte_bus_find(rte_bus_handle_t start,
rte_bus_cmp_t cmp, const void *data)
{
struct rte_bus *bus = (struct rte_bus *)start.opaque;
// do bus things on bus
return {.opaque = whatever};
}
then you will get hard compile time failure if someone messes up
argument passing.
e.g.
void *somerandomp = ...;
...
rte_bus_find(somerandomp, ...); // compile fail
i would actually suggest this wrapping in a struct / handle approach for
any opaque object that is passed over the api surface. the change is
bigger of course...
it has various other advantages when/if we decide to make the bus/driver
surface stable in abi which i understand is not a promise dpdk makes
right now but still we might one day.
anyway, just a suggestion. i like the series either way.
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, Jun 28, 2022 at 09:22:13AM -0700, Tyler Retzlaff wrote:
>
> e.g. make the opaque object an explicit type.
>
oops missed the typedef there but you probably know what i meant.
typedef
> struct {
> uintptr_t opaque;
> } rte_bus_handle_t;
>
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, 28 Jun 2022 09:22:13 -0700
Tyler Retzlaff wrote:
> On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> > Make rte_bus opaque for non internal users.
> > This will make extending this object possible without breaking the ABI.
> >
> > Introduce a new driver header and move rte_bus definition and helpers.
> >
> > Signed-off-by: David Marchand
> > ---
>
> ... snip ...
>
> > -struct rte_bus {
> > - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> > - const char *name;/**< Name of the bus */
> > - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> > - rte_bus_probe_t probe; /**< Probe devices on bus */
> > - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> > - rte_bus_plug_t plug; /**< Probe single device for drivers */
> > - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> > - rte_bus_parse_t parse; /**< Parse a device name */
> > - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> > - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> > - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> > - struct rte_bus_conf conf;/**< Bus configuration */
> > - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> > - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> > - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> > - /**< handle hot-unplug failure on the bus */
> > - rte_bus_sigbus_handler_t sigbus_handler;
> > - /**< handle sigbus error on the bus */
> > -
> > -};
>
> since we're overhauling anyway we could follow suit with a number of the
> lessons from posix apis e.g. pthread and eliminate typed pointers for a
> little extra value.
>
> > +struct rte_bus;
> > +struct rte_device;
>
> to avoid people tripping over mishandling pointers in/out of the api
> surface taking the opaque object you could declare opaque handle for the
> api to operate on instead. it would force the use of a cast in the
> implementation but would avoid accidental void * of the wrong thing that
> got cached being passed in. if the cast was really undesirable just
> whack it under an inline / internal function.
I don't like that because it least to dangerous casts in the internal code.
Better to keep the the type of the object. As long as the API only passes
around an pointer to a struct, without exposing the contents of the struct;
it is safer and easier to debug.
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, Jun 28, 2022 at 09:29:05AM -0700, Stephen Hemminger wrote:
> On Tue, 28 Jun 2022 09:22:13 -0700
> Tyler Retzlaff wrote:
>
> > On Tue, Jun 28, 2022 at 04:46:43PM +0200, David Marchand wrote:
> > > Make rte_bus opaque for non internal users.
> > > This will make extending this object possible without breaking the ABI.
> > >
> > > Introduce a new driver header and move rte_bus definition and helpers.
> > >
> > > Signed-off-by: David Marchand
> > > ---
> >
> > ... snip ...
> >
> > > -struct rte_bus {
> > > - RTE_TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */
> > > - const char *name;/**< Name of the bus */
> > > - rte_bus_scan_t scan; /**< Scan for devices attached to bus */
> > > - rte_bus_probe_t probe; /**< Probe devices on bus */
> > > - rte_bus_find_device_t find_device; /**< Find a device on the bus */
> > > - rte_bus_plug_t plug; /**< Probe single device for drivers */
> > > - rte_bus_unplug_t unplug; /**< Remove single device from driver */
> > > - rte_bus_parse_t parse; /**< Parse a device name */
> > > - rte_bus_devargs_parse_t devargs_parse; /**< Parse bus devargs */
> > > - rte_dev_dma_map_t dma_map; /**< DMA map for device in the bus */
> > > - rte_dev_dma_unmap_t dma_unmap; /**< DMA unmap for device in the bus */
> > > - struct rte_bus_conf conf;/**< Bus configuration */
> > > - rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> > > - rte_dev_iterate_t dev_iterate; /**< Device iterator. */
> > > - rte_bus_hot_unplug_handler_t hot_unplug_handler;
> > > - /**< handle hot-unplug failure on the bus */
> > > - rte_bus_sigbus_handler_t sigbus_handler;
> > > - /**< handle sigbus error on the bus */
> > > -
> > > -};
> >
> > since we're overhauling anyway we could follow suit with a number of the
> > lessons from posix apis e.g. pthread and eliminate typed pointers for a
> > little extra value.
> >
> > > +struct rte_bus;
> > > +struct rte_device;
> >
> > to avoid people tripping over mishandling pointers in/out of the api
> > surface taking the opaque object you could declare opaque handle for the
> > api to operate on instead. it would force the use of a cast in the
> > implementation but would avoid accidental void * of the wrong thing that
> > got cached being passed in. if the cast was really undesirable just
> > whack it under an inline / internal function.
>
> I don't like that because it least to dangerous casts in the internal code.
> Better to keep the the type of the object. As long as the API only passes
> around an pointer to a struct, without exposing the contents of the struct;
> it is safer and easier to debug.
as i mentioned you can use an inline/internal function or even a macro
to hide the cast, you could provide some additional integrity checks
here if desired as a value add.
the fact that you expose that it is a struct is an internal
implementation detail, if truly opaque tomorrow you could convert it
to a simple integer that indexes or enumerates something and prevents
any meaningful interpretation in the application.
when you say it is safer to debug i think you mean for dpdk devs not the
application developer because unless the app developer does something
really gross/dangerous casting they really can't "mishandle" the opaque
object except to use one that isn't initialized at all which we
can detect and handle internally in a general way.
i will however concede there would be slightly more finger work when
debugging dpdk itself since gdb / debugger doesn't automatically infer
type so you end up having to tell gdb what is in the uintptr_t.
anyway just drawing from experience in the driver frameworks we maintain
in windows, i think one of our regrets is that we didn't do this from
day 1 and subsequentl that we initially only used one opaque type
instead of defining separate (not implicitly convertable) types to each
opaque type.
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, 28 Jun 2022 10:07:12 -0700 Tyler Retzlaff wrote: > > > to avoid people tripping over mishandling pointers in/out of the api > > > surface taking the opaque object you could declare opaque handle for the > > > api to operate on instead. it would force the use of a cast in the > > > implementation but would avoid accidental void * of the wrong thing that > > > got cached being passed in. if the cast was really undesirable just > > > whack it under an inline / internal function. > > > > I don't like that because it least to dangerous casts in the internal code. > > Better to keep the the type of the object. As long as the API only passes > > around an pointer to a struct, without exposing the contents of the struct; > > it is safer and easier to debug. > > as i mentioned you can use an inline/internal function or even a macro > to hide the cast, you could provide some additional integrity checks > here if desired as a value add. > > the fact that you expose that it is a struct is an internal > implementation detail, if truly opaque tomorrow you could convert it > to a simple integer that indexes or enumerates something and prevents > any meaningful interpretation in the application. > > when you say it is safer to debug i think you mean for dpdk devs not the > application developer because unless the app developer does something > really gross/dangerous casting they really can't "mishandle" the opaque > object except to use one that isn't initialized at all which we > can detect and handle internally in a general way. > > i will however concede there would be slightly more finger work when > debugging dpdk itself since gdb / debugger doesn't automatically infer > type so you end up having to tell gdb what is in the uintptr_t. > > anyway just drawing from experience in the driver frameworks we maintain > in windows, i think one of our regrets is that we didn't do this from > day 1 and subsequentl that we initially only used one opaque type > instead of defining separate (not implicitly convertable) types to each > opaque type. It seems to be a difference in style/taste. The Linux/Unix side prefers opaque structure pointers. Windows (and LLVM) uses numeric handles. At this point DPDK should follow the Linux bus.
Re: [RFC PATCH 11/11] bus: hide bus object
On Tue, Jun 28, 2022 at 10:38:27AM -0700, Stephen Hemminger wrote: > On Tue, 28 Jun 2022 10:07:12 -0700 > Tyler Retzlaff wrote: > > > > > to avoid people tripping over mishandling pointers in/out of the api > > > > surface taking the opaque object you could declare opaque handle for the > > > > api to operate on instead. it would force the use of a cast in the > > > > implementation but would avoid accidental void * of the wrong thing that > > > > got cached being passed in. if the cast was really undesirable just > > > > whack it under an inline / internal function. > > > > > > I don't like that because it least to dangerous casts in the internal > > > code. > > > Better to keep the the type of the object. As long as the API only passes > > > around an pointer to a struct, without exposing the contents of the > > > struct; > > > it is safer and easier to debug. > > > > as i mentioned you can use an inline/internal function or even a macro > > to hide the cast, you could provide some additional integrity checks > > here if desired as a value add. > > > > the fact that you expose that it is a struct is an internal > > implementation detail, if truly opaque tomorrow you could convert it > > to a simple integer that indexes or enumerates something and prevents > > any meaningful interpretation in the application. > > > > when you say it is safer to debug i think you mean for dpdk devs not the > > application developer because unless the app developer does something > > really gross/dangerous casting they really can't "mishandle" the opaque > > object except to use one that isn't initialized at all which we > > can detect and handle internally in a general way. > > > > i will however concede there would be slightly more finger work when > > debugging dpdk itself since gdb / debugger doesn't automatically infer > > type so you end up having to tell gdb what is in the uintptr_t. > > > > anyway just drawing from experience in the driver frameworks we maintain > > in windows, i think one of our regrets is that we didn't do this from > > day 1 and subsequentl that we initially only used one opaque type > > instead of defining separate (not implicitly convertable) types to each > > opaque type. > > It seems to be a difference in style/taste. it's not i've sited at least one example of a mistake that becomes a compile time failure where application code is incorrectly authored where use of a pointer offers no such protection. > The Linux/Unix side prefers opaque structure pointers. > Windows (and LLVM) uses numeric handles. > > At this point DPDK should follow the Linux bus. dpdk is multi-platform and unix does not necessarily standardize on pointer to struct for opaque objects. freebsd has many apis notably bus_space that does uses handles and as previously mentioned posix threads uses handles. i understand that linux is an important platform but it isn't the only platform dpdk targets and just because it is important doesn't mean it should always enjoy being the defacto standard. anyway, i'll leave it for the patch author to decide. i still like the patch series either way. i just think this would make applications more robust.
Re: Service core statistics MT safety
On 2022-06-28 17:24, Honnappa Nagarahalli wrote: > > > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Monday, 27 June 2022 13.06 > > Hi. > > Is it safe to enable stats on MT safe services? > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122- >> 313273af > - 4 > 5444731-6096fdb16385f88f&q=1&e=27b94605-d1e2-40b6- >> af6d- 9ebc54d > >> 5db18&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain% 2Flib > %2Feal%2Fcommon%2Frte_service.c%23 > L3 > 6 > 6 > > It seems to me this would have to be an __atomic_add for this > code to produce deterministic results. I agree. The same goes for the 'calls' field. >>> The calling function does the locking. >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- 454 >>> 44731-5ce419f8bf9f9b76&q=1&e=27b94605-d1e2-40b6-af6d- 9ebc54d5db1 >>> >> 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib %2Feal >>> %2Fcommon%2Frte_service.c%23L3 >>> 98 >>> >>> For more information you can look at: >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- 454 >>> 44731-ba0d1416f08856f0&q=1&e=27b94605-d1e2-40b6-af6d- 9ebc54d5db1 >>> >> 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib %2Feal >>> %2Finclude%2Frte_service.h%23L >>> 120 >>> >> >> What about the >> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af- 4544 >> 4731-b64334addc78c264&q=1&e=27b94605-d1e2-40b6-af6d- 9ebc54d5db18& >> >> u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib%2 Feal%2F >> common%2Frte_service.c%23L404 >> call (for MT safe services)? >> >> There's no lock held there. > Good point. > This is the case where the service running in service cores is MT > safe. However, the stats are incremented outside of the MT Safety mechanism employed by the service. So, yes, this and other updates in the function 'service_runner_do_callback' need to be updated atomically. Maybe a better solution would be to move this to the core_state struct (and eliminate the "calls" field since the same information is already in the core_state struct). The contention on these cache lines will be pretty crazy for services with short run time (say a thousand cycles or less per call), assuming they are mapped to many cores. >>> That's one option, the structures are internal as well. With this option >>> stats >> need to be aggregated which will not give an accurate view. But, that is the >> nature of the statistics. >>> >> >> Per-core counters is a very common pattern. Used for Linux MIB counters, for >> example. I'm not sure I think it's much less accurate. I mean, you just load >> in >> quick succession what's globally visible for the different per-lcore >> counters. If >> you do a relaxed store on an ARM, how long time does it take until it's seen >> by >> someone doing a relaxed load on a different core? Roughly. > I think my explanation of the problem is not clear. > > If a service is running on more than one core and the stats are per core, > when we aggregate, the resulting statistics is not atomic. By making the > stats per core, we will be taking out that feature which is present currently > (even though it is implemented incorrectly). As we agree, the proposed change > is a common pattern and taking away the atomicity of the stats might not be a > problem. > Isn't it just a push model, versus a pull one? Both give just an approximation, albeit a very good one, of how many cycles are spent "now" for a particular service. Isn't time a local phenomena in a SMP system, and there is no global "now"? Maybe you can achieve such with a transaction or handshake of some sort, but I don't see how the an __atomic_add would be enough. I was fortunate to get some data from a real-world application, and enabling service core stats resulted in a 7% degradation of overall system capacity. I'm guessing atomic instructions would not make things better. >> >>> I am also wondering if these stats are of any use other than for debugging. >> Adding a capability to disable stats might help as well. >>> >> >> They could be used as a crude tool to determine service core utilization. >> Comparing utilization between different services running on the same core >> should be straight-forward, but lcore utilization is harder in absolute >> terms. If >> you just look at "cycles", a completely idle core would look like it's very >> busy >> (basically rdtsc latency added for every loop). I assume you'd have to do >> some >> heuristic based on both "calls" and "cycles" to get an estimate. >> >> I think service core utilization w
[PATCH] doc: announce support for MACsec in rte_security
MACsec support is planned for DPDK 22.11, which would result in ABI breakage in some of the rte_security structures. This patch is to give deprecation notice for the affected structures. Signed-off-by: Akhil Goyal --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..1c3bf54d72 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -116,6 +116,11 @@ Deprecation Notices pointer for the private data to the application which can be attached to the packet while enqueuing. +* security: MACsec support is planned to be added in DPDK 22.11 which would + result in updates to structures ``rte_security_macsec_xform``, + ``rte_security_macsec_stats`` and security capability structure + ``rte_security_capability`` to accomodate MACsec capabilities. + * metrics: The function ``rte_metrics_init`` will have a non-void return in order to notify errors instead of calling ``rte_exit``. -- 2.25.1
RE: Service core statistics MT safety
> > > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > > Sent: Monday, 27 June 2022 13.06 > > > > Hi. > > > > Is it safe to enable stats on MT safe services? > > > > https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > >> 313273af > > - > 4 > > 5444731-6096fdb16385f88f&q=1&e=27b94605-d1e2-40b6- > >> af6d- > 9ebc54d > > > > >> > 5db18&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain% > 2Flib > > %2Feal%2Fcommon%2Frte_service.c%23 > > L3 > > 6 > > 6 > > > > It seems to me this would have to be an __atomic_add for this > > code to produce deterministic results. > > I agree. The same goes for the 'calls' field. > >>> The calling function does the locking. > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > 313273af > >>> - > 454 > >>> 44731-5ce419f8bf9f9b76&q=1&e=27b94605-d1e2-40b6-af6d- > 9ebc54d5db1 > >>> > > >> > 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib > %2Feal > >>> %2Fcommon%2Frte_service.c%23L3 > >>> 98 > >>> > >>> For more information you can look at: > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > 313273af > >>> - > 454 > >>> 44731-ba0d1416f08856f0&q=1&e=27b94605-d1e2-40b6- > af6d- > 9ebc54d5db1 > >>> > > >> > 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib > %2Feal > >>> %2Finclude%2Frte_service.h%23L > >>> 120 > >>> > >> > >> What about the > >> https://protect2.fireeye.com/v1/url?k=31323334-501d5122- > 313273af- > 4544 > >> 4731-b64334addc78c264&q=1&e=27b94605-d1e2-40b6-af6d- > 9ebc54d5db18& > >> > > >> > u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib%2 > Feal%2F > >> common%2Frte_service.c%23L404 > >> call (for MT safe services)? > >> > >> There's no lock held there. > > Good point. > > This is the case where the service running in service cores is MT > > safe. However, > the stats are incremented outside of the MT Safety mechanism > employed by the service. So, yes, this and other updates in the > function 'service_runner_do_callback' need to be updated atomically. > > Maybe a better solution would be to move this to the core_state > struct (and eliminate the "calls" field since the same information > is already in the core_state struct). The contention on these cache > lines will be pretty crazy for services with short run time (say a > thousand cycles or less per call), assuming they are mapped to many > cores. > >>> That's one option, the structures are internal as well. With this > >>> option stats > >> need to be aggregated which will not give an accurate view. But, that > >> is the nature of the statistics. > >>> > >> > >> Per-core counters is a very common pattern. Used for Linux MIB > >> counters, for example. I'm not sure I think it's much less accurate. > >> I mean, you just load in quick succession what's globally visible for > >> the different per-lcore counters. If you do a relaxed store on an > >> ARM, how long time does it take until it's seen by someone doing a relaxed > load on a different core? Roughly. > > I think my explanation of the problem is not clear. > > > > If a service is running on more than one core and the stats are per core, > > when > we aggregate, the resulting statistics is not atomic. By making the stats per > core, > we will be taking out that feature which is present currently (even though it > is > implemented incorrectly). As we agree, the proposed change is a common > pattern and taking away the atomicity of the stats might not be a problem. > > > > Isn't it just a push model, versus a pull one? Both give just an > approximation, > albeit a very good one, of how many cycles are spent "now" for a particular > service. Isn't time a local phenomena in a SMP system, and there is no global > "now"? Maybe you can achieve such with a transaction or handshake of some > sort, but I don't see how the an __atomic_add would be enough. If we consider a global time line of events, using atomic operation will provide a single 'now' from the reader's perspective (of course there might be writers waiting to update). Without the atomic operations, there will not be a single 'now' from reader's perspective, there will be multiple read events on the timeline. > > I was fortunate to get some data from a real-world application, and enabling > service core stats resulted in a 7% degradation of overall system capacity. > I'm > guessing atomic instructions would not make things better. Is the service running on multiple cores? > > >> > >>> I am also wondering if these stats are of any use other than for > >>> debugging. > >> Adding a capabilit
[PATCH v2] examples/distributor: update dynamic configuration
In this patch,
* It is possible to switch the running mode of the distributor
using the command line argument.
* With "-c" parameter, you can run RX and Distributor
on the same core.
* Without "-c" parameter, you can run RX and Distributor
on the different core.
* Syntax error of the single RX and distributor core is fixed.
* Consecutive termination of the lcores fixed.
The termination order was wrong, and you couldn't terminate the
application while traffic was capturing. The current order is
RX -> Distributor -> TX -> Workers
* When "-c" parameter is active, the wasted distributor core is
also deactivated in the main function.
Fixes: 4a7f40c0ff9a ("examples/distributor: add dedicated core")
Cc: sta...@dpdk.org
Signed-off-by: Abdullah Ömer Yamaç
---
Cc: david.h...@intel.com
---
doc/guides/sample_app_ug/dist_app.rst | 3 +-
examples/distributor/main.c | 222 ++
2 files changed, 159 insertions(+), 66 deletions(-)
diff --git a/doc/guides/sample_app_ug/dist_app.rst
b/doc/guides/sample_app_ug/dist_app.rst
index 3bd03905c3..5c80561187 100644
--- a/doc/guides/sample_app_ug/dist_app.rst
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -42,11 +42,12 @@ Running the Application
.. code-block:: console
- .//examples/dpdk-distributor [EAL options] -- -p PORTMASK
+ .//examples/dpdk-distributor [EAL options] -- -p PORTMASK
[-c]
where,
* -p PORTMASK: Hexadecimal bitmask of ports to configure
+ * -c: Combines the RX core with distribution core
#. To run the application in linux environment with 10 lcores, 4 ports,
issue the command:
diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index 8995806b4e..632d5e5554 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -39,6 +39,8 @@ volatile uint8_t quit_signal_rx;
volatile uint8_t quit_signal_dist;
volatile uint8_t quit_signal_work;
unsigned int power_lib_initialised;
+bool enable_lcore_rx_distributor;
+unsigned int num_workers;
static volatile struct app_stats {
struct {
@@ -256,14 +258,82 @@ lcore_rx(struct lcore_params *p)
}
app_stats.rx.rx_pkts += nb_rx;
-/*
- * You can run the distributor on the rx core with this code. Returned
- * packets are then send straight to the tx core.
- */
-#if 0
- rte_distributor_process(p->d, bufs, nb_rx);
- const uint16_t nb_ret = rte_distributor_returned_pkts(p->d,
- bufs, BURST_SIZE*2);
+ /*
+* Swap the following two lines if you want the rx traffic
+* to go directly to tx, no distribution.
+*/
+ struct rte_ring *out_ring = p->rx_dist_ring;
+ /* struct rte_ring *out_ring = p->dist_tx_ring; */
+
+ uint16_t sent = rte_ring_enqueue_burst(out_ring,
+ (void *)bufs, nb_rx, NULL);
+
+ app_stats.rx.enqueued_pkts += sent;
+ if (unlikely(sent < nb_rx)) {
+ app_stats.rx.enqdrop_pkts += nb_rx - sent;
+ RTE_LOG_DP(DEBUG, DISTRAPP,
+ "%s:Packet loss due to full ring\n", __func__);
+ while (sent < nb_rx)
+ rte_pktmbuf_free(bufs[sent++]);
+ }
+ if (++port == nb_ports)
+ port = 0;
+ }
+ if (power_lib_initialised)
+ rte_power_exit(rte_lcore_id());
+ printf("\nCore %u exiting rx task.\n", rte_lcore_id());
+ /* set distributor threads quit flag */
+ quit_signal_dist = 1;
+ return 0;
+}
+
+static int
+lcore_rx_and_distributor(struct lcore_params *p)
+{
+ struct rte_distributor *d = p->d;
+ const uint16_t nb_ports = rte_eth_dev_count_avail();
+ const int socket_id = rte_socket_id();
+ uint16_t port;
+ struct rte_mbuf *bufs[BURST_SIZE*2];
+
+ RTE_ETH_FOREACH_DEV(port) {
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0)
+ continue;
+
+ if (rte_eth_dev_socket_id(port) > 0 &&
+ rte_eth_dev_socket_id(port) != socket_id)
+ printf("WARNING, port %u is on remote NUMA node to "
+ "RX thread.\n\tPerformance will not "
+ "be optimal.\n", port);
+ }
+
+ printf("\nCore %u doing packet RX and Distributor.\n", rte_lcore_id());
+ port = 0;
+ while (!quit_signal_rx) {
+
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0) {
+ if (++port == nb_ports)
+ port = 0;
+ continue;
+ }
+ const uint16_t nb_rx = rt
[PATCH v2] examples/distributor: update dynamic configuration
In this patch,
* It is possible to switch the running mode of the distributor
using the command line argument.
* With "-c" parameter, you can run RX and Distributor
on the same core.
* Without "-c" parameter, you can run RX and Distributor
on the different core.
* Syntax error of the single RX and distributor core is fixed.
* Consecutive termination of the lcores fixed.
The termination order was wrong, and you couldn't terminate the
application while traffic was capturing. The current order is
RX -> Distributor -> TX -> Workers
* When "-c" parameter is active, the wasted distributor core is
also deactivated in the main function.
Fixes: 4a7f40c0ff9a ("examples/distributor: add dedicated core")
Cc: sta...@dpdk.org
Signed-off-by: Abdullah Ömer Yamaç
---
Cc: david.h...@intel.com
---
doc/guides/sample_app_ug/dist_app.rst | 3 +-
examples/distributor/main.c | 222 ++
2 files changed, 159 insertions(+), 66 deletions(-)
diff --git a/doc/guides/sample_app_ug/dist_app.rst
b/doc/guides/sample_app_ug/dist_app.rst
index 3bd03905c3..5c80561187 100644
--- a/doc/guides/sample_app_ug/dist_app.rst
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -42,11 +42,12 @@ Running the Application
.. code-block:: console
- .//examples/dpdk-distributor [EAL options] -- -p PORTMASK
+ .//examples/dpdk-distributor [EAL options] -- -p PORTMASK
[-c]
where,
* -p PORTMASK: Hexadecimal bitmask of ports to configure
+ * -c: Combines the RX core with distribution core
#. To run the application in linux environment with 10 lcores, 4 ports,
issue the command:
diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index 8995806b4e..632d5e5554 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -39,6 +39,8 @@ volatile uint8_t quit_signal_rx;
volatile uint8_t quit_signal_dist;
volatile uint8_t quit_signal_work;
unsigned int power_lib_initialised;
+bool enable_lcore_rx_distributor;
+unsigned int num_workers;
static volatile struct app_stats {
struct {
@@ -256,14 +258,82 @@ lcore_rx(struct lcore_params *p)
}
app_stats.rx.rx_pkts += nb_rx;
-/*
- * You can run the distributor on the rx core with this code. Returned
- * packets are then send straight to the tx core.
- */
-#if 0
- rte_distributor_process(p->d, bufs, nb_rx);
- const uint16_t nb_ret = rte_distributor_returned_pkts(p->d,
- bufs, BURST_SIZE*2);
+ /*
+* Swap the following two lines if you want the rx traffic
+* to go directly to tx, no distribution.
+*/
+ struct rte_ring *out_ring = p->rx_dist_ring;
+ /* struct rte_ring *out_ring = p->dist_tx_ring; */
+
+ uint16_t sent = rte_ring_enqueue_burst(out_ring,
+ (void *)bufs, nb_rx, NULL);
+
+ app_stats.rx.enqueued_pkts += sent;
+ if (unlikely(sent < nb_rx)) {
+ app_stats.rx.enqdrop_pkts += nb_rx - sent;
+ RTE_LOG_DP(DEBUG, DISTRAPP,
+ "%s:Packet loss due to full ring\n", __func__);
+ while (sent < nb_rx)
+ rte_pktmbuf_free(bufs[sent++]);
+ }
+ if (++port == nb_ports)
+ port = 0;
+ }
+ if (power_lib_initialised)
+ rte_power_exit(rte_lcore_id());
+ printf("\nCore %u exiting rx task.\n", rte_lcore_id());
+ /* set distributor threads quit flag */
+ quit_signal_dist = 1;
+ return 0;
+}
+
+static int
+lcore_rx_and_distributor(struct lcore_params *p)
+{
+ struct rte_distributor *d = p->d;
+ const uint16_t nb_ports = rte_eth_dev_count_avail();
+ const int socket_id = rte_socket_id();
+ uint16_t port;
+ struct rte_mbuf *bufs[BURST_SIZE*2];
+
+ RTE_ETH_FOREACH_DEV(port) {
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0)
+ continue;
+
+ if (rte_eth_dev_socket_id(port) > 0 &&
+ rte_eth_dev_socket_id(port) != socket_id)
+ printf("WARNING, port %u is on remote NUMA node to "
+ "RX thread.\n\tPerformance will not "
+ "be optimal.\n", port);
+ }
+
+ printf("\nCore %u doing packet RX and Distributor.\n", rte_lcore_id());
+ port = 0;
+ while (!quit_signal_rx) {
+
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0) {
+ if (++port == nb_ports)
+ port = 0;
+ continue;
+ }
+ const uint16_t nb_rx = rt
RE: [PATCH v2] baseband/turbo_sw: Remove flexran_sdk meson option
> From: Thomas Monjalon > > 27/06/2022 22:29, Nicolas Chautru: > > Hi Thomas, > > This is change you requested earlier this year. This is targeting 22.11. > > OK thanks. > > > Basically we no longer pass a specific option but rely on pkgconfig. > > There is small change to generate the .pc files that Intel will make > > available > by end of year. Still the related change in DPDK is available now. > > It means we depend on a future version of Flexran? > Please could you document the minimum version? I expect the new version to be available in FlexRAN 22.11 (hence in November as well). Is that a concern? > > Note: I think you messed tab indents in the meson file. > Thanks. Will fix now and send a v3
[PATCH v3] baseband/turbo_sw: Remove flexran_sdk meson option
v3: fix mix of space and tabs in meson files v2: typo in documentation Hi Thomas, This is change you requested earlier this year. This is targeting 22.11. Basically we no longer pass a specific option but rely on pkgconfig. There is small change to generate the .pc files that Intel will make available by end of year. Still the related change in DPDK is available now. Thanks Nic Nicolas Chautru (1): baseband/turbo_sw: remove Flexran SDK meson option doc/guides/bbdevs/turbo_sw.rst| 6 -- drivers/baseband/turbo_sw/meson.build | 36 +-- meson_options.txt | 2 -- 3 files changed, 17 insertions(+), 27 deletions(-) -- 1.8.3.1
[PATCH v3] baseband/turbo_sw: remove Flexran SDK meson option
The related dependency to build the PMD based on the
SDK libraries is now enabled through pkfconfig.
Signed-off-by: Nicolas Chautru
---
doc/guides/bbdevs/turbo_sw.rst| 6 --
drivers/baseband/turbo_sw/meson.build | 36 +--
meson_options.txt | 2 --
3 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/doc/guides/bbdevs/turbo_sw.rst b/doc/guides/bbdevs/turbo_sw.rst
index 1e23e37..24a9621 100644
--- a/doc/guides/bbdevs/turbo_sw.rst
+++ b/doc/guides/bbdevs/turbo_sw.rst
@@ -136,7 +136,8 @@ In order to enable this virtual bbdev PMD, the user may:
FlexRAN SDK libraries were installed. And ``DIR_WIRELESS_SDK`` to the path
where the libraries were extracted.
-* Tune the meson build option pointing the location of the FlexRAN SDK
libraries ``flexran_sdk``
+* Point pkgconfig towards these libraries so that they can be automatically
found by meson.
+ If not DPDK will still compile but the related functionality would be
stubbed out.
Example:
@@ -144,8 +145,9 @@ Example:
export
FLEXRAN_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/install
export
DIR_WIRELESS_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/
+export PKG_CONFIG_PATH=$DIR_WIRELESS_SDK/pkgcfg:$PKG_CONFIG_PATH
cd build
-meson configure
-Dflexran_sdk=/FlexRAN-FEC-SDK-19-04/sdk/build-avx512-icc/install
+meson configure
* For AVX512 machines with SDK libraries installed then both 4G and 5G can be
enabled for full real time FEC capability.
For AVX2 machines it is possible to only enable the 4G libraries and the PMD
capabilities will be limited to 4G FEC.
diff --git a/drivers/baseband/turbo_sw/meson.build
b/drivers/baseband/turbo_sw/meson.build
index 477b8b3..417ec63 100644
--- a/drivers/baseband/turbo_sw/meson.build
+++ b/drivers/baseband/turbo_sw/meson.build
@@ -1,38 +1,28 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2019 Intel Corporation
-path = get_option('flexran_sdk')
+# check for FlexRAN SDK libraries
+dep_turbo = dependency('flexran_sdk_turbo', required: false)
+dep_dec5g = dependency('flexran_sdk_ldpc_decoder_5gnr', required: false)
-# check for FlexRAN SDK libraries for AVX2
-lib4g = cc.find_library('libturbo', dirs: [path + '/lib_turbo'], required:
false)
-if lib4g.found()
-ext_deps += cc.find_library('libturbo', dirs: [path + '/lib_turbo'],
required: true)
-ext_deps += cc.find_library('libcrc', dirs: [path + '/lib_crc'], required:
true)
-ext_deps += cc.find_library('librate_matching', dirs: [path +
'/lib_rate_matching'], required: true)
-ext_deps += cc.find_library('libcommon', dirs: [path + '/lib_common'],
required: true)
+if dep_turbo.found()
ext_deps += cc.find_library('libstdc++', required: true)
ext_deps += cc.find_library('libirc', required: true)
ext_deps += cc.find_library('libimf', required: true)
ext_deps += cc.find_library('libipps', required: true)
ext_deps += cc.find_library('libsvml', required: true)
-includes += include_directories(path + '/lib_turbo')
-includes += include_directories(path + '/lib_crc')
-includes += include_directories(path + '/lib_rate_matching')
-includes += include_directories(path + '/lib_common')
+ext_deps += dep_turbo
+ext_deps += dependency('flexran_sdk_crc', required: true)
+ext_deps += dependency('flexran_sdk_rate_matching', required: true)
+ext_deps += dependency('flexran_sdk_common', required: true)
cflags += ['-DRTE_BBDEV_SDK_AVX2']
endif
-# check for FlexRAN SDK libraries for AVX512
-lib5g = cc.find_library('libldpc_decoder_5gnr', dirs: [path +
'/lib_ldpc_decoder_5gnr'], required: false)
-if lib5g.found()
-ext_deps += cc.find_library('libldpc_encoder_5gnr', dirs: [path +
'/lib_ldpc_encoder_5gnr'], required: true)
-ext_deps += cc.find_library('libldpc_decoder_5gnr', dirs: [path +
'/lib_ldpc_decoder_5gnr'], required: true)
-ext_deps += cc.find_library('libLDPC_ratematch_5gnr', dirs: [path +
'/lib_LDPC_ratematch_5gnr'], required: true)
-ext_deps += cc.find_library('librate_dematching_5gnr', dirs: [path +
'/lib_rate_dematching_5gnr'], required: true)
-includes += include_directories(path + '/lib_ldpc_encoder_5gnr')
-includes += include_directories(path + '/lib_ldpc_decoder_5gnr')
-includes += include_directories(path + '/lib_LDPC_ratematch_5gnr')
-includes += include_directories(path + '/lib_rate_dematching_5gnr')
+if dep_dec5g.found()
+ext_deps += dep_dec5g
+ext_deps += dependency('flexran_sdk_ldpc_encoder_5gnr', required: true)
+ext_deps += dependency('flexran_sdk_LDPC_ratematch_5gnr', required: true)
+ext_deps += dependency('flexran_sdk_rate_dematching_5gnr', required: true)
cflags += ['-DRTE_BBDEV_SDK_AVX512']
endif
diff --git a/meson_options.txt b/meson_options.txt
index 7c220ad..abaa304 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -22,8 +22,6 @@ option('enable_kmods', type: 'boolean', value: fals
[PATCH] net/i40e: fix error disable double VLAN
Sync the kernel driver, enable double VLAN by default after
firmware v8.3 and disable double VLAN is not allowed in subsequent
operations.
Fixes: 4f13a78f1b8f ("net/i40e: add outer VLAN processing")
Signed-off-by: Kevin Liu
---
drivers/net/i40e/i40e_ethdev.c | 45 --
1 file changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index dd471d487e..b07ef89220 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2575,7 +2575,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
- struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
struct i40e_filter_control_settings settings;
struct rte_flow *p_flow;
uint32_t reg;
@@ -2588,18 +2587,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- /*
-* It is a workaround, if the double VLAN is disabled when
-* the program exits, an abnormal error will occur on the
-* NIC. Need to enable double VLAN when dev is closed.
-*/
- if (pf->fw8_3gt) {
- if (!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
- rxmode->offloads |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
- i40e_vlan_offload_set(dev, RTE_ETH_VLAN_EXTEND_MASK);
- }
- }
-
ret = rte_eth_switch_domain_free(pf->switch_domain_id);
if (ret)
PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
@@ -3950,20 +3937,8 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
else if (vlan_type == RTE_ETH_VLAN_TYPE_INNER)
hw->second_tag = rte_cpu_to_le_16(tpid);
} else {
- /*
-* If tpid is equal to 0x88A8, indicates that the
-* disable double VLAN operation is in progress.
-* Need set switch configuration back to default.
-*/
- if (pf->fw8_3gt && tpid == RTE_ETHER_TYPE_QINQ) {
- sw_flags = 0;
- valid_flags = I40E_AQ_SET_SWITCH_CFG_OUTER_VLAN;
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->first_tag = rte_cpu_to_le_16(tpid);
- } else {
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->second_tag = rte_cpu_to_le_16(tpid);
- }
+ if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
+ hw->second_tag = rte_cpu_to_le_16(tpid);
}
ret = i40e_aq_set_switch_config(hw, sw_flags,
valid_flags, 0, NULL);
@@ -4043,6 +4018,12 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
}
if (mask & RTE_ETH_VLAN_EXTEND_MASK) {
+ /* Sync the kernel driver. Double VLAN not allowed to be
disabled.*/
+ if (pf->fw8_3gt && !(rxmode->offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
+ PMD_DRV_LOG(WARNING,
+ "Disable double VLAN is not allowed after
firmwarev8.3!");
+ return 0;
+ }
i = 0;
num = vsi->mac_num;
mac_filter = rte_zmalloc("mac_filter_info_data",
@@ -4078,9 +4059,6 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
i40e_vlan_tpid_set(dev, RTE_ETH_VLAN_TYPE_INNER,
RTE_ETHER_TYPE_VLAN);
} else {
- if (pf->fw8_3gt)
- i40e_vlan_tpid_set(dev, RTE_ETH_VLAN_TYPE_OUTER,
- RTE_ETHER_TYPE_QINQ);
i40e_vsi_config_double_vlan(vsi, FALSE);
}
/* Restore all mac */
@@ -6176,6 +6154,7 @@ i40e_vsi_config_vlan_stripping(struct i40e_vsi *vsi, bool
on)
static int
i40e_dev_init_vlan(struct rte_eth_dev *dev)
{
+ struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct rte_eth_dev_data *data = dev->data;
int ret;
int mask = 0;
@@ -6185,6 +6164,12 @@ i40e_dev_init_vlan(struct rte_eth_dev *dev)
RTE_ETH_QINQ_STRIP_MASK |
RTE_ETH_VLAN_FILTER_MASK |
RTE_ETH_VLAN_EXTEND_MASK;
+
+ /* Sync the kernel driver. Double VLAN be enabled by default.*/
+ if (pf->fw8_3gt) {
+ struct rte_eth_rxmode
Re: dpdk-devbind.py ./. bonding interfaces
On Sat, 25 Jun 2022 01:13:01 +0200 qcqx-obaq.6cba8...@hashmail.org wrote: > To whom it may concern. > > usertools/dpdk-devbind.py currently does not recognize interfaces > that are part of a bond as active. > that can be a nuisance if you are using something like libmoon which > proactively rebinds drivers for all "not active" interfaces. > > yes, i am aware of the dpdk contribution guideline. > > no, i am not going to jump through linux-kernel level hoops for > a trivial 9-sloc-python driveby-contrib. > > yes, that glorious code is all written by me, i promise i didnt > steal it, and whoever takes pity and merges it is free to claim > full credits for it. > (if you feel bad about claiming credits for something you didnt > write, perhaps find more useful names for "f" and "l" and/or > add some comment above it...) > > yes, i promise i will read and respect the contrib guide if i ever > want to contrib code that took longer to write than it takes to > read the contrib guide. > > regards, >x23 Sounds like a libmoon bug, not a DPDK bug. There are many more types of joined devices in Linux, and just doing bonding seems wrong. Also, since your patch is missing Signed-off-by with a valid name, it can not be accepted.
[PATCH v2] net/i40e: fix error disable double VLAN
Sync the kernel driver, enable double VLAN by default after
firmware v8.3 and disable double VLAN is not allowed in subsequent
operations.
Fixes: 4f13a78f1b8f ("net/i40e: add outer VLAN processing")
Signed-off-by: Kevin Liu
v2: update the document
---
doc/guides/nics/i40e.rst | 5 ++--
drivers/net/i40e/i40e_ethdev.c | 45 --
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a7b51618b0..d051c7ec36 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -969,11 +969,10 @@ it will fail and return the info "Conflict with the first
rule's input set",
which means the current rule's input set conflicts with the first rule's.
Remove the first rule if want to change the input set of the PCTYPE.
-PF reset fail after QinQ set with FW >= 8.4
+Disable Qinq is not supported when FW >= 8.4
~~~
-If upgrade FW to version 8.4 and higher, after set MAC VLAN filter and
configure outer VLAN on PF, kill
-DPDK process will cause the card crash.
+If upgrade FW to version 8.4 and higher, sync kernel driver, enable Qinq by
default and disable Qinq is not supported.
Example of getting best performance with l3fwd example
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index dd471d487e..b07ef89220 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2575,7 +2575,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
- struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
struct i40e_filter_control_settings settings;
struct rte_flow *p_flow;
uint32_t reg;
@@ -2588,18 +2587,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- /*
-* It is a workaround, if the double VLAN is disabled when
-* the program exits, an abnormal error will occur on the
-* NIC. Need to enable double VLAN when dev is closed.
-*/
- if (pf->fw8_3gt) {
- if (!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
- rxmode->offloads |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
- i40e_vlan_offload_set(dev, RTE_ETH_VLAN_EXTEND_MASK);
- }
- }
-
ret = rte_eth_switch_domain_free(pf->switch_domain_id);
if (ret)
PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
@@ -3950,20 +3937,8 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
else if (vlan_type == RTE_ETH_VLAN_TYPE_INNER)
hw->second_tag = rte_cpu_to_le_16(tpid);
} else {
- /*
-* If tpid is equal to 0x88A8, indicates that the
-* disable double VLAN operation is in progress.
-* Need set switch configuration back to default.
-*/
- if (pf->fw8_3gt && tpid == RTE_ETHER_TYPE_QINQ) {
- sw_flags = 0;
- valid_flags = I40E_AQ_SET_SWITCH_CFG_OUTER_VLAN;
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->first_tag = rte_cpu_to_le_16(tpid);
- } else {
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->second_tag = rte_cpu_to_le_16(tpid);
- }
+ if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
+ hw->second_tag = rte_cpu_to_le_16(tpid);
}
ret = i40e_aq_set_switch_config(hw, sw_flags,
valid_flags, 0, NULL);
@@ -4043,6 +4018,12 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
}
if (mask & RTE_ETH_VLAN_EXTEND_MASK) {
+ /* Sync the kernel driver. Double VLAN not allowed to be
disabled.*/
+ if (pf->fw8_3gt && !(rxmode->offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
+ PMD_DRV_LOG(WARNING,
+ "Disable double VLAN is not allowed after
firmwarev8.3!");
+ return 0;
+ }
i = 0;
num = vsi->mac_num;
mac_filter = rte_zmalloc("mac_filter_info_data",
@@ -4078,9 +4059,6 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
i40e_vlan_tpid_set(dev, RTE_ETH_VLAN_TYPE_INNER,
RTE_ETHER_TYPE_VLAN);
} else {
-
[PATCH 1/2] net/txgbe: fix customized devices probe failure
The devices with OEM subsystem vendor ID failed to be initialized,
because flash was read before memory address was set.
Fixes: 138d869e41c0 ("net/txgbe: support OEM subsystem vendor ID")
Signed-off-by: Jiawen Wu
---
drivers/net/txgbe/txgbe_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/txgbe/txgbe_ethdev.c b/drivers/net/txgbe/txgbe_ethdev.c
index dc8c3c70a9..9dc9948219 100644
--- a/drivers/net/txgbe/txgbe_ethdev.c
+++ b/drivers/net/txgbe/txgbe_ethdev.c
@@ -591,6 +591,8 @@ eth_txgbe_dev_init(struct rte_eth_dev *eth_dev, void
*init_params __rte_unused)
rte_eth_copy_pci_info(eth_dev, pci_dev);
+ hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
+
/* Vendor and Device ID need to be set before init of shared code */
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
@@ -607,7 +609,6 @@ eth_txgbe_dev_init(struct rte_eth_dev *eth_dev, void
*init_params __rte_unused)
}
hw->subsystem_device_id = (u16)ssid >> 8 | (u16)ssid << 8;
}
- hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
hw->allow_unsupported_sfp = 1;
/* Reserve memory for interrupt status block */
--
2.27.0
[PATCH 2/2] net/ngbe: fix customized devices probe failure
The devices with OEM subsystem vendor ID failed to be initialized,
because flash was read before memory address was set.
Fixes: 240422edbf84 ("net/ngbe: support OEM subsystem vendor ID")
Signed-off-by: Jiawen Wu
---
drivers/net/ngbe/ngbe_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ngbe/ngbe_ethdev.c b/drivers/net/ngbe/ngbe_ethdev.c
index 308c231183..86c28099c4 100644
--- a/drivers/net/ngbe/ngbe_ethdev.c
+++ b/drivers/net/ngbe/ngbe_ethdev.c
@@ -363,6 +363,8 @@ eth_ngbe_dev_init(struct rte_eth_dev *eth_dev, void
*init_params __rte_unused)
rte_eth_copy_pci_info(eth_dev, pci_dev);
eth_dev->data->dev_flags |= RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
+ hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
+
/* Vendor and Device ID need to be set before init of shared code */
hw->back = pci_dev;
hw->device_id = pci_dev->id.device_id;
@@ -381,7 +383,6 @@ eth_ngbe_dev_init(struct rte_eth_dev *eth_dev, void
*init_params __rte_unused)
hw->sub_system_id = (u16)ssid >> 8 | (u16)ssid << 8;
}
ngbe_map_device_id(hw);
- hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
/* Reserve memory for interrupt status block */
mz = rte_eth_dma_zone_reserve(eth_dev, "ngbe_driver", -1,
--
2.27.0
Re: [PATCH] doc: announce support for MACsec in rte_security
On 6/29/2022 12:38 AM, Akhil Goyal wrote: MACsec support is planned for DPDK 22.11, which would result in ABI breakage in some of the rte_security structures. This patch is to give deprecation notice for the affected structures. Signed-off-by: Akhil Goyal --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..1c3bf54d72 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -116,6 +116,11 @@ Deprecation Notices pointer for the private data to the application which can be attached to the packet while enqueuing. +* security: MACsec support is planned to be added in DPDK 22.11 which would + result in updates to structures ``rte_security_macsec_xform``, + ``rte_security_macsec_stats`` and security capability structure + ``rte_security_capability`` to accomodate MACsec capabilities. + * metrics: The function ``rte_metrics_init`` will have a non-void return in order to notify errors instead of calling ``rte_exit``. Acked-by: Hemant Agrawal
[PATCH] doc: notice to deprecate DPAA2 cmdif raw driver
dpaa2_cmdif raw driver is no longer in use, so it will be removed in v22.11 Signed-off-by: Gagandeep Singh --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..d279fcc99b 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,6 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* raw/dpaa2_cmdif/: The ``dpaa2_cmdif`` rawdev driver will be deprecated + in 22.11, as it is no longer in use, no active user known. -- 2.25.1
Re: [PATCH] doc: notice to deprecate DPAA2 cmdif raw driver
Acked-by: Hemant Agrawal On 6/29/2022 10:08 AM, Gagandeep Singh wrote: dpaa2_cmdif raw driver is no longer in use, so it will be removed in v22.11 Signed-off-by: Gagandeep Singh --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c53d..d279fcc99b 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -125,3 +125,6 @@ Deprecation Notices applications should be updated to use the ``dmadev`` library instead, with the underlying HW-functionality being provided by the ``ioat`` or ``idxd`` dma drivers + +* raw/dpaa2_cmdif/: The ``dpaa2_cmdif`` rawdev driver will be deprecated + in 22.11, as it is no longer in use, no active user known.
Re: Service core statistics MT safety
On 2022-06-28 21:15, Honnappa Nagarahalli wrote: From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] Sent: Monday, 27 June 2022 13.06 Hi. Is it safe to enable stats on MT safe services? https://protect2.fireeye.com/v1/url?k=31323334-501d5122- 313273af - 4 5444731-6096fdb16385f88f&q=1&e=27b94605-d1e2-40b6- af6d- 9ebc54d 5db18&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain% 2Flib %2Feal%2Fcommon%2Frte_service.c%23 L3 6 6 It seems to me this would have to be an __atomic_add for this code to produce deterministic results. I agree. The same goes for the 'calls' field. The calling function does the locking. https://protect2.fireeye.com/v1/url?k=31323334-501d5122- 313273af - 454 44731-5ce419f8bf9f9b76&q=1&e=27b94605-d1e2-40b6-af6d- 9ebc54d5db1 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib %2Feal %2Fcommon%2Frte_service.c%23L3 98 For more information you can look at: https://protect2.fireeye.com/v1/url?k=31323334-501d5122- 313273af - 454 44731-ba0d1416f08856f0&q=1&e=27b94605-d1e2-40b6- af6d- 9ebc54d5db1 8&u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib %2Feal %2Finclude%2Frte_service.h%23L 120 What about the https://protect2.fireeye.com/v1/url?k=31323334-501d5122- 313273af- 4544 4731-b64334addc78c264&q=1&e=27b94605-d1e2-40b6-af6d- 9ebc54d5db18& u=https%3A%2F%2Fgithub.com%2FDPDK%2Fdpdk%2Fblob%2Fmain%2Flib%2 Feal%2F common%2Frte_service.c%23L404 call (for MT safe services)? There's no lock held there. Good point. This is the case where the service running in service cores is MT safe. However, the stats are incremented outside of the MT Safety mechanism employed by the service. So, yes, this and other updates in the function 'service_runner_do_callback' need to be updated atomically. Maybe a better solution would be to move this to the core_state struct (and eliminate the "calls" field since the same information is already in the core_state struct). The contention on these cache lines will be pretty crazy for services with short run time (say a thousand cycles or less per call), assuming they are mapped to many cores. That's one option, the structures are internal as well. With this option stats need to be aggregated which will not give an accurate view. But, that is the nature of the statistics. Per-core counters is a very common pattern. Used for Linux MIB counters, for example. I'm not sure I think it's much less accurate. I mean, you just load in quick succession what's globally visible for the different per-lcore counters. If you do a relaxed store on an ARM, how long time does it take until it's seen by someone doing a relaxed load on a different core? Roughly. I think my explanation of the problem is not clear. If a service is running on more than one core and the stats are per core, when we aggregate, the resulting statistics is not atomic. By making the stats per core, we will be taking out that feature which is present currently (even though it is implemented incorrectly). As we agree, the proposed change is a common pattern and taking away the atomicity of the stats might not be a problem. Isn't it just a push model, versus a pull one? Both give just an approximation, albeit a very good one, of how many cycles are spent "now" for a particular service. Isn't time a local phenomena in a SMP system, and there is no global "now"? Maybe you can achieve such with a transaction or handshake of some sort, but I don't see how the an __atomic_add would be enough. If we consider a global time line of events, using atomic operation will provide a single 'now' from the reader's perspective (of course there might be writers waiting to update). Without the atomic operations, there will not be a single 'now' from reader's perspective, there will be multiple read events on the timeline. At the time of the read operation (in the global counter solution), there may well be cycles consumed or calls having been made, but not yet posted. The window between call having been made, and global counter having been incremented (and thus made globally visible) is small, but non-zero. (The core-local counter solution also use atomic operations, although not __atomic_add, but store, for the producer, and load, for the consumer.) I was fortunate to get some data from a real-world application, and enabling service core stats resulted in a 7% degradation of overall system capacity. I'm guessing atomic instructions would not make things better. Is the service running on multiple cores? Yes. I think something like 6 cores were used in this case. The effect will grow with core count, obviously. On a large system, I don't think you will do much else but fight for this cache line. If you want post counter updates to some shared data structure, you need to batch the updates to achieve reasonable efficiency. That will be, obviously, at the cost of accuracy, since
[PATCH v3] net/i40e: fix error disable double VLAN
Enable double VLAN by default after firmware v8.3
and disable double VLAN is not allowed in subsequent
operations.
Fixes: 4f13a78f1b8f ("net/i40e: add outer VLAN processing")
Signed-off-by: Kevin Liu
v3: refine commit log
v2: update the document
---
doc/guides/nics/i40e.rst | 5 ++--
drivers/net/i40e/i40e_ethdev.c | 46 --
2 files changed, 18 insertions(+), 33 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a7b51618b0..d051c7ec36 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -969,11 +969,10 @@ it will fail and return the info "Conflict with the first
rule's input set",
which means the current rule's input set conflicts with the first rule's.
Remove the first rule if want to change the input set of the PCTYPE.
-PF reset fail after QinQ set with FW >= 8.4
+Disable Qinq is not supported when FW >= 8.4
~~~
-If upgrade FW to version 8.4 and higher, after set MAC VLAN filter and
configure outer VLAN on PF, kill
-DPDK process will cause the card crash.
+If upgrade FW to version 8.4 and higher, sync kernel driver, enable Qinq by
default and disable Qinq is not supported.
Example of getting best performance with l3fwd example
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index dd471d487e..95e6b1578c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2575,7 +2575,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
- struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
struct i40e_filter_control_settings settings;
struct rte_flow *p_flow;
uint32_t reg;
@@ -2588,18 +2587,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- /*
-* It is a workaround, if the double VLAN is disabled when
-* the program exits, an abnormal error will occur on the
-* NIC. Need to enable double VLAN when dev is closed.
-*/
- if (pf->fw8_3gt) {
- if (!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
- rxmode->offloads |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
- i40e_vlan_offload_set(dev, RTE_ETH_VLAN_EXTEND_MASK);
- }
- }
-
ret = rte_eth_switch_domain_free(pf->switch_domain_id);
if (ret)
PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
@@ -3950,20 +3937,8 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
else if (vlan_type == RTE_ETH_VLAN_TYPE_INNER)
hw->second_tag = rte_cpu_to_le_16(tpid);
} else {
- /*
-* If tpid is equal to 0x88A8, indicates that the
-* disable double VLAN operation is in progress.
-* Need set switch configuration back to default.
-*/
- if (pf->fw8_3gt && tpid == RTE_ETHER_TYPE_QINQ) {
- sw_flags = 0;
- valid_flags = I40E_AQ_SET_SWITCH_CFG_OUTER_VLAN;
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->first_tag = rte_cpu_to_le_16(tpid);
- } else {
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->second_tag = rte_cpu_to_le_16(tpid);
- }
+ if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
+ hw->second_tag = rte_cpu_to_le_16(tpid);
}
ret = i40e_aq_set_switch_config(hw, sw_flags,
valid_flags, 0, NULL);
@@ -4043,6 +4018,12 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
}
if (mask & RTE_ETH_VLAN_EXTEND_MASK) {
+ /* Double VLAN not allowed to be disabled.*/
+ if (pf->fw8_3gt && !(rxmode->offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
+ PMD_DRV_LOG(WARNING,
+ "Disable double VLAN is not allowed after
firmwarev8.3!");
+ return 0;
+ }
i = 0;
num = vsi->mac_num;
mac_filter = rte_zmalloc("mac_filter_info_data",
@@ -4078,9 +4059,6 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
i40e_vlan_tpid_set(dev, RTE_ETH_VLAN_TYPE_INNER,
RTE_ETHER_TYPE_VLAN);
} else {
- if (pf->
[PATCH v4] net/i40e: fix error disable double VLAN
Enable double VLAN by default after firmware v8.3
and disable double VLAN is not allowed in subsequent
operations.
Fixes: 4f13a78f1b8f ("net/i40e: add outer VLAN processing")
Signed-off-by: Kevin Liu
v4: fix warnig
v3: refine commit log
v2: update the document
---
doc/guides/nics/i40e.rst | 5 ++--
drivers/net/i40e/i40e_ethdev.c | 45 --
2 files changed, 17 insertions(+), 33 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index a7b51618b0..d051c7ec36 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -969,11 +969,10 @@ it will fail and return the info "Conflict with the first
rule's input set",
which means the current rule's input set conflicts with the first rule's.
Remove the first rule if want to change the input set of the PCTYPE.
-PF reset fail after QinQ set with FW >= 8.4
+Disable Qinq is not supported when FW >= 8.4
~~~
-If upgrade FW to version 8.4 and higher, after set MAC VLAN filter and
configure outer VLAN on PF, kill
-DPDK process will cause the card crash.
+If upgrade FW to version 8.4 and higher, sync kernel driver, enable Qinq by
default and disable Qinq is not supported.
Example of getting best performance with l3fwd example
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index dd471d487e..7ab788246c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2575,7 +2575,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = pci_dev->intr_handle;
- struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
struct i40e_filter_control_settings settings;
struct rte_flow *p_flow;
uint32_t reg;
@@ -2588,18 +2587,6 @@ i40e_dev_close(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
- /*
-* It is a workaround, if the double VLAN is disabled when
-* the program exits, an abnormal error will occur on the
-* NIC. Need to enable double VLAN when dev is closed.
-*/
- if (pf->fw8_3gt) {
- if (!(rxmode->offloads & RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
- rxmode->offloads |= RTE_ETH_RX_OFFLOAD_VLAN_EXTEND;
- i40e_vlan_offload_set(dev, RTE_ETH_VLAN_EXTEND_MASK);
- }
- }
-
ret = rte_eth_switch_domain_free(pf->switch_domain_id);
if (ret)
PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
@@ -3950,20 +3937,8 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
else if (vlan_type == RTE_ETH_VLAN_TYPE_INNER)
hw->second_tag = rte_cpu_to_le_16(tpid);
} else {
- /*
-* If tpid is equal to 0x88A8, indicates that the
-* disable double VLAN operation is in progress.
-* Need set switch configuration back to default.
-*/
- if (pf->fw8_3gt && tpid == RTE_ETHER_TYPE_QINQ) {
- sw_flags = 0;
- valid_flags = I40E_AQ_SET_SWITCH_CFG_OUTER_VLAN;
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->first_tag = rte_cpu_to_le_16(tpid);
- } else {
- if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
- hw->second_tag = rte_cpu_to_le_16(tpid);
- }
+ if (vlan_type == RTE_ETH_VLAN_TYPE_OUTER)
+ hw->second_tag = rte_cpu_to_le_16(tpid);
}
ret = i40e_aq_set_switch_config(hw, sw_flags,
valid_flags, 0, NULL);
@@ -4043,6 +4018,12 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
}
if (mask & RTE_ETH_VLAN_EXTEND_MASK) {
+ /* Double VLAN not allowed to be disabled.*/
+ if (pf->fw8_3gt && !(rxmode->offloads &
RTE_ETH_RX_OFFLOAD_VLAN_EXTEND)) {
+ PMD_DRV_LOG(WARNING,
+ "Disable double VLAN is not allowed after
firmwarev8.3!");
+ return 0;
+ }
i = 0;
num = vsi->mac_num;
mac_filter = rte_zmalloc("mac_filter_info_data",
@@ -4078,9 +4059,6 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
i40e_vlan_tpid_set(dev, RTE_ETH_VLAN_TYPE_INNER,
RTE_ETHER_TYPE_VLAN);
} else {
-
RE: [PATCH v5] gro: bug fix in identifying fragmented packets
Reviewed-by: Jiayu Hu
Thanks,
Jiayu
> -Original Message-
> From: Kumara Parameshwaran
> Sent: Monday, June 27, 2022 6:31 PM
> To: Hu, Jiayu
> Cc: dev@dpdk.org; Kumara Parameshwaran
> ; sta...@dpdk.org
> Subject: [PATCH v5] gro: bug fix in identifying fragmented packets
>
> From: Kumara Parameshwaran
>
> A packet with RTE_PTYPE_L4_FRAG(0x300) contains both RTE_PTYPE_L4_TCP
> (0x100) & RTE_PTYPE_L4_UDP (0x200). A fragmented packet as defined in
> rte_mbuf_ptype.h cannot be recognized as other L4 types and hence the
> GRO layer should not use IS_IPV4_TCP_PKT or IS_IPV4_UDP_PKT for
> RTE_PTYPE_L4_FRAG. Hence, if the packet type is RTE_PTYPE_L4_FRAG the ip
> header should be parsed to recognize the appropriate IP type and invoke the
> respective gro handler.
>
> Fixes: 1ca5e6740852 ("gro: support UDP/IPv4")
> Cc: sta...@dpdk.org
> Signed-off-by: Kumara Parameshwaran
> ---
> v1:
> * Introduce IS_IPV4_FRAGMENT macro to check if fragmented packet and
> if true extract the IP header to identify the protocol type and
> invoke the appropriate gro handler. This is done for both
> rte_gro_reassemble and rte_gro_reassemble_burst APIs.
> v2,v3,v4:
> * Fix extra whitespace and column limit warnings
> v5
> * Use RTE_PTYPE_L4_FRAG to identify the fragmented packets in
> IS_IPV4_TCP_PKT and IS_IPV4_VXLAN_TCP4_PKT
>
> lib/gro/rte_gro.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/gro/rte_gro.c b/lib/gro/rte_gro.c index
> 6f7dd4d709..e35399fd42 100644
> --- a/lib/gro/rte_gro.c
> +++ b/lib/gro/rte_gro.c
> @@ -32,6 +32,7 @@ static gro_tbl_pkt_count_fn
> tbl_pkt_count_fn[RTE_GRO_TYPE_MAX_NUM] = {
>
> #define IS_IPV4_TCP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \
> ((ptype & RTE_PTYPE_L4_TCP) == RTE_PTYPE_L4_TCP) && \
> + ((ptype & RTE_PTYPE_L4_FRAG) != RTE_PTYPE_L4_FRAG) &&
> \
> (RTE_ETH_IS_TUNNEL_PKT(ptype) == 0))
>
> #define IS_IPV4_UDP_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype) && \ @@ -
> 40,6 +41,7 @@ static gro_tbl_pkt_count_fn
> tbl_pkt_count_fn[RTE_GRO_TYPE_MAX_NUM] = {
>
> #define IS_IPV4_VXLAN_TCP4_PKT(ptype) (RTE_ETH_IS_IPV4_HDR(ptype)
> && \
> ((ptype & RTE_PTYPE_L4_UDP) == RTE_PTYPE_L4_UDP) && \
> + ((ptype & RTE_PTYPE_L4_FRAG) != RTE_PTYPE_L4_FRAG) &&
> \
> ((ptype & RTE_PTYPE_TUNNEL_VXLAN) == \
>RTE_PTYPE_TUNNEL_VXLAN) && \
> ((ptype & RTE_PTYPE_INNER_L4_TCP) == \
> --
> 2.25.1
