is UDP_CORK "real"

is UDP_CORK "real"

[Rick Jones]

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

Re: is UDP_CORK "real"

[David S. Miller]

On Thu, 21 Apr 2005 16:14:56 -0700
Rick Jones <rick.jones2@hp.com> wrote:

> Is UDP_CORK going to be an ongoing feature?

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?

Re: is UDP_CORK "real"

[Rick Jones]

David S. Miller wrote:
> On Thu, 21 Apr 2005 16:14:56 -0700
> Rick Jones <rick.jones2@hp.com> wrote:
> 
> 
>>Is UDP_CORK going to be an ongoing feature?
> 
> 
> 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

Re: is UDP_CORK "real"

[Andi Kleen]

Rick Jones <rick.jones2@hp.com> writes:
> 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).

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

Re: is UDP_CORK "real"

[Michael Kerrisk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1621 bytes --]

> Rick Jones <rick.jones2@hp.com> writes:
> > 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).
> 
> 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.

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

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

Yes, unfortunately.

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

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: mtk-manpages@gmx.net

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

network manpages was Re: is UDP_CORK "real"

[Andi Kleen]

On Wed, Apr 27, 2005 at 03:28:53PM +0930, Glen Turner wrote:
> Please mail me with what you think is required here.  I've
> been getting grief from our high performance users on
> exactly this point (and the sysctl maze of twisty options)

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

Re: network manpages was Re: is UDP_CORK "real"

[David S. Miller]

On 27 Apr 2005 14:26:48 +0200
Andi Kleen <ak@muc.de> wrote:

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

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.

Re: network manpages was Re: is UDP_CORK "real"

[Andi Kleen]

On Wed, Apr 27, 2005 at 11:43:23AM -0700, David S. Miller wrote:
> On 27 Apr 2005 14:26:48 +0200
> Andi Kleen <ak@muc.de> wrote:
> 
> > 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.
> 
> 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.

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

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

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

-Andi