On Aug 24, 2014, at 8:15 AM, Jamal Hadi Salim <j...@mojatatu.com> wrote:
> On 08/24/14 07:12, Thomas Graf wrote: >> On 08/23/14 at 09:53pm, Jamal Hadi Salim wrote: > >> >> I get what you are saying but I don't see that to be the case here. I >> don't see how this series proposes the OVS case as *the* interface. > > The focus of the patches is on offloading flows (uses the > ovs or shall i say the broadcom OF-DPA API, which is one > vendor's view of the world). > > Yes, people are going to deploy more hardware which knows how to do > a lot of flows (but today that is in the tiny tiny minority) > > I would have liked to see more focus on L2/3 as a first step because > they are more predominantly deployed than anything with flows. And > they are well understood from a functional perspective. > Then that would bring to the front API issues since you have > a large sample space of deployments and we can refactor as needed. With respect to focus on L2/L3, I have a pretty *good* hunch someone could write a kernel module that gleans from the L2/L3 netlink echoes already flying around and translates to sw_flows and in turn into ndo_swdev_flow_* calls. So the existing linux bonds and bridges and vlans and ROUTEs and NEIGHs and LINKs and ADDRs work as normal, unchanged, with iproute2 still originating the netlink msgs from the user. The new kernel module (let’s call it “dagger” after the white spy from spy vs. spy MAD comic) can figure out what forwarding gets offloaded to HW just from the netlink echoes. If someone wrote a dagger module in parallel with the other efforts being discussed here, I think we’d have a pretty good idea what the API needs to look like, at least to cover existing L2/L3 world we're all familiar with. Gleaning netlink msgs isn’t ideal for several reasons (and probably making more than a few in the audience squeamish), but it would be a quick way to get us closer to the answer we’re seeking which is the swdev driver model. -scott _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
