From ips-bounces@ietf.org Tue Apr 15 06:39:46 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE5E28C3DE; Tue, 15 Apr 2008 06:39:46 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D5228C0E1 for ; Tue, 15 Apr 2008 06:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObIU+Mw0Svmx for ; Tue, 15 Apr 2008 06:39:44 -0700 (PDT) Received: from exil.voltaire.com (fwil.voltaire.com [193.47.165.2]) by core3.amsl.com (Postfix) with ESMTP id B515E28C3DE for ; Tue, 15 Apr 2008 06:39:42 -0700 (PDT) Received: from [127.0.0.1] ([172.25.5.95]) by exil.voltaire.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 16:40:12 +0300 Message-ID: <4804B03C.6060507@voltaire.com> Date: Tue, 15 Apr 2008 16:40:12 +0300 From: Erez Zilber User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ips@ietf.org X-OriginalArrivalTime: 15 Apr 2008 13:40:12.0948 (UTC) FILETIME=[3B0A6D40:01C89EFE] Subject: [Ips] Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org We're trying to understand what should be the write VA (tagged offset) in the iSER header for WRITE commands. If unsolicited data is to be sent, should the VA be the original VA or should it be original VA + FirstBurstLength? Example: InitialR2T=3DNo FirstBurstLength =3D 1000 Base address of the registered buffer =3D 0 Now, what should be the VA in the iSER header? 0 or 1000? We read the following paragraph in the iSER spec, but didn't get an answer from there: * If there is solicited data to be transferred for the SCSI write or bidirectional command, as indicated by the Expected Data Transfer Length in the SCSI Command PDU exceeding the value of UnsolicitedDataSize, the iSER layer at the initiator MUST do the following: a. It MUST allocate a Write STag for the I/O Buffer defined by the qualifier DataDescriptorOut. The DataDescriptorOut describes the I/O buffer starting with the immediate unsolicited data (if any), followed by the non-immediate unsolicited data (if any) and solicited data. This means that the BufferOffset for the SCSI Data-out for this command is equal to the TO. This implies that a zero TO for this STag points to the beginning of this I/O Buffer. Thanks, -- = ____________________________________________________________ Erez Zilber | 972-9-971-7689 Software Engineer, Storage Solutions Voltaire =96 _The Grid Backbone_ __ www.voltaire.com _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Apr 15 10:18:21 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3883A6EA4; Tue, 15 Apr 2008 10:18:21 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3F43A6F26; Tue, 15 Apr 2008 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgrQrFKrEvto; Tue, 15 Apr 2008 10:18:14 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 10FBE3A6C07; Tue, 15 Apr 2008 10:18:13 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3FHIiKu022623; Tue, 15 Apr 2008 13:18:44 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3FHIiKC247726; Tue, 15 Apr 2008 13:18:44 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3FHEEUB024170; Tue, 15 Apr 2008 13:14:14 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av05.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3FHEEoC024165; Tue, 15 Apr 2008 13:14:14 -0400 In-Reply-To: <4804B03C.6060507@voltaire.com> To: Erez Zilber MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Mike Ko Date: Tue, 15 Apr 2008 10:18:43 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0.1|February 07, 2008) at 04/15/2008 13:18:44, Serialize complete at 04/15/2008 13:18:44 Cc: ips@ietf.org, ips-bounces@ietf.org Subject: Re: [Ips] Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0351733222==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0351733222== Content-Type: multipart/alternative; boundary="=_alternative 005F18EC8825742C_=" This is a multipart message in MIME format. --=_alternative 005F18EC8825742C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable VA is a concept introduced in an Infiniband annex to support iSER. It=20 appears in the expanded iSER header for Infiniband use only to support the = non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA=20 used in IETF. "The DataDescriptorOut describes the I/O buffer starting with the=20 immediate unsolicited data (if any), followed by the non-immediate=20 unsolicited data (if any) and solicited data." If non-ZBVA mode is used,=20 then VA points to the beginning of this buffer. So in your example, the=20 VA field in the expanded iSER header will be zero. Note that for IETF,=20 ZBVA is assumed and there is no provision to specify a different VA in the = iSER header. Tagged offset (TO) refers to the offset within a tagged buffer in RDMA=20 Write and RDMA Read Request Messages. When sending non-immediate=20 unsolicited data, Send Message types are used and the TO field is not=20 present. Instead, the buffer offset is appropriately represented by the=20 Buffer Offset field in the SCSI Data-Out PDU. Note that Tagged Offset is=20 not the same as write VA and it does not appear in the iSER header. Mike Erez Zilber =20 Sent by: ips-bounces@ietf.org 04/15/2008 06:40 AM To ips@ietf.org cc Subject [Ips] Calculating the VA in iSER header We're trying to understand what should be the write VA (tagged offset) in the iSER header for WRITE commands. If unsolicited data is to be sent, should the VA be the original VA or should it be original VA + FirstBurstLength? Example: InitialR2T=3DNo FirstBurstLength =3D 1000 Base address of the registered buffer =3D 0 Now, what should be the VA in the iSER header? 0 or 1000? We read the following paragraph in the iSER spec, but didn't get an answer from there: * If there is solicited data to be transferred for the SCSI write or bidirectional command, as indicated by the Expected Data Transfer Length in the SCSI Command PDU exceeding the value of UnsolicitedDataSize, the iSER layer at the initiator MUST do the following: a. It MUST allocate a Write STag for the I/O Buffer defined by the qualifier DataDescriptorOut. The DataDescriptorOut describes the I/O buffer starting with the immediate unsolicited data (if any), followed by the non-immediate unsolicited data (if any) and solicited data. This means that the BufferOffset for the SCSI Data-out for this command is equal to the TO. This implies that a zero TO for this STag points to the beginning of this I/O Buffer. Thanks, --=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Erez Zilber | 972-9-971-7689 Software Engineer, Storage Solutions Voltaire ? =5FThe Grid Backbone=5F =5F=5F www.voltaire.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --=_alternative 005F18EC8825742C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
VA is a concept introduced in an Inf= iniband annex to support iSER.  It appears in the expanded iSER header for Infiniband use only to support the non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA used in IETF.

"The DataDescriptorOut describes the I/O buffer starting with the immediate unsolicited data (if any), follo= wed by the non-immediate unsolicited data (if any) and solicited data."  If non-ZBVA mode is used, then VA points to the beginning of this buffer.  So in your example, the VA field in the expanded iSER header will be zero.  Note that for IETF, ZBVA is assumed and there is no provision to specify a different VA in the iSER header.

Tagged offset (TO) refers to the off= set within a tagged buffer in RDMA Write and RDMA Read Request Messages.  = When sending non-immediate unsolicited data, Send Message types are used and the TO field is not present.  Instead, the buffer offset is appropriat= ely represented by the Buffer Offset field in the SCSI Data-Out PDU.  Note that Tagged Offset is not the same as write VA and it does not appear in the iSER header.

Mike


Erez Zilber <erezz= @voltaire.com>
Sent by: ips-bounces@ietf.org

04/15/2008 06:40 AM

To
ips@ietf.org
cc
Subject
[Ips] Calculating the VA in iSER hea= der





We're trying to understand what should be the write VA (tagged offset)
in the iSER header for WRITE commands. If unsolicited data is to be
sent, should the VA be the original VA or should it be original VA +
FirstBurstLength?


Example:


InitialR2T=3DNo

FirstBurstLength =3D 1000


Base address of the registered buffer =3D 0


Now, what should be the VA in the iSER header? 0 or 1000?


We read the following paragraph in the iSER spec, but didn't get an
answer from there:


* If there is solicited data to be transferred for the SCSI write or
bidirectional command, as indicated by the Expected Data Transfer
Length in the SCSI Command PDU exceeding the value of
UnsolicitedDataSize, the iSER layer at the initiator MUST do the
following:

a. It MUST allocate a Write STag for the I/O Buffer defined by
the qualifier DataDescriptorOut. The DataDescriptorOut
describes the I/O buffer starting with the immediate
unsolicited data (if any), followed by the non-immediate
unsolicited data (if any) and solicited data. This means
that the BufferOffset for the SCSI Data-out for this
command is equal to the TO. This implies that a zero TO
for this STag points to the beginning of this I/O Buffer.


Thanks,

--

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

Erez Zilber | 972-9-971-7689

Software Engineer, Storage Solutions

Voltaire – =5FThe Grid Backbone=5F

=5F=5F

www.voltaire.com <http://www.voltaire.com/>



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips
--=_alternative 005F18EC8825742C_=-- --===============0351733222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0351733222==-- From ips-bounces@ietf.org Tue Apr 15 18:58:00 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D9E3A6AAC; Tue, 15 Apr 2008 18:58:00 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD7D3A6AAC for ; Tue, 15 Apr 2008 18:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.452 X-Spam-Level: ** X-Spam-Status: No, score=2.452 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFJeaL8cinbH for ; Tue, 15 Apr 2008 18:57:57 -0700 (PDT) Received: from bay0-omc3-s11.bay0.hotmail.com (bay0-omc3-s11.bay0.hotmail.com [65.54.246.211]) by core3.amsl.com (Postfix) with ESMTP id CF9603A6852 for ; Tue, 15 Apr 2008 18:57:57 -0700 (PDT) Received: from BAY135-W8 ([65.55.140.43]) by bay0-omc3-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 18:58:32 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: Date: Wed, 16 Apr 2008 09:58:32 +0800 Importance: Normal In-Reply-To: References: <4804B03C.6060507@voltaire.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 01:58:32.0522 (UTC) FILETIME=[5FA4FAA0:01C89F65] Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is not available X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0052999146==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0052999146== Content-Type: multipart/alternative; boundary="_acb313db-3830-442e-9e21-63289a6bc9db_" --_acb313db-3830-442e-9e21-63289a6bc9db_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dears, I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator. But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload. So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it? Thanks! Best Regards, Jason _________________________________________________________________ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18 --_acb313db-3830-442e-9e21-63289a6bc9db_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dears,
I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator.
 
But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload.
 
So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it?
 
Thanks!

Best Regards,

Jason 


“七件武器，七种完美” 立刻体验！ --_acb313db-3830-442e-9e21-63289a6bc9db_-- --===============0052999146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0052999146==-- From ips-bounces@ietf.org Tue Apr 15 20:04:01 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DF63A693A; Tue, 15 Apr 2008 20:04:01 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351423A6CDC for ; Tue, 15 Apr 2008 20:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puYHlkHwGeyA for ; Tue, 15 Apr 2008 20:03:58 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 1A7A03A6A58 for ; Tue, 15 Apr 2008 20:03:57 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3G34TFx005116; Tue, 15 Apr 2008 23:04:29 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 15 Apr 2008 23:04:28 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3G33lT2023828; Tue, 15 Apr 2008 23:04:22 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 23:04:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 23:04:15 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Thread-Index: AcifZWs6yBNpmmT1T8eJnCxahOBnqQACIu0A References: <4804B03C.6060507@voltaire.com> To: , X-OriginalArrivalTime: 16 Apr 2008 03:04:16.0773 (UTC) FILETIME=[8E99EB50:01C89F6E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, CN_TLD 0.5, MIME_CHARSET_FARAWAY 0.409, HTML_50_70 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HIGHBITS 0, __IMS_MSGID 0, __MIME_CHARSET_FARAWAY 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1503329600==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1503329600== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89F6E.8E0DF0E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89F6E.8E0DF0E1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. =20 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason Sent: Tuesday, April 15, 2008 9:59 PM To: ips@ietf.org Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =09 =09 Dears, =09 I am curently implement iscsi target on a resource-limted device. In = my implementation, orignal to-be-rejected PDU is not available when it = realised that a Reject should be sent to initiator. =20 But as RFC3720 said, Target must send back the orignal PDU as the = Reject's payload.=20 =20 So my question is: Why we need to send back the orignal PDU ? Can we = simply eliminate it? =20 Thanks! =09 Best Regards, Jason=20 ________________________________ =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1 =20 ------_=_NextPart_001_01C89F6E.8E0DF0E1 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
The original PDU header has to be sent back so that the=20 initiator
knows what was rejected.  iSCSI has a number = of mechanisms=20 that
can be used by the target to control resource consumption=20 and
those should be used to ensure that adequate=20 resources are
available to deal with the PDU that = is to be=20 rejected.
 
Thanks,
--David

----------------------------------------------------
David = L.=20 Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508)=20 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 394-7754
----------------------------------------------------

From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason
Sent:=20 Tuesday, April 15, 2008 9:59 PM
To: = ips@ietf.org
Subject:=20 [Ips] Send Reject PDU when orignal to-be-rejected PDU is=20 notavailable

Dears,
I am curently = implement iscsi=20 target on a resource-limted device. In my implementation, orignal=20 to-be-rejected PDU is not available when it realised that a Reject = should be=20 sent to initiator.
 
But as RFC3720 said, Target = must send=20 back the orignal PDU as the Reject's payload.
 
So = my=20 question is: Why we need to send back the orignal PDU ? Can we = simply=20 eliminate it?
 
Thanks!

Best Regards,

Jason 


=A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1=20 ------_=_NextPart_001_01C89F6E.8E0DF0E1-- --===============1503329600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1503329600==-- From ips-bounces@ietf.org Tue Apr 15 20:45:31 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0023A6B3E; Tue, 15 Apr 2008 20:45:31 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA7A3A6847 for ; Tue, 15 Apr 2008 20:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.921 X-Spam-Level: ** X-Spam-Status: No, score=2.921 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_50=0.001, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRjd152b1INx for ; Tue, 15 Apr 2008 20:45:28 -0700 (PDT) Received: from bay0-omc1-s30.bay0.hotmail.com (bay0-omc1-s30.bay0.hotmail.com [65.54.246.102]) by core3.amsl.com (Postfix) with ESMTP id 19BAD3A6B3E for ; Tue, 15 Apr 2008 20:45:09 -0700 (PDT) Received: from BAY135-W42 ([65.55.140.77]) by bay0-omc1-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 20:45:43 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: , Date: Wed, 16 Apr 2008 11:45:43 +0800 Importance: Normal In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> References: <4804B03C.6060507@voltaire.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 03:45:43.0830 (UTC) FILETIME=[5900B360:01C89F74] Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397535522==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1397535522== Content-Type: multipart/alternative; boundary="_9b58b40e-2262-40eb-9df7-c7231f59833c_" --_9b58b40e-2262-40eb-9df7-c7231f59833c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi David, Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack. Best Regards, Jason From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Tue, 15 Apr 2008 23:04:15 -0400To: hzj_wuying@hotmail.com; ips@ietf.org The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. Thanks, --David ----------------------------------------------------David L. Black, Distinguished EngineerEMC Corporation, 176 South St., Hopkinton, MA 01748+1 (508) 293-7953 FAX: +1 (508) 293-7786black_david@emc.com Mobile: +1 (978) 394-7754---------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJasonSent: Tuesday, April 15, 2008 9:59 PMTo: ips@ietf.orgSubject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Dears, I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator. But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload. So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it? Thanks! Best Regards, Jason “七件武器，七种完美” 立刻体验！ _________________________________________________________________ 用手机MSN聊天写邮件看空间，无限沟通，分享精彩！ http://mobile.msn.com.cn/ --_9b58b40e-2262-40eb-9df7-c7231f59833c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi David,

Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack.


Best Regards,
Jason
From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Tue, 15 Apr 2008 23:04:15 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

The original PDU header has to be sent back so that the initiator
knows what was rejected.  iSCSI has a number of mechanisms that
can be used by the target to control resource consumption and
those should be used to ensure that adequate resources are
available to deal with the PDU that is to be rejected.
 
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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJason
Sent: Tuesday, April 15, 2008 9:59 PM
To: ips@ietf.org
Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable

Dears,
I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator.
 
But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload.
 
So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it?
 
Thanks!

Best Regards,

Jason 


“七件武器，七种完美” 立刻体验！

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ --_9b58b40e-2262-40eb-9df7-c7231f59833c_-- --===============1397535522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1397535522==-- From ips-bounces@ietf.org Tue Apr 15 21:29:55 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E803A3A6A56; Tue, 15 Apr 2008 21:29:54 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27A63A6A56 for ; Tue, 15 Apr 2008 21:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjEOMi5zBo6x for ; Tue, 15 Apr 2008 21:29:52 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 703173A6838 for ; Tue, 15 Apr 2008 21:29:52 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3G4UPot020340; Wed, 16 Apr 2008 00:30:25 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 16 Apr 2008 00:30:24 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3G4U9Hx026763; Wed, 16 Apr 2008 00:30:21 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 00:30:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 00:30:10 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5FDE@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Thread-Index: AcifdHCdTM7IFMUCSJmZOlL1al0rXAABJdpQ References: <4804B03C.6060507@voltaire.com><8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> To: , X-OriginalArrivalTime: 16 Apr 2008 04:30:12.0434 (UTC) FILETIME=[8F9D5B20:01C89F7A] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, CN_TLD 0.5, MIME_CHARSET_FARAWAY 0.409, HTML_50_70 0.1, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HIGHBITS 0, __IMS_MSGID 0, __MIME_CHARSET_FARAWAY 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1736358156==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1736358156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89F7A.8EB58230" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89F7A.8EB58230 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Jason, =20 The CmdSN window allows the target to control the resources consumed by commands. I don't understand the need to save "all PDU header comes from the Initiator until corresponding statSN is explicitly ACKed". What purpose is that accomplishing (e.g., why save all the iSCSI Data-Out PDU headers for a SCSI WRITE)? =20 In any case, the original PDU header is required for a Reject in order for the initiator to figure out what was rejected. If the initiator cannot figure that out, it is going to have a very difficult time recovering from the Reject. =20 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason Sent: Tuesday, April 15, 2008 11:46 PM To: Black, David; ips@ietf.org Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =20 =09 Hi David, =09 Thank you for the suggestion. A little more to consider is that it = seems that whatever mechanisms we use, as a target, we must reserve all = PDU header comes from Initiator until the coressponding statSN is = explicitly acked. For a resource-limted iscsi target engine(all SCSI = data is on host, so it is not in this question), It can be considered as = a big memory consumer and becomes a bottlenack.=20 =09 =09 Best Regards, Jason =09 ________________________________ From: Black_David@emc.com Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable Date: Tue, 15 Apr 2008 23:04:15 -0400 To: hzj_wuying@hotmail.com; ips@ietf.org =09 =09 The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. =20 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =09 ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason Sent: Tuesday, April 15, 2008 9:59 PM To: ips@ietf.org Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =09 =09 Dears, =09 I am curently implement iscsi target on a resource-limted device. In = my implementation, orignal to-be-rejected PDU is not available when it = realised that a Reject should be sent to initiator. =20 But as RFC3720 said, Target must send back the orignal PDU as the = Reject's payload.=20 =20 So my question is: Why we need to send back the orignal PDU ? Can we = simply eliminate it? =20 Thanks! =09 Best Regards, Jason=20 ________________________________ =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1 =20 ________________________________ Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 = =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1 = ------_=_NextPart_001_01C89F7A.8EB58230 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Jason,
 
The CmdSN window allows the target to control the resources=20 consumed
by commands.  I don't understand the need to save "all = PDU=20 header
comes from the Initiator until corresponding = statSN is=20 explicitly
ACKed".  What purpose is that accomplishing (e.g., why = save=20 all
the iSCSI Data-Out PDU headers for a = SCSI=20 WRITE)?
 
In any case, the original PDU header is required for a = Reject in=20 order
for the initiator to figure out what was = rejected.  If=20 the initiator
cannot figure that out, it is going to have a very difficult=20 time
recovering from the Reject.
 
Thanks,
--David

----------------------------------------------------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508)=20 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 394-7754
----------------------------------------------------

From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason
Sent:=20 Tuesday, April 15, 2008 11:46 PM
To: Black, David;=20 ips@ietf.org
Subject: Re: [Ips] Send Reject PDU when orignal = to-be-rejected PDU is notavailable
 
Hi David,

Thank you for the suggestion. A = little more=20 to consider is that it seems that whatever mechanisms we use, as a = target, we=20 must reserve all PDU header comes from Initiator until the = coressponding=20 statSN is explicitly acked. For a resource-limted iscsi target = engine(all=20 SCSI data is on host, so it is not in this question), It can be = considered as=20 a big memory consumer and becomes a bottlenack.


Best=20 Regards,
Jason
From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when = orignal=20 to-be-rejected PDU is notavailable
Date: Tue, 15 Apr 2008 = 23:04:15=20 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

The original PDU header has to be sent = back so=20 that the initiator
knows what was rejected.  iSCSI = has a number=20 of mechanisms that
can be used by the target to control = resource=20 consumption and
those should be used=20 to ensure that adequate resources are
available to = deal with the=20 PDU that is to be rejected.
 
Thanks,
--David
----------------------------------------------------
David = L.=20 Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508)=20 = 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason
Sent:=20 Tuesday, April 15, 2008 9:59 PM
To:=20 ips@ietf.org
Subject: [Ips] Send Reject PDU when orignal = to-be-rejected PDU is notavailable

Dears,
I am curently = implement=20 iscsi target on a resource-limted device. In my implementation, = orignal=20 to-be-rejected PDU is not available when it realised that a = Reject=20 should be sent to initiator.
 
But as RFC3720 said, = Target=20 must send back the orignal PDU as the Reject's = payload.=20
 
So my question is: Why we need to send = back the=20 orignal PDU ? Can we simply eliminate=20 it?
 
Thanks!

Best Regards,

Jason 


=A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1=20

Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1=20 ------_=_NextPart_001_01C89F7A.8EB58230-- --===============1736358156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1736358156==-- From ips-bounces@ietf.org Tue Apr 15 23:12:19 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59073A6BA9; Tue, 15 Apr 2008 23:12:19 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2C53A6C46 for ; Tue, 15 Apr 2008 23:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.456 X-Spam-Level: ** X-Spam-Status: No, score=2.456 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6cfM7wKCTgK for ; Tue, 15 Apr 2008 23:12:16 -0700 (PDT) Received: from bay0-omc1-s36.bay0.hotmail.com (bay0-omc1-s36.bay0.hotmail.com [65.54.246.108]) by core3.amsl.com (Postfix) with ESMTP id 1BCF53A6A9B for ; Tue, 15 Apr 2008 23:12:16 -0700 (PDT) Received: from BAY135-W46 ([65.55.140.81]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 23:12:51 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: , Date: Wed, 16 Apr 2008 14:12:51 +0800 Importance: Normal In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91016F5FDE@CORPUSMX20A.corp.emc.com> References: <4804B03C.6060507@voltaire.com><8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5FDE@CORPUSMX20A.corp.emc.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 06:12:51.0344 (UTC) FILETIME=[E69C7100:01C89F88] Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0156123892==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0156123892== Content-Type: multipart/alternative; boundary="_deae3a60-40b7-494c-aa2a-d87b5b9b8862_" --_deae3a60-40b7-494c-aa2a-d87b5b9b8862_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit David, In some situations, for example, one or more DATA-OUT PDUs of a WRITE are CRC ERROR. If the implementation(just like mine) choose to use Pipeline fashion process in which TX and RX are seperated as two stages, then it seems we have no choice but to hold those CRC ERROR DATA-OUT PDU headers until the REJECTs sent out. As we do not know how many DATA-OUT PDU will become CRC ERROR in RX stage, so we choose to reserve all DATA-OUT PDU headers in the end. Best Regards, Jason HU From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Wed, 16 Apr 2008 00:30:10 -0400To: hzj_wuying@hotmail.com; ips@ietf.org Jason, The CmdSN window allows the target to control the resources consumed by commands. I don't understand the need to save "all PDU header comes from the Initiator until corresponding statSN is explicitly ACKed". What purpose is that accomplishing (e.g., why save all the iSCSI Data-Out PDU headers for a SCSI WRITE)? In any case, the original PDU header is required for a Reject in order for the initiator to figure out what was rejected. If the initiator cannot figure that out, it is going to have a very difficult time recovering from the Reject. Thanks, --David ----------------------------------------------------David L. Black, Distinguished EngineerEMC Corporation, 176 South St., Hopkinton, MA 01748+1 (508) 293-7953 FAX: +1 (508) 293-7786black_david@emc.com Mobile: +1 (978) 394-7754---------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJasonSent: Tuesday, April 15, 2008 11:46 PMTo: Black, David; ips@ietf.orgSubject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Hi David,Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack. Best Regards,Jason From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Tue, 15 Apr 2008 23:04:15 -0400To: hzj_wuying@hotmail.com; ips@ietf.org The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. Thanks, --David ----------------------------------------------------David L. Black, Distinguished EngineerEMC Corporation, 176 South St., Hopkinton, MA 01748+1 (508) 293-7953 FAX: +1 (508) 293-7786black_david@emc.com Mobile: +1 (978) 394-7754---------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJasonSent: Tuesday, April 15, 2008 9:59 PMTo: ips@ietf.orgSubject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Dears, I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator. But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload. So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it? Thanks! Best Regards, Jason “七件武器，七种完美” 立刻体验！ Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ _________________________________________________________________ 用手机MSN聊天写邮件看空间，无限沟通，分享精彩！ http://mobile.msn.com.cn/ --_deae3a60-40b7-494c-aa2a-d87b5b9b8862_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit David,
 
In some situations, for example, one or more DATA-OUT PDUs of a WRITE are CRC ERROR. If the implementation(just like mine) choose to use Pipeline fashion process in which TX and RX are seperated as two stages, then it seems we have no choice but to hold those CRC ERROR DATA-OUT PDU headers until the REJECTs sent out. 
 
As we do not know how many DATA-OUT PDU will become CRC ERROR in RX stage, so we choose to reserve all DATA-OUT PDU headers in the end.


Best Regards,
Jason HU

From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Wed, 16 Apr 2008 00:30:10 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

Jason,
 
The CmdSN window allows the target to control the resources consumed
by commands.  I don't understand the need to save "all PDU header
comes from the Initiator until corresponding statSN is explicitly
ACKed".  What purpose is that accomplishing (e.g., why save all
the iSCSI Data-Out PDU headers for a SCSI WRITE)?
 
In any case, the original PDU header is required for a Reject in order
for the initiator to figure out what was rejected.  If the initiator
cannot figure that out, it is going to have a very difficult time
recovering from the Reject.
 
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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJason
Sent: Tuesday, April 15, 2008 11:46 PM
To: Black, David; ips@ietf.org
Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
 
Hi David,

Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack.


Best Regards,
Jason
From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Tue, 15 Apr 2008 23:04:15 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

The original PDU header has to be sent back so that the initiator
knows what was rejected.  iSCSI has a number of mechanisms that
can be used by the target to control resource consumption and
those should be used to ensure that adequate resources are
available to deal with the PDU that is to be rejected.
 
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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJason
Sent: Tuesday, April 15, 2008 9:59 PM
To: ips@ietf.org
Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable

Dears,
I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator.
 
But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload.
 
So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it?
 
Thanks!

Best Regards,

Jason 


“七件武器，七种完美” 立刻体验！

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ --_deae3a60-40b7-494c-aa2a-d87b5b9b8862_-- --===============0156123892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0156123892==-- From ips-bounces@ietf.org Wed Apr 16 01:21:32 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E14028C40D; Wed, 16 Apr 2008 01:21:32 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5766428C400 for ; Wed, 16 Apr 2008 01:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCuuKGu5ib7Q for ; Wed, 16 Apr 2008 01:21:30 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id CE70728C1DE for ; Wed, 16 Apr 2008 01:21:29 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so1365063and.122 for ; Wed, 16 Apr 2008 01:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MvfS14CF9/I0PpiIjRHHPb3RTbPdUSyb4eGlVLw3SWg=; b=LrUU1FZW+MtWTQ11kKlWXfNqnHExHixTe917ytMZe2cotDJfgSk0NFGP7Up+dneUyxaC/v/PWw7+pIJJXD42I8XViXoLtuSuZQQLatYuWghJZ6r2WCgrsTT917fMCTMP0m8AxXs0HjzVr6ghQybpM1kfqKypx6L1LraUStWoNnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WM6eiCH1IAK0O6EODah9o4f2p7HNOf0I3QTcNhGSS/U1OhU50bdXf8Br4o7HG/OTCqy5JbOPho4ukm3uUPYjA5Kk//SXTPDS40zfIjuiPsBzNOwwM/FO1NlEey/Kz/nNTi0cnVOG30tNHF0qjcTDSLHLuPO9nGVcoX52sQ62Wto= Received: by 10.101.69.6 with SMTP id w6mr16879960ank.92.1208334124283; Wed, 16 Apr 2008 01:22:04 -0700 (PDT) Received: by 10.100.212.19 with HTTP; Wed, 16 Apr 2008 01:22:04 -0700 (PDT) Message-ID: <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> Date: Wed, 16 Apr 2008 11:22:04 +0300 From: "Eli Dorfman" To: ofa-general , open-iscsi@googlegroups.com, stgt-devel , "Pete Wyckoff" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4804B03C.6060507@voltaire.com> Cc: ogerlitz@voltaire.com, ips@ietf.org, Mike Ko Subject: Re: [Ips] Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org QWNjb3JkaW5nIHRvIE1pa2UncyBleHBsYW5hdGlvbiBiZWxvdyBpdCBzZWVtcyB0aGF0IHdlIGhh dmUgYSBidWcgaW4KaVNFUiBpbml0aWF0b3IuCkZpeGluZyB0aGlzIGJ1ZyB3aWxsIHJlcXVpcmUg YSBmaXggaW4gdGhlIHN0Z3QgaVNFUiBjb2RlLgoKVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgaW5p dGlhdG9yIHNlbmQgYSBWQSB3aGljaCBhbHJlYWR5IGluY2x1ZGVzIGFuCm9mZnNldCBmb3IgdGhl IHVuc29saWNpdGVkIGRhdGEgKHdoaWNoIGlzIHdyb25nKS4KSW4gaXNlcl9pbml0aWF0b3IuYzo6 aXNlcl9wcmVwYXJlX3dyaXRlX2NtZCB0aGUgY29kZSBsb29rcyBsaWtlIHRoaXM6Cmhkci0+d3Jp dGVfdmEgICA9IGNwdV90b19iZTY0KHJlZ2RfYnVmLT5yZWcudmEgKyB1bnNvbF9zeik7Cgp3ZSB0 aGluayB0aGF0IGl0IHNob3VsZCBiZSBtb2RpZmllZCB0bzoKaGRyLT53cml0ZV92YSAgID0gY3B1 X3RvX2JlNjQocmVnZF9idWYtPnJlZy52YSk7CgpMZXQncyBkaXNjdXNzIHRoaXMgYW5kIHZlcmlm eSB3ZSBpbnRlcnByZXQgdGhlIHNwZWMgY29ycmVjdGx5LgpJZiBhZ3JlZWQgd2Ugd2lsbCBzZW5k IGEgcGF0Y2guCgpFbGkKCjIwMDgvNC8xNSBNaWtlIEtvIDxtYWtvQGFsbWFkZW4uaWJtLmNvbT46 Cj4KPiBWQSBpcyBhIGNvbmNlcHQgaW50cm9kdWNlZCBpbiBhbiBJbmZpbmliYW5kIGFubmV4IHRv IHN1cHBvcnQgaVNFUi4gIEl0Cj4gYXBwZWFycyBpbiB0aGUgZXhwYW5kZWQgaVNFUiBoZWFkZXIg Zm9yIEluZmluaWJhbmQgdXNlIG9ubHkgdG8gc3VwcG9ydCB0aGUKPiBub24tWmVybyBCYXNlZCBW aXJ0dWFsIEFkZHJlc3MgKG5vbi1aQlZBKSB1c2VkIGluIEluZmluaWJhbmQgdnMgdGhlIFpCVkEK PiB1c2VkIGluIElFVEYuCj4KPiAiVGhlIERhdGFEZXNjcmlwdG9yT3V0IGRlc2NyaWJlcyB0aGUg SS9PIGJ1ZmZlciBzdGFydGluZyB3aXRoIHRoZSBpbW1lZGlhdGUKPiB1bnNvbGljaXRlZCBkYXRh IChpZiBhbnkpLCBmb2xsb3dlZCBieSB0aGUgbm9uLWltbWVkaWF0ZSB1bnNvbGljaXRlZCBkYXRh Cj4gKGlmIGFueSkgYW5kIHNvbGljaXRlZCBkYXRhLiIgIElmIG5vbi1aQlZBIG1vZGUgaXMgdXNl ZCwgdGhlbiBWQSBwb2ludHMgdG8KPiB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgYnVmZmVyLiAgU28g aW4geW91ciBleGFtcGxlLCB0aGUgVkEgZmllbGQgaW4gdGhlCj4gZXhwYW5kZWQgaVNFUiBoZWFk ZXIgd2lsbCBiZSB6ZXJvLiAgTm90ZSB0aGF0IGZvciBJRVRGLCBaQlZBIGlzIGFzc3VtZWQgYW5k Cj4gdGhlcmUgaXMgbm8gcHJvdmlzaW9uIHRvIHNwZWNpZnkgYSBkaWZmZXJlbnQgVkEgaW4gdGhl IGlTRVIgaGVhZGVyLgo+Cj4gVGFnZ2VkIG9mZnNldCAoVE8pIHJlZmVycyB0byB0aGUgb2Zmc2V0 IHdpdGhpbiBhIHRhZ2dlZCBidWZmZXIgaW4gUkRNQSBXcml0ZQo+IGFuZCBSRE1BIFJlYWQgUmVx dWVzdCBNZXNzYWdlcy4gIFdoZW4gc2VuZGluZyBub24taW1tZWRpYXRlIHVuc29saWNpdGVkCj4g ZGF0YSwgU2VuZCBNZXNzYWdlIHR5cGVzIGFyZSB1c2VkIGFuZCB0aGUgVE8gZmllbGQgaXMgbm90 IHByZXNlbnQuICBJbnN0ZWFkLAo+IHRoZSBidWZmZXIgb2Zmc2V0IGlzIGFwcHJvcHJpYXRlbHkg cmVwcmVzZW50ZWQgYnkgdGhlIEJ1ZmZlciBPZmZzZXQgZmllbGQgaW4KPiB0aGUgU0NTSSBEYXRh LU91dCBQRFUuICBOb3RlIHRoYXQgVGFnZ2VkIE9mZnNldCBpcyBub3QgdGhlIHNhbWUgYXMgd3Jp dGUgVkEKPiBhbmQgaXQgZG9lcyBub3QgYXBwZWFyIGluIHRoZSBpU0VSIGhlYWRlci4KPgo+IE1p a2UKPgo+Cj4KPiAgRXJleiBaaWxiZXIgPGVyZXp6QHZvbHRhaXJlLmNvbT4KPiBTZW50IGJ5OiBp cHMtYm91bmNlc0BpZXRmLm9yZwo+Cj4gMDQvMTUvMjAwOCAwNjo0MCBBTQo+Cj4gVG8gaXBzQGll dGYub3JnCj4KPiBjYwo+Cj4gU3ViamVjdCBbSXBzXSBDYWxjdWxhdGluZyB0aGUgVkEgaW4gaVNF UiBoZWFkZXIKPgo+Cj4KPgo+Cj4KPiBXZSdyZSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0IHNo b3VsZCBiZSB0aGUgd3JpdGUgVkEgKHRhZ2dlZCBvZmZzZXQpCj4gIGluIHRoZSBpU0VSIGhlYWRl ciBmb3IgV1JJVEUgY29tbWFuZHMuIElmIHVuc29saWNpdGVkIGRhdGEgaXMgdG8gYmUKPiAgc2Vu dCwgc2hvdWxkIHRoZSBWQSBiZSB0aGUgb3JpZ2luYWwgVkEgb3Igc2hvdWxkIGl0IGJlIG9yaWdp bmFsIFZBICsKPiAgRmlyc3RCdXJzdExlbmd0aD8KPgo+Cj4gIEV4YW1wbGU6Cj4KPgo+ICBJbml0 aWFsUjJUPU5vCj4KPiAgRmlyc3RCdXJzdExlbmd0aCA9IDEwMDAKPgo+Cj4gIEJhc2UgYWRkcmVz cyBvZiB0aGUgcmVnaXN0ZXJlZCBidWZmZXIgPSAwCj4KPgo+ICBOb3csIHdoYXQgc2hvdWxkIGJl IHRoZSBWQSBpbiB0aGUgaVNFUiBoZWFkZXI/IDAgb3IgMTAwMD8KPgo+Cj4gIFdlIHJlYWQgdGhl IGZvbGxvd2luZyBwYXJhZ3JhcGggaW4gdGhlIGlTRVIgc3BlYywgYnV0IGRpZG4ndCBnZXQgYW4K PiAgYW5zd2VyIGZyb20gdGhlcmU6Cj4KPgo+ICAqIElmIHRoZXJlIGlzIHNvbGljaXRlZCBkYXRh IHRvIGJlIHRyYW5zZmVycmVkIGZvciB0aGUgU0NTSSB3cml0ZSBvcgo+ICBiaWRpcmVjdGlvbmFs IGNvbW1hbmQsIGFzIGluZGljYXRlZCBieSB0aGUgRXhwZWN0ZWQgRGF0YSBUcmFuc2Zlcgo+ICBM ZW5ndGggaW4gdGhlIFNDU0kgQ29tbWFuZCBQRFUgZXhjZWVkaW5nIHRoZSB2YWx1ZSBvZgo+ICBV bnNvbGljaXRlZERhdGFTaXplLCB0aGUgaVNFUiBsYXllciBhdCB0aGUgaW5pdGlhdG9yIE1VU1Qg ZG8gdGhlCj4gIGZvbGxvd2luZzoKPgo+ICBhLiBJdCBNVVNUIGFsbG9jYXRlIGEgV3JpdGUgU1Rh ZyBmb3IgdGhlIEkvTyBCdWZmZXIgZGVmaW5lZCBieQo+ICB0aGUgcXVhbGlmaWVyIERhdGFEZXNj cmlwdG9yT3V0LiBUaGUgRGF0YURlc2NyaXB0b3JPdXQKPiAgZGVzY3JpYmVzIHRoZSBJL08gYnVm ZmVyIHN0YXJ0aW5nIHdpdGggdGhlIGltbWVkaWF0ZQo+ICB1bnNvbGljaXRlZCBkYXRhIChpZiBh bnkpLCBmb2xsb3dlZCBieSB0aGUgbm9uLWltbWVkaWF0ZQo+ICB1bnNvbGljaXRlZCBkYXRhIChp ZiBhbnkpIGFuZCBzb2xpY2l0ZWQgZGF0YS4gVGhpcyBtZWFucwo+ICB0aGF0IHRoZSBCdWZmZXJP ZmZzZXQgZm9yIHRoZSBTQ1NJIERhdGEtb3V0IGZvciB0aGlzCj4gIGNvbW1hbmQgaXMgZXF1YWwg dG8gdGhlIFRPLiBUaGlzIGltcGxpZXMgdGhhdCBhIHplcm8gVE8KPiAgZm9yIHRoaXMgU1RhZyBw b2ludHMgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGlzIEkvTyBCdWZmZXIuCj4KPgo+ICBUaGFua3Ms Cj4KPiAgLS0KPgo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPgo+ICBFcmV6IFppbGJlciB8IDk3Mi05LTk3MS03Njg5Cj4KPiAg U29mdHdhcmUgRW5naW5lZXIsIFN0b3JhZ2UgU29sdXRpb25zCj4KPiAgVm9sdGFpcmUg4oCTIF9U aGUgR3JpZCBCYWNrYm9uZV8KPgo+ICBfXwo+Cj4gIHd3dy52b2x0YWlyZS5jb20gPGh0dHA6Ly93 d3cudm9sdGFpcmUuY29tLz4KPgo+Cj4KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiAgSXBzIG1haWxpbmcgbGlzdAo+ICBJcHNAaWV0Zi5vcmcKPiAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHMKPgo+Cj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiAgSXBzIG1haWxpbmcgbGlz dAo+ICBJcHNAaWV0Zi5vcmcKPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHMKPgo+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CklwcyBtYWlsaW5nIGxpc3QKSXBzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBzCg== From ips-bounces@ietf.org Wed Apr 16 07:24:43 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5933A6BC4; Wed, 16 Apr 2008 07:24:43 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E2F3A6CF3 for ; Wed, 16 Apr 2008 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaKocG0madAT for ; Wed, 16 Apr 2008 07:24:37 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id AA0DD3A6BC4 for ; Wed, 16 Apr 2008 07:24:36 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3GEP9su003422; Wed, 16 Apr 2008 10:25:10 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Wed, 16 Apr 2008 10:22:05 -0400 Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3GEOXUZ008763; Wed, 16 Apr 2008 10:25:04 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 10:24:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 10:24:49 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F5FE0@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Thread-Index: AcifiOrGtBnsaAhoTEqW99iBZB4ItwAQ4+dg References: <4804B03C.6060507@voltaire.com><8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5FDE@CORPUSMX20A.corp.emc.com> To: , X-OriginalArrivalTime: 16 Apr 2008 14:24:50.0716 (UTC) FILETIME=[A18725C0:01C89FCD] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, CN_TLD 0.5, MIME_CHARSET_FARAWAY 0.409, HTML_50_70 0.1, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HIGHBITS 0, __IMS_MSGID 0, __MIME_CHARSET_FARAWAY 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0924911854==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0924911854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89FCD.A0EB4741" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89FCD.A0EB4741 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable But that only requires holding a Data-Out PDU header while the corresponding data is in the RX pipe - once the data digest CRC has been checked, the Data-Out PDU headers can be discarded - they don't have to be held until the status is sent and acked. =20 Reject is primarily intended for errors that can be detected on receipt of the PDU. =20 Thanks, --David ________________________________ From: HUJason [mailto:hzj_wuying@hotmail.com]=20 Sent: Wednesday, April 16, 2008 2:13 AM To: Black, David; ips@ietf.org Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =09 =09 David, =20 In some situations, for example, one or more DATA-OUT PDUs of a WRITE = are CRC ERROR. If the implementation(just like mine) choose to use = Pipeline fashion process in which TX and RX are seperated as two stages, = then it seems we have no choice but to hold those CRC ERROR DATA-OUT PDU = headers until the REJECTs sent out. =20 =20 As we do not know how many DATA-OUT PDU will become CRC ERROR in RX = stage, so we choose to reserve all DATA-OUT PDU headers in the end.=20 =09 =09 Best Regards, Jason HU =09 =09 ________________________________ From: Black_David@emc.com Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable Date: Wed, 16 Apr 2008 00:30:10 -0400 To: hzj_wuying@hotmail.com; ips@ietf.org =09 =09 Jason, =20 The CmdSN window allows the target to control the resources consumed by commands. I don't understand the need to save "all PDU header comes from the Initiator until corresponding statSN is explicitly ACKed". What purpose is that accomplishing (e.g., why save all the iSCSI Data-Out PDU headers for a SCSI WRITE)? =20 In any case, the original PDU header is required for a Reject in order for the initiator to figure out what was rejected. If the initiator cannot figure that out, it is going to have a very difficult time recovering from the Reject. =20 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =09 ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason Sent: Tuesday, April 15, 2008 11:46 PM To: Black, David; ips@ietf.org Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =20 =09 Hi David, =09 Thank you for the suggestion. A little more to consider is that it = seems that whatever mechanisms we use, as a target, we must reserve all = PDU header comes from Initiator until the coressponding statSN is = explicitly acked. For a resource-limted iscsi target engine(all SCSI = data is on host, so it is not in this question), It can be considered as = a big memory consumer and becomes a bottlenack.=20 =09 =09 Best Regards, Jason =09 ________________________________ From: Black_David@emc.com Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU = is notavailable Date: Tue, 15 Apr 2008 23:04:15 -0400 To: hzj_wuying@hotmail.com; ips@ietf.org =09 =09 The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. =20 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@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =09 ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf = Of HUJason Sent: Tuesday, April 15, 2008 9:59 PM To: ips@ietf.org Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is = notavailable =09 =09 Dears, =09 I am curently implement iscsi target on a resource-limted device. = In my implementation, orignal to-be-rejected PDU is not available when = it realised that a Reject should be sent to initiator. =20 But as RFC3720 said, Target must send back the orignal PDU as the = Reject's payload.=20 =20 So my question is: Why we need to send back the orignal PDU ? Can = we simply eliminate it? =20 Thanks! =09 Best Regards, Jason=20 ________________________________ =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1 =20 ________________________________ Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 = =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1 = ________________________________ Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 = =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1 = ------_=_NextPart_001_01C89FCD.A0EB4741 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
But that only requires holding a Data-Out PDU header while=20 the
corresponding data is in the RX pipe - once the data = digest=20 CRC
has been checked, the = Data-Out=20 PDU headers can be discarded -
they don't have to be held until the status is sent and=20 acked.
 
Reject is primarily intended for errors = that can be=20 detected
on receipt of the PDU.
 
Thanks,
--David

From: HUJason = [mailto:hzj_wuying@hotmail.com]=20
Sent: Wednesday, April 16, 2008 2:13 AM
To: = Black, David;=20 ips@ietf.org
Subject: RE: [Ips] Send Reject PDU when orignal = to-be-rejected PDU is notavailable

David,
 
In some situations, for example, one or = more=20 DATA-OUT PDUs of a WRITE are CRC ERROR. If the implementation(just = like mine)=20 choose to use Pipeline fashion process in which TX and RX are = seperated as two=20 stages, then it seems we have no choice but to hold those CRC ERROR = DATA-OUT=20 PDU headers until the REJECTs sent out. 
 
As we do = not know=20 how many DATA-OUT PDU will become CRC ERROR in RX stage, so = we choose=20 to reserve all DATA-OUT PDU headers in the end.


Best=20 Regards,
Jason HU

From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when = orignal=20 to-be-rejected PDU is notavailable
Date: Wed, 16 Apr 2008 = 00:30:10=20 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

Jason,
 
The CmdSN window allows the target to = control the=20 resources consumed
by commands. =20 I don't understand the need to save "all PDU = header
comes from the=20 Initiator until corresponding statSN is = explicitly
ACKed".  What purpose is that=20 accomplishing (e.g., why save all
the iSCSI Data-Out PDU headers = for a SCSI=20 WRITE)?
 
In any case, the original PDU = header is=20 required for a Reject in order
for the initiator to=20 figure out what was rejected.  If the = initiator
cannot figure that out, it is going to = have a very=20 difficult time
recovering from the = Reject.
 
Thanks,
--David
----------------------------------------------------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St.,=20 Hopkinton, MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508)=20 = 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------
From: = ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason
Sent:=20 Tuesday, April 15, 2008 11:46 PM
To: Black, David;=20 ips@ietf.org
Subject: Re: [Ips] Send Reject PDU when = orignal=20 to-be-rejected PDU is notavailable
 
Hi David,

Thank you for the suggestion. A = little=20 more to consider is that it seems that whatever mechanisms we use, = as a=20 target, we must reserve all PDU header comes from Initiator = until the=20 coressponding statSN is explicitly acked. For a = resource-limted iscsi=20 target engine(all SCSI data is on host, so it is not in this = question), It=20 can be considered as a big memory consumer and becomes a = bottlenack.=20


Best Regards,
Jason
From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU = when=20 orignal to-be-rejected PDU is notavailable
Date: Tue, 15 Apr = 2008=20 23:04:15 -0400
To: hzj_wuying@hotmail.com; = ips@ietf.org

The original PDU header has to be = sent back so=20 that the initiator
knows what was rejected.  = iSCSI has a=20 number of mechanisms that
can be used by the target to = control resource=20 consumption and
those should be=20 used to ensure that adequate = resources are
available to deal=20 with the PDU that is to be=20 rejected.
 
Thanks,
--David
----------------------------------------------------
David = L.=20 Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton, MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508)=20 = 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org = [mailto:ips-bounces@ietf.org] On Behalf Of=20 HUJason
Sent: Tuesday, April 15, 2008 9:59=20 PM
To: ips@ietf.org
Subject: [Ips] Send = Reject PDU=20 when orignal to-be-rejected PDU is = notavailable

Dears,
I am = curently=20 implement iscsi target on a resource-limted device. In my=20 implementation, orignal to-be-rejected PDU is not available = when it=20 realised that a Reject should be sent to = initiator.
 
But=20 as RFC3720 said, Target must send back the orignal = PDU as=20 the Reject's payload.
 
So my question is: Why = we need=20 to send back the orignal PDU ? Can we simply eliminate=20 it?
 
Thanks!

Best Regards,

Jason 


= =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1=20

Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1=20
Windows Live = Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3= =AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1=20 ------_=_NextPart_001_01C89FCD.A0EB4741-- --===============0924911854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0924911854==-- From ips-bounces@ietf.org Wed Apr 16 08:05:36 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40A828C157; Wed, 16 Apr 2008 08:05:36 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B083A69CF for ; Wed, 16 Apr 2008 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYRrkisnlUf5 for ; Wed, 16 Apr 2008 07:47:55 -0700 (PDT) Received: from quasar.osc.edu (quasar.osc.edu [192.148.249.15]) by core3.amsl.com (Postfix) with ESMTP id 624403A6879 for ; Wed, 16 Apr 2008 07:47:55 -0700 (PDT) Received: by quasar.osc.edu (Postfix, from userid 7770) id 5A0B7900FBA; Wed, 16 Apr 2008 10:48:30 -0400 (EDT) Date: Wed, 16 Apr 2008 10:48:30 -0400 From: Pete Wyckoff To: open-iscsi@googlegroups.com Message-ID: <20080416144830.GC23861@osc.edu> References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> X-Mailman-Approved-At: Wed, 16 Apr 2008 08:05:35 -0700 Cc: stgt-devel , ogerlitz@voltaire.com, ofa-general , Mike Ko , ips@ietf.org Subject: Re: [Ips] Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org dorfman.eli@gmail.com wrote on Wed, 16 Apr 2008 11:22 +0300: > According to Mike's explanation below it seems that we have a bug in > iSER initiator. > Fixing this bug will require a fix in the stgt iSER code. > > The problem is that the initiator send a VA which already includes an > offset for the unsolicited data (which is wrong). > In iser_initiator.c::iser_prepare_write_cmd the code looks like this: > hdr->write_va = cpu_to_be64(regd_buf->reg.va + unsol_sz); > > we think that it should be modified to: > hdr->write_va = cpu_to_be64(regd_buf->reg.va); > > Let's discuss this and verify we interpret the spec correctly. > If agreed we will send a patch. Agree with the interpretation of the spec, and it's probably a bit clearer that way too. But we have working initiators and targets that do it the "wrong" way. The transition involved in fixing both sides will lead to problems. How does a target detect an unfixed initiator and vice versa? A mismatched pair will lead to data corruption. We could address this in a few ways: 1. Flag day: all initiators and targets change at the same time. Will see data corruption if someone unluckily runs one or the other using old non-fixed code. 2. Rewrite the IB Annex to codify what's done in practice, and don't "fix" any code. 3. Start using the Hello messages and extend them to specify if the VA marks the start of the buffer or the unsol offset. I really don't look forward to the bug reports we'll get from a flag da approach. Old linux versions tend to hang around for a very long time, and people are often reluctant to upgrade. -- Pete > 2008/4/15 Mike Ko : > > > > VA is a concept introduced in an Infiniband annex to support iSER. It > > appears in the expanded iSER header for Infiniband use only to support the > > non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA > > used in IETF. > > > > "The DataDescriptorOut describes the I/O buffer starting with the immediate > > unsolicited data (if any), followed by the non-immediate unsolicited data > > (if any) and solicited data." If non-ZBVA mode is used, then VA points to > > the beginning of this buffer. So in your example, the VA field in the > > expanded iSER header will be zero. Note that for IETF, ZBVA is assumed and > > there is no provision to specify a different VA in the iSER header. > > > > Tagged offset (TO) refers to the offset within a tagged buffer in RDMA Write > > and RDMA Read Request Messages. When sending non-immediate unsolicited > > data, Send Message types are used and the TO field is not present. Instead, > > the buffer offset is appropriately represented by the Buffer Offset field in > > the SCSI Data-Out PDU. Note that Tagged Offset is not the same as write VA > > and it does not appear in the iSER header. > > > > Mike > > > > Erez Zilber > > Sent by: ips-bounces@ietf.org > > > > 04/15/2008 06:40 AM > > > > To ips@ietf.org > > > > cc > > > > Subject [Ips] Calculating the VA in iSER header > > > > We're trying to understand what should be the write VA (tagged offset) > > in the iSER header for WRITE commands. If unsolicited data is to be > > sent, should the VA be the original VA or should it be original VA + > > FirstBurstLength? > > > > > > Example: > > > > > > InitialR2T=No > > > > FirstBurstLength = 1000 > > > > > > Base address of the registered buffer = 0 > > > > > > Now, what should be the VA in the iSER header? 0 or 1000? > > > > > > We read the following paragraph in the iSER spec, but didn't get an > > answer from there: > > > > > > * If there is solicited data to be transferred for the SCSI write or > > bidirectional command, as indicated by the Expected Data Transfer > > Length in the SCSI Command PDU exceeding the value of > > UnsolicitedDataSize, the iSER layer at the initiator MUST do the > > following: > > > > a. It MUST allocate a Write STag for the I/O Buffer defined by > > the qualifier DataDescriptorOut. The DataDescriptorOut > > describes the I/O buffer starting with the immediate > > unsolicited data (if any), followed by the non-immediate > > unsolicited data (if any) and solicited data. This means > > that the BufferOffset for the SCSI Data-out for this > > command is equal to the TO. This implies that a zero TO > > for this STag points to the beginning of this I/O Buffer. _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Apr 16 18:10:31 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F7628C433; Wed, 16 Apr 2008 18:10:31 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69DA3A66B4 for ; Wed, 16 Apr 2008 18:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.432 X-Spam-Level: *** X-Spam-Status: No, score=3.432 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGaqXvETLqpe for ; Wed, 16 Apr 2008 18:10:27 -0700 (PDT) Received: from bay0-omc1-s34.bay0.hotmail.com (bay0-omc1-s34.bay0.hotmail.com [65.54.246.106]) by core3.amsl.com (Postfix) with ESMTP id 2FD223A6CF9 for ; Wed, 16 Apr 2008 18:09:59 -0700 (PDT) Received: from BAY135-W56 ([65.55.140.91]) by bay0-omc1-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 18:10:36 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: , Date: Thu, 17 Apr 2008 09:10:36 +0800 Importance: Normal In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91016F5FE0@CORPUSMX20A.corp.emc.com> References: <4804B03C.6060507@voltaire.com><8CC6CEAB44F131478D3A7B429ECACD91016F5FD7@CORPUSMX20A.corp.emc.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5FDE@CORPUSMX20A.corp.emc.com> <8CC6CEAB44F131478D3A7B429ECACD91016F5FE0@CORPUSMX20A.corp.emc.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2008 01:10:36.0043 (UTC) FILETIME=[D78ADDB0:01C8A027] Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1177213917==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1177213917== Content-Type: multipart/alternative; boundary="_b8a33e2b-ebbb-4119-8e62-8e9477ebbed5_" --_b8a33e2b-ebbb-4119-8e62-8e9477ebbed5_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit David, Oh, sorry I am wrong on that point, PDU headers don't have to be held until the status is sent and acked. I will make it correctly. Thanks,Jason From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Wed, 16 Apr 2008 10:24:49 -0400To: hzj_wuying@hotmail.com; ips@ietf.org But that only requires holding a Data-Out PDU header while the corresponding data is in the RX pipe - once the data digest CRC has been checked, the Data-Out PDU headers can be discarded - they don't have to be held until the status is sent and acked. Reject is primarily intended for errors that can be detected on receipt of the PDU. Thanks, --David From: HUJason [mailto:hzj_wuying@hotmail.com] Sent: Wednesday, April 16, 2008 2:13 AMTo: Black, David; ips@ietf.orgSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable David, In some situations, for example, one or more DATA-OUT PDUs of a WRITE are CRC ERROR. If the implementation(just like mine) choose to use Pipeline fashion process in which TX and RX are seperated as two stages, then it seems we have no choice but to hold those CRC ERROR DATA-OUT PDU headers until the REJECTs sent out. As we do not know how many DATA-OUT PDU will become CRC ERROR in RX stage, so we choose to reserve all DATA-OUT PDU headers in the end. Best Regards,Jason HU From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Wed, 16 Apr 2008 00:30:10 -0400To: hzj_wuying@hotmail.com; ips@ietf.org Jason, The CmdSN window allows the target to control the resources consumed by commands. I don't understand the need to save "all PDU header comes from the Initiator until corresponding statSN is explicitly ACKed". What purpose is that accomplishing (e.g., why save all the iSCSI Data-Out PDU headers for a SCSI WRITE)? In any case, the original PDU header is required for a Reject in order for the initiator to figure out what was rejected. If the initiator cannot figure that out, it is going to have a very difficult time recovering from the Reject. Thanks, --David ----------------------------------------------------David L. Black, Distinguished EngineerEMC Corporation, 176 South St., Hopkinton, MA 01748+1 (508) 293-7953 FAX: +1 (508) 293-7786black_david@emc.com Mobile: +1 (978) 394-7754---------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJasonSent: Tuesday, April 15, 2008 11:46 PMTo: Black, David; ips@ietf.orgSubject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Hi David,Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack. Best Regards,Jason From: Black_David@emc.comSubject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailableDate: Tue, 15 Apr 2008 23:04:15 -0400To: hzj_wuying@hotmail.com; ips@ietf.org The original PDU header has to be sent back so that the initiator knows what was rejected. iSCSI has a number of mechanisms that can be used by the target to control resource consumption and those should be used to ensure that adequate resources are available to deal with the PDU that is to be rejected. Thanks, --David ----------------------------------------------------David L. Black, Distinguished EngineerEMC Corporation, 176 South St., Hopkinton, MA 01748+1 (508) 293-7953 FAX: +1 (508) 293-7786black_david@emc.com Mobile: +1 (978) 394-7754---------------------------------------------------- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJasonSent: Tuesday, April 15, 2008 9:59 PMTo: ips@ietf.orgSubject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable Dears, I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator. But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload. So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it? Thanks! Best Regards, Jason “七件武器，七种完美” 立刻体验！ Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ _________________________________________________________________ MSN 中文网，最新时尚生活资讯，白领聚集门户。 http://cn.msn.com --_b8a33e2b-ebbb-4119-8e62-8e9477ebbed5_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit David,
 
Oh, sorry I am wrong on that point, PDU headers don't have to be held until the status is sent and acked. I will make it correctly.
 
Thanks,
Jason



From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Wed, 16 Apr 2008 10:24:49 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

But that only requires holding a Data-Out PDU header while the
corresponding data is in the RX pipe - once the data digest CRC
has been checked, the Data-Out PDU headers can be discarded -
they don't have to be held until the status is sent and acked.
 
Reject is primarily intended for errors that can be detected
on receipt of the PDU.
 
Thanks,
--David

From: HUJason [mailto:hzj_wuying@hotmail.com]
Sent: Wednesday, April 16, 2008 2:13 AM
To: Black, David; ips@ietf.org
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable

David,
 
In some situations, for example, one or more DATA-OUT PDUs of a WRITE are CRC ERROR. If the implementation(just like mine) choose to use Pipeline fashion process in which TX and RX are seperated as two stages, then it seems we have no choice but to hold those CRC ERROR DATA-OUT PDU headers until the REJECTs sent out. 
 
As we do not know how many DATA-OUT PDU will become CRC ERROR in RX stage, so we choose to reserve all DATA-OUT PDU headers in the end.


Best Regards,
Jason HU

From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Wed, 16 Apr 2008 00:30:10 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

Jason,
 
The CmdSN window allows the target to control the resources consumed
by commands.  I don't understand the need to save "all PDU header
comes from the Initiator until corresponding statSN is explicitly
ACKed".  What purpose is that accomplishing (e.g., why save all
the iSCSI Data-Out PDU headers for a SCSI WRITE)?
 
In any case, the original PDU header is required for a Reject in order
for the initiator to figure out what was rejected.  If the initiator
cannot figure that out, it is going to have a very difficult time
recovering from the Reject.
 
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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJason
Sent: Tuesday, April 15, 2008 11:46 PM
To: Black, David; ips@ietf.org
Subject: Re: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
 
Hi David,

Thank you for the suggestion. A little more to consider is that it seems that whatever mechanisms we use, as a target, we must reserve all PDU header comes from Initiator until the coressponding statSN is explicitly acked. For a resource-limted iscsi target engine(all SCSI data is on host, so it is not in this question), It can be considered as a big memory consumer and becomes a bottlenack.


Best Regards,
Jason
From: Black_David@emc.com
Subject: RE: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable
Date: Tue, 15 Apr 2008 23:04:15 -0400
To: hzj_wuying@hotmail.com; ips@ietf.org

The original PDU header has to be sent back so that the initiator
knows what was rejected.  iSCSI has a number of mechanisms that
can be used by the target to control resource consumption and
those should be used to ensure that adequate resources are
available to deal with the PDU that is to be rejected.
 
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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of HUJason
Sent: Tuesday, April 15, 2008 9:59 PM
To: ips@ietf.org
Subject: [Ips] Send Reject PDU when orignal to-be-rejected PDU is notavailable

Dears,
I am curently implement iscsi target on a resource-limted device. In my implementation, orignal to-be-rejected PDU is not available when it realised that a Reject should be sent to initiator.
 
But as RFC3720 said, Target must send back the orignal PDU as the Reject's payload.
 
So my question is: Why we need to send back the orignal PDU ? Can we simply eliminate it?
 
Thanks!

Best Regards,

Jason 


“七件武器，七种完美” 立刻体验！

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！

Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！

轻松把Hotmail下载到本地，试试 Windows Live Mail。 立即尝试！ --_b8a33e2b-ebbb-4119-8e62-8e9477ebbed5_-- --===============1177213917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1177213917==-- From ips-bounces@ietf.org Thu Apr 17 01:21:35 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86FE3A6CD5; Thu, 17 Apr 2008 01:21:35 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722CD28C18D for ; Thu, 17 Apr 2008 01:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.037 X-Spam-Level: *** X-Spam-Status: No, score=3.037 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwb7VUTJwIOn for ; Thu, 17 Apr 2008 01:21:30 -0700 (PDT) Received: from bay0-omc3-s8.bay0.hotmail.com (bay0-omc3-s8.bay0.hotmail.com [65.54.246.208]) by core3.amsl.com (Postfix) with ESMTP id 808DE3A6BE4 for ; Thu, 17 Apr 2008 01:21:30 -0700 (PDT) Received: from BAY135-W33 ([65.55.140.68]) by bay0-omc3-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Apr 2008 01:22:08 -0700 Message-ID: X-Originating-IP: [221.239.61.183] From: HUJason To: Date: Thu, 17 Apr 2008 16:22:08 +0800 Importance: Normal In-Reply-To: References: <4804B03C.6060507@voltaire.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2008 08:22:08.0209 (UTC) FILETIME=[2079DC10:01C8A064] Subject: [Ips] How to deal with PROTOCOL ERROR on iscsi target side X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832525551==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0832525551== Content-Type: multipart/alternative; boundary="_fbb767f2-c392-4c9c-b53a-9836a61825a4_" --_fbb767f2-c392-4c9c-b53a-9836a61825a4_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dears, If target works on ERL == 0 and meets a PROTOCOL ERROR condition that it can not figure out PDU length any more(no FIM...), what should the target do for session recover? Can it simply drop the TCP connection? Many Many Thanks! Jason _________________________________________________________________ 新年换新颜，快来妆扮自己的MSN给心仪的TA一个惊喜！ http://im.live.cn/emoticons/?ID=18 --_fbb767f2-c392-4c9c-b53a-9836a61825a4_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Dears,
 
If target works on ERL == 0 and meets a PROTOCOL ERROR condition that it can not figure out PDU length any more(no FIM...), what should the target do for session recover? Can it simply drop the TCP connection?
 
 
Many Many Thanks!
Jason

“七件武器，七种完美” 立刻体验！ --_fbb767f2-c392-4c9c-b53a-9836a61825a4_-- --===============0832525551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0832525551==-- From ips-bounces@ietf.org Thu Apr 17 04:12:28 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A0128C0E0; Thu, 17 Apr 2008 04:12:28 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286073A6C74 for ; Thu, 17 Apr 2008 04:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8GVKQxRR0U2 for ; Thu, 17 Apr 2008 04:12:25 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id CB6513A69A3 for ; Thu, 17 Apr 2008 04:12:24 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so5784and.122 for ; Thu, 17 Apr 2008 04:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l0LRp1wBTfFMZy2TeABHaCCgXs8UHR/GgxkoLS6DfSA=; b=mvSgUb1tHWgSH4VAxL7nbfXPE6w+HXMFNwPsvKBhQ3azOwkAqE9oS5TRwO1UimLLvQacplqX097icmgna4NQG70UI/z9okFJNoFvWFFCpfF/rSbM8/0624MB51EyKE4K+IZhApwBYUU4glcBw33H1yq5m/Gmq0a6pj60Dp4U2g4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OxtnBrTUthMLNnYsCEX6SH06+aKdejxS7av6hSbglcGD7u7hCkwIiDFPvB5wSIREJ/JvqVmu1hbGU52OzY3KSMlt8RzqFdQDrCz9oFS0IXSGKbhNW9+ZW+OCOfnD+rgOiwt1TL7JlCq4ytd2uC4muHD0TVKDAgsgf5KU5xEhhrU= Received: by 10.100.194.17 with SMTP id r17mr2289682anf.127.1208430782165; Thu, 17 Apr 2008 04:13:02 -0700 (PDT) Received: by 10.100.212.19 with HTTP; Thu, 17 Apr 2008 04:13:01 -0700 (PDT) Message-ID: <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> Date: Thu, 17 Apr 2008 14:13:01 +0300 From: "Eli Dorfman" To: "Roland Dreier" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> <20080416144830.GC23861@osc.edu> Cc: stgt-devel , Pete Wyckoff , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [ofa-general] Re: Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Wed, Apr 16, 2008 at 6:46 PM, Roland Dreier wrote: > > Agree with the interpretation of the spec, and it's probably a bit > > clearer that way too. But we have working initiators and targets > > that do it the "wrong" way. > > Yes... I guess the key question is whether there are any initiators that > do things the "right" way. > > > > 1. Flag day: all initiators and targets change at the same time. > > Will see data corruption if someone unluckily runs one or the other > > using old non-fixed code. > > Seems unacceptable to me... it doesn't make sense at all to break every > setup in the world just to be "right" according to the spec. This will break only when both initiator and target will use InitialR2T=No, which means allow unsolicited data. As far as I know, STGT is not very common (and its version in RHEL5.1 is considered experimental). Its default is also InitialR2T=Yes. Voltaire's iSCSI over iSER target also uses default InitialR2T=Yes. So it seems that nothing will break. > > > > 2. Rewrite the IB Annex to codify what's done in practice, and don't > > "fix" any code. > > If existing practice is universally to do things "wrong" then this seems > to me by far the best way to proceed. Assuming there aren't many iSER installation that currently work with unsolicited data, then it is the right time to do it right. Future implementation will rely on the spec and unless you modify the spec this will lead to greater confusion. _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Apr 17 08:33:15 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7842728C57C; Thu, 17 Apr 2008 08:33:15 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357C428C218 for ; Wed, 16 Apr 2008 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhAGOVN4WTLy for ; Wed, 16 Apr 2008 08:46:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D713728C45F for ; Wed, 16 Apr 2008 08:45:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,665,1199692800"; d="scan'208";a="11191409" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 16 Apr 2008 08:46:26 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3GFkQ1D014620; Wed, 16 Apr 2008 08:46:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3GFkQLu009890; Wed, 16 Apr 2008 15:46:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 08:46:26 -0700 Received: from roland-conroe ([10.33.42.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 08:46:26 -0700 Received: by roland-conroe (Postfix, from userid 33217) id DD257E71DB; Wed, 16 Apr 2008 08:46:25 -0700 (PDT) From: Roland Dreier To: Pete Wyckoff References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> <20080416144830.GC23861@osc.edu> X-Message-Flag: Warning: May contain useful information Date: Wed, 16 Apr 2008 08:46:25 -0700 In-Reply-To: <20080416144830.GC23861@osc.edu> (Pete Wyckoff's message of "Wed, 16 Apr 2008 10:48:30 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2008 15:46:26.0453 (UTC) FILETIME=[079D5450:01C89FD9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1138; t=1208360786; x=1209224786; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdreier@cisco.com; z=From:=20Roland=20Dreier=20 |Subject:=20Re=3A=20[ofa-general]=20Re=3A=20[Ips]=20Calcula ting=20the=20VA=20in=20iSER=20header |Sender:=20; bh=jdrQ2huR646mgwMVIgzniVQkp4Y5pK4a2y72kjtcahc=; b=E2CkIpZWCfWMFTdNy1cQIbiMzEbcpwfAmdyOuDc8E4JqK8f3dw7zg/WP/Z QUwfsPYC3ZWkB9StOv4XQpHoyf5WWRpE5rwmyhiU3X9v+JuJR8N9x/MDgbao KGa5n0fmG1Mk//oRH9id9zR6nHdhZp0trAMJakgiIFaT8xJ/E+cns=; Authentication-Results: sj-dkim-1; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Thu, 17 Apr 2008 08:33:14 -0700 Cc: ips@ietf.org, open-iscsi@googlegroups.com, stgt-devel , ofa-general , Mike Ko Subject: Re: [Ips] [ofa-general] Re: Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Agree with the interpretation of the spec, and it's probably a bit > clearer that way too. But we have working initiators and targets > that do it the "wrong" way. Yes... I guess the key question is whether there are any initiators that do things the "right" way. > 1. Flag day: all initiators and targets change at the same time. > Will see data corruption if someone unluckily runs one or the other > using old non-fixed code. Seems unacceptable to me... it doesn't make sense at all to break every setup in the world just to be "right" according to the spec. > 2. Rewrite the IB Annex to codify what's done in practice, and don't > "fix" any code. If existing practice is universally to do things "wrong" then this seems to me by far the best way to proceed. > 3. Start using the Hello messages and extend them to specify if the > VA marks the start of the buffer or the unsol offset. this seems like a pain for not much benefit... every initiator and target needs new code to handle the negotiation, and you don't get anything except the satisfaction of following the letter of the spec. _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Apr 17 10:41:49 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C095C3A6C64; Thu, 17 Apr 2008 10:41:49 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7393A6C64 for ; Thu, 17 Apr 2008 10:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoVIzZnF9-as for ; Thu, 17 Apr 2008 10:41:47 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 936333A6968 for ; Thu, 17 Apr 2008 10:41:47 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3HHgMLB027772; Thu, 17 Apr 2008 13:42:22 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Thu, 17 Apr 2008 13:39:02 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3HHg9uK029824; Thu, 17 Apr 2008 13:42:20 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Apr 2008 13:42:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 13:42:15 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F600D@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] How to deal with PROTOCOL ERROR on iscsi target side Thread-Index: AcigZDORYnvm8cGoQVOCW7nDeIrEJQATQFyw References: <4804B03C.6060507@voltaire.com> To: , X-OriginalArrivalTime: 17 Apr 2008 17:42:17.0032 (UTC) FILETIME=[60E54480:01C8A0B2] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=3%, Reason='EMC_FROM_0+ -3, CN_TLD 0.5, MIME_CHARSET_FARAWAY 0.409, HTML_50_70 0.1, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HIGHBITS 0, __IMS_MSGID 0, __MIME_CHARSET_FARAWAY 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Subject: Re: [Ips] How to deal with PROTOCOL ERROR on iscsi target side X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2059211585==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2059211585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A0B2.603C09D1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A0B2.603C09D1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Yes, as any data received subsequently on that connection will have to be discarded, but see Section 6.4 of RFC 3720 for applicable timeouts. =20 Thanks, --David ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason Sent: Thursday, April 17, 2008 4:22 AM To: ips@ietf.org Subject: [Ips] How to deal with PROTOCOL ERROR on iscsi target side =09 =09 Dears, =20 If target works on ERL =3D=3D 0 and meets a PROTOCOL ERROR condition = that it can not figure out PDU length any more(no FIM...), what should = the target do for session recover? Can it simply drop the TCP = connection? =20 =20 Many Many Thanks! Jason =09 =09 ________________________________ =A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 = =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1 =20 ------_=_NextPart_001_01C8A0B2.603C09D1 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Yes, as any data received subsequently on that connection=20 will
have to be discarded, but see Section 6.4 of RFC 3720=20 for
applicable timeouts.
 
Thanks,
--David

From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of = HUJason
Sent:=20 Thursday, April 17, 2008 4:22 AM
To: = ips@ietf.org
Subject:=20 [Ips] How to deal with PROTOCOL ERROR on iscsi target=20 side

Dears,
 
If target works on ERL =3D=3D 0 and = meets a=20 PROTOCOL ERROR condition that it can not figure out PDU length any = more(no=20 FIM...), what should the target do for session recover? Can it = simply=20 drop the TCP connection?
 
 
Many Many=20 Thanks!
Jason

=A1=B0=C6=DF=BC=FE=CE=E4=C6=F7=A3=AC=C6=DF=D6=D6=CD=EA=C3=C0=A1=B1 =C1=A2=BF=CC=CC=E5=D1=E9=A3=A1=20 ------_=_NextPart_001_01C8A0B2.603C09D1-- --===============2059211585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============2059211585==-- From nialaari_1993@SSG.FUJITSU.COM Sun Apr 27 01:41:20 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB71E3A69FB for ; Sun, 27 Apr 2008 01:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.549 X-Spam-Level: X-Spam-Status: No, score=-45.549 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jbohBoYRCOL for ; Sun, 27 Apr 2008 01:41:19 -0700 (PDT) Received: from 181-207-231-201.fibertel.com.ar (181-207-231-201.fibertel.com.ar [201.231.207.181]) by core3.amsl.com (Postfix) with ESMTP id E05383A6E1A for ; Sun, 27 Apr 2008 01:41:11 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sun, 27 Apr 2008 05:41:22 -0300 Subject: Make your girl happy From: Ireland To: "ips-archive@lists.ietf.org" Message-ID: <0CAEE785.6%nialaari_1993@SSG.FUJITSU.COM> Thread-Topic: Make your girl happy Thread-Index: AcioKVM24ubuCQ1JSAWAglwv6465hA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_9973665187_46652" --B_9973665187_46652 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Always dreamt of being a real man? Stop dreaming now http://www.plibmean.com/ --B_9973665187_46652 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Make your girl happy Always dreamt of being a real man? Stop = dreaming now http://www.plibmean.com/
 --B_9973665187_46652-- From ips-bounces@ietf.org Wed Apr 30 00:43:22 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E792128C165; Wed, 30 Apr 2008 00:43:22 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BB43A6B4C for ; Wed, 30 Apr 2008 00:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsqoBGJqfphd for ; Wed, 30 Apr 2008 00:43:17 -0700 (PDT) Received: from blu139-omc2-s7.blu139.hotmail.com (blu139-omc2-s7.blu139.hotmail.com [65.55.175.177]) by core3.amsl.com (Postfix) with ESMTP id B49183A6B0D for ; Wed, 30 Apr 2008 00:43:16 -0700 (PDT) Received: from BLU117-W28 ([65.55.162.186]) by blu139-omc2-s7.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 00:43:19 -0700 Message-ID: X-Originating-IP: [61.14.27.42] From: Ken Sandars To: Pete Wyckoff , Eli Dorfman Date: Wed, 30 Apr 2008 17:43:19 +1000 Importance: Normal In-Reply-To: <20080429170516.GA8857@osc.edu> References: <4804B03C.6060507@voltaire.com> <694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com> <20080416144830.GC23861@osc.edu> <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> <20080429170516.GA8857@osc.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2008 07:43:19.0525 (UTC) FILETIME=[DBD7A150:01C8AA95] Cc: stgt-devel , Roland Dreier , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [Stgt-devel] [ofa-general] Re: Calculating the VA in iSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0193512607==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0193512607== Content-Type: multipart/alternative; boundary="_802566f5-2ed0-4e71-ab21-9b7946f50dc7_" --_802566f5-2ed0-4e71-ab21-9b7946f50dc7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, It appears the current Linux iSER initiator does not send the HELLO message= when the connection transits to full feature phase. The stgt target also i= gnores this message (if it were to appear). Both of these implementations u= se a non-conformant iSER header (they add write_va and read_va fields, whic= h incidentally do not appear to be used). Are these changes documented anyw= here in the IB domain, or are these variations needed for another reason? If these deviations from the RFC are not needed and were to be fixed (along= with the offset fix), then these implementations can detect the current mo= de of operation by examining the size of the iSER header received. The choi= ce to proceed in the broken way, or to terminate the connection (with big l= oud error messages) is the implementor's choice. Either way, the issue is d= etected and corruption avoided. Thoughts? Cheers Ken > Date: Tue, 29 Apr 2008 13:05:16 -0400 > From: pw@osc.edu > To: dorfman.eli@gmail.com > CC: stgt-devel@lists.berlios.de; rdreier@cisco.com; general@lists.openfab= rics.org; mako@almaden.ibm.com; ips@ietf.org; open-iscsi@googlegroups.com > Subject: Re: [Stgt-devel] [ofa-general] Re: [Ips] Calculating the VA in i= SER header >=20 > dorfman.eli@gmail.com wrote on Thu, 17 Apr 2008 14:13 +0300: > > On Wed, Apr 16, 2008 at 6:46 PM, Roland Dreier wrot= e: > > > > Agree with the interpretation of the spec, and it's probably a bit > > > > clearer that way too. But we have working initiators and targets > > > > that do it the "wrong" way. > > > > > > Yes... I guess the key question is whether there are any initiators = that > > > do things the "right" way. > > > > > > > > > > 1. Flag day: all initiators and targets change at the same time. > > > > Will see data corruption if someone unluckily runs one or the oth= er > > > > using old non-fixed code. > > > > > > Seems unacceptable to me... it doesn't make sense at all to break ev= ery > > > setup in the world just to be "right" according to the spec. > >=20 > > This will break only when both initiator and target will use > > InitialR2T=3DNo, which means allow unsolicited data. > > As far as I know, STGT is not very common (and its version in RHEL5.1 > > is considered experimental). Its default is also InitialR2T=3DYes. > > Voltaire's iSCSI over iSER target also uses default InitialR2T=3DYes. > > So it seems that nothing will break. >=20 > I finally got a chance to look at this just now. I think you mean > default is InitialR2T=3DNo above, which means no unsolicited data. > That is the default case, and true, the two different meanings > of the initiator-supplied VA coincide. >=20 > But you missed the impact of immediate data. We run with the > defaults (I think) that say the first write request packet should be > filled with a bit of the coming data stream. From iscsid.conf: >=20 > # To enable immediate data (i.e., the initiator sends unsolicited dat= a > # with the iSCSI command packet), uncomment the following line: > # > # The default is Yes > node.session.iscsi.ImmediateData =3D Yes >=20 > Looking at the offset printed out by your patch, it is indeed > non-zero for the first RDMA read. Please correct me if I am > mistaken about this---you must have tested all four variations of > with and without the patches on initiator and target side, but I did > not. >=20 > Hence I am still a bit unhappy about having to deal with the > fallout, with no way to detect it. For our local use, I'll keep an > older version of stgt in use until we switch to a new kernel, then > merge up the target side change. It is a bother, but I can deal > with it. For other institutions, this lockstep upgrade requirement > will not be obvious until they debug the resulting data corruption. >=20 > Still, I do understand why it would be nice to conform to the spec, > and it is maybe a bit cleaner that way too. Maybe you can help with > the bug reports on stgt-devel during the transition, and maintain > and publish a patch to let it work with old kernels. >=20 > -- Pete > _______________________________________________ > Stgt-devel mailing list > Stgt-devel@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/stgt-devel _________________________________________________________________ Find the job of your dreams before someone else does http://mycareer.com.au/?s_cid=3D596064 = --_802566f5-2ed0-4e71-ab21-9b7946f50dc7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

I= t appears the current Linux iSER initiator does not send the HELLO message = when the connection transits to full feature phase. The stgt target also ig= nores this message (if it were to appear). Both of these implementations us= e a non-conformant iSER header (they add write_va and read_va fields, which= incidentally do not appear to be used). Are these changes documented anywh= ere in the IB domain, or are these variations needed for another reason?
If these deviations from the RFC are not needed and were to be fixed (= along with the offset fix), then these implementations can detect the curre= nt mode of operation by examining the size of the iSER header received. The= choice to proceed in the broken way, or to terminate the connection (with = big loud error messages) is the implementor's choice. Either way, the issue= is detected and corruption avoided.

Thoughts?

Cheers
Ken<= br>



> Date: Tue, 29 Apr 2008 13= :05:16 -0400
> From: pw@osc.edu
> To: dorfman.eli@gmail.com
= > CC: stgt-devel@lists.berlios.de; rdreier@cisco.com; general@lists.open= fabrics.org; mako@almaden.ibm.com; ips@ietf.org; open-iscsi@googlegroups.co= m
> Subject: Re: [Stgt-devel] [ofa-general] Re: [Ips] Calculating the= VA in iSER header
>
> dorfman.eli@gmail.com wrote on Thu, 17 = Apr 2008 14:13 +0300:
> > On Wed, Apr 16, 2008 at 6:46 PM, Roland = Dreier <rdreier@cisco.com> wrote:
> > > > Agree with = the interpretation of the spec, and it's probably a bit
> > > = > clearer that way too. But we have working initiators and targets
= > > > > that do it the "wrong" way.
> > >
>= > > Yes... I guess the key question is whether there are any initia= tors that
> > > do things the "right" way.
> > >> > >
> > > > 1. Flag day: all initiators and t= argets change at the same time.
> > > > Will see data corr= uption if someone unluckily runs one or the other
> > > > = using old non-fixed code.
> > >
> > > Seems unacce= ptable to me... it doesn't make sense at all to break every
> > &g= t; setup in the world just to be "right" according to the spec.
> &g= t;
> > This will break only when both initiator and target will u= se
> > InitialR2T=3DNo, which means allow unsolicited data.
>= ; > As far as I know, STGT is not very common (and its version in RHEL5.= 1
> > is considered experimental). Its default is also InitialR2T= =3DYes.
> > Voltaire's iSCSI over iSER target also uses default In= itialR2T=3DYes.
> > So it seems that nothing will break.
> <= br>> I finally got a chance to look at this just now. I think you mean<= br>> default is InitialR2T=3DNo above, which means no unsolicited data.<= br>> That is the default case, and true, the two different meanings
&= gt; of the initiator-supplied VA coincide.
>
> But you missed = the impact of immediate data. We run with the
> defaults (I think) t= hat say the first write request packet should be
> filled with a bit = of the coming data stream. From iscsid.conf:
>
> # To ena= ble immediate data (i.e., the initiator sends unsolicited data
> = # with the iSCSI command packet), uncomment the following line:
> = #
> # The default is Yes
> node.session.iscsi.Immediat= eData =3D Yes
>
> Looking at the offset printed out by your pa= tch, it is indeed
> non-zero for the first RDMA read. Please correct= me if I am
> mistaken about this---you must have tested all four var= iations of
> with and without the patches on initiator and target sid= e, but I did
> not.
>
> Hence I am still a bit unhappy a= bout having to deal with the
> fallout, with no way to detect it. Fo= r our local use, I'll keep an
> older version of stgt in use until we= switch to a new kernel, then
> merge up the target side change. It = is a bother, but I can deal
> with it. For other institutions, this = lockstep upgrade requirement
> will not be obvious until they debug t= he resulting data corruption.
>
> Still, I do understand why i= t would be nice to conform to the spec,
> and it is maybe a bit clean= er that way too. Maybe you can help with
> the bug reports on stgt-d= evel during the transition, and maintain
> and publish a patch to let= it work with old kernels.
>
> -- Pete
> _____________= __________________________________
> Stgt-devel mailing list
> = Stgt-devel@lists.berlios.de
> https://lists.berlios.de/mailman/listin= fo/stgt-devel

before someone else does Find the job of your dreams= = --_802566f5-2ed0-4e71-ab21-9b7946f50dc7_-- --===============0193512607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0193512607==-- From ips-bounces@ietf.org Wed Apr 30 04:55:59 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918263A6C1E; Wed, 30 Apr 2008 04:55:59 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E473A68BA for ; Wed, 30 Apr 2008 04:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4XDUuM3dYRP for ; Wed, 30 Apr 2008 04:55:57 -0700 (PDT) Received: from exil.voltaire.com (fwil.voltaire.com [193.47.165.2]) by core3.amsl.com (Postfix) with ESMTP id 1C13B3A6CEF for ; Wed, 30 Apr 2008 04:55:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:54:14 +0300 Message-ID: <39C75744D164D948A170E9792AF8E7CAF60D50@exil.voltaire.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Stgt-devel] [ofa-general] Re: [Ips] Calculating the VA iniSER header Thread-Index: AciqlesMUQ5b5xCESYqcjGoLigvMTwAIv6FQ References: <4804B03C.6060507@voltaire.com><694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com><20080416144830.GC23861@osc.edu> <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> <20080429170516.GA8857@osc.edu> From: "Erez Zilber" To: "Ken Sandars" , "Pete Wyckoff" , "Eli Dorfman" Cc: stgt-devel , Roland Dreier , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [Stgt-devel] [ofa-general] Re: Calculating the VA iniSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Hi all, > > It appears the current Linux iSER initiator does not send the HELLO message when the connection transits to full feature phase. The stgt target also ignores this message (if it were to appear). Both of these implementations use a non-conformant iSER header (they add write_va and read_va fields, which incidentally do not appear to be used). Are these changes documented anywhere in the IB domain, or are these variations needed for another reason? > > If these deviations from the RFC are not needed and were to be fixed (along with the offset fix), then these implementations can detect the current mode of operation by examining the size > of the iSER header received. The choice to proceed in the broken way, or to terminate the connection (with big loud error messages) is the implementor's choice. Either way, the issue is detected and corruption avoided. > > Thoughts? Take a look at the iSER for IB annex: http://www.infinibandta.org/members/spec/Annex_iSER.PDF Erez _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 1 01:24:15 2008 Return-Path: X-Original-To: ips-archive@optimus.ietf.org Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853353A6A2A; Thu, 1 May 2008 01:24:15 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1FD3A698C for ; Thu, 1 May 2008 01:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXnkyN9tN8oZ for ; Thu, 1 May 2008 01:24:13 -0700 (PDT) Received: from blu139-omc1-s11.blu139.hotmail.com (blu139-omc1-s11.blu139.hotmail.com [65.55.175.151]) by core3.amsl.com (Postfix) with ESMTP id 1F4F13A67AE for ; Thu, 1 May 2008 01:24:13 -0700 (PDT) Received: from BLU117-W9 ([65.55.162.182]) by blu139-omc1-s11.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 May 2008 01:24:15 -0700 Message-ID: X-Originating-IP: [61.14.27.42] From: Ken Sandars To: Erez Zilber , Pete Wyckoff , Eli Dorfman Date: Thu, 1 May 2008 18:24:15 +1000 Importance: Normal In-Reply-To: <39C75744D164D948A170E9792AF8E7CAF60D50@exil.voltaire.com> References: <4804B03C.6060507@voltaire.com><694d48600804160122l1cc97b8aka8986ee6deb7dec8@mail.gmail.com><20080416144830.GC23861@osc.edu> <694d48600804170413g4d54cd9g447abd345a1f6301@mail.gmail.com> <20080429170516.GA8857@osc.edu> <39C75744D164D948A170E9792AF8E7CAF60D50@exil.voltaire.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2008 08:24:15.0400 (UTC) FILETIME=[BE122A80:01C8AB64] Cc: stgt-devel , Roland Dreier , ofa-general , Mike Ko , ips@ietf.org, open-iscsi@googlegroups.com Subject: Re: [Ips] [Stgt-devel] [ofa-general] Re: Calculating the VA iniSER header X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0126257936==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0126257936== Content-Type: multipart/alternative; boundary="_e6d9dbf2-b443-4ef2-ad4b-41c9ba806d84_" --_e6d9dbf2-b443-4ef2-ad4b-41c9ba806d84_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> [Ken] It appears the current Linux iSER initiator does not send the HELL= O message when >> the connection transits to full feature phase. The stgt target also igno= res this >> message (if it were to appear).=20 [Ken] The IBTA document does not mention the HELLO/HELLOREPLY messages. Implementing this message exchange gives a distinction between the current = implementations and those that will correctly calculate the write_va (as per Pete Wyckoff's= option 3). >> [Ken] Both of these implementations use a non-conformant iSER header (th= ey add >> write_va and read_va fields, which incidentally do not appear to be used= ). Are >> these changes documented anywhere in the IB domain, or are these variati= ons >> needed for another reason? > > [Erez] Take a look at the iSER for IB annex: > http://www.infinibandta.org/members/spec/Annex_iSER.PDF [Ken] Ouch. That link requires a username/password. Looks like it is only a= vailable to members of the Infiniband Trade Association. Fortunately I gained access to it with= username "open" and password "standard". ;-) [Ken] Neither of these implementations send or examine the iSER CM REQ/REP = message private data. The document doesn't define what action to take when this message is = absent. Interestingly, when the target reports that "ZBVA shall be used for this connection" and "= the target shall issue Send with Invalidate as needed" then it appears the iSER header specified i= n RFC5046 should be used for control-type PDUs. Is there any plan to conform with the list of r= equirements for IBTA compliance? =0A= Cheers, Ken _________________________________________________________________ Never miss another e-mail with Hotmail on your mobile. http://www.livelife.ninemsn.com.au/article.aspx?id=3D343869= --_e6d9dbf2-b443-4ef2-ad4b-41c9ba806d84_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>> [Ken] I= t appears the current Linux iSER initiator does not send the HELLO message = when
>> the connection transits to full feature phase. The stgt ta= rget also ignores this
>> message (if it were to appear).
[Ken= ] The IBTA document does not mention the HELLO/HELLOREPLY messages.
Impl= ementing this message exchange gives a distinction between the current impl= ementations
and those that will correctly calculate the write_va (as per= Pete Wyckoff's option 3).

>> [Ken] Both of these implementati= ons use a non-conformant iSER header (they add
>> write_va and rea= d_va fields, which incidentally do not appear to be used). Are
>> = these changes documented anywhere in the IB domain, or are these variations=
>> needed for another reason?
>
> [Erez] Take a= look at the iSER for IB annex:
> http://www.infinibandta.org/members= /spec/Annex_iSER.PDF

[Ken] Ouch. That link requires a username/passw= ord. Looks like it is only available to members
of the Infiniband Trade = Association. Fortunately I gained access to it with username "open" and
= password "standard". ;-)

[Ken] Neither of these implementations send= or examine the iSER CM REQ/REP message private
data. The document doesn= 't define what action to take when this message is absent. Interestingly,when the target reports that "ZBVA shall be used for this connection" and= "the target shall issue
Send with Invalidate as needed" then it appears= the iSER header specified in RFC5046 should be
used for control-type PD= Us. Is there any plan to conform with the list of requirements for IBTA
= compliance?
=0A=
Cheers,
Ken

Hotmail on your mobile. Neve= r miss another e-mail with = --_e6d9dbf2-b443-4ef2-ad4b-41c9ba806d84_-- --===============0126257936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============0126257936==--