netdev - Re: [RFC PATCH net-next-2.6 0/2] Automatic XPS mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 19 Jul 2011 10:07:53 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	netdev <netdev@...r.kernel.org>,
	sf-linux-drivers <linux-net-drivers@...arflare.com>
Subject: Re: [RFC PATCH net-next-2.6 0/2] Automatic XPS mapping

Hi Ben,

I've finally gotten around to looking at how XPS interacts with the HW
priority queues...

On Fri, Feb 18, 2011 at 8:13 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> In the same way that we maintain a mapping CPUs to RX queues for RFS
> acceleration based on current IRQ affinity and the CPU topology, we can
> maintain a mapping of CPUs to TX queues for queue selection in XPS.  (In
> fact this may be the same mapping.)
>

Any more progress on this?  It seem like a good way to provide default
configuration for XPS that is usable.

> Questions:
> - Does this make a real difference to performance?

XPS seems to when configured correctly :-)

>  (I've only barely tested this.)
> - Should there be a way to disable it?
> - Should the automatic mapping be made visible?

Yes, would be nice for this to be readable in the tx-<n> directory for
the queue.  Same thing for rmap in RFS acceleration.

>  (This applies RFS acceleration too.)

> - Should different mappings be allowed for different traffic classes,
>  in case they have separate sets of TX interrupts with different
>  affinity?
>  (This applies to manual XPS configuration too.)
>
Yes.  Looking at XPS and the HW traffic class support, I realized that
they don't seem to play together at all.  If XPS is enabled, we don't
do the skb_tx_hash which is where the priority is taken into account.
It's probably worse than that, AFAICT XPS could be configured so that
packets are inadvertently sent on arbitrary priority queues.

I think the correct approach is to first choose a set of queues by
priority, and then among those queues perform XPS.  Probably requires
some new configuration to make this hierarchy visible.

Tom

> Ben Hutchings (2):
>  net: XPS: Allow driver to provide a default mapping of CPUs to TX
>    queues
>  sfc: Add CPU queue mapping for XPS
>
>  drivers/net/sfc/efx.c     |   59 +++++++++++++++++++++++++++++++-------------
>  include/linux/netdevice.h |   10 +++++--
>  net/Kconfig               |   17 +++++++++----
>  net/core/dev.c            |   41 +++++++++++++++++-------------
>  4 files changed, 83 insertions(+), 44 deletions(-)
>
> --
> 1.7.3.4
>
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html