|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Jijo, > A related question - from the above discussions, i assume that > there is no, application-level, end-to-end flow control from > the initiator-to-target, as it relates to queued commands. As > TCP flow control layers already allowed the command-bytes in > to the host, we have the memory buffers at the TCP layer, > and later commands are just ignored, with ICR return code 0x06. > And initiator re-submits, target re-rejects, and this repeats > this is not good for internet, as it relates to congestion. > When tagged queueing/no of outstanding commands support added > to SCSI, iSCSI was not in anybody's mind(IMHO).. please > dis-agree with me here. Happy to do so, as that last statement is incorrect, because the initial assumption is wrong. Tagged command queuing is in SAM-2, which is normatively referenced by iSCSI (RFC 3720). The mechanism that you're looking for is TASK SET FULL status (28h), which is widely supported. The recent discussion on this list was specific to iSCSI commands, which are intended for exceptional cases where the outstanding queue of undelivered commands in iSCSI needs to be bypassed (see Section 3.2.2.1 of RFC 3720). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ips
[IETF] [Linux iSCSI] [Linux SCSI] [Linux Resources] [Yosemite News] [IETF Announcements] [IETF Discussion] [SCSI]
![]() |
![]() |