netdev - Re: [PATCH net-next v6 05/12] net: homa: create homa_rpc.h and homa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iJ+mvp48F9tMmO=ttK3ai2WTVC7NNKy8YbV1d0wr-BD+Q@mail.gmail.com>
Date: Wed, 29 Jan 2025 21:40:56 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: John Ousterhout <ouster@...stanford.edu>
Cc: Paolo Abeni <pabeni@...hat.com>, Netdev <netdev@...r.kernel.org>, 
	Simon Horman <horms@...nel.org>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next v6 05/12] net: homa: create homa_rpc.h and homa_rpc.c

On Wed, Jan 29, 2025 at 9:27 PM John Ousterhout <ouster@...stanford.edu> wrote:
>
> On Wed, Jan 29, 2025 at 9:04 AM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Wed, Jan 29, 2025 at 5:55 PM John Ousterhout <ouster@...stanford.edu> wrote:
> > >
> > > On Wed, Jan 29, 2025 at 8:50 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > > >
> > > > On Wed, Jan 29, 2025 at 5:44 PM John Ousterhout <ouster@...stanford.edu> wrote:
> > > > >
> > > > > GRO is implemented in the "full" Homa (and essential for decent
> > > > > performance); I left it out of this initial patch series to reduce the
> > > > > size of the patch. But that doesn't affect the cost of freeing skbs.
> > > > > GRO aggregates skb's into batches for more efficient processing, but
> > > > > the same number of skb's ends up being freed in the end.
> > > >
> > > > Not at all, unless GRO is forced to use shinfo->frag_list.
> > > >
> > > > GRO fast path cooks a single skb for a large payload, usually adding
> > > > as many page fragments as possible.
> > >
> > > Are you referring to hardware GRO or software GRO? I was referring to
> > > software GRO, which is what Homa currently implements. With software
> > > GRO there is a stream of skb's coming up from the driver; regardless
> > > of how GRO re-arranges them, each skb eventually has to be freed, no?
> >
> > I am referring to software GRO.
> > We do not allocate/free skbs for each aggregated segment.
> > napi_get_frags() & napi_reuse_skb() for details.
>
>  YATIDNK (Yet Another Thing I Did Not Know); thanks for the information.
>
> So it sounds like GRO moves the page frags into another skb and
> returns the skb shell to napi for reuse, eliminating an
> alloc_skb/kfree_skb pair? Nice.
>
> The skb that receives all of the page frags: does that eventually get
> kfree_skb'ed, or is there an optimization for that that I'm also not
> aware of?

This fat skb is going to be stored into a socket receive queue,
so that its content can be copied or given to the user application.

TCP then gives back the fat skb to the cpu which allocated the pages,
so that kfree_skb() is very cheap. Fast NIC have page pools.

tcp_eat_recv_skb()

With BIG TCP, we typically store 180 KB of payload per sk_buff