[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200721002150.GB21585@hoboy>
Date: Mon, 20 Jul 2020 17:21:50 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Vladimir Oltean <olteanv@...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 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
Powered by blists - more mailing lists