[openib-general] [PATCH 6/6] [RFC] iser socket

[Alexander Nezhinsky]

>>
>>Open iscsi expects the transport to support the following chain:
>>
>>+1 create socket
>>+2 connect the socket to the target
>>+3 bind the socket to an iscsi connection enabling actual
>>communication over this iscsi connection
>>
>>so, we implemented the minimal set of operations (ie socket/connect)
>>which will enable open iscsi to work transparently with the
>>iser transport.
>>
>>Or.
>>
>
>As indicated in my other reply, this is not consistent
>with how iWARP connections are being done. The CMA
>infrastructure, with IP semantics for IB addressing,
>should be built upon here. There is no reason why
>iSER connections should follow different logic than
>RDMA connections.
>
This one is from your other reply:

>There really isn't a lot of user-space logic being preserved
>here unless you keep the negotiations in user-space as well.
>
The point is that open-iscsi *keeps* all negotiations in user-space.
As far as i understand, it's not going to change because the separation of
control and data paths is one of the basic design principles of the project.

And iSER/IB connections do differ from other types.
Again, citing your other reply:

>Using iscsi_tcp the "startup phase" messages would simply
>be translated into writes/reads over a TCP socket. For
>iSER/IB they would be translated to Send Messages. For
>iSER/IP they could be translated into TCP segments.
>
The differences that you mentioned correspond to 3 ways that various
transports (iscsi/ip, iser/ib, iser/ip) would handle the reads/writes.
This presents no problem, because there would be 3 different transport 
modules,
each one acting appropriately in response to the "messages".
The only problem that remains is connection establishment.
Because the differences there are just as pronounced, and the connections
are initiated from user space using a socket, we don't have another
solution which looks cleaner.