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.
next prev parent reply other threads:[~2023-05-11 23:16 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
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-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=20230511161625.2e3f0161@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=andrew@lunn$(echo .)ch \
--cc=gerhard@engleder-embedded$(echo .)com \
--cc=glipus@gmail$(echo .)com \
--cc=kory.maincent@bootlin$(echo .)com \
--cc=krzysztof.kozlowski+dt@linaro$(echo .)org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=maxime.chevallier@bootlin$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=richardcochran@gmail$(echo .)com \
--cc=robh+dt@kernel$(echo .)org \
--cc=thomas.petazzoni@bootlin$(echo .)com \
--cc=vadim.fedorenko@linux$(echo .)dev \
--cc=vladimir.oltean@nxp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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