large-receive-offload no more tunable in 5.4.0-89-generic

[Christian Ehrhardt ]

While debugging a bug 1945868 I found something that I think is a separate issue to that original report, hence this new bug.
I found the virtio-net behavior changing in an unexpected way in 5.4.0-89-generic that is currently in Focal-proposed.

1. 5.4.0-86-generic
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off
$ sudo ethtool --features enp1s0 lro on
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: on
$ sudo ethtool --features enp1s0 lro off
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off

2. 5.4.0-88-generic
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off
$ sudo ethtool --features enp1s0 lro on
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: on
$ sudo ethtool --features enp1s0 lro off
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off

3. 5.4.0-89-generic
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off [fixed]
$ sudo ethtool --features enp1s0 lro on
Cannot change large-receive-offload
Could not change any device features
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off [fixed]
$ sudo ethtool --features enp1s0 lro off
Cannot change large-receive-offload
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off [fixed

I've installed/uninstalled the guest kernel twice but the above behavior remained consistent and seemed to be only influenced by the new kernel.

The used guest config is the default that falls out of uvt-kvm, that means in regard to this bug:
  <os>
    <type arch='x86_64' machine='pc-q35-focal'>hvm</type>
  </os>
...
    <interface type='network'>
      <mac address='52:54:00:b2:c2:2a'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Virt-Stack is qemu 1:4.2-3ubuntu6.17 and libvirt 6.0.0-0ubuntu8.14 from current Focal-updates.
---
ProblemType: Bug
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Oct 6 06:47 seq
 crw-rw---- 1 root audio 116, 33 Oct 6 06:47 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.20.11-0ubuntu27.20
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: N/A
CasperMD5CheckResult: skip
DistroRelease: Ubuntu 20.04
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
Package: linux (not installed)
PciMultimedia:

ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-89-generic root=UUID=5697bbf9-a186-49b9-98bc-2a94313535b4 ro console=tty1 console=ttyS0
ProcVersionSignature: Ubuntu 5.4.0-89.100-generic 5.4.143
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-89-generic N/A
 linux-backports-modules-5.4.0-89-generic N/A
 linux-firmware N/A
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
Tags: focal uec-images
Uname: Linux 5.4.0-89-generic x86_64
UnreportableReason: This report is about a package that is not installed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: False
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.13.0-1ubuntu1.1
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-focal
dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-focal:cvnQEMU:ct1:cvrpc-q35-focal:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-focal
dmi.sys.vendor: QEMU

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

apport information

[Christian Ehrhardt  (paelzer)]

Tagged as regression-proposed because until we know better that is what it appears to me.
Ran apport-collect to silence the bot complaining about missing details :-)

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Stefan Bader (smb)]

Looking at the delta I found this change (referencing the upstream commit which was received via upstream stable):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dbcf24d153884439dad30484a0e3f02350692e4c

This sounds like LRO should not have been configurable and they (upstram) fixed that now. And they claim any problem are not theirs... (at least I read it that way).

    Commit a02e8964eaf92 ("virtio-net: ethtool configurable LRO")
    maps LRO to virtio guest offloading features and allows the
    administrator to enable and disable those features via ethtool.

    This leads to several issues:

    - For a device that doesn't support control guest offloads, the "LRO"
      can't be disabled triggering WARN in dev_disable_lro() when turning
      off LRO or when enabling forwarding bridging etc.

    - For a device that supports control guest offloads, the guest
      offloads are disabled in cases of bridging, forwarding etc slowing
      down the traffic.

    Fix this by using NETIF_F_GRO_HW instead. Though the spec does not
    guarantee packets to be re-segmented as the original ones,
    we can add that to the spec, possibly with a flag for devices to
    differentiate between GRO and LRO.

    Further, we never advertised LRO historically before a02e8964eaf92
    ("virtio-net: ethtool configurable LRO") and so bridged/forwarded
    configs effectively always relied on virtio receive offloads behaving
    like GRO - thus even if this breaks any configs it is at least not
    a regression.

    Fixes: a02e8964eaf92 ("virtio-net: ethtool configurable LRO")

[Christian Ehrhardt  (paelzer)]

Thanks Stefan,
that at least explains why it changed!

I think without knowing broken use-cases I'm ok with it then.
Not what I'd expect to be ok under SRU terms but IIRC it was added in a similar way back then, so I'm not stopping you to remove/fix it under similar terms.
I'm setting the state to "Won't Fix" to reflect that.

It might happen that other users will spot other use cases that are more broken by it.
In that case you might need to start a place to document common mitigations.