|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Ordered delivery capability notificationJulian, Where: ====== 1.2.2.1 Command numbering "iSCSI supports ordered command delivery within a session" "The target iSCSI layer SHOULD deliver the commands to the target SCSI layer in the order specified by CmdRN". Problem: ======= An initiator is unable to know if the iSCSI target layer support ordered command delivery. Hence it cannot trust iSCSI to have ordered delivery. Hence all the iSCSI ordering mechanism becomes useless because it can't be trusted. The problem is not that iSCSI target layers can't support ordered delivery, the problem is that the initiator/application doesn't know anything about it. Solution: ====== a) Add a Login/Text key Ordered:<yes|no> b) Put the explanation in for the key: "If the target answered "yes" and is unable to maintain the order for whatever reason, it must notify the initiator and drop the session" If the target answered "yes", when it receives a "retried" command (retry bit), it must be able to retry the command in such a way that the effect on the initiator and target device when the command completes is the same as if the command would have not needed to be retried. This doesn't mean always restart from where left, a READ can have all the data re-transmitted because it is transparent a completion time.
Home Last updated: Tue Sep 04 01:05:54 2001 6315 messages in chronological order |