From: David Vrabel <david.vrabel@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: Linux grant map/unmap improvement proposal (Draft B)
Date: Tue, 14 Oct 2014 11:32:58 +0100 [thread overview]
Message-ID: <543CFBDA.1000105@citrix.com> (raw)
In-Reply-To: <1413282456.10417.27.camel@citrix.com>
On 14/10/14 11:27, Ian Campbell wrote:
> On Mon, 2014-10-13 at 14:41 +0100, David Vrabel wrote:
>> Safe grant unmap
>> ----------------
>>
>> Grant references will only be unmapped when they are no longer in use.
>> i.e., the page reference count is one.
>>
>> int gnttab_unmap_refs_async(struct gnttab_unmap_grant_ref *unmap_ops,
>> struct gnttab_unmap_grant_ref *kunmap_ops,
>> struct page **pages, unsigned int count,
>> void (*done)(void *data), void *data);
>>
>> The `gnttab_unmap_refs_async()` function will unmap the grant
>> references using the supplied unmap operations and call `done(data)`.
>> The grant unmap will only be done once all pages are no longer in use.
>>
>> It shall run synchronously on the first attempt (this is expected to
>> be the most common case). If any page is in use, it shall queue the
>> unmap request to be tried at a later time.
>>
>> Only the blkback and gntdev devices need to use asynchronouse unmaps.
>
> What about storage over networking? Does this work for that case too? I
> suppose that would just manifest as >1 reference counts when the blk op
> finishes, which would be taken care of by the delay.
I'm not sure I follow what use case you're talking about here. If the
guest is using NFS or iSCSI or similar, then netback just sees ethernet
packets and doesn't need to distinguish between different types of
network traffic from the guest.
David
next prev parent reply other threads:[~2014-10-14 10:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 13:41 Linux grant map/unmap improvement proposal (Draft B) David Vrabel
2014-10-13 16:43 ` Stefano Stabellini
2014-10-13 17:22 ` David Vrabel
2014-10-14 10:27 ` Ian Campbell
2014-10-14 10:32 ` David Vrabel [this message]
2014-10-14 10:35 ` Ian Campbell
2014-10-14 12:49 ` David Vrabel
2014-10-14 12:59 ` Ian Campbell
2014-10-15 17:45 ` Zoltan Kiss
2014-10-16 15:54 ` David Vrabel
2014-12-18 17:55 ` David Vrabel
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=543CFBDA.1000105@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Xen-devel@lists.xen.org \
--cc=ian.campbell@citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.