On Wed, Jul 08, 2015 at 01:32:05PM -0700, 'Christoph Hellwig' wrote: > On Wed, Jul 08, 2015 at 01:08:42PM -0600, Jason Gunthorpe wrote: > > Then, what is left is all remote MRs and maybe it will be clearer what > > to do about them then... > > From looking at that for a while the APIs needed seem pretty simple > to me from a consumer perspective: > > struct rdma_mr *rmda_alloc_mr(struct ib_pd *pd, unsigned int nr_pages); > void rdma_free_mr(struct rdma_mr *mr); The major trouble with that is that the new MR types work by posting work to the send queue, that work creates the MR. I don't know all the details of how those schemes work, but it doesn't look like it fits into this model ? Maybe if rdma_register_sg was the only API and it accepted a QP, under the hood it could re-use a pooled/create a non-queued (F)MR, or issue FRMR, or work with indirect? It would be nice if it is that simple :) Sagi, are FMRs, FRMRs and Indirect MRs documented any place? I can't recall off hand if FRMR was ever published by the IBTA? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
