On Fri, Sep 05, 2014 at 12:02:03AM -0700, Scott Feldman wrote: > > On Sep 4, 2014, at 9:08 PM, Simon Horman <simon.hor...@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.hor...@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
