Hello, I believe commit 260aae9a [1] has introduced a regression for the case of 32-bit process running on a 64-bit kernel.
The commit is effectively casting mbuf->buf_physaddr to uintptr_t before dereferencing it. It truncates the physical address to the width of the process's uint, and in the the aforementioned combination this loses important bits. I can confirm this under GDB. When virtqueue_enqueue_xmit is filling in start_dp, I get this result: (gdb) p /x cookie->buf_physaddr $5 = 0x12f94a000 (gdb) p /x start_dp[idx].addr $6 = 0x2f94a080 On my system, I capture the packet that goes out to the host and I see it has the correct size but the content is all-zeroes. I would like to propose a patch that would work for all supported combinations of user/kernel bitwidth *and* virtio-pci/virtio-user. But I don't really see how that could work, given virtio-user tries to store a physical address in rte_mbuf's "void *buf_addr", and this is not always big enough for a physical address. Any suggestions on if and how this could be fixed? Meanwhile, the bug affects dpdk 17.05, 17.02.1 and master. Users not requiring virtio-user support can avoid it by setting CONFIG_VIRTIO_USER=n during compilation. Best regards, Frederico Cadete