On 04-Apr-19 18:47, Jason Gunthorpe wrote: > On Thu, Apr 04, 2019 at 03:25:26PM +0000, Saleem, Shiraz wrote: >>> Subject: Re: [PATCH rdma-next v1 2/6] RDMA/umem: Add API to find best driver >>> supported page size in an MR >>> >>> On 19-Feb-19 16:57, Shiraz Saleem wrote: >>>> This helper iterates through the SG list to find the best page size to >>>> use from a bitmap of HW supported page sizes. Drivers that support >>>> multiple page sizes, but not mixed pages in an MR can use this API. >>>> >>>> Suggested-by: Jason Gunthorpe <jgg@xxxxxxxx> >>>> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@xxxxxxxxx> >>>> Signed-off-by: Shiraz Saleem <shiraz.saleem@xxxxxxxxx> >>> >>> I've tested this patch comparing our existing efa_cont_pages() implementation vs >>> ib_umem_find_single_pg_size() running different test suites: >> >> Thanks for testing! >> >>> >>> Supported page sizes are anything between 4k to 2G. >>> I'm using page shift to compare results of both functions (ilog2 the return value of >>> ib_umem_find_single_pg_size). >>> >>> When huge pages are disabled, in many cases efa_cont_pages() returns page shift >>> of 13 where ib_umem_find_single_pg_size() returns 12. Didn't see a test where >>> ib_umem_find_single_pg_size() returns anything other than 12 (PAGE_SIZE). >> >> I wonder if the checks in place to guarantee offset into large page >> align for user-space virt buf and phy buf is downgrading the page >> bit. And that EFA might not need it. > > EFA doesn't have actual MRs with virtual addreses, so it probably > doesn't care. Can you please explain this statement?
