[openib-general] Re: CMA stuff

[Tom Tucker]

On Thu, 2006-03-02 at 23:40 +0200, Michael S. Tsirkin wrote:
> Quoting r. Caitlin Bestler <caitlinb at broadcom.com>:
> > 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 ;-)