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
