Re: [PATCH rdma-next 1/8] net/mlx5: Expand mkey page size to support 6 bits

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 05, 2024 at 11:48:30PM +0300, Michael Guralnik wrote:
> 
> On 04/09/2024 19:18, Jason Gunthorpe wrote:
> > On Wed, Sep 04, 2024 at 06:30:31PM +0300, Michael Guralnik wrote:
> > > +#define mlx5_umem_find_best_pgsz(umem, dev, iova)                              \
> > > +	ib_umem_find_best_pgsz(                                                \
> > > +		umem,                                                          \
> > > +		__mlx5_log_page_size_to_bitmap(                                \
> > > +			MLX5_CAP_GEN_2(dev->mdev, umr_log_entity_size_5) ? 6 : \
> > > +									   5,  \
> > > +			0),                                                    \
> > > +		iova)
> > This can go in a real static inline function now.
> Ack.
> > Isn't is mlx5_mkx_find_best_pgsz ? It is only for mkc right?
> 
> Yes. It was written to be generic but mkc users were the only ones calling
> it.

Well, more than that, it hardwires details about the mkc layout inside
it with those open coded constants.

> > > @@ -4221,8 +4223,7 @@ struct mlx5_ifc_mkc_bits {
> > >   	u8         reserved_at_1c0[0x19];
> > >   	u8         relaxed_ordering_read[0x1];
> > > -	u8         reserved_at_1d9[0x1];
> > > -	u8         log_page_size[0x5];
> > > +	u8         log_page_size[0x6];
> > ?
> > 
> > Why is this change OK without more changes? Doesn't it move
> > log_page_size forward by 1 bit?
> 
> The reserved_at_1d9 is the new MSB of log_page_size that was not exposed in
> ifc so far.

Oh wow, I never noticed this ifc scheme has a scrambled bit ordering..

Jason