From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH RFC net-next 00/11] udp gso Date: Wed, 18 Apr 2018 13:28:08 -0400 (EDT) Message-ID: <20180418.132808.1710130437020293308.davem@davemloft.net> References: <74f0b490-de65-f05a-6332-6deaeb0fac2a@intel.com> <20180418123103.GC19633@oracle.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: willemdebruijn.kernel@gmail.com, sridhar.samudrala@intel.com, netdev@vger.kernel.org, willemb@google.com To: sowmini.varadhan@oracle.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:45766 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbeDRR2K (ORCPT ); Wed, 18 Apr 2018 13:28:10 -0400 In-Reply-To: <20180418123103.GC19633@oracle.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Sowmini Varadhan Date: Wed, 18 Apr 2018 08:31:03 -0400 > However, I share Sridhar's concerns about the very fundamental change > to UDP message boundary semantics here. There is actually no such thing > as a "segment" in udp, so in general this feature makes me a little > uneasy. Well behaved udp applications should already be sending mtu > sized datagrams. And the not-so-well-behaved ones are probably relying > on IP fragmentation/reassembly to take care of datagram boundary semantics > for them? > > As Sridhar points out, the feature is not really "negotiated" - one side > unilaterally sets the option. If the receiver is a classic/POSIX UDP > implementation, it will have no way of knowing that message boundaries > have been re-adjusted at the sender. There are no "semantics". What ends up on the wire is the same before the kernel/app changes as afterwards. The only difference is that instead of the application doing N - 1 sendmsg() calls with mtu sized writes, it's giving everything all at once and asking the kernel to segment. It even gives the application control over the size of the packets, which I think is completely prudent in this situation.