lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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