I've been messing about with the latest netperf, and by accident specified -D
for TCP_NODELAY on a UDP_RR test. In the past, and even today on HP-UX at
least, that results in an error on the setsockopt(). However, with the
getaddrinfo() changes to netperf and the addtion of SCTP support, setsockopt()
is now called with the ai_protocol from the getaddrinfo() call rather than a
hard-coded IPPROTO_TCP. Sooo, for UDP tests that becomes an IPPROTO_UDP.
When I run the UDP_RR test with -D set on a 2.6 kernel, netperf stops cold until
the test timer expires.
It seems there is an overlap in the setsockopt() option numbers between TCP and
UDP under Linux 2.6 at least, I've not gone back to check 2.4. TCP_NODELAY and
UDP_CORK are both defined as "1". Those seem to be the only two options that
overlap. The other UDP_mumble option is defined to be 100, which is presently
outside the range of the TCP_mumble options. So, instead of trying to set
TCP_NODELAY on a UDP socket, which would fail; netperf was unwittingly setting
UDP_CORK on a UDP socket, which would succede.
Is UDP_CORK going to be an ongoing feature? Is it a "real" feature today? While
man tcp described TCP_CORK, on the two places I've checked thusfar, man udp does
not describe UDP_CORK. I'm not sure if that means UDP_CORK is "unreal" or just
that the udp manpage needs repair (or was out of date on my systems).
I _can_ go in and have netperf check for IPPROTO_TCP and/or IPPROTO_SCTP before
making the _NODELAY setsockopt, and I suppose I probably should, but if UDP_CORK
isn't going to be around, or if TCP and UDP socket options were not _really_
meant to overlap... although the level option would seem to be there to allow it...