Re: [Xen-devel] Poor network performance between DomU with multiqueue support

[openlui <openlui@xxxxxxx>]

At 2015-02-27 19:30:20, "David Vrabel" <david.vrabel@xxxxxxxxxx> wrote:
>On 27/02/15 10:59, Wei Liu wrote:
>> 
>> Persistent grant is not silver bullet. There is email thread on the
>> list discussing whether it should be removed in block driver.
>
>Persistent grants for to-guest network traffic is a flawed idea.  It
>either requires:
>
>a) the backend to memcpy into the mapped grant /and/ the frontend to
>memcpy out of the persistently mapped pool.  This is clearly going to be
>worse for memory bandwidth than a single grant copy.

Yes, persistent grant method does use more DomU's cpu than grant copy method. 

However, the persistent way does have one more memcpy operation than grant copy, but it has two less "mmap" operation than grant copy and no hypercall too. I have examined the code for grant copy, it needs to "mmap" the memory from src and dest domain to hypervisor,  then "memcpy" the data from src to dest. There will be more cpu used by hypervisor instead of DomU.

>or
>
>b) the backend to accumulate more and more mappings of guest memory,
>which is bad for security and it uses too many grant and map track
>resources hence it does not scale to many VIFs.

I find that persistent grant patch has a upper limit for amount of guest memory can be mapped by each queue of VIF. The limit seems to the VIF‘s ring size if I understand right, so the amount seems not high.
Under my benchmark, at least for single UDP flow, the persistent grant way has more higher throughout than grant copy way. 

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

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