On 3/4/2019 8:30 PM, Jason Gunthorpe wrote:
On Sun, Mar 03, 2019 at 06:34:42PM +0200, Max Gurtovoy wrote:
On 2/7/2019 8:12 PM, Sagi Grimberg wrote:
From: Israel Rukshin <israelr@xxxxxxxxxxxx>
Instead of adding many arguments to RDMA mapping functions with PI,
create a new data structure 'ib_scatterlist' which contains the needed
information on a mapped scatterlist. In the future, this will also be
used by ULPs that define these attributes explicitly.
While this can be viewed as a natural packing of a scatterlist
attributes it seems unneeded. Personally I would rather pass
the arguments explicitly.
If you really don't want to do that, would it make sense to split the
mapping APIs to data vs. pi?
I prefer to ease the API. This was the whole point (+ perf improvements) of
this patches.
I've always been prefering more entry points to gaint multiplexor
entry points.. It is usually more understandable.
We already have this entry point in this patch set.
Which giant multiplexor are you referring to ?
Something like the following maybe?
ret = ib_map_mr_sg(mr, sg, nents, &offset, PAGE_SIZE);
...
ret = ib_map_mr_sg_pi(mr, meta_sg, meta_nents, &meta_offset,
PAGE_SIZE);
So call the normal map_mr then 'augment' it with pi data? Not an
unreasonable way to go..
we've just had a discussion regarding the augmented sg list that we
already solved few weeks ago.
This was solved only because Christoph knew/remembered exactly this
weird API that augments the SG list and unmap it using the orig_nents.
we really don't want the same for MR mappings (+ unneeded error flow
addition to ULPs, bahh).
Let's leave it "as is" with the new structure or use more arguments to
ib_map_mr_sg_pi function.
-Max.
Jason
