You are on page 1of 9

Performance Study

10Gbps Networking Performance
VMware® ESX 3.5 Update 1

With increasing number of CPU cores in today’s computers and with high consolidation ratios combined with 
the high bandwidth requirements of today’s applications, the total I/O load on a server is substantial. Single 
1Gbps network cards are unable to support the demands of these applications, and multiple NICs are often 
impractical because the number of ports utilized on the host and on the network switches. Now 10Gbps 
Ethernet adapters offer a solution that provides much higher bandwidth while using fewer ports on the hosts 
and switches.

Support for 10Gbps networking devices was introduced in ESX 3.5. Features such as TCP segmentation offload 
(TSO), jumbo frames, and multiple receive queues were introduced to efficiently use 10Gbps devices. ESX 3.5 
Update 1 added support for PCI‐E–based Intel Oplin 10Gbps Ethernet adapters to ESX. 

In this paper, we present the following results:

„ A single one‐vCPU virtual machine can drive 8Gbps of traffic on the send path and 4Gbps traffic on the 
receive path when using standard MTU (1500 byte) frames.

„ Using jumbo frames, a single virtual machine can saturate a 10Gbps link on the transmit path and can 
receive network traffic at rates up to 5.7Gbps.

„ Both transmit and receive performance scale very well with increasing load on the ESX host.

„ Even on hosts with high consolidation ratios, all virtual machines get a fair share of the available receive 
and transmit bandwidth.

This paper covers the following topics:

„ “Performance Enhancements in ESX 3.5” on page 2
„ “Benchmarking Methodology” on page 2

„ “Standard MTU Performance” on page 4

„ “Jumbo Frame Performance” on page 5

„ “Performance Scalability with Multiple Virtual Machines” on page 6

„ “Conclusion” on page 8

„ “Resources” on page 9

Copyright © 2008 VMware, Inc. All rights reserved. 1

4. Hence.  such as the socket size and the message size. The NetQueue API allows a NIC driver to have multiple  queues for processing incoming packets on different physical CPU cores.5 Update 1 Client machine Red Hat Enterprise Linux 5 Update 1 AS 64‐bit  kernel: 2.el5  Virtual machines „ Red Hat Enterprise Linux 5 Update 1 AS 64‐bit  „ 1 virtual CPU kernel: 2. we used five simultaneous netperf sessions per  virtual machine. the device can use multiple physical CPU cores for processing packets destined for different virtual  machines on the host. Benchmark Test Configuration Hardware ESX  HP DL 580 G5 „ 4 quad‐core Xeon X7350 at 2. This boosts the networking performance on the receive path (which traditionally has  higher costs than the transmit path) when multiple virtual machines are running on the same host.2 for all the tests. which are larger than the standard Ethernet MTU (maximum transfer unit) of 1500 bytes. because a single session is unable to saturate a 10Gbps  link even when ample CPU cycles are available.66GHz  „ 16GB RAM „ Intel 82598 XF 10Gbps dual‐port  adapter Software ESX  ESX 3.18‐53. Table 1. It includes support to measure TCP and UDP throughput. see the Netperf Manual. see “Resources” on page 9. Netperf has a client‐server model and comprises the following: „ Netperf client.6. 2 .  using bulk transfers. Guest  operating systems using jumbo frames need fewer packets to transfer large amounts of data and can achieve  higher throughputs and lower CPU utilization than guests using packets with the standard MTU size.18‐53. that allows the CPU‐intensive task of segmenting  large TCP packets (up to 64KB) to be offloaded to the hardware.el5  „ 512MB RAM „ Windows Server 2003 SP2 Enterprise Edition  „ Virtual device: Enhanced VMXNET 64‐bit For tests using both single and multiple virtual machines.6.5 A number of enhancements have been integrated into the networking code of ESX 3.  Benchmarking Methodology We used the network benchmarking tool netperf 2. Copyright © 2008 VMware. which acts as a data sender „ Netserver process. Multiple netperf sessions are needed.5 also introduced support for NetQueue. Because the guest operating system can now  send packets larger than the standard MTU to ESX.  ESX 3. Netperf measures unidirectional  network performance for TCP and UDP traffic.  For a link to the manual. Inc. on a machine with MSI‐X  support. the processing overheads on the transmit path are greatly  reduced.  TSO is a feature. All rights reserved. typically  9000 bytes. widely supported by today’s network cards.5. Jumbo frames are large Ethernet frames. For more details on netperf. including support for  jumbo frames and TSO for Enhanced VMXNET devices.93GHz „ 16GB RAM „ Intel 82598 XF 10Gbps dual‐port  adapter Client machine HP DL 380 G5 „ 2 quad‐core Xeon X5355 at 2. 10Gbps Networking Performance Performance Enhancements in ESX 3. and end‐to‐end latencies. netperf allows you to specify parameters. which acts as a receiver To check for network performance under different configurations. for the tests.

 we  used nonpersistent disks. we needed to reboot the ESX host. see “Resources” on page 9. Inc. We pinned the Oplin interrupt vector (0xb1 in our case) to the adjoining core by running the  following command in ESX: echo "move 0xb1 2" > /proc/vmware/intr-tracker For the tests using multiple virtual machines. To  understand the performance difference between e1000 and vmxnet virtual devices. All rights reserved. For tests using a single virtual machine. both the virtual machine and  physical NIC interrupt vectors were pinned to two adjoining cores on the same CPU.  the MTU was set to 9000 in the following places: „ In the client. using esxcfg-vswitch -m 9000 vSwitch1 „ In the Windows virtual machine. by setting Device Manager > Network adapters > VMware PCI  Ethernet Adapter > Properties > Advanced > MTU to 9000 „ In the Linux virtual machine. 10Gbps Networking Performance The details of the experimental configuration are presented in Table 1.2 VMDQ=16. We booted the virtual machines in nonpersistent mode by adding the following line  to the .mode = independent-nonpersistent In this way.vmx file for each virtual machine: scsi0:0.1" ixgbe For the changes to come into effect. All virtual machines used for the  experiments used a uniprocessor kernel or HAL and were configured with one virtual CPU. We configured the Intel Oplin driver (ixgbe) to be loaded with MSI‐X based interrupt and 16 receive queues  on the test interface and a single queue on the second interface of the dual‐port NIC by using the following  command: esxcfg-module -s "InterruptType=2.” For a link.MaxNetifTxQueueLen). Copyright © 2008 VMware. We pinned the virtual  machine to physical CPU 3 using VI Client (VM > Edit Settings > Resources > Advanced CPU > Scheduling  affinity). Because 16 virtual machines sending a large number of small packets can easily overflow the default queues  on the host. using ifconfig eth1 mtu 9000 „ On the ESX host. see “Performance  Comparison of Virtual Network Devices.netNetqueueEnabled). we enabled NetQueue using VI Client (Configuration >  Advanced Settings > VMkernel > VMkernel. we could boot multiple virtual machines from the same virtual disk. TSO was enabled by default in the virtual machines as well as on the client machine.” For a link.  see “Enabling Support for NetQueue on the Intel 82598 10 Gigabit Ethernet Controller. for tests using multiple virtual machines. see  “Resources” on page 9. for minimal variance in the experiments. To enable jumbo frames. using ifconfig eth1 mtu 9000 NOTE   It is important that there is no mismatch of MTUs along a given link. For more details on enabling NetQueue. For the scaling tests using multiple virtual machines. All changes to such a virtual  machine are lost after the virtual machine powers down. 3 .Boot. we increased the Pending Tx Packet queue size from the  default value of 200 to 500 using VI Client (Configuration > Advanced Settings > Net >  Net. instead of creating 15 clones of the original virtual machines. All virtual  machines were configured with 512MB of RAM and used the Enhanced VMXNET virtual device.

 with current hardware. all  reported numbers are the average of three one‐minute runs. we swapped the netperf and netserver processes. Test Setup for Send Test from Virtual Machine to Native Environment guest (virtual machine) netperf virtual switch netserver ESX host client machine crossover cable Figure 1 shows the test configuration for the send tests in which a virtual machine is sending data. see  “Resources” on page 9. Thus. For the  receive tests. The receive throughput is  usually lower than the transmit throughput for the same network configuration. Copyright © 2008 VMware. because the processing  overheads on the receive path are higher than those on the transmit path. We ran two sets of throughput tests—first  without jumbo frames. Using a large socket size and a large message size  helps transmit performance significantly. This difference in performance can  be attributed to the differences in the TCP/IP stacks of the two operating systems. 10Gbps Networking Performance Figure 1. and then with jumbo frames enabled. For the tests using a single virtual machine.” For a link.  The network performance between two virtual machines on the same host is independent of physical NIC  speeds and is discussed in detail in “Networking Performance in VMware ESX Server 3. a one‐vCPU virtual machine can drive 8Gbps of traffic on the transmit path and  4Gbps on the receive path. the  run lengths were increased to two minutes to compensate for the skew in starting experiments simultaneously  in as many as 16 virtual machines. This paper does not discuss the performance when two virtual machines are running on the same ESX host. Linux virtual machines can receive 4Gbps of  traffic. With either operating system.5. All rights reserved. Standard MTU Performance Figure 2 shows the TCP throughput observed for Linux and Windows one‐vCPU virtual machines  transmitting and receiving without using Jumbo Frames. 4 . whereas Windows virtual machines are limited to 3Gbps of traffic. a single uniprocessor  virtual machine can drive approximately 8Gbps of traffic. For the tests using multiple virtual machines. Inc. On the receive path.

 with a 128KB socket.8KB . as can be seen in the graph.  On the receive path.64KB . Single Virtual Machine Performance with 1500-byte Packets 9 8 Throughput (Gbps) 7 6 5 4 3 2 1 0 8KB .64KB . We have observed that Windows receive performance is adversely affected by socket sizes greater  than 64KB.64KB - 512B 4KB 512B 8KB 16KB 64KB 512B 4KB 512B 8KB 16KB 64KB Netperf configuration (Socket size . 5 .64KB . the Linux virtual  machine is able to saturate the 10Gbps link.64KB .64KB .8KB .Message size) Transmit Receive Linux Windows Jumbo Frame Performance Though the transmit throughput using the standard MTU (1500 bytes) packets comes close to the native  throughput. we used 128KB sockets instead of 8KB sockets because most operating systems see benefits  from jumbo frames when using large socket sizes. irrespective of the message sizes being used for the test.  Figure 3 shows the throughput results for one‐vCPU virtual machines using 9000 byte jumbo frames. For  jumbo frame tests. Similarly. As the graphs show. Inc. Copyright © 2008 VMware. a single uniprocessor virtual machine is CPU limited and cannot saturate a 10Gbps link.64KB .64KB . with jumbo frames. 10Gbps Networking Performance Figure 2. Jumbo frames can help reduce some processing overheads because  large Ethernet frames result in few packets. 8KB . All rights reserved.  receive throughput is limited to 4Gbps. Windows  throughput remains nearly constant for all the network configurations. the throughput for Linux virtual machines increases by up to 40 percent over the standard  MTU case. a single virtual machine can saturate a 10Gbps link on the transmit path and its  receive performance can improve by up to 40 percent in some cases. Thus.

 we ran  tests with as many as 16 virtual machines sharing the same physical NIC. Ideally.512B Linux 64KB . Figure 4 and Figure 5 show the results from the transmit  scaling and receive scaling tests.512B Windows 64KB .512B Linux 64KB .64KB .512B Windows 64KB .16KB Copyright © 2008 VMware. Inc.128KB 128KB 128KB 64KB . All rights reserved. In real world deployments. The results presented in this section simulate the worst case  scenario. Figure 4. 6 . These virtual machines share the host CPU  and memory as well as the storage and networking devices. To understand the performance in such a scenario.128KB 128KB 128KB 8KB 16KB 64KB .8KB -16KB -64KB Netperf configuration (Socket size . in which all virtual machines are simultaneously stressing the network.8KB -16KB -64KB 8KB 16KB 64KB . We assume that a large number of small virtual  machines will share a single physical 10Gbps NIC. the throughput should increase linearly and then stabilize after a certain point (and not  decrease as the load is increased on the system).64KB . as virtual machines are  added to the system.64KB .Message size) Transmit Receive Linux Windows Performance Scalability with Multiple Virtual Machines One of the primary advantages of using virtualization is the ability to consolidate multiple physical servers  into multiple virtual machines running on a single physical host. Single Virtual Machine Performance with 9000-byte Packets 10 9 Throughput (Gbps) 8 7 6 5 4 3 2 1 0 64KB . 10Gbps Networking Performance Figure 3. Multiple Virtual Machine Transmit Performance 10 9 8 Throughput (Gbps) 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Number of virtual machines Linux 8KB .  the bandwidth requirements of most applications are low. and hence consolidation ratios will be higher.16KB Windows 8KB . respectively.64KB .

 In such configurations. throughput increases linearly up to a few virtual machines and  then stabilizes at a lower value. Inc.16KB Figure 5 shows how performance scales on the receive path with an increasing number of virtual machines.  as mentioned earlier. Our tests show the worst  case scenario. ESX scales well with an increasing number of virtual machines on the system. Copyright © 2008 VMware. throughput is usually limited by the TCP/IP stack or  by the processing power of the single client.4Gbps for standard MTU) and remains constant despite increasing load on the system. Virtual machines in typical customer environments  usually have much lower throughput requirements and can scale to a much larger numbers of virtual  machines. we  showed that a single virtual machine can drive up to 8Gbps of traffic. Multiple Virtual Machine Receive Performance 10 9 8 Throughput (Gbps) 7 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Number of virtual machines Linux 8KB .5 scales well and that networking throughput increases until it reaches the saturation  point (9. All lines on the graph show a similar trend—the throughput increases linearly until it reaches  line rates and remains constant until the load reaches seven virtual machines. 10Gbps Networking Performance Figure 4 shows how the transmit performance scales with an increasing number of virtual machines. As we increased to more than  seven virtual machines. For both  Linux and Windows. 7 . Figure 5.  As expected from the single virtual machine results.512B Windows 64KB . we saw a very gradual continuous decline as the load in increased to 16 virtual  machines.512B Linux 64KB .16KB Windows 8KB . two virtual machines are enough to saturate a 10Gbps link. Thus. which is receiving all traffic from multiple virtual machines. To  confirm this. The Linux small socket size and small message size case does not perform as well as the others and. In tests with  small socket sizes and small message sizes. The large socket size cases show that  VMware Infrastructure 3. three virtual machines are enough to saturate the link in  the receive case.512B Windows 64KB . this is a result of the fact that Red Hat Enterprise Linux 5 running natively (on the client)  cannot push beyond 6Gbps when using small sockets and small message sizes. Performance  should be better in real world deployments in which it is rare that all virtual machines booted on a system are  pushing traffic at the maximum rate at the same time. we ran Red Hat Enterprise Linux 5 natively on the same hardware (with 16 physical cores) and  found that it can drive only approximately 6Gbps of traffic when using an 8KB socket size and 512 byte  message size. In the previous sections. All rights reserved.512B Linux 64KB . in which all virtual machines are running a bandwidth‐intensive application.

  Thus. A single uniprocessor virtual machine can push as much  as 8Gbps of traffic with frames that use the standard MTU size and can saturate a 10Gbps link when using  jumbo frames. with  throughput increasing linearly until we achieve line rate and then gracefully decreasing as system load and  resource contention increase. Jumbo frames can also boost receive throughput by up to 40 percent. and  the throughput remains constant as we add more virtual machines. Figure 6 shows the average  throughput per virtual machine when using a configuration with 64KB sockets and 16KB messages.3Gbps for packets that use the standard MTU size because of protocol overheads). 10Gbps Networking Performance Figure 6. in which there are 75  TCP connections (five per virtual machines). allowing a single virtual  machine to receive traffic at rates up to 5. in the Windows transmit case with 15 virtual machines. Copyright © 2008 VMware. Two virtual machines can easily saturate a 10Gbps link  (the practical limit is 9.7Gbps. the average throughput per virtual machine is 627Mbps and the  standard deviation is a mere 17Mbps. Inc. Throughput Fairness in Test with 15 Virtual Machines 800 700 600 Throughput (Mbps) 500 400 300 200 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Virtual machines Linux Rx Linux Tx Windows Rx Windows Tx We also investigated fairness among the TCP flows across all virtual machines.5 Update 1 can  efficiently share and saturate 10Gbps Ethernet links. For example. The  relatively flat lines indicate that even when the system is highly loaded. ESX 3. All rights reserved. 8 . Scaling on the receive path is similar.5 Update 1 supports the latest generation of 10Gbps NICs with minimal overheads and allows  high virtual machine consolidation ratios while being fair to all virtual machines sharing the NICs and  maintaining 10Gbps line rates. Conclusion The results presented in the previous sections show that virtual machines running on ESX 3. all virtual machines get a fair share of  the bandwidth.  Our detailed scaling tests show that ESX scales very well with increasing load on the system and fairly  allocates bandwidth to all the booted virtual machines.

7.155. and 7.com/files/pdf/perf_comparison_virtual_network_devices_wp.966. CA 94304 www.409. 7. 7.412.vmware.222.951.377.111.496.136.806.944. Revision: 20081104 Item: PS-071-PRD-01-01 9 .785.145.5” http://www.102. 7..683.vmware.699.275. 7.117.242. 6.710. 7. Patent Nos.org/netperf/training/Netperf.558. 6.961.289.815. Inc.492. and VMotion are registered trademarks or trademarks of VMware. All other marks and names mentioned herein may be trademarks of their respective companies.156. 3401 Hillview Ave.434.278. Virtual SMP.260.281.795.pdf „ Netperf manual  http://www.vmware. 7.789.941.com/files/pdf/ESX_networking_performance. in the United States and/or other jurisdictions.html „ “Networking Performance: VMware ESX Server 3. 7. 7.702.277.030. 10Gbps Networking Performance Resources „ “Enabling Support for NetQueue on the Intel 82598 10 Gigabit Ethernet Controller“ http://kb. patents pending.636.711.netperf. 7.672.424.481. Inc. Palo Alto.111. 6.pdf If you have comments about this documentation.149.com/kb/1004278 „ “Performance Comparison of Virtual Network Devices” www. 7.998. 6. 7.413.269.679. 6.598.925. 7.069.260.022.735. Protected by one or more of U.847. 6. 6. 7.082.086.221. All rights reserved.277. 7. 7.999. 7.com Copyright © 2008 VMware. 7.S.com VMware. 7.886. 6.704.428.601. 7. 6.002. 6. Inc.253. VMware.725.433. 843.vmware.356. 6.089.880.397. submit your feedback to: docfeedback@vmware.487. 6. 6. 7.412.961.290.820. the VMware “boxes” logo and design. 7. 7. 7. 7.