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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel