Re: [PATCH net v1 3/3] tcp: use skb_get_hwtstamp() for hardware timestamps

[Kohei Enju <kohei@enjuk.jp>]

On 04/29 23:09, Eric Dumazet wrote:
> On Wed, Apr 29, 2026 at 10:07 PM Kohei Enju <kohei@enjuk.jp> wrote:
> >
> > On 04/29 17:09, Willem de Bruijn wrote:
> > > Kohei Enju wrote:
> > > > Since commit 97dc7cd92ac6 ("ptp: Support late timestamp determination"),
> > > > skb_shared_hwtstamps may contain netdev_data instead of hwtstamp. TCP
> > > > receive timestamping can then interpret the stored value as a ktime_t
> > > > and report bogus hardware timestamps to userspace.
> > > >
> > > > Use skb_get_hwtstamp() instead of reading hwtstamp directly, so TCP
> > > > sockets follow the same hardware timestamp resolution path as the socket
> > > > layer. When coalescing SKBs, resolve late timestamps before copying them
> > > > to the merged skb.
> > >
> > > Why? Does this preclude supporting SOF_TIMESTAMPING_BIND_PHC for such
> > > sockets at a later time?
> >
> > You're right. If we want to keep the door open for
> > SOF_TIMESTAMPING_BIND_PHC on coalesced skbs, resolving the timestamp at
> > coalescing time is the wrong approach.
> >
> > >
> > > It is just as easy to coalesce the cookie as the htwtstamp.
> > >
> > > That also avoids the need to mask out SKBTX_HW_TSTAMP_NETDEV.
> >
> > Indeed. We should also carry the matching @napi_id, since
> > skb_get_hwtstamp() uses it for late resolution.
> >
> > I'll update this in v2.
> 
> Do you plan adding a selftest ?
> 
> I am confused by your series, a test would really help clarify the
> issue at hand.

Yes, I agree a selftest would help.

Since this issue is only triggered with drivers that use late RX
timestamp determination (SKBTX_HW_TSTAMP_NETDEV / ndo_get_tstamp), it
would likely need to live under tools/testing/selftests/drivers/net/hw/
rather than as a generic net selftest. I'm looking into whether I can
add such a test.

Either way, I'll expand the cover letter to explain the issue in more
detail. Sorry for the confusion.