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 20:11:22 -0700 Message-ID: References: <74f0b490-de65-f05a-6332-6deaeb0fac2a@intel.com> <20180418123103.GC19633@oracle.com> <20180418.132808.1710130437020293308.davem@davemloft.net> <5195a7d9-7b7d-044b-0031-6fa13c0fe48a@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Miller , Sowmini Varadhan , Willem de Bruijn , "Samudrala, Sridhar" , Netdev , Willem de Bruijn To: Alexander Duyck Return-path: Received: from userp2130.oracle.com ([156.151.31.86]:50158 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750858AbeDTULw (ORCPT ); Fri, 20 Apr 2018 16:11:52 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 04/20/2018 01:08 PM, Alexander Duyck wrote: > On Fri, Apr 20, 2018 at 11:27 AM, Tushar Dave wrote: >> >> >> 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 > > Tushar, > > I am not sure you have been following this thread, but this is about > adding UDP GSO support, not fragmentation offload. With GSO support > the UDP frames are not expected to be reassembled they are meant to be > handled as individual frames. > > What you have described is why I am interested. This patch set adds > support for GSO segmentation, not fragmentation. I see. Never mind. Thanks. -Tushar > > Thanks. > > - Alex >