Sean, The assumption here is that user space library prepares the vendor specific data in user-space using a shared page allocated by vendor driver. Here information about posted buffers is passed not through ib_wr but using the shared page. It is a reason why pointers indicating ib_wr in post_send are not set, they are not passed to kernel at all to avoid copying them in kernel.
As there is no ib_wr structure in kernel there is no reference to bad_wr and a buffer that failed in this context so the only reasonable information about operation state passed using bad_wr could be return of binary information - operation successful (bad_wr = 0) or not (bad_wr != 0) Instead of using a specific case for RAW_QP it is possible to pass some information about posting buffers method by enum ib_qp_create_flags { IB_QP_CREATE_IPOIB_UD_LSO = 1 << 0, IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK = 1 << 1 }; Extending it with IB_QP_CREATE_USE_SHARED_PAGE = 1 << 2, In that case a new method could be used for any type of QP and will be backward compatible. Regards, Mirek -----Original Message----- From: Hefty, Sean Sent: Friday, January 21, 2011 4:50 PM To: Walukiewicz, Miroslaw; Roland Dreier Cc: Or Gerlitz; Jason Gunthorpe; linux-rdma@vger.kernel.org Subject: RE: ibv_post_send/recv kernel path optimizations > + qp = idr_read_qp(cmd.qp_handle, file->ucontext); > + if (!qp) > + goto out_raw_qp; > + > + if (qp->qp_type == IB_QPT_RAW_ETH) { > + resp.bad_wr = 0; > + ret = qp->device->post_send(qp, NULL, NULL); This looks odd to me and can definitely confuse someone reading the code. It adds assumptions to uverbs about the underlying driver implementation and ties that to the QP type. I don't know if it makes more sense to key off something in the cmd or define some other property of the QP, but the NULL parameters into post_send are non-intuitive. > + if (ret) > + resp.bad_wr = cmd.wr_count; Is this always the case? - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html