qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: David Edmondson <dme@dme.org>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <fam@euphon.net>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server
Date: Tue, 25 Aug 2020 12:03:27 +0200	[thread overview]
Message-ID: <2154afa0-9d37-ee31-a446-4d3ec6df45a3@redhat.com> (raw)
In-Reply-To: <m2ft8ivhuu.fsf@dme.org>


[-- Attachment #1.1: Type: text/plain, Size: 1798 bytes --]

On 19.08.20 16:19, David Edmondson wrote:
> On Wednesday, 2020-08-19 at 15:11:37 +01, Stefan Hajnoczi wrote:
> 
>> On Tue, Aug 18, 2020 at 12:08:36PM +0100, David Edmondson wrote:
>>> When using qemu-img to convert an image that is hosted on an HTTP
>>> server to some faster local (or pseudo-local) storage, the overall
>>> performance can be improved by reading data from the HTTP server in
>>> larger blocks and by caching and re-using blocks already read. This
>>> set of patches implements both of these, and adds a further patch
>>> allowing an offset to be added to all of the HTTP requests.
>>
>> Hi David,
>> Thanks for posting this! Kevin and Max are the maintainers in this area,
>> but I wanted to ask an initial question:
>>
>> Is caching curl-specific or could this be implemented as a block filter
>> driver so that it can be stacked on top of other network protocols too?
> 
> This implementation is curl specific, as you probably surmised. I will
> look at implementing something similar as a block filter.

I think from an implementation standpoint the best would be if we could
just use such a generic caching block filter above all curl nodes so we
can drop all caching from curl.

However, I suppose then we’d at least have the problem of how to put
this cache node on top of all curl nodes without breaking compatibility,
which may be impossible.

OTOH, maybe it would be fine to leave the new cache optional, and just
leave the curl driver itself as it is.  Which would also mean that
wouldn’t need readahead support in the cache driver.

But if we do need this full cache directly in the curl driver, is it at
least possible to share most of the caching code between it and a
(potential future) dedicated cache block driver?

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2020-08-25 10:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 11:08 [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server David Edmondson
2020-08-18 11:08 ` [RFC PATCH 1/9] block/curl: Add an 'offset' parameter, affecting all range requests David Edmondson
2020-08-18 11:08 ` [RFC PATCH 2/9] block/curl: Remove readahead support David Edmondson
2020-08-18 11:08 ` [RFC PATCH 3/9] block/curl: Tracing David Edmondson
2020-08-18 11:08 ` [RFC PATCH 4/9] block/curl: Perform IO in fixed size chunks David Edmondson
2020-08-18 11:08 ` [RFC PATCH 5/9] block/curl: Allow the blocksize to be specified by the user David Edmondson
2020-08-24 13:19   ` Markus Armbruster
2020-08-24 14:21     ` David Edmondson
2020-08-18 11:08 ` [RFC PATCH 6/9] block/curl: Cache downloaded blocks David Edmondson
2020-08-18 11:08 ` [RFC PATCH 7/9] block/curl: Allow the user to control the number of cache blocks David Edmondson
2020-08-18 11:08 ` [RFC PATCH 8/9] block/curl: Allow 16 sockets/ACB David Edmondson
2020-08-18 11:08 ` [RFC PATCH 9/9] block/curl: Add readahead support David Edmondson
2020-08-19 14:11 ` [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server Stefan Hajnoczi
2020-08-19 14:19   ` David Edmondson
2020-08-25 10:03     ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2154afa0-9d37-ee31-a446-4d3ec6df45a3@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dme@dme.org \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).