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; [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
