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

From: Simon Horman <simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
To: Scott Feldman
	<sfeldma-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
Cc: Sergey Ryazanov
	<ryazanov.s.a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	John Fastabend
	<john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Neil.Jerram-QnUH15yq9NYqDJ6do+/SaQ@public.gmane.org,
	Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Andy Gospodarek <andy-QlMahl40kYEqcZcGjlUOXw@public.gmane.org>,
	dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
	Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>,
	Florian Fainelli
	<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	ronye-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org,
	Jeff Kirsher
	<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	ogerlitz <ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>,
	Lennert Buytenhek
	<buytenh-OLH4Qvv75CYX/NnBR394Jw@public.gmane.org>,
	Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>,
	Roopa Prabhu
	<roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>,
	Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>,
	Aviad Raveh <aviadr-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org,
	Vlad Yasevich <vyasevic-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
	netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Stephen Hemminger
	<stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>,
	dborkman <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	David Miller <dav
Subject: Re: [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload
Date: Mon, 8 Sep 2014 09:02:30 +0900	[thread overview]
Message-ID: <20140908000228.GA19405@vergenet.net> (raw)
In-Reply-To: <E3C7797F-081E-484F-918E-937C705B43D6-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>

On Fri, Sep 05, 2014 at 12:02:03AM -0700, Scott Feldman wrote:
> 
> On Sep 4, 2014, at 9:08 PM, Simon Horman <simon.horman@netronome.com> wrote:
> 
> > On Thu, Sep 04, 2014 at 09:30:45AM -0700, Scott Feldman wrote:
> >> 
> >> On Sep 4, 2014, at 2:04 AM, Simon Horman <simon.horman@netronome.com> wrote:
> >> 
> >>> 
> >>> 
> >>> [snip]
> >>> 
> >>> In relation to ports and datapaths it seems to me that the API that
> >>> has been developed accommodates a model where a port may belong to a
> >>> switch device; that this topology is fixed before any API calls are made
> >>> and that all all ports belonging to the same switch belong to the same
> >>> datapath.
> >>> 
> >>> This makes sense in the case of hardware that looks a lot like a switch.
> >>> But I think that other scenarios are possible. For example hardware that
> >>> is able to handle the same abstractions handled by the datapath: datapaths
> >>> may be created or destroyed; vports may be added and removed from datapaths.
> >>> 
> >>> So one might have a piece of hardware that is configured with more than one
> >>> datapath configured and its different ports belong to it might be
> >>> associated with different data paths.
> >> 
> >> I’ve tested multiple datapaths on one switch hardware with the current patch set and it works fine, without the need to push down any datapath id in the API.  It works because a switch port can’t belong to more than one datapath.  Datapaths can be created/destroyed and ports added/removed from datapaths dynamically and the right sw_flows are added/removed to program HW.
> > 
> > And the flows added to a switch always match the in port? Thus
> > so a given flow is only ever for one in-port and thus one datapath?
> 
> Correct, for the particular switch implementation we’re working with.  If
> another implementation can’t match on in_port then it seems datapath_id
> may be needed to partition flows.

Thanks, I understand and agree.

> >>> Or we might have hardware that is able to offload a tunnel vport.
> > 
> > I think tunnel vports is still an unsolved part of the larger puzzle.
> 
> Agreed, TBD work to offload tunnel vports.  Current implementation only looking at VLAN vports so far.
> 
> > 
> >>> In short I am thinking in terms of API callbacks to manipulate datapaths
> >>> and vports. Although I have not thought about it in detail I believe
> >>> that the current model you have implemented using such a scheme because
> >>> the scheme I am suggesting maps to that of the datapath and you have
> >>> implemented your model there.
> 
> 
> -scott
> 
> 
> 
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev