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

[Talpey, Thomas]

At 01:17 PM 11/2/2007, Sean Hefty wrote:
>>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.

Sure, the CM needs a timeout when handling its own transport connections
as it does over native IB. But if it's running over timeout-aware transports
such as TCP, I think it should defer to them.

>>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.

Options 2 and 4 are not a good solution, IMO. They don't actually specify a
timeout and depend on events beyond the ULP's control. So, my opinion is
that it's down to #3.

Is the rdma_connect() API interruptible? I.e. if the connection is running
in an application with a TTY associated, does it abort if the user types ^C?
What else causes the CM client to abort?

Tom.

>
>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