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

[net] Introduce abstractions for the New API (NAPI) #1018

Draft
wants to merge 1 commit into
base: rust
Choose a base branch
from

Conversation

Lymkwi
Copy link

@Lymkwi Lymkwi commented Jun 27, 2023

(patch note below)

Hi again,
This is more of the code I wrote for UDP tunneling, as mentioned in #1014 . Once again, I don't think it is worth being sent to the Rust mailing list until we've got kernel::net in mainline, to avoid potential conflicts (and because I still need some ground work for this whole thing, even if it is only the existence of Device).

These abstractions should be enough to write a driver that can at least run a polling function and send socket buffers off into the GRO while checking return states (at least it was enough for mine). That seems to cover most use cases I observed, but there is clearly not everything (for example, I do not have a function to remove the NAPI from its Device yet).

As a side note, everything is in kernel::net::gro, because the header defining all of the structures and methods is include/net/gro.h, so it made sense to me to keep the association between NAPI and GRO in Rust.

EDIT: I'll take a look at why CI fails; I will be honest I was not expecting it to happen Missed a bindings helper header when stripping and testing the code, should be fixed now


This patch introduces the necessary abstractions to declare, attach, and schedule (as well as prepare the scheduling of) NAPI structures. The NAPI mechanism is necessary to write network device drivers, especially because they help handle passing socket buffers to the Generic Receiver Offload (GRO) mechanism.

Rust drivers can implement the net::gro::NapiPoller trait over a type which implements their polling function. Afterwards, a NAPI can be tied to a device with the polling function by calling net::Device::napi_add with a type argument implementing the corresponding NapiPoller trait, as well as a regular argument giving a reference to the NAPI structure used by the network driver.

This patch introduces the necessary abstractions to declare, attach, and
schedule (as well as prepare the scheduling of) NAPI structures. The
NAPI mechanism is necessary to write network device drivers, especially
because they help handle passing socket buffers to the Generic Receiver
Offload (GRO) mechanism.

Rust drivers can implement the `net::gro::NapiPoller` trait over a type
which implements their polling function. Afterwards, a NAPI can be tied
to a device with the polling function by calling `net::Device::napi_add`
with a type argument implementing the corresponding `NapiPoller` trait,
as well as a regular argument giving a reference to the NAPI structure
used by the network driver.

Signed-off-by: Amélie Gonzalez <lymkwi@vulpinecitrus.info>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant