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

On Sep 4, 2014, at 2:04 AM, Simon Horman [off-list ref] 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.

Or we might have hardware that is able to offload a tunnel vport.

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