On 7/20/2020 3:13 PM, Vladimir Oltean wrote:> > Yes, indeed, a lot of them are exclusively checking > "skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS", without any further > verification that they have hardware timestamping enabled in the first > place, a lot more than I remembered. Some of the occurrences are > actually new. > > 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. 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. > > What I've been trying to do is at least try to get people (especially > people who have a lot of XP with 1588 drivers) to agree on a common set > of guidelines that are explicitly written down. I think that's step #1. > > -Vladimir > Right. I think the guideline should be: This flag indicates to the stack whether or not a hardware Tx timestamp has been started. It's primary purpose is to prevent sending software timestamps if a hw timestamp is provided. 1) set the flag whenever you start a tx timestamp 2) do not assume you are the only driver that will set the flag for a given skb. Use a separate mechanism to decide if that skb is supposed to have a timestamp.
