netdev - Re: [PATCH net-next,RFC 00/13] New fast forwarding path

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] [day] [month] [year] [list]

Message-ID: <CAKTPYJTBQSwNPx=pV1mQpRc6OriEru-1N7-XegUOOiU-xDMQ8A@mail.gmail.com>
Date:   Tue, 19 Jun 2018 18:56:45 -0600
From:   Andrew Collins <bsderandrew@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     f.fainelli@...il.com, pablo@...filter.org,
        netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
        Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [PATCH net-next,RFC 00/13] New fast forwarding path

On Thu, Jun 14, 2018 at 5:55 PM, David Miller <davem@...emloft.net> wrote:
> And guess what?  Then millions of possibilities would have been
> openned up, rather than just this one special case.
>
> So, I ask, please see the larger picture.

+cc netdev/etc

This is perhaps unrelated to the topic at hand, but as someone who's shipped
a bunch of devices over the years using the linux kernel forwarding path and
needs performance but wants to avoid moving to out of tree userspace offload
for all the reasons that you and many others have stated, is the long
term vision that the existing kernel forwarding path will transparently take
advantage of eBPF (ala bpfilter), or that users will write custom/individualized
eBPF forwarding paths for their usecases as necessary?

I (and I suspect many others) will start on the latter anyways, I'm just curious
whether it's desired/expected that such custom fastpath users will eventually
be rolled back into/replaced by a transparent upstream in-kernel equivalent.