| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] n/w performance degradation
On 6 Dec 2005, at 00:04, Diwaker Gupta wrote:
> Look forward to it. Whats the deal with the pipelined backend? Whats
> the target scenario there?
It's a form of request-notification avoidance. It allows the frontend
to avoid sending a notification (virtual ipi) to the backend if any
previous requests are still in flight (no response received). In some
situations, pipelining can mean you basically need to send no
notifications, because the backend will pull down new requests as it
responds to old ones.
Thing is, it doesn;t work for some forms of packet processing in
domain0. For example, if you send fragmented IP datagrams and they are
reassembled in domain0 there may be a dependency between packets. Hence
you need to send notifications even if buffers are in flight because
you won't get a response until the datagram is reassembled and
forwarded.
Meanwhile, though I agree that SMPs and hyperthreaded processors are
becoming the norm, it still doesn't solve this problem. Even on an SMP
machine, I can have dom0 co-located with a VM on the same CPU, and I'm
not sure how different that would be from the current situation.
With enough hardware contexts, it'll soon become sensible to dedicate a
context to domain0 or your IDD. It's certainly a very sensible use of a
hyperthread (almost certainly a better use than multiprocessing within
a guest, if you do a significant amount of i/o).
On a related note, has anyone been working on the IDD stuff? Is it
possible to wrap up a device driver in its own domain? The last time
I tried, it basically wasn't possible, but I'd really be interested in
helping out any which way to get it working.
Needs some PCI virtualization in Xen (managed by platform code in
domain0). Nothing too tricky I think.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home