On 08/21/2014 09:19 AM, Jiri Pirko wrote:
Benefit from the possibility to work with flows in switch devices and use the swdev api to offload flow datapath.
we should add a description here on the strategy being used. If I read this correctly this will try to add any flow to the hardware along with the actions and duplicate it in software. There are a couple things I don't like, - this requires OVS to be loaded to work. If all I want is direct access to the hardware flow tables requiring openvswitch.ko shouldn't be needed IMO. For example I may want to use the hardware flow tables with something not openvswitch and we shouldn't preclude that. - Also there is no programmatic way to learn which flows are in hardware and which in software. There is a pr_warn but that doesn't help when interacting with the hardware remotely. I need some mechanism to dump the set of hardware tables and the set of software tables. - Simply duplicating the software flow/action into hardware may not optimally use the hardware tables. If I have a TCAM in hardware for instance. (This is how I read the patch let me know if I missed something) - I need a way to specify put this flow/action in hardware, put this flow/action in software, or put this in both software and hardware. We did this with a bitmask in the fdb L2 stuff and it seems to work reasonable well so maybe something like that would help. For example if I don't have this what happens if I have an entry to decrement TTL in both hardware and software. If the flow hits both the hardware path and software path the TTL gets decremented. Here userspace needs to indicate where to do the decrement to avoid the duplication. I think if we can pull this out OVS and add the hw/sw bitmask (or maybe a better implementation of that idea) then this should work for the stuff I'm looking at. I want to try and get it working on the i40e driver as a fdir replacement but it might take me a bit to get to it. Thanks, John -- John Fastabend Intel Corporation _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev