Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Alexander Duyck <hidden>
Date: 2017-12-07 18:13:07
On Thu, Dec 7, 2017 at 12:03 AM, Michael Chan [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Introduce NETIF_F_GRO_HW feature flag for NICs that support hardware GRO. With this flag, we can now independently turn on or off hardware GRO when GRO is on. Previously, drivers were using NETIF_F_GRO to control hardware GRO and so it cannot be independently turned on or off without affecting GRO. Hardware GRO (just like GRO) guarantees that packets can be re-segmented by TSO/GSO to reconstruct the original packet stream. It is a subset of NETIF_F_GRO and depends on it Since NETIF_F_GRO is not propagated between upper and lower devices, NETIF_F_GRO_HW should follow suit since it is a subset of GRO. In other words, a lower device can independent have GRO/GRO_HW enabled or disabled and no feature propagation is required. This will preserve the current GRO behavior. Cc: Ariel Elior <redacted> Cc: everest-linux-l2@cavium.com Signed-off-by: Michael Chan <michael.chan@broadcom.com> --- Documentation/networking/netdev-features.txt | 8 ++++++++ include/linux/netdev_features.h | 3 +++ net/core/dev.c | 17 +++++++++++++++++ net/core/ethtool.c | 1 + 4 files changed, 29 insertions(+)diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt index 7413eb0..8f36527 100644 --- a/Documentation/networking/netdev-features.txt +++ b/Documentation/networking/netdev-features.txt@@ -163,3 +163,11 @@ This requests that the NIC receive all possible frames, including errored frames (such as bad FCS, etc). This can be helpful when sniffing a link with bad packets on it. Some NICs may receive more packets if also put into normal PROMISC mode. + +* rx-gro-hw + +This requests that the NIC enables Hardware GRO (generic receive offload). +Hardware GRO is basically the exact reverse of TSO, and is generally +stricter than Hardware LRO. A packet stream merged by Hardware GRO must +be re-segmentable by GSO or TSO back to the exact original packet stream. +Hardware GRO is dependent on GRO and RXCSUM.diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h index b1b0ca7..db84c51 100644 --- a/include/linux/netdev_features.h +++ b/include/linux/netdev_features.h@@ -78,6 +78,8 @@ enum { NETIF_F_HW_ESP_TX_CSUM_BIT, /* ESP with TX checksum offload */ NETIF_F_RX_UDP_TUNNEL_PORT_BIT, /* Offload of RX port for UDP tunnels */ + NETIF_F_GRO_HW_BIT, /* Hardware Generic receive offload */ + /* * Add your fresh new feature above and remember to update * netdev_features_strings[] in net/core/ethtool.c and maybe@@ -97,6 +99,7 @@ enum { #define NETIF_F_FRAGLIST __NETIF_F(FRAGLIST) #define NETIF_F_FSO __NETIF_F(FSO) #define NETIF_F_GRO __NETIF_F(GRO) +#define NETIF_F_GRO_HW __NETIF_F(GRO_HW) #define NETIF_F_GSO __NETIF_F(GSO) #define NETIF_F_GSO_ROBUST __NETIF_F(GSO_ROBUST) #define NETIF_F_HIGHDMA __NETIF_F(HIGHDMA)diff --git a/net/core/dev.c b/net/core/dev.c index 6bea893..7242e5e 100644 --- a/net/core/dev.c +++ b/net/core/dev.c@@ -7405,6 +7405,23 @@ static netdev_features_t netdev_fix_features(struct net_device *dev, features &= ~dev->gso_partial_features; } + if (features & NETIF_F_GRO_HW) { + /* Hardware GRO depends on GRO and RXCSUM. */ + if (!(features & NETIF_F_GRO)) { + netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no GRO feature.\n"); + features &= ~NETIF_F_GRO_HW; + }
I'm not sure I agree with this part. The hardware offload should not be dependent on the software offload. If you are concerned with the XDP case and such you should probably just look at handling it more like how TSO is handled with a group of flags that aggregate GRO, LRO, and GRO_HW into a group of features that must be disabled to support XDP.
+ if (!(features & NETIF_F_RXCSUM)) {
+ netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no RXCSUM feature.\n");
+ features &= ~NETIF_F_GRO_HW;
+ }
+ /* Hardware GRO and LRO are mutually exclusive. */
+ if (features & NETIF_F_LRO) {
+ netdev_dbg(dev, "Dropping NETIF_F_LRO since GRO_HW is set.\n");
+ features &= ~NETIF_F_LRO;
+ }This is going to be problematic. What if you bond one interface that has LRO and one that has GRO_HW? It seems like this is going to cause the bond interface to lie and say LRO isn't there when it actually is, or worse yet it will force features off when they shouldn't be.
quoted hunk ↗ jump to hunk
+ } + return features; }diff --git a/net/core/ethtool.c b/net/core/ethtool.c index f8fcf45..50a7920 100644 --- a/net/core/ethtool.c +++ b/net/core/ethtool.c@@ -73,6 +73,7 @@ int ethtool_op_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info) [NETIF_F_LLTX_BIT] = "tx-lockless", [NETIF_F_NETNS_LOCAL_BIT] = "netns-local", [NETIF_F_GRO_BIT] = "rx-gro", + [NETIF_F_GRO_HW_BIT] = "rx-gro-hw", [NETIF_F_LRO_BIT] = "rx-lro", [NETIF_F_TSO_BIT] = "tx-tcp-segmentation", --1.8.3.1