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

[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.

> 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.

Cheers - Michael

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