From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f51.google.com (mail-yx1-f51.google.com [74.125.224.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69118387598 for ; Mon, 2 Feb 2026 17:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054039; cv=none; b=eavWVYAzZNWDoUx+9xc2U0qWza9O+DnYORbcLWv5C//DSxedKlzTgtqM96GR0eRvmjbyVt/6G7AYMXXaxvx/nWISWgaLt7cIc/7nqJF/oJfcf85c2HJAPxpk9mKeW0Etdo8SxGOBz+JRoxoDgCikq17+/NUB3T+BwUGdOdMU2YE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054039; c=relaxed/simple; bh=VRCx+c4hexJbmDKx+kICIYWJ1xdiJDc4rP2eOiSEuIU=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=RetnnxWiijBWrseZxt8GhVznr/FBLci/pRUMXVM26R/+FqZDMFGR6osgd2UFLw/gZZ3jkPGDZA9Rc8H4yxHFMhRrX2nVFRMxLujO0IIIJw2qGoB76h7PIwmwZEzec25j2/fo+XC7dYssVT+N0t8EeA5rfoeTvKTY9ZwvLPeHofw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G9l/AZ01; arc=none smtp.client-ip=74.125.224.51 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.b="G9l/AZ01" Received: by mail-yx1-f51.google.com with SMTP id 956f58d0204a3-649b383919bso1952756d50.1 for ; Mon, 02 Feb 2026 09:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770054037; x=1770658837; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Lr0owY/HcJsxUU3YNVxCg49UjG1nqp/rA/XqNsApWS4=; b=G9l/AZ01uvaKzqM0spB9OptqzXa+8ThWKUTl5XOLCsTKZYifw/CugJmz18t52q9IGT B4KlSCY6qw9cx19sI4qLYLzUnRpbcCf5FgVA1ZTYbVWXNiwSNog/kRZiCyvxeEadtzbf YOTB5svihQLMBD+ufSXOjEIzp8rrmWFO/sAFCOstqIw6a3/vyMzw2jJtMf+oDqoIe/zU gPn7QaigeC6bjXJhRo6CmNjg7undpOmZG/+JicmFTXn77FRYtT9AvcKT3Ybpl4DYPK9W vd75XpSrsZudDOE9SFTITzzwIEXyfw7juZr9XW6nNiaGVuiyqnNPYB3g4V684mJpTQtx X6ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770054037; x=1770658837; h=content-transfer-encoding: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; bh=Lr0owY/HcJsxUU3YNVxCg49UjG1nqp/rA/XqNsApWS4=; b=ePHMBldsSXwrD5rDJQajE5gC5wo3dfTh/eELjxMXNbpSnoC+8h6EtbtAg8neuavOkD Bm5Nl8XIoqAi/s0kh5HbXtHMc+KtjHQQXqjrY83uDv1mL7YAQU7UQeF/Kdbx5wDs/O2e iXtYAMD8c80OXhHv/VNSQ2qi/Q9SH6pcm+ZDJLKgNirwEujX0i74GjynjKv/3BpXffnC SAuYnv1YMl3wFswlslFo3giZ1bllIwqDqy6WC772r+vPFQb2p5CPAWLToNxUCMufG6XK DLcJ0A1tNOY8aiNZKY/8mMvg6Rn5kLFr34zKC0a67wraGdxRzohSFV9WYwhRMJGWSjYz BdiQ== X-Forwarded-Encrypted: i=1; AJvYcCUfBZBY2JQS69vbk0HW5u/kKgJYeMGKbqi3bGB3RltYW3//fZ7k3aZQ46GdDNZrcHgXepUPvN4MqjJ61LI=@vger.kernel.org X-Gm-Message-State: AOJu0YzeoTz9a4Aej7cxOSHmDenbe6GCRGBIDRomtej0Az/KK7tnJO0+ PB3JHoLgQz1zURcg5TY1+In81vAIdCyQL4oJC0sxTsUINgTQk5vWgoJr X-Gm-Gg: AZuq6aJzEVuYzz2DQYPWUWHziI+LB/PCnfwTkIT9cSWbyEl7VdpWc2HiwUTJyJ20+Nv 5bW33GM6c9gzZnvZmtUujPjpJHRTzJfuOOyEp23Gv6Rtzmug0oqIGKNqb5JTjw+JeH7V6tTY9iK szZ1Oih/x/dZ3rG4P9WDTGsB9GwSnPUkZtBqSwpBNCk079PSAUEhDqO3qvICe1Cghxbhij0IXWp /PWtHXvR0o6f6QvwXyz6XEAVaWcqDsV19zFkctevQoM+IK4Ufu/ibz21cQ03F9ig5mRGSXcCJHq vC+8SUOVEoFXuXB8jb4GFOZE/CCfxU8ljNxGjNbxW4q+bSxJ4oskfmm9Ua+lQ+dVtsvoh17Faov s97wX1d8lLkGLpErC8Rh1SKGlUbiKipndotACrAZm9AhXwx9mSGBcO8RcyujAhtmwdbMpj6pGvF yEcN6mGFB0t4yDec3gTV82KhUmlqKWIw1h89YpHryf7LexC2+mxBNr0YWNueE= X-Received: by 2002:a05:690e:c49:b0:649:66c5:74ec with SMTP id 956f58d0204a3-649a849ef90mr9532381d50.56.1770054037437; Mon, 02 Feb 2026 09:40:37 -0800 (PST) Received: from gmail.com (21.33.48.34.bc.googleusercontent.com. [34.48.33.21]) by smtp.gmail.com with UTF8SMTPSA id 956f58d0204a3-64996063a24sm9718869d50.5.2026.02.02.09.40.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 09:40:36 -0800 (PST) Date: Mon, 02 Feb 2026 12:40:36 -0500 From: Willem de Bruijn To: "Michael S. Tsirkin" , Willem de Bruijn Cc: Steffen Trumtrar , Jason Wang , Xuan Zhuo , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Andrew Lunn , =?UTF-8?B?RXVnZW5pbyBQw6lyZXo=?= , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: <20260202025322-mutt-send-email-mst@kernel.org> References: <20260129-v6-7-topic-virtio-net-ptp-v2-0-30a27dc52760@pengutronix.de> <20260129-v6-7-topic-virtio-net-ptp-v2-2-30a27dc52760@pengutronix.de> <20260202025322-mutt-send-email-mst@kernel.org> Subject: Re: [PATCH RFC v2 2/2] virtio-net: support receive timestamp Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Michael S. Tsirkin wrote: > On Sun, Feb 01, 2026 at 04:05:54PM -0500, Willem de Bruijn wrote: > > Steffen Trumtrar wrote: > > > Add optional hardware rx timestamp offload for virtio-net. > > > > > > Introduce virtio feature VIRTIO_NET_F_TSTAMP. If negotiated, the > > > virtio-net header is expanded with room for a timestamp. > > > > > > To get and set the hwtstamp the functions ndo_hwtstamp_set/get need > > > to be implemented. This allows filtering the packets and only time stamp > > > the packets where the filter matches. This way, the timestamping can > > > be en/disabled at runtime. > > > > > > Tested: > > > guest: ./timestamping eth0 \ > > > SOF_TIMESTAMPING_RAW_HARDWARE \ > > > SOF_TIMESTAMPING_RX_HARDWARE > > > host: nc -4 -u 192.168.1.1 319 > > > > > > Signed-off-by: Steffen Trumtrar > > > @@ -475,6 +478,8 @@ struct virtnet_info { > > > > > > struct control_buf *ctrl; > > > > > > + struct kernel_hwtstamp_config tstamp_config; > > > + > > > /* Ethtool settings */ > > > u8 duplex; > > > u32 speed; > > > @@ -511,6 +516,7 @@ struct virtio_net_common_hdr { > > > struct virtio_net_hdr_mrg_rxbuf mrg_hdr; > > > struct virtio_net_hdr_v1_hash hash_v1_hdr; > > > struct virtio_net_hdr_v1_hash_tunnel tnl_hdr; > > > + struct virtio_net_hdr_v1_hash_tunnel_ts ts_hdr; > > > > Jason, Michael: creating a new struct for every field is not very > > elegant. Is it time to find a more forward looking approach to > > expanding with new fields? Like a TLV, or how netlink structs like > > tcp_info are extended with support for legacy users that only use > > a truncated struct? > > I certainly wouldn't mind, though I suspect tlv is too complex as > hardware implementations can't efficiently follow linked lists. I'll > try to ping some hardware designers for what works well for offloads. Great thanks. Agreed that TLV was probably the wrong suggestion. We can definitely have a required order of fields. My initial thought is as said like many user/kernel structures: where both sides agree on the basic order of the struct, and pass along the length, so that they agree only to process the min of both their supported lengths. New fields are added at the tail of the struct. See for instance getsockopt TCP_INFO.