[PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[Di Zhu]

Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
allows control over offload support, but the offloads that can be
controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
nor GUEST_TSO6 is supported).

In such a setup, reporting NETIF_F_GRO_HW as available for the device
is too optimistic and misleading to the user.

Improve the situation by masking off NETIF_F_GRO_HW unless the device
possesses actual GRO-related offload capabilities. Out of an abundance
of caution, this does not change the current behaviour for hardware with
just v6 or just v4 GRO: current interfaces do not allow distinguishing
between v6/v4 GRO, so we can't expose them to userspace precisely.

Signed-off-by: Di Zhu <zhud@hygon.cn>
---
/* v4 */
  -Move the hw_features update logic before register_netdevice()
  -Target the net-next tree

/* v3 */
  -Update Fixes tag to dbcf24d15388
  -Refine commit message using Maintainer's "too optimistic"
    phrasing to clarify the risk of misleading configurations.

/* v2 */
  -make the modified logic clearer
---
 drivers/net/virtio_net.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 022f60728721..29bd313e7592 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -6795,8 +6795,6 @@ static int virtnet_probe(struct virtio_device *vdev)
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
 	    virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6))
 		dev->features |= NETIF_F_GRO_HW;
-	if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
-		dev->hw_features |= NETIF_F_GRO_HW;
 
 	dev->vlan_features = dev->features;
 	dev->xdp_features = NETDEV_XDP_ACT_BASIC | NETDEV_XDP_ACT_REDIRECT |
@@ -6989,6 +6987,19 @@ static int virtnet_probe(struct virtio_device *vdev)
 
 	enable_rx_mode_work(vi);
 
+	for (i = 0; i < ARRAY_SIZE(guest_offloads); i++) {
+		unsigned int fbit;
+
+		fbit = virtio_offload_to_feature(guest_offloads[i]);
+		if (virtio_has_feature(vi->vdev, fbit))
+			set_bit(guest_offloads[i], &vi->guest_offloads);
+	}
+	vi->guest_offloads_capable = vi->guest_offloads;
+
+	if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) &&
+	    (vi->guest_offloads_capable & GUEST_OFFLOAD_GRO_HW_MASK))
+		dev->hw_features |= NETIF_F_GRO_HW;
+
 	/* serialize netdev register + virtio_device_ready() with ndo_open() */
 	rtnl_lock();
 
@@ -7071,15 +7082,6 @@ static int virtnet_probe(struct virtio_device *vdev)
 		netif_carrier_on(dev);
 	}
 
-	for (i = 0; i < ARRAY_SIZE(guest_offloads); i++) {
-		unsigned int fbit;
-
-		fbit = virtio_offload_to_feature(guest_offloads[i]);
-		if (virtio_has_feature(vi->vdev, fbit))
-			set_bit(guest_offloads[i], &vi->guest_offloads);
-	}
-	vi->guest_offloads_capable = vi->guest_offloads;
-
 	rtnl_unlock();
 
 	err = virtnet_cpu_notif_add(vi);
-- 
2.34.1

Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[Jakub Kicinski]

On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
> 
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
> 
> Improve the situation by masking off NETIF_F_GRO_HW unless the device
> possesses actual GRO-related offload capabilities. Out of an abundance
> of caution, this does not change the current behaviour for hardware with
> just v6 or just v4 GRO: current interfaces do not allow distinguishing
> between v6/v4 GRO, so we can't expose them to userspace precisely.

Michael, Jason, does this patch look good now?

https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/

Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[Jason Wang]

On Fri, Mar 27, 2026 at 11:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:
> > Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> > allows control over offload support, but the offloads that can be
> > controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> > nor GUEST_TSO6 is supported).
> >
> > In such a setup, reporting NETIF_F_GRO_HW as available for the device
> > is too optimistic and misleading to the user.
> >
> > Improve the situation by masking off NETIF_F_GRO_HW unless the device
> > possesses actual GRO-related offload capabilities. Out of an abundance
> > of caution, this does not change the current behaviour for hardware with
> > just v6 or just v4 GRO: current interfaces do not allow distinguishing
> > between v6/v4 GRO, so we can't expose them to userspace precisely.
>
> Michael, Jason, does this patch look good now?
>
> https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/
>

Yes, I've acked.

Thanks

Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[Jakub Kicinski]

On Fri, 27 Mar 2026 11:22:43 +0800 Jason Wang wrote:
> On Fri, Mar 27, 2026 at 11:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:  
> > > Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> > > allows control over offload support, but the offloads that can be
> > > controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> > > nor GUEST_TSO6 is supported).
> > >
> > > In such a setup, reporting NETIF_F_GRO_HW as available for the device
> > > is too optimistic and misleading to the user.
> > >
> > > Improve the situation by masking off NETIF_F_GRO_HW unless the device
> > > possesses actual GRO-related offload capabilities. Out of an abundance
> > > of caution, this does not change the current behaviour for hardware with
> > > just v6 or just v4 GRO: current interfaces do not allow distinguishing
> > > between v6/v4 GRO, so we can't expose them to userspace precisely.  
> >
> > Michael, Jason, does this patch look good now?
> >
> > https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/
> >  
> 
> Yes, I've acked.

Obrigado!

Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[Jason Wang]

On Mon, Mar 23, 2026 at 12:18 PM Di Zhu <zhud@hygon.cn> wrote:
>
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
>
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
>
> Improve the situation by masking off NETIF_F_GRO_HW unless the device
> possesses actual GRO-related offload capabilities. Out of an abundance
> of caution, this does not change the current behaviour for hardware with
> just v6 or just v4 GRO: current interfaces do not allow distinguishing
> between v6/v4 GRO, so we can't expose them to userspace precisely.
>
> Signed-off-by: Di Zhu <zhud@hygon.cn>
> ---
> /* v4 */
>   -Move the hw_features update logic before register_netdevice()
>   -Target the net-next tree
>
> /* v3 */
>   -Update Fixes tag to dbcf24d15388
>   -Refine commit message using Maintainer's "too optimistic"
>     phrasing to clarify the risk of misleading configurations.
>
> /* v2 */
>   -make the modified logic clearer

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks

Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 23 Mar 2026 12:17:30 +0800 you wrote:
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
> 
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
> 
> [...]

Here is the summary with links:
  - [net-next,v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
    https://git.kernel.org/netdev/net-next/c/f8844dfeeae8

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html