Re: Is there a way to transfer a rdma connection between userspace processes?

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

On 10/15/2012 4:07 AM, Yann Droneaud wrote:
> Le lundi 15 octobre 2012 à 10:27 +0200, Stefan (metze) Metzmacher a
> écrit :
>> Hi,
>>
>> I'm currently researching how to implement SMBDirect [MS-SMBD]
>> together with the multi channel feature of SMB 3.0 in Samba.
>>
>> As Samba currently uses one process per tcp connection
>> and maintains a lot of in memory state within the process
>> (e.g. for the SMB_VFS modules) it would require a lot of work
>> to change Samba to coordinate two (or more) processes for one logical
>> multi channel connection.
>>
>> My current plan tries to pass the socket fd of new connections
>> (which join an existing multi channel session) via fd-passing to
>> the existing process.
>>
>> Now I'm wondering if this would also be possible with
>> a rdma connection (struct rdma_cm_i ).
>>
> RDMA / verbs ressources are tied to a process (especially Memory
> Registration), but it's ending up in the HCA, which is probably unaware
> of processes.
>
> Additionally, an RDMA_CM connection is not identified by a FD, so this
> kind of Unix trick (FD passing through Unix socket: SCM_RIGHTS) is not
> going to work.
>
> Forking might already be a challenge for a RDMA/verbs application, so I
> don't think that sharing/moving an RDMA_CM connection across different
> processes is supported.
>
> But other people on this list (especially Roland Dreier and Sean Hefty)
> could find a solution.
>
> Regards.
>

fork() support like you need is not there in Linux RDMA verbs. Another 
alternative is to fork() before you setup the RDMA connection.  IE if a 
regular TCP socket is first used to negotiate RDMA mode, then maybe you 
could fork() after negotiation but before setting up the RDMA connection 
and other resources?


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html