Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS

[David Miller <davem@davemloft.net>]

From: Edward Cree <ecree@solarflare.com>
Date: Tue, 27 Feb 2018 17:59:12 +0000

> This series introduces the ability to mark an ethtool steering filter to use
>  RSS spreading, and the ability to create and configure multiple RSS contexts
>  with different indirection tables, hash keys, and hash fields.
> An implementation for the sfc driver (for 7000-series and later SFC NICs) is
>  included in patch 2/2.
> 
> The anticipated use case of this feature is for steering traffic destined for
>  a container (or virtual machine) to the subset of CPUs on which processes in
>  the container (or the VM's vCPUs) are bound, while retaining the scalability
>  of RSS spreading from the viewpoint inside the container.
> The use of both a base queue number (ring_cookie) and indirection table is
>  intended to allow re-use of a single RSS context to target multiple sets of
>  CPUs.  For instance, if an 8-core system is hosting three containers on CPUs
>  [1,2], [3,4] and [6,7], then a single RSS context with an equal-weight [0,1]
>  indirection table could be used to target all three containers by setting
>  ring_cookie to 1, 3 and 6 on the respective filters.

We really should have the ethtool interfaces under deep freeze until we
convert it to netlink or similar.

Second, this is a real hackish way to extend ethtool with new
semantics.  A structure changes layout based upon a flag bit setting
in an earlier member?  Yikes...

Lastly, there has been feedback asking how practical and useful this
facility actually is, and you must address that.