On Wed, Dec 19, 2018 at 05:44:44PM -0500, Willem de Bruijn wrote: > On Wed, Dec 19, 2018 at 5:32 PM Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: > > > > From: Willem de Bruijn <will...@google.com> > > > > Virtio-net devices negotiate LRO support with the host. > > Display the initially negotiated state with ethtool -k. > > > > Also allow configuring it with ethtool -K, reusing the existing > > virtnet_set_guest_offloads helper that disables LRO for XDP. > > > > Virtio-net negotiates TSO4 and TSO6 separately, but ethtool does not > > distinguish between the two. In the unlikely legacy case where the > > host only supports one of the two, maintain the current state. > > > > RTNL is held while calling virtnet_set_features, same as on the path > > from virtnet_xdp_set. > > > > Tested: > > Verified that large-receive-offload is "off [fixed]" when not > > negotiated during initial probe and "on" otherwise. > > > > Measured packet size when scp-ing a large file to the guest with > > nstat (IpExtInOctets / IpInDelivers). Verified that packet size > > exceeds MTU only if ethtool -k shows LRO and/or GRO as enabled. > > > > Signed-off-by: Willem de Bruijn <will...@google.com> > > Two comments for the review: > > 1. Current drivers show LRO as disabled even if it is negotiated at > probe. That is arguably a bug. In which case I can split this patch into > - a net patch to advertise the initially negotiated value through dev->feature > - a net-next patch to configure it with ndo_set_features. > > 2. virtnet_clear_guest_offloads disables all guest_offloads, including > VIRTIO_NET_F_GUEST_CSUM. That seems undesirable? The feature is a > prerequisite for LRO, but not the other way around. This applies > equally to the xdp and ethtool paths, so would be another separate > net patch.
Makes sense I guess.
