kvm-guest-drivers-windows-2
Quoted 4 lines · Avi Kivity
This is the second release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP, and Windows 2003. Both x86 and x64 variants are provided. kvm-61 or later is needed in the host. At the moment only binaries are available.
Hi,
This is great news!
Do you have any performance numbers for networking to see how it compares to the real hardware?
- Linux host (or: real Windows running on that host)
- PV Windows (network driver)
- non-PV Windows
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 7 lines · Tomasz Chmielewski
Quoted 4 lines · Avi Kivity
This is the second release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP, and Windows 2003. Both x86 and x64 variants are provided. kvm-61 or later is needed in the host. At the moment only binaries are available.
Quoted 8 lines
Hi,
This is great news!
Do you have any performance numbers for networking to see how it compares to the real hardware?
- Linux host (or: real Windows running on that host)
For host you can measure yourself but for Linux guest (to host) it currently do about 1G, using TSO (work in progress) it can do 2.5G, and there is also work in progress to make the kernel know virtio through the tap interface which will further boot performance.
Quoted 1 line
- PV Windows (network driver)
About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver.
Quoted 1 line
- non-PV Windows
What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 9 lines · Dor Laor
Quoted 4 lines
Do you have any performance numbers for networking to see how it compares to the real hardware?
- Linux host (or: real Windows running on that host)
For host you can measure yourself but for Linux guest (to host) it currently do about 1G, using TSO (work in progress) it can do 2.5G, and there is also work in progress to make the kernel know virtio through the tap interface which will further boot performance.
... with what kind of CPU utilization?
Quoted 4 lines
Quoted 1 line
- PV Windows (network driver)
About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver.
Same question (although it's less interesting if we can't even saturate the pipe).
Quoted 5 lines
Quoted 1 line
- non-PV Windows
What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-.
Same question (although again it's less interesting if we can't even saturate the pipe).
Cheers,
Muli
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Dor Laor schrieb:
(...)
Quoted 10 lines
Quoted 1 line
- PV Windows (network driver)
About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver.
Quoted 1 line
- non-PV Windows
What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-.
Just generally, how Windows PV drivers help to improve network performance.
So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 600 Mb/s, Windows guest to host?
That would be about 20% improvement?
Signature · 8 lines
Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 15 lines · Tomasz Chmielewski
Dor Laor schrieb:
(...)
Quoted 10 lines
Quoted 1 line
- PV Windows (network driver)
About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver.
Quoted 1 line
- non-PV Windows
What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-.
Quoted 8 lines
Just generally, how Windows PV drivers help to improve network performance.
So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 600 Mb/s, Windows guest to host?
That would be about 20% improvement?
It's work in progress, doing zero copy in the guest, adding TSO, using virtio'd tap will drastically boot performance. There is no reason the performance won't match Linux guest.
Also I don't exactly remember the numbers but the gain in the tx pass is grater.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 19 lines · Dor Laor
Quoted 17 lines · Tomasz Chmielewski
Dor Laor schrieb:
(...)
Quoted 12 lines
Quoted 2 lines
- PV Windows (network driver)
About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver.
Quoted 2 lines
- non-PV Windows
What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-.
Quoted 7 lines
Quoted 7 lines
Just generally, how Windows PV drivers help to improve network performance.
So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 600 Mb/s, Windows guest to host?
That would be about 20% improvement?
FWIW, virtio-net is much better with my patches applied. The difference between the e1000 and virtio-net is that e1000 consumes almost twice as much CPU as virtio-net so in my testing, the performance improvement with virtio-net is about 2x. We were loosing about 20-30% throughput because of the delays in handling incoming packets.
Regards,
Anthony LIguori
Quoted 10 lines
Quoted 1 line
It's work in progress, doing zero copy in the guest, adding TSO, using virtio'd tap will drastically boot performance. There is no reason the performance won't match Linux guest.
Also I don't exactly remember the numbers but the gain in the tx pass is grater.
Quoted 9 lines
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Anthony Liguori schrieb:
(...)
Quoted 11 lines
Quoted 5 lines
Quoted 5 lines
So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 600 Mb/s, Windows guest to host?
That would be about 20% improvement?
FWIW, virtio-net is much better with my patches applied. The difference between the e1000 and virtio-net is that e1000 consumes almost twice as much CPU as virtio-net so in my testing, the performance improvement with virtio-net is about 2x. We were loosing about 20-30% throughput because of the delays in handling incoming packets.
Do you by chance have any recent numbers on disk performance (i.e., Windows guest vs Linux host)?
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 10 lines · Tomasz Chmielewski
Anthony Liguori schrieb:
(...)
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
So, a PV network driver can do about 700Mb/s, and an emulated NIC can do about 600 Mb/s, Windows guest to host?
That would be about 20% improvement?
Quoted 10 lines
Quoted 5 lines
FWIW, virtio-net is much better with my patches applied. The difference between the e1000 and virtio-net is that e1000 consumes almost twice as much CPU as virtio-net so in my testing, the performance improvement with virtio-net is about 2x. We were loosing about 20-30% throughput because of the delays in handling incoming packets.
Do you by chance have any recent numbers on disk performance (i.e., Windows guest vs Linux host)?
At the moment there is no pv block driver for Windows guests. (there is for linux)
You can use scsi for windows, it should perform well.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Dor Laor schrieb:
(...)
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
FWIW, virtio-net is much better with my patches applied. The difference between the e1000 and virtio-net is that e1000 consumes almost twice as much CPU as virtio-net so in my testing, the performance improvement with virtio-net is about 2x. We were loosing about 20-30% throughput because of the delays in handling incoming packets.
Quoted 8 lines
Quoted 4 lines
Do you by chance have any recent numbers on disk performance (i.e., Windows guest vs Linux host)?
At the moment there is no pv block driver for Windows guests. (there is for linux)
You can use scsi for windows, it should perform well.
How well, when compared to "bare metal"? Or when compared to a Linux guest with a pv block driver? Do you have any numbers?
Signature · 7 lines
Tomasz Chmielewski http://wpkg.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 1 line · Anthony Liguori
FWIW, virtio-net is much better with my patches applied.
The can_receive patches?
Again, I'm not opposed to them in principle, I just think that if they help that this points at a virtio deficiency. Virtio should never leave the rx queue empty. Consider the case where the virtio queue isn't tied to a socket buffer, but directly to hardware.
Signature · 7 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 9 lines · Avi Kivity
Quoted 1 line · Anthony Liguori
FWIW, virtio-net is much better with my patches applied.
The
can_receivepatches?Again, I'm not opposed to them in principle, I just think that if they help that this points at a virtio deficiency. Virtio should never leave the rx queue empty. Consider the case where the virtio queue isn't tied to a socket buffer, but directly to hardware.
For RX performance:
right now
[ 3] 0.0-10.0 sec 1016 MBytes 852 Mbits/sec
revert tap hack
[ 3] 0.0-10.0 sec 564 MBytes 473 Mbits/sec
all patches applied
[ 3] 0.0-10.0 sec 1.17 GBytes 1.01 Gbits/sec
drop lots of packets
[ 3] 0.0-10.0 sec 1.05 GBytes 905 Mbits/sec
The last patch is not in my series but it basically makes the ring size 512 and drops packets when we run out of descriptors. That was to valid that we're not hiding a virtio deficiency. The reason I want to buffer
packets is that it avoids having to deal with tuning. For
vringfd/vmdq, we'll have to make sure to get the tuning right though.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 27 lines · Anthony Liguori
Quoted 9 lines · Avi Kivity
Quoted 1 line · Anthony Liguori
FWIW, virtio-net is much better with my patches applied.
The
can_receivepatches?Again, I'm not opposed to them in principle, I just think that if they help that this points at a virtio deficiency. Virtio should never leave the rx queue empty. Consider the case where the virtio queue isn't tied to a socket buffer, but directly to hardware.
For RX performance:
right now
[ 3] 0.0-10.0 sec 1016 MBytes 852 Mbits/secrevert tap hack
[ 3] 0.0-10.0 sec 564 MBytes 473 Mbits/secall patches applied
[ 3] 0.0-10.0 sec 1.17 GBytes 1.01 Gbits/secdrop lots of packets
[ 3] 0.0-10.0 sec 1.05 GBytes 905 Mbits/sec
Quoted 5 lines
The last patch is not in my series but it basically makes the ring size 512 and drops packets when we run out of descriptors. That was to valid that we're not hiding a virtio deficiency. The reason I want
to buffer packets is that it avoids having to deal with tuning. For
vringfd/vmdq, we'll have to make sure to get the tuning right though.
Okay; I'll apply the patches. Hopefully we won't diverge too much from upstream qemu.
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 35 lines · Avi Kivity
Quoted 27 lines · Anthony Liguori
Quoted 9 lines · Avi Kivity
Quoted 1 line · Anthony Liguori
FWIW, virtio-net is much better with my patches applied.
The
can_receivepatches?Again, I'm not opposed to them in principle, I just think that if they help that this points at a virtio deficiency. Virtio should never leave the rx queue empty. Consider the case where the virtio queue isn't tied to a socket buffer, but directly to hardware.
For RX performance:
right now
[ 3] 0.0-10.0 sec 1016 MBytes 852 Mbits/secrevert tap hack
[ 3] 0.0-10.0 sec 564 MBytes 473 Mbits/secall patches applied
[ 3] 0.0-10.0 sec 1.17 GBytes 1.01 Gbits/secdrop lots of packets
[ 3] 0.0-10.0 sec 1.05 GBytes 905 Mbits/secQuoted 6 lines
The last patch is not in my series but it basically makes the ring size 512 and drops packets when we run out of descriptors. That was to valid that we're not hiding a virtio deficiency. The reason I want to buffer packets is that it avoids having to deal with
tuning. For vringfd/vmdq, we'll have to make sure to get the tuning
right though.
Quoted 2 lines
Okay; I'll apply the patches. Hopefully we won't diverge too much from upstream qemu.
I am going to push these upstream. I need to finish the page_desc cache first b/c right now the version of virtio that could go into upstream QEMU has unacceptable performance for KVM.
Regards,
Anthony Liguori
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/