]> git.baikalelectronics.ru Git - kernel.git/commit
virtio-net: use NETIF_F_GRO_HW instead of NETIF_F_LRO
authorJason Wang <jasowang@redhat.com>
Tue, 17 Aug 2021 08:06:59 +0000 (16:06 +0800)
committerDavid S. Miller <davem@davemloft.net>
Tue, 17 Aug 2021 09:45:09 +0000 (10:45 +0100)
commitdbcf24d153884439dad30484a0e3f02350692e4c
treeac8d5338247dc70bf745d6eaada4fab3de0c2f6b
parent09e856d54bda5f288ef8437a90ab2b9b3eab83d1
virtio-net: use NETIF_F_GRO_HW instead of NETIF_F_LRO

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")
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Ivan <ivan@prestigetransportation.com>
Tested-by: Ivan <ivan@prestigetransportation.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/virtio_net.c