Home > Blogs > VMware VROOM! Blog


Performance Evaluation of VMXNET3 Virtual Network Device

vSphere 4.0 introduces a new para-virtualized network device – VMXNET3.  We recently published a paper demonstrating its performance characteristics, compared to that of enhanced VMXNET2 (the previous generation of high performance virtual network device from VMware).

Some highlights of this paper are:

(1) Throughput gains of up to 92% for 10G TCP/IPv4 Rx workloads with large socket buffer, which greatly improves bulk data transfer performance in a data center environment.

(2) Dramatic gains across all configurations of IPv6 traffic, with significant CPU usage reduction and throughput improvement over enhanced VMXNET2.

In a nutshell, VMXNET3 offers performance on par with or better than its predecessors on both Windows and Linux guests. Both the driver and the device have been highly tuned to perform better on modern systems.  Furthermore, VMXNET3 introduces new features and enhancements, such as TSO6 and RSS. TSO6 makes it especially useful for users deploying applications that deal with IPv6 traffic, while RSS is helpful for deployments requiring high scalability.  Moving forward, to keep pace with an ever-increasing demand for network bandwidth, we recommend customers migrate to VMXNET3.

For more details, please read our full paper from here.

2 thoughts on “Performance Evaluation of VMXNET3 Virtual Network Device

  1. Fred Pratt

    On my RHEL 5 VM, I did the installation of vmxnet3:
    /etc/init.d/network stop
    rmmod vmxnet
    modprobe vmxnet3
    fine so far..
    when I
    /etc/init.d/network start
    it complains about an unexpected MAC address.

    Reply
    1. Darren G

      Old post, but for anyone that hits the above problem, it’ll be one of two things, either:

      * /etc/sysconfig/network-scripts/ifcfg-ethX contains a hardcoded MAC address.
      * udev has mapped the MAC address the the interface name. Removing or amending the contents of /etc/udev/rules.d/XX-persistent-net.rules (or similar) and rebooting is often the quickest resolution.

      Note that theoretically this will disappear with the introduction of the new Linux Network Device naming convention covered at http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming where eth0 becomes p0p0 etc…

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>