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

[Stanislav Fomichev]

On 09/25, Pavel Begunkov wrote:
> 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.

SG, none of these sound material to me :-p but I'll resubmit with io_uring
part removed. I do like the index approach (for halving the array memory
requirements), will switch devmem to it.