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. >>> 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
