netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	netdev@vger.kernel.org, glipus@gmail.com,
	maxime.chevallier@bootlin.com, vadim.fedorenko@linux.dev,
	richardcochran@gmail.com, gerhard@engleder-embedded.com,
	thomas.petazzoni@bootlin.com, krzysztof.kozlowski+dt@linaro.org,
	robh+dt@kernel.org
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space.
Date: Thu, 11 May 2023 15:09:02 -0700	[thread overview]
Message-ID: <20230511150902.57d9a437@kernel.org> (raw)
In-Reply-To: <20230511210237.nmjmcex47xadx6eo@skbuf>

On Fri, 12 May 2023 00:02:37 +0300 Vladimir Oltean wrote:
> > Surely that is equivalent to MAC timestamping? Whether the MAC
> > places it in a DMA descriptor, or whether it places it in some
> > auxiliary information along with the packet is surely irrelevant,
> > because the MAC has to have the timestamp available to it in some
> > manner. Where it ends up is just a function of implementation surely?
> > 
> > I'm just wondering what this would mean for mvpp2, where the
> > timestamps are in the descriptors. If we have a "DMA timestamp"
> > is that a "DMA timestamp" or a "MAC timestamp"? The timestamp comes
> > from the MAC in this case.  
> 
> No, a MAC timestamp carried through a DMA descriptor is still a MAC
> timestamp (better said: timestamp taken at the MAC).

Right. The method of communicating the TS and where TS is taken 
are theoretically unrelated (in practice DMA timestamp not in
a descriptor is likely pointless).

> DMA timestamps probably have to do with this igc patch set, which I
> admit to not having had the patience to follow along all the way and
> understand what is its status and if it was ever accepted in that form,
> or a different form, or if Vinicius' work for multiple in-flight TX

Exactly, think Tx. For Rx hauling the TS in metadata from PHY/MAC to
descriptor is easy. For Tx device will buffer the packet so the DMA
completion happens before the packet actually left onto the wire.

Which is not to say that some devices may not generate the Rx timestamp
when the packet is DMA'ed out of laziness, too.

> timestamps is an alternate solution to the same problem as DMA
> timestamps, or whatever:
> https://lore.kernel.org/netdev/20221018010733.4765-1-muhammad.husaini.zulkifli@intel.com/

What I was thinking was:

 - PHY - per spec, at the RS layer
 - MAC - "close to the wire" in the MAC, specifically the pipeline
   delay (PHY stamp vs MAC stamp) should be constant for all packets;
   there must be no variable-time buffering and (for Tx) the time
   stamping must be past the stage of the pipeline affected by pause
   frames
 - DMA - worst quality, variable delay timestamp, usually taken when
   packets DMA descriptors (Rx or completion) are being written

With these definitions MAC and PHY timestamps are pretty similar
from the perspective of accuracy.

  reply	other threads:[~2023-05-11 22:09 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 17:33 [PATCH net-next RFC v4 0/5] net: Make MAC/PHY time stamping selectable Köry Maincent
2023-04-06 17:33 ` [PATCH net-next RFC v4 1/5] net: ethtool: Refactor identical get_ts_info implementations Köry Maincent
2023-04-12 13:16   ` Vladimir Oltean
2023-04-12 13:49     ` Köry Maincent
2023-04-12 16:56       ` Richard Cochran
2023-04-06 17:33 ` [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space Köry Maincent
2023-04-07  1:46   ` Jakub Kicinski
2023-04-07  8:58     ` Köry Maincent
2023-04-07 14:26       ` Jakub Kicinski
2023-04-07 14:44         ` Jakub Kicinski
2023-05-17 19:58       ` Jacob Keller
2023-04-12 10:50     ` Michael Walle
2023-04-12 11:08       ` Vladimir Oltean
2023-04-12 11:12         ` Michael Walle
2023-04-12 12:19         ` Köry Maincent
2023-05-11 20:36     ` Vladimir Oltean
2023-05-11 20:50       ` Andrew Lunn
2023-05-11 20:55         ` Russell King (Oracle)
2023-05-11 21:02           ` Vladimir Oltean
2023-05-11 22:09             ` Jakub Kicinski [this message]
2023-05-11 23:07               ` Vladimir Oltean
2023-05-11 23:16                 ` Jakub Kicinski
2023-05-12 10:29                   ` Vladimir Oltean
2023-05-12 17:38                     ` Jakub Kicinski
2023-05-17 19:19                       ` Jakub Kicinski
2023-05-17 19:46                         ` Andrew Lunn
2023-05-17 20:07                           ` Jakub Kicinski
2023-09-04 15:22                             ` Köry Maincent
2023-09-04 17:47                               ` Richard Cochran
2023-09-05 18:47                                 ` Jakub Kicinski
2023-09-05 20:29                                   ` Andrew Lunn
2023-09-06  9:22                                     ` Köry Maincent
2023-09-07  9:29                                     ` Russell King (Oracle)
2023-05-19 13:28                       ` Vladimir Oltean
2023-05-19 20:22                         ` Jakub Kicinski
2023-05-22  3:56                           ` Zulkifli, Muhammad Husaini
2023-05-22 20:04                             ` Richard Cochran
2023-05-22 20:21                               ` Jakub Kicinski
2023-05-23  3:54                                 ` Richard Cochran
2023-05-17 22:01                   ` Jacob Keller
2023-05-17 22:13     ` Jacob Keller
2023-05-17 22:46       ` Richard Cochran
2023-05-18 23:23         ` Jacob Keller
2023-05-19 12:50           ` Andrew Lunn
2023-05-19 13:50             ` Richard Cochran
2023-05-19 15:18               ` Andrew Lunn
2023-04-08 14:06   ` Richard Cochran
2023-04-06 17:33 ` [PATCH net-next RFC v4 3/5] dt-bindings: net: phy: add timestamp preferred choice property Köry Maincent
2023-04-12 13:14   ` Vladimir Oltean
2023-04-12 13:44     ` Köry Maincent
2023-04-29 17:42       ` Vladimir Oltean
2023-05-02  9:10         ` Köry Maincent
2023-05-11 13:10           ` Vladimir Oltean
2023-05-11 13:25             ` Köry Maincent
2023-05-11 13:56               ` Vladimir Oltean
2023-05-11 14:22                 ` Köry Maincent
2023-04-12 14:14   ` Krzysztof Kozlowski
2023-04-06 17:33 ` [PATCH net-next RFC v4 4/5] net: Let the active time stamping layer be selectable Köry Maincent
2023-04-07  1:47   ` Jakub Kicinski
2023-04-29 17:58   ` Vladimir Oltean
2023-05-02 11:05     ` Köry Maincent
2023-05-11 13:48       ` Vladimir Oltean
2023-05-11 15:36         ` Jakub Kicinski
2023-05-11 15:56           ` Vladimir Oltean
2023-05-11 16:25             ` Jakub Kicinski
2023-05-11 20:54               ` Vladimir Oltean
2023-05-11 23:08                 ` Jakub Kicinski
2023-05-11 23:18                   ` Vladimir Oltean
2023-05-11 23:35                     ` Jakub Kicinski
2023-05-15  9:04                       ` Köry Maincent
2023-05-16 19:28                         ` Jakub Kicinski
2023-05-11 21:06               ` Russell King (Oracle)
2023-05-11 22:54                 ` Jakub Kicinski
2023-05-17 22:19               ` Jacob Keller
2023-04-06 17:33 ` [PATCH net-next RFC v4 5/5] net: fix up drivers WRT phy time stamping Köry Maincent
2023-04-06 17:59 ` [PATCH net-next RFC v4 0/5] net: Make MAC/PHY time stamping selectable Köry Maincent

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=20230511150902.57d9a437@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=gerhard@engleder-embedded.com \
    --cc=glipus@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vadim.fedorenko@linux.dev \
    --cc=vladimir.oltean@nxp.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).