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]

Message-ID: <20190329142444.6d968cef@cakuba.netronome.com>
Date:   Fri, 29 Mar 2019 14:24:44 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jonathan Lemon <bsd@...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 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 :(