netdev - Re: Focusing the XDP project

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: <20170222104328.4b9c6c5d@redhat.com>
Date:   Wed, 22 Feb 2017 10:43:28 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     Saeed Mahameed <saeedm@....mellanox.co.il>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        John Fastabend <john.fastabend@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Brenden Blanco <bblanco@...il.com>, brouer@...hat.com
Subject: Re: Focusing the XDP project

On Tue, 21 Feb 2017 14:54:35 -0800 Tom Herbert <tom@...bertland.com> wrote:
> On Tue, Feb 21, 2017 at 2:29 PM, Saeed Mahameed <saeedm@....mellanox.co.il> wrote:
[...]
> > The only complexity XDP is adding to the drivers is the constrains on
> > RX memory management and memory model, calling the XDP program itself
> > and handling the  action is really a simple thing once you have the
> > correct memory model.

Exactly, that is why I've been looking at introducing a generic
facility for a memory model for drivers.  This should help simply
drivers.  Due to performance needs this need to be a very thin API layer
on top of the page allocator. (That's why I'm working with Mel Gorman
to get more close integration with the page allocator e.g. a bulking
facility).

> > Who knows! maybe someday XDP will define one unified RX API for all
> > drivers and it even will handle normal stack delivery it self :).
> >  
> That's exactly the point and what we need for TXDP. I'm missing why
> doing this is such rocket science other than the fact that all these
> drivers are vastly different and changing the existing API is
> unpleasant. The only functional complexity I see in creating a generic
> batching interface is handling return codes asynchronously. This is
> entirely feasible though...

I'll be happy as long as we get a batching interface, then we can
incrementally do the optimizations later.

In the future, I do hope (like Saeed) this RX API will evolve into
delivering (a bulk of) raw-packet-pages into the netstack, this should
simplify drivers, and we can keep the complexity and SKB allocations
out of the drivers.
To start with, we can play with doing this delivering (a bulk of)
raw-packet-pages into Tom's TXDP engine/system?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer