On 2020-06-07 04:41, Cliff Burdick wrote:
I can't tell from your code, but you assigned nb_rx to the number of
packets received, but then used vec_size, which might be larger. Does
this happen if you use nb_rx in your loops?
No, this doesn't happen.
I just skip the part of the code that translates nb_rx to vec_size,
since that code is double checked.
My actual question now is about possible impact of using
incorrect values of mbuf's pkt_len and data_len fields.
On Sat, Jun 6, 2020 at 5:59 AM Alex Kiselev <[email protected]>
wrote:
1 июня 2020 г., в 19:17, Stephen Hemminger
<[email protected]> написал(а):
On Mon, 01 Jun 2020 15:24:25 +0200
Alex Kiselev <[email protected]> wrote:
Hello,
I've got a segmentation fault error in my data plane path.
I am pretty sure the code where the segfault happened is ok,
so my guess is that I somehow received a corrupted mbuf.
How could I troubleshoot this? Is there any way?
Is it possible that other threads of the application
corrupted that mbuf?
I would really appriciate any advice.
Thanks.
DPDK 18.11.3
NIC: 82599ES
Code:
nb_rx = rte_eth_rx_burst(port_id, queue_id, pkts_burst,
MAX_PKT_BURST);
...
for (i=0; i < vec_size; i++) {
rte_prefetch0(rte_pktmbuf_mtod(m_v[i], void *));
for (i=0; i < vec_size; i++) {
m = m_v[i];
eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
eth_type = rte_be_to_cpu_16(eth_hdr->ether_type);
<---
Segmentation fault
...
#0 rte_arch_bswap16 (_x=<error reading variable: Cannot access
memory
at address 0x4d80000000053010>)
Build with as many of the debug options turned on in the DPDK
config,
and build with EXTRA_CFLAGS of -g.
Could using an incorrect (a very big one) value of mbuf pkt_len and
data_len while transmitting cause mbuf corruption and following
segmentation fault on rx?
