Re: ucma question - backlog limit

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

On 08/09/2010 12:51 PM, Hefty, Sean wrote:
>> I agree.  I think it should default to say 1024.  Further, I propose we
>> make this a sysctl variable such that admins can tweak it as needed.
>>      
> The default is based on:
>
> #define SOMAXCONN       128
>
> I have no objection to making it adjustable.
>
> - Sean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    


For TCP, a dropped SYN will cause the peer to retransmit the SYN, and 
the connection will be eventually established.  So a small backlog limit 
is probably ok for TCP.  With iWARP, the connect request is TCP payload 
an on established connection.  So the connection request is transmitted 
and acked at the TCP level by the time the connect request gets dropped 
in the ucma.  What finally happens is the peer times out (after many 
seconds typically) and kills the connection.  Further, a 32 node 256NP 
OpenMPI job will generate > 128 connect requests on some ranks.

So I think its reasonable to up default max value.   I'll post a patch 
to change the max and make it a sysctl variable as well.

Ok?

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html