Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload

[John Fastabend <john.fastabend-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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