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

Re: Immediate Commands in iSCSI




Jijo,

There is an ISCSI level flow control from the target back to the initiator via the MaxCmdSn field.  The field can be found in the SCSI response, and it stops initiators from sending more than (MaxCmdSn-ExpCmdSn+1) commands on the session at any one time.  See RFC 3720 10.4 (specifically 10.4.11) for more information.

regards,

david


Java: The elegant simplicity of C++
and the blazing speed of smalltalk.


David J Cuddihy
Principal Engineer
ATTO Technology, Inc.

www.attotech.com
Power Behind the Storage




"Jijo Chacko" <consultant.bangalore@xxxxxxxxx>

12/06/2007 04:12 AM

To
"Ken Sandars" <kensandars@xxxxxxxxxxx>
cc
ips@xxxxxxxx, jacob_cherian@xxxxxxxx, nam_nguyen@xxxxxxxx, julian_satran@xxxxxxxxxx
Subject
Re: Immediate Commands in iSCSI






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.

And strongly feel that, we need to have some way of throttling the initiator to prevent from swamping the target, or  target implementation code should have the logic to re-submit the un-honored commands from the TCP buffers(or local buffers), before returning an error code to the initiator. or there can be an iSCSI, pending-coomands cache at the target stack, to solve this problem.

In essence, IMHO, we should do some fixes for target iSCSI implementation, to provide some staging buffers for already tcp-received commands. We should not be returning wrong error code to the initiator, if we already received the command at the TCP layer, and the target has the ability to apply it. We should be returning the error code only if target failed to apply it.

IN the SCSI world, as the number of initiators are typically just 1, and the data is not travelling across WAN, target can  return "Too many commands pending" errors.. as it has only local effect, having few meters.

Please correct me, if i am wrong...

thanks,
Jijo Chacko
Bangalore.


_______________________________________________
Ips mailing list

Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
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