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 <[email protected]> > > 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.
