[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86A26064-B1CE-4828-85AB-1228C2BA97C3@fb.com>
Date: Fri, 29 Mar 2019 21:57:36 +0000
From: Jonathan Lemon <bsd@...com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Magnus Karlsson <magnus.karlsson@...el.com>,
Björn Töpel <bjorn.topel@...il.com>,
Saeed Mahameed <saeedm@...lanox.com>
Subject: Re: [RFC] xdp, multiple rss objects
On 29 Mar 2019, at 14:24, Jakub Kicinski wrote:
> On Fri, 29 Mar 2019 16:14:57 +0000, Jonathan Lemon wrote:
>> Background:
>>
>> With AF_XDP, packets are placed on queues which are serviced directly
>> from
>> an application running in user space, which promises greatly
>> increased
>> performance. However, not all incoming packets should be delivered
>> to the
>> application; there may be management traffic, or packets which should
>> be
>> handled by normal Linux networking applications.
>>
>> Having the AF_XDP application handle the packets and return them to
>> the
>> kernel for processing is not ideal, nor is adding a bpf filter at the
>> kernel
>> level which performs the redirection. It would be nicer if the
>> redirection
>> was done in the NIC itself. Fortunately, there is a facility for
>> this: the
>> RX network flow classification.
>>
>> Unfortunately, the target of the classification is currently a single
>> queue.
>>
>> Traffic arriving at a NIC which is not steered to a specific queue
>> can be
>> distributed across a set of queues through the RX flow hash
>> redirection
>> table (RSS steering). But being able to target a separate RSS object
>> would
>> allow arbitrary distribution of previously classified traffic.
>>
>> Ask:
>>
>> It would be nice to have more than one RSS table, which would be the
>> target
>> of a classifier or default packet stream.
>>
>> Queues would be attached to an RSS object, and flow classifiers could
>> target
>> the RSS object for further distribution. For example, something
>> like:
>>
>> ethtool -X eth0 rss 0 queue 0-13
>> ethtool -X eth0 rss 1 queue 14-55
>> ethtool -N eth0 flow-type udp6 dst-port 4242 rss 1
>>
>> This would set up a default RSS object (rss 0), which sprays traffic
>> to 14
>> queues; this would be equivalent to "ethtool -X eth0 equal 14". At
>> the same
>> time, a second object (rss 1) is set up, distributing traffic across
>> another
>> set of queues.
>>
>> Is there interest in adding this type of feature? Having the ability
>> to
>> express this concept (not necessarily in ethtool) should facilitate
>> having
>> HW vendors add this to their products. I believe that some vendors
>> have
>> hardware which may be capable of this already.
>
> I thought Ed Cree added something like that to ethtool - multiple RSS
> contexts that is: commit 84a1d9c48200 ("net: ethtool: extend RXNFC API
> to support RSS spreading of filter matches").
>
> With Netronome NICs you could also program your RSS with offloaded
> BPF.
>
> Unfortunately only Intel supports AF_XDP right now so that probably
> doesn't help you :(
Thanks - I didn't know about the ethtool changes. This does look fairly
close to what I'm looking for, but I'm not seeing the ability to specify
a distribution of (start, length).
--
Jonathan
Powered by blists - more mailing lists