From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bob Liu <bob.liu@oracle.com>
Subject: Re: netfront/netback multiqueue exhausting grants
Date: Sat, 23 Jan 2016 08:29:19 +0800
Message-ID: <56A2C95F.8060609@oracle.com>
References: <1453292623.26343.95.camel@citrix.com>
	<56A0B957.9060101@citrix.com> <1453378752.4320.26.camel@citrix.com>
	<56A1A3AB.1040603@oracle.com>
	<56A1EE2102000078000C9E13@prv-mh.provo.novell.com>
	<56A20716.9090607@oracle.com>
	<56A21A6B02000078000C9FDD@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56A21A6B02000078000C9FDD@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel <xen-devel@lists.xen.org>, Wei Liu <wei.liu2@citrix.com>, David Vrabel <david.vrabel@citrix.com>, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org


On 01/22/2016 07:02 PM, Jan Beulich wrote:
>>>> On 22.01.16 at 11:40, <bob.liu@oracle.com> wrote:
>> On 01/22/2016 03:53 PM, Jan Beulich wrote:
>>>>>> On 22.01.16 at 04:36, <bob.liu@oracle.com> wrote:
>>>> By the way, do you think it's possible to make grant table support bigger 
>>>> page e.g 64K?
>>>> One grant-ref per 64KB instead of 4KB, this should able to reduce the grant 
>>>> entry consumption significantly.
>>>
>>> How would that work with an underlying page size of 4k, and pages
>>> potentially being non-contiguous in machine address space? Besides
>>> that the grant table hypercall interface isn't prepared to support
>>> 64k page size, due to its use of uint16_t for the length of copy ops.
>>
>> Right, and I mean whether we should consider address all the place as your 
>> mentioned.
> 
> Just from an abstract perspective: How would you envision to avoid
> machine address discontiguity? Or would you want to limit such an

E.g Reserve a page pool with continuous 64KB pages, or make grant-map support huge page(2MB)?
To be honest, I haven't think much about the detail.

Do you think that's unlikely to implement?
If yes, we have to limit the queue numbers, VM numbers and vdisk/vif numbers in a proper way
to make sure the guests won't enter grant-exhausted state.

> improvement to only HVM/PVH/HVMlite guests?
> 
> Jan
> 

-- 
Regards,
-Bob