[ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
john.fastabend at gmail.com
Fri Aug 22 19:39:00 UTC 2014
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
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.
John Fastabend Intel Corporation
More information about the dev