[openib-general] IB Driver Initialization of FMR methods

[Tom Tucker]

Got it. Thanks. 

> -----Original Message-----
> From: Roland Dreier [mailto:rolandd at cisco.com] 
> Sent: Friday, August 12, 2005 11:11 AM
> To: Tom Tucker
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] IB Driver Initialization of FMR methods
> 
> >>>>> "Tom" == Tom Tucker <tom at ammasso.com> writes:
> 
>     Tom> I've noticed that in the IB driver, the FMR methods are not
>     Tom> initialized if the XX_FLAG_FRM bit is not set in the device
>     Tom> structure. My assumption at this point is that these methods
>     Tom> are not present if they are not supported by the device.
> 
>     Tom> What's confusing is that the verbs do not check if the
>     Tom> function ptr is null when involking the underlying method. I
>     Tom> would have expected, that a method would be initialized that
>     Tom> returned ENOSYS in this case. Any explanation as to the
>     Tom> intended design point for FMR initialization would be greatly
>     Tom> appreciated.
> 
> I think you must have looked in the wrong place.  In
> drivers/infiniband/core/verbs.c, ib_alloc_fmr() starts with:
> 
> 	struct ib_fmr *ib_alloc_fmr(struct ib_pd *pd,
> 				    int mr_access_flags,
> 				    struct ib_fmr_attr *fmr_attr)
> 	{
> 		struct ib_fmr *fmr;
> 	
> 		if (!pd->device->alloc_fmr)
> 			return ERR_PTR(-ENOSYS);
> 
> so if alloc_fmr is not set, the caller will get -ENOSYS.
> 
> We do assume that if the device implements alloc_fmr(), it will
> implement the other FMR methods.  This isn't enforced by any code,
> since it doesn't seem worth checking for something that is an obvious
> bug, and that will cause an immediate and easy-to-diagnose oops.
> 
>  - R.
>