Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?
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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
why does DCCP SO_REUSEADDR have to be SOL_DCCP?
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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?
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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does DCCP SO_REUSEADDR have to be SOL_DCCP?
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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html