docs: net: dsa: sja1105: document the best_effort_vlan_filtering option
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Vladimir Oltean
David S. Miller
parent
3f01c91aab
commit
a20bc43bfb
|
|
@ -0,0 +1,27 @@
|
|||
best_effort_vlan_filtering
|
||||
[DEVICE, DRIVER-SPECIFIC]
|
||||
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.
|
||||
Configuration mode: runtime
|
||||
Type: bool.
|
||||
|
|
@ -66,34 +66,193 @@ reprogrammed with the updated static configuration.
|
|||
Traffic support
|
||||
===============
|
||||
|
||||
The switches do not support switch tagging in hardware. But they do support
|
||||
customizing the TPID by which VLAN traffic is identified as such. The switch
|
||||
driver is leveraging ``CONFIG_NET_DSA_TAG_8021Q`` by requesting that special
|
||||
VLANs (with a custom TPID of ``ETH_P_EDSA`` instead of ``ETH_P_8021Q``) are
|
||||
installed on its ports when not in ``vlan_filtering`` mode. This does not
|
||||
interfere with the reception and transmission of real 802.1Q-tagged traffic,
|
||||
because the switch does no longer parse those packets as VLAN after the TPID
|
||||
change.
|
||||
The TPID is restored when ``vlan_filtering`` is requested by the user through
|
||||
the bridge layer, and general IP termination becomes no longer possible through
|
||||
the switch netdevices in this mode.
|
||||
|
||||
The switches have two programmable filters for link-local destination MACs.
|
||||
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.
|
||||
functionality. For frames trapped to the CPU, source port and switch ID
|
||||
information is encoded by the hardware into the frames.
|
||||
|
||||
The following traffic modes are supported over the switch netdevices:
|
||||
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.
|
||||
|
||||
+--------------------+------------+------------------+------------------+
|
||||
| | Standalone | Bridged with | Bridged with |
|
||||
| | ports | vlan_filtering 0 | vlan_filtering 1 |
|
||||
+====================+============+==================+==================+
|
||||
| Regular traffic | Yes | Yes | No (use master) |
|
||||
+--------------------+------------+------------------+------------------+
|
||||
| Management traffic | Yes | Yes | Yes |
|
||||
| (BPDU, PTP) | | | |
|
||||
+--------------------+------------+------------------+------------------+
|
||||
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
|
||||
==================
|
||||
|
|
|
|||
Loading…
Reference in New Issue