On Thu, 2006-03-02 at 23:40 +0200, Michael S. Tsirkin wrote: > Quoting r. Caitlin Bestler <[EMAIL PROTECTED]>: > > The consumer can post receive buffers as soon as the QP > > is created. Send buffers cannot be posted until the > > consumer has been notified that the connection is established. > > I'm talking about cma_modify_qp_rtr here. > On the receive side, I might need the data from REP to post receives.
Ok, but there is no RTR state for an iWARP QP. This is what Caitlin means by "explicit state control is not transport neutral". We have an issue today because the ucma manages QP state explicitly. I didn't want to futz with the user mode code (I wanted it to be transport neutral), so in the context of the CMA I simply treat RTR as another IDLE state in iWARP. The point being that transport neutral apps should us rdma_create_qp and let the CMA walk the QP state machine thereby hiding transport differences. > > > Applications that attempt to tune parameters based upon > > presumptions of how drivers work, rather than in terms > > of their requirements/expectations of the driver, are > > always fragile. > > Yes but if an app works for TCP people expect it to work for e.g. sockets > direct. > Perhaps, but IMHO SDP is not a transport neutral ULP. I _know_ I'm going to get flamed for saying this, but it doesn't seem particularly lucent to encapsulate a byte stream in three protocol layers, and four API layers so that you can emulate a byte stream. But I have been told many times that it is not only perfectly reasonable, it's brilliant. Maybe it's just me ;-) _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
