Linux-Doc Archive on
 help / color / Atom feed
From: Vladimir Oltean <>
To: Richard Cochran <>
Cc: Jacob Keller <>,,,,,
Subject: Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set of frequently asked questions
Date: Tue, 21 Jul 2020 22:51:27 +0300
Message-ID: <20200721195127.nxuxg6ef2h6cs3wj@skbuf> (raw)
In-Reply-To: <20200721002150.GB21585@hoboy>

On Mon, Jul 20, 2020 at 05:21:50PM -0700, Richard Cochran wrote:
> On Tue, Jul 21, 2020 at 01:13:14AM +0300, Vladimir Oltean wrote:
> > I think at least part of the reason why this keeps going on is that
> > there aren't any hard and fast rules that say you shouldn't do it. When
> > there isn't even a convincing percentage of DSA/PHY drivers that do set
> > SKBTX_HW_TSTAMP, the chances are pretty low that you'll get a stacked
> > PHC driver that sets the flag, plus a MAC driver that checks for it
> > incorrectly. So people tend to ignore this case.
> Right.
> > Even though, if stacked
> > DSA drivers started supporting software TX timestamping (which is not
> > unlikely, given the fact that this would also give you compatibility
> > with PHY timestamping), I'm sure things would change, because more
> > people would become aware of the issue once mv88e6xxx starts getting
> > affected.
> I really can't see the utility in having a SW time stamp from a DSA
> interface.  The whole point of DSA time stamping is to get the ingress
> and egress time of frames on the external ports, in order to correct
> for the residence time within the switch.
> Thanks,
> Richard

I understand where this is coming from. The DSA software data path is
the mirror image of the hardware data path: first the net device
corresponding to the switch port, then the net device corresponding to
the host port, then the physical host port, then the physical switch
port. So, just as hardware timestamping makes the most sense on the
outermost PHC, software timestamping makes the most sense on the
innermost driver, the last frontier before the packet leaves software
hands. That is clear.

But I feel that going as far as saying that 'DSA shouldn't set
SKBTX_IN_PROGRESS because it already offers hardware timestamping' is
wrong. A software timestamp provided by a DSA net device is just as
valuable (or not, depending on your needs) as a software timestamp
provided by any other net device. For example, to the people doing TCP
time stamping, this software timestamp is just 'the driver timestamp',
so it makes perfect sense to have it just where it is: in DSA. Not only
that, but we shouldn't completely rule out the idea of software TX
timestamps in DSA _and_ in the host interface for the same packet,
either, since that could form the basis for some nice benchmarking.

Not only that, but with PHY timestamping, one popular way of handling TX
hardware timestamps from a PHY is to call skb_tx_timestamp(). It is
nonsense to me, and counterproductive, to end up having that in the
code, but not claim SOF_TIMESTAMPING_TX_SOFTWARE support. And PHY
timestamping with DSA is not a contradiction in terms by any means,
on the contrary, it makes just as much sense as PHY timestamping in

So I think the position of "just don't have software timestamping code
in DSA and you'll be fine" won't be getting us anywhere. Either you can
or you can't, and there isn't anything absurd about it, so sooner or
later somebody will want to do it. The rules surrounding it, however,
are far from being ready, or clear.

Am I missing something?


  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 16:10 [PATCH net-next 0/3] Document more PTP timestamping known quirks Vladimir Oltean
2020-07-17 16:10 ` [PATCH net-next 1/3] docs: networking: timestamping: rename last section to "Known bugs" Vladimir Oltean
2020-07-17 22:05   ` Jacob Keller
2020-07-17 16:10 ` [PATCH net-next 2/3] docs: networking: timestamping: add one more known issue Vladimir Oltean
2020-07-17 23:08   ` Jacob Keller
2020-07-18 11:36     ` Vladimir Oltean
2020-07-17 16:10 ` [PATCH net-next 3/3] docs: networking: timestamping: add a set of frequently asked questions Vladimir Oltean
2020-07-17 23:12   ` Jacob Keller
2020-07-18 11:35     ` Vladimir Oltean
2020-07-20 18:54       ` Jacob Keller
2020-07-20 21:05         ` Vladimir Oltean
2020-07-20 21:45           ` Jacob Keller
2020-07-20 22:13             ` Vladimir Oltean
2020-07-21  0:21               ` Richard Cochran
2020-07-21 19:51                 ` Vladimir Oltean [this message]
2020-07-22  3:25                   ` Richard Cochran
2020-07-25 21:32                     ` Vladimir Oltean
2020-07-21 17:16               ` Jacob Keller
2020-07-21  0:15           ` Richard Cochran
2020-07-17 21:13 ` [PATCH net-next 0/3] Document more PTP timestamping known quirks Sergey Organov
2020-07-17 21:57   ` Vladimir Oltean
2020-07-17 23:13     ` Jacob Keller
2020-07-18 10:54     ` Sergey Organov
2020-07-18 11:30       ` Vladimir Oltean
2020-07-18 13:35         ` Sergey Organov
2020-07-18 11:21 ` Sergey Organov

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:

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

  git send-email \
    --in-reply-to=20200721195127.nxuxg6ef2h6cs3wj@skbuf \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Doc Archive on

Archives are clonable:
	git clone --mirror linux-doc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-doc linux-doc/ \
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone