All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kurt Kanzenbach <kurt@kmk-computers.de>
To: Richard Cochran <richardcochran@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic
Date: Mon, 13 Dec 2021 19:40:04 +0100	[thread overview]
Message-ID: <87a6h4xsaj.fsf@kmk-computers.de> (raw)
In-Reply-To: <20211213121045.GA14042@hoboy.vegasvil.org>

On Mon Dec 13 2021, Richard Cochran wrote:
> On Sat, Dec 11, 2021 at 07:39:26AM -0800, Richard Cochran wrote:
>> On Fri, Dec 10, 2021 at 09:14:10PM -0800, Jakub Kicinski wrote:
>> > On Fri, 10 Dec 2021 01:07:59 +0100 Tobias Waldekranz wrote:
>> > > Do we know how PTP is supposed to work in relation to things like STP?
>> > > I.e should you be able to run PTP over a link that is currently in
>> > > blocking?
>> > 
>> > Not sure if I'm missing the real question but IIRC the standard
>> > calls out that PTP clock distribution tree can be different that
>> > the STP tree, ergo PTP ignores STP forwarding state.
>> 
>> That is correct.  The PTP will form its own spanning tree, and that
>> might be different than the STP.  In fact, the Layer2 PTP messages
>> have special MAC addresses that are supposed to be sent
>> unconditionally, even over blocked ports.
>
> Let me correct that statement.
>
> I looked at 1588 again, and for E2E TC it states, "All PTP version 2
> messages shall be forwarded according to the addressing rules of the
> network."  I suppose that includes the STP state.
>
> For P2P TC, there is an exception that the peer delay messages are not
> forwarded.  These are generated and consumed by the switch.
>
> The PTP spanning tree still is formed by the Boundary Clocks (BC), and
> a Transparent Clock (TC) does not participate in forming the PTP
> spanning tree.
>
> What does this mean for Linux DSA switch drivers?
>
> 1. All incoming PTP frames should be forwarded to the CPU port, so
>    that the software stack may perform its BC or TC functions.
>
> 2. When used as a BC, the PTP frames sent from the CPU port should not
>    be dropped.
>
> 3. When used as a TC, PTP frames sent from the CPU port can be dropped
>    on blocked external ports, except for the Peer Delay messages.

Maybe I'm missing something, but how is #2 and #3 supposed to work with
DSA? The switch driver doesn't know whether the user wants to run BC or
TC. For #2 the STP state is ignored, for #3 it is not except for peer
delay measurements.

Thanks,
Kurt

      parent reply	other threads:[~2021-12-13 18:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 17:33 [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic Kurt Kanzenbach
2021-12-10  0:07 ` Tobias Waldekranz
2021-12-10 17:39   ` Kurt Kanzenbach
2021-12-11 23:02     ` Tobias Waldekranz
2021-12-13 18:54       ` Kurt Kanzenbach
2021-12-11  5:14   ` Jakub Kicinski
2021-12-11 15:39     ` Richard Cochran
2021-12-12 15:16       ` Kurt Kanzenbach
2021-12-13 12:10       ` Richard Cochran
2021-12-13 12:31         ` Vladimir Oltean
2021-12-13 15:27           ` Andrew Lunn
2021-12-13 17:11           ` Richard Cochran
2021-12-13 18:58             ` Vladimir Oltean
2021-12-13 16:44         ` Jakub Kicinski
2021-12-13 17:04           ` Richard Cochran
2021-12-13 18:40         ` Kurt Kanzenbach [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6h4xsaj.fsf@kmk-computers.de \
    --to=kurt@kmk-computers.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=richardcochran@gmail.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.