Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1645955 > unrolled thread
| Started by | Vivien Didelot <vivien.didelot@savoirfairelinux.com> |
|---|---|
| First post | 2017-05-19 23:10 +0200 |
| Last post | 2017-05-23 01:40 +0200 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.kernel
[PATCH net-next 00/20] net: dsa: distribute switch events Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2017-05-19 23:10 +0200
Re: [PATCH net-next 00/20] net: dsa: distribute switch events Andrew Lunn <andrew@lunn.ch> - 2017-05-22 16:50 +0200
Re: [PATCH net-next 00/20] net: dsa: distribute switch events David Miller <davem@davemloft.net> - 2017-05-22 16:50 +0200
Re: [PATCH net-next 00/20] net: dsa: distribute switch events Florian Fainelli <f.fainelli@gmail.com> - 2017-05-22 22:10 +0200
Re: [PATCH net-next 00/20] net: dsa: distribute switch events David Miller <davem@davemloft.net> - 2017-05-23 01:40 +0200
| From | Vivien Didelot <vivien.didelot@savoirfairelinux.com> |
|---|---|
| Date | 2017-05-19 23:10 +0200 |
| Subject | [PATCH net-next 00/20] net: dsa: distribute switch events |
| Message-ID | <tIXjP-7UF-3@gated-at.bofh.it> |
DSA is by nature the support for a switch fabric, which can be composed
of a single, or multiple interconnected Ethernet switch chips.
The current DSA core behavior is to identify the slave port targeted by
a request (e.g. adding a VLAN entry), and program the switch chip to
which it belongs accordingly.
This is problematic in a multi-chip environment, since all chips of a
fabric must be aware of most configuration changes. Here are some
concrete examples in a 3-chip environment:
[CPU].................... (mdio)
(eth0) | : : :
_|_____ _______ _______
[__sw0__]--[__sw1__]--[__sw2__]
| | | | | | | | |
v v v v v v v v v
p1 p2 p3 p4 p5 p6 p7 p8 p9
If you add a VLAN entry on p7, sw2 gets programmed, but frames won't
reach the CPU interface in a VLAN filtered setup. sw0 and sw1 also need
to be programmed. The same problem comes with MAC addresses (FDB, MDB),
or ageing time changes for instance.
This patch series uses the notification chain introduced for bridging,
to notify not only bridge, but switchdev attributes and objects events
to all switch chips of the fabric.
An ugly debug message printing the ignored event and switch info in the
code handling the switch VLAN events would give us:
# bridge vlan add dev p7 vid 42
sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
To achieve that, patches 1-8 change the scope of the bridge and
switchdev callbacks from the DSA slave device to the generic DSA port,
so that the port-wide API can be used later for switch ports not exposed
to userspace, such as CPU and DSA links.
Patches 9-15 move the DSA port specific functions in a new port.c file.
Patches 16-20 introduce new events to notify the fabric about switchdev
attributes and objects manipulation.
This patch series only adds the plumbing to support a distributed
configuration, but for the moment, each switch chip ignores events from
other chips of the fabric, to keep the current behavior.
The next patch series will add support for cross-chip configuration of
bridge ageing time, VLAN and MAC address databases operations, etc.
Vivien Didelot (20):
net: dsa: change scope of STP state setter
net: dsa: change scope of notifier call chain
net: dsa: change scope of bridging code
net: dsa: change scope of FDB handlers
net: dsa: change scope of MDB handlers
net: dsa: change scope of VLAN handlers
net: dsa: change scope of VLAN filtering setter
net: dsa: change scope of ageing time setter
net: dsa: move port state setters
net: dsa: move bridging routines
net: dsa: move VLAN filtering setter
net: dsa: move ageing time setter
net: dsa: move FDB handlers
net: dsa: move MDB handlers
net: dsa: move VLAN handlers
net: dsa: move notifier info to private header
net: dsa: add notifier for ageing time
net: dsa: add FDB notifier
net: dsa: add MDB notifier
net: dsa: add VLAN notifier
include/net/dsa.h | 10 --
net/dsa/Makefile | 2 +-
net/dsa/dsa_priv.h | 83 +++++++++++++
net/dsa/port.c | 260 +++++++++++++++++++++++++++++++++++++++
net/dsa/slave.c | 354 +++++------------------------------------------------
net/dsa/switch.c | 175 ++++++++++++++++++++++++++
6 files changed, 547 insertions(+), 337 deletions(-)
create mode 100644 net/dsa/port.c
--
2.13.0
[toc] | [next] | [standalone]
| From | Andrew Lunn <andrew@lunn.ch> |
|---|---|
| Date | 2017-05-22 16:50 +0200 |
| Message-ID | <tJWOK-6Ut-7@gated-at.bofh.it> |
| In reply to | #1645955 |
On Mon, May 22, 2017 at 10:45:57AM -0400, David Miller wrote:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Date: Fri, 19 May 2017 17:00:35 -0400
>
> > DSA is by nature the support for a switch fabric, which can be composed
> > of a single, or multiple interconnected Ethernet switch chips.
> >
> > The current DSA core behavior is to identify the slave port targeted by
> > a request (e.g. adding a VLAN entry), and program the switch chip to
> > which it belongs accordingly.
> >
> > This is problematic in a multi-chip environment, since all chips of a
> > fabric must be aware of most configuration changes. Here are some
> > concrete examples in a 3-chip environment:
> ...
> > This patch series uses the notification chain introduced for bridging,
> > to notify not only bridge, but switchdev attributes and objects events
> > to all switch chips of the fabric.
>
> Andrew or Florian, can I get a review?
Yes, it is on my TODO list for today/tomorrow.
Andrew
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2017-05-22 16:50 +0200 |
| Message-ID | <tJWOK-6Ut-9@gated-at.bofh.it> |
| In reply to | #1645955 |
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Date: Fri, 19 May 2017 17:00:35 -0400 > DSA is by nature the support for a switch fabric, which can be composed > of a single, or multiple interconnected Ethernet switch chips. > > The current DSA core behavior is to identify the slave port targeted by > a request (e.g. adding a VLAN entry), and program the switch chip to > which it belongs accordingly. > > This is problematic in a multi-chip environment, since all chips of a > fabric must be aware of most configuration changes. Here are some > concrete examples in a 3-chip environment: ... > This patch series uses the notification chain introduced for bridging, > to notify not only bridge, but switchdev attributes and objects events > to all switch chips of the fabric. Andrew or Florian, can I get a review? I audited the slave-->port transformations and they all look good.
[toc] | [prev] | [next] | [standalone]
| From | Florian Fainelli <f.fainelli@gmail.com> |
|---|---|
| Date | 2017-05-22 22:10 +0200 |
| Message-ID | <tK1Op-1JR-7@gated-at.bofh.it> |
| In reply to | #1645955 |
Yo Vivien, On 05/19/2017 02:00 PM, Vivien Didelot wrote: > DSA is by nature the support for a switch fabric, which can be composed > of a single, or multiple interconnected Ethernet switch chips. > > The current DSA core behavior is to identify the slave port targeted by > a request (e.g. adding a VLAN entry), and program the switch chip to > which it belongs accordingly. > > This is problematic in a multi-chip environment, since all chips of a > fabric must be aware of most configuration changes. Here are some > concrete examples in a 3-chip environment: > > [CPU].................... (mdio) > (eth0) | : : : > _|_____ _______ _______ > [__sw0__]--[__sw1__]--[__sw2__] > | | | | | | | | | > v v v v v v v v v > p1 p2 p3 p4 p5 p6 p7 p8 p9 > > If you add a VLAN entry on p7, sw2 gets programmed, but frames won't > reach the CPU interface in a VLAN filtered setup. sw0 and sw1 also need > to be programmed. The same problem comes with MAC addresses (FDB, MDB), > or ageing time changes for instance. > > This patch series uses the notification chain introduced for bridging, > to notify not only bridge, but switchdev attributes and objects events > to all switch chips of the fabric. > > An ugly debug message printing the ignored event and switch info in the > code handling the switch VLAN events would give us: > > # bridge vlan add dev p7 vid 42 > sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase) > sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase) > sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase) > sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase) > > To achieve that, patches 1-8 change the scope of the bridge and > switchdev callbacks from the DSA slave device to the generic DSA port, > so that the port-wide API can be used later for switch ports not exposed > to userspace, such as CPU and DSA links. > > Patches 9-15 move the DSA port specific functions in a new port.c file. > > Patches 16-20 introduce new events to notify the fabric about switchdev > attributes and objects manipulation. > > This patch series only adds the plumbing to support a distributed > configuration, but for the moment, each switch chip ignores events from > other chips of the fabric, to keep the current behavior. > > The next patch series will add support for cross-chip configuration of > bridge ageing time, VLAN and MAC address databases operations, etc. For this entire series: Tested-by: Florian Fainelli <f.fainelli@gmail.com> on a 7445 (bcm-sf2), normal bridging still worked, and bridging with VLAN filtering also did, just like adding VLANs to user-facing ports also did. Great job! > > > Vivien Didelot (20): > net: dsa: change scope of STP state setter > net: dsa: change scope of notifier call chain > net: dsa: change scope of bridging code > net: dsa: change scope of FDB handlers > net: dsa: change scope of MDB handlers > net: dsa: change scope of VLAN handlers > net: dsa: change scope of VLAN filtering setter > net: dsa: change scope of ageing time setter > net: dsa: move port state setters > net: dsa: move bridging routines > net: dsa: move VLAN filtering setter > net: dsa: move ageing time setter > net: dsa: move FDB handlers > net: dsa: move MDB handlers > net: dsa: move VLAN handlers > net: dsa: move notifier info to private header > net: dsa: add notifier for ageing time > net: dsa: add FDB notifier > net: dsa: add MDB notifier > net: dsa: add VLAN notifier > > include/net/dsa.h | 10 -- > net/dsa/Makefile | 2 +- > net/dsa/dsa_priv.h | 83 +++++++++++++ > net/dsa/port.c | 260 +++++++++++++++++++++++++++++++++++++++ > net/dsa/slave.c | 354 +++++------------------------------------------------ > net/dsa/switch.c | 175 ++++++++++++++++++++++++++ > 6 files changed, 547 insertions(+), 337 deletions(-) > create mode 100644 net/dsa/port.c > -- Florian
[toc] | [prev] | [next] | [standalone]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2017-05-23 01:40 +0200 |
| Message-ID | <tK55D-3FX-7@gated-at.bofh.it> |
| In reply to | #1647328 |
From: Florian Fainelli <f.fainelli@gmail.com> Date: Mon, 22 May 2017 13:01:06 -0700 > For this entire series: > > Tested-by: Florian Fainelli <f.fainelli@gmail.com> > > on a 7445 (bcm-sf2), normal bridging still worked, and bridging with > VLAN filtering also did, just like adding VLANs to user-facing ports > also did. > > Great job! Series applied, thanks. Andrew, if you have any feedback or have any reservations about what this series is doing, don't worry. I'm sure you can work it out with Vivien and he'll make whatever changes are necessary to make you happy about it. Thanks.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web