Re: [storm] Updated iSER draft
"Mallikarjun Chadalapaka" <cbm@chadalapaka.com> Sat, 05 December 2009 01:29 UTC
Return-Path: <cbm@chadalapaka.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3793A6859 for <storm@core3.amsl.com>; Fri, 4 Dec 2009 17:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.754, 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 ee50sfD+5H2m for <storm@core3.amsl.com>; Fri, 4 Dec 2009 17:29:31 -0800 (PST)
Received: from snt0-omc1-s8.snt0.hotmail.com (snt0-omc1-s8.snt0.hotmail.com [65.55.90.19]) by core3.amsl.com (Postfix) with ESMTP id 2DE343A6801 for <storm@ietf.org>; Fri, 4 Dec 2009 17:29:31 -0800 (PST)
Received: from SNT131-DS11 ([65.55.90.9]) by snt0-omc1-s8.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 17:29:22 -0800
X-Originating-IP: [15.203.233.75]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds112CA15E86F8BAD18A71DFA0920@phx.gbl>
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: 'Mike Ko' <Michael@huaweisymantec.com>, storm@ietf.org
References: <4B0C76CF.8070905@ieee.org> <C2D311A6F086424F99E385949ECFEBCBCA8E5D@CORPUSMX80B.corp.emc.com> <E15870DC-3DFF-4B8F-82C2-18A5248E132D@gmail.com> <SNT131-ds11E5485BA6BABFE246D4EDA0960@phx.gbl> <AC32D7C72530234288643DD5F1435D53077CB9C0@RTPMVEXC1-PRD.hq.netapp.com> <176FE63F6E624A398CCA995FBE562AFF@china.huawei.com> <SNT131-ds11848CC4B9CF73A115672CA0920@phx.gbl> <ADB46DCF991C4C7487AE81422381E0AF@china.huawei.com>
In-Reply-To: <ADB46DCF991C4C7487AE81422381E0AF@china.huawei.com>
Date: Fri, 04 Dec 2009 17:29:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acp1Q7yL1zB6/duCSVWrSzZb4GbqAAABXqLQ
Content-Language: en-us
X-OriginalArrivalTime: 05 Dec 2009 01:29:22.0633 (UTC) FILETIME=[5FA79B90:01CA754A]
Subject: Re: [storm] Updated iSER draft
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2009 01:29:32 -0000
Hi Mike, > The question is whether our intention to update the iSER spec is to reflect > "running code". It should be, I was only trying to make sure other "running code" implementations of iSER aren't impacted due to this change, particularly when this change is not typical SCSI. I am going to have to defer to those working hands-on on "running code". Thanks. Mallikarjun > -----Original Message----- > From: Mike Ko [mailto:Michael@huaweisymantec.com] > Sent: Friday, December 04, 2009 4:42 PM > To: Mallikarjun Chadalapaka; storm@ietf.org > Subject: Re: [storm] Updated iSER draft > > Mallikarjun, > > The question is whether our intention to update the iSER spec is to reflect > "running code". This hinges on whether there are any other commonly adopted > software support for iSER other than the OFED stack. Felix Marti responded > in November that the Chelsio iWARP products support ZBVA, but no detail was > given on how this is done. Do you know of any "running code" in widespread > use that supports ZBVA? > > Unless there are some recent changes, AFAIK, there is no intention of > embracing ZBVA in IB. ZBVA is "tolerated" because it is in the iSER spec. > > Mike > ----- Original Message ----- > From: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com> > To: "'Mike Ko'" <Michael@huaweisymantec.com>; <storm@ietf.org> > Sent: Friday, December 04, 2009 4:19 PM > Subject: RE: [storm] Updated iSER draft > > > > Hi Mike, > > > > I hope you had a chance to see my note on this topic a few weeks ago. > > > >> 5. Added two 64-bit fields in iSER header in section 9.2 for the Read > >> Virtual Address and the Write Virtual Address to conform to the > >> Infiniband > >> format as proposed by Bob Russell. This allows one implementation such > >> as > >> the OFED stack to be used in both the Infiniband and the iWARP > > environment. > > > > Are you proposing this protocol change to support just the OFED stack? > > > > ZB-VA is supported with iWARP as a base feature, and I thought IB was > > going > > to embrace it as an extension as of three years ago. If that is the case, > > IMO, we should reconsider making iSER protocol changes to support non-ZBVA > > for benefiting one implementation - particularly when the change is > > neither > > efficient nor free. > > > > Thanks. > > > > Mallikarjun > > > > > > > > > >> -----Original Message----- > >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of > > Mike > >> Ko > >> Sent: Friday, December 04, 2009 3:41 PM > >> To: storm@ietf.org > >> Subject: [storm] Updated iSER draft > >> > >> I have just submitted an updated iSER draft to the storm WG. The > > following > >> are extracted from section 14 on "Summary of Changes from RFC 5046": > >> > >> 1. Removed the requirement that a connection be opened in "normal" > >> TCP > >> mode and transitioned to zero-copy mode. The allows the spec to conform > > to > >> existing implementation for both Infiniband and iWARP. Changes were made > > in > >> sections 2, 3.1.6, 4.2, 5.1, 5.1.1, 5.1.2, 5.1.3, 10.1.3.4, and 11. > >> > >> 2. Added a clause in section 6.2 to clarify that the initiator must not > > send > >> more than InitiatorMaxRecvDataSegmentLength worth of data when a NOP-Out > >> request is sent with a valid Initiator Task Tag. Since > >> InitiatorMaxRecvDataSegmentLength can be smaller than > >> TargetMaxRecvDataSegmentLength, returning the original data in the > >> NOP-Out > >> request in this situation can overflow the receive buffer unless the > > length > >> of the data sent with the NOP-Out request is less than > >> InitiatorMaxRecvDataSegmentLength. > >> > >> 3. Added MaxAHSLength key in section 6.8 to set a limit on the AHS Length > > as > >> proposed by Alex Nezhinsky. This is useful when posting receive buffers > > in > >> knowing what the maximum possible message length is in a PDU which > > contains > >> AHS. > >> > >> 4. Added WriteAddressForSolicitedDataOnly key in section 6.9 to indicate > > how > >> the memory region will be used as proposed by Alex Nezhinsky. Alex > >> argued > >> that WSTAG (RKEY+VA for Infiniband) sent by the initiator with a WRITE > > SCSI > >> command already accounts for the offset associated with the solicited > > data, > >> and does not reference the entire data. The rationale is that the > > initiator > >> sometimes treats the memory regions intended for unsolicited and > >> solicited > >> data differently, as they are carried out using different Infiniband > >> mechanisms (Send from the initiator, RDMA from the target) that imply > >> different registration modes. In contrast, the model implied by the iSER > >> spec creators was that the memory occupied by data is treated as > > contiguous > >> (or virtually contiguous, by means of scatter-gather mechanisms) and > >> homogenous region. Adding a new key will allow coping with current > >> implementations. > >> > >> 5. Added two 64-bit fields in iSER header in section 9.2 for the Read > >> Virtual Address and the Write Virtual Address to conform to the > >> Infiniband > >> format as proposed by Bob Russell. This allows one implementation such > >> as > >> the OFED stack to be used in both the Infiniband and the iWARP > > environment. > >> > >> Proposed Changes To Be Considered > >> > >> 6. Alex Nezhinsky stated that iSER Hello and iSER HelloReply messages are > >> not implemented in practice. He argued that we should update the spec to > >> remove the requirement to exchange the iSER Hello and iSER HelloReply > >> messages. > >> > >> Changes To Be Done > >> > >> Update all diagrams to conform with the expanded iSER header format. > >> > >> Mike > >> > >> _______________________________________________ > >> storm mailing list > >> storm@ietf.org > >> https://www.ietf.org/mailman/listinfo/storm > >
- [storm] What if a SCSI Response PDU has GOOD stat… Ralph Weber
- Re: [storm] What if a SCSI Response PDU has GOOD … Black_David
- Re: [storm] What if a SCSI Response PDU has GOOD … Julian Satran
- Re: [storm] What if a SCSI Response PDU has GOOD … Suzanne Morgan
- Re: [storm] What if a SCSI Response PDU has GOOD … Black_David
- Re: [storm] What if a SCSI Response PDU has GOOD … Mallikarjun Chadalapaka
- Re: [storm] What if a SCSI Response PDU has GOOD … Knight, Frederick
- [storm] Updated iSER draft Mike Ko
- Re: [storm] Updated iSER draft Mallikarjun Chadalapaka
- Re: [storm] Updated iSER draft Mike Ko
- Re: [storm] Updated iSER draft Felix Marti
- Re: [storm] Updated iSER draft Mallikarjun Chadalapaka