[openib-general] Re: [PATCHv2 1/2] resend: mthca support for max_map_per_fmr device attribute

Or Gerlitz ogerlitz at voltaire.com
Mon Jun 5 05:41:42 PDT 2006


Roland Dreier wrote:
> I had a chance to look at this, and I don't believe it is precisely
> correct for mem-free HCAs with the current FMR implementation.
> 
>  > +	/* on memfull HCA an FMR can be remapped 2^B - 1 times where B < 32 is
>  > +	 * the number of bits which are not used for MPT addressing, on memfree
>  > +	 * HCA B=8 so an FMR can be remapped 255 times.
>  > +	 */
>  > +	if(!mthca_is_memfree(mdev))
>  > +		props->max_map_per_fmr = (1 << (32 -
>  > +					long_log2(mdev->limits.num_mpts))) - 1;
>  > +	else
>  > +		props->max_map_per_fmr = (1 << 8) - 1;
> 
> Look at mthca_arbel_map_phys_fmr().  The question is how often key
> will repeat after being indexed, and when MTHCA_FLAG_SINAI_OPT is not
> set, then the same increment is used in the mem-free case as in the
> Tavor case.
> 
> So I think the code I quoted should really be:
> 
> 	if (dev->mthca_flags & MTHCA_FLAG_SINAI_OPT)
> 		props->max_map_per_fmr = (1 << (32 -
> 					long_log2(mdev->limits.num_mpts))) - 1;
> 	else
> 		props->max_map_per_fmr = (1 << 8) - 1;
> 
> Do you agree?  If so I can fix this patch up myself and apply it.

Yes it makes sense, but you need the check should be

	if (!(dev->mthca_flags & MTHCA_FLAG_SINAI_OPT))

instead of

	if (dev->mthca_flags & MTHCA_FLAG_SINAI_OPT)

also, what about the other patch which changes fmr_pool.c to query the 
device, have you got(reviewed/accepted) it? i have modified it to 
allocate the device attr struct on the heap as you have asked.

Or.



More information about the general mailing list