On Tue, 27 Feb 2018 17:59:12 +0000, Edward Cree wrote: > 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.
Please, let's stop extending ethtool_rx_flow APIs. I bit my tongue when Intel was adding their "redirection to VF" based on ethtool ntuples and look now they're adding the same functionality with flower :| And wonder how to handle two interfaces doing the same thing. On the use case itself, I wonder how much sense that makes. Can your hardware not tag the packet as well so you could then mux it to something like macvlan offload? CC: Alex, Or
