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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 14/10/14 11:35, Ian Campbell wrote:
> 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.

I'm still confused.  Is this not the use case I describe in the "Blkback
and network storage" section?  Whether the retransmitted packet is sent
via a physical NIC or a virtual one doesn't matter.

David

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