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 <m...@redhat.com> wrote: > > > > On Thu, Jan 17, 2019 at 08:08:53PM -0500, Willem de Bruijn wrote: > > > From: Willem de Bruijn <will...@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 <mhl...@google.com> > > > Signed-off-by: Willem de Bruijn <will...@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 <m...@redhat.com>
