Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-03 review

[Chuck Lever <[e-mail]>]

> On May 20, 2016, at 2:51 PM, Karen <[e-mail]> wrote:
> 
> 
> 
> On 5/20/16 12:44 PM, Chuck Lever wrote:
>>> On May 20, 2016, at 2:30 PM, Karen <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> On 5/20/16 10:41 AM, Chuck Lever wrote:
>>>>> 
>>>>> 4.1
>>>>> 
>>>>> "When message direction is not fully determined by context"
>>>>> 
>>>>> "fully determined by context" thats confusing, what does that really mean? I think this means when the rdma header does not directly indicate if the message is a call or reply, but the wording is confusing.
>>>> That means that in some cases the receiver can guess
>>>> accurately which direction the message was going, based
>>>> on the context of the operation, even without having
>>>> an RPC message payload.
>>>> 
>>>> I'm open to suggestions.
>>>> 
>>>> I think some prefer that the document simply state that
>>>> direction is always unknown in cases where an RPC
>>>> message payload is not present. That kind of opens a
>>>> can of worms with RDMA_ERROR, which is needed to report
>>>> that the client does not support backward direction
>>>> operation.
>>> I don't think that it can always absolutely be clear which direction without the RPC header. Or am I misunderstanding RPC payload? I'm taking that to mean the RPC header, but maybe you are referring to the NFS data in the rpc payload?
>> "Context" here means that if the receiver can tell
>> by other means (like, there are no other outstanding
>> operations). So no, it's not always going to be clear.
>> In those cases, direction is not known.
> I don't think there is ever a 100% way to know the direction without the rpc header's call or reply field.

I don't think what I wrote contradicts that statement, but
it does allow latitude for innovation to close this hole
in other ways.


> Even if there is an outstanding request, and it is for the xid that is defined in the rdma header, being that the xid is not unique between client and server, there still exists, though extremely small, a possiblity that this is a new request that just so happens to have the same xid and is not actually the reply to an outstanding operation.

The only case in RPC-over-RDMA Version One where this is
a concern is RDMA_ERROR. The other two valid procs are
RDMA_NOMSG and RDMA_MSG, and both of those have RPC
message payloads.

When a client receives an RDMA_ERROR, that normally means
one of its forward requests had a problem.

Typical RPC-over-RDMA Version One client implementations
don't send an error to a server due to a problem with a
forward reply. We can probably say the same about a
server sending an RDMA_ERROR to a client in response
to a bad backward reply. (And, rfc5666bis could be
enhanced to suggest or require that requesters don't
send RDMA_ERROR in response to a bogus reply).

So the only instance where a server might receive an
RDMA_ERROR message is when it has sent a backward
request that the client did not like.

Thus: context indicates what direction that RDMA_ERROR
message is going.


--
Chuck Lever