Thanks Chuck for the additional clarification. That helped me to understand better. Sorry that I missed it in my reading.
Yes the suggested changes look great. Cheers Suhas On Wed, Jan 29, 2020 at 7:23 AM Chuck Lever <[email protected]> wrote: > > > On Jan 29, 2020, at 12:03 AM, Suhas Nandakumar <[email protected]> > wrote: > > > > Thanks Chuck for the response. Please see inline > > > >> On Tue, Jan 28, 2020 at 7:52 AM Chuck Lever <[email protected]> > wrote: > >> > >> 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 ? > > Section 5.2 says: > > Inline threshold sizes from 1KB to 256KB can be represented in the > Send Size and Receive Size fields. A sender computes the encoded > value by dividing the actual value by 1024 and subtracting one from > the result. A receiver decodes this value by performing a > complementary set of operations. > > Here, "actual value" means the real size of the buffer. A 1024-octet > buffer would result in (1024 / 1024) - 1 = 0. > > The computation done by the receiver is the inverse: > > (0 + 1) * 1024 = 1024 > > I could replace "actual value" by "buffer size, in octets". Would it > help if the text also spelled out the inverse computation? > > > -- > Chuck Lever > > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
