All of lore.kernel.org
 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 16:16:25 -0700	[thread overview]
Message-ID: <20230511161625.2e3f0161@kernel.org> (raw)
In-Reply-To: <20230511230717.hg7gtrq5ppvuzmcx@skbuf>

On Fri, 12 May 2023 02:07:17 +0300 Vladimir Oltean wrote:
> On Thu, May 11, 2023 at 03:09:02PM -0700, Jakub Kicinski wrote:
> > 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.  
> 
> So if I add a call to ptp_clock_info :: gettimex64() where the
> skb_tx_timestamp() call is located in a driver, could that pass as
> a DMA timestamp?

Yes.

> The question is how much do we want to encourage these DMA timestamps:
> enough to make them a first-class citizen in the UAPI? Are users even
> happy with their existence?

I don't want to call anyone out, but multiple high speed devices
with the current, in tree drivers report DMA timestamps when you 
ask for HW timestamps. DMA stamps are still 2 orders of magnitude
better than SW stamping.

> I mean, I can't ignore the fact that there are NICs that can provide
> 2-step TX timestamps at line rate for all packets (not just PTP) for
> line rates exceeding 10G, in band with the descriptor in its TX
> completion queue. I don't want to give any names, just to point out
> that there isn't any inherent limitation in the technology.

Oh, you should tell me, maybe off-list then. 'Cause I don't know any.

> AFAIU from igc_ptp_tx_hwtstamp(), it's just that the igc DMA
> controller did not bother to transport the timestamps from the MAC
> back into the descriptor, leaving it up to software to do it out of
> band, which of course may cause correlation bugs and limits
> throughput. Surely they can do better.

It's not that simple. Any packet loss or diversion and you may end up
missing a completion.

  reply	other threads:[~2023-05-11 23:16 UTC|newest]

Thread overview: 79+ 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
2023-05-11 23:07               ` Vladimir Oltean
2023-05-11 23:16                 ` Jakub Kicinski [this message]
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-06 20:04   ` kernel test robot
2023-04-07  1:02   ` kernel test robot
2023-04-07  1:47   ` Jakub Kicinski
2023-04-07  2:04   ` kernel test robot
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=20230511161625.2e3f0161@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 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.