[netperf-talk] SCTP and Nagle's Algorithm

Rick Jones rick.jones2 at hp.com
Thu Jul 5 13:48:21 PDT 2007


Chris Lydick wrote:
> Rick,
> 
> Thanks for the reply. To cut down on the extent of the text file, here's
> a little before and a after the setsockopt() call.
> 
> ..
> write(1, "SCTP STREAM TEST from 0.0.0.0 (0"..., 105) = 105
> socket(PF_INET, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 4
> getsockopt(4, SOL_SOCKET, SO_SNDBUF, [110592], [4]) = 0
> getsockopt(4, SOL_SOCKET, SO_RCVBUF, [110592], [4]) = 0
> setsockopt(4, 0x84 /* SOL_?? */, 1, [1], 4) = -1 EINVAL (Invalid
> argument)
> write(1, "netperf: create_data_socket: nod"..., 47) = 47
> setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(4, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> brk(0x80c7000)                          = 0x80c7000
> send(3, "\0\0\1\364\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 256, 0) = 256
> ..

So, here is the corresponding source code:

#if defined(TCP_NODELAY) || defined(SCTP_NODELAY)
   if ((loc_nodelay) && (res->ai_protocol != IPPROTO_UDP)) {

     /* strictly speaking, since the if defined above is an OR, we
        should probably check against TCP_NODELAY being defined here.
        however, the likelihood of SCTP_NODELAY being defined and
        TCP_NODELAY _NOT_ being defined is, probably :), epsilon.  raj
        2005-03-15 */

     int option = TCP_NODELAY;

     /* I suspect that WANT_SCTP would suffice here since that is the
        only time we would have called getaddrinfo with a hints asking
        for SCTP, but just in case there is an SCTP implementation out
        there _without_ SCTP_NODELAY... raj 2005-03-15 */

#if defined(WANT_SCTP) && defined(SCTP_NODELAY)
     if (IPPROTO_SCTP == res->ai_protocol) {
       option = SCTP_NODELAY;
     }
#endif

     one = 1;
     if(setsockopt(temp_socket,
		  res->ai_protocol,
		  option,
		  (char *)&one,
		  sizeof(one)) == SOCKET_ERROR) {
       fprintf(where,
	      "netperf: create_data_socket: nodelay: errno %d\n",
	      errno);
       fflush(where);
     }


Well, I guess there's an enhancement request/bug to file against strace 
- teach it about the protocol number for SCTP, because I suspect that is 
what 0x84 happens to be and in res->ai_protocol.


This may also be related to why the EINVAL - you mentioned something 
about user space libraries - how about stuff in the kernel?  I'm still 
really weak on SCTP implementation knowledge, but wonder if there is 
something missing from the kernel to grok an SOL_SCTP?  It is something 
of a reach/guess on my part though because I would have expected that if 
the socket creation went OK, that a setsockopt() with that protocol 
number would have worked also - perhaps a hole in a shim library not 
intercepting something it needed to?

> 
> For the full text file, I've uploaded it to the following location:
> 
> http://tinyurl.com/2qn46d

We probably don't need that but thanks,

happy benchmarking,

rick jones


More information about the netperf-talk mailing list