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

On 08/23/14 at 10:09am, John Fastabend wrote:

Right. I think this is basically what Jiri and I discussed when he
originally posted the series. For my use cases this is one of the
more interesting pieces. If no one else is looking at it I can try
it on some of the already existing open source drivers that have some
very simple support for ingress flow tables read flow director.

Awesome. I'm definitely very interested in helping out on this part
as well.

Thanks. This is exactly what I was trying to hint at and why the
optimization can not be done in the driver. The driver shouldn't
have to know about the cost models of SW vs HW rules or how to
break up rules into sets of complimentary hw/sw rules.

That's an excellent summary of what I wanted to say.

the other thing I've been thinking about is how to handle hardware
with multiple flow tables. We could let the driver handle this
but if I ever want to employ a new optimization strategy then I
need to rewrite the driver. To me this looks a lot like policy
which should not be driven by the kernel. We can probably ignore
this case for the moment until we get some of the other things
addressed.

Agreed, this sounds like something to handle a bit later.
It is potentially very interesting as it would allow to offload at
least partial pipelines but it obviously adds a new dimension to
the API. I strongly feel that the API as proposed could be extended
in this direction though. It will require a notion of tables for
swdev_flow_insert() and we'll likely need an API to set default
table policies although that is likely even needed for single table
support. We might also have to introduce a concept of bundles at
some point to provide atomic updates across multiple tables for
consistency.

IMO I think extending the API is the easiest route but the best
way to resolve this is to try and write the code. I'll take a
stab at it next week.

I'm absolutely interested in writing code for this as well. If we
can find consensus on merging at least the core API bits in some
form then that would allow for more people to get involved. Maybe
we can skip the OVS bits in the first merge and continue that work
in a separate git tree. I'm also definitely very interested in hearing
Pravin's and Jesse's thoughts on the overall API ;-)

John's flow director API replacement idea can definitely serve as an
excellent first in-tree consumer as it looks even simpler.

by the way Jiri I think the patches are a great start.

+1