All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Edward Cree <ecree.xilinx@gmail.com>, <davem@davemloft.net>,
	<netdev@vger.kernel.org>, <edumazet@google.com>,
	<pabeni@redhat.com>, <willemb@google.com>, <fw@strlen.de>
Subject: Re: [PATCH net-next 2/3] net: skbuff: cache one skb_ext for use by GRO
Date: Wed, 15 Feb 2023 09:52:00 -0800	[thread overview]
Message-ID: <20230215095200.0d2e3b7e@kernel.org> (raw)
In-Reply-To: <f2a30934-a0fe-ae1e-0897-2bb7dc572270@intel.com>

On Wed, 15 Feb 2023 17:17:53 +0100 Alexander Lobakin wrote:
> > On 15/02/2023 03:43, Jakub Kicinski wrote:  
> >> On the driver -> GRO path we can avoid thrashing the kmemcache
> >> by holding onto one skb_ext.  
> > 
> > Hmm, will one be enough if we're doing GRO_NORMAL batching?
> > As for e.g. UDP traffic up to 8 skbs (by default) can have
> >  overlapping lifetimes.
> >   
> I thought of an array of %NAPI_SKB_CACHE_SIZE to be honest. From what
> I've ever tested, no cache (for any netstack-related object) is enough
> if it can't serve one full NAPI poll :D

I was hoping to leave sizing of the cache until we have some data from
a production network (or at least representative packet traces).

NAPI_SKB_CACHE_SIZE kinda assumes we're not doing much GRO, right?
And the current patch feeds the cache exclusively from GRO...

> + agree with Paolo re napi_reuse_skb(), it's used only in the NAPI
> context and recycles a lot o'stuff already, we can speed it up safely here.

LMK what's your opinion on touching the other potential spots, too.
(in Paolo's subthread).

  reply	other threads:[~2023-02-15 17:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-15  3:43 [PATCH net-next 0/3] net: skbuff: cache one skb_ext for use by GRO Jakub Kicinski
2023-02-15  3:43 ` [PATCH net-next 1/3] net: skb: carve the allocation out of skb_ext_add() Jakub Kicinski
2023-02-15  3:43 ` [PATCH net-next 2/3] net: skbuff: cache one skb_ext for use by GRO Jakub Kicinski
2023-02-15  8:41   ` Paolo Abeni
2023-02-15 17:45     ` Jakub Kicinski
2023-02-15 18:08       ` Alexander Lobakin
2023-02-15 19:08         ` Paolo Abeni
2023-02-15 15:37   ` Edward Cree
2023-02-15 16:17     ` Alexander Lobakin
2023-02-15 17:52       ` Jakub Kicinski [this message]
2023-02-15 18:01         ` Alexander Lobakin
2023-02-15 18:20           ` Jakub Kicinski
2023-02-16 12:04             ` Alexander Lobakin
2023-02-15  3:43 ` [PATCH net-next 3/3] net: create and use NAPI version of tc_skb_ext_alloc() Jakub Kicinski
2023-02-15 16:50   ` Jamal Hadi Salim
2023-02-15 17:03     ` Jiri Pirko
2023-02-15 18:36       ` Jamal Hadi Salim
2023-02-15 17:35     ` Jakub Kicinski
2023-02-15 18:38       ` Jamal Hadi Salim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230215095200.0d2e3b7e@kernel.org \
    --to=kuba@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.