That's why I suggest to return success/fail and not the number of
SG elems that were mapped.
It's not a problem doing it, but I wanted it to be similar return code
and the regular data mapping function.
I guess it safer to return success/fail..
I don't understand the concern here.
Can you give an example ?
In case your max nents for data+meta is 16 but you get data_sg=15
and meta_sg=2, its not that if you map 15+1 you can trivially continue
from that point.
This can't happen since if max_nents is 16, I limit the max_data_nents
to 8 and max_meta_nents to 8.
Still there is a possibility that we cannot map all nents. Exactly like
srp sends all the nents and allocates more until it finishes in the
normal mr mapping.
Or, if this cannot happen we need to describe why here.
failures can always happen :)
Yes, but what I was referring to is the difference between the normal
mr_map_sg and the mr_map_sg_pi. srp for example actually uses the
continuation of the number of mapped sg returned, it cannot do the
same with the pi version.
Well I guess we can still use this API in SRP and set the pointers and
offsets correctly.
That is another option, but the mapping routine needs to perform a non
trivial klm/mtt trimming in the case we did not cover all the entries,
its not trivial because the data pages and the meta pages have
completely different alignments.
I'd say that its simpler to make this a success/fail until srp or alike
will actually use it and then we can make it continuation friendly.
