<div>Hi again,</div><div><br></div>On Fri, Sep 17, 2010 at 3:11 PM, Lars Ellenberg <span dir="ltr"><<a href="mailto:lars.ellenberg@linbit.com" target="_blank">lars.ellenberg@linbit.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Fri, Sep 17, 2010 at 02:12:35PM -0500, J. Ryan Earl wrote:<br> > Is this the fix to which you refer?<br>
> <a href="http://www.mail-archive.com/general@lists.openfabrics.org/msg10615.html" target="_blank">http://www.mail-archive.com/general@lists.openfabrics.org/msg10615.html</a><br>
<br>
</div></div>That's certainly relevant as well,<br>
but it would have returned EAFNOSUPPORT, which is 97.<br></blockquote><div><br></div><div>I'm going through the code and that patch is already included anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
I doubt that this has anything to do with performance, btw,<br>
it is just the address lookup during connect.<br></blockquote><div><br></div><div>Oh, that blows then.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My guess is if you strace a netcat in userland, using your sdp preload<br>
thingy, you'll likely see that it only creates the socket as<br>
AF_INET_SDP, but all the rest of the network functions keep using<br>
AF_INET, so no-one ever noticed. If that is intentional, we'd have to<br>
adjust that in DRBD. If not, it needs to be fixed in the sdp stack.<br></blockquote><div><br></div><div>It seems to intercept AF_INET. The LD_PRELOAD doesn't change the strace except for opening the shared object.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
DRBD over SDP performance tuning is a bit tricky,<br>
and no, I don't remember the details, it's been a while.<br>
<br>
I think cpu usage dropped considerable, thats a plus. But neither<br>
single write latency nor sequential throughput of a single connection<br>
improved much or even degraded respective to IPoIB. If you have<br>
multiple DRBD, thus multiple connections, the cumulative throughput<br>
scaled better, though.<br></blockquote><div><br></div><div>Actually CPU usage went up. The wall time was 50% longer with 10% more CPU time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But please go ahead and tune your stack, on your hardware, which may be<br>
more capable than the test lab hardware we used.<br>
Depending on your hardware, and the quality recommendations of<br>
your SDP tuning expert, your findings may be different.<br></blockquote><div><br></div><div>I'm not sure how to tune SDP, but I'll look into it. ssocks when I tried didn't seem to need tuning. With 2 ports, I was getting better performance than with IB and SDP, though it had other issues.</div>
<div><br></div><div>Thanks!</div><div>-JR</div></div>