From: Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public•gmane.org>
To: Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public•gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
Cc: vyasevic-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public•gmane.org,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public•gmane.org,
nhorman-2XuSBdqkA4R54TAoqtyWWQ@public•gmane.org,
sfeldma-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public•gmane.org,
edumazet-hpIqsD4AKlfQT0dZR+AlfA@public•gmane.org,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public•gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public•gmane.org,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public•gmane.org,
dborkman-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public•gmane.org,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public•gmane.org,
dev-yBygre7rU0TnMu66kgdUjQ@public•gmane.org,
ben-/+tVBieCtBitmTQ+vhA3Yw@public•gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public•gmane.org,
andy-QlMahl40kYEqcZcGjlUOXw@public•gmane.org
Subject: Re: [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath
Date: Wed, 26 Mar 2014 17:44:31 -0400 [thread overview]
Message-ID: <53334A3F.6020105@mojatatu.com> (raw)
In-Reply-To: <1395851472-10524-1-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
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.
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).
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-26 21:44 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
[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 ` Jamal Hadi Salim [this message]
[not found] ` <53334A3F.6020105-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
2014-03-26 21:57 ` [patch net-next RFC v2 0/6] introduce infrastructure for support of switch chip datapath 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
[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
2014-03-26 16:33 ` [patch iproute2 RFC v2] iproute: add support for dummyswport 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=53334A3F.6020105@mojatatu.com \
--to=jhs-jkuajuhpggjwk0htik3j/w@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=jiri-rHqAuBHg3fBzbRFIqnYvSA@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