On Wed, Mar 29, 2017 at 04:15:10PM +0000, Bart Van Assche wrote: > On Wed, 2017-03-29 at 07:23 +0300, Leon Romanovsky wrote: > > On Wed, Mar 29, 2017 at 03:20:37AM +0000, Bart Van Assche wrote: > > > On Wed, 2017-03-29 at 06:09 +0300, Leon Romanovsky wrote: > > > > -#define MLX5_FS_MAX_TYPES 10 > > > > -#define MLX5_FS_MAX_ENTRIES 32000UL > > > > +#define MLX5_FS_MAX_TYPES 6 > > > > +#define MLX5_FS_MAX_ENTRIES BIT(16) > > > > > > Hello Leon and Maor, > > > > > > The use of the BIT() macro here looks misleading to me. Elsewhere in the > > > kernel BIT() is used to represent a bitmask. My understanding is that > > > MLX5_FS_MAX_ENTRIES is not a bitmask but a value? > > > > Hello Bart, > > > > I agree with you that the name "MAX_ENTRIES" is misleading. This define > > MLX5_FS_MAX_ENTRIES is needed to compare num_entries with max_table_size > > which is represented in BIT() format. The max_table was added in previous > > patch and we thought that it will be much convenient for the reader to > > compare the same BIT(..) constructions. > > > > If you think that we abused the BIT() macro, let me know and I'll send > > updated version (without BIT()). > > Hello Leon, > > It's not that important to me, but does MLX5_FS_MAX_ENTRIES represent a number > or a bitmask? To me the name "MLX5_FS_MAX_ENTRIES" suggests that it is a number > and using BIT() suggests that it's a bitmask. This seems contradictory to me. Down the road, that define is translated to bitmask, and it is hard for me to categorize it. If we limit ourselves to the upper layer only, it will be a number, otherwise it will be a bitmask. > > Thanks, > > Bart.-- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature