On Tue, Nov 11, 2025 at 12:10 AM Michael S. Tsirkin <[email protected]> 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 <[email protected]> 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 protected]> > > > > 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 protected]> 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 > > > >
