In vde_switch retry send() when it returns ENOBUFS on Darwin and FreeBSD #35
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On these platforms ENOBUFS can be returned by send() even on blocking sockets.
I've done throughput testing with Lima on macOS (uses a qemu VM under the hood), downloading a 4GB ISO (hosted by Apache on the host) over various interfaces, writing to /dev/null.
Using vde_switch and vde_vmnet it takes about 75min.
With the patch in this PR (and a similar one to vde_vmnet) it takes about 90s.
Over the qemu slirp interface it takes 13s.
Directly on the host it takes less than 3s.
It is not clear to me why vde_switch & vde_vmnet are still so much slower than slirp, but that will be a separate investigation.
Fixes #19
Fixes https://bugs.launchpad.net/qemu/+bug/1861875
cc/ @AkihiroSuda
Related downstream issues:
lima-vm/vde_vmnet#19
rancher-sandbox/rancher-desktop#1070