Re: [PATCH RFC v2 2/2] virtio-net: support receive timestamp

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

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 <s.trumtrar@pengutronix.de>

> > > @@ -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.