Message-ID: <a0b29ac4-7159-6ccf-9ad1-8193951be7ea@gmail.com>
Date:   Fri, 3 May 2019 19:17:38 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, vivien.didelot@...il.com,
        andrew@...n.ch, davem@...emloft.net
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 9/9] Documentation: net: dsa: sja1105: Add info
 about supported traffic modes



On 5/3/2019 6:18 PM, Vladimir Oltean wrote:
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>
> ---
>  Documentation/networking/dsa/sja1105.rst | 49 ++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst
> index 7c13b40915c0..a70a04164d07 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) |
> ++--------------------+------------+------------------+------------------+

Just to make sure I fully understand the limitation here and sorry for
making you repeat it since I am sure you have explained it already.

Let's say that I have a bridge with vlan_filtering=1 configured, and I
assign an IP address to the bridge master device (as is a common thing
with e.g.: SOHO routers), does that mean I cannot ping any stations
behind that bridge at all?

We used to have this problem with DSA master devices being a bridge
member which was fixed a while ago by simply denying them a bridge join
[1], would that be something to rework somehow here such that we can let
your DSA master device join the bridge to continue delivering frames to
the bridge master?

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8db0a2ee2c6302a1dcbcdb93cb731dfc6c0cdb5e


> +| Management traffic |     Yes    |       Yes        |       Yes        |
> +|    (BPDU, PTP)     |            |                  |                  |
> ++--------------------+------------+------------------+------------------+
> +
>  Switching features
>  ==================
>  
> @@ -92,6 +124,23 @@ 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.
> +
> +Other notable features
> +======================
> +
> +The switches have a PTP Hardware Clock that can be steered through SPI and used
> +for timestamping management traffic on ingress and egress.
> +Also, the T, Q and S devices support TTEthernet (an implementation of SAE
> +AS6802 from TTTech), which is a set of Ethernet QoS enhancements somewhat
> +similar in behavior to IEEE TSN (time-aware shaping, time-based policing).
> +Configuring these features is currently not supported in the driver.
> +
>  Device Tree bindings and board design
>  =====================================
>  
> 

-- 
Florian

Powered by blists - more mailing lists