Subject: Re: [PATCH net v4 3/4] virtio-net: correct hdr_len handling for VIRTIO_NET_F_GUEST_HDRLEN

From: "Michael S. Tsirkin" <[email-masked]>
Date: Mon, 10 Nov 2025 11:10:43 -0500

On Mon, Nov 10, 2025 at 03:39:50PM +0800, Jason Wang wrote:
> On Mon, Nov 10, 2025 at 3:27 PM Michael S. Tsirkin <[email-masked]> wrote:
> >
> > On Mon, Nov 10, 2025 at 03:16:08PM +0800, Jason Wang wrote:
> > > On Mon, Nov 10, 2025 at 5:41 AM Michael S. Tsirkin <[email-masked]> wrote:
> > > >
> > > > On Thu, Oct 30, 2025 at 10:53:01AM +0800, Jason Wang wrote:
> > > > > On Wed, Oct 29, 2025 at 11:09 AM Xuan Zhuo <[email-masked]> wrote:
> > > > > >
> > > > > > The commit be50da3e9d4a ("net: virtio_net: implement exact header length
> > > > > > guest feature") introduces support for the VIRTIO_NET_F_GUEST_HDRLEN
> > > > > > feature in virtio-net.
> > > > > >
> > > > > > This feature requires virtio-net to set hdr_len to the actual header
> > > > > > length of the packet when transmitting, the number of
> > > > > > bytes from the start of the packet to the beginning of the
> > > > > > transport-layer payload.
> > > > > >
> > > > > > However, in practice, hdr_len was being set using skb_headlen(skb),
> > > > > > which is clearly incorrect. This commit fixes that issue.
> > > > >
> > > > > I still think it would be more safe to check the feature
> > > >
> > > > which feature VIRTIO_NET_F_GUEST_HDRLEN ?
> > > >
> > >
> > > Yes.
> > >
> > > Thanks
> >
> > Seems more conservative for sure, though an extra mode to maintain isn't
> > great. Hmm?
> 
> Considering it's not a lot of code, it might be worth it to reduce the risk.
> 
> But I'm fine if you think we can go with this patch.
> 
> Thanks

hard to say what does "not a lot of code" mean here.
but generally if VIRTIO_NET_F_GUEST_HDRLEN is not set
just doing a quick skb_headlen and not poking at
the transport things sounds like a win.

I'd like to at least see the patch along the lines you propose,
and we will judge if it's too much mess to support.

> > --
> > MST