netdev - Re: [PATCH net-next v6 3/9] kbuild: document RPS/XPS network Kconfig options

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1321485122.2709.55.camel@bwh-desktop>
Date:	Wed, 16 Nov 2011 23:12:02 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	David Decotigny <david.decotigny@...gle.com>
CC:	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Ian Campbell <ian.campbell@...rix.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jiri Pirko <jpirko@...hat.com>, Joe Perches <joe@...ches.com>,
	Szymon Janc <szymon@...c.net.pl>,
	Richard Jones <rick.jones2@...com>,
	Ayaz Abdulla <AAbdulla@...dia.com>,
	Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next v6 3/9] kbuild: document RPS/XPS network
 Kconfig options

On Wed, 2011-11-16 at 14:15 -0800, David Decotigny wrote:
> This adds a description of RPS/XPS options and allow them to be
> changed at make menuconfig time.

I'm not sure why you think this is necessary.

[...]
>  config RPS
> -	boolean
> +	boolean "Enable Receive Packet Steering"
>  	depends on SMP && SYSFS && USE_GENERIC_SMP_HELPERS
>  	default y
> +	help
> +	  RPS distributes the load of received packet processing
> +	  across multiple CPUs. If unsure, say Y.
>  
>  config RFS_ACCEL
> -	boolean
> +	boolean "Enable Hardware Acceleration of RFS"
>  	depends on RPS && GENERIC_HARDIRQS
>  	select CPU_RMAP
>  	default y
> +	help
> +	  This is the hardware version of RPS. On multi-queue network
> +	  devices, this configures the hardware to distribute the
> +	  received packets across multiple CPUs. If unsure, say Y.
[...]

There is some confusion/conflation between RPS and RFS in both code and
documentation.

RPS originaly referred to spreading out RX packet processing based on a
flow hash.  Most multiqueue devices do this in hardware, which is
commonly referred to as RSS.  RSS can be enabled independently of any
networking core features.

RFS refers to directing RX packet processsing of specific flows based on
where the corresponding sockets have been used.  RFS acceleration means
that the driver and hardware help with this by changing hardware queue
selection for specific flows.

The RPS Kconfig option controls both RPS and RFS, and various references
to 'RPS' in the code really cover RFS as well.

The RFS_ACCEL Kconfig option enables RFS to support acceleration, and
like most offload features it has no effect without a driver that
specifically supports that.  The option only exists to abstract the
slightly odd dependency on GENERIC_HARDIRQS, and I don't think it should
be manually controllable.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
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