[openib-general] RE: rdma_cm.h: comment nits.

[Caitlin Bestler]

Tom Tucker wrote:
> On Thu, 2006-05-11 at 10:56 +0300, Michael S. Tsirkin wrote:
>> Quoting r. Tom Tucker <tom at opengridcomputing.com>:
>>> Subject: RE: rdma_cm.h: comment nits.
>>> 
>>> On Wed, 2006-05-10 at 14:20 -0700, Caitlin Bestler wrote:
>>>> Tom Tucker wrote:
>>>> 
>>>>> 
>>>>> So... all that said, I could in fact support rdma_reject on an
>>>>> active side connection. But this would effectively reduce to a
>>>>> QP --> ERROR and I doubt this matches the semantics you're
>>>>> looking for. 
>>>>> 
>>>>> 
>>>> 
>>>> And you could send an RST.
>>> 
>>> Yep, in fact that's what many RNIC's do when you move the QP to
>>> ERROR instead of CLOSING. 
>>> 
>>>> There's just no way to send any user supplied private data. It's
>>>> not just unreliable, it's guaranteed not to arrive. It's still a
>>>> long way from the truly desired semantics, but the wire protocol
>>>> just doesn't carry that info. 
>>>> 
>>> 
>>> Yeah, I think you're correct -- it would be a bogus "emulation".
>> 
>> I don't think any real ULP passes private data inside the Reject.
> 
>> 
>> Private data in response (SYN/ACK) is clearly portable, is it not?
> 
> For iWARP the data is actually exchanged after TCP connection
> establishment as part of MPA negotiation. But yes, private
> data exchange is supported during connection establishment.
> It can be provided on the active side (rdma_connect) and on
> the passive side (rdma_accept, rdma_reject). What is not
> currently supported is calling rdma_connect and then
> rdma_reject (presumably to cancel the connect request after
> receiving the remote peers private data). The supported
> behavior for iWARP on the active side would be to call
> rdma_disconnect if you didn't like the private data provided.


A good summary.

The very minimal benefit to a transport neutral applicatiaon here
is the ability to cancel a connection before it is established
without destroying the QP.

This is nice in theory, but I doubt that there are many applications
that need to cancel connection requests for a reason other than 
shutting down -- and none that need to do this so frequently that
destroying the QP would be an unacceptable overhead.

So this really comes down to whether the application should be able
to request the unreliable delivery of the private data, when in fact
it is *more* than unreliable over iWARP. It's definitely approaching
transport neutral syntax with transport specific semantics.