Re: [Xen-devel] Linux grant map/unmap improvement proposal (Draft B)

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2014-10-14 at 11:32 +0100, David Vrabel wrote:
> 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.

I meant dom0 mounted NFS/ISCSI disks (either loopback or from driver
domains) going out over either physical or virtual network interfaces.

Ian.
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel