Thanks Chuck for the response. Please see inline On Tue, Jan 28, 2020 at 7:52 AM Chuck Lever <chuck.le...@oracle.com> wrote:
> Hi Suhas - > > Thanks for your review and comments! My responses are below. > > > > On Jan 27, 2020, at 2:37 PM, Suhas Nandakumar via Datatracker < > nore...@ietf.org> wrote: > > > > Reviewer: Suhas Nandakumar > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-?? > > Reviewer: Suhas Nandakumar > > Review Date: 2020-01-27 > > IETF LC End Date: 2020-01-27 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: Thanks for the work. This document is clear in the problem to be > > solved . This document is ready to be published as it-is, however I do > have few > > clarification questions for my own understanding > > > > Major issues: > > > > Minor issues: > > > > Nits/editorial comments: > > 1. The draft doesn't specify normative procedures on sender/receiver > behavior > > when certain fields are missing (say size of all zeroes). Should the > draft say > > recommended procedures for handling these scenarios ? > > Section 4 defines the format, which is fixed in size. Section 4.1.1 in > particular mandates the behavior when a perfectly-formed RPC-over-RDMA > private message is not received. > > Zero is a permitted value for the size fields. Section 5.2 explains how > to compute the actual buffer size. If those fields contain zero, the > actual send and receive buffer sizes would be 1024 octets. > > [Suhas] I am not sure if i am reading it right here. Section 5.2 would result in the value of -1 if the min of the values is Zero (0/1024 - 1). Isn't it so ? > "Recommended procedures" are scattered about, but IMO the cases are > covered appropriately. If you see one that isn't, or one that could be > made more clear, please let me know. > > > > 2. Also i didn't see fallback procedures to be followed when the server > > reported size isn't of much use to the sender of the data . In such case > the > > sender might decide to go with existing explicit RDMA data transfer > operations > > instead of failing the connection ? > > If I understand your question, you mean when an RPC message to be > transmitted is larger than the buffer sizes reported in the private > data. Section 3.5 of RFC 8166 explains how the RPC-over-RDMA protocol > handles that situation. > > I see the confusion: Section 3.1 of the current document could be more > precise about the risks of exceeding the inline threshold size. The > second paragraph could instead read: > > "If an incoming RDMA message exceeds the size of a receiver's inline > threshold, the receive operation fails, and the RDMA provider typically > terminates the connection. To convey an RPC message larger than a > receiver's inline threshold without risking receive failure, the sender > must use explicit RDMA data transfer operations, which are more expensive > than RDMA Send." > [Suhas] This works great. Thanks for adding the clarification > > > -- > Chuck Lever > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
