On Wed, Apr 18, 2018 at 10:28 AM, David Miller <da...@davemloft.net> wrote: > From: Sowmini Varadhan <sowmini.varad...@oracle.com> > 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. Thanks. - Alex
