Date: Thu, 11 May 2023 14:46:29 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Fabio Estevam <festevam@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, tobias@...dekranz.com,
	Florian Fainelli <f.fainelli@...il.com>,
	Steffen Bätz <steffen@...osonix.de>,
	netdev <netdev@...r.kernel.org>
Subject: Re: mv88e6320: Failed to forward PTP multicast

Hi Fabio,

On Thu, May 11, 2023 at 08:03:01AM -0300, Fabio Estevam wrote:
> Hi Vladimir,
> 
> On Wed, May 10, 2023 at 3:28 PM Vladimir Oltean <olteanv@...il.com> wrote:
> 
> > I checked out the v6.1.26 tag from linux-stable and I was able to
> > synchronize 2 stations attached to my Turris MOX (Marvell 6190) with
> > this commands: sudo ptp4l -i eth0 -4 -m
> > (also I was able to synchronize a third station behind a mvneta bridge
> > port foreign to the MV88E6190, using software forwarding)
> 
> Thanks for testing it, appreciate it.
> 
> > My bridge configuration is VLAN-aware. FWIW, I'm using vlan_default_pvid
> > 1000, but it should not make a difference.
> >
> > In a bridging configuration where there are only 2 ports in the bridge
> > PVID (1 source and 1 destination), could you please run the following
> > command from a station attached to one of the Marvell switch ports:
> >
> > board # ethtool -S lanX | grep -v ': 0'
> > station # mausezahn eth0 -B 224.0.1.129 -c 1000 -t udp "dp=319"
> > board # ethtool -S lanX | grep -v ': 0'
> >
> > and tell me which counters increment?
> 
> In our tests:
> eth0 is the port connected to the i.MX8MN.

I don't see the "eth0" name referenced in any of the attached files. By
"connected to the i.MX8MN" you mean "separate from the board under test",
right? To be more specific, it is always connected to the eth2 switch
port, correct?

> eth1 and eth2 are the Marvell switch ports
> 
> Please find attached two configurations and the results.
> 
> Some notes:
> 
> - We have bridged (eth1+eth2) = br0, no matter if it is VLAN aware or not.
> - PTP traffic flows correctly over eth1+eth2 (the 2 hardware switch interfaces)

"Flows correctly" with vlan_filtering=1? (netconfig_mausezahn_test1.sh, right)?

> - PTP traffic appears shortly, (like during 30 seconds) on the
> non-VLAN-aware case br0 interface.

Which test case is this? Both test1 and test2 are fully VLAN-aware from
the start.

What happens after 30 seconds? PTP traffic disappears? Is the bridge
still VLAN-unaware when this happens?

> - PTP traffic does not appear on the VLAN-aware br0 interface

The collected statistics are a bit noisy. The $(after - before) for
in_multicasts is 1400, and for out_multicasts is 1026. So it appears
that multicast traffic is flowing bidirectionally. Could you either stop
the other sources of traffic while repeating the experiment, or send a
higher number of mausezahn packets, so they stand out more clearly in
the delta? The mausezahn packets should have the same basic characteristics
to the switch as the PTP traffic, so you shouldn't need PTP to figure
out what's wrong for now.

Also, result_mausezahn_test1.txt says:
| Station that generates the traffic with mausezahn is connected to eth2, statistics on eth1

Could you take the statistics on the ingress switch port please? (eth2)

As for result_mausezahn_test2.txt, it says:
| Station that generates the traffic with mausezahn is connected to eth2, statistics on br0

but eth2 is not one of the ports under br0! (only eth1 and veth1 are)
So you don't expect eth2 to forward these packets, do you?

Also, the same comment: please capture the statistics at the ingress
port, not at the expected egress port. I am operating under the
assumption that in the case which doesn't work for you, the switch drops
the packets somewhere, and I want to find out the reason (which should
be on the ingress port).

Powered by blists - more mailing lists