Re: [PATCH V2 for-next] RDMA/hns: Bugfix for posting multiple srq work request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 30, 2019 at 10:31:17PM +0300, Leon Romanovsky wrote:
> On Thu, May 30, 2019 at 03:49:19PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 30, 2019 at 11:55:53PM +0800, Lijun Ou wrote:
> > > When the user submits more than 32 work request to a srq queue
> > > at a time, it needs to find the corresponding number of entries
> > > in the bitmap in the idx queue. However, the original lookup
> > > function named ffs only processes 32 bits of the array element,
> > > When the number of srq wqe issued exceeds 32, the ffs will only
> > > process the lower 32 bits of the elements, it will not be able
> > > to get the correct wqe index for srq wqe.
> > >
> > > Signed-off-by: Xi Wang <wangxi11@xxxxxxxxxx>
> > > Signed-off-by: Lijun Ou <oulijun@xxxxxxxxxx>
> > > V1->V2:
> > > 1. Use bitmap function instead of __ffs64()
> > >  drivers/infiniband/hw/hns/hns_roce_device.h |  2 +-
> > >  drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 29 +++++++++++++----------------
> > >  drivers/infiniband/hw/hns/hns_roce_srq.c    | 15 +++------------
> > >  3 files changed, 17 insertions(+), 29 deletions(-)
> >
> > Applied to for-next, thanks
> 
> Jason,
> 
> I don't want to be a party buster, but it is hard to believe that
> this part of their patch is correct.
> 
> +       if (unlikely(bitmap_full(idx_que->bitmap, size)))
> +               bitmap_zero(idx_que->bitmap, size);
> 
> They simply "dropping" all indexes.

It is what the logic did before.. No idea what this algorithm is
supposed to be

Jason



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux