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
