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
