From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Rick Jones <rick.jones2@hp.com>
Cc: Linux Network Development list <netdev@vger.kernel.org>
Subject: Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?
Date: Sat, 2 Feb 2008 00:52:59 -0200 [thread overview]
Message-ID: <20080202025259.GH17164@ghostprotocols.net> (raw)
In-Reply-To: <47A3CA7F.8040300@hp.com>
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
next prev parent reply other threads:[~2008-02-02 2:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 1:42 why does DCCP SO_REUSEADDR have to be SOL_DCCP? Rick Jones
2008-02-02 2:52 ` Arnaldo Carvalho de Melo [this message]
2008-02-02 3:02 ` Arnaldo Carvalho de Melo
2008-02-04 18:46 ` Rick Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080202025259.GH17164@ghostprotocols.net \
--to=acme@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.