Skip to contentSkip to conversation

udp: GRO L4 improvements

PATCH Applied Paolo Abeni 3 participants 14 messages Mar 30, 2021 – Mar 31, 2021

Subsystems (4)
lore
Share & tools
lore

Paolo Abeni

author maintainer
#0 lore raw

v3 cover udp: GRO L4 improvements

This series improves the UDP L4 - either 'forward' or 'frag_list' - co-existence with UDP tunnel GRO, allowing the first to take place correctly even for encapsulated UDP traffic.

The first for patches are mostly bugfixes, addressing some GRO edge-cases when both tunnels and L4 are present, enabled and in use.

The next 3 patches avoid unneeded segmentation when UDP GRO traffic traverses in the receive path UDP tunnels.

Finally, some self-tests are included, covering the relevant GRO scenarios.

Even if most patches are actually bugfixes, this series is targeting net-next, as overall it makes available a new feature.

v2 -> v3:
- no code changes, more verbose commit messages and comment in patch 1/8

v1 -> v2:
- restrict post segmentation csum fixup to the only the relevant pkts
- use individual 'accept_gso_type' fields instead of whole gso bitmask (Willem)
- use only ipv6 addesses from test range in self-tests (Willem)
- hopefully clarified most individual patches commit messages

Paolo Abeni (8):
udp: fixup csum for GSO receive slow path
udp: skip L4 aggregation for UDP tunnel packets
udp: properly complete L4 GRO over UDP tunnel packet
udp: never accept GSO_FRAGLIST packets
vxlan: allow L4 GRO passthrough
geneve: allow UDP L4 GRO passthrou
bareudp: allow UDP L4 GRO passthrou
selftests: net: add UDP GRO forwarding self-tests

 drivers/net/bareudp.c                     |   1 +
 drivers/net/geneve.c                      |   1 +
 drivers/net/vxlan.c                       |   1 +
 include/linux/udp.h                       |  22 +-
 include/net/udp.h                         |  23 ++
 net/ipv4/udp.c                            |   5 +
 net/ipv4/udp_offload.c                    |  27 ++-
 net/ipv6/udp.c                            |   1 +
 net/ipv6/udp_offload.c                    |   3 +-
 tools/testing/selftests/net/Makefile      |   1 +
 tools/testing/selftests/net/udpgro_fwd.sh | 251 ++++++++++++++++++++++
 11 files changed, 323 insertions(+), 13 deletions(-)
 create mode 100755 tools/testing/selftests/net/udpgro_fwd.sh
Signature · 1 line
2.26.2
author maintainer
#1 lore raw

PATCH v3 1/8 udp: fixup csum for GSO receive slow path

When UDP packets generated locally by a socket with UDP_SEGMENT traverse the following path:

UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->

	UDP tunnel (rx) -> UDP socket (no UDP_GRO)

ip_summed will be set to CHECKSUM_PARTIAL at creation time and such checksum mode will be preserved in the above path up to the UDP tunnel receive code where we have:

__iptunnel_pull_header() -> skb_pull_rcsum() ->
skb_postpull_rcsum() -> __skb_postpull_rcsum()

The latter will convert the skb to CHECKSUM_NONE.

The UDP GSO packet will be later segmented as part of the rx socket receive operation, and will present a CHECKSUM_NONE after segmentation.

Additionally the segmented packets UDP CB still refers to the original GSO packet len. Overall that causes unexpected/wrong csum validation errors later in the UDP receive path.

We could possibly address the issue with some additional checks and csum mangling in the UDP tunnel code. Since the issue affects only this UDP receive slow path, let's set a suitable csum status there.

Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP encapsulation present a valid checksum when landing to udp_queue_rcv_skb(), as the UDP checksum has been validated by the GRO engine.

v2 -> v3:
- even more verbose commit message and comments

v1 -> v2:
- restrict the csum update to the packets strictly needing them
- hopefully clarify the commit message and code comments

---
 include/net/udp.h | 23 +++++++++++++++++++++++
 net/ipv4/udp.c    |  2 ++
 net/ipv6/udp.c    |  1 +
 3 files changed, 26 insertions(+)
include/net/udp.h +23 -0
index d4d064c592328..adf2ff8ac87c9 100644
@@ -515,6 +515,29 @@ static inline struct sk_buff *udp_rcv_segment(struct sock *sk,
 	return segs;
 }
 
+static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
+{
+	/* UDP-lite can't land here - no GRO */
+	WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
+
+	/* UDP packets generated with UDP_SEGMENT and traversing:
+	 *
+	 * UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx)
+	 *
+	 * can reach an UDP socket with CHECKSUM_NONE, because
+	 * __iptunnel_pull_header() converts CHECKSUM_PARTIAL into NONE.
+	 * SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets with no UDP tunnel will
+	 * have a valid checksum, as the GRO engine validates the UDP csum
+	 * before the aggregation and nobody strips such info in between.
+	 * Instead of adding another check in the tunnel fastpath, we can force
+	 * a valid csum after the segmentation.
+	 * Additionally fixup the UDP CB.
+	 */
+	UDP_SKB_CB(skb)->cscov = skb->len;
+	if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
+		skb->csum_valid = 1;
+}
+
 #ifdef CONFIG_BPF_SYSCALL
 struct sk_psock;
 struct proto *udp_bpf_get_proto(struct sock *sk, struct sk_psock *psock);
net/ipv4/udp.c +2 -0
index 4a0478b17243a..fe85dcf8c0087 100644
@@ -2178,6 +2178,8 @@ static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 	segs = udp_rcv_segment(sk, skb, true);
 	skb_list_walk_safe(segs, skb, next) {
 		__skb_pull(skb, skb_transport_offset(skb));
+
+		udp_post_segment_fix_csum(skb);
 		ret = udp_queue_rcv_one_skb(sk, skb);
 		if (ret > 0)
 			ip_protocol_deliver_rcu(dev_net(skb->dev), skb, ret);
net/ipv6/udp.c +1 -0
index d25e5a9252fdb..fa2f547383925 100644
@@ -749,6 +749,7 @@ static int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 	skb_list_walk_safe(segs, skb, next) {
 		__skb_pull(skb, skb_transport_offset(skb));
 
+		udp_post_segment_fix_csum(skb);
 		ret = udpv6_queue_rcv_one_skb(sk, skb);
 		if (ret > 0)
 			ip6_protocol_deliver_rcu(dev_net(skb->dev), skb, ret,
Signature · 1 line
2.26.2
maintainer Reviewed-by on v3 1/8
#2 lore raw

Re: [PATCH net-next v3 1/8] udp: fixup csum for GSO receive slow path

Quoted 31 lines · Paolo Abeni

When UDP packets generated locally by a socket with UDP_SEGMENT traverse the following path:

UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->

        UDP tunnel (rx) -> UDP socket (no UDP_GRO)

ip_summed will be set to CHECKSUM_PARTIAL at creation time and such checksum mode will be preserved in the above path up to the UDP tunnel receive code where we have:

__iptunnel_pull_header() -> skb_pull_rcsum() ->
skb_postpull_rcsum() -> __skb_postpull_rcsum()

The latter will convert the skb to CHECKSUM_NONE.

The UDP GSO packet will be later segmented as part of the rx socket receive operation, and will present a CHECKSUM_NONE after segmentation.

Additionally the segmented packets UDP CB still refers to the original GSO packet len. Overall that causes unexpected/wrong csum validation errors later in the UDP receive path.

We could possibly address the issue with some additional checks and csum mangling in the UDP tunnel code. Since the issue affects only this UDP receive slow path, let's set a suitable csum status there.

Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP encapsulation present a valid checksum when landing to udp_queue_rcv_skb(), as the UDP checksum has been validated by the GRO engine.

Quoted 8 lines

v2 -> v3:
- even more verbose commit message and comments

v1 -> v2:
- restrict the csum update to the packets strictly needing them
- hopefully clarify the commit message and code comments

author maintainer
#3 lore raw

PATCH v3 2/8 udp: skip L4 aggregation for UDP tunnel packets

In reply to Paolo Abeni

If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header.

That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc.

Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive.

The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets.

Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity.

v1 -> v2:
- hopefully clarify the commit message

Fixes 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
Fixes 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
---
 net/ipv4/udp_offload.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)
net/ipv4/udp_offload.c +11 -8
index c5b4b586570fe..25134a3548e99 100644
@@ -515,21 +515,24 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
 	unsigned int off = skb_gro_offset(skb);
 	int flush = 1;
 
+	/* we can do L4 aggregation only if the packet can't land in a tunnel
+	 * otherwise we could corrupt the inner stream
+	 */
 	NAPI_GRO_CB(skb)->is_flist = 0;
-	if (skb->dev->features & NETIF_F_GRO_FRAGLIST)
-		NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1;
+	if (!sk || !udp_sk(sk)->gro_receive) {
+		if (skb->dev->features & NETIF_F_GRO_FRAGLIST)
+			NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled : 1;
 
-	if ((!sk && (skb->dev->features & NETIF_F_GRO_UDP_FWD)) ||
-	    (sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist) {
-		pp = call_gro_receive(udp_gro_receive_segment, head, skb);
+		if ((!sk && (skb->dev->features & NETIF_F_GRO_UDP_FWD)) ||
+		    (sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist)
+			pp = call_gro_receive(udp_gro_receive_segment, head, skb);
 		return pp;
 	}
 
-	if (!sk || NAPI_GRO_CB(skb)->encap_mark ||
+	if (NAPI_GRO_CB(skb)->encap_mark ||
 	    (uh->check && skb->ip_summed != CHECKSUM_PARTIAL &&
 	     NAPI_GRO_CB(skb)->csum_cnt == 0 &&
-	     !NAPI_GRO_CB(skb)->csum_valid) ||
-	    !udp_sk(sk)->gro_receive)
+	     !NAPI_GRO_CB(skb)->csum_valid))
 		goto out;
 
 	/* mark that this skb passed once through the tunnel gro layer */
Signature · 1 line
2.26.2
author maintainer
#4 lore raw

PATCH v3 3/8 udp: properly complete L4 GRO over UDP tunnel packet

In reply to Paolo Abeni

After the previous patch, the stack can do L4 UDP aggregation on top of a UDP tunnel.

In such scenario, udp{4,6}_gro_complete will be called twice. This function will enter its is_flist branch immediately, even though that is only correct on the second call, as GSO_FRAGLIST is only relevant for the inner packet.

Instead, we need to try first UDP tunnel-based aggregation, if the GRO packet requires that.

This patch changes udp{4,6}_gro_complete to skip the frag list processing when while encap_mark == 1, identifying processing of the outer tunnel header.
Additionally, clears the field in udp_gro_complete() so that we can enter the frag list path on the next round, for the inner header.

v1 -> v2:
- hopefully clarified the commit message

---
 net/ipv4/udp_offload.c | 8 +++++++-
 net/ipv6/udp_offload.c | 3 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)
net/ipv4/udp_offload.c +7 -1
index 25134a3548e99..54e06b88af69a 100644
@@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
 		skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
 					: SKB_GSO_UDP_TUNNEL;
 
+		/* clear the encap mark, so that inner frag_list gro_complete
+		 * can take place
+		 */
+		NAPI_GRO_CB(skb)->encap_mark = 0;
+
 		/* Set encapsulation before calling into inner gro_complete()
 		 * functions to make them set up the inner offsets.
 		 */
@@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
 	const struct iphdr *iph = ip_hdr(skb);
 	struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
 
-	if (NAPI_GRO_CB(skb)->is_flist) {
+	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
+	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
 		uh->len = htons(skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
net/ipv6/udp_offload.c +2 -1
index faa823c242923..b3d9ed96e5ea5 100644
@@ -163,7 +163,8 @@ INDIRECT_CALLABLE_SCOPE int udp6_gro_complete(struct sk_buff *skb, int nhoff)
 	const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
 	struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
 
-	if (NAPI_GRO_CB(skb)->is_flist) {
+	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
+	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
 		uh->len = htons(skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
Signature · 1 line
2.26.2
author maintainer
#5 lore raw

PATCH v3 4/8 udp: never accept GSO_FRAGLIST packets

In reply to Paolo Abeni

Currently the UDP protocol delivers GSO_FRAGLIST packets to the sockets without the expected segmentation.

This change addresses the issue introducing and maintaining a couple of new fields to explicitly accept SKB_GSO_UDP_L4 or GSO_FRAGLIST packets. Additionally updates udp_unexpected_gso() accordingly.

UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist zeroed.

v1 -> v2:
- use 2 bits instead of a whole GSO bitmask (Willem)

Fixes 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
---
 include/linux/udp.h | 16 +++++++++++++---
 net/ipv4/udp.c      |  3 +++
 2 files changed, 16 insertions(+), 3 deletions(-)
include/linux/udp.h +13 -3
index aa84597bdc33c..ae58ff3b6b5b8 100644
@@ -51,7 +51,9 @@ struct udp_sock {
 					   * different encapsulation layer set
 					   * this
 					   */
-			 gro_enabled:1;	/* Can accept GRO packets */
+			 gro_enabled:1,	/* Request GRO aggregation */
+			 accept_udp_l4:1,
+			 accept_udp_fraglist:1;
 	/*
 	 * Following member retains the information to create a UDP header
 	 * when the socket is uncorked.
@@ -131,8 +133,16 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk,
 
 static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 {
-	return !udp_sk(sk)->gro_enabled && skb_is_gso(skb) &&
-	       skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4;
+	if (!skb_is_gso(skb))
+		return false;
+
+	if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && !udp_sk(sk)->accept_udp_l4)
+		return true;
+
+	if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST && !udp_sk(sk)->accept_udp_fraglist)
+		return true;
+
+	return false;
 }
 
 #define udp_portaddr_for_each_entry(__sk, list) \
net/ipv4/udp.c +3 -0
index fe85dcf8c0087..c0695ce42dc53 100644
@@ -2666,9 +2666,12 @@ int udp_lib_setsockopt(struct sock *sk, int level, int optname,
 
 	case UDP_GRO:
 		lock_sock(sk);
+
+		/* when enabling GRO, accept the related GSO packet type */
 		if (valbool)
 			udp_tunnel_encap_enable(sk->sk_socket);
 		up->gro_enabled = valbool;
+		up->accept_udp_l4 = valbool;
 		release_sock(sk);
 		break;
 
Signature · 1 line
2.26.2
maintainer Reviewed-by on v3 4/8
#6 lore raw

Re: [PATCH net-next v3 4/8] udp: never accept GSO_FRAGLIST packets

Quoted 9 lines · Paolo Abeni

Currently the UDP protocol delivers GSO_FRAGLIST packets to the sockets without the expected segmentation.

This change addresses the issue introducing and maintaining a couple of new fields to explicitly accept SKB_GSO_UDP_L4 or GSO_FRAGLIST packets. Additionally updates udp_unexpected_gso() accordingly.

Quoted 8 lines

UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist zeroed.

v1 -> v2:
- use 2 bits instead of a whole GSO bitmask (Willem)

Fixes 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
author maintainer
#7 lore raw

PATCH v3 5/8 vxlan: allow L4 GRO passthrough

In reply to Paolo Abeni

When passing up an UDP GSO packet with L4 aggregation, there is no need to segment it at the vxlan level. We can propagate the packet untouched and let it be segmented later, if needed.

Introduce an helper to allow let the UDP socket to accept any L4 aggregation and use it in the vxlan driver.

v1 -> v2:
- updated to use the newly introduced UDP socket 'accept*' fields

---
 drivers/net/vxlan.c | 1 +
 include/linux/udp.h | 6 ++++++
 2 files changed, 7 insertions(+)
drivers/net/vxlan.c +1 -0
index 7665817f3cb61..39ee1300cdd9d 100644
@@ -3484,6 +3484,7 @@ static struct socket *vxlan_create_sock(struct net *net, bool ipv6,
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
include/linux/udp.h +6 -0
index ae58ff3b6b5b8..ae66dadd85434 100644
@@ -145,6 +145,12 @@ static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 	return false;
 }
 
+static inline void udp_allow_gso(struct sock *sk)
+{
+	udp_sk(sk)->accept_udp_l4 = 1;
+	udp_sk(sk)->accept_udp_fraglist = 1;
+}
+
 #define udp_portaddr_for_each_entry(__sk, list) \
 	hlist_for_each_entry(__sk, list, __sk_common.skc_portaddr_node)
 
Signature · 1 line
2.26.2
maintainer Reviewed-by on v3 5/8
#8 lore raw

Re: [PATCH net-next v3 5/8] vxlan: allow L4 GRO passthrough

Quoted 5 lines · Paolo Abeni

When passing up an UDP GSO packet with L4 aggregation, there is no need to segment it at the vxlan level. We can propagate the packet untouched and let it be segmented later, if needed.

Quoted 7 lines

Introduce an helper to allow let the UDP socket to accept any L4 aggregation and use it in the vxlan driver.

v1 -> v2:
- updated to use the newly introduced UDP socket 'accept*' fields

author maintainer
#9 lore raw

PATCH v3 6/8 geneve: allow UDP L4 GRO passthrou

In reply to Paolo Abeni

Similar to the previous commit, let even geneve
passthrou the L4 GRO packets

---
 drivers/net/geneve.c | 1 +
 1 file changed, 1 insertion(+)
drivers/net/geneve.c +1 -0
index 4ac0373326efd..5d7a2b1469f4c 100644
@@ -461,6 +461,7 @@ static struct socket *geneve_create_sock(struct net *net, bool ipv6,
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
Signature · 1 line
2.26.2
author maintainer
#10 lore raw

PATCH v3 7/8 bareudp: allow UDP L4 GRO passthrou

In reply to Paolo Abeni

Similar to the previous commit, let even geneve
passthrou the L4 GRO packets

---
 drivers/net/bareudp.c | 1 +
 1 file changed, 1 insertion(+)
drivers/net/bareudp.c +1 -0
index 7511bca9c15ed..edfad93e7b686 100644
@@ -218,6 +218,7 @@ static struct socket *bareudp_create_sock(struct net *net, __be16 port)
 	if (err < 0)
 		return ERR_PTR(err);
 
+	udp_allow_gso(sock->sk);
 	return sock;
 }
 
Signature · 1 line
2.26.2
author maintainer
#11 lore raw

PATCH v3 8/8 selftests: net: add UDP GRO forwarding self-tests

In reply to Paolo Abeni

Create a bunch of virtual topologies and verify that NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD-enabled devices aggregate the ingress packets as expected. Additionally check that the aggregate packets are segmented correctly when landing on a socket

Also test SKB_GSO_FRAGLIST and SKB_GSO_UDP_L4 aggregation on top of UDP tunnel (vxlan)

v1 -> v2:
- hopefully clarify the commit message
- moved the overlay network ipv6 range into the 'documentation' reserved range (Willem)

---
 tools/testing/selftests/net/Makefile      |   1 +
 tools/testing/selftests/net/udpgro_fwd.sh | 251 ++++++++++++++++++++++
 2 files changed, 252 insertions(+)
 create mode 100755 tools/testing/selftests/net/udpgro_fwd.sh
tools/testing/selftests/net/Makefile +1 -0
index 25f198bec0b25..2d71b283dde36 100644
@@ -23,6 +23,7 @@ TEST_PROGS += drop_monitor_tests.sh
 TEST_PROGS += vrf_route_leaking.sh
 TEST_PROGS += bareudp.sh
 TEST_PROGS += unicast_extensions.sh
+TEST_PROGS += udpgro_fwd.sh
 TEST_PROGS_EXTENDED := in_netns.sh
 TEST_GEN_FILES =  socket nettest
 TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
tools/testing/selftests/net/udpgro_fwd.sh new file +251 -0

251 lines not on this page · raw message

Signature · 1 line
2.26.2
maintainer Acked-by on v3 8/8
#12 lore raw

Re: [PATCH net-next v3 8/8] selftests: net: add UDP GRO forwarding self-tests

Quoted 10 lines · Paolo Abeni

Create a bunch of virtual topologies and verify that NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD-enabled devices aggregate the ingress packets as expected. Additionally check that the aggregate packets are segmented correctly when landing on a socket

Also test SKB_GSO_FRAGLIST and SKB_GSO_UDP_L4 aggregation on top of UDP tunnel (vxlan)

Quoted 6 lines

v1 -> v2:
- hopefully clarify the commit message
- moved the overlay network ipv6 range into the 'documentation' reserved range (Willem)

#13 lore raw
In reply to Paolo Abeni
This series was applied to netdev/net-next.git (refs/heads/master):

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

Quoted 8 lines · On Tue, 30 Mar 2021 12:28:48 +0200 you wrote:

This series improves the UDP L4 - either 'forward' or 'frag_list' - co-existence with UDP tunnel GRO, allowing the first to take place correctly even for encapsulated UDP traffic.

The first for patches are mostly bugfixes, addressing some GRO edge-cases when both tunnels and L4 are present, enabled and in use.

[...]

Here is the summary with links:
- [net-next,v3,1/8] udp: fixup csum for GSO receive slow path

    https://git.kernel.org/netdev/net-next/c/000ac44da7d0
  - [net-next,v3,2/8] udp: skip L4 aggregation for UDP tunnel packets
    https://git.kernel.org/netdev/net-next/c/18f25dc39990
  - [net-next,v3,3/8] udp: properly complete L4 GRO over UDP tunnel packet
    https://git.kernel.org/netdev/net-next/c/e0e3070a9bc9
  - [net-next,v3,4/8] udp: never accept GSO_FRAGLIST packets
    https://git.kernel.org/netdev/net-next/c/78352f73dc50
  - [net-next,v3,5/8] vxlan: allow L4 GRO passthrough
    https://git.kernel.org/netdev/net-next/c/d18931a92a0b
  - [net-next,v3,6/8] geneve: allow UDP L4 GRO passthrou
    https://git.kernel.org/netdev/net-next/c/61630c4f052b
  - [net-next,v3,7/8] bareudp: allow UDP L4 GRO passthrou
    https://git.kernel.org/netdev/net-next/c/b03ef676ba6d
  - [net-next,v3,8/8] selftests: net: add UDP GRO forwarding self-tests
    https://git.kernel.org/netdev/net-next/c/a062260a9d5f

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html