Re: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt

<david.black@emc.com> Tue, 13 September 2011 14:47 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA51121F86F6 for <storm@ietfa.amsl.com>; Tue, 13 Sep 2011 07:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.547
X-Spam-Level:
X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrubjAiormoF for <storm@ietfa.amsl.com>; Tue, 13 Sep 2011 07:47:44 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9480121F8804 for <storm@ietf.org>; Tue, 13 Sep 2011 07:47:44 -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.4.3/Switch-3.4.3) with ESMTP id p8DEnokC002656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Sep 2011 10:49:50 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 13 Sep 2011 10:49:39 -0400
Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p8DEncL0027606; Tue, 13 Sep 2011 10:49:38 -0400
Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 13 Sep 2011 10:49:38 -0400
From: <david.black@emc.com>
To: <ttalpey@microsoft.com>, <storm@ietf.org>
Date: Tue, 13 Sep 2011 10:49:33 -0400
Thread-Topic: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt
Thread-Index: AQHMQAd5rqByIG3LqkyzMQBSkqr9oZVK5DSAgAC35eCAACw6cA==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058CCE4510@MX14A.corp.emc.com>
References: <20110711201645.11642.41672.idtracker@ietfa.amsl.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058C03F818@MX14A.corp.emc.com> <F83812DF4B59B9499C1BC978336D91745EF1A4D3@TK5EX14MBXC113.redmond.corp.microsoft.com>
In-Reply-To: <F83812DF4B59B9499C1BC978336D91745EF1A4D3@TK5EX14MBXC113.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 13 Sep 2011 14:47:49 -0000

Restating my concern:

If an alignment violation causes an error in this protocol, then this protocol must specify how to avoid causing an alignment violation.

Thanks,
--David

> -----Original Message-----
> From: Tom Talpey [mailto:ttalpey@microsoft.com]
> Sent: Tuesday, September 13, 2011 8:22 AM
> To: Black, David; storm@ietf.org
> Subject: RE: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt
> 
> Actually, this question goes deeper - alignment requirements such as this are actually on the
> *application*. Are we requiring that they align their atomics? Is 64-bits always enough to ensure
> correctness? Also remember the peer performs no processing, it simply issues an operation to an
> application-provided value (the atomic's RDMA triplet).
> 
> Normally such a requirement would be specified in the Verbs. Since local behavior is not in scope
> here, perhaps the document should make no requirement at all, and simply give some advice. The
> mechanism to avoid it is necessarily at the upper layer.
> 
> Tom.
> 
> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com
> Sent: Monday, September 12, 2011 2:12 PM
> To: storm@ietf.org
> Subject: Re: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt
> 
> In looking at the changes in this draft from the -00 version, I noticed something that needs
> attention, although it was already present in the -00 version:
> 
> The term "naturally aligned" needs to be defined for buffer addresses, because failure to use a
> "naturally aligned" buffer address causes a "Catastrophic Error" at the recipient.  For this reason,
> there needs to be a tight specification of what the sender needs to do to avoid that error.
> Specifying a boundary that is always "naturally aligned" (e.g., 64-bit) should suffice (and is
> probably superior to providing a way to figure this out on-the-wire).
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
> > Of internet-drafts@ietf.org
> > Sent: Monday, July 11, 2011 4:17 PM
> > To: i-d-announce@ietf.org
> > Cc: storm@ietf.org
> > Subject: [storm] I-D Action: draft-ietf-storm-rdmap-ext-01.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the STORage Maintenance Working Group of the IETF.
> >
> > 	Title           : RDMA Protocol Extensions
> > 	Author(s)       : Hemal Shah
> >                           Felix Marti
> >                           Wael Noureddine
> >                           Asgeir Eiriksson
> >                           Robert Sharp
> > 	Filename        : draft-ietf-storm-rdmap-ext-01.txt
> > 	Pages           : 30
> > 	Date            : 2011-07-11
> >
> >    This document specifies extensions to the IETF Remote Direct Memory
> >    Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write
> >    services directly to applications and enables data to be transferred
> >    directly into Upper Layer Protocol (ULP) Buffers without
> >    intermediate data copies. The extensions specified in this document
> >    provide the following capabilities and/or improvements: Atomic
> >    Operations and Immediate Data.
> >
> >
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-storm-rdmap-ext-01.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-rdmap-ext-01.txt
> > _______________________________________________
> > storm mailing list
> > storm@ietf.org
> > https://www.ietf.org/mailman/listinfo/storm
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
>