From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Liu Subject: Re: netfront/netback multiqueue exhausting grants Date: Fri, 22 Jan 2016 18:40:22 +0800 Message-ID: <56A20716.9090607@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A1EE2102000078000C9E13@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Boris Ostrovsky , xen-devel , Wei Liu , David Vrabel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 01/22/2016 03:53 PM, Jan Beulich wrote: >>>> On 22.01.16 at 04:36, 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. With multi-queue xen-block and xen-network, we got more reports that the grants were exhausted. -- Regards, -Bob