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