On Fri, Mar 20, 2026 at 10:18:16AM +0800, Xuan Zhuo wrote:
> v11:
>   1. rename virtio_net_set_hdrlen() to __virtio_net_set_hdrlen(),
>   virtio_net_set_tnl_hdrlen() to __virtio_net_set_tnl_hdrlen(), and add
>   explicitly mention in a comment that such functions must be invoked only 
> after
>   virtio_net_hdr_from_skb()
> 
> v10:
>   1. fix http://lore.kernel.org/all/[email protected]
> 
> v9:
>   1. Introduce new helpers to set hdr len, and virtio_net_hdr_tnl_from_skb
>   calls them directly.
> 
> v8:
>   1. move changes of virtio_net_hdr_from_skb for udp tunnel to #2
>   2. remove change for num_sg
> 
> v7:
>   1. fix bug reported by robot
>   2. Still splitting into two commits, as the issues fixed originate from
>      different commits. This separation makes it easier to selectively revert 
> to
>      previous versions.
> 
> v6:
>   1. rename to guest_hdrlen
>   2. introduce a function virtio_net_set_hdrlen to set the hdrlen
> 
> 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 path set fixes that issue.
> 
> As discussed in [0], this version checks the VIRTIO_NET_F_GUEST_HDRLEN is
> negotiated.
> 
> 
> [0]: 
> http://lore.kernel.org/all/[email protected]
> 



Acked-by: Michael S. Tsirkin <[email protected]>

> 
> 
> 
> 
> 
> Xuan Zhuo (2):
>   virtio-net: correct hdr_len handling for VIRTIO_NET_F_GUEST_HDRLEN
>   virtio-net: correct hdr_len handling for tunnel gso
> 
>  drivers/net/tun_vnet.h     |  2 +-
>  drivers/net/virtio_net.c   |  6 ++++-
>  include/linux/virtio_net.h | 53 +++++++++++++++++++++++++++++++++++---
>  3 files changed, 55 insertions(+), 6 deletions(-)
> 
> --
> 2.32.0.3.g01195cf9f


Reply via email to