[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

RE: Immediate Commands in iSCSI



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]

Add to Google Powered by Linux