On Thu, Sep 20, 2018 at 09:48:55AM -0600, Jason Gunthorpe wrote: > On Thu, Sep 20, 2018 at 08:10:36AM +0300, Leon Romanovsky wrote: > > On Wed, Sep 19, 2018 at 03:27:19PM -0600, Jason Gunthorpe wrote: > > > On Tue, Sep 18, 2018 at 10:56:55AM +0300, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro@xxxxxxxxxxxx> > > > > > > > > There is no need to do custom logic to allocate indexes while kernel > > > > provides specific API for that. > > > > > > I think if we are going to do this then the RDMA_MAX_PORTS should be > > > increased to match the memory overhead of the IDA, at least. > > > > > > Otherwise we are paying a greater allocation cost and getting nothing > > > for it. > > > > > > IIRC an IDA allocates bitmaps in 64*64 bits chunks, so RDMA_MAX_PORTS > > > should be >> 4096 ? > > > > > > Maybe it should be 1<<MINORBITS like NVME does? > > > > > > Reserving more minor numbers is basically free other than the tracking > > > bitmap, which is why Huy was so stingy when this was introduced.. > > > > I don't see the need to do extra optimization in memory footprint for > > rare and not significant case, but do see the great value of using > > standard kernel APIs with proper coding pattern in opposite to to home > > grown implementation of the same thing. > > find_bit is the usual API to use here if the bitmap is small, IDA is > the right API when the bitmap gets larger. If you want to use IDA you > should increase the bitmap range to be appropriate for IDA.. "appropriate" ??? It works correctly for small bitmaps too. > > Jason
Attachment:
signature.asc
Description: PGP signature
