On 11/05/2020 16:12, Yishai Hadas wrote: > Introduce import verbs for device, PD, MR, it enables processes to share > their ibv_contxet and then share PD and MR that is associated with. > > A process is creating a device and then uses some of the Linux systems > calls to dup its 'cmd_fd' member which lets other process to obtain > owning on. > > Once other process obtains the 'cmd_fd' it can call ibv_import_device() > which returns an ibv_contxet on the original RDMA device. > > On the imported device there is an option to import PD(s) and MR(s) to > achieve a sharing on those objects. > > This is the responsibility of the application to coordinate between all > ibv_context(s) that use the imported objects, such that once destroy is > done no other process can touch the object except for unimport. All > users of the context must collaborate to ensure this. > > A matching unimport verbs where introduced for PD and MR, for the device > the ibv_close_device() API should be used. > > Detailed man pages are introduced as part of this RFC patch to clarify > the expected usage and notes. > > Signed-off-by: Yishai Hadas <yishaih@xxxxxxxxxxxx> Hi Yishai, A few questions: Can you please explain the use case? I remember there was a discussion on the previous shared PD kernel submission (by Yuval and Shamir) but I'm not sure if there was a conclusion. Could you please elaborate more how the process cleanup flow (e.g killed process) is going to change? I know it's a very broad question but I'm just trying to get the general idea. What's expected to happen in a case where we have two processes P1 & P2, both use a shared PD, but separate MRs and QPs (created under the same shared PD). Now when an RDMA read request arrives at P2's QP, but refers to an MR of P1 (which was not imported, but under the same PD), how would you expect the device to handle that?
