[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130524133432.GD16745@zion.uk.xensource.com>
Date: Fri, 24 May 2013 14:34:32 +0100
From: Wei Liu <wei.liu2@...rix.com>
To: David Vrabel <david.vrabel@...rix.com>
CC: Wei Liu <wei.liu2@...rix.com>, <xen-devel@...ts.xen.org>,
<netdev@...r.kernel.org>, <ian.campbell@...rix.com>,
<konrad.wilk@...cle.com>
Subject: Re: [Xen-devel] [PATCH net-next 1/3] xen-netback: page pool support
On Fri, May 24, 2013 at 01:44:31PM +0100, David Vrabel wrote:
> On 24/05/13 11:32, Wei Liu wrote:
> > This patch implements a page pool for all vifs. It has two functionalities:
> > a) to limit the amount of pages used by all vifs
> > b) to track pages belong to vifs
>
> This adds a global spin lock. This doesn't seem very scalable.
>
> It's also not clear how this is usefully limiting the memory usage by
> guest network traffic. It limits the number of pages that netback can
> use during the grant copy from the guest pages but this is only short
> time compared to the lifetime of the network packet within the rest of
> the network stack.
>
> If you didn't have this page pool stuff then each thread/VIF is limited
> to at most 256 pages anyway and I think 1 MiB of memory per VIF is
> perfectly acceptable.
>
Oh I forgot to mention another important function of page pool -- to
track pages.
With this tracking facility it is really tricky to make thread-per-vif
work.
If you look at the original code, you can see we steal page->mapping
field for tracking purpose. The netback ref is stored in that field.
When switching to 1:1 model, the information embedded into page->mapping
is the index to pool element. If we don't have this pool, tracking
becomes more difficult.
Wei.
> David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists