From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sowmini Varadhan Subject: Re: [PATCH RFC net-next 00/11] udp gso Date: Wed, 18 Apr 2018 08:31:03 -0400 Message-ID: <20180418123103.GC19633@oracle.com> References: <20180417200059.30154-1-willemdebruijn.kernel@gmail.com> <20180417201557.GA4080@oracle.com> <20180417204829.GK7632@oracle.com> <74f0b490-de65-f05a-6332-6deaeb0fac2a@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Samudrala, Sridhar" , Network Development , Willem de Bruijn To: Willem de Bruijn Return-path: Received: from aserp2120.oracle.com ([141.146.126.78]:42130 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752617AbeDRMbK (ORCPT ); Wed, 18 Apr 2018 08:31:10 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: I went through the patch set and the code looks fine- it extends existing infra for TCP/GSO to UDP. One thing that was not clear to me about the API: shouldn't UDP_SEGMENT just be automatically determined in the stack from the pmtu? Whats the motivation for the socket option for this? also AIUI this can be either a per-socket or a per-packet option? 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. One thought to recover from this: use the infra being proposed in https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-09 to include a new UDP TLV option that tracks datagram# (similar to IP ID) to help the receiver reassemble the UDP datagram and pass it up with the POSIX-conformant UDP message boundary. I realize that this is also not a perfect solution: as you point out, there are risks from packet re-ordering/drops- you may well end up just reinventing IP frag/re-assembly when you are done (with just the slight improvement that each "fragment" has a full UDP header, so it has a better shot at ECMP and RSS). --Sowmini