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

[Stefan (metze) Metzmacher]

Am 19.05.2014 17:22, schrieb Michael Adam:
> On 2014-05-19 at 08:14 -0700, Richard Sharpe wrote:
>>
>> I am seeking clarity on something we are arguing about, again, WRT
>> multi-connect and thus SMB over RDMA.
>>
>> Attached is a diagram I have drawn of how I think things will work.
>>
>>>>>
>>>>> 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?
>>>
>>> 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.
>>
>> Essentially, the claim here is that we can determine which session to
>> bind the new connection to simply by looking at the ClientGUID in the
>> NegProt.
> 
> No, I don't claim that: I simply want to be less precise than we
> could be and transfer connections to a given smbd by ClientGUID
> during negprot instead of by SessionID during session bind. This
> way, in particular those connections bundled to one session will
> be handled by one smbd, but there could be more than one session
> in that smbd.
> 
> I agree this is a tradeoff, but I don't think that we would be
> incorrect.

The key is that a real client will always use the same ClientGUID
when reconnecting. That the only way the client can reuse file handles
with leases, as the client lease key is always relative to the ClientGUID.

So we don't have to be 100% correct. A session bind using a different
ClientGUID
for the 2nd connection will just fail against Samba.

>> I don't think this is correct, and I believe that this came up at SDC last year.
>>
>> I believe that we need to use the sessionID in the SessionSetup to do
>> this binding because a client can have multiple sessions with a
>> server.
> 
> The session bind using the sessionID will still happen.
> The fd-passing would just have happened before.
> The fd-passing is something we plan to do under the hood
> and is not necessarily tied to the session-bind.

Yes, we will do fd-passing at a stage where we don't have much state on
the connection.
We'll just forward the Negprot request in addition to the fd.
So that the receiving smbd can generate all needed state.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140519/d0b2825d/attachment.pgp>