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/
Home Products Support Community News


Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 20 Mar 2007 07:10:27 +0000
Delivery-date: Tue, 20 Mar 2007 00:08:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070320044625.GA17463@xxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdqvtX/FF+5OtayEdukngAWy6hiGQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
Sounds good. I'm not sure about putting this in for 3.0.5 since that's only
a couple of weeks away. Also I'm loathe to add yet another darned
grant-table operation if we can avoid it. In this case I have my doubts it's
required, if we're prepared to hook off a slow path in the page-fault
handler (unhandled kernel fault). If we could get a callback into netback in
that case for some range of kernel virtual addresses then we could fix up
lazily in the case that an access races replacement of foreign mapping with
local mapping. We would like this anyway so we can do zero-copy-to-the-wire
(this may additionally require us to rev our interface to copy the packet
headers in the rings, or we could see how far just a small grant-copy
operation gets us). The idea would be to point the skb at a bunch of empty
mappings in the netback mapping area: if the areas have to be filled in (due
to firewall rules, filtering, PIO, etc) then we do it on demand from the
page-fault handler.

 -- Keir

On 20/3/07 04:46, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> These two patches remove the need for netloop by performing the
> copying in netback and only if it is necessary.  The rationale
> is that most packets will be processed without delay allowing
> them to be freed without copying at all.  So instead of copying
> every packet destined to dom0 we'll only copy those that linger
> longer than a specified amount of time (currently 0.5s).
> As it is netloop doesn't take care of all delays anyway.  For
> instance packets delayed by qdisc or netfilter can hold up
> resources without any limits.  Also if bridging isn't used
> then traffic to dom0 does not even go through netloop.
> Testing shows that these patches do eliminate the copying for
> bulk transfers.  In fact, bulk transfer throughput from domU
> to dom0 are increased by around 50%.  Even when the copying
> path is taken the performance is roughly equal to that of
> netloop despite the unoptimised copying path.

Xen-devel mailing list