summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2020-11-04 03:54:00 +0300
committerJakub Kicinski <kuba@kernel.org>2020-11-04 03:54:00 +0300
commit8e6a0485d1c41cdddbae64fec4ee6005eadc8998 (patch)
treef4ddb75b93d17ad0085f49b20e0bf89f6fc54515 /include
parentc1c0f6eac3db61761dc8bfeb2e61989b1f3eeee9 (diff)
parentecb8fed408b6454606bbb3cd0edb083bf0ad162a (diff)
downloadlinux-8e6a0485d1c41cdddbae64fec4ee6005eadc8998.tar.xz
Merge branch 'net-allow-virtual-netdevs-to-forward-udp-l4-and-fraglist-gso-skbs'
Alexander Lobakin says: ==================== net: allow virtual netdevs to forward UDP L4 and fraglist GSO skbs NETIF_F_GSO_UDP_L4 and NETIF_F_GSO_FRAGLIST allow drivers to offload GSO UDP L4. This works well on simple setups, but when any logical netdev (e.g. VLAN) is present, kernel stack always performs software resegmentation which actually kills the performance. The full path in such cases is like: 1. Our NIC driver advertises a support for fraglists, GSO UDP L4, GSO fraglists. 2. User enables fraglisted GRO via Ethtool. 3. GRO subsystem receives UDP frames from driver and merges the packets into fraglisted GSO skb(s). 4. Networking stack queues it up for xmitting. 5. Virtual device like VLAN doesn't advertise a support for GSO UDP L4 and GSO fraglists, so skb_gso_check() doesn't allow to pass this skb as is to the real driver. 6. Kernel then has to form a bunch of regular UDP skbs from that one and pass it to the driver instead. This fallback is *extremely* slow for any GSO types, but especially for GSO fraglists. 7. All further processing performs with a series of plain UDP skbs, and the driver gets it one-by-one, despite that it supports UDP L4 and fraglisted GSO. That's not OK because: a) logical/virtual netdevs like VLANs, bridges etc. should pass GSO skbs as is; b) even if the final driver doesn't support such type of GSO, this software resegmenting should be performed right before it, not in the middle of processing -- I think I even saw that note somewhere in kernel documentation, and it's totally reasonable in terms of performance. Despite the fact that no mainline drivers currently supports fraglist GSO, this should and can be easily fixed by adding UDP L4 and fraglist GSO to the list of GSO types that can be passed-through the logical interfaces (NETIF_F_GSO_SOFTWARE). After this change, no resegmentation occurs (if a particular driver supports and advertises this), and the performance goes on par with e.g. 1:1 forwarding. The only logical netdevs that seem to be unaffected to this are bridge interfaces, as their code uses full NETIF_F_GSO_MASK. Tested on MIPS32 R2 router board with a WIP NIC driver in VLAN NAT: 20 Mbps baseline, 1 Gbps / link speed with this patch. Since v1 [1]: - handle bonding and team drivers as suggested by Willem de Bruijn; - reword and expand the introduction with the particular example. [1] https://lore.kernel.org/netdev/Mx3BWGop6fGORN6Cpo4mHIHz2b1bb0eLxeMG8vsijnk@cp3-web-020.plabs.ch ==================== Link: https://lore.kernel.org/r/NysZRGMkuWq0KPTCJ1Dz2FTjRkeJXDH3edVrsEeJkQI@cp4-web-036.plabs.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include')
-rw-r--r--include/linux/netdev_features.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 0b17c4322b09..934de56644e7 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -207,8 +207,8 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start)
NETIF_F_FSO)
/* List of features with software fallbacks. */
-#define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | \
- NETIF_F_GSO_SCTP)
+#define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | NETIF_F_GSO_SCTP | \
+ NETIF_F_GSO_UDP_L4 | NETIF_F_GSO_FRAGLIST)
/*
* If one device supports one of these features, then enable them