[openib-general] CM private data

[Caitlin Bestler]

With a two-way handshake only the passive side accepts the 
connection request (it_ep_accept() or dat_cr_accept()). IT-API
defines an optional *three-way* handshake where the active
side must *also* call it_ep_accept() before the final connection
establishment can proceed.

This does not map to iWARP/MPA in any standard way, so
rather than defining a protocol to wrap the first handshake
private data, DAT decided to stick with only two-way 
handshaking.

There has been no screaming, so we can presume that
*most* applications find two-way handshaking acceptable.

However an IT-API provider is free to say that it supports
three-way handshaking, and I believe it is implied (if not
required) that InfiniBand providers do so.

What I do not know is if any actual applications have ever
made use of this capability, or if it is only a defensive
encoding of a protocol option into an API that prefers
not to avoid removal of options that are available at the
wire level. DAT emphasized providing a clean API for
transport neutral services, and so simply said "use
two-way handshaking".

In any event, if no support is going to be provided for
private data on the second it_ep_accept at the verb
layer then that should be explicitly documented, and
I'd suggest sending a 'heads up' to the IT-API authors,

On 5/19/05, Or Gerlitz <ogerlitz at voltaire.com> wrote:
> Caitlin> I believe that an IT-API it_ep_accept() supplies private data
> that it expects to be delivered to its peer when the three-way handshake
> option is selected.
> 
> Both IT-API it_ep_accept() and DAT dat_cr_accept() cause the provider at
> the passive side to send a --REP--,
> so how --RTU-- is related to the _accept calls?
> 
> I think you ment to say that exposing two-way handshake means that the
> consumer can not supply private data for
> the RTU as he is not aware of it (the RTU) being sent?
> 
> Or.
> 
> -----Original Message-----
> From: openib-general-bounces at openib.org
> [mailto:openib-general-bounces at openib.org] On Behalf Of Caitlin Bestler
> Sent: Thursday, May 19, 2005 2:16 AM
> To: Sean Hefty
> Cc: openib-general
> Subject: Re: [openib-general] CM private data
> 
> I believe that an IT-API it_ep_accept() supplies private data that it
> expects to be delivered to its peer when the three-way handshake option
> is selected.
> 
> DAT only exposes a two-way handshake, so there it never requires private
> data on the RTU.
> 
> I don't know if any IT-API applications actually require the three-way
> handshake.
> 
> 
> On 5/18/05, Sean Hefty <mshefty at ichips.intel.com> wrote:
> > Do any applications make use of the private data in these CM message:
> > RTU, MRA, or DREP?  I'm doubtful of the RTU or DREP, but not as sure
> of the MRA.
> >
> > Since no replies are generated in response to these messages, the CM
> > does not keep them after their sends complete.  However, it may need
> > to resend the messages.  For example, it will resend the RTU if a
> > duplicate REP is received.
> >
> > If no applications are using the private data, I will not worry about
> > storing the private data for the retransmissions at this time.
> >
> > - Sean
> > _______________________________________________
> > openib-general mailing list
> > openib-general at openib.org
> > http://openib.org/mailman/listinfo/openib-general
> >
> > To unsubscribe, please visit
> > http://openib.org/mailman/listinfo/openib-general
> >
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>