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

[Michael Adam]

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?

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.

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




-------------- 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/5978e2c6/attachment.pgp>