Hi Jiri,
sorry for coming a little late to the party.
I'm very happy to see work in this area.
On Thu, Aug 21, 2014 at 06:19:03PM +0200, Jiri Pirko wrote:
> Benefit from the possibility to work with flows in switch devices and
> use the swdev api to offload flow datapath.
>
> Signed-off-by: Jiri Pirko <j...@resnulli.us>
> ---
> include/linux/sw_flow.h | 14 +++
> net/openvswitch/Makefile | 3 +-
> net/openvswitch/datapath.c | 33 ++++++
> net/openvswitch/datapath.h | 3 +
> net/openvswitch/flow_table.c | 1 +
> net/openvswitch/hw_offload.c | 235
> +++++++++++++++++++++++++++++++++++++++++
> net/openvswitch/hw_offload.h | 22 ++++
> net/openvswitch/vport-netdev.c | 3 +
> net/openvswitch/vport.h | 2 +
> 9 files changed, 315 insertions(+), 1 deletion(-)
> create mode 100644 net/openvswitch/hw_offload.c
> create mode 100644 net/openvswitch/hw_offload.h
>
> diff --git a/include/linux/sw_flow.h b/include/linux/sw_flow.h
> index b622fde..079d065 100644
> --- a/include/linux/sw_flow.h
> +++ b/include/linux/sw_flow.h
> @@ -80,7 +80,21 @@ struct sw_flow_mask {
> struct sw_flow_key key;
> };
>
> +enum sw_flow_action_type {
> + SW_FLOW_ACTION_TYPE_OUTPUT,
> + SW_FLOW_ACTION_TYPE_VLAN_PUSH,
> + SW_FLOW_ACTION_TYPE_VLAN_POP,
> +};
> +
> struct sw_flow_action {
> + enum sw_flow_action_type type;
> + union {
> + struct net_device *output_dev;
> + struct {
> + __be16 vlan_proto;
> + u16 vlan_tci;
> + } vlan;
> + };
> };
I think it would be nice to use an more end-to-end approach for actions.
The way things that are set up in this patch there are thee actions
that are allowed. This is in contrast to the Open vSwtich datapath which
supports a much later superset of actions. And occasionally aquires
support for new ones (e.g. my recent work on MPLS push, pop and set
actions).
I think it would be nicer if arbitrary actions could be passed
down to the swdev API and for the underlying driver to return
an appropriate error code if an action is unsupported. Rather than having
datapath or swdev API code filtering actions.
That is allow end-to-end communication between the datapath and the driver
rather than having a filter in the middle.
[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 datapaths.
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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
