Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set correctly the offload flags of TAP device based on feature negotiation with the guest #4659

Open
roypat opened this issue Jul 1, 2024 · 2 comments
Assignees
Labels
Good first issue Indicates a good issue for first-time contributors Status: Parked Indicates that an issues or pull request will be revisited later

Comments

@roypat
Copy link
Contributor

roypat commented Jul 1, 2024

Firecracker networking relies on virtio-net [1] virtualized ethernet cards, backed by TAP devices on the host. Both TAP and virtio-net support several offloading features [1][2]. In order for these to play correctly together, each offloading feature needs to be supported by both the guest driver and the TAP device on the host.

The Linux virtio-net driver always (at least in the configuration we use it) supports the same offloading features the TAP devices does. As a result, during device initialization, Firecracker informs the guest about the offloads that are possible (the ones supported by the TAP device) and configures the TAP device to use them trusting that the driver will also support the same features.

However, other operating systems, such as FreeBSD might make other decisions (see also #3905). Moreover, Linux in the future might decide that (at least in some cases) will not support.

We should fix the Firecracker virtio-net implementation to validate that the features it offered to the guest are actually supported by the driver and only configure the TAP device with the subset of the features that the driver acknowledged.

  • Change the functionality of virtio-net device to do the right thing
  • Add a unit-test that ensures we set the correct features to the TAP device

These is some preliminary work in #4386 on which a PR could be based

@roypat roypat added Good first issue Indicates a good issue for first-time contributors Status: Parked Indicates that an issues or pull request will be revisited later labels Jul 1, 2024
@yuluo-zy
Copy link

yuluo-zy commented Jul 3, 2024

I think I can try this question!!

@roypat
Copy link
Contributor Author

roypat commented Jul 4, 2024

Hi @yuluo-zy,
that sounds awesome, feel free to have a stab at it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Indicates a good issue for first-time contributors Status: Parked Indicates that an issues or pull request will be revisited later
Projects
None yet
Development

No branches or pull requests

2 participants