On 6/9/25 23:58, Jakub Kicinski wrote:
On Fri, 6 Jun 2025 22:48:53 +0700 Bui Quang Minh wrote:
But currently, if a multi-buffer packet arrives, it will not go through XDP program so it doesn't increase the stats but still goes to network stack. So I think it's not a correct behavior.
Sounds fair, but at a glance the normal XDP path seems to be trying to linearize the frame. Can we not try to flatten the frame here? If it's simply to long for the chunk size that's a frame length error, right?
Here we are in the zerocopy path, so the buffers for the frame to fill in are allocated from XDP socket's umem. And if the frame spans across multiple buffers then the total frame size is larger than the chunk size.
Is that always the case? Can the multi-buf not be due to header-data split of the incoming frame? (I'm not familiar with the virtio spec)
Ah, maybe I cause some confusion :) zerocopy here means zerocopy if the frame is redirected to XDP socket. In this zerocopy mode, XDP socket will provide buffers to virtio-net, the frame from vhost will be placed in those buffers. If the bind XDP program in virtio-net returns XDP_REDIRECT to that XDP socket, then the frame is zerocopy. In case XDP_PASS is returned, the frame's data is copied to newly created skb and the frame's buffer is returned to XDP socket. AFAIK, virtio-net has not supported header-data split yet.
Furthermore, we are in the zerocopy so we cannot linearize by allocating a large enough buffer to cover the whole frame then copy the frame data to it. That's not zerocopy anymore. Also, XDP socket zerocopy receive has assumption that the packet it receives must from the umem pool. AFAIK, the generic XDP path is for copy mode only.
Generic XDP == do_xdp_generic(), here I think you mean the normal XDP patch in the virtio driver? If so then no, XDP is very much not expected to copy each frame before processing.
Yes, I mean generic XDP = do_xdp_generic(). I mean that we can linearize the frame if needed (like in netif_skb_check_for_xdp()) in copy mode for XDP socket but not in zerocopy mode.
This is only slightly related to you patch but while we talk about multi-buf - in the netdev CI the test which sends ping while XDP multi-buf program is attached is really flaky :( https://netdev.bots.linux.dev/contest.html?executor=vmksft-drv-hw&test=p...
metal-drv-hw means the NETIF is the real NIC, right?
Thanks, Quang Minh.