From: Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public•gmane.org>
To: Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public•gmane.org>
Cc: john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public•gmane.org,
edumazet-hpIqsD4AKlfQT0dZR+AlfA@public•gmane.org,
andy-QlMahl40kYEqcZcGjlUOXw@public•gmane.org,
dev-yBygre7rU0TnMu66kgdUjQ@public•gmane.org,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public•gmane.org,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public•gmane.org,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public•gmane.org,
ben-/+tVBieCtBitmTQ+vhA3Yw@public•gmane.org,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public•gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public•gmane.org,
vyasevic-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org,
nhorman-2XuSBdqkA4R54TAoqtyWWQ@public•gmane.org,
sfeldma-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public•gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public•gmane.org,
dborkman-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public•gmane.org
Subject: Re: [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath
Date: Thu, 27 Mar 2014 08:21:07 +0100 [thread overview]
Message-ID: <20140327072107.GC2845@minipsycho.orion> (raw)
In-Reply-To: <53334A3F.6020105-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
Wed, Mar 26, 2014 at 10:44:31PM CET, jhs-jkUAjuhPggJWk0Htik3J/w@public•gmane.org 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
>>
>
next prev parent reply other threads:[~2014-03-27 7:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 16:31 [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath Jiri Pirko
2014-03-26 16:31 ` [patch net-next RFC v2 1/6] net: make packet_type->ak_packet_priv generic Jiri Pirko
2014-03-26 16:31 ` [patch net-next RFC v2 2/6] skbuff: add "missed_flow" flag Jiri Pirko
[not found] ` <1395851472-10524-3-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
2014-03-26 16:59 ` Alexei Starovoitov
2014-03-26 17:25 ` [ovs-dev] " Jiri Pirko
2014-03-27 10:31 ` Nicolas Dichtel
[not found] ` <5333FE0E.2090008-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-03-27 10:34 ` Jiri Pirko
2014-03-31 20:39 ` Neil Jerram
2014-03-26 16:31 ` [patch net-next RFC v2 3/6] openvswitch: split flow structures into ovs specific and generic ones Jiri Pirko
2014-03-26 16:31 ` [patch net-next RFC v2 4/6] net: introduce switchdev API Jiri Pirko
2014-03-27 11:23 ` Thomas Graf
[not found] ` <20140327112339.GB1615-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-03-27 11:26 ` Jiri Pirko
[not found] ` <1395851472-10524-5-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
2014-03-31 20:47 ` Neil Jerram
2014-03-31 20:55 ` Neil Jerram
2014-03-26 16:33 ` [patch iproute2 RFC v2] iproute: add support for dummyswport Jiri Pirko
[not found] ` <1395851472-10524-1-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
2014-03-26 16:31 ` [patch net-next RFC v2 5/6] openvswitch: Introduce support for switchdev based datapath Jiri Pirko
2014-03-26 16:31 ` [patch net-next RFC v2 6/6] net: introduce dummy switch Jiri Pirko
2014-03-26 21:44 ` [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath Jamal Hadi Salim
[not found] ` <53334A3F.6020105-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
2014-03-26 21:57 ` Florian Fainelli
[not found] ` <CAGVrzcaOph7=2WfMzTfqtwFkN1fu5uKJAH59aF7mqD4MwL7iOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-27 7:23 ` Jiri Pirko
2014-03-27 7:21 ` Jiri Pirko [this message]
[not found] ` <20140327072107.GC2845-RDzucLLXGGI88b5SBfVpbw@public.gmane.org>
2014-03-27 10:27 ` Jamal Hadi Salim
2014-03-27 11:02 ` Thomas Graf
2014-03-27 11:17 ` Jamal Hadi Salim
[not found] ` <533408C0.8000608-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
2014-03-27 12:00 ` Thomas Graf
2014-03-27 12:32 ` Jamal Hadi Salim
2014-03-27 12:57 ` Jiri Pirko
[not found] ` <20140327125711.GL2845-RDzucLLXGGI88b5SBfVpbw@public.gmane.org>
2014-03-27 14:03 ` John W. Linville
2014-03-27 16:27 ` Florian Fainelli
2014-03-27 17:20 ` Thomas Graf
[not found] ` <20140327172048.GC13573-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-03-27 17:26 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140327072107.GC2845@minipsycho.orion \
--to=jiri-rhqaubhg3fbzbrfiqnyvsa@public$(echo .)gmane.org \
--cc=andy-QlMahl40kYEqcZcGjlUOXw@public$(echo .)gmane.org \
--cc=ben-/+tVBieCtBitmTQ+vhA3Yw@public$(echo .)gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public$(echo .)gmane.org \
--cc=dborkman-H+wXaHxf7aLQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public$(echo .)gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public$(echo .)gmane.org \
--cc=f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public$(echo .)gmane.org \
--cc=jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public$(echo .)gmane.org \
--cc=jhs-jkUAjuhPggJWk0Htik3J/w@public$(echo .)gmane.org \
--cc=john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public$(echo .)gmane.org \
--cc=linville-2XuSBdqkA4R54TAoqtyWWQ@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public$(echo .)gmane.org \
--cc=ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public$(echo .)gmane.org \
--cc=roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public$(echo .)gmane.org \
--cc=sfeldma-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public$(echo .)gmane.org \
--cc=stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public$(echo .)gmane.org \
--cc=vyasevic-H+wXaHxf7aLQT0dZR+AlfA@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox