Date:   Thu, 27 Jun 2019 09:38:16 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Benedikt Spranger <b.spranger@...utronix.de>
Cc:     netdev@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>
Subject: Re: [RFC PATCH 1/1] Documentation: net: dsa: b53: Describe b53
 configuration

On 6/27/19 3:15 AM, Benedikt Spranger wrote:
> Document the different needs of documentation for the b53 driver.
> 
> Signed-off-by: Benedikt Spranger <b.spranger@...utronix.de>
> ---
>  Documentation/networking/dsa/b53.rst | 300 +++++++++++++++++++++++++++
>  1 file changed, 300 insertions(+)
>  create mode 100644 Documentation/networking/dsa/b53.rst
> 
> diff --git a/Documentation/networking/dsa/b53.rst b/Documentation/networking/dsa/b53.rst
> new file mode 100644
> index 000000000000..5838cf6230da
> --- /dev/null
> +++ b/Documentation/networking/dsa/b53.rst
> @@ -0,0 +1,300 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==========================================
> +Broadcom RoboSwitch Ethernet switch driver
> +==========================================
> +
> +The Broadcom RoboSwitch Ethernet switch family is used in quite a range of
> +xDSL router, cable modems and other multimedia devices.
> +
> +The actual implementation supports the devices BCM5325E, BCM5365, BCM539x,
> +BCM53115 and BCM53125 as well as BCM63XX.
> +
> +Implementation details
> +======================
> +
> +The driver is located in ``drivers/net/dsa/bcm_sf2.c`` and is implemented as a
> +DSA driver; see ``Documentation/networking/dsa/dsa.rst`` for details on the
> +subsystemand what it provides.

The driver is under drivers/net/dsa/b53/

s/ethernet/Ethernet/ for your global submission.

What you are describing is not entirely specific to the B53 driver
(maybe with the exception of having a VLAN tag on the DSA master network
device, since B53 puts the CPU port tagged in all VLANs by default), and
therefore the entire document should be written with the general DSA
devices in mind, and eventually pointing out where B53 differs in a
separate document.

There are largely two kinds of behavior:

- switches that are configured with DSA_TAG_PROTO_NONE, which behave in
a certain way and require a bridge with VLAN filtering even when ports
are intended to be used as standalone devices.

- switches that are configured with a tagging protocol other than
DSA_TAG_PROTO_NONE, which behave more like traditional network devices
people are used to use.

> +
> +The switch is, if possible, configured to enable a Broadcom specific 4-bytes
> +switch tag which gets inserted by the switch for every packet forwarded to the
> +CPU interface, conversely, the CPU network interface should insert a similar
> +tag for packets entering the CPU port. The tag format is described in
> +``net/dsa/tag_brcm.c``.
> +
> +The configuration of the device depends on whether or not tagging is
> +supported.
> +
> +Configuration with tagging support
> +----------------------------------
> +
> +The tagging based configuration is desired.
> +
> +To use the b53 DSA driver some configuration need to be performed. As
> +example configuration the following scenarios are used:
> +
> +*single port*
> +  Every switch port acts as a different configurable ethernet port
> +
> +*bridge*
> +  Every switch port is part of one configurable ethernet bridge
> +
> +*gateway*
> +  Every switch port except one upstream port is part of a configurable
> +  ethernet bridge.
> +  The upstream port acts as different configurable ethernet port.
> +
> +All configurations are performed with tools from iproute2, wich is available at
> +https://www.kernel.org/pub/linux/utils/net/iproute2/
> +
> +In this documentation the following ethernet ports are used:
> +
> +*eth0*
> +  CPU port
> +
> +*LAN1*
> +  a switch port
> +
> +*LAN2*
> +  another switch port
> +
> +*WAN*
> +  A switch port dedicated as upstream port
> +
> +Further ethernet ports can be configured similar.
> +The configured IPs and networks are:
> +
> +*single port*
> +  *  wan: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
> +  * lan1: 192.0.2.5/30 (192.0.2.4 - 192.0.2.7)
> +  * lan2: 192.0.2.9/30 (192.0.2.8 - 192.0.2.11)
> +
> +*bridge*
> +  * br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
> +
> +*gateway*
> +  * br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
> +  * wan: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
> +
> +single port
> +~~~~~~~~~~~
> +
> +.. code-block:: sh
> +
> +  # configure each interface
> +  ip addr add 192.0.2.1/30 dev wan
> +  ip addr add 192.0.2.5/30 dev lan1
> +  ip addr add 192.0.2.9/30 dev lan2
> +
> +  # The master interface needs to be brought up before the slave ports.
> +  ip link set eth0 up
> +
> +  # bring up the slave interfaces
> +  ip link set wan up
> +  ip link set lan1 up
> +  ip link set lan2 up
> +
> +bridge
> +~~~~~~

I would add something like:

All ports being part of a single bridge/broadcast domain or something
along those lines. Seeing the "wan" interface being added to a bridge is
a bit confusing.

> +
> +.. code-block:: sh
> +
> +  # create bridge
> +  ip link add name br0 type bridge
> +
> +  # add ports to bridge
> +  ip link set dev wan master br0
> +  ip link set dev lan1 master br0
> +  ip link set dev lan2 master br0
> +
> +  # configure the bridge
> +  ip addr add 192.0.2.129/25 dev br0
> +
> +  # The master interface needs to be brought up before the slave ports.
> +  ip link set eth0 up
> +
> +  # bring up the slave interfaces
> +  ip link set wan up
> +  ip link set lan1 up
> +  ip link set lan2 up
> +
> +  # bring up the bridge
> +  ip link set dev br0 up
> +
> +gateway
> +~~~~~~~
> +
> +.. code-block:: sh
> +
> +  # create bridge
> +  ip link add name br0 type bridge
> +
> +  # add ports to bridge
> +  ip link set dev lan1 master br0
> +  ip link set dev lan2 master br0
> +
> +  # configure the bridge
> +  ip addr add 192.0.2.129/25 dev br0
> +
> +  # configure the upstream port
> +  ip addr add 192.0.2.1/30 dev wan
> +
> +  # The master interface needs to be brought up before the slave ports.
> +  ip link set eth0 up
> +
> +  # bring up the slave interfaces
> +  ip link set wan up
> +  ip link set lan1 up
> +  ip link set lan2 up
> +
> +  # bring up the bridge
> +  ip link set dev br0 up
> +
> +Configuration without tagging support
> +-------------------------------------
> +
> +Older models (5325, 5365) support a different tag format that is not supported
> +yet. 539x and 531x5 require managed mode and some special handling, which is
> +also not yet supported. The tagging support is disabled in these cases and the
> +switch need a different configuration.

On that topic, did the patch I sent you ended up working the way you
wanted it with ifupdown-scripts or are you still chasing some other
issues with it?

> +
> +single port
> +~~~~~~~~~~~
> +The configuration can only be set up via VLAN tagging and bridge setup.
> +By default packages are tagged with vid 1:
> +
> +.. code-block:: sh
> +
> +  # tag traffic on CPU port
> +  ip link add link eth0 name eth0.1 type vlan id 1
> +  ip link add link eth0 name eth0.2 type vlan id 2
> +  ip link add link eth0 name eth0.3 type vlan id 3

That part is indeed a B53 implementation specific detail because B53
tags the CPU port in all VLANs, since otherwise any PVID untagged VLAN
programming would basically change the CPU port's default PVID and make
it untagged, undesirable.

> +
> +  # create bridges
> +  ip link add name br0 type bridge
> +  ip link add name br1 type bridge
> +  ip link add name br2 type bridge
> +
> +  # activate VLAN filtering
> +  ip link set dev br0 type bridge vlan_filtering 1
> +  ip link set dev br1 type bridge vlan_filtering 1
> +  ip link set dev br2 type bridge vlan_filtering 1
> +
> +  # add ports to bridges
> +  ip link set dev wan master br0
> +  ip link set eth0.1 master br0
> +  ip link set dev lan1 master br1
> +  ip link set eth0.2 master br1
> +  ip link set dev lan2 master br2
> +  ip link set eth0.3 master br2

I don't think you need one bridge for each port you want to isolate with
DSA_PROTO_TAG_NONE, you can just have a single bridge and assign the
ports a different VLAN with the commands below:

> +
> +  # tag traffic on ports
> +  bridge vlan add dev lan1 vid 2 pvid untagged
> +  bridge vlan del dev lan1 vid 1
> +  bridge vlan add dev lan2 vid 3 pvid untagged
> +  bridge vlan del dev lan2 vid 1

And also permit the different VLANs that you created on the bridge
master device itself:

bridge vlan add vid 2 dev br0 self
bridve vlan add vid 3 dev br0 self

Maybe that last part above ^^ was missing and that's why people tend to
create multiple bridge devices?

> +
> +  # configure the bridges
> +  ip addr add 192.0.2.1/30 dev br0
> +  ip addr add 192.0.2.5/30 dev br1
> +  ip addr add 192.0.2.9/30 dev br2
> +
> +  # The master interface needs to be brought up before the slave ports.
> +  ip link set eth0 up
> +  ip link set eth0.1 up
> +  ip link set eth0.2 up
> +  ip link set eth0.3 up
> +
> +  # bring up the slave interfaces
> +  ip link set wan up
> +  ip link set lan1 up
> +  ip link set lan2 up
> +
> +  # bring up the bridge devices
> +  ip link set br0 up
> +  ip link set br1 up
> +  ip link set br2 up
> +
> +bridge
> +~~~~~~
> +
> +.. code-block:: sh
> +
> +  # tag traffic on CPU port
> +  ip link add link eth0 name eth0.1 type vlan id 1
> +
> +  # create bridge
> +  ip link add name br0 type bridge
> +
> +  # activate VLAN filtering
> +  ip link set dev br0 type bridge vlan_filtering 1
> +
> +  # add ports to bridge
> +  ip link set dev wan master br0
> +  ip link set dev lan1 master br0
> +  ip link set dev lan2 master br0
> +  ip link set eth0.1 master br0
> +
> +  # configure the bridge
> +  ip addr add 192.0.2.129/25 dev br0
> +
> +  # The master interface needs to be brought up before the slave ports.
> +  ip link set eth0 up
> +  ip link set eth0.1 up
> +
> +  # bring up the slave interfaces
> +  ip link set wan up
> +  ip link set lan1 up
> +  ip link set lan2 up
> +
> +  # bring up the bridge
> +  ip link set dev br0 up
> +
> +gateway
> +~~~~~~~
> +
> +.. code-block:: sh
> +
> +  # tag traffic on CPU port
> +  ip link add link eth0 name eth0.1 type vlan id 1
> +  ip link add link eth0 name eth0.2 type vlan id 2
> +
> +  # create bridges
> +  ip link add name br0 type bridge
> +  ip link add name br1 type bridge

Likewise, I have seen claims of people telling me they used two bridge
devices, but AFAICT this is only because the bridge master did not have
VID 2 programmed to it, so if you did the following:

bridge vlan add vid 2 dev br0 self

you should be able to get away with a single bridge master device, can
you try that?

Overall this is fills a lot of gaps and questions that were being asked
on the lamobo R1 threads on various forums, thanks a lot for doing that!
-- 
Florian

Powered by blists - more mailing lists