Nigel Smith wrote:
Hi Peter
Many thanks for all that details on the issues the comstar iscsi team are
looking at with regards to the "small and simple" iscsi initiators.
All sounds very positive and I look forward to seeing the fruits
of your deliberations.
I'm particularly pleased to see you mention the phase collapse issue.
I too was surprised to hear that there are initiators that apparently
depend on the use of status phase collapse. I think it is worth
pointing out that if this is the problem it is clearly a defect in those
initiators since there is nothing in the RFC to require the use of phase
collapse -- it's an optional feature that the target can use at its
discretion. It sounds like all the targets these small initiators
tested with used phase collapse so they didn't bother to implement the
handling for separate status PDU's.
Of course the only way to know for sure that this is the problem would
be to put together a COMSTAR iSCSI that supports phase collapse and try it.
One of the things that stood out in Vazer's traces was how
the Microsoft & NetApp iscsi targets were using phase collapse.
But Comstar was sending separate packets for returning response.
which does seem somewhat inefficient, especially for reads of
just a small number of blocks.
Less efficient yes but not hugely inefficient. Since the status PDU can
be sent immediately after the data PDU without any response from the
client the cost of not doing status phase collapse is just the time to
build and transmit another PDU. Compare that to immediate write data
(which COMSTAR iSCSI already supports) which avoids an entire round-trip
delay of 100us or more for small writes that fit into a PDU.
It would be excellent to see the Comstar iscsi target being able to
use this approach.
Agreed. I hope that at some point COMSTAR iSCSI will also support
unsolicited data (data-out PDU's sent after the command PDU without an
intervening R2T PDU from the target). The iSCSI features that COMSTAR
doesn't use today are generally problematic because of the protocol
layering. Between the STMF layer which knows nothing of iSCSI, the
iscsit driver which knows iSCSI but can use two different transports
(sockets and iser) and then the transport layers themselves some of the
implementation details become sticky. For example, status phase
collapse is not possible with iSER since the read data is sent using
RDMA. And handling unsolicited data is possible with iSER but not
easily mapped into STMF. Also in the case of a large iSER write command
it probably makes more sense to use RDMA instead of sending several data
PDUs using the host CPU. None of these issues are insurmountable but
they were complicated enough that we decided to defer them in the
initial implementation.
-Peter D
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
