Re: [PATCH net-next 1/3] net: netmem: add net_iov_area freelist helpers

[Pavel Begunkov <asml.silence@gmail.com>]

On 9/24/26 17:48, Stanislav Fomichev wrote:
> On 09/24, Pavel Begunkov wrote:
>> On 9/24/26 16:02, Mina Almasry wrote:
>>> On Tue, Sep 22, 2026 at 1:43 PM Stanislav Fomichev <sdf.kernel@gmail.com> wrote:
>>>>
>>>> io_uring zero-copy receive and devmem both maintain a bounded LIFO for
>>>> net_iovs in a contiguous area. Store the freelist in struct net_iov_area
>>>> and provide common push and pop helpers.
>>>>
>>>> Leave synchronization to area owners. Keep devmem's area adjacent to its
>>>
>>> This could be a follow up change, but I think synchronization should
>>> be provided by the netmem/niov infra, rather than the area owners. TBH
>>> the infra providing an unsynchronized data structure and letting the
>>> area owner use it and shoot themselves in the foot feels error prone.
>>> For now we could use a comment.
>>
>> I don't think we want it. The duplication is minor, but I'm not set
>> on the per area index array approach, and it'd make changing it
>> more difficult.
> 
> Do you want me to not touch iou in this patch at all? Or are you talking
> about potential future synchronization part?

Sorry, I should've more specific. I meant that I don't think trying to
consolidate it at all makes much sense, and I'd just drop this patch.
> I don't see how this is making changing it more difficult, the freelist is
> now behind push/pop which you can freely change, and both UAPIs benefit
> from a faster/better freelist.

There are several reasons. If there is any mismatch in how it's done
b/w io_uring and devmem it'd need to be split back, and then having it
in struct net_iov_area for devmem only wouldn't make sense. E.g.
Packaging of {area/offset} pair if converted to a ifq global list might
differ. And it moves one part of buffer management to another tree, and
there was already a precedent of patches being blocked for no technical
reasons; I'd rather minimise cross-tree changes. Synchronisation might
also be a bit difficult, zcrx uses it to protect more than just the
freelist modifications, patterns like lock(zcrx_area->common_area.lock)
in the zcrx code is usually not a great idea. In general, I just think
the upside is smaller comparing to losing the development flexibility,
it's not it makes it faster, nor the current code is tricky or complex.
Hope it explains it.

-- 
Pavel Begunkov