Corrected diagram and description for SMB-Direct (RDMA) support in Samba

[Richard Sharpe]

On Mon, May 19, 2014 at 12:10 AM, Michael Adam <obnox at samba.org> wrote:
> On 2014-05-18 at 22:58 -0700, Richard Sharpe wrote:
>> On Sun, May 18, 2014 at 10:46 PM, Michael Adam <obnox at samba.org> wrote:
>> >
>> > The clientGUID is already available in the
>> > NegProt request, so we can look for the client's
>> > smbd by clientGUID already here, and have c1 do
>> > the session setup.
>>
>> Ummm, that is true. I have checked the SMB2 document. That being the
>> case, we really should sanction the small layering violation and have
>> the SMBDirect daemon look in the NegProt request and send the
>> connection to the correct smbd. Why mess around with starting a
>> temporary smbd for one request/response pair?

OK, I made a mistake yesterday. While it is true that the ClientGUID
is available in the NegProt, you cannot use it in this way. This issue
came up in my talk at SDC last year.

The problem is that the client might have multiple connections to the
server. You have to use the sessionID in the SessionSetup to bind a
new connection to an existing session.

That being the case, you have to pay the cost of transferring the
state that you have accumulated from one smbd to another.

However, it seems to me that you can simply forward the SessionSetup
request to the correct smbd and the amount of state accumulated with
the NegProt is small (but there is some state, of course).


> Because for multi-channel TCP connections we intend to do
> the same: Here smbd forks a child for the new connection and
> this child transfers the connection to the target smbd after
> doing the initial processing looking onto negprot.

I don't think you can do this. Let me ask Tom Talpey.

> This would allow us to handle the rdma connections essentially
> in the same code path. And it would remove the need to teach
> the rdma proxy daemon anything except the smb direct rdma calls.
>
> What is more, the layer violation is not so small:
> First we need to teach negprot, and then we need to
> provide a way for smbd-d to find the smbd process for
> a given ClientGUID. This would involve either knowing
> the database format of smbd or sending a messagt to
> smbd "which smbd is responsible", receiving the server-id
> as a response and then sending to that process directly.
>
> I am not certain that this is worth it and I also think
> that we should first go the layer-wise cleaner approach
> that we need to go anyways for tcp-multi-channel, but of
> course we can then experiment with that and compare performance
> between the two approaches. The layer violation would only
> make sense if it comes with a huge performance benefit, and
> I wouldn't expect rdma connections to be created like mad.
>
> Cheers - Michael
>
>
>
>



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)