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][Pv-ops][PATCH 0/3] Resend: Netback multiple thread suppo

To: "Steven Smith" <steven.smith@xxxxxxxxxx>, "Dongxiao Xu" <dongxiao.xu@xxxxxxxxx>
Subject: Re: [Xen-devel][Pv-ops][PATCH 0/3] Resend: Netback multiple thread support
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 28 Apr 2010 13:43:40 +0100
Cc: Steven Smith <Steven.Smith@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 Apr 2010 05:44:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100428115157.GA17448@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B182D87.6030901@xxxxxxxx> <EADF0A36011179459010BDF5142A457501D11C20F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B187513.80003@xxxxxxxx> <EADF0A36011179459010BDF5142A457501D13FDE62@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B200727.8040000@xxxxxxxx> <EADF0A36011179459010BDF5142A457501D13FE3BB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B213766.7030201@xxxxxxxx> <D5AB6E638E5A3E4B8F4406B113A5A19A1D8CC03F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100427104925.GA14523@xxxxxxxxxxxxxxxxxxxxxxxxxx> <D5AB6E638E5A3E4B8F4406B113A5A19A1D8CC904@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100428115157.GA17448@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Steven Smith <steven.smith@xxxxxxxxxx> 28.04.10 13:51 >>>
>2) Introduce struct ext_page and use it everywhere you use it in the
>   current patch.  This should be fairly small.

In working through the patches to make them usable on our forward
ported trees, I wondered what this is good for at all, for two reasons:

On 64-bits embedding the data directly into page->mapping would
be possible without any other consideration.

Even on 32-bits embedding is possible based on the observation
that the two fields together don't need more than 32 bits (idx
always being less than MAX_PENDING_REQS [which itself could
even grow significantly] and group being bounded by NR_CPUS).

>I think we might be using slightly different terminology here.  When I
>say ``netfront'', I mean the frontend half of a virtual network
>interface, rather than the netfront driver, so a single domain can be
>configured with multiple netfronts in the same way that a single
>physical host can have multiple ixgbes (say), despite only having one
>ixgbe driver loaded.
>
>So, my original point was that it might be better to balance
>interfaces such that the number of interfaces in each group is the
>same, ignoring the frontend domain ID completely.  This would mean
>that if, for instance, a domain had two very busy NICs then they
>wouldn't be forced to share a tasklet, which might otherwise be a
>bottleneck.

As you had pointed out in an earlier reply, the use of the domain
ID here is flawed anyway - it had to be replaced for the whole
set to be usable for us. We count netif-s and balance based on
that count, at once eliminating the need to do any allocation
when adding a new netif.

Jan


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