From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Pv-ops][PATCH 0/3] Resend: Netback multiple thread support Date: Wed, 28 Apr 2010 13:43:40 +0100 Message-ID: <4BD8499C020000780003C6AF@vpn.id2.novell.com> References: <4B182D87.6030901@goop.org> <4B187513.80003@goop.org> <4B200727.8040000@goop.org> <4B213766.7030201@goop.org> <20100427104925.GA14523@weybridge.uk.xensource.com> <20100428115157.GA17448@weybridge.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100428115157.GA17448@weybridge.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith , Dongxiao Xu Cc: Steven Smith , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Steven Smith 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