WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xen-unstable: TX/RX ring buffer exhaustion and NR_GRANT_

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] xen-unstable: TX/RX ring buffer exhaustion and NR_GRANT_FRAMES
From: harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 11 Nov 2005 12:11:48 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Birger Toedtmann <btoedtmann@xxxxxxxxxxxxxx>
Delivery-date: Fri, 11 Nov 2005 12:12:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <ecb5734c1f5cfe17aac43e322a6b28f1@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1131699597.3405.8.camel@lomin> <ecb5734c1f5cfe17aac43e322a6b28f1@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
The xenidc code has the concept of a buffer resource provider which
implements an anti-deadlock resource reservation.  Each client has uses
a pool with it's own buffer resource provider and the anti-deadlock
resource reservations decouple the clients from one another.  The
underlying implementation of the buffer resource provider is currently
trivial (individual resource pools) but the intention is that the buffer
resource providers will share resources from a common underlying pool.

This resource management strategy allows you to make better use of
constrained resources like grant tables whilst avoiding deadlock.

On Fri, 2005-11-11 at 10:48 +0000, Keir Fraser wrote:
> On 11 Nov 2005, at 08:59, Birger Toedtmann wrote:
> 
> > message - see bug #183.  It was pointed out to me that it might be
> > possible to adjust this manually in xen/include/xen/grant_table.h,
> > however, setting ORDER_GRANT_FRAMES to 3 to get more pages of grant
> > tables doesn't change anything.  Sooo, question #1: how can I alter the
> > code to get more grant tables such that more nics per domU will become
> > available?  Question #2: is it planned to make this configurable, e.g.
> > by boot option for dom0?
> 
> 1: you need to edit NR_GRANT_FRAMES in linux/include/asm-xen/gnttab.h
> 
> 2: yes, it will eventually be manually configurable with a higher 
> default 'maximum'
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>