netdev - Re: [RFC] xdp, multiple rss objects

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]

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