Re: Kernel fast memory registration API proposal [RFC]

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Thu, Jul 16, 2015 at 03:21:04PM +0300, Sagi Grimberg wrote:
> I gotta say,
> 
> these suggestions of bool/write or supported_ops with a convert helper
> seem (to me at least) to make things more complicated.
> 
> Why not just set the the access_flags as they are?
> I want local use?
> set IB_ACCESS_LOCAL_WRITE
> I want a peer to read from me?
> set IB_ACCESS_REMOTE_READ
> I want a peer to write to me?
> IB_ACCESS_REMOTE_WRITE
> ...
> 
> isn't it much simpler?

I don't have a really strong preference, but I like the idea of using
the OP names because it means the API cannot be used wrong.

Ie this, is absolutely wrong:

 rdma_map_sg_lkey(..,IB_ACCESS_REMOTE_READ);

But this:

 rdma_map_sg_lkey(..,IB_ACCESS_REMOTE_WRITE);

Is only wrong on IB.

While,
 rdma_map_sg_lkey(..,RDMA_OP_RDMA_READ)

Is always right, and can never be used wrong, and thus is less
complicated (for the ULP).

> If we want to mask out iWARP difference, we use the Steve's
> roles_to_access() helper thing...

If that scheme exists, it's usage should be mandatory, IMHO.

However, iwarp needs more than just flag translation, it also can't
use the local_dma_lkey ..

If we can come to a scheme to support iWarp (wrappers!) then the
rdma_map_sg_lkey is largely an internal function and it can stick with
IB_ACCESS flags...

The main use of rdma_map_sg_lkey is to support iWarp's RDMA READ
requirement.

rdma_map_sg_rkey is the commonly used API, and I can't think of a reason
why it needs the roles buisness beyond symmetry..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html