virtio/net/unixgram: handle ENOBUFS on macOS by retrying#556
virtio/net/unixgram: handle ENOBUFS on macOS by retrying#556nirs wants to merge 1 commit intocontainers:mainfrom
Conversation
When running iperf3 with gvproxy, krunkit breaks quickly with:
[2026-02-19T02:53:41Z ERROR devices::virtio::net::worker] Failed to process rx:
Backend(Internal(ENOBUFS)) (triggered by backend socket readable)
macOS returns ENOBUFS when the kernel socket buffer is full, rather
than blocking or returning EAGAIN. The kernel does not provide any
readiness notification for this condition, so the only recovery is
to retry the send.
Map ENOBUFS to WriteError::NothingWritten so the caller retries the
frame instead of treating it as a fatal error.
Assisted-by: Cursor/Claude Opus 4.6
Signed-off-by: Nir Soffer <nirsof@gmail.com>
nirs
requested review from
MatiasVara,
dorindabassey,
jakecorrenti,
mtjhrc,
slp and
tylerfanelli
as code owners
Summary of ChangesHello @nirs, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical network stability and performance issue on macOS when using Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly handles the ENOBUFS error on macOS for unixgram sockets by mapping it to WriteError::NothingWritten, which allows the caller to retry sending the frame. This prevents a fatal error when the kernel socket buffer is full. I've added one suggestion to also handle EAGAIN and EWOULDBLOCK in the same way to improve portability and make the error handling more robust across different Unix-like systems.
| // macOS returns ENOBUFS when the kernel socket buffer is full, | ||
| // rather than blocking or returning EAGAIN on non-blocking sockets. | ||
| // The only way to recover is to retry the send; the kernel does not | ||
| // provide any readiness notification for this condition. | ||
| // vmnet-helper handles this with a 50us sleep between retries, | ||
| // and typically one retry is enough: | ||
| // https://github.com/nirs/vmnet-helper/blob/455d172/helper.c#L42 | ||
| Err(nix::Error::ENOBUFS) => { | ||
| return Err(WriteError::NothingWritten); | ||
| } |
There was a problem hiding this comment.
While handling ENOBUFS is correct for macOS, for better portability it's a good practice to also handle EAGAIN and EWOULDBLOCK. These errors can be returned on other Unix-like systems (e.g., Linux) for non-blocking sockets when the send buffer is full. Handling them will make the implementation more robust.
You can use an or-pattern to match all three errors. I've also updated the comment to reflect this change.
| // macOS returns ENOBUFS when the kernel socket buffer is full, | |
| // rather than blocking or returning EAGAIN on non-blocking sockets. | |
| // The only way to recover is to retry the send; the kernel does not | |
| // provide any readiness notification for this condition. | |
| // vmnet-helper handles this with a 50us sleep between retries, | |
| // and typically one retry is enough: | |
| // https://github.com/nirs/vmnet-helper/blob/455d172/helper.c#L42 | |
| Err(nix::Error::ENOBUFS) => { | |
| return Err(WriteError::NothingWritten); | |
| } | |
| // On macOS, ENOBUFS is returned when the kernel socket buffer is full. | |
| // On other systems, EAGAIN or EWOULDBLOCK can be returned. | |
| // In all cases, we should retry the send. The kernel does not | |
| // provide any readiness notification for this condition. | |
| // | |
| // Ref: https://github.com/nirs/vmnet-helper/blob/455d172/helper.c#L42 | |
| // | |
| #[allow(unreachable_patterns)] | |
| Err(nix::Error::ENOBUFS) | Err(nix::Error::EAGAIN) | Err(nix::Error::EWOULDBLOCK) => { | |
| return Err(WriteError::NothingWritten); | |
| } |
There was a problem hiding this comment.
@gemini-code-assist This code is macOS only so EAGAIN or EWOULDBLOCK are not relevant.
1 participant
When running iperf3 with gvproxy, krunkit breaks quickly with:
macOS returns ENOBUFS when the kernel socket buffer is full, rather than blocking or returning EAGAIN. The kernel does not provide any readiness notification for this condition, so the only recovery is to retry the send.
Map ENOBUFS to WriteError::NothingWritten so the caller retries the frame instead of treating it as a fatal error.
Test results
Tested using vmnet-helper and gvproxy using:
With vmnet-helper we get consistent performance in both direction (20.14-23.67 Gbits/s). With gvproxy we get higher bandwidth from vm to host (28 Gbits/s) but very low bandwidth from host to vm (0.69 Gbits/s).
Note
Without this change we cannot test performance, stress test breaks in few seconds.
Using gvproxy from containers/gvisor-tap-vsock#613.
Fixes #555