[Xen-devel] RE: Re: help with bugs

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> > If you're running services in dom0 that are used by other 
> domains you 
> > are liable to get head-of-line blocking or even deadlock of 
> the domU's 
> > networking unless you use veth0:  all of the domU's skb's 
> could end up 
> > getting queued in dom0 socket buffers.
> > 
> > veth0 avoids this by copying packets destined for dom0 and 
> giving the 
> > buffer back to the domU.
> 
> Is there a test case for this?  I've been running some 
> services in dom0 and apparently running without veth0 for 
> quite some time.  It would be good to have a test that shows 
> this problem.

I haven't tried this, but I suspect it would work:

 * run a ttcp receiver in dom0 with a very large socket buffer size
 * connect to it with a ttcp transmitter in domU (again, large sock
buffer)
 * with data in flight, ^Z the dom0 receiver

I'd expect to see the ntworking of the domU (and potentially other
domU's) start to run very slowly or even grind to a halt. You may need
multiple parallel tcp connections to trigger this. Using UDP makes it
happen much more easily.

If you're using veth0 you shouldn't have the problem.

[There are plans for making the backend buffer management more dynamic
that would mitigate the effect on other domU's, but this wouldn't
completely obviate the need for veth0 as a single domU could still end
up with all of its buffers being held by dom0.
There's a partial fix for TCP (not UDP) whereby we have dom0 release
it's mapping of the domU buffer as soon as its sent the TCP ACK, rather
than when it finally frees the skb when the client reads it. 

Possibly the cleanest option would be to add a hook in the local receive
path that would enable us to copy&unmap any packets destined for local
delivery. Anyhow, not for 3.0.0 ...]

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel