public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: kuniyu@google.com, ncardwell@google.com, netdev@vger.kernel.org,
	davem@davemloft.net, pabeni@redhat.com, andrew+netdev@lunn.ch,
	horms@kernel.org
Subject: Re: [PATCH net-next] tcp: try to defer / return acked skbs to originating CPU
Date: Mon, 16 Feb 2026 10:11:08 -0800	[thread overview]
Message-ID: <20260216101108.6b2319b2@kernel.org> (raw)
In-Reply-To: <CANn89iL+kzhRqwBr5wAcEBMdC_wbLFanHJ6VxS1r5ppGKUhftA@mail.gmail.com>

On Mon, 16 Feb 2026 18:58:08 +0100 Eric Dumazet wrote:
> > > I think I totally missed your email :/
> > >
> > > What about not attempting defer for zero copy skbs ?
> > >
> > > It turns out existing patch e20dfbad8aab ("net: fix napi_consume_skb()
> > > with alien skbs") is already a problem for zcopy.  
> >
> > We definitely need either this or the timer patch I attached, for UDP.
> >
> > I put the TCP write side on a back burner because slab sheaves got
> > merged, I think skb defer free will still make a difference but IDK
> > how much. Maybe juice will no longer be worth the squeeze?  
> 
> It depends how many frags are attached to each skb.
> 
> page frags are not yet handled by SLUB sheaves :)

Ack, my recollection is that more of the cycles are spent in slab than
pcp handling, tho. I could be misremembering. But my thinking was that
if we both:
 - lose zc sends due to the unbounded completion time
 - lose the slab benefit due to sheaves
we are only left with fairly narrow case of page handling of small skbs.
My gut feeling was that however unclean the timer fix would be best
since it gives us zc back. But I don't have a way to experiment with
sheaves yet to get data. All of this is pure speculation.

Regardless the patch you shared earlier is probably best as a fix for
zero-copy UDP for now.

  reply	other threads:[~2026-02-16 18:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17 16:42 [PATCH net-next] tcp: try to defer / return acked skbs to originating CPU Jakub Kicinski
2026-01-17 17:10 ` Jakub Kicinski
2026-01-17 18:16 ` Eric Dumazet
2026-01-17 23:03   ` Jakub Kicinski
2026-01-18 12:15     ` Eric Dumazet
2026-01-19 17:04       ` Jakub Kicinski
2026-01-29 23:04         ` Jakub Kicinski
2026-01-29 23:10           ` Jakub Kicinski
2026-02-16 16:06           ` Eric Dumazet
2026-02-16 17:49             ` Jakub Kicinski
2026-02-16 17:58               ` Eric Dumazet
2026-02-16 18:11                 ` Jakub Kicinski [this message]
2026-02-16 18:16                   ` Eric Dumazet
2026-02-17 21:50                     ` Jakub Kicinski
2026-02-17 21:56                       ` Eric Dumazet

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=20260216101108.6b2319b2@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuniyu@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox