Re: [PATCH RFC 2/2] RDMA/isert: Support iWARP transport

Sagi Grimberg
2015-06-27T09:33:04Z

On 6/25/2015 10:29 PM, Jason Gunthorpe wrote:
> On Thu, Jun 25, 2015 at 02:25:49PM -0500, Steve Wise wrote:
>
>> To stage the changes we could introduce a new function that returns
>> the needed ib_access_flags value given the desired opcodes. Then
>> have a series that changes all the existing ULPs to make use of this
>> new function.
>
> I wouldn't be afraid to add a new create_mr entry point that does the
> right thing, we can unexport/delete the old one when all kernel users
> are gone. Trivially the core can just have a default that translates
> based on iwarp/!iwarp for now.
>

Note that we have ib_create_mr() that receives an easily extensible
ib_mr_init_attr (similar to qp creation). I think this is a good
opportunity to unite all the create routines to ib_create_mr.

ib_get_dma_mr will become:
ib_mr_init_attr.type = IB_MR_DMA;
ib_mr_init_attr.mr_access_flags = mr_access_flags;
ib_create_mr(pd, &ib_mr_init_attr);

ib_alloc_fast_reg_mr will become:
ib_mr_init_attr.type = IB_MR_FAST_REG;
ib_create_mr(pd, &ib_mr_init_attr);

ib_reg_phys_mr (if we don't want to kill it by now) will become:
ib_mr_init_attr.type = IB_MR_REG_PHYS;
ib_mr_init_attr.arr = phys_buf_array;
ib_mr_init_attr.max_reg_descriptors = num_phys_buf;
ib_mr_init_attr.mr_access_flags = mr_access_flags;
ib_mr_init_attr.iova_start = iova_start;
ib_create_mr(pd, &ib_mr_init_attr);

The core layer will spread these in the different driver routines
(although it would be nice if the drivers can have a single MR craetion
routine that can handle all MR types (including fail if unsupported).

Thoughts?