On 7/30/2015 8:25 PM, Jason Gunthorpe wrote:
On Thu, Jul 30, 2015 at 10:05:53AM -0500, Steve Wise wrote:
+int iser_assign_reg_ops(struct iser_device *device)
+{
+ struct ib_device_attr *dev_attr = &device->dev_attr;
+
+ /* Assign function handles - based on FMR support */
+ if (device->ib_device->alloc_fmr && device->ib_device->dealloc_fmr &&
+ device->ib_device->map_phys_fmr && device->ib_device->unmap_fmr) {
+ iser_info("FMR supported, using FMR for registration\n");
+ device->reg_ops = &fmr_ops;
+ } else
+ if (dev_attr->device_cap_flags & IB_DEVICE_MEM_MGT_EXTENSIONS) {
+ iser_info("FastReg supported, using FastReg for
registration\n");
+ device->reg_ops = &fastreg_ops;
+ } else {
+ iser_err("IB device does not support FMRs nor FastRegs, can't
register memory\n");
+ return -1;
+ }
+
Perhaps no device supports both FMR and FRMR, but the above code would
choose FMR over FRMR. Shouldn't it be the other way around?
Agree. We should always prefer FRMR. Many of the IB drivers support
both..
I agree,
I planned to change that as part of my remote invalidate support
patches. Would it be acceptable to hold that off for the next cycle?
--
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
