netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, tom@herbertland.com,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	dsahern@kernel.org, makita.toshiaki@lab.ntt.co.jp,
	kernel-team@cloudflare.com, phil@nwl.cc
Subject: Re: [PATCH net-next V6 2/2] veth: apply qdisc backpressure on full ptr_ring to reduce TX drops
Date: Thu, 24 Apr 2025 08:53:58 -0700	[thread overview]
Message-ID: <20250424085358.75d817ae@kernel.org> (raw)
In-Reply-To: <c6abaa9f-cd3e-4259-bed6-5e795ff58ecd@kernel.org>

On Thu, 24 Apr 2025 17:24:51 +0200 Jesper Dangaard Brouer wrote:
> > Looks like I wrote a reply to v5 but didn't hit send. But I may have
> > set v5 to Changes Requested because of it :S Here is my comment:
> > 
> >   I think this is missing a memory barrier. When drivers do this dance
> >   there's usually a barrier between stop and recheck, to make sure the
> >   stop is visible before we check. And vice versa veth_xdp_rcv() needs
> >   to make sure other side sees the "empty" indication before it checks
> >   if the queue is stopped.  
> 
> The call netif_tx_stop_queue(txq); already contains a memory barrier
> smp_mb__before_atomic() plus an atomic set_bit operation.  That should
> be sufficient.

That barrier is _before_ stopping the queue. I'm saying we need a
barrier between stop and emptiness re-check. Note that:
 - smp_mb__after_atomic() is enough, and it 'compiles' to nothing
   on x86
 - all of this is the unlikely path :) You restart the qdisc
   when the ptr ring is completely full so the stopping in absolute
   worst case will happen once or twice per full ptr_ring ?

> And the other side veth_poll(), have a smp_store_mb() before reading
> ptr_ring.
> 
> --Jesper
> 
> p.s.
> I actually had an alternative implementation of this, that only calls
> stop when it is needed.  See below, it kind of looks prettier, but it
> adds an extra memory barrier in the likely path. (And I'm not sure if 
> read memory barrier is strong enough).

Not sure that works either :S

  reply	other threads:[~2025-04-24 15:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24 12:56 [PATCH net-next V6 0/2] veth: qdisc backpressure and qdisc check refactor Jesper Dangaard Brouer
2025-04-24 12:56 ` [PATCH net-next V6 1/2] net: sched: generalize check for no-queue qdisc on TX queue Jesper Dangaard Brouer
2025-04-24 12:56 ` [PATCH net-next V6 2/2] veth: apply qdisc backpressure on full ptr_ring to reduce TX drops Jesper Dangaard Brouer
2025-04-24 14:23   ` Jakub Kicinski
2025-04-24 15:24     ` Jesper Dangaard Brouer
2025-04-24 15:53       ` Jakub Kicinski [this message]
2025-04-25 13:55         ` Jesper Dangaard Brouer

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=20250424085358.75d817ae@kernel.org \
    --to=kuba@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=eric.dumazet@gmail.com \
    --cc=hawk@kernel.org \
    --cc=kernel-team@cloudflare.com \
    --cc=makita.toshiaki@lab.ntt.co.jp \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=phil@nwl.cc \
    --cc=toke@toke.dk \
    --cc=tom@herbertland.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;
as well as URLs for NNTP newsgroup(s).