Wed, Feb 08, 2017 at 08:10:06PM CET, t...@herbertland.com wrote: >On Wed, Feb 8, 2017 at 10:54 AM, David Miller <da...@davemloft.net> wrote: >> From: Tom Herbert <t...@herbertland.com> >> Date: Wed, 8 Feb 2017 10:33:46 -0800 >> >>> On Wed, Feb 8, 2017 at 1:28 AM, Simon Horman <simon.hor...@netronome.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. >> >> Ok Tom? > >Right, ND is okay on the basis that we already have ARP (although I >still may grumble from time to time that ARP, ND, and ICMP are being >identified as flows ;-) ). > >I think there are two projects in the are that someone, maybe an >aspiring kernel network developer, might want to look into if they >have the time: > >- Inevitably someone will want to support VXLAN or other UDP >encapsulations in flow dissector. The only correct way to do this is >going to be to do a lookup on UDP socket and have a flow_dissector >function related to the socket. This is the model for dealing with UDP >encapsulations in GRO that could be extended for flow dissection. We >cannot hard code port numbers in flow_dissector. The interesting part >here will be making a robust interface to avoid the pitfalls we've >seen in some of the protocols in flow_dissector. > >- Allow calling a BPF function to do custom flow dissection. IIRC >there someone (Daniel?) had already implement flow_dissector in BPF >with pretty good results.
How will this help us for cls_flower case? Are you suggesting to put this whole BPF occult to the next level and use it kernel-to-kernel? :D
