Return-Path: Received: from newbox.ece.cmu.edu (localhost [127.0.0.1]) by newbox.ece.cmu.edu (Cyrus v2.1.12) with LMTP; Tue, 22 Jul 2003 13:37:58 -0400 X-Sieve: CMU Sieve 2.2 Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by newbox.ece.cmu.edu (Postfix) with ESMTP id 1602D32B0 for ; Tue, 22 Jul 2003 13:37:58 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id C012FB1; Tue, 22 Jul 2003 13:37:57 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by bache.ece.cmu.edu (Postfix) with ESMTP id AB99497; Tue, 22 Jul 2003 13:37:20 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 25EB889E5; Tue, 22 Jul 2003 13:37:04 -0400 (EDT) Delivered-To: ips-outgoing@sos.ece.cmu.edu Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id 10E9489D8 for ; Tue, 22 Jul 2003 13:37:04 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id E03A8A6; Tue, 22 Jul 2003 13:37:03 -0400 (EDT) Delivered-To: ips-outgoing@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id BED00FE; Tue, 22 Jul 2003 13:37:03 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by hazard.ece.cmu.edu (Postfix) with ESMTP id AA68FA6 for ; Tue, 22 Jul 2003 13:36:57 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 9598989E6; Tue, 22 Jul 2003 13:36:57 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Delivered-To: ips@sos.ece.cmu.edu Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by sos.ece.cmu.edu (Postfix) with ESMTP id BE3EB89D8 for ; Tue, 22 Jul 2003 13:36:55 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix) id 7BB7C7B; Tue, 22 Jul 2003 13:36:55 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 4A84A9E; Tue, 22 Jul 2003 13:36:55 -0400 (EDT) Received: from lucy.trebia.com (lucy.trebia.com [65.192.191.151]) by bache.ece.cmu.edu (Postfix) with ESMTP id CDCA77C for ; Tue, 22 Jul 2003 13:36:44 -0400 (EDT) Received: by lucy.trebia.com with Internet Mail Service (5.5.2653.19) id <340B98A1>; Tue, 22 Jul 2003 13:36:42 -0400 Message-ID: <2AFBA56DFD6AE14BA11C5E2727609174469AE5@lucy.trebia.com> From: Alex Iannicelli To: Eddy Quicksall , Dean Scoville , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: CDB/PDU inconsistencies and residual counts Date: Tue, 22 Jul 2003 13:36:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35077.CEC1894A" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,HTML_50_60,HTML_FONT_COLOR_BLUE,ORIGINAL_MESSAGE version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35077.CEC1894A Content-Type: text/plain; charset="iso-8859-1" My take: The overflow/underflow is determined by the iSCSI layer. The SCSI layer simply tries to satisfy the CDB. If the SCSI layer hands the iSCSI layer too much data (more than ExpectedDataTransferLength) the iSCSI layer will mark it as overflow. If the SCSI layer does not hand the iSCSI layer enough data (very common when sending INQUIRY) then the iSCSI layer must mark it as an underflow. Also, the target must NEVER send too much data even if the SCSI layer tries to issue more than ExpectedDataTransferLength. This data should be truncated by the iSCSI layer and marked as overflow. Overflow does NOT indicate that the target just sent more data then was requested in the ExpectedDataTransferLength. Alex -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Tuesday, July 22, 2003 1:26 PM To: Dean Scoville; Julian Satran Cc: ips@ece.cmu.edu Subject: RE: CDB/PDU inconsistencies and residual counts My take is this: The overflow/underflow is determined by the SCSI layer. This is because the "expected data transfer length" gives the size of the initiators buffer and the CDB gives the size of the "attempted transfer". If the target is attempting to transfer too much, that would be an overflow. In some transports (like parallel SCSI) this is not determined by the target but is determined by the initiator driver or host adapter. In this case the target will try to stay in data-in phase to transfer all of the data. The initiator sees this as an overflow. Eddy -----Original Message----- From: Dean Scoville [mailto:dean.scoville@qlogic.com] Sent: Tuesday, July 22, 2003 12:43 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: CDB/PDU inconsistencies and residual counts Julian, The overflow/underflow and residual count values in Data-in and SCSI Response PDUs are set by the target based on the expected transfer length for the command, but should these values be set based on the CDB (SCSI layer) or based on the PDU "expected data transfer length" field (iSCSI layer)? For example, suppose an initiator sends a 4 block SCSI Read command but for some reason thinks the block size is 1024 bytes when in actuality the disk has 512 byte blocks. The SCSI Command PDU would have an "expected data transfer length" of value of 4096 bytes, but the target would actually return 2048 bytes (based on the true block size). Should the target set the underflow bit and return a residual count (based on the iSCSI PDU), or should it return no underflow and no residual count (based on the SCSI CDB)? The question comes up because I was running some iSCSI protocol test scripts where the PDU "expected transfer length" and the transfer length in the CDB were inconsistent in one of the scripts. Another example would be if the "allocation length" field in the CDB for an Inquiry command doesn't match the "expected data transfer length" field in the SCSI Command PDU. The script was in error and should be fixed, is there a desired target behavior in such situations, given that the CDB fields are not typically parsed by the iSCSI layer, the SCSI device may know nothing about iSCSI PDUs, and some middle-layer may or may not know about both. If the initiator detects that an underflow has occurred, based solely on the amount of data received and the "expected data transfer field" in the iSCSI PDU, but the target did not report an underflow or residual count in the SCSI response, is the initiator allowed/expected to report an underflow to the upper layers? Thanks, Dean Scoville ------_=_NextPart_001_01C35077.CEC1894A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CDB/PDU inconsistencies and residual counts
My=20 take:
 
The=20 overflow/underflow is determined by the iSCSI layer. The SCSI layer = simply tries=20 to satisfy the CDB. If the SCSI layer hands the iSCSI layer too much = data (more=20 than ExpectedDataTransferLength) the iSCSI = layer will=20 mark it as overflow. If the SCSI layer does not hand the = iSCSI layer=20 enough data (very common when sending INQUIRY) then the iSCSI layer = must mark it=20 as an underflow.
 
Also, the target must NEVER send too much data even if the = SCSI layer=20 tries to issue more than ExpectedDataTransferLength. This data = should be=20 truncated by the iSCSI layer and marked as overflow. Overflow does NOT = indicate=20 that the target just sent more data then was requested in the ExpectedDataTransferLength.<= /DIV>
 
Alex
-----Original Message-----
From: Eddy Quicksall=20 [mailto:eddy_quicksall@ivivity.com]
Sent: Tuesday, July 22, = 2003 1:26=20 PM
To: Dean Scoville; Julian Satran
Cc:=20 ips@ece.cmu.edu
Subject: RE: CDB/PDU inconsistencies and = residual=20 counts

My=20 take is this:

 

The = overflow/underflow=20 is determined by the SCSI layer. This is because the "expected data = transfer=20 length" gives the size of the initiators buffer and the CDB gives the = size of=20 the "attempted transfer". If the target is attempting to transfer too = much, that=20 would be an overflow.

 

In some = transports=20 (like parallel SCSI) this is not determined by the target but is = determined by=20 the initiator driver or host adapter. In this case the target will try = to stay=20 in data-in phase to transfer all of the data. The initiator sees this = as an=20 overflow.

 

Eddy

 

-----Original=20 Message-----
From: = Dean=20 Scoville [mailto:dean.scoville@qlogic.com]
Sent: Tuesday, July 22, 2003 = 12:43=20 PM
To: Julian=20 Satran
Cc:=20 ips@ece.cmu.edu
Subject:=20 CDB/PDU inconsistencies and residual counts

 

Julian, =
The=20 overflow/underflow and residual count values in Data-in and=20
SCSI Response PDUs are = set by the=20 target based on the expected
transfer length for the = command, but=20 should these values be set based
on the CDB (SCSI layer) = or based on=20 the PDU "expected data transfer length"
field = (iSCSI=20 layer)?

For example, suppose an = initiator=20 sends a 4 block SCSI Read command
but for = some reason=20 thinks the block size is 1024 bytes when in actuality =
the disk has=20 512 byte blocks. The SCSI Command PDU would have an =
"expected=20 data transfer length" of value of 4096 bytes, but the target = would=20
actually return 2048 = bytes (based on=20 the true block size). Should the target
set the = underflow bit=20 and return a residual count (based on the iSCSI PDU), =
or should it=20 return no underflow and no residual count (based on the SCSI = CDB)?=20

The question comes up = because I was=20 running some iSCSI protocol test
scripts where the PDU = "expected=20 transfer length" and the transfer length
in the CDB = were=20 inconsistent in one of the scripts.

Another example would be = if the=20 "allocation length" field in the CDB for
an Inquiry = command=20 doesn't match the "expected data transfer length" field =
in the SCSI=20 Command PDU.

The script was in error = and should=20 be fixed, is there a desired target
behavior = in such=20 situations, given that the CDB fields are not typically = parsed=20
by=20 the iSCSI layer, the SCSI device may know nothing about iSCSI=20 PDUs,
and some middle-layer may = or may not=20 know about both.

If the initiator detects = that an=20 underflow has occurred, based solely on the
amount of = data received=20 and the "expected data transfer field" in the iSCSI PDU, =
but the=20 target did not report an underflow or residual count in the SCSI=20 response,
is the initiator = allowed/expected to=20 report an underflow to the upper layers?

Thanks,=20

Dean = Scoville=20

------_=_NextPart_001_01C35077.CEC1894A--