<div class="gmail_quote">Thanks Theo, I will see what I can pull. I think grabbing just the aggr module is the best option at the moment. The guest is Gentoo (Kernel 3.2.12). Here's the performance bottleneck I'm seeing .. gazoo is OmniOS host with 2 x igb in L4 aggr with main lan on VLAN 300 slate is Gentoo KVM on OmniOS with 1 x virtio vnic on aggr VLAN 300 myth is Gentoo phys with 1 x nvidia single gige with main lan on VLAN 300 Issue: gazoo <> myth = good anything <> slate = bad Examples: myth ~ # iperf -c gazoo ------------------------------------------------------------ Client connecting to gazoo, TCP port 5001 TCP window size: 22.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.245.136 port 60917 connected with 192.168.245.134 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.09 GBytes 932 Mbits/sec root@gazoo ~ # iperf -c myth ------------------------------------------------------------ Client connecting to myth, TCP port 5001 TCP window size: 48.0 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.245.134 port 36001 connected with 192.168.245.136 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.05 GBytes 899 Mbits/sec root@gazoo ~ # iperf -c slate ------------------------------------------------------------ Client connecting to slate, TCP port 5001 TCP window size: 48.0 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.245.134 port 51500 connected with 192.168.245.152 port 5001 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 26.5 MBytes 22.2 Mbits/sec myth ~ # iperf -c slate ------------------------------------------------------------ Client connecting to slate, TCP port 5001 TCP window size: 22.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.245.136 port 56461 connected with 192.168.245.152 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 91.8 MBytes 75.3 Mbits/sec<div class="HOEnZb"><div class="h5"> <div class="gmail_quote">On Mon, Jul 9, 2012 at 10:53 AM, Theo Schlossnagle <<a href="mailto:jesus@omniti.com" target="_blank">jesus@omniti.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes. If you switch to the bloody repo, you should be able to do a pkg update and get a new kernel. The release publisher is: <a href="http://pkg.omniti.com/omnios/release/" target="_blank">http://pkg.omniti.com/omnios/release/</a> Bloody's publisher is: <a href="http://pkg.omniti.com/omnios/bloody/" target="_blank">http://pkg.omniti.com/omnios/bloody/</a> pkg unset-publisher omnios pkg set-publisher -g <a href="http://pkg.omniti.com/omnios/bloody/" target="_blank">http://pkg.omniti.com/omnios/bloody/</a> omnios pkg update This should give you a new BE running bloody to reboot into. Alternatively, you could just snag the aggr module from bloody and replace the one you have. There are a couple of severe performance pathologies regarding networking under qemu/kvm, can you say what the guest is? <div><div> On Sun, Jul 8, 2012 at 8:24 PM, Denis Cheong <<a href="mailto:denis@denisandyuki.net" target="_blank">denis@denisandyuki.net</a>> wrote: > Hi Theo > > Is there an easy way that I can test your proposed fix to this issue? > > I am having major network performance bottlenecks in KVM and I suspect that > it has something to do with the duplicate packets, so would like to test it > out. </div></div>-- Theo Schlossnagle <a href="http://omniti.com/is/theo-schlossnagle" target="_blank">http://omniti.com/is/theo-schlossnagle</a> </blockquote></div> </div></div></div>