[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0Ud805EGQn4v9xbG2PfOVTs8EwQ=cKM8j8e+eUzemkuE4A@mail.gmail.com>
Date: Tue, 27 Feb 2018 17:24:23 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jakub Kicinski <kubakici@...pl>
Cc: Edward Cree <ecree@...arflare.com>,
linux-net-drivers@...arflare.com,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
"John W. Linville" <linville@...driver.com>,
Or Gerlitz <gerlitz.or@...il.com>,
Alexander Duyck <alexander.h.duyck@...el.com>
Subject: Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS
On Tue, Feb 27, 2018 at 3:47 PM, Jakub Kicinski <kubakici@...pl> wrote:
> 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
We did something like this for i40e. Basically we required creating
the queue groups using mqprio to keep them symmetric on Tx and Rx, and
then allowed for TC ingress filters to redirect traffic to those queue
groups.
- Alex
Powered by blists - more mailing lists