On 03/29/2016 12:03 PM, Wouter Verhelst wrote: > On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote: >> On 03/29/2016 11:34 AM, Alex Bligh wrote: >>> I would agree. I think if it supports the structured reply semantics, >>> it should also support 'DF'. So if you know the server supports >>> structured replies, you know you can set DF on them without any >>> further requirements. >> >> Supporting DF merely transfers the burden of collection between server >> and client. I suspect that there are cases where the server does NOT >> want to support DF (because it would require the server to allocate >> memory to collect the data before sending a single structured read >> reply), > > There are other ways to handle that; e.g., the server could have a > "request too large for non-fragmented read" error message. The spec > should give a minimum size that the server MUST support (which should be > reasonably large), and should state that a server MAY reply to any > request with DF set for a block larger than that minimum, with that > error.
How does 64k sound? > > Otherwise the client could conceivably send out heaps of requests for > (UINT32_MAX - 8) bytes with DF set and basically DoS the server. Point taken. > >> just as you have stated that there are cases where the client >> has an additional burden if DF is not supported. So for v2, I'm going >> to explicitly document a DF export flag, and recommend (but not require) >> that the server support it. > > I'd prefer not to see that. Okay, good thing I haven't sent v2 yet; I'm making more edits to drop the export flag, and require unconditional support for the command flag once structured reads are negotiated. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
