Re: [PATCH bpf] xsk: Do not free ZC Rx buffer when the Rx ring is full

From: Marcin Knap

Date: Tue Oct 20 2026 - 11:09:45 EST


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