Marcin Knap <[email protected]> writes: > On Tue, Oct 20, 2026 at 07:00:47AM +0000, Maciej Fijalkowski wrote: > >> Please don't top-post on MLs and configure your mail client to wrap your >> lines. Kernel people get triggered by this :P > > Sorry for that, I was trying but not good enough... > cannot setup this on web outlook and I have blocked every other client. > >> ZC drivers are supposed to break processing and yield cpu to >> application when xsk rxq gets full. We didn't want to expose >> particular packet multiple times to XDP progs as that might confuse >> internal logic of progs. Therefore we drop the packet in the core and >> let driver side know about this via ENOBUFS return value. > > Thanks, that explains it and it makes sense to me. > I will drop the core change and fix the > drivers that free the buffer again after -ENOBUFS instead. > >> Marcin, could you re-iterate why Jerome's fixes were not enough for >> you? > > This is how I understand this but I don't know this code well and I can be > wrong. > Jerome's patches stop mlx5e from releasing the same WQE buffer twice > when a refill is retried. They don't cover the case where the core > has already freed the buffer on -ENOBUFS. mlx5e_xdp_handle() treats > the failed redirect as XDP_DROP, skip-release isn't set, and the > buffer is released again when its slot is refilled. > > xp_free() only catches this if the buffer is still on the free list. > The free list is LIFO and refill allocates replacement buffers in > bulk, so the buffer freed by the core is usually handed to another > WQE before its old slot is refilled. The second free then puts a > buffer that is still in use back on the free list, and the same UMEM > frame is later published twice. > >> Would also be nice to align mlx-5 to -ENOBUFS case. > > Will do, I have potential mlx5 fix (this was my workaround). > > I did quick analysis with AI tool and it sounds like all drivers have > similar problem and they don't handle -ENOBUFS correctly except > Intel drivers needs_wakup path. Given that, would you prefer the driver > fixes, or do you have any other ideas?
Marcin, FWIW, we'll discuss this topic on the office hours today [1]. Feel free to join! I added a link with suggested wording for a future doc [2], and asked an LLM to audit the drivers [3]. Björn [1] https://lore.kernel.org/netdev/aqPxxX9MeGmAqGy6@boxer/ [2] https://gist.github.com/fb-bjorn/d6835c49650bc3433b427a9c9708fbe2 [3] https://gist.github.com/fb-bjorn/181786547c4dd8182ba09e23cf394dbe
