netdev - Re: [oss-drivers] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

On Wed, Feb 08, 2017 at 09:09:17PM +0100, Jiri Pirko wrote:
> Wed, Feb 08, 2017 at 07:54:15PM CET, davem@...emloft.net wrote:
> >From: Tom Herbert <tom@...bertland.com>
> >Date: Wed, 8 Feb 2017 10:33:46 -0800
> >
> >> On Wed, Feb 8, 2017 at 1:28 AM, Simon Horman <simon.horman@...ronome.com> wrote:
> >>> 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.

I think this serious discussion is all about the long term and am
completely in favour of that. But in the short term it would help me to
know if the line in the sand excludes proposing enhancements to protocols
already supported by the flow dissector; in particular MPLS and IP fields I
listed earlier in this thread.

Perhaps the answer is that it depends. But if the line in
the sand has been fortified I'd rather avoid trying to cross it.

> 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.

Making the flow dissector more modular makes some sense to me.
It seems that it should be a way to address sharing common code while
allowing more flexibility for users, such as flower, that need it.

Elsewhere in this thread there has been some discussion of BPF. While I
also think that makes sense I think that for in-kernel users it makes
more sense to allow leveraging of the flow dissector using C code.

Such an approach well allow some of the complexity that was recently added
to the flow dissector to move into more peripheral code. Which may or may
not be a win as I think was discussed earlier in this thread.