From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tushar Dave Subject: Re: [PATCH RFC net-next 00/11] udp gso Date: Fri, 20 Apr 2018 11:27:48 -0700 Message-ID: <5195a7d9-7b7d-044b-0031-6fa13c0fe48a@oracle.com> References: <74f0b490-de65-f05a-6332-6deaeb0fac2a@intel.com> <20180418123103.GC19633@oracle.com> <20180418.132808.1710130437020293308.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sowmini Varadhan , Willem de Bruijn , "Samudrala, Sridhar" , Netdev , Willem de Bruijn To: Alexander Duyck , David Miller Return-path: Received: from userp2130.oracle.com ([156.151.31.86]:41120 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753587AbeDTS2U (ORCPT ); Fri, 20 Apr 2018 14:28:20 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 04/18/2018 11:12 AM, Alexander Duyck wrote: > On Wed, Apr 18, 2018 at 10:28 AM, David Miller wrote: >> 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. > > My only concern with the patch set is verifying what mitigations are > in case so that we aren't trying to set an MSS size that results in a > frame larger than MTU. I'm still digging through the code and trying > to grok it, but I figured I might just put the question out there to > may my reviewing easier. > > Also any plans for HW offload support for this? I vaguely recall that > the igb and ixgbe parts had support for something like this in > hardware. I would have to double check to see what exactly is > supported. Alex, If by HW support you meant UFO (UDP Fragmentation Offload), then I have dig into that last year using ixgbe. And I found that Intel 10G HW does break large UDP packets into MTU size however it does not generate *true* IP fragments. Instead, when large (> MTU) size UDP packet is given to NIC, HW generates unique UDP packets with distinct IP fragments. This makes it impossible for receiving station to reassemble them into one UDP packet. I am not sure about igb! -Tushar > > Thanks. > > - Alex >