diff mbox series

[net-next,v3,10/10] Documentation: net: dsa: sja1105: Add info about supported traffic modes

Message ID 20190505101929.17056-11-olteanv@gmail.com
State Accepted
Delegated to: David Miller
Headers show
Series Traffic support for SJA1105 DSA driver | expand

Commit Message

Vladimir Oltean May 5, 2019, 10:19 a.m. UTC
This adds a table which illustrates what combinations of management /
regular traffic work depending on the state the switch ports are in.

Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
Changes in v3:
  - Added a commit description.

Changes in v2:
  - Added clarification about bridging other netdevices with swich
    ports.
  - Removed "Other notable features" section.

 Documentation/networking/dsa/sja1105.rst | 54 ++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

Comments

Florian Fainelli May 5, 2019, 5:04 p.m. UTC | #1
On 5/5/2019 3:19 AM, Vladimir Oltean wrote:
> This adds a table which illustrates what combinations of management /
> regular traffic work depending on the state the switch ports are in.
> 
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

I have finally put my brain on and understood what you meant with the
vlan_filtering=1 case, which is quite similar, if not identical to what
happens with DSA_TAG_PROTO_NONE where DSA slave network devices are
simply conduit for offloading bridge operations and the data path
continues to be on the DSA master device.
Vladimir Oltean May 5, 2019, 6:34 p.m. UTC | #2
On Sun, 5 May 2019 at 20:04, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 5/5/2019 3:19 AM, Vladimir Oltean wrote:
> > This adds a table which illustrates what combinations of management /
> > regular traffic work depending on the state the switch ports are in.
> >
> > Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
> I have finally put my brain on and understood what you meant with the
> vlan_filtering=1 case, which is quite similar, if not identical to what
> happens with DSA_TAG_PROTO_NONE where DSA slave network devices are
> simply conduit for offloading bridge operations and the data path
> continues to be on the DSA master device.
> --
> Florian

It is similar but not identical with DSA_TAG_PROTO_NONE. The
difference being that L2 multicast traffic still goes through DSA
slave netdevices, and that is exactly why I need the filtering
function.

-Vladimir
diff mbox series

Patch

diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst
index 7c13b40915c0..ea7bac438cfd 100644
--- a/Documentation/networking/dsa/sja1105.rst
+++ b/Documentation/networking/dsa/sja1105.rst
@@ -63,6 +63,38 @@  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 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.
+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.
+
+The following traffic modes are supported over the switch netdevices:
+
++--------------------+------------+------------------+------------------+
+|                    | 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)     |            |                  |                  |
++--------------------+------------+------------------+------------------+
+
 Switching features
 ==================
 
@@ -92,6 +124,28 @@  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.
 
+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.
+
 Device Tree bindings and board design
 =====================================