On Mon, Mar 23, 2026 at 12:18 PM Di Zhu <[email protected]> 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 <[email protected]> > --- > /* 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 <[email protected]> Thanks
