vmx driver when used in windows vmware player is not sending packets when tso mode (default) is enabled on interface. because probably not all packets are tso offloaded networking seems to work if you send packets occasionally - such as ssh. packets starts to drop if you send larger file for example ftp upload. increasing hw.vmx.txndesc did not improved situation Fix: ifconfig vmx0 -tso id would be good to have errata notice for this bug for 10.0 How-To-Repeat: get vmware player, install bsd into it, change network driver to vmx0, upload some file to ftp server, then look at netstat -s you will get massive amount of resent packets.
Responsible Changed From-To: freebsd-bugs->freebsd-emulation reclassify.
Responsible Changed From-To: freebsd-emulation->bryanv
State Changed From-To: open->feedback There's recenlty been several TSO related fixes to both the stack and several drivers. I MFC'ed the relevant changes to vmx in 10-STABLE with r264866. If you're not using vlan or lagg, I believe that will sufficient to fix this. If you're still able to recreate this, please provide the output of `netstat -I vmxX -idb` and `sysctl dev.vmx`.
yes, i am still able to reproduce this on today 10-STABLE netstat -I vmx0 -idb Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll Drop vmx0 1500 <Link#1> 00:0c:29:97:76:85 20552 0 0 27298216 12571 0 2655787 0 0 vmx0 - fbsd9.localdo 2001:470:6f:4af:: 14 - - 3315 6 - 476 - - vmx0 - fe80::20c:29f fe80::20c:29ff:fe 1 - - 72 100 - 7816 - - vmx0 - 10.0.0.0 fbsd9 20306 - - 26980347 12445 - 2338055 - - sysctl dev.vmx 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=0x020000 dev.vmx.0.%parent: pci3 dev.vmx.0.max_ntxqueues: 2 dev.vmx.0.max_nrxqueues: 2 dev.vmx.0.ntxqueues: 1 dev.vmx.0.nrxqueues: 1 dev.vmx.0.defragged: 0 dev.vmx.0.defrag_failed: 0 dev.vmx.0.mgetcl_failed: 0 dev.vmx.0.mbuf_load_failed: 0 dev.vmx.0.txq0.opackets: 12653 dev.vmx.0.txq0.obytes: 2693446 dev.vmx.0.txq0.omcasts: 112 dev.vmx.0.txq0.csum: 11700 dev.vmx.0.txq0.tso: 247 dev.vmx.0.txq0.ringfull: 0 dev.vmx.0.txq0.offload_failed: 0 dev.vmx.0.txq0.hstats.tso_packets: 568 dev.vmx.0.txq0.hstats.tso_bytes: 784203 dev.vmx.0.txq0.hstats.ucast_packets: 12851 dev.vmx.0.txq0.hstats.unicast_bytes: 2699418 dev.vmx.0.txq0.hstats.mcast_packets: 112 dev.vmx.0.txq0.hstats.mcast_bytes: 10368 dev.vmx.0.txq0.hstats.error: 0 dev.vmx.0.txq0.hstats.discard: 0 dev.vmx.0.txq0.debug.cmd_head: 462 dev.vmx.0.txq0.debug.cmd_next: 462 dev.vmx.0.txq0.debug.cmd_ndesc: 1024 dev.vmx.0.txq0.debug.cmd_gen: 1 dev.vmx.0.txq0.debug.comp_next: 373 dev.vmx.0.txq0.debug.comp_ndesc: 1024 dev.vmx.0.txq0.debug.comp_gen: 1 dev.vmx.0.rxq0.ipackets: 20633 dev.vmx.0.rxq0.ibytes: 27319480 dev.vmx.0.rxq0.iqdrops: 0 dev.vmx.0.rxq0.ierrors: 0 dev.vmx.0.rxq0.hstats.lro_packets: 0 dev.vmx.0.rxq0.hstats.lro_bytes: 0 dev.vmx.0.rxq0.hstats.ucast_packets: 20606 dev.vmx.0.rxq0.hstats.unicast_bytes: 27399191 dev.vmx.0.rxq0.hstats.mcast_packets: 0 dev.vmx.0.rxq0.hstats.mcast_bytes: 0 dev.vmx.0.rxq0.hstats.bcast_packets: 17 dev.vmx.0.rxq0.hstats.bcast_bytes: 2123 dev.vmx.0.rxq0.hstats.nobuffer: 0 dev.vmx.0.rxq0.hstats.error: 0 dev.vmx.0.rxq0.debug.cmd0_fill: 154 dev.vmx.0.rxq0.debug.cmd0_ndesc: 1024 dev.vmx.0.rxq0.debug.cmd0_gen: 0 dev.vmx.0.rxq0.debug.cmd1_fill: 0 dev.vmx.0.rxq0.debug.cmd1_ndesc: 1024 dev.vmx.0.rxq0.debug.cmd1_gen: 0 dev.vmx.0.rxq0.debug.comp_next: 155 dev.vmx.0.rxq0.debug.comp_ndesc: 2048 dev.vmx.0.rxq0.debug.comp_gen: 1 dev.vmx.0.wake: 0 =
A commit references this bug: Author: bryanv Date: Mon Jun 9 02:45:54 UTC 2014 New revision: 267253 URL: http://svnweb.freebsd.org/changeset/base/267253 Log: Fix TSO support on VMware Fusion Apparently for VMware Fusion (and presumably VMware Workstation/Player since the PR states TSO is broken there too, but I cannot test), the TCP header pseudo checksum calculated should only include the protocol (IPPROTO_TCP) value, not also the lengths as the stack does instead. VMware ESXi seems to ignore whatever value is in the TCP header checksum, and it is a bit surprising there is a different behavior between the VMware products. And it is unfortunate that on ESXi we are forced to do this extra bit of work. PR: kern/185849 MFC after: 3 days Changes: head/sys/dev/vmware/vmxnet3/if_vmx.c
You cant detect ESXi vs VMWare workstation in driver?
Nothing in the shared data between the driver and the host identifies the type or version of host. None of the smbios stuff looks unique. This is a bit annoying for multiple queues as well: the host does not provide the maximum number of Rx queues it supports, so (if MQ is enabled), we will setup multiple Rx queues but VMware Fusion (and probably Workstation too) will only use the first one.
MFC'd to 10-STABLE in r267382.