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

[Jason Wang <jasowang@redhat.com>]

On Tue, Nov 11, 2025 at 12:10 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> 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 <mst@redhat.com> 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 <mst@redhat.com> 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 <xuanzhuo@linux.alibaba.com> 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.

Yes, this is exactly what I meant.

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

+1.

Thanks

>
>
> > >
> > > --
> > > MST
> > >
>