On Thu, Jun 25, 2015 at 04:29:17PM -0500, Steve Wise wrote:
> - * ib_dma_mapping_error - check a DMA addr for error
> + * rdma_mr_roles - possible roles a MR will be used for
> + *
> + * This allows a transport independent RDMA application to
> + * create MRs that are usable for all the desired roles w/o
> + * having to understand which access rights are needed.
> + */
> +enum rdma_mr_roles {
> + RDMA_MRR_RECV = 1,
> + RDMA_MRR_SEND = (1<<1),
> + RDMA_MRR_READ_SOURCE = (1<<2),
> + RDMA_MRR_READ_SINK = (1<<3),
> + RDMA_MRR_WRITE_SOURCE = (1<<4),
> + RDMA_MRR_WRITE_SINK = (1<<5),
> + RDMA_MRR_ATOMIC = (1<<6),
> + RDMA_MRR_MW_BIND = (1<<7),
> + RDMA_MRR_ZERO_BASED = (1<<8),
> + RDMA_MRR_ACCESS_ON_DEMAND = (1<<9),
So we don't have this problem again, it would be best to explicitly
list exactly which ib_wc_opcode members what use a RKEY are matched to
which MMR flags
RDMA_MRR_RECV
LOCAL: post to receive work queue
RDMA_MRR_READ_SOURCE
LOCAL: post IB_WC_RDMA_READ to send work queue
RDMA_MRR_READ_SINK
REMOTE: respond to IB_WC_RDMA_READ
[..]
Seems reasonable to me otherwise
Jason
--
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
