Message-ID: <20200721195127.nxuxg6ef2h6cs3wj@skbuf>
Date:   Tue, 21 Jul 2020 22:51:27 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Jacob Keller <jacob.e.keller@...el.com>, kuba@...nel.org,
        davem@...emloft.net, netdev@...r.kernel.org, sorganov@...il.com,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set
 of frequently asked questions

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
general.

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?

Thanks,
-Vladimir

Powered by blists - more mailing lists