On 04/25/2016 03:20 AM, Alex Bligh wrote: > I had a think about structured replies over the weekend. > > The current proposal is a big change for any existing server implementation (and, I suspect, client implementation). Yes, and that's partly why I still don't have a proof of concept coded up for qemu yet. > > One thing that struck me is that each chunk of the reply is sort of handled like a reply of its own. The simplest way for me to code them was probably to break up each request into internal sub-requests, have each of those fire off in parallel, send their own replies, and send a final segment once all had been sent. > > At this point, the following occurred to me. If I knew the client would respect my maximum blocksize, I could achieve about 90% of what structured replies do simply by setting a maximum blocksize. The client would break up each request into a suitable size chunks, and would send them all back independently. I'd not need to chunk anything. Yes, a smaller maximum block size can reduce the need for you to want to chunk your read reply. > > The main thing I'd be missing from structured replies would be the ability to put an error code at the END of a read (that currently prevents sendfile type implementations of read as you need to know whether the read fails anywhere before you start sending the beginning). > > Is the current structured-reply extension incredibly baroque for no gain? No, I still think we want the full flexibility of multiple chunks. Remember, the BIG gain is the ability to read holes without sending zeros over the wire. You cannot get that without multiple chunks, or else by constraining your maximum block size to be relatively small (aren't there file systems with holes at the granularity of 32k?). Requiring the client to only read 32k at a time in order to efficiently report holes seems like it will cause more traffic overhead. Other benefits from structured replies: error messages to accompany an error chunk, and the ability to implement the BLOCK_STATUS extension (proposals have been floated on list, but right now we still don't have an extension-* branch for it). > Could we do something much simpler if we assume that the 'chunking' is done by the BLOCKSIZE stuff? > I don't think so, because the ability to read holes is the main reason I added chunking of the read reply. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature