Thread (39 messages) 39 messages, 5 authors, 2017-03-13

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

From: Jiri Pirko <jiri@resnulli.us>
Date: 2017-02-08 20:09:20

Wed, Feb 08, 2017 at 07:54:15PM CET, davem@davemloft.net wrote:
From: Tom Herbert <redacted>
Date: Wed, 8 Feb 2017 10:33:46 -0800
quoted
On Wed, Feb 8, 2017 at 1:28 AM, Simon Horman [off-list ref] wrote:
quoted
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.
If it wasn't ND it would be something else... with all the activity
happening in networking features and HW this is a timely discussion.
Flow dissector presents a good example of a function that might become
a dumping ground for an endless stream of features if we don't figure
out how exercise some restraint.
I agree on most points.

But, I would say that in this specific case, since we have ARP support in
there already it behooves us to support the ipv6 side in the form of ND
too.

Then we can put a line in the sand and say that future feature additions
in this area require serious discussion.
Yeah, well, and if there is a functinality that is unacceptable for any
reason to put into flow_dissector, we have to do a flow_dissector2?

Note that I originally had separate dissection in cls_flower, you
suggested to use the existing flow_dissector. And I still believe it was
the right way to do it.

I think that better is to make existing flow dissector more modular.
I'll look into this.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help