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 12:44:51 -0400 X-Sieve: CMU Sieve 2.2 Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by newbox.ece.cmu.edu (Postfix) with ESMTP id 28E8B3079 for ; Tue, 22 Jul 2003 12:44:51 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 6FAF9B3; Tue, 22 Jul 2003 12:44:50 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by osgood.ece.cmu.edu (Postfix) with ESMTP id AA6C4AA; Tue, 22 Jul 2003 12:44:36 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 8EF2C89E3; Tue, 22 Jul 2003 12:44:22 -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 8117D89E2 for ; Tue, 22 Jul 2003 12:44:22 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id 5020B114; Tue, 22 Jul 2003 12:44:22 -0400 (EDT) Delivered-To: ips-outgoing@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 27C8DBB; Tue, 22 Jul 2003 12:44:22 -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 F0A08114 for ; Tue, 22 Jul 2003 12:44:18 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id CA96C89E4; Tue, 22 Jul 2003 12:44:18 -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 F1D6B89E2 for ; Tue, 22 Jul 2003 12:44:16 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix) id 8B0327B; Tue, 22 Jul 2003 12:44:16 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 66C539C; Tue, 22 Jul 2003 12:44:16 -0400 (EDT) Received: from homer.qlogic.org (unknown [198.70.192.130]) by bache.ece.cmu.edu (Postfix) with ESMTP id 41F347B for ; Tue, 22 Jul 2003 12:44:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: CDB/PDU inconsistencies and residual counts MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35070.5DA59691" Date: Tue, 22 Jul 2003 09:43:23 -0700 Message-ID: <2A8D600C919D2D41A3DAA2D2FEC71714471382@homer.qlogic.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CDB/PDU inconsistencies and residual counts Thread-Index: AcNQcGejqNCknLxREdeLgQBQ2thomQ== From: "Dean Scoville" To: "Julian Satran" Cc: Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,HTML_20_30 version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This is a multi-part message in MIME format. ------_=_NextPart_001_01C35070.5DA59691 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, The overflow/underflow and residual count values in Data-in and=20 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=20 "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=20 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_01C35070.5DA59691 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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_01C35070.5DA59691--