af_packet can't send packet more than framecnt
Hi, I used af_packet interface, but found only can send packets successfully less than framecnt argument. E.g. if I pass "--vdev=eth_af_packet0,iface=tap0,blocksz=4096,framesz=2048,framecnt=512,qpa irs=1,qdisc_bypass=0" to DPDK, the rte_eth_tx_burst only return 1 for 512 times, after that it always return 0. If I pass "--vdev=eth_af_packet0,iface=tap0,blocksz=4096,framesz=2048,framecnt=1024,qp airs=1,qdisc_bypass=0" to DPDK, the rte_eth_tx_burst only return 1 for 1024 times, after that it always return 0. BTW, I use busy loop mode in project, Is there any help for this? Thanks so much Haifeng
回复: af_packet can't send packet more than framecnt
Hi,
The issue has been resolved when I patched new code from dpdk 22.12, my dpdk
version is 19.11
Index: rte_eth_af_packet.c
===
--- rte_eth_af_packet.c (版本 44115)
+++ rte_eth_af_packet.c (版本 44128)
@@ -169,6 +169,29 @@
}
/*
+ * Check if there is an available frame in the ring
+ */
+static inline int
+tx_ring_status_available(uint32_t tp_status)
+{
+ /*
+* We eliminate the timestamp status from the packet status.
+* This should only matter if timestamping is enabled on the socket,
+* but there is a bug in the kernel which is fixed in newer
releases.
+*
+* See the following kernel commit for reference:
+* commit 171c3b151118a2fe0fc1e2a9d1b5a1570cfe82d2
+* net: packetmmap: fix only tx timestamp on request
+*/
+ tp_status &= ~(TP_STATUS_TS_SOFTWARE | TP_STATUS_TS_RAW_HARDWARE);
+
+ if (tp_status == TP_STATUS_AVAILABLE)
+return 1;
+
+return 0;
+}
+
+/*
* Callback to handle sending packets through a real NIC.
*/
static uint16_t
@@ -213,7 +236,7 @@
}
/* point at the next incoming frame */
- if (ppd->tp_status != TP_STATUS_AVAILABLE) {
+ if (!tx_ring_status_available(ppd->tp_status)) {
if (poll(&pfd, 1, -1) < 0)
break;
@@ -236,7 +259,7 @@
*
* This results in poll() returning POLLOUT.
*/
- if (ppd->tp_status != TP_STATUS_AVAILABLE)
+ if (!tx_ring_status_available(ppd->tp_status))
break;
/* copy the tx frame data */
Thanks,
Haifeng
-邮件原件-
发件人: h...@netitest.com
发送时间: 2023年3月20日 11:32
收件人: 'dev@dpdk.org'
主题: af_packet can't send packet more than framecnt
Hi,
I used af_packet interface, but found only can send packets successfully
less than framecnt argument.
E.g. if I pass “--vdev=eth_af_packet0,iface=tap0,blocksz=4096,framesz=2048,
framecnt=512,qpairs=1,qdisc_bypass=0” to DPDK, the rte_eth_tx_burst only
return 1 for 512 times, after that it always return 0.
If I pass
“--vdev=eth_af_packet0,iface=tap0,blocksz=4096,framesz=2048,framecnt=1024,q
pairs=1,qdisc_bypass=0” to DPDK, the rte_eth_tx_burst only return 1 for
1024 times, after that it always return 0.
BTW, I use busy loop mode in project, Is there any help for this?
Thanks so much
Haifeng
回复: 回复: af_packet can't send packet more than framecnt
Hi Stephen,
Thanks for your response, my OS is CentOS7.9, so the kernel is 3.10. However,
the issue has been resolved depend on new DPDK code.
Regards,
Haifeng
-邮件原件-
发件人: Stephen Hemminger
发送时间: 2023年3月21日 0:54
收件人: h...@netitest.com
抄送: dev@dpdk.org
主题: Re: 回复: af_packet can't send packet more than framecnt
On Mon, 20 Mar 2023 19:36:02 +0800
wrote:
> Hi,
>
> The issue has been resolved when I patched new code from dpdk 22.12,
> my dpdk version is 19.11
>
> Index: rte_eth_af_packet.c
> ===
> --- rte_eth_af_packet.c (版本 44115)
> +++ rte_eth_af_packet.c (版本 44128)
> @@ -169,6 +169,29 @@
> }
>
> /*
> + * Check if there is an available frame in the ring */ static inline
> +int tx_ring_status_available(uint32_t tp_status) {
> + /*
> +* We eliminate the timestamp status from the packet status.
> +* This should only matter if timestamping is enabled on the socket,
> +* but there is a bug in the kernel which is fixed in newer
> releases.
> +*
> +* See the following kernel commit for reference:
> +* commit 171c3b151118a2fe0fc1e2a9d1b5a1570cfe82d2
> +* net: packetmmap: fix only tx timestamp on request
Thanks for investigating, what kernel are you using?
That bug was fixed in 5.13 kernel (in 2021-05-11) almost 2 years ago.
It looks like it was also fixed in the LTS stable kernels.
DPDK probably should not be modified to handle kernel bugs that are ready fixed
in the current kernel LTS versions.
build dpdk error by gcc 8.4.0
Hi Dev,
When I build dpdk on CentOS7.9 and GCC 8.4.0, it throw “operand type
mismatch for `vpclmulqdq'”, how can I fix this?
FAILED: lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o
ccache cc -Ilib/net/libnet_crc_avx512_lib.a.p -Ilib/net -I../lib/net -I.
-I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I..
/lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../lib/telemetry -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -O3 -include rte_config.h
-Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-DCC_X86_64_SSE42_PCLMULQDQ_SUPPORT -DCC_X86_64_AVX512_VPCLMULQDQ_SUPPORT
-mavx512f -mavx512bw -mavx512dq -mavx512vl -mvpclmulqdq -mavx2 -mavx -MD -MQ
lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o -MF
lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o.d -o
lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o -c
../lib/net/net_crc_avx512.c
{standard input}: Assembler messages:
{standard input}:66: 错误：operand type mismatch for `vpclmulqdq'
Here are meson and ninja output:
# meson build
The Meson build system
Version: 0.55.1
Source dir: /home/daemon/dpdk_net/dpdk_env/dpdk-stable-22.11.1
Build dir: /home/daemon/dpdk_net/dpdk_env/dpdk-stable-22.11.1/build
Build type: native build
Program cat found: YES
Project name: DPDK
Project version: 22.11.1
C compiler for the host machine: ccache cc (gcc 8.4.0 "cc (GCC) 8.4.0")
C linker for the host machine: cc ld.bfd 2.27-41
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program pkg-config found: YES
Program check-symbols.sh found: YES
Program options-ibverbs-static.sh found: YES
Program objdump found: YES
Program python3 found: YES (/usr/bin/python3)
Program cat found: YES
Program ../buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh
/home/daemon/dpdk_net/dpdk_env/dpdk-stable-22.11.1/config/../buildtools/syml
ink-drivers-solibs.sh)
Checking for size of "void *" : 8
Checking for size of "void *" : 8
Library m found: YES
Library numa found: YES
Has header "numaif.h" : YES
Library libfdt found: NO
Library libexecinfo found: NO
Found pkg-config: /bin/pkg-config (0.27.1)
Run-time dependency libarchive found: NO (tried pkgconfig)
Run-time dependency libbsd found: NO (tried pkgconfig)
Run-time dependency jansson found: YES 2.12
Run-time dependency openssl found: YES 1.0.2k
Run-time dependency libpcap found: NO (tried pkgconfig)
Library pcap found: YES
Has header "pcap.h" with dependency -lpcap: YES
Compiler for C supports arguments -Wcast-qual: YES
Compiler for C supports arguments -Wdeprecated: YES
Compiler for C supports arguments -Wformat: YES
Compiler for C supports arguments -Wformat-nonliteral: YES
Compiler for C supports arguments -Wformat-security: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wsign-compare: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wwrite-strings: YES
Compiler for C supports arguments -Wno-address-of-packed-member
-Waddress-of-packed-member: NO
Compiler for C supports arguments -Wno-packed-not-aligned
-Wpacked-not-aligned: YES
Compiler for C supports arguments -Wno-missing-field-initializers
-Wmissing-field-initializers: YES
Compiler for C supports arguments -mavx512f: YES
Checking if "AVX512 checking" compiles: YES
Fetching value of define "__SSE4_2__" : 1
Fetching value of define "__AES__" : 1
Fetching value of define "__AVX__" : 1
Fetching value of define "__AVX2__" : 1
Fetching value of define "__AVX512BW__" :
Fetching value of define "__AVX512CD__" :
Fetching value of define "__AVX512DQ__" :
Fetching value of define "__AVX512F__" :
Fetching value of define "__AVX512VL__" :
Fetching value of define "__PCLMUL__" : 1
Fetching value of define "__RDRND__" : 1
Fetching value of define "__RDSEED__" : 1
Fetching value of define "__VPCLMULQDQ__" :
Compiler for C supports arguments -Wno-format-truncation
-Wformat-truncation: YES
Checking for function "getentropy" : NO
Fetching value of define "__PCLMUL__" : 1 (cached)
Fetching value of define "__AVX512F__" : (cached)
Compiler for C supports arguments -mpclmul: YES
Compiler for C supports
回复: build dpdk error by gcc 8.4.0
Hi Bruce,
The issue has been fixed after I upgrade binutis to 2.38, thanks a lot.
Regards,
Haifeng
-邮件原件-
发件人: Bruce Richardson
发送时间: 2023年3月21日 19:54
收件人: h...@netitest.com
抄送: dev@dpdk.org
主题: Re: build dpdk error by gcc 8.4.0
On Tue, Mar 21, 2023 at 03:13:14PM +0800, h...@netitest.com wrote:
> Hi Dev,
>
> When I build dpdk on CentOS7.9 and GCC 8.4.0, it throw “operand type
> mismatch for `vpclmulqdq'”, how can I fix this?
>
> FAILED: lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o
> ccache cc -Ilib/net/libnet_crc_avx512_lib.a.p -Ilib/net -I../lib/net -I.
> -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
> -Ilib/eal/linux/include -I../lib/eal/linux/include
> -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common
> -I../lib/eal/common -Ilib/eal -I..
> /lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
> -Ilib/telemetry -I../lib/telemetry -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -O3 -include
> rte_config.h -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral
> -Wformat-security -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> -DCC_X86_64_SSE42_PCLMULQDQ_SUPPORT
> -DCC_X86_64_AVX512_VPCLMULQDQ_SUPPORT
> -mavx512f -mavx512bw -mavx512dq -mavx512vl -mvpclmulqdq -mavx2 -mavx
> -MD -MQ lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o -MF
> lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o.d -o
> lib/net/libnet_crc_avx512_lib.a.p/net_crc_avx512.c.o -c
> ../lib/net/net_crc_avx512.c {standard input}: Assembler messages:
> {standard input}:66: 错误：operand type mismatch for `vpclmulqdq'
>
The assembler generally comes from the binutils package rather than with gcc,
so it could be a mismatch between new compiler and older assembler.
You could try getting a newer copy of binutils and see if that fixes it.
Alternatively, you can just try building with a target instruction set which
does not include vpcmulqdq (unless you need the code that uses that
instruction). Try configuring a build with
"-Dcpu_instruction_set=skylake-avx512", and see if that works. According to the
man page for gcc, that should give you AVX512 support, but not the problematic
instruction.
/Bruce
[dpdk-dev] How to send packet with line rate on I350-DA2, but not care rx speed
Wenzhuo, >From "MAINTAINERS" file in package of dpdk source code, I know that you maintain e1000e driver now, could you help me for an question? I use DPDK-pktgen based on Intel I350-DA2 network adapters, when I loopback two ports on one NIC(I350_eth1 <-> I350_eth2), I got 1Gbps line rate TX throughput. But when I link a Firewall between two ports, just like I350_eth1 -> Firewall_port1 -> Firewall_port2 -> I350_eth2, even I try to burst tx throughput as line rate by power CPU cores, it only get 600Mbps tx throughput which is firewall's rx speed, seem the tx speed from I350 just depend on peer firewall rx capability. I try this on others network adapters like X520-DA2 and X710DA2, both of them got different results, tx speed only depend on CPU power, but no related with rx capability of network devices. Could you know why of this? Is there any configuration/interface/register update this feature? Let us send packet with line rate, but not care rx speed. / # lspci | grep I350 0e:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 0e:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) / # Thanks and Regards, Haifeng
[dpdk-dev] 8023ad bond tx crashed if one port has 2 more tx queues
Hi Guys,
I found a bug in dpdk bond code, while one port has 2 more tx queues, 8023ad
bond port will be crashed in tx burst.
Just analyzed the code below, if 2 more CPU cores send packets on a port by
different tx queue, the arrays like
slave_port_ids/ dist_slave_port_ids/ slave_tx_fail_coun/ slave_bufs will be
shared by all of cores, it will be crashed in this function.
Is there any better solution for this? For now, I just add lock for
rte_eth_tx_burst.
static uint16_t
bond_ethdev_tx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
uint16_t nb_bufs)
{
struct bond_tx_queue *bd_tx_q = (struct bond_tx_queue *)queue;
struct bond_dev_private *internals = bd_tx_q->dev_private;
uint16_t [RTE_MAX_ETHPORTS];
uint16_t slave_count;
uint16_t dist_slave_port_ids[RTE_MAX_ETHPORTS];
uint16_t dist_slave_count;
/* 2-D array to sort mbufs for transmission on each slave into */
struct rte_mbuf *slave_bufs[RTE_MAX_ETHPORTS][nb_bufs];
/* Number of mbufs for transmission on each slave */
uint16_t slave_nb_bufs[RTE_MAX_ETHPORTS] = { 0 };
/* Mapping array generated by hash function to map mbufs to slaves
*/
uint16_t bufs_slave_port_idxs[RTE_MAX_ETHPORTS] = { 0 };
uint16_t slave_tx_count, slave_tx_fail_count[RTE_MAX_ETHPORTS] = {
0 };
uint16_t total_tx_count = 0, total_tx_fail_count = 0;
Thanks and Regards,
Haifeng
