Re: [nfsv4] AD Evaluation for draft-ietf-nfsv4-rpcrdma-bidirection-05

Hi, Spencer (S),

On Jan 12, 2017 12:32, "spencer shepler" <spencer.shepler@gmail.com> wrote:

Yes, Spencer D.  I believe we are ready with the updates that Chuck has
in-hand.  Thanks for the review.

Spencer S

Excellent. I'll request Last Call when Chuck submits his update.

Spencer

On Tue, Jan 10, 2017 at 7:26 PM, Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Chuck,
>
> On Tue, Jan 10, 2017 at 5:02 PM, Chuck Lever <chuck.lever@oracle.com>
> wrote:
>
>>
>> > On Jan 10, 2017, at 5:13 PM, Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>> >
>> > Hi, Chuck,
>> >
>> > On Tue, Jan 10, 2017 at 3:47 PM, Chuck Lever <chuck.lever@oracle.com>
>> wrote:
>> > Again, thanks for your review! Responses below.
>> >
>> > Oh, thank YOU. You responded while I still have this draft in my solid
>> state memory :-) ...
>> >
>> > It looks like we're good except for the last point.
>> >
>> > > On Jan 10, 2017, at 4:32 PM, Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>> [ snipped ]
>>
>> > > In this text,
>> > >
>> > >    When message direction is not fully determined by context (e.g.,
>> > >    suggested by the definition of the RPC-over-RDMA version that is in
>> > >    use) or by an accompanying RPC message payload with a call
>> direction
>> > >    field, it is not possible for the receiver to tell with certainty
>> > >    whether the header credit value is a request or grant.  In such
>> > >    cases, the receiver MUST NOT use the header's credit value.
>> > >
>> > > does RDMA work at all, if the credit value can't be used?
>> >
>> > What this means is the receiver MUST NOT update its credit accounting
>> > based on the information in this header. These foggy situations should
>> > be exceptionally rare.
>> >
>> > "MUST ignore" might be more appropriate.
>> >
>> > I think what I was thinking about, is whether this situation can lead
>> to deadlock.
>>
>> The credit grant value has to be ignored whenever the forward and backward
>> grants are not the same value (which is typical in current
>> implementations).
>>
>> With the current set of protocols, the only case like this is RDMA_ERROR,
>> which is almost never used. Ignoring the credit value for those messages
>> doesn't seem problematic.
>>
>> If the backward credit grant (which is likely to be smaller) is suddenly
>> used in the forward direction, for that one message, the forward requester
>> would wait for any outstanding replies before sending more requests. The
>> next message from the responder would restore the forward credit grant to
>> its correct value.
>>
>> I don't think a deadlock could occur unless the grant value went to zero,
>> and that is already forbidden by rfc5666bis.
>
>
> I had forgotten that detail. Thanks for the wake-up call!
>
>
>> Another way to address this I suppose would be to ensure the grant values
>> in both directions are always the same.
>>
>>
>> > I guess I should back up and ask a more basic question, which is
>> whether you'd be able to recognize that this situation applies from looking
>> at the definition of the RPC-over-RDMA version, so you could just say "I'm
>> not going to do bidirectional" when a transport connection is established,
>> rather than trying to figure out that there's a problem during request
>> processing.
>>
>> An implementer would be able to tell where these corner cases are, since
>> her implementation has to ignore the credit value in those cases. But
>> maybe I'm missing something.
>>
>
> I'm thinking the guy who's missing something is me ;-)
>
> I think we're good to go on this document.
>
> Spencer (S), would you agree?
>
> Spencer (D)
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>