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-next>] [day] [month] [year] [list]

Message-ID: <CAGXJAmweUSP8-eG--nOrcst4tv-qq9RKuE0arme4FJzXW67x3Q@mail.gmail.com>
Date: Wed, 29 Jan 2025 08:43:28 -0800
From: John Ousterhout <ouster@...stanford.edu>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Netdev <netdev@...r.kernel.org>, Eric Dumazet <edumazet@...gle.com>, 
	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 2:24 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 1/29/25 2:23 AM, John Ousterhout wrote:
> > In my measurements, skb freeing is by far the largest cost in RPC
> > reaping. I'm not currently in a good position to remeasure this, but
> > my recollection is that it takes a few hundred ns to free an skb. A
> > large RPC (1 MByte is Homa's current limit) will have at least 100
> > skbs (with jumbo frames) and more than 600 skbs with 1500B frames:
> > that's 20-100 usec.
>
> I guess a couple of things could improve skb free performances:
>
> - packet aggregation for home protocol - either at the GRO stage[*] or
> skb coalescing while enqueuing in `msgin.packets`, see
> skb_try_coalesce()/tcp_try_coalesce().
>
> - deferred skb freeing, see skb_attempt_defer_free() in net/core/skbuff.c.
>
> [*] I see a bunch of parameters for it but no actual code, I guess it's
> planned for later?

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.

-John-