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


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 20 Mar 2007 15:46:25 +1100
Delivery-date: Mon, 19 Mar 2007 21:45:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
User-agent: Mutt/1.5.9i
Hi Keir:

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.

The copying is achieved through a new grant table operation.
I've only implemented it for x86.  However, there is a fallback
path for other platforms so they should continue to work.  It
shouldn't be too hard to implement this for ia64/ppc (for someone
with access to them).

In future I intend to exntend this idea to support lazy
copying for dom0 to domU as well which should give us a
complete zero-copy path from one domU to another.

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Xen-devel mailing list