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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev