From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next 00/10] udp: implement GRO support Date: Wed, 07 Nov 2018 16:23:23 -0800 (PST) Message-ID: <20181107.162323.528796082485932111.davem@davemloft.net> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, willemb@google.com, steffen.klassert@secunet.com, subashab@codeaurora.org To: pabeni@redhat.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:47700 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728169AbeKHJ4N (ORCPT ); Thu, 8 Nov 2018 04:56:13 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: Paolo Abeni Date: Wed, 7 Nov 2018 12:38:27 +0100 > This series implements GRO support for UDP sockets, as the RX counterpart > of commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT"). > The core functionality is implemented by the second patch, introducing a new > sockopt to enable UDP_GRO, while patch 3 implements support for passing the > segment size to the user space via a new cmsg. > UDP GRO performs a socket lookup for each ingress packets and aggregate datagram > directed to UDP GRO enabled sockets with constant l4 tuple. > > UDP GRO packets can land on non GRO-enabled sockets, e.g. due to iptables NAT > rules, and that could potentially confuse existing applications. > > The solution adopted here is to de-segment the GRO packet before enqueuing > as needed. Since we must cope with packet reinsertion after de-segmentation, > the relevant code is factored-out in ipv4 and ipv6 specific helpers and exposed > to UDP usage. > > While the current code can probably be improved, this safeguard ,implemented in > the patches 4-7, allows future enachements to enable UDP GSO offload on more > virtual devices eventually even on forwarded packets. > > The last 4 for patches implement some performance and functional self-tests, > re-using the existing udpgso infrastructure. The problematic scenario described > above is explicitly tested. > > This revision of the series try to address the feedback provided by Willem and > Subash on previous iteration. Series applied.