Roland Dreier wrote:
Or> Also, if the patch makes sense and the memfree issue is
Or> resolved, i'd like to change the name of the device attribute
Or> from max_map_per_fmr to max_remaps_per_fmr, i can resend this
Or> patch series with this fix.
The patch makes sense, although of course you need to make sure you
understand and handle the mem-free case as well if you want it
applied.
+ /* FMR can be remapped 2^B - 1 times where B < 32 is the number of
+ * bits which are not used for MPT addressing */
+ max_map_per_fmr = (1 << (32 - long_log2(mdev->limits.num_mpts))) - 1;
OK, fair enough, i will need at least some kickoff helping... can you
comment if the above calculation is indeed broken under memfree? if yes,
is it broken under both Arbel/Sinai? where should i look into the driver
or i should look in the PRM?
> I'm not sure changing to max_remaps_per_fmr is really
> clearer, since the value counts the first mapping of the FMR (which is
> not a remapping). But I guess I could be convinced if more people
> think it's clearer.
remaps means all the maps except the first one, for this stands the "-1"
in the calculation above. Let me know what makes sense more to you (or
others if they choose to respond) calling it max_maps_per_fmr (which
counts also the first map) or calling it max_remaps_per_fmr (so it does
not count the first map).
Or.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
