Return-Path: 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 82D7E3A10B7 for ; Mon, 4 May 2020 17:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 Xtzj6s6k_d1C for ; Mon, 4 May 2020 17:59:43 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 940013A10B1 for ; Mon, 4 May 2020 17:59:43 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id b20so185781ejg.11 for ; Mon, 04 May 2020 17:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a13MUtFtTUcj3MelMMI6T16fR4JLUqkYB/MxZRF48xk=; b=YkcpwMoVeJkGwaJH7mbWHpTZY7viBOrrfvF1W3+dbPjd9onSdKpnFdWug8J11UkPoR p9aaPUCJXMx2xouEXqt0NAQeHRh8/Dq7W1mgU+Y6cC1mc9cQu4bn/HdhBbwKjvNhIP2q K5+zuV2RWGqm1ZXn0xE42KUfYmV5xYS+PfqTB13dZs7kmS7e65Fn99dvD+5EWieBVtu8 A1lbZfl2horiic+NeiEoa9m/yhItcBlkueK1rKu3Rb+XJotV7R8etv27IzbwMUVWId2d Y7A2l1HDeo5AYmjg2h0+SPZnZkF46Ecs1DvNMll52BqOfaOo/3hiYyQGLMZHcZiAeGc3 IVjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a13MUtFtTUcj3MelMMI6T16fR4JLUqkYB/MxZRF48xk=; b=YpHyKX+GV5J/D5BYjPFC1krrRJxn5Q5M0qGuCEXJJTg5jawRxq0ZJfIB3FpQXSbWzf d9JckwQl4S5JhoUVpcovi9BQdAiYyhT/USjur6tn0E9XME3p8fhEbisMJYP5t8IzL8fh Wh+4ORRYdVyffu9KZBx4CQDRl48qpgCnIewDqrXnppAPpxuqxI5PEEqrh1TEIQIAisSQ /kv1YAH5J/ZFL7ex0R4DSikYx1gvlKPulOqtyC2kdT30T/lxSsPPr84bAeF6rRP7o7NF w46LwKkaqyeHWrifR3JSaY38gNzl+YicQiL45/91jYYSfy1jGxSzpBz+xd2nrVx1PfHr 0DGA== X-Gm-Message-State: AGi0PuYTik/JAztrXpjsVXWgybq0Fh+QBlgJU8OkjnwfzgB9YZRaap/h 3R14i8yXfz9E+fnr7G6Nim0Fpc6l67Jr0GjZfxE= X-Google-Smtp-Source: APiQypIaNEHX/C/iEefh2NL+/nt6CPZGuX0oKwLXOmmG6AtF6EbttIJ7/sH7X1DW3EGjoODwu5swlVIpuBYhqs39+7w= X-Received: by 2002:a17:907:4060:: with SMTP id ns24mr470766ejb.3.1588640382082; Mon, 04 May 2020 17:59:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Noveck Date: Mon, 4 May 2020 20:59:29 -0400 Message-ID: To: Chuck Lever Cc: NFSv4 Content-Type: multipart/alternative; boundary="000000000000a65ff805a4dc2996" Archived-At: Subject: Re: [nfsv4] Clean up for rpcrdma-version-two Read chunks X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 00:59:46 -0000 --000000000000a65ff805a4dc2996 Content-Type: text/plain; charset="UTF-8" On Mon, May 4, 2020, 12:13 PM Chuck Lever wrote: > Two weeks ago, I presented on the status of > draft-ietf-nfsv4-rpcrdma-version-two. > The slides are here: > > > https://datatracker.ietf.org/meeting/interim-2020-nfsv4-01/materials/slides-interim-2020-nfsv4-01-sessa-ietf-107-rpc-rdma-v2.pdf > > On slide 18, I described three situations involving Read chunks that do > not appear > to be adequately covered by RFC 8166 ("Remote Direct Memory Access > Transport for > Remote Procedure Call Version 1"). I'd like to propose modifications to the > rpcrdma-version-two draft to address these cases: > > > > RPC/RDMA v1 allows a position zero Read chunk to appear in an RDMA_MSG > type Call. > > Where does a Responder put the inline portion of such a message? > > I propose that in RPC/RDMA version 2, a Responder MUST return > RDMA2_ERR_BAD_XDR if > a Requester sends a Read list containing a position zero Read chunk as > part of > header type other than RDMA2_NOMSG. > Agree. > > > RPC/RDMA v1 does not explicitly require an RDMA_NOMSG type Call to have > a position > > zero Read chunk. Does such a message have gaps? Are they zero-filled? > > > I propose that in RPC/RDMA version 2, a Responder MUST return > RDMA2_ERR_BAD_XDR if > a Requester sends an RDMA2_NOMSG header type whose Read list does not > include a > position zero Read chunk. > As stated, this would forbid NOMSG bring used to send a long reply. I think the text to address this needs to be careful not to foreclose that. Your text above uses the word "requester" assuming this is sufficient but the only way a peer receiving message could determine whether it was sent by a requester or responder is my looking at the message, which,in this case, does not exist. > > > > RPC/RDMA v1 does not prevent or prohibit overlapping Read chunks. Is the > correct > > response ERR_CHUNK? > > A protocol change would be needed to totally prevent the expression of > overlapping > Read chunks. Maybe it's a little too late to address that in RPC/RDMA > version 2. > I think you mean version 1. Nobody seems up to do rfc8166bis. > > I propose that in RPC/RDMA version 2, a Responder MUST return > RDMA2_ERR_BAD_XDR if > a Requester sends a Read list with chunks whose offsets and lengths result > in the > same message byte position appearing in more than one Read chunk. > This would require sorting by the receiver. It might be better to place responsibility on the sender to sort these. > Comments/concerns? > > -- > Chuck Lever > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 > --000000000000a65ff805a4dc2996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 4, 2020, 12:13 PM Chuck Lever <chuck.lever@oracle.com> wrote:
Two weeks ago, I presented on the sta= tus of draft-ietf-nfsv4-rpcrdma-version-two.
The slides are here:

https://datatracker.ietf.org/meeting= /interim-2020-nfsv4-01/materials/slides-interim-2020-nfsv4-01-sessa-ietf-10= 7-rpc-rdma-v2.pdf

On slide 18, I described three situations involving Read chunks that do not= appear
to be adequately covered by RFC 8166 ("Remote Direct Memory Access Tra= nsport for
Remote Procedure Call Version 1"). I'd like to propose modificatio= ns to the
rpcrdma-version-two draft to address these cases:


> RPC/RDMA v1 allows a position zero Read chunk to appear in an RDMA_MSG= type Call.
> Where does a Responder put the inline portion of such a message?

I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD= _XDR if
a Requester sends a Read list containing a position zero Read chunk as part= of
header type other than RDMA2_NOMSG.

Agree.

=


> RPC/RDMA v1 does not explicitly require an RDMA_NOMSG type Call to hav= e a position
> zero Read chunk. Does such a message have gaps? Are they zero-filled?<= br>

I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD= _XDR if
a Requester sends an RDMA2_NOMSG header type whose Read list does not inclu= de a
position zero Read chunk.
As stated, this would forbid NOMSG bring used to s= end a long reply.=C2=A0 I think the text to address this needs to be carefu= l not to foreclose that. Your text above uses the word "requester"= ; assuming this is sufficient but the only way a peer receiving message cou= ld determine whether it was sent by a requester or responder is my looking = at the message, which,in this case, does not exist.
=


> RPC/RDMA v1 does not prevent or prohibit overlapping Read chunks. Is t= he correct
> response ERR_CHUNK?

A protocol change would be needed to totally prevent the expression of over= lapping
Read chunks. Maybe it's a little too late to address that in RPC/RDMA v= ersion 2.

I think you mean version 1.=C2=A0 Nobody seems up to do rfc8166bi= s.

I propose that in RPC/RDMA version 2, a Responder MUST return RDMA2_ERR_BAD= _XDR if
a Requester sends a Read list with chunks whose offsets and lengths result = in the
same message byte position appearing in more than one Read chunk.

This would= require sorting by the receiver. It might be better to place responsibilit= y on the sender to sort these.


Comments/concerns?

--
Chuck Lever



_______________________________________________
nfsv4 mailing list
nfsv= 4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
--000000000000a65ff805a4dc2996--