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.