Sean Hefty wrote: > >> Alternately, it would be reasonable to simply document that a receive >> completion *implied* a connection established event, and therefore >> the application could post to the send queue after it reaped a >> receive completion (or got a connection established event). > > The problem is that the QP is not in the RTS state, so cannot accept > sends. >
Well, I suppose if your adapter can be in a state where it has completed a receive work request for a connection but is not yet convinced that that connection is established then it would have to queue those work completions somewhere. If that is all you are proposing then I have no objections, an iWARP adapter can never be in such a state. But I am curious as to why completing a receive work request does not place the QP in the RTS state since the end-to-end QP pairing has obviously been confirmed, and therefore the QP can send. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
