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

Support for sending raw Ethernet frames #638

Open
jamwaffles opened this issue Feb 13, 2024 · 3 comments
Open

Support for sending raw Ethernet frames #638

jamwaffles opened this issue Feb 13, 2024 · 3 comments

Comments

@jamwaffles
Copy link

I'm looking at using glommio for its io_uring support with ethercrab which sends raw Ethernet II frames containing a custom protocol. It currently uses smol::Async with an AsFd/AsRawFd handle. Is there either

a. currently a way to use glommio to send raw Ethernet frames using this FD handle or
b. something you'd consider adding?

I'd be happy to help with a PR for the latter but could use some guidance on the implementation.

If this doesn't fit the design goals of glommio I'm happy to close this issue and go my own way but I thought I'd ask here first :)

@glommer
Copy link
Collaborator

glommer commented Feb 14, 2024

I am not very familiar with raw ethernet. From the io_uring's point of view, what is it exactly that is needed?
To the best of my knowledge, io_uring itself will operate in a much higher level at the socket layer, no?

@jamwaffles
Copy link
Author

Because I have a RawFd, I can use that pretty much directly with io_uring. I wrote a quick blocking test which kind of works. The bit I'm stuck on is making it async. I figured glommio might have some prior art in this area I could build on top of.

So I guess to alter my original question a bit: can I read/write a RawFd (or OwnedFd or whatever) with glommio? If not, where could I look in the codebase for inspiration? The FD I'm using just happens to be hooked up to tx/rx raw ethernet packets but from io_uring's perspective it's just data.

@glommer
Copy link
Collaborator

glommer commented Feb 14, 2024

The way I would do this, is at the sys/uring.rs level, try our best to either reuse the existing functions (open_at and one of the read/writes should work?), and if changes are made, try to make it in a way that we don't have special reads and writes just for that.

But at the API level (src/io), then have a specialized API that deals with raw file descriptors and keep as high level, specialized, and hard to misuse as possible (I wouldn't go as far as specializing to ethernet frames, but certainly to a rawfd - but that's mostly because I don't understand ethernet well, and don't see any benefit)

I don't think this exists today, so you'd have to add it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants