Re: Reorganising how the networking layer handles memory

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 02 May 2025 17:21:48 +0100 David Howells wrote:
> Okay, perhaps I should start at the beginning :-).

Thanks :) Looks like Eric is CCed, also adding Willem.
The direction of using ubuf_info makes sense to me.
Random comments below on the little I know.

> There a number of things that are going to mandate an overhaul of how the
> networking layer handles memory:
> 
>  (1) The sk_buff code assumes it can take refs on pages it is given, but the
>      page ref counter is going to go away in the relatively near term.
> 
>      Indeed, you're already not allowed to take a ref on, say, slab memory,
>      because the page ref doesn't control the lifetime of the object.
> 
>      Even pages are going to kind of go away.  Willy haz planz...

I think the part NVMe folks run into is the BPF integration layer
called skmsg. It's supposed to be a BPF-based "data router", at
the socket layer, before any protocol processing, so it tries
to do its own page ref accounting..

>  (2) sendmsg(MSG_ZEROCOPY) suffers from the O_DIRECT vs fork() bug because it
>      doesn't use page pinning.  It needs to use the GUP routines.

We end up calling iov_iter_get_pages2(). Is it not setting
FOLL_PIN is a conscious choice, or nobody cared until now?

>  (3) sendmsg(MSG_SPLICE_PAGES) isn't entirely satisfactory because it can't be
>      used with certain memory types (e.g. slab).  It takes a ref on whatever
>      it is given - which is wrong if it should pin this instead.

s/takes a ref/requires a ref/ ? I mean - the caller implicitly grants 
a ref  to the stack, right? But yes, the networking stack will try to
release it.

>  (4) iov_iter extraction will probably change to dispensing {physaddr,len}
>      tuples rather than {page,off,len} tuples.  The socket layer won't then
>      see pages at all.
>
>  (5) Memory segments splice()'d into a socket may have who-knows-what weird
>      lifetime requirements.
> 
> So after discussions at LSF/MM, what I'm proposing is this:
> 
>  (1) If we want to use zerocopy we (the kernel) have to pass a cleanup
>      function to sendmsg() along with the data.  If you don't care about
>      zerocopy, it will copy the data.

TAL at struct ubuf_info

>  (2) For each message sent with sendmsg, the cleanup function is called
>      progressively as parts of the data it included are completed.  I would do
>      it progressively so that big messages can be handled.
> 
>  (3) We also pass an optional 'refill' function to sendmsg.  As data is sent,
>      the code that extracts the data will call this to pin more user bufs (we
>      don't necessarily want to pin everything up front).  The refill function
>      is permitted to sleep to allow the amount of pinned memory to subside.

Why not feed the data as you get the notifications for completion?

>  (4) We move a lot the zerocopy wrangling code out of the basement of the
>      networking code and put it at the system call level, above the call to
>      ->sendmsg() and the basement code then calls the appropriate functions to  
>      extract, refill and clean up.  It may be usable in other contexts too -
>      DIO to regular files, for example.
> 
>  (5) The SO_EE_ORIGIN_ZEROCOPY completion notifications are then generated by
>      the cleanup function.

Already the case? :)

>  (6) The sk_buff struct does not retain *any* refs/pins on memory fragments it
>      refers to.  This is done for it by the zerocopy layer.