Draft
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds support for virtio-net headers in VM networking by introducing a new vnet_hdr flag. This flag enables proper handling of segmentation offload for containers running with their own network namespace and veth pairs, where unsegmented packets would otherwise be dropped by the kernel.
Key changes:
- Adds a new
vnet_hdrboolean field to control virtio-net header inclusion - Introduces network flag constants to replace magic numbers
- Updates documentation to describe the new optional field
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| internal/shim/task/networking_unix.go | Adds vnet_hdr field and flag constant, updates parsing and flag handling logic |
| docs/vm-networking.md | Documents the new vnet_hdr optional field |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
4b8398f to
fbdd137
Compare
When segmentation offload is enabled, and unsegmented packets are sent to a VM (i.e. when running a container in the root netns), the kernel will detect that packets are larger than expected and proceed. That's not the case for containers (i.e. when running a container with its own netns, and a veth pair). In that case, packets reach the virtio-net interface, are forwarded to the bridge, and then to the appropriate veth. Unsegmented packets with GSO fields unset are dropped by the kernel either at the bridge or at the veth level. That may be due to the current network topology where the vnet interface is attached to a bridge. In that case, we need to tell libkrun that the network backend sends / receives virtio_net_hdr structs with the packets, and the backend need to preserve GSO fields for VM-to-VM connections, or populate them for host-to-VM connections. Signed-off-by: Albin Kerouanton <albin.kerouanton@docker.com>
fbdd137 to
f5f3bb5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When segmentation offload is enabled, and unsegmented packets are sent to a VM (i.e. when running a container in the root netns), the kernel will detect that packets are larger than expected and proceed.
That's not the case for containers (i.e. when running a container with its own netns, and a veth pair). In that case, packets reach the virtio-net interface, are forwarded to the bridge, and then to the appropriate veth.
Unsegmented packets with GSO fields unset are dropped by the kernel either at the bridge or at the veth level. That may be due to the current network topology where the vnet interface is attached to a bridge.
In that case, we need to tell libkrun that the network backend sends / receives virtio_net_hdr structs with the packets, and the backend need to preserve GSO fields for VM-to-VM connections, or populate them for host-to-VM connections.