diff options
| -rw-r--r-- | Documentation/networking/devlink/index.rst | 1 | ||||
| -rw-r--r-- | Documentation/networking/devlink/sja1105.rst | 49 | ||||
| -rw-r--r-- | Documentation/networking/dsa/dsa.rst | 29 | ||||
| -rw-r--r-- | Documentation/networking/dsa/sja1105.rst | 218 |
4 files changed, 17 insertions, 280 deletions
diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 03f56ed2961f..45b5f8b341df 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -43,7 +43,6 @@ parameters, info versions, and other features it supports. mv88e6xxx netdevsim nfp - sja1105 qed ti-cpsw-switch am65-nuss-cpsw-switch diff --git a/Documentation/networking/devlink/sja1105.rst b/Documentation/networking/devlink/sja1105.rst deleted file mode 100644 index e2679c274085..000000000000 --- a/Documentation/networking/devlink/sja1105.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======================= -sja1105 devlink support -======================= - -This document describes the devlink features implemented -by the ``sja1105`` device driver. - -Parameters -========== - -.. list-table:: Driver-specific parameters implemented - :widths: 5 5 5 85 - - * - Name - - Type - - Mode - - Description - * - ``best_effort_vlan_filtering`` - - Boolean - - runtime - - Allow plain ETH_P_8021Q headers to be used as DSA tags. - - Benefits: - - - Can terminate untagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1. - - Can terminate VLAN-tagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1, with some constraints (no more than - 7 non-pvid VLANs per user port). - - Can do QoS based on VLAN PCP and VLAN membership - admission control for autonomously forwarded frames - (regardless of whether they can be terminated on the - CPU or not). - - Drawbacks: - - - User cannot use VLANs in range 1024-3071. If the - switch receives frames with such VIDs, it will - misinterpret them as DSA tags. - - Switch uses Shared VLAN Learning (FDB lookup uses - only DMAC as key). - - When VLANs span cross-chip topologies, the total - number of permitted VLANs may be less than 7 per - port, due to a maximum number of 32 VLAN retagging - rules per switch. diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 20baacf2bc5c..89bb4fa4c362 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -200,19 +200,6 @@ receive all frames regardless of the value of the MAC DA. This can be done by setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``. Note that this assumes a DSA-unaware master driver, which is the norm. -Hardware manufacturers are strongly discouraged to do this, but some tagging -protocols might not provide source port information on RX for all packets, but -e.g. only for control traffic (link-local PDUs). In this case, by implementing -the ``filter`` method of ``struct dsa_device_ops``, the tagger might select -which packets are to be redirected on RX towards the virtual DSA user network -interfaces, and which are to be left in the DSA master's RX data path. - -It might also happen (although silicon vendors are strongly discouraged to -produce hardware like this) that a tagging protocol splits the switch-specific -information into a header portion and a tail portion, therefore not falling -cleanly into any of the above 3 categories. DSA does not support this -configuration. - Master network devices ---------------------- @@ -663,6 +650,22 @@ Bridge layer CPU port, and flooding towards the CPU port should also be enabled, due to a lack of an explicit address filtering mechanism in the DSA core. +- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after + ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to + a non-zero value. Returning success in this function activates the TX + forwarding offload bridge feature for this port, which enables the tagging + protocol driver to inject data plane packets towards the bridging domain that + the port is a part of. Data plane packets are subject to FDB lookup, hardware + learning on the CPU port, and do not override the port STP state. + Additionally, replication of data plane packets (multicast, flooding) is + handled in hardware and the bridge driver will transmit a single skb for each + packet that needs replication. The method is provided as a configuration + point for drivers that need to configure the hardware for enabling this + feature. + +- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver + leaves a bridge port which had the TX forwarding offload feature enabled. + Bridge VLAN filtering --------------------- diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index da4057ba37f1..564caeebe2b2 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -65,199 +65,6 @@ If that changed setting can be transmitted to the switch through the dynamic reconfiguration interface, it is; otherwise the switch is reset and reprogrammed with the updated static configuration. -Traffic support -=============== - -The switches do not have hardware support for DSA tags, except for "slow -protocols" for switch control as STP and PTP. For these, the switches have two -programmable filters for link-local destination MACs. -These are used to trap BPDUs and PTP traffic to the master netdevice, and are -further used to support STP and 1588 ordinary clock/boundary clock -functionality. For frames trapped to the CPU, source port and switch ID -information is encoded by the hardware into the frames. - -But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging -format based on VLANs), general-purpose traffic termination through the network -stack can be supported under certain circumstances. - -Depending on VLAN awareness state, the following operating modes are possible -with the switch: - -- Mode 1 (VLAN-unaware): a port is in this mode when it is used as a standalone - net device, or when it is enslaved to a bridge with ``vlan_filtering=0``. -- Mode 2 (fully VLAN-aware): a port is in this mode when it is enslaved to a - bridge with ``vlan_filtering=1``. Access to the entire VLAN range is given to - the user through ``bridge vlan`` commands, but general-purpose (anything - other than STP, PTP etc) traffic termination is not possible through the - switch net devices. The other packets can be still by user space processed - through the DSA master interface (similar to ``DSA_TAG_PROTO_NONE``). -- Mode 3 (best-effort VLAN-aware): a port is in this mode when enslaved to a - bridge with ``vlan_filtering=1``, and the devlink property of its parent - switch named ``best_effort_vlan_filtering`` is set to ``true``. When - configured like this, the range of usable VIDs is reduced (0 to 1023 and 3072 - to 4094), so is the number of usable VIDs (maximum of 7 non-pvid VLANs per - port*), and shared VLAN learning is performed (FDB lookup is done only by - DMAC, not also by VID). - -To summarize, in each mode, the following types of traffic are supported over -the switch net devices: - -+-------------+-----------+--------------+------------+ -| | Mode 1 | Mode 2 | Mode 3 | -+=============+===========+==============+============+ -| Regular | Yes | No | Yes | -| traffic | | (use master) | | -+-------------+-----------+--------------+------------+ -| Management | Yes | Yes | Yes | -| traffic | | | | -| (BPDU, PTP) | | | | -+-------------+-----------+--------------+------------+ - -To configure the switch to operate in Mode 3, the following steps can be -followed:: - - ip link add dev br0 type bridge - # swp2 operates in Mode 1 now - ip link set dev swp2 master br0 - # swp2 temporarily moves to Mode 2 - ip link set dev br0 type bridge vlan_filtering 1 - [ 61.204770] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 61.239944] sja1105 spi0.1: Disabled switch tagging - # swp3 now operates in Mode 3 - devlink dev param set spi/spi0.1 name best_effort_vlan_filtering value true cmode runtime - [ 64.682927] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 64.711925] sja1105 spi0.1: Enabled switch tagging - # Cannot use VLANs in range 1024-3071 while in Mode 3. - bridge vlan add dev swp2 vid 1025 untagged pvid - RTNETLINK answers: Operation not permitted - bridge vlan add dev swp2 vid 100 - bridge vlan add dev swp2 vid 101 untagged - bridge vlan - port vlan ids - swp5 1 PVID Egress Untagged - - swp2 1 PVID Egress Untagged - 100 - 101 Egress Untagged - - swp3 1 PVID Egress Untagged - - swp4 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - bridge vlan add dev swp2 vid 102 - bridge vlan add dev swp2 vid 103 - bridge vlan add dev swp2 vid 104 - bridge vlan add dev swp2 vid 105 - bridge vlan add dev swp2 vid 106 - bridge vlan add dev swp2 vid 107 - # Cannot use mode than 7 VLANs per port while in Mode 3. - [ 3885.216832] sja1105 spi0.1: No more free subvlans - -\* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the -CPU in mode 3 is possible through VLAN retagging of packets that go from the -switch to the CPU. In cross-chip topologies, the port that goes to the CPU -might also go to other switches. In that case, those other switches will see -only a retagged packet (which only has meaning for the CPU). So if they are -interested in this VLAN, they need to apply retagging in the reverse direction, -to recover the original value from it. This consumes extra hardware resources -for this switch. There is a maximum of 32 entries in the Retagging Table of -each switch device. - -As an example, consider this cross-chip topology:: - - +-------------------------------------------------+ - | Host SoC | - | +-------------------------+ | - | | DSA master for embedded | | - | | switch (non-sja1105) | | - | +--------+-------------------------+--------+ | - | | embedded L2 switch | | - | | | | - | | +--------------+ +--------------+ | | - | | |DSA master for| |DSA master for| | | - | | | SJA1105 1 | | SJA1105 2 | | | - +--+---+--------------+-----+--------------+---+--+ - - +-----------------------+ +-----------------------+ - | SJA1105 switch 1 | | SJA1105 switch 2 | - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - -To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses -to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn). -Similarly for SJA1105 switch 2. - -Also consider the following commands, that add VLAN 100 to every sja1105 user -port:: - - devlink dev param set spi/spi2.1 name best_effort_vlan_filtering value true cmode runtime - devlink dev param set spi/spi2.2 name best_effort_vlan_filtering value true cmode runtime - ip link add dev br0 type bridge - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2 sw2p3; do - ip link set dev $port master br0 - done - ip link set dev br0 type bridge vlan_filtering 1 - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2; do - bridge vlan add dev $port vid 100 - done - ip link add link br0 name br0.100 type vlan id 100 && ip link set dev br0.100 up - ip addr add 192.168.100.3/24 dev br0.100 - bridge vlan add dev br0 vid 100 self - - bridge vlan - port vlan ids - sw1p0 1 PVID Egress Untagged - 100 - - sw1p1 1 PVID Egress Untagged - 100 - - sw1p2 1 PVID Egress Untagged - 100 - - sw1p3 1 PVID Egress Untagged - 100 - - sw2p0 1 PVID Egress Untagged - 100 - - sw2p1 1 PVID Egress Untagged - 100 - - sw2p2 1 PVID Egress Untagged - 100 - - sw2p3 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - 100 - -SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port -towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that -it is also interested in, which is configured on any port of any neighbor -switch. - -In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as -follows: - -- 8 retagging entries for VLANs 1 and 100 installed on its user ports - (``sw1p0`` - ``sw1p3``) -- 3 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 2 (``sw2p0`` - ``sw2p2``), because it also has ports that are - interested in it. The VLAN 1 is a pvid on SJA1105 switch 2 and does not need - reverse retagging. - -SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows: - -- 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` - - ``sw2p3``). -- 4 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 1 (``sw1p0`` - ``sw1p3``). - Switching features ================== @@ -282,33 +89,10 @@ untagged), and therefore this mode is also supported. Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but all bridges should have the same level of VLAN awareness (either both have -``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact -that VLAN awareness is global at the switch level is that once a bridge with -``vlan_filtering`` enslaves at least one switch port, the other un-bridged -ports are no longer available for standalone traffic termination. +``vlan_filtering`` 0, or both 1). Topology and loop detection through STP is supported. -L2 FDB manipulation (add/delete/dump) is currently possible for the first -generation devices. Aging time of FDB entries, as well as enabling fully static -management (no address learning and no flooding of unknown traffic) is not yet -configurable in the driver. - -A special comment about bridging with other netdevices (illustrated with an -example): - -A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1. -The switch ports (swp0-3) are under br0. -It is desired that eth0 is turned into another switched port that communicates -with swp0-3. - -If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the -intended results. -If br0 has vlan_filtering 1, then a new br1 interface needs to be created that -enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in -this mode, the switch ports beneath br0 are not capable of regular traffic, and -are only used as a conduit for switchdev operations. - Offloads ======== |