Date:   Wed, 8 Feb 2017 17:43:32 +0100
From:   Simon Horman <simon.horman@...ronome.com>
To:     David Miller <davem@...emloft.net>
Cc:     tom@...bertland.com, jiri@...nulli.us, eric.dumazet@...il.com,
        dinan.gunawardena@...ronome.com, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

Responding to myself as my previous post doesn't seem to have hit netdev
for some reason.

On Wed, Feb 08, 2017 at 10:28:24AM +0100, Simon Horman wrote:
> On Tue, Feb 07, 2017 at 12:38:31PM -0500, David Miller wrote:
> > From: Tom Herbert <tom@...bertland.com>
> > Date: Tue, 7 Feb 2017 09:36:20 -0800
> > 
> > > Okay, but can you give us an idea of how many more of these protocols
> > > are going to be added to flow_dissector. TBH I'm not very enthused
> > > about making more flow_dissector more complex for the benefit of OVS.
> > 
> > Especially since the kernel datapath of OVS has been marked
> > experimental.
> 
> Hi Dave, Hi Tom,
> 
> Firstly I'd like to apologise for posing what has turned out to be a
> somewhat divisive patch.
> 
> After looking through things a little more I think the simple answer to
> Tom's question is only ND. But there are also some fields of already
> supported protocols which are covered in the OvS flow key but not the flow
> dissector.
> 
> My analysis of OvS flow key fields for non-tunnel packet data - which I
> think is the extent of what is relevant to the flow dissector - yields the
> following list:
> 
>   New protocols:
>   * ND (this patch)
> 
>   Fields of already supported protocols:
>   * MPLS.lse (currently the label of the LSE is handled by the dissector
>               so this could also be described as MPLS.lse.{tc,s,ttl})
>   * IPV4.tos
>   * IPV4.ttl
>   * IPV6.hlimit
>   * IPV6.tclass
> 
>   I do expect that some of the above will not be appropriate for existing
>   users of the flow dissector; e.g. IPV4.ttl does not seem much use when
>   calculating the hash of a flow for steering purposes. And I do not yet
>   have a good idea of how to approach that beyond using different dissector
>   keys.
> 
>   Further support for to already supported fields.
>   * IPV[46].frag (supported by flow dissector : 1st frag flag;
>                   not supported by flow dissector: subsequent frag flag)
> 
> From my point of view some parts of what is above is more important than
> others. In particular ND is probably not particularly important at least at
> this time. I would be happy to withdraw this patchset if the complexity is
> not deemed worth it at this time.
> 
> 
> I'd like to take a moment to give a little background and restate that my
> goal is not to create a burden for existing users of the flow dissector
> - or any other part of the stack.
> 
> Netronome has worked on various approaches to an upstream offload of OvS.
> One was hooks added to the OvS kernel datapath; an idea which was rejected
> at least twice but none the less I'd be happy to revisit if there is
> interest in it.
> 
> The result of trying various approaches is that it seems the most
> acceptable is to use TC for programming flows into hardware which is where
> my work on TC flower and the flow dissector is coming from.  A key part of
> the reasoning being, as I understand it, that the flows could also be
> programmed into hardware for non-OvS use-cases; technology that could be
> useful e.g. in a post-OvS world.
> 
> I think the above paragraph gets back to Tom's original question regarding
> making things more complex just for OvS (use-cases). Possibly ND is an edge
> case even for OvS and on reflection my timing for posting it seems to have
> been less than ideal.

Powered by blists - more mailing lists