From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from www2881.sakura.ne.jp (www2881.sakura.ne.jp [49.212.198.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 308C0377ECD for ; Thu, 30 Apr 2026 06:52:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=49.212.198.91 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777531972; cv=none; b=DGTn5gDE375X3RsIa0eBvF0agqTed54eRVgw/GNPDmZBGxnOusk450EieZg/EVq/eytPHCH1iMRyA8agdHR4dBHKBn2M3FC1dLmszuefd1uHeAr+VyA4NpAlL0NAHeP5dIdqKd3//tW0Sv6Trb/QZ4gqOgHkXkbfUY3OUyhOdME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777531972; c=relaxed/simple; bh=HdZTeVEOnlll/V0J+Es7BGEsIH0paVJMwW0tqmHdEVE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ANny07CrKoSR5hL4JfluftuUnRnb+w9TtjhAvB3rlnzR9cswqgetaenZK+jzZlAdutl7oEN/w9LSng21QslD3h9G/Ri7NeQZZOaZdqw9jSq40rglMPzxWg1KBQ3J2g+7mJU2iqa4Bh9NxT0Q9NHmGs9VnfmmasalfXts+h/UySs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enjuk.jp; spf=pass smtp.mailfrom=enjuk.jp; dkim=pass (2048-bit key) header.d=enjuk.jp header.i=@enjuk.jp header.b=ixdwmzeH; arc=none smtp.client-ip=49.212.198.91 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=enjuk.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=enjuk.jp Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=enjuk.jp header.i=@enjuk.jp header.b="ixdwmzeH" Received: from x1 (197.87.13.160.dy.iij4u.or.jp [160.13.87.197]) (authenticated bits=0) by www2881.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 63U6qlWY016759 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Apr 2026 15:52:49 +0900 (JST) (envelope-from kohei@enjuk.jp) DKIM-Signature: a=rsa-sha256; bh=ga//PkVdVcOc+iQouQF6R8qn8+tGcT2W6yixW1flLbM=; c=relaxed/relaxed; d=enjuk.jp; h=From:Message-ID:To:Subject:Date; s=rs20251215; t=1777531969; v=1; b=ixdwmzeHhgz0TVFzCdl3Cj+DzOCMvxOFSKSTNlJgj/az33/93ZRhWCKbPHshF4cv oE5TU3LV0L1jSquHHLK528bfFsbopl61sMvHT7omwLe5XeN6fqBHpHOQH2OOcm8l CbdqrUsh2Gl3X7DbUMq3T2NdMiBt9l5MCqriVSkYauZTSND0N6D8264xWoTAnWUX UHd8NmDHBpkAUFXZkFkdR+58pSC5tKLXRSIABCNtMSUzHYDxs0KNVnvvjXyNe+Pd y6ULkijAUITu9KD7EIUxUKzEaC4JHpc7AlLlEgrmelAwOcBEArsm787NNFsGNS38 4dI2ZnDkQvOq1C3eo7d6tw== Date: Thu, 30 Apr 2026 15:52:47 +0900 From: Kohei Enju To: Eric Dumazet Cc: Willem de Bruijn , netdev@vger.kernel.org, "David S. Miller" , Jakub Kicinski , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , David Ahern , Neal Cardwell , Gerhard Engleder , Jonathan Lemon , Richard Cochran Subject: Re: [PATCH net v1 3/3] tcp: use skb_get_hwtstamp() for hardware timestamps Message-ID: References: <20260429091632.26509-1-kohei@enjuk.jp> <20260429091632.26509-4-kohei@enjuk.jp> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 04/29 23:09, Eric Dumazet wrote: > On Wed, Apr 29, 2026 at 10:07 PM Kohei Enju 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.