[ofa-general] rdma cm timeout option, was [iWARP issues]

[Kanevsky, Arkady]

The longer timeout is what I was after.
If server need to do fair amount of setup before
responding to connection request it times out on the client.

Even if RDMA_CM runs on top of TCP it does not help
since RDMA client will get a signal that timeout expired.

So I was looking for extension to API so client can specify longer
timeout. 

Thanks,

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance Inc.               phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
Waltham, MA 02451                   central phone: 781-768-5300
 

> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com] 
> Sent: Friday, November 02, 2007 1:18 PM
> To: Talpey, Thomas; Sean Hefty
> Cc: OpenFabrics General
> Subject: [ofa-general] rdma cm timeout option, was [iWARP issues]
> 
> >I still don't understand why you would want to do this. TCP already 
> >implements the best timer you could hope for.
> 
> Because TCP isn't running on top of IB.  And IB doesn't 
> automatically establish connections for the user on the passive side.
> 
> >But, if all you want to do is abort an in-progress 
> connection attempt, 
> >can't you just run a timer to signal you and thereby interrupt the
> >connect(2) in progress?
> 
> Yes - that's one of the options I'm considering.  But either 
> the ULP can be responsible for canceling the connection 
> request, or the rdma cm can manage this for the user.
> 
> These are the possibilities that I see:
> 
> 1 Leave API unchanged.
> 2 Allow ULP to set number of connection retries.
> 3 Allow ULP to set connection timeout.
> 4 Allow ULP to set timeout per retry and number of retries.
> 
> The 1st option requires ULP to manage shorter timeouts.  From 
> what I can tell, the 2nd option matches a non-portable Linux 
> setsockopt() capability.  The 3rd and 4th options can be 
> applied to IB connections, but do not easily extend to iWarp.
> 
> Of these, I'm leaning towards the first option.  But this 
> doesn't allow for longer timeouts.
> 
> - Sean
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>