why does DCCP SO_REUSEADDR have to be SOL_DCCP?

why does DCCP SO_REUSEADDR have to be SOL_DCCP?

[Rick Jones]

Hi -

I'm tweaking the netperf omni tests to be able to run over DCCP.  I've 
run across a not-unorecedented problem with getaddrinfo() not groking 
either SOCK_DCCP or IPPROTO_DCCP in the hints, and that I can more or 
less live with - I had to do a kludge for getaddrinfo() for IPPROTO_SCTP 
under Linux at one point and I can see how the two are not necessarily 
going to be in sync.

And I've worked-around no user-level include files (ie without setting 
__KERNEL__) define the DCCP stuff, and that is OK too, albeit somewhat 
inconvenient.

My question though is why on earth does an SO_REUSEADDR setsockopt() 
against a DCCP socket have to be SOL_DCCP?  SCTP and TCP are quite happy 
with SOL_SOCKET, and it might be foolish consistency, but since the 
option _does_ begin with SO_ I'd have expected it to work for 
SOL_SOCKET, but (again RHEL5.1, yes, I do plan on getting upstream but 
have to satisfy several masters) it doesn't seem to be the case - a 
subsequent listen() or connect() call after an SOL_SOCKET SO_REUSEADDR 
against a DCCP socket leaves one SOL as it were...

Of course the setsockopt(SO_REUSEADDR) against the DCCP socket using 
SOL_SOCKET itself doesn't fail, only the later listen() or connect() call...

happy benchmarking,

rick jones

Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?

[Arnaldo Carvalho de Melo]

Em Fri, Feb 01, 2008 at 05:42:23PM -0800, Rick Jones escreveu:
> Hi -
>
> I'm tweaking the netperf omni tests to be able to run over DCCP.  I've run 
> across a not-unorecedented problem with getaddrinfo() not groking either 
> SOCK_DCCP or IPPROTO_DCCP in the hints, and that I can more or less live 
> with - I had to do a kludge for getaddrinfo() for IPPROTO_SCTP under Linux 
> at one point and I can see how the two are not necessarily going to be in 
> sync.

See the ttcp patch where we do a xgetaddrinfo crude hack to handle dccp:

http://vger.kernel.org/~acme/dccp/ttcp.c

> And I've worked-around no user-level include files (ie without setting 
> __KERNEL__) define the DCCP stuff, and that is OK too, albeit somewhat 
> inconvenient.

Humm, for what? Again, see the ttcp code above:

> My question though is why on earth does an SO_REUSEADDR setsockopt() 
> against a DCCP socket have to be SOL_DCCP?  SCTP and TCP are quite happy 
> with SOL_SOCKET, and it might be foolish consistency, but since the option 
> _does_ begin with SO_ I'd have expected it to work for SOL_SOCKET, but 
> (again RHEL5.1, yes, I do plan on getting upstream but have to satisfy 
> several masters) it doesn't seem to be the case - a subsequent listen() or 
> connect() call after an SOL_SOCKET SO_REUSEADDR against a DCCP socket 
> leaves one SOL as it were...

Strange, lemme check...

 1. sys_socketcall ->
 2.  sys_setsockopt ->
 3.    if (level == SOL_SOCKET) {
 4.      sock_setsockopt:
 5.        case SO_REUSEADDR:
 6.          sk->sk_reuse = valbool;
 7.    } else
 8.      sock->ops->setsockopt = inet_dccp_ops->setsockopt =
 9.        inet_dccp_ops->setsockopt = sock_common_setsockopt ->
10.          sk->sk_prot->setsockopt = dccp_v4_prot->setsockopt =
11.	    dccp_setsockopt
12.              if (level != SOL_DCCP)
13.                return inet_csk(sk)->icsk_af_ops->setsockopt() =
14.		  ip_setsockopt
15.              return do_dccp_setsockopt()

SO_REUSEADDR is handled in 4, if you pass SOL_SOCKET.

If instead you pass SOL_DCCP we'll go down the rabbit hole till
do_dccp_setsockopt() and SO_REUSEADDR, that is equal to 2, will be
interpreted as DCCP_SOCKOPT_SERVICE, that is also equal to 2, so you'll
be setting the service, not changing the SO_REUSEADDR setting.

The problem here is that you need to use:

setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_PACKET_SIZE, service,
           sizeof(service));

Again, take a look at the ttcp patch, the other patches for iperf,
netcat, etc handles this.

> Of course the setsockopt(SO_REUSEADDR) against the DCCP socket using 
> SOL_SOCKET itself doesn't fail, only the later listen() or connect() 
> call...
>
> happy benchmarking,

Look forward for a happy DCCP netperf bencharking session!

Thanks a lot,

- Arnaldo

Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?

[Arnaldo Carvalho de Melo]

Em Sat, Feb 02, 2008 at 12:52:59AM -0200, Arnaldo Carvalho de Melo escreveu:
> If instead you pass SOL_DCCP we'll go down the rabbit hole till
> do_dccp_setsockopt() and SO_REUSEADDR, that is equal to 2, will be
> interpreted as DCCP_SOCKOPT_SERVICE, that is also equal to 2, so you'll
> be setting the service, not changing the SO_REUSEADDR setting.
> 
> The problem here is that you need to use:
> 
> setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_PACKET_SIZE, service,
>            sizeof(service));

Further info on DCCP service codes:

http://www.rfc.net/rfc4340.txt -> "8.1.2.  Service Codes"
 
> Again, take a look at the ttcp patch, the other patches for iperf,
> netcat, etc handles this.

- Arnaldo

Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?

[Rick Jones]

Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 01, 2008 at 05:42:23PM -0800, Rick Jones escreveu:
> 
>>Hi -
>>
>>I'm tweaking the netperf omni tests to be able to run over DCCP.  I've run 
>>across a not-unorecedented problem with getaddrinfo() not groking either 
>>SOCK_DCCP or IPPROTO_DCCP in the hints, and that I can more or less live 
>>with - I had to do a kludge for getaddrinfo() for IPPROTO_SCTP under Linux 
>>at one point and I can see how the two are not necessarily going to be in 
>>sync.
> 
> 
> See the ttcp patch where we do a xgetaddrinfo crude hack to handle dccp:
> 
> http://vger.kernel.org/~acme/dccp/ttcp.c

That is basically what netperf ends-up doing presently, although it is 
much more vocal about it :)

>>And I've worked-around no user-level include files (ie without setting 
>>__KERNEL__) define the DCCP stuff, and that is OK too, albeit somewhat 
>>inconvenient.
> 
> 
> Humm, for what? Again, see the ttcp code above:

I see that it too is making a guess for the DCCP defines.  I prefer to 
get those from the "regular" include files because several of them can 
be platform specific and netperf happens on many platforms.  If DCCP is 
still "experimental" I suppose that living with defines not being in 
user-level includes is to be expected.

>>My question though is why on earth does an SO_REUSEADDR setsockopt() 
>>against a DCCP socket have to be SOL_DCCP?  SCTP and TCP are quite happy 
>>with SOL_SOCKET, and it might be foolish consistency, but since the option 
>>_does_ begin with SO_ I'd have expected it to work for SOL_SOCKET, but 
>>(again RHEL5.1, yes, I do plan on getting upstream but have to satisfy 
>>several masters) it doesn't seem to be the case - a subsequent listen() or 
>>connect() call after an SOL_SOCKET SO_REUSEADDR against a DCCP socket 
>>leaves one SOL as it were...
> 
> 
> Strange, lemme check...
> 
>  1. sys_socketcall ->
>  2.  sys_setsockopt ->
>  3.    if (level == SOL_SOCKET) {
>  4.      sock_setsockopt:
>  5.        case SO_REUSEADDR:
>  6.          sk->sk_reuse = valbool;
>  7.    } else
>  8.      sock->ops->setsockopt = inet_dccp_ops->setsockopt =
>  9.        inet_dccp_ops->setsockopt = sock_common_setsockopt ->
> 10.          sk->sk_prot->setsockopt = dccp_v4_prot->setsockopt =
> 11.	    dccp_setsockopt
> 12.              if (level != SOL_DCCP)
> 13.                return inet_csk(sk)->icsk_af_ops->setsockopt() =
> 14.		  ip_setsockopt
> 15.              return do_dccp_setsockopt()
> 
> SO_REUSEADDR is handled in 4, if you pass SOL_SOCKET.
> 
> If instead you pass SOL_DCCP we'll go down the rabbit hole till
> do_dccp_setsockopt() and SO_REUSEADDR, that is equal to 2, will be
> interpreted as DCCP_SOCKOPT_SERVICE, that is also equal to 2, so you'll
> be setting the service, not changing the SO_REUSEADDR setting.

That is completely unexpected.  Particularly based on the implications of:

http://www.linux-foundation.org/en/Net:DCCP

> 
> The problem here is that you need to use:
> 
> setsockopt(fd, SOL_DCCP, DCCP_SOCKOPT_PACKET_SIZE, service,
>            sizeof(service));

I guess since I was going off the URL above and it doesn't mention 
that... :)  I was just blythly ass-u-me-ing that DCCP was usable as a 
"just swap the IPPROTO in your socket() call and go" sort of thing. And 
wasn't expecting to have to make additional setsockopt() calls.

> Look forward for a happy DCCP netperf bencharking session!

Looks like some very basic stuff (whatever one gets passing SOL_DCCP to 
the SO_REUSEADDR setting) is functioning in the top of trunk.  I now 
have to think about what to do wrt DCCP service types.  If I should add 
something to the parsing of -T dccp or if I should add yet another 
command-line option :)

happy benchmarking,

rick jones