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? > > 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. > > 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
