netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Hubert Feurstein <h.feurstein@gmail.com>,
	Miroslav Lichvar <mlichvar@redhat.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-spi@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver
Date: Thu, 22 Aug 2019 16:56:45 +0200	[thread overview]
Message-ID: <20190822145645.GJ13020@lunn.ch> (raw)
In-Reply-To: <20190822141641.GB1437@localhost>

> Thinking back...
> 
> One problem is this.  PTP requires a delay measurement.  You can send
> a delay request from the host, but there will never be a reply.
> 
> Another problem is this.  A Sync message arriving on an external port
> is time stamped there, but then it is encapsulated as a tagged DSA
> management message and delivered out the CPU port.  At this point, it
> is no longer a PTP frame and will not be time stamped at the CPU port
> on egress.

I think so that both the host interface and the CPU port recognize the
frame and time stamp it, it needs to be untagged. Otherwise, as you
said, the hardware does not recognise it. I've never tried sending
untagged frames to the CPU port. I expect they are just dropped.

However, somebody might want to play with the TCAM. The TCAM can
redirect a packet out any port. I've no idea what the pipeline
ordering is, but it might be possible for the TCAM to redirect a frame
back to the host interface, before it gets dropped because it does not
have DSA tags?  But is the TCAM before or after PTP in the pipeline?
Could you then get 4 timestamps for the same frame?  Host egress,
switch ingress, switch egress, host ingress?

But how do you make this generic? Can other switches also loop a frame
back like this and do the same time stamping? How do you actually get
access to these time stamps split over two blocks of hardware?

So in theory, this might be possible, but in practice?

     Andrew

  reply	other threads:[~2019-08-22 14:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-18 18:25 [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-18 18:25 ` [PATCH spi for-5.4 1/5] spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messages Vladimir Oltean
2019-08-20 18:21   ` Mark Brown
2019-08-20 19:36     ` Vladimir Oltean
2019-08-21 11:01       ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 2/5] spi: Add a PTP system timestamp to the transfer structure Vladimir Oltean
2019-08-22 17:11   ` Mark Brown
2019-08-24 12:38     ` Vladimir Oltean
2019-08-27 19:01       ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 3/5] spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing Vladimir Oltean
2019-08-22 17:38   ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 4/5] spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode Vladimir Oltean
2019-08-18 18:26 ` [PATCH spi for-5.4 5/5] spi: spi-fsl-dspi: Disable interrupts and preemption during poll mode transfer Vladimir Oltean
2019-08-20 15:57 ` [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-20 16:57   ` Andrew Lunn
2019-08-21  4:38   ` Richard Cochran
2019-08-21 14:08     ` Richard Cochran
2019-08-21 20:17       ` Vladimir Oltean
2019-08-22 14:16         ` Richard Cochran
2019-08-22 14:56           ` Andrew Lunn [this message]
2019-08-22 14:58           ` Vladimir Oltean
2019-08-22 16:05             ` Richard Cochran
2019-08-22 16:13               ` Vladimir Oltean
2019-08-23  5:22                 ` Richard Cochran
2019-08-24 12:13                   ` Vladimir Oltean
2019-08-22 16:10             ` Richard Cochran
2019-08-21  4:42   ` Richard Cochran

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=20190822145645.GJ13020@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=h.feurstein@gmail.com \
    --cc=linux-spi@vger.kernel.org \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=richardcochran@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).