[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACGkMEsqobRMhtz3LUuWu3O1njK9jU7oQ65OOyy9vHcZ_QLz4A@mail.gmail.com>
Date: Tue, 3 Feb 2026 11:24:13 +0800
From: Jason Wang <jasowang@...hat.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Steffen Trumtrar <s.trumtrar@...gutronix.de>, "Michael S. Tsirkin" <mst@...hat.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Richard Cochran <richardcochran@...il.com>, Andrew Lunn <andrew+netdev@...n.ch>,
Eugenio Pérez <eperezma@...hat.com>,
virtualization@...ts.linux.dev, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC v2 2/2] virtio-net: support receive timestamp
On Mon, Feb 2, 2026 at 5:06 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> 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 <s.trumtrar@...gutronix.de>
> >
> > --
> > Changes to last version:
> > - rework series to use flow filters
> > - add new struct virtio_net_hdr_v1_hash_tunnel_ts
> > - original work done by: Willem de Bruijn <willemb@...gle.com>
> > ---
> > drivers/net/virtio_net.c | 136 ++++++++++++++++++++++++++++++++++++----
> > include/uapi/linux/virtio_net.h | 9 +++
> > 2 files changed, 133 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 1bb3aeca66c6e..4e8d9b20c1b34 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -429,6 +429,9 @@ struct virtnet_info {
> > struct virtio_net_rss_config_trailer rss_trailer;
> > u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
> >
> > + /* Device passes time stamps from the driver */
> > + bool has_tstamp;
> > +
> > /* Has control virtqueue */
> > bool has_cvq;
> >
> > @@ -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 fully agree, we need somebody to work on this.
Thanks
Powered by blists - more mailing lists