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

[Pavel Begunkov]

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@xxxxxxxxx> 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