Re: [nfsv4] [internet-drafts@ietf.org: New Version Notification for draft-hellwig-nfsv4-rdma-layout-00.txt]
Chuck Lever <chucklever@gmail.com> Mon, 17 July 2017 09:49 UTC
Return-Path: <chucklever@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF58812EBFE for <nfsv4@ietfa.amsl.com>; Mon, 17 Jul 2017 02:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqo60kshFd-G for <nfsv4@ietfa.amsl.com>; Mon, 17 Jul 2017 02:49:38 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC30312EB99 for <nfsv4@ietf.org>; Mon, 17 Jul 2017 02:49:37 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id 70so21063330wmo.1 for <nfsv4@ietf.org>; Mon, 17 Jul 2017 02:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/teYyZJHDV7U1Wl9+pXfFgFFOkCftK2OSKoIN9MfGzA=; b=j30uiX877Waxpn5xXsTz3oQaMhG5Pp5ZjNTRMAkJdBZxhxo8jO+ByDTCAZ5Y+Zsllh V50WOOHYo1oVnFm/Z9CsQ5gl7H1gSMhWUdHpcREBA0T9e4GjocD3qutYKniXvji0E5tE VpYsfgX98h+WnMNn4QKyEiErr8hckEO0PPS7xZHYtds0geYyi7mOJzIm05RrOOTCG/tj NjfiSchEG6tqbAXsLrlzGlw5Mo68/+Oo/iHnmmY5kZ1Rrz0YEKyncXNxC0Nm2+6fNj3L lg9jYEf8ARJxCfeXmHTHm2UPmkPuGctF3Rb9iSgsn8iVgMq6FO8QLCtXsPJ5fDj/TQ8N krUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/teYyZJHDV7U1Wl9+pXfFgFFOkCftK2OSKoIN9MfGzA=; b=DRLixHMSMR3cBTcfaF54qTnjE6z9Siini8SGrWN2jXJKM4h7KRqXh8+aXx0chfOsuC YHLyoqwmVciCTkG84GTxEZC08G5pBv6WqIj0VKEJTcPq/tTA7tZHJVmChOvplO0OHELI rtwyhLQ7HZRCcVfvSHCMYvAkTYM0sVYtFKxuxtDBllVn8ihHQGJECYSqDq3ecLjSC3r/ Qrzwo2NDNzBO+CobZM3Up6ZjfGr/hWKGNNHOGd1ypK7X5LFLmSMzUr26J9L/U5x96nj3 QMP114KgF+dAliosB87biY7MqnINq+F9jpPklQ/t57SjsFymH0TUmmiRm/pxtJXrvQfX QPJA==
X-Gm-Message-State: AIVw112DzYeNZAG7O8UnKWgMXb3+UYBED+J87L49oWe7CVRvhyJGJj8r jvnwKDOMC7KO+Q==
X-Received: by 10.28.19.201 with SMTP id 192mr3835486wmt.123.1500284976474; Mon, 17 Jul 2017 02:49:36 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:1d94:2866:9e0b:134e? ([2001:67c:370:128:1d94:2866:9e0b:134e]) by smtp.gmail.com with ESMTPSA id b195sm19470364wmf.0.2017.07.17.02.49.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Jul 2017 02:49:36 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chucklever@gmail.com>
In-Reply-To: <20170702231000.GA2564@lst.de>
Date: Mon, 17 Jul 2017 11:49:35 +0200
Cc: nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <26A3EDDF-200C-49F2-934B-CD9155AECE88@gmail.com>
References: <20170702231000.GA2564@lst.de>
To: Christoph Hellwig <hch@lst.de>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/MK5_YYf74RNXO4SQHIhhLwXgGNM>
Subject: Re: [nfsv4] [internet-drafts@ietf.org: New Version Notification for draft-hellwig-nfsv4-rdma-layout-00.txt]
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 09:49:40 -0000
> On Jul 3, 2017, at 01:10, Christoph Hellwig <hch@lst.de> wrote: > > As promised here is an initial cut at the RDMA layout before the > meeting in Prague. > > I have to admit it's not the highest quality draft, but I wanted to > get it out - it's probably unsuitable for readers without deep > knowledge of RDMA at this point. > > The idea of the layout is to provide RDMA READ / WRITE access to > remote memory regions - usually persistent memory in some form, > but to some extent it will also work with volatile caching of > data, e.g. in features like the NVMe controller memory buffer or > even host memory. It is done by registering these regions on > the server and performing the RDMA READ / WRITE operations from > the client, that is it inverts the model used by RDMA RPC or > other storage models. > > Besides improving the spec language there still is a lot left to > be done: > > - define the exact connection establishment model. I'd really > like to rely on RDMA/CM for that The connection model is critical, because the handles returned to clients can work only on one connection (QP). For example, you can't assume that NFS/RDMA will be used to access the MDS, nor can you assume that the MDS and DS's are accessed through the same HCA/RNIC on the same connection. To make it work, there will have to be some way of binding a layout (containing handles) to a particular connection to a particular storage device. Also, if the connection to a DS is lost, more than a reconnect is necessary. The client will need to take steps to get the server to re-register the memory and send fresh handles. > - figure out if we can get rid of the sub-layout extent inherited > from the block layout. This should be possible by providing two > handles in the layout > - find a way to future-proof for the introduction of a RDMA FLUSH > or COMMIT operation, where we don't have to do a LAYOUTCOMMIT > for every write > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Sun, 02 Jul 2017 16:04:45 -0700 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hellwig-nfsv4-rdma-layout-00.txt > To: Christoph Hellwig <hch@lst.de> > > > A new version of I-D, draft-hellwig-nfsv4-rdma-layout-00.txt > has been successfully submitted by Christoph Hellwig and posted to the > IETF repository. > > Name: draft-hellwig-nfsv4-rdma-layout > Revision: 00 > Title: Parallel NFS (pNFS) RDMA Layout > Document date: 2017-07-02 > Group: Individual Submission > Pages: 18 > URL: https://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-rdma-layout-00.txt > Status: https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-rdma-layout/ > Htmlized: https://tools.ietf.org/html/draft-hellwig-nfsv4-rdma-layout-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-hellwig-nfsv4-rdma-layout-00 > > > Abstract: > The Parallel Network File System (pNFS) allows a separation between > the metadata (onto a metadata server) and data (onto a storage > device) for a file. The RDMA Layout Type is defined in this document > as an extension to pNFS to allow the use of RDMA Verbs operations to > access remote storage, with a special focus on accessing byte > addressable persistent memory. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > ----- End forwarded message ----- > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 -- Chuck Lever chucklever@gmail.com
- [nfsv4] [internet-drafts@ietf.org: New Version No… Christoph Hellwig
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Chuck Lever
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… David Noveck
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Steve Byan's Lists
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Christoph Hellwig
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Christoph Hellwig
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Christoph Hellwig
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Tom Talpey
- Re: [nfsv4] [internet-drafts@ietf.org: New Versio… Steve Byan's Lists