From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.222.43 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794328467; b=aMmlc1slWwz9BjjVbR8ntcfDR8bO0zg/pwTbg7zWVaDsBHd+dHrxg4b5t6iJa8p/dgNV +hptVy/viAxd4lyJZbzkC2Sd6jE7V2F1aTajt6U8WUG/uMjL4m1XX+FkXuboWzqfWR6lB h6V+T7luSsaxO2a2NKjgn25hNLywyOclyTWYwqC0SdiIT32EY9EoUrS2c2Lqskd3Y3Kb3 BIyhZhI2E7teGV1sbAhiTdnhW99dae8Y09piKMh9yt11uZnVA3WVghnPXLXtBE+miv/4v OIjk+BXDjzSqxN3iQeuMRsc7Z51oizvBLYuljLvJltTYYFwZ7uLlCypUJwXgPZ89ipA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794328467; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=y+V2JxIlVOChITFgo1z9lTreH4E5kp3RpfFu+UewLVo=; b=l2HSmJdyXEdQxQslpMDMIMH0y5m46yBeHXQP9ULwnak+s3kGYtlm8Xs/Hid2pWM8b3bW Gb+6YtBZzEBBiM6bjs7RjRj8H0PCjCgm8qjLuUtmuP5ceZowU8EzsgOWJ+HEkakD/Vx7B P+fJXNJcpTI9nYhRwCdwcCaY3dQZU0EA8khdIuaftOivTdpfPxnenFYg9ZYPf4d/SLZrJ HwRr8zbJguTe1bYlzzaYN7CaPLEpWMHUOLfj8MEdQnIPZD4ji5h83k0RS1fa8ZorLBkjU 4MFybolv56L4jw3vS/SDvZaHgr6cEM44Gl6y2tY5ptGVnTuf7m9hSmf7/8W2HWcirwA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=fSy8tcC5; arc=none smtp.remote-ip=209.85.222.43 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57542606A8A3 for ; Tue, 10 Nov 2026 16:34:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 57542606A8A3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=fSy8tcC5 Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-98c7798ce74so590879241.1 for ; Tue, 10 Nov 2026 08:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794328466; x=1794933266; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=y+V2JxIlVOChITFgo1z9lTreH4E5kp3RpfFu+UewLVo=; b=fSy8tcC5IqRPJ8T9YRj22z1qFAkPgpRi2kcT3apWfgMEplaE1W0onrcdvaL/BL/ywE rOSS0ydfaat3r8gteyf5+yftpLD+2I78ebj6isd5tSmAO9uXKA6drfZE2fPbEDLgB8tv 4nj5eU6BbFuMME+jx7QiJhMbdOwnH56XkB3/HT/fr1ZGQooLEtuVaD6KLZUnJ4xbTN5H VkTk3pY/yOZ/w9fPvBKK5wNUDrb1f6zcpKrwD0C4hM87Oys5nnQ81EVXkI7GaiyDb9rK 5iOj/aarsL/qQFbE1WK3Ho0Kl6BxOfVqScOWNlF4Xqlcyi87wAdVUnIdMg2NDVulzXnv hkjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794328466; x=1794933266; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=y+V2JxIlVOChITFgo1z9lTreH4E5kp3RpfFu+UewLVo=; b=ntBayhDHiu8kMrmwFTr3EjXY1RuuiLorps77e6EzbZeLse94CHXm9KgL45v/Qk/5e7 tn+A0mxzD94BIK7O91uPiP89OJ1NbnJ2GI+YPgnxHbntfoT95oSZTDknqHLrEdoPlG6/ /j/uJfCt0S+eCp9dcKjBz9M94QzDgRe11XI9zwH3bqLm3yDdCqa2B8Z22WFHLMgLpTOL thE2BQryMDgE2wZgj4Stvs/uLJetqs7YJcV26JHn/CbBPx6ncviDGyOzAlmTujZ8v4cu S+bcatko3YD4ssZQo6vR/+4isO8w4GUwhn/xTg2M9zt6MxmrKWu8YZhX4Nag7B25/adJ e8Yw== X-Forwarded-Encrypted: i=1; AL+hErGz7GEAlYYI4RClPCS/Cp9rHTErrhfXSRnuEyWglhSth4Y/0qrJBYHHnnhwTRYS9VotyDtlZv81gLcnLEw=@vger.kernel.org X-Gm-Message-State: APuU4Z8Vinn+Dh+ExmVO8LQPg7PxuZmdqsPb/KAUvF2F9lM1hBudmreg Gy7xQ9OWz70b/Wbr4MZv4MPk17JERpk0NMkR4cNEGHrZRSKnFeas0SGb X-Gm-Gg: AYBFou3MQIijMurr2zONIK9z7CJu2AfNjalmtKJv4kiyhD/8WIUd9B+i6eNMrS+R9lJ LM5infP+A5szsch+yXz64DUwL2i2Drid5FfBYzmPEEysCgYMdda5mhsLTXKAp/DOe5SgvStSfZ4 QVITrnQ9ktO136Zc12YtnfNXYPnaTonmo9EbPez7cmxqXYgHmU+3ZfooPiUiYHEjOIrJkAlqFoH C/yFLbcVr20GXlooHmZnUfKRx6oX9Q/VSNv4psROXgygO7OsUAUqtml/SkvbO2/ojY/A11+6jit QnfxLLctwcCU0quTPr+UryGnKO9zN02/48qPtkm7DRA8AHqyLoI/5eQ6DhJ2tCbO8f6WhCoKroc v0kl2Wxsqt5rDnkKys5fWyETZH/p2zLtpDoYWdC/zBK8WTvHYJfKBGi3GtvcpSks4SqpWpAdUq5 JenadsE2uW/36hkMk8fSLjjcn70BKN+2Tm15+3nP7dEsW1IfnjSTZCgclli91MD6/qJLIrdLAm8 ximv+k9QF2Udo7q49Bpb32MgLXKARYW+vO0qGL8/gzIAP+sGqkKA6QKXM/xyXbe7eg0awL5GFnH 3SakZoVJTr2czzdjTik8UQYk/jtfSaNKWFUV0CxbVHJli1RftQKRSRjjBhtJXdjXq521JtccuP+ H8nB8c55bZUfgIncNZ5igQ9vc98G6mAJjwrWG+vRIuG8XZwh25bzlgMmQzQmWhkV3d3CkgXqTDZ dS0cqal7znaZ2WbFyU X-Received: by 2002:a05:6102:c54:b0:7b5:7cd5:2a1b with SMTP id ada2fe7eead31-7d301b9d79fmr866580137.10.1794328466169; Tue, 10 Nov 2026 08:34:26 -0800 (PST) Received: from gmail.com (223.230.150.34.bc.googleusercontent.com. [34.150.230.223]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-99c200838f0sm2147394241.9.2026.11.10.08.34.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2026 08:34:25 -0800 (PST) Date: Tue, 10 Nov 2026 11:34:25 -0500 From: Willem de Bruijn To: Steffen Trumtrar , Willem de Bruijn , kuba@kernel.org Cc: "Michael S. Tsirkin" , Xuan Zhuo , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Richard Cochran , Andrew Lunn , =?UTF-8?B?RXVnZW5pbyBQw6lyZXo=?= , Jason Wang , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Eric Dumazet , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, kvm@vger.kernel.org, namangulati@google.com Message-ID: In-Reply-To: <874ido29iy.fsf@pengutronix.de> References: <20261026-v6-7-topic-virtio-net-ptp-v4-0-008af03cd43b@pengutronix.de> <874ido29iy.fsf@pengutronix.de> Subject: Re: [PATCH RFC v4 0/6] virtio-net: add receive timestamp support X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Steffen Trumtrar wrote: > > Hi Willem, > > On 2026-11-01 at 09:57 -05, Willem de Bruijn wrote: > > > Steffen Trumtrar wrote: > > > This series picks up Willem de Bruijn's work on a virtio-net receive > > > timestamp. The device puts the time of arrival (TAI, ns) into the > > > virtio-net header so the guest can use it for PTP and RTT estimation > > > without taking the timestamp itself after the host-to-guest latency. > > > > > > The series is an RFC. I am mostly interested in feedback on the > > > approach and on the wire format: > > > > At a high level +1 from me. > > Thanks! > > > > > Some comments inline. > > > > > > - The timestamp is a new field at the end of virtio_net_common_hdr > > > after outer_nh_offset and ipsec, offset 32 (see virtio spec), > > > negotiated with VIRTIO_NET_F_RX_TSTAMP (bit 49). Header size now 40 > > > bytes. > > > Willem noted on v3 that virtio_net_common_hdr was not meant to be > > > extended this way; I kept it as the simplest approach, but a > > > separate struct for the timestamp header is an option. > > > - Timestamping is enabled at runtime with SIOCSHWTSTAMP; all > > > supported rx filters behave the same for now. > > > - XDP programs can read the timestamp with > > > bpf_xdp_metadata_rx_timestamp(). > > > - vhost-net passes the feature through; the timestamp itself is > > > written by tun. The tun patch is only meant as a reference > > > implementation for the device side. > > > - The timestamp is in TAI. > > > > Is this a requirement? It is common for PHCs to be synced to TAI, > > but not 100% the case. Does virtio need to specify this. > > > > No, I don't think it has to be TAI. TAI is only what the tun reference > implementation does (ktime_get_clocktai_ns()). What the guest really > needs is to know which clock the timestamp comes from, so it can compare > it with something. > > One idea for the spec change: don't fix the time base in virtio-net at > all, only say the timestamp is in nanoseconds of some device clock, and > let the device tell the driver which clock that is. virtio_rtc already > has clock ids with a type (UTC, TAI, monotonic, ...), and the Linux > driver registers a PHC for each of them (with VIRTIO_RTC_PTP). > virtio-net could carry the virtio_rtc clock id in its config space, and > the driver reports the index of that PHC in get_ts_info. That would also > fix the phc_index == -1 problem you pointed out in 2/6. > > What I don't like about it: virtio-net then depends on a second device > being there, and with more than one virtio_rtc device the clock id alone > is not enough to find the right one. Without virtio_rtc the driver would > not offer hardware timestamps at all. > > The alternative is a PHC in virtio-net itself (gettime over the control > vq), which is a lot more spec for one timestamp field. > > Do you think the virtio_rtc way is reasonable, or is there something > simpler I'm missing? I don't have an obvious answer. This needs consensus. Hardcoding clock base to TAI is definitely easiest. Outside of virtio, the relationship between PHY RX timestamps and PHC is well understood. It would make some sense for virtio to follow that model. But indeed when having multiple NICs and multiple PHCs, how to map them I think is an unresolved issue in general? Of course, aslo moot if they are all synced, which I think may be an implicit assumption especially in the world of spec compliant PTP. And, if virtualizing anyway, it is feasible to do the clock conversion in the software device, not having to bother with all this complexity inside the VM. Though maybe not for direct HW virtio-net queues.