https://bugs.dpdk.org/show_bug.cgi?id=951
Bug ID: 951
Summary: net/mlx5: error when using rte_pktmbuf_attach_extbuf
Product: DPDK
Version: 21.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: bme...@sarao.ac.za
Target Milestone: ---
Created attachment 195
--> https://bugs.dpdk.org/attachment.cgi?id=195&action=edit
Sample code illustrating the bug
This is related to #949, but directly attaching external memory to each packet
rather than letting a mempool manage the external memory (because in my actual
application I want to transmit specific memory in each packet). I haven't been
able to find much documentation, so let me know if I'm just using it wrong.
The attached sample application allocates some external memory using mmap, then
attempts to transmit it as payload in a sequence of UDP multicast packets. It
fails and spits out a bunch of files with names like
dpdk_mlx5_port_0_txq_0_index_0_2644609052, which contain errors such as
Unexpected CQE error syndrome 0x04 CQN = 16 SQN = 5878 wqe_counter = 0 wq_ci =
64 cq_ci = 0
MLX5 Error SQ: at [0x1100b5e000], len=8192
When run with --log-level debug --log-level *:debug, there are messages like
this (one set per packet):
mlx5_common: Creating a MR using address (0x7f7a38400000)
mlx5_common: Extending 0x7f7a38400000 to [0x7f7a38400000, 0x7f7a38600000),
page_sz=0x200000, ms_n=1
mlx5_common: Unable to allocate memory for a new MR of address
(0x7f7a38400000).
Unlike #949, this is failing on HEAD (which is at v22.03-rc2).
I did a little debugging and the problem seems to be that
https://github.com/DPDK/dpdk/blob/v22.03-rc2/drivers/common/mlx5/mlx5_common_mr.c#L722-L724
calls mlx5_malloc with the socket ID from the memory segment, which is some
magic value (0x100) for the external memory. Lower down the call stack
malloc_socket_to_heap_id fails to find a heap_id for that socket_id.
--
You are receiving this mail because:
You are the assignee for the bug.
