[ofiwg] [libfabric-users] mmap'ed kernel memory in fi_mr_reg
Jörn Schumacher
joern.schumacher at cern.ch
Sat Nov 17 14:22:27 PST 2018
On 11/16/18 5:35 PM, Hefty, Sean wrote:
>> I am happy with this being a provider-specific extension for now. The
>> project that requires this will anyway only use the verbs provider.
>>
>> I do not think there is a fully reliable way of distinguishing
>> physical/virtual addresses. I spoke with our driver expert here who
>> cannot think of a way either. The provider-specific flag seems to be
>> the way to go, what do you think?
>
> I agree this works fine.
>
> The only alternative I can think of is to try a normal registration call, and if that fails, try again using the physical flag. Would this work, or does the normal registration call succeed, but produce an unusable MR?
This would not work because of a subtlety of the physical memory
registration. The reason is that actually NULL is passed as address in
the call. Check the github link to my patch in the other E-Mail, there
is a line that replaces the address with NULL.
If a user passes an illegal virtual address the call should fail. But if
the libfabric call falls back to the physical address registration, this
would then actually succeed as the address is replaced with NULL.
Cheers,
Jörn
More information about the ofiwg
mailing list