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? Thanks, Marcin
