All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Jason Wang <jasowang@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	Mark Hlady <mhlady@google.com>
Subject: Re: [PATCH net-next] virtio-net: per-queue RPS config
Date: Thu, 17 Jan 2019 22:59:32 -0500	[thread overview]
Message-ID: <20190117225900-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAF=yD-KafyXz4CYcZg__tLCULPhgj8NuW9SJ-5rDHgZO3SrgrA@mail.gmail.com>

On Thu, Jan 17, 2019 at 10:37:26PM -0500, Willem de Bruijn wrote:
> On Thu, Jan 17, 2019 at 8:43 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Jan 17, 2019 at 08:08:53PM -0500, Willem de Bruijn wrote:
> > > From: Willem de Bruijn <willemb@google.com>
> > >
> > > On multiqueue network devices, RPS maps are configured independently
> > > for each receive queue through /sys/class/net/$DEV/queues/rx-*.
> > >
> > > On virtio-net currently all packets use the map from rx-0, because the
> > > real rx queue is not known at time of map lookup by get_rps_cpu.
> > >
> > > Call skb_record_rx_queue in the driver rx path to make lookup work.
> > >
> > > Recording the receive queue has ramifications beyond RPS, such as in
> > > sticky load balancing decisions for sockets (skb_tx_hash) and XPS.
> > >
> > > Reported-by: Mark Hlady <mhlady@google.com>
> > > Signed-off-by: Willem de Bruijn <willemb@google.com>
> >
> > And any examples how to see the benefit of this?
> 
> When there are fewer queues than cpus and rps is used to spread load
> across all cpus, it can be preferable to setup disjoint sets, such
> that each cpu handling an rxq interrupt spreads to an exclusive set of
> neighbors instead of having all interrupt handling cores contend on
> all other cores' softnet_data.
> 
> More subtly, even if the policy is to spread uniformly, it can be
> preferable to set the RPS map to all cores except the core that
> handled the interrupt, as it already had to do some work in the
> initial receive path.
> 
> It is also simply expected behavior for network devices to be able to
> configure rxq rps maps individually, so the current silent fallback to
> rx0 is confusing, especially since rx-1/rps_cpus, .. rx-n/rps_cpus
> files do exist and can be configured.

OK I think I got it.

Acked-by: Michael S. Tsirkin <mst@redhat.com>


  reply	other threads:[~2019-01-18  3:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18  1:08 [PATCH net-next] virtio-net: per-queue RPS config Willem de Bruijn
2019-01-18  1:43 ` Michael S. Tsirkin
2019-01-18  3:37   ` Willem de Bruijn
2019-01-18  3:59     ` Michael S. Tsirkin [this message]
2019-01-18  3:49 ` Jason Wang
2019-01-19 18:05 ` David Miller

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=20190117225900-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=mhlady@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.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.