netdev - Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

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:   Thu, 2 Feb 2017 11:19:45 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Simon Horman <simon.horman@...ronome.com>,
        David Miller <davem@...emloft.net>,
        Dinan Gunawardena <dinan.gunawardena@...ronome.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

On Thu, Feb 2, 2017 at 10:56 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Thu, 2017-02-02 at 10:36 -0800, Tom Herbert wrote:
>
>> It's going to be a problem with a whole host of application level
>> protocols especially those run over UDP. QUIC is a great example. The
>> actual protocol will probably only ever run in userspace, but it is
>> inevitable that we want to provide targeted kernel support for packet
>> steering. filtering, GRO/GSO if they have such things. Instead of
>> implementing this in a specialized QUIC module, it will most likely
>> make everyone happier to add these in a generic protocol-agnostic way.
>> From QUIC POV they want to minimize any dependencies on the kernel and
>> be able to iterate quickly, from a kernel POV we really don't want to
>> have to explicitly support an endless stream of protocols like this.
>
> Small note here : Google does not intend to add QUIC knowledge anywhere
> in the kernel.
>
Someone else might want to do that. It's also conceivable that we
could see NIC vendors trying to offload parts of QUIC and they would
want support in the kernel for that.

Tom

> SO_ATTACH_REUSEPORT_EBPF can be used if someone wants to take a deep
> look at QUIC header (and presumably hash the connection-id) to select
> one socket among the group.
>
> Thanks.
>
>
>