public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Zhud <zhud@hygon.cn>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "jasowang@redhat.com" <jasowang@redhat.com>,
	"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
	"eperezma@redhat.com" <eperezma@redhat.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"willemb@google.com" <willemb@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
	Jing Li <lijing@hygon.cn>, Zhiwei Ying <yingzhiwei@hygon.cn>
Subject: RE: [PATCH net-next v2] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
Date: Mon, 16 Mar 2026 10:18:04 +0000	[thread overview]
Message-ID: <607818aba89a44d88afa213f39611451@hygon.cn> (raw)
In-Reply-To: <20260316051327-mutt-send-email-mst@kernel.org>

> Thanks! Yes something to improve:
> 
> On Mon, Mar 16, 2026 at 03:21:52PM +0800, Di Zhu wrote:
> > Although VIRTIO_NET_F_CTRL_GUEST_OFFLOADS is negotiated, which
> > indicates the device supports dynamic control of guest offloads, it
> > does not necessarily mean the device supports specific hardware GRO features.
> >
> > If none of the features defined in GUEST_OFFLOAD_GRO_HW_MASK (such as
> > TSO4, TSO6, or UFO) are present in vi->guest_offloads_capable, the
> > device effectively lacks the hardware capability to perform GRO.
> 
> So what is the user-visible problem this is trying to address?

A key concern is that once a user enables NETIF_F_GRO_HW via ethtool, 
they might manually disable software GRO (ethtool -K eth0 gro off) assuming the 
hardware is now handling the aggregation.

Secondly, while we haven't encountered a specific hardware failure yet, 
enabling a hardware offload feature that the DPU does not physically support 
introduces the risk of undefined hardware behavior

> >
> > So, making NETIF_F_GRO_HW conditional on these feature bits ensures
> > the stack does not enable an unsupported hardware offload configuration.
> 
> I guess the assumption is that without this, something enables such a config? Which
> stack is this and what happens then?
> 

Sorry for the confusion, let me clarify the intent.
The 'stack' here refers to the ethtool interface and the netset (ioctl/netlink) path. 

> 
> > Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO")
> > Signed-off-by: Di Zhu <zhud@hygon.cn>
> 
> judging by this, has something to do with LRO?
> 
> > ---
> > /* v2 */
> >   -make the modified logic clearer
> > ---
> >  drivers/net/virtio_net.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 72d6a9c6a5a2..b233c99925e9 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -6781,8 +6781,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 |
> > @@ -7058,6 +7056,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> >  	}
> >  	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;
> > +
> >  	rtnl_unlock();
> >
> >  	err = virtnet_cpu_notif_add(vi);
> > --
> > 2.34.1
> >
> 



  reply	other threads:[~2026-03-16 10:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16  7:21 [PATCH net-next v2] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported Di Zhu
2026-03-16  9:15 ` Michael S. Tsirkin
2026-03-16 10:18   ` Zhud [this message]
2026-03-16 10:47     ` Michael S. Tsirkin
2026-03-16 12:57       ` Zhud
2026-03-16 13:30         ` Michael S. Tsirkin
2026-03-16 13:57           ` Zhud
2026-03-16 14:46             ` Michael S. Tsirkin
2026-03-17  1:55               ` Zhud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=607818aba89a44d88afa213f39611451@hygon.cn \
    --to=zhud@hygon.cn \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=lijing@hygon.cn \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=willemb@google.com \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yingzhiwei@hygon.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox