[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211213171140.GB14706@hoboy.vegasvil.org>
Date: Mon, 13 Dec 2021 09:11:40 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Tobias Waldekranz <tobias@...dekranz.com>,
Kurt Kanzenbach <kurt@...-computers.de>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic
On Mon, Dec 13, 2021 at 02:31:47PM +0200, Vladimir Oltean wrote:
> With other drivers, all packets injected from the CPU port act as if in
> "god mode", bypassing any STP state. It then becomes the responsibility
> of the software to not send packets on a port that is blocking,
> except for packets for control protocols. Would you agree that ptp4l
> should consider monitoring whether its ports are under a bridge, and
> what STP state that bridge port is in?
Perhaps. linuxptp TC mode will forward frames out all configured
interfaces. If the bridge can't drop the PTP frames automatically,
then this could cause loops.
So if switch HW in general won't drop them, then, yes, the TC user
space stack will need to follow the STP state.
> I think this isn't even specific
> to DSA, the same thing would happen with software bridging:
(Linux doesn't support even SW time stamping on SW bridges, so you
can't have a TC running in this case.)
Thanks,
Richard
Powered by blists - more mailing lists