[ovs-dev] [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath
Jiri Pirko
jiri at resnulli.us
Thu Mar 27 07:21:07 UTC 2014
Wed, Mar 26, 2014 at 10:44:31PM CET, jhs at mojatatu.com wrote:
>Jiri,
>
>The flow extensions may be distracting - note there are many
>tables (L3, L2, etc) in such chips not just ACLs. And there's likely no
>OneWay(tm) to add a flow. My view is probably to solve or reach an
>agreement on the ports. Then resolve the different tables control/data
>exposure.
Well, I think there are 2 main models to be considered:
1. OSV-like model, where everything is flows and that is the OneWay(tm)
mode you mentioned :)
2. clasic switch setting-like model where you manually set up vlans,
lag, whatever.
The phase one for me is 1. and that is what I'm trying to resolve with
this patchset.
>From what I understand from the discussion, 2. is likely the model you
have in mind.
>On the switchdev - You are still exposing it; do you expect these
>things to be created from user space? Probably thats one approach, but
>I would suspect the majority would result in the driver itself creating
>these devices after discovering the resources from the control
>interfaces (PCIE etc).
Sorry, I'm not sure I follow you question correctly.
The driver should create and register the switch and switch ports itself.
>
>cheers,
>jamal
>
>
>On 03/26/14 12:31, Jiri Pirko wrote:
>>This is second version of RFC. Here are the main differences from the first one:
>>-There is no special swdev of swport structure. The switch and its ports are
>> now represented only by net_device structures. There are couple of switch-specific
>> ndos added (inserting and removing flows).
>>
>>-Regarding the flows, driver marks skb with "missing flow" flag now. That would
>> give indication to a user (OVS datapath of af_packet userspace application).
>> On the opposite direction, skb can be xmitted by a port.
>>
>>-dummyswitch module has now rtnetlink iface for easy creation of dummy switches
>> and ports.
>>
>>The basic idea is to introduce a generic infractructure to support various
>>switch chips in kernel. Also the idea is to benefit of currently existing
>>Open vSwitch userspace infrastructure.
>>
>>
>>The first two patches are just minor skb flag and packet_type modifications.
>>
>>
>>The third patch does a split of structures which are not specific to OVS
>>into more generic ones that can be reused.
>>
>>
>>The fourth patch introduces the "switchdev" API itself. It should serve as
>>a glue between chip drivers on the one side and the user on the other.
>>That user might be OVS datapath but in future it might be just userspace
>>application interacting via af_packet and Netlink iface.
>>
>>The infrastructure is designed to be similar to for example linux bridge.
>>There is one netdevice representing a switch chip and one netdevice per every
>>port. These are bound together in classic slave-master way. The reason
>>to reuse the netdevices for port representation is that userspace can use
>>standard tools to get information about the ports, statistics, tcpdump, etc.
>>
>>Note that the netdevices are just representations of the ports in the switch.
>>Therefore **no actual data** goes though, only missed flow skbs and, if drivers
>>supports it, when ETH_P_ALL packet_type is hooked on (tcpdump).
>>
>>
>>The fifth patch introduces a support for switchdev vports into OVS datapath.
>>After that, userspace would be able to create a switchdev DP for a switch chip,
>>to add switchdev ports to it and to use it in the same way as it would be
>>OVS SW datapath.
>>
>>
>>The sixth patch adds a dummy switch module. It is just an example of
>>switchdev driver implementation.
>>
>>
>>Jiri Pirko (6):
>> net: make packet_type->ak_packet_priv generic
>> skbuff: add "missed_flow" flag
>> openvswitch: split flow structures into ovs specific and generic ones
>> net: introduce switchdev API
>> openvswitch: Introduce support for switchdev based datapath
>> net: introduce dummy switch
>>
>> drivers/net/Kconfig | 7 +
>> drivers/net/Makefile | 1 +
>> drivers/net/dummyswitch.c | 235 +++++++++++++++++++++++++++++
>> include/linux/filter.h | 1 +
>> include/linux/netdevice.h | 26 +++-
>> include/linux/skbuff.h | 13 ++
>> include/linux/sw_flow.h | 105 +++++++++++++
>> include/linux/switchdev.h | 30 ++++
>> include/uapi/linux/if_link.h | 9 ++
>> include/uapi/linux/openvswitch.h | 4 +
>> net/Kconfig | 10 ++
>> net/core/Makefile | 1 +
>> net/core/dev.c | 4 +-
>> net/core/filter.c | 3 +
>> net/core/switchdev.c | 172 +++++++++++++++++++++
>> net/openvswitch/Makefile | 4 +
>> net/openvswitch/datapath.c | 90 +++++++----
>> net/openvswitch/datapath.h | 12 +-
>> net/openvswitch/dp_notify.c | 3 +-
>> net/openvswitch/flow.c | 14 +-
>> net/openvswitch/flow.h | 123 +++------------
>> net/openvswitch/flow_netlink.c | 24 +--
>> net/openvswitch/flow_netlink.h | 4 +-
>> net/openvswitch/flow_table.c | 100 ++++++------
>> net/openvswitch/flow_table.h | 18 +--
>> net/openvswitch/vport-gre.c | 4 +-
>> net/openvswitch/vport-internal_switchdev.c | 179 ++++++++++++++++++++++
>> net/openvswitch/vport-internal_switchdev.h | 28 ++++
>> net/openvswitch/vport-netdev.c | 4 +-
>> net/openvswitch/vport-switchportdev.c | 205 +++++++++++++++++++++++++
>> net/openvswitch/vport-switchportdev.h | 24 +++
>> net/openvswitch/vport-vxlan.c | 2 +-
>> net/openvswitch/vport.c | 6 +-
>> net/openvswitch/vport.h | 4 +-
>> net/packet/af_packet.c | 22 ++-
>> 35 files changed, 1269 insertions(+), 222 deletions(-)
>> create mode 100644 drivers/net/dummyswitch.c
>> create mode 100644 include/linux/sw_flow.h
>> create mode 100644 include/linux/switchdev.h
>> create mode 100644 net/core/switchdev.c
>> create mode 100644 net/openvswitch/vport-internal_switchdev.c
>> create mode 100644 net/openvswitch/vport-internal_switchdev.h
>> create mode 100644 net/openvswitch/vport-switchportdev.c
>> create mode 100644 net/openvswitch/vport-switchportdev.h
>>
>
More information about the dev
mailing list