IETF Logo Mail Archive

Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt

Chuck Lever <chuck.lever@oracle.com> Mon, 29 August 2016 01:14 UTC

Return-Path: <chuck.lever@oracle.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 9FF2A12D0B1 for <nfsv4@ietfa.amsl.com>; Sun, 28 Aug 2016 18:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 ybm4aUmblyy2 for <nfsv4@ietfa.amsl.com>; Sun, 28 Aug 2016 18:14:01 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AA212D0AD for <nfsv4@ietf.org>; Sun, 28 Aug 2016 18:14:01 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7T1E0hs021273 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 29 Aug 2016 01:14:00 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u7T1Dxp7017998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 01:13:59 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7T1DwOW017897; Mon, 29 Aug 2016 01:13:59 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Aug 2016 18:13:58 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jetr6dfdtqAtxoNvd+bSJRR92+=qULzEqrX=+PitDadwQ@mail.gmail.com>
Date: Sun, 28 Aug 2016 21:13:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBF00640-0F7D-44F6-BF32-0D085CFC727E@oracle.com>
References: <147155138353.27840.7944779905916585881.idtracker@ietfa.amsl.com> <CADaq8jeb6P_1mG9++T=Ff31WBeJi-bD7NqUBQM4GOscxquiDxQ@mail.gmail.com> <2E2207C2-EC6D-4C44-9024-56D103563617@oracle.com> <CADaq8jd6PT7y=x1a5Tynxdzed2DivEuCG_6UK1eA=Vxod3PJxQ@mail.gmail.com> <54FAE2DB-2583-4512-89D7-2EC9E7AEA86F@oracle.com> <CADaq8jcWTuCC4yb3_fFpYYWcW3he2HHvjz7zaPON2_Yc5qXN-A@mail.gmail.com> <4FDB0016-8E32-4E61-B139-F46C5AFCED7C@oracle.com> <CADaq8jcirk3GFzY6m8q-sggPDXp_iSyufmGRvZpfzx8mR26M8Q@mail.gmail.com> <57C0D77D.8080601@oracle.com> <CADaq8jetr6dfdtqAtxoNvd+bSJRR92+=qULzEqrX=+PitDadwQ@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/WKoZKQJpJu3UmdR3uzsdmcy-FfU>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Aug 2016 01:14:03 -0000

> On Aug 28, 2016, at 7:10 PM, David Noveck <davenoveck@gmail.com> wrote:
> 
> 
> > Also, what guarentees that the xid of the updxch is unique 
> > among the xid's the peer is using?
> 
> There aren't any and I don't believe any are needed.  There is some text that says xid for updxch is not tied to that for the reqxch, but I think it need to be more clearly stated that there is no use for this.  I could either tell the receiver to ignore this or tell the sender to always make this zero.

Thinking aloud:

Generally speaking, I'm wondering about the rdma_xid field in any RPC-over-RDMA message
that does not carry an RPC message payload (and that would include any extension of
RPC-over-RDMA Version Two).

Seems to me that if there is no RPC message payload, that XID field could (even should?)
be used independently of the XID space used by the RPC client (the "upper layer").

In other words, a disjoint XID space could be used for non-RPC-message bearing messages
such as XCH operations. That field could be used for some other purpose entirely when
there's no need to provide call-reply transactional semantics.

We have the same problem if we were to, say, send more than one RPC message in a single
RPC-over-RDMA message.


--
Chuck Lever

v2.23.0 | Report a Bug | By Email