is UDP_CORK "real"

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...

thanks,

rick jones

Yes, it's there and it's real.

If netperf is passing a TCP socket option number in for a setsockopt() on a UDP socket, how in the world is that the kernel's problem?

I didn't really mean to say that it was a kernel problem per se. I was trying to understand the space, make sure that it was deliberate that there were actual overlaps between the TCP_mumble and UDP_mumble options and such. The release bits for netperf 2.4.0 will have checks to make sure it does not try to set "TCP_NODLEAY" on a UDP socket. Call it a 13 year lingering misfeature in netperf if you like :)

rick jones

AFAIK nobody has been updating the protocol manpages since I stopped doing so several years ago when they were included into the standard manpages. There are lots of missing features etc. that could be documented, the BUGS sections are usually out of date etc. It is roughly at the state of early 2.3.

There is also unfortunately no policy to require a manpage update when a new feature is added to the kernel.

Some manpages have been even never fully written like the ipv6 manpage. Perhaps someone is interested in updating all these? It unfortunately needs quite a lot of RTFS to figure out what the code actually does.

-Andi

I make ocassional changes, as far as my knowledge permits. But there's lots that I don't know...

Yes, unfortunately.

I welcome all such patches, which will go into the standard man-pages set (get the latest set at ftp://ftp.win.tue.nl/pub/linux-local/manpages/ ). Please send patches to: [email protected]

In terms of checking people's input, it helps if you identify how the knowledge going into a patch was obtained, and perhaps point me at some relevant parts of the source.

Cheers,

Michael

+++ GMX - die erste Adresse für Mail, Message, More +++

10 GB Mailbox, 100 FreeSMS  http://www.gmx.net/de/go/topmail

sysctl is mostly documented in Documentation/*.
Also the sysctls change sometimes, so I am not sure it is a good idea to put them into the manpages which are supposed to be more version independent. At least I would only put the more important ones there.

In particular the ipv6 protocol manpage needs a rewrite, it was only a relatively poor quick&dirty job. For the others it would be probably sufficient to just check what new ioctls/socket options are missing and document them and perhaps check if the NOTES/BUGS caveats still apply. An sctp manpage is also lacking I think, that was a completely new protocol.

It would be nice of course if David could enforce a policy to require a manpage patch for new ioctls/socket options etc. in the future, then such documentation lag would not happen.

-Andi

I could easily do this if the files were in the kernel tree itself, but since it's external it's not so easy to do.

Why don't we put them into the kernel tree? They are just small documents and I bet they will stay in sync better if they were moved into the kernel tree.

Hmm, you could ask them at least to submit a patch.

Well, you have to talk to Michael who maintains them now. I personally think it would be a good idea, yes.

-Andi