--- v1
+++ v3
@@ -1,18 +1,32 @@
-If UDP GRO forwarding (or list) is enabled, and there are
-udp tunnel available in the system, we could end-up doing L4
-aggregation for packets targeting the UDP tunnel.
+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 inner protocol corruption, as no overaly network
-parameters is taken in account at aggregation time.
+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 fwd GRO if this packet could land in an UDP
-tunnel. The current check is broader than what is strictly
-needed, as the UDP tunnel could be e.g. on top of a different
-device, but is simple and the performance downside looks not
-relevant.
+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")
+Reviewed-by: Willem de Bruijn <willemb@google.com>
 Signed-off-by: Paolo Abeni <pabeni@redhat.com>
 ---
  net/ipv4/udp_offload.c | 19 +++++++++++--------