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

[Andy Gospodarek <gospo-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>]

On Tue, Aug 26, 2014 at 05:44:59PM +0200, Jiri Pirko wrote:
> Tue, Aug 26, 2014 at 05:29:10PM CEST, jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org wrote:
> >On 08/26/14 11:22, Jiri Pirko wrote:
> >
> >>I do not think that really matters. Phase one is flows. After that we
> >>can focus on l2/l3. If we would be able to fit in in flows (some drivers
> >>may), then ok. If not, we extend the api with couple of more l2/l3
> >>related ndos. I see no problem there.
> >
> >Well, it matters because we are proceeding to implement L2/3.
> >i.e the simple stuff first. We dont have anything to show yet - but
> >we will hopefully have some useful bit by Plumbers.
> >So maybe best path forward is we talk then and see how we can merge
> >efforts since we cant seem to agree at this point.
> 
> I think we are in agreement. We have two worlds: flows and l2/3. We need
> both for sure. And my patchset adds an initial part of the first one.
> The second one can be added later. I do not see any issues in that.

It is easy to *say* it could be added later, but connecting to software
forwarding in the kernel outside of OVS (which is important to some)
would take significant effort since this set only connects switch
hardware to OVS.

It may be that all software-based forwarding is done via OVS in the
future, but it feels like we are long way from that future for those
that do not want to use an external controller.