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
> >