| 2a87457c | 20-Jun-2014 |
Bryan Venteicher <[email protected]> |
Increment the pending packets more aggressively for TSO
Assume the number of description used is reasonable value to
increment this otherwise opaque field by.
While here, reduce a minor difference
Increment the pending packets more aggressively for TSO
Assume the number of description used is reasonable value to
increment this otherwise opaque field by.
While here, reduce a minor difference between the legacy and
multiqueue transmit paths.
MFC after: 1 week
show more ...
|
| 1204e374 | 20-Jun-2014 |
Bryan Venteicher <[email protected]> |
Handle multiple calls to rxq_eof for single packet completion
This requires the VMware vmxnet3 device to flip the start of packet
descriptor's generation before the rest of the packet's descriptors
Handle multiple calls to rxq_eof for single packet completion
This requires the VMware vmxnet3 device to flip the start of packet
descriptor's generation before the rest of the packet's descriptors
have been loaded into the Rx ring. I've never observed this behavior,
and it seems to make the most sense not to do it this way. But it is
not a lot of work for the driver to handle this situation just in case.
MFC after: 1 week
show more ...
|
| e41318fc | 09-Jun-2014 |
Bryan Venteicher <[email protected]> |
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 checksu
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
show more ...
|