From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Herbert <tom@herbertland.com>
Subject: Re: [PATCH/RFC net-next 1/2] flow dissector: ND support
Date: Thu, 2 Feb 2017 11:19:45 -0800
Message-ID: <CALx6S35kJsWfk0od11jCZNgrrgLRM4HamfU3gH6eWby9++FpxQ@mail.gmail.com>
References: <1486031855-10551-1-git-send-email-simon.horman@netronome.com>
 <1486031855-10551-2-git-send-email-simon.horman@netronome.com>
 <1486038693.13103.20.camel@edumazet-glaptop3.roam.corp.google.com>
 <20170202155849.GA28482@penelope.horms.nl> <CALx6S37b00GfUBQ5imVfOhg2Rbp_GtDntkwqyj3cN8kzt6gG0w@mail.gmail.com>
 <20170202174803.GF1845@nanopsycho.orion> <CALx6S37QtKgc14DFway-Ajme7JhbAN71M+83w28+4FELdv7Xew@mail.gmail.com>
 <1486061783.21871.28.camel@edumazet-glaptop3.roam.corp.google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cc: Jiri Pirko <jiri@resnulli.us>,
        Simon Horman <simon.horman@netronome.com>,
        David Miller <davem@davemloft.net>,
        Dinan Gunawardena <dinan.gunawardena@netronome.com>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        oss-drivers@netronome.com
To: Eric Dumazet <eric.dumazet@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f193.google.com ([209.85.216.193]:35107 "EHLO
        mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751245AbdBBTTq (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 2 Feb 2017 14:19:46 -0500
Received: by mail-qt0-f193.google.com with SMTP id s58so6038615qtc.2
        for <netdev@vger.kernel.org>; Thu, 02 Feb 2017 11:19:46 -0800 (PST)
In-Reply-To: <1486061783.21871.28.camel@edumazet-glaptop3.roam.corp.google.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, Feb 2, 2017 at 10:56 AM, Eric Dumazet <eric.dumazet@gmail.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.
>
>
>