The data required when doing a qp-modify-to-rts is inherently transport specific. IB requires a set of data obtained from the IB CM protocol (or the equivalent data through application specific black magic), while iWARP requires a handle for a TCP connection (assumed to be a socket, but not explicitly required to be so).
The problem is that when the RDMAC specified the iWARP modify qp to RTS behaviour they did not forsee the non-technical barriers to simply using a socket handle to specify transfer of ownership of a TCP connection from one stack to another. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of James Lentini > Sent: Thursday, August 25, 2005 7:54 AM > To: Roland Dreier > Cc: [email protected] > Subject: Re: [openib-general] RDMA connection and address > translation API > > > > On Wed, 24 Aug 2005, Roland Dreier wrote: > > > Sean> Is the idea that the user calls connect() and > then receives > > Sean> a single callback indicating that the connection has been > > Sean> established? If so, then the user may need to > modify the QP > > Sean> to the INIT state, which would require some knowledge > > Sean> already of the path. We would also need to be clear on > > Sean> whether the QP is expected to be in the INIT state before > > Sean> connect is called, or if it could be in any > arbitrary state. > > Sean> The other alternative is to provide multiple callbacks > > Sean> during connection establishment. > > > > To me it makes sense for the generic CM API to be defined > so that an > > IB QP must be in the INIT state before being passed to connect(). > > Will the ib_modify_qp() function be made transport neutral? I > see some fields in the ib_qp_attr structure that are IB specific. > > I think the RDMA connection API should perform all the QP > state transitions for the ULP. How about a new call to create > the QP and perform all QP state transitions necessary for the > posting receive work requests? > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
