On Thu, Oct 25, 2018 at 05:20:43PM -0500, Shiraz Saleem wrote: > > > + > > > +/** > > > + * ib_umem_next_phys_iter - SG list iterator that returns aligned HW address > > > + * @umem: umem struct > > > + * @sg_phys_iter: SG HW address iterator > > > + * @supported_pgsz: bitmask of HW supported page sizes > > > + * > > > + * This helper iterates over the SG list and returns the HW > > > + * address aligned to a supported HW page size. > > > + * > > > + * The algorithm differs slightly between HW that supports single > > > + * page sizes vs mixed page sizes in an MR. For example, if an > > > + * MR of size 4M-4K, starts at an offset PAGE_SIZE (ex: 4K) into > > > + * a 2M page; HW that supports multiple page sizes (ex: 4K, 2M) > > > + * would get 511 4K pages and one 2M page. Single page support > > > + * HW would get back two 2M pages or 1023 4K pages. > > > > That doesn't seem quite right, the first and last pages should always > > be the largest needed to get to alignment, as HW always has an > > offset/length sort of scheme to make this efficient. > > > > So I would expect 4M-4k to always return two 2M pages if the HW > > supports 2M, even if supports smaller sizes. > > > > For this to work the algorithm needs to know start/end... > > > > Maybe we should not support multiple page sizes yet, do we have HW > > that can even do that? > > > Sorry. I think my comment is confusing. > There is a typo in my description. Its not multiple page size but mixed > page size. In which case, I think it should be 511 4K and one 2M page > for my example of 4M-4k. This is how I understood it based on your > description here. > https://patchwork.kernel.org/patch/10499753/#22186847 I depends if the HW can do the start/end offset thing, ie if you can start and end on a partial page size. Since IB requires this I assume that all HW can do it for all page sizes, and we can pretty much ignore the alignment of the start of the first sgl and the end of the last sgl. Jason
