mbox series

[net,0/3] Fixes for sja1105 best-effort VLAN filtering

Message ID 20210407201452.1703261-1-olteanv@gmail.com (mailing list archive)
Headers show
Series Fixes for sja1105 best-effort VLAN filtering | expand

Message

Vladimir Oltean April 7, 2021, 8:14 p.m. UTC
From: Vladimir Oltean <vladimir.oltean@nxp.com>

This series addresses some user complaints regarding best-effort VLAN
filtering support on sja1105:
- switch not pushing VLAN tag on egress when it should
- switch not dropping traffic with unknown VLAN when it should
- switch not overwriting VLAN flags when it should

Those bugs are not the reason why it's called best-effort, so we should
fix them :)

Vladimir Oltean (3):
  net: dsa: sja1105: use the bridge pvid in best_effort_vlan_filtering
    mode
  net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic
  net: dsa: sja1105: update existing VLANs from the bridge VLAN list

 drivers/net/dsa/sja1105/sja1105.h      |  1 +
 drivers/net/dsa/sja1105/sja1105_main.c | 61 ++++++++++++++++++--------
 2 files changed, 43 insertions(+), 19 deletions(-)

Comments

Vladimir Oltean April 7, 2021, 8:46 p.m. UTC | #1
On Wed, Apr 07, 2021 at 11:14:49PM +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> 
> This series addresses some user complaints regarding best-effort VLAN
> filtering support on sja1105:
> - switch not pushing VLAN tag on egress when it should
> - switch not dropping traffic with unknown VLAN when it should
> - switch not overwriting VLAN flags when it should
> 
> Those bugs are not the reason why it's called best-effort, so we should
> fix them :)
> 
> Vladimir Oltean (3):
>   net: dsa: sja1105: use the bridge pvid in best_effort_vlan_filtering
>     mode
>   net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic
>   net: dsa: sja1105: update existing VLANs from the bridge VLAN list
> 
>  drivers/net/dsa/sja1105/sja1105.h      |  1 +
>  drivers/net/dsa/sja1105/sja1105_main.c | 61 ++++++++++++++++++--------
>  2 files changed, 43 insertions(+), 19 deletions(-)
> 
> -- 
> 2.25.1
> 

Please don't apply these patches yet. I finished regression testing and
it looks like patch 1 breaks PTP for some reason I'm afraid to even think
of now - the RX timestamps are still collected but synchronization looks
flat by around 1 ms.

If my suspicion is right and the VLAN retagging affects PTP traffic too
(which should hit a trap-to-host rule before that even takes place),
then the MAC timestamp might be replaced with a timestamp taken on the
internal loopback port, which would be pretty nasty. Or the strict
delivery order guarantees towards the DSA master (first comes the PTP
frame, then the meta frame holding the RX timestamp) might no longer be
true if the original PTP frame is dropped in hardware because its
VLAN-retagged replacement is sent to the CPU instead? I don't know. I'll
do some more debugging tomorrow.