Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - - Original Message - Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime): ... snip The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. if_vmx - if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo - if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run was only 3.47GBits/sec in that case, took the numbers anyway) Thanks for the sysctl output. dev.vmx.0.txq0.ringfull: 133479 dev.vmx.0.txq0.hstats.tso_packets: 564986 dev.vmx.0.txq0.hstats.ucast_packets: 570604 For the number of packets transmitted, there's a really high percentage of time we find the Tx queue full enough it is not able to hold the next to transmit frame. I've haven't been able to recreate this. But I recently made a commit [1] that might help alleviate this. [1] http://svnweb.freebsd.org/base?view=revisionrevision=255055 wbr, -Harry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime): ... It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo frames with vmxnet3. This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ Thanks a lot for your ongoing work! I can confirm that with recent if_vmx.c from head and compiled for 9.2-RC3, setting mtu to 9000 works as expected :-) I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 VMware Software Switch. I've got a few performance things to still look at. What's the sysctl dev.vmx.X output for the if_vmx-if_vmx tests? Just repeated if_vmx simple iperf bench, results vary slightly from standard 10sec run to run, but still noticable high Intr usage: if_vmx - if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo - if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run was only 3.47GBits/sec in that case, took the numbers anyway) wbr, -Harry dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter dev.vmx.0.%driver: vmx dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0 dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad subdevice=0x07b0 class=0x02 dev.vmx.0.%parent: pci3 dev.vmx.0.ntxqueues: 1 dev.vmx.0.nrxqueues: 1 dev.vmx.0.collapsed: 0 dev.vmx.0.mgetcl_failed: 0 dev.vmx.0.mbuf_load_failed: 0 dev.vmx.0.txq0.ringfull: 133479 dev.vmx.0.txq0.offload_failed: 0 dev.vmx.0.txq0.hstats.tso_packets: 564986 dev.vmx.0.txq0.hstats.tso_bytes: 1686184580 dev.vmx.0.txq0.hstats.ucast_packets: 570604 dev.vmx.0.txq0.hstats.unicast_bytes: 1694679608 dev.vmx.0.txq0.hstats.mcast_packets: 0 dev.vmx.0.txq0.hstats.mcast_bytes: 0 dev.vmx.0.txq0.hstats.error: 0 dev.vmx.0.txq0.hstats.discard: 0 dev.vmx.0.txq0.debug.cmd_head: 106 dev.vmx.0.txq0.debug.cmd_next: 106 dev.vmx.0.txq0.debug.cmd_ndesc: 512 dev.vmx.0.txq0.debug.cmd_gen: 0 dev.vmx.0.txq0.debug.comp_next: 238 dev.vmx.0.txq0.debug.comp_ndesc: 512 dev.vmx.0.txq0.debug.comp_gen: 1 dev.vmx.0.rxq0.hstats.lro_packets: 0 dev.vmx.0.rxq0.hstats.lro_bytes: 0 dev.vmx.0.rxq0.hstats.ucast_packets: 579137 dev.vmx.0.rxq0.hstats.unicast_bytes: 38409312 dev.vmx.0.rxq0.hstats.mcast_packets: 0 dev.vmx.0.rxq0.hstats.mcast_bytes: 0 dev.vmx.0.rxq0.hstats.bcast_packets: 29 dev.vmx.0.rxq0.hstats.bcast_bytes: 1740 dev.vmx.0.rxq0.hstats.nobuffer: 0 dev.vmx.0.rxq0.hstats.error: 0 dev.vmx.0.rxq0.debug.cmd0_fill: 94 dev.vmx.0.rxq0.debug.cmd0_ndesc: 256 dev.vmx.0.rxq0.debug.cmd0_gen: 0 dev.vmx.0.rxq0.debug.cmd1_fill: 0 dev.vmx.0.rxq0.debug.cmd1_ndesc: 256 dev.vmx.0.rxq0.debug.cmd1_gen: 0 dev.vmx.0.rxq0.debug.comp_next: 94 dev.vmx.0.rxq0.debug.comp_ndesc: 512 dev.vmx.0.rxq0.debug.comp_gen: 0 dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter dev.vmx.0.%driver: vmx dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0 dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad subdevice=0x07b0 class=0x02 dev.vmx.0.%parent: pci3 dev.vmx.0.ntxqueues: 1 dev.vmx.0.nrxqueues: 1 dev.vmx.0.collapsed: 0 dev.vmx.0.mgetcl_failed: 0 dev.vmx.0.mbuf_load_failed: 0 dev.vmx.0.txq0.ringfull: 58950 dev.vmx.0.txq0.offload_failed: 0 dev.vmx.0.txq0.hstats.tso_packets: 230508 dev.vmx.0.txq0.hstats.tso_bytes: 4314020112 dev.vmx.0.txq0.hstats.ucast_packets: 235382 dev.vmx.0.txq0.hstats.unicast_bytes: 4356943552 dev.vmx.0.txq0.hstats.mcast_packets: 0 dev.vmx.0.txq0.hstats.mcast_bytes: 0 dev.vmx.0.txq0.hstats.error: 0 dev.vmx.0.txq0.hstats.discard: 0 dev.vmx.0.txq0.debug.cmd_head: 333 dev.vmx.0.txq0.debug.cmd_next: 333 dev.vmx.0.txq0.debug.cmd_ndesc: 512 dev.vmx.0.txq0.debug.cmd_gen: 0 dev.vmx.0.txq0.debug.comp_next: 376 dev.vmx.0.txq0.debug.comp_ndesc: 512 dev.vmx.0.txq0.debug.comp_gen: 0 dev.vmx.0.rxq0.hstats.lro_packets: 0 dev.vmx.0.rxq0.hstats.lro_bytes: 0 dev.vmx.0.rxq0.hstats.ucast_packets: 255918 dev.vmx.0.rxq0.hstats.unicast_bytes: 17043918 dev.vmx.0.rxq0.hstats.mcast_packets: 0 dev.vmx.0.rxq0.hstats.mcast_bytes: 0 dev.vmx.0.rxq0.hstats.bcast_packets: 15 dev.vmx.0.rxq0.hstats.bcast_bytes: 900 dev.vmx.0.rxq0.hstats.nobuffer: 0 dev.vmx.0.rxq0.hstats.error: 0 dev.vmx.0.rxq0.debug.cmd0_fill: 121
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime): ... It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo frames with vmxnet3. This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ Thanks a lot for your ongoing work! I can confirm that with recent if_vmx.c from head and compiled for 9.2-RC3, setting mtu to 9000 works as expected :-) I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 VMware Software Switch. I've got a few performance things to still look at. What's the sysctl dev.vmx.X output for the if_vmx-if_vmx tests? Just repeated if_vmx simple iperf bench, results vary slightly from standard 10sec run to run, but still noticable high Intr usage: The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. if_vmx - if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo - if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run was only 3.47GBits/sec in that case, took the numbers anyway) wbr, -Harry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime): Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) Hello Bryan, thanks a lot for your hard work! It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo frames with vmxnet3. This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 VMware Software Switch. I've got a few performance things to still look at. What's the sysctl dev.vmx.X output for the if_vmx-if_vmx tests? Simple iperf (standard TCP) results: vmxnet3jumbo - vmxnet3jumbo 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr vmxnet3 - vmxnet3 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr if_vmx - if_vmx 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr !!! if_vmxjumbo - if_vmxjumbo not possible if_em(e1000) - if_em(e1000) 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr if_em(e1000)jumbo - if_em(e1000)jumbo 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr if_igb(e1000e) - if_igb(e1000e) 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096 4.81 Gbits/s, load: 65%Sys 0.5%Intr Conclusion: if_vmx performs well compared to the regular emulated nics and standard MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 performance with regular mtu. If one needs throughput, the missing jumbo frame support in if_vmx is a show stopper. e1000e is preferable over e1000, even if not officially choosable with FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev = e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf, although the driver e1000e attaches is if_igb!) Thanks, -Harry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime): Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) Hello Bryan, thanks a lot for your hard work! It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo frames with vmxnet3. I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi 5.1U1 and FreeBSD-9.2-RC2 Two guests are connected to one MTU9000 VMware Software Switch. Simple iperf (standard TCP) results: vmxnet3jumbo - vmxnet3jumbo 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr vmxnet3 - vmxnet3 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr if_vmx - if_vmx 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr !!! if_vmxjumbo - if_vmxjumbo not possible if_em(e1000) - if_em(e1000) 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr if_em(e1000)jumbo - if_em(e1000)jumbo 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr if_igb(e1000e) - if_igb(e1000e) 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096 4.81 Gbits/s, load: 65%Sys 0.5%Intr Conclusion: if_vmx performs well compared to the regular emulated nics and standard MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 performance with regular mtu. If one needs throughput, the missing jumbo frame support in if_vmx is a show stopper. e1000e is preferable over e1000, even if not officially choosable with FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev = e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf, although the driver e1000e attaches is if_igb!) Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: [CFT] VMware vmxnet3 ethernet driver
On 8/6/13 6:52 AM, Bryan Venteicher wrote: - Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; there was a compiler warning of a silly bug like: if (foo) ; do_something(); vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. it'd be nice if we could get vmware to just support the drivers in tree.. by which I mean, just submit patches.. why do they need to have it out of tree? [1] - http://ogris.de/vmware/ -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - it'd be nice if we could get vmware to just support the drivers in tree.. by which I mean, just submit patches.. why do they need to have it out of tree? I agree. But they are all unfriendly licensed. The FF had a discussion to get them relicensed to something more suitable, but that went no where over the past year. It is unfortunate this vendor supplied, out of tree driver, issue is still around. Linux should have taught companies how foolish this is. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD specific issue of the busted timer that was fixed. But they've less helpful in other regards, and have more or less said FreeBSD isn't high in their priority because it isn't Linux. Are you aiming at completely replacing VMware tools, or just the device drivers? I'd like as much as possible to work out of the box. vmxnet3 is as far as my current interests go. OpenBSD has a vmt device that apparently does (at least the important bits of) what vmtoolsd does; I'll look at that closer at some point. I have no intention of preventing people from using VMware's tools if they desire, nor breaking existing users. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
6 aug 2013 kl. 08:05 skrev Bryan Venteicher bry...@daemoninthecloset.org: - Original Message - Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Yes, it is not a blackhole of support. At $JOB, we got caught by the FreeBSD specific issue of the busted timer that was fixed. But they've less helpful in other regards, and have more or less said FreeBSD isn't high in their priority because it isn't Linux. Are you aiming at completely replacing VMware tools, or just the device drivers? I'd like as much as possible to work out of the box. vmxnet3 is as far as my current interests go. OpenBSD has a vmt device that apparently does (at least the important bits of) what vmtoolsd does; I'll look at that closer at some point. Cool. I didn't know about vmt. I read the CVS log in the OpenBSD tree and it actually seems to do most of what I need. Having all this working out of the box (without VMware Tools installed) would be most welcome. …but I guess VMware would consider this an unsupported configuration or something like that, which sucks if/when I need to contact their support. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
On Sun, Aug 04, 2013 at 07:12:17PM -0500, Bryan Venteicher wrote: Hi, I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a lot of cleanup, bug fixes, new features, etc (+2000 new lines) along the way so there is not much of a resemblance left. The driver is in good enough shape I'd like additional testers. A patch against -CURRENT is at [1]. Alternatively, the driver and a Makefile is at [2]; this should compile at least as far back as 9.1. I can look at 8-STABLE if there is interest. Obviously, besides reports of 'it works', I'm interested performance vs the emulated e1000, and (for those using it) the VMware tools vmxnet3 driver. Hopefully it is no worse :) I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
- Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; there was a compiler warning of a silly bug like: if (foo) ; do_something(); vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences. [1] - http://ogris.de/vmware/ -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] VMware vmxnet3 ethernet driver
On Mon, Aug 05, 2013 at 05:52:01PM -0500, Bryan Venteicher wrote: - Original Message - I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the VMware tools package from VMware. Everything has been running great for years. (we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the VMware tools driver or the emulated e1000? They are out of tree and subject to rotting. I had to use the patches at [1] to even get them to compile on 9.1 and -current. I don't think VMware puts much engineering resources behind it; Perhaps not, but they do support FreeBSD. I've started several support cases with FreeBSD-specific problems and they've fixed all so far. Are you aiming at completely replacing VMware tools, or just the device drivers? -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
