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

["Björn Töpel" <bjorn@kernel.org>]

Marcin Knap <Marcin.Knap@vecima.com> 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