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

Implement kernel-level software timestamping #14

Closed
davidv1992 opened this issue Apr 5, 2022 · 2 comments
Closed

Implement kernel-level software timestamping #14

davidv1992 opened this issue Apr 5, 2022 · 2 comments

Comments

@davidv1992
Copy link
Member

We need some way to have software timestamping work with tokio in a proper way. Would prefer to have thin unsafe wrappers for the system calls in separate crates, prefer also to have few dependencies (this shouldn't be too much code, and it is probably better to own it ourselves than have a dependency on something like nix, libc is acceptable though in my view)

@rnijveld
Copy link
Member

rnijveld commented Apr 6, 2022

I've been looking at a way to get this implemented.

Setting the right flags shouldn't be much trouble using the RawFd and a few basic libc calls, but reading the ancillary messages for the actual time stamp data is a bigger issue. Tokio doesn't implement it right now, although there have been some mentions (e.g. tokio-rs/tokio#799). The most recent mention I could find (tokio-rs/tokio#2975) suggests waiting for an std implementation (rust-lang/rust#76915), but it looks like that will still take quite a lot of work to get somewhere.

I think our current best bet is to go with implementing our own recvmsg with AsyncFd to detect socket reading readiness. That would require us implementing our own parsing of ancillary control messages (for examples look at std or the recvmsg code in nix). That seems doable given our limited use-case, although it will require a good chunk of unsafe code because of all the pointer arithmetic involved.

@djc
Copy link

djc commented Apr 6, 2022

Might be useful to look at quinn-udp which I think has similar concerns (though for UDP sockets).

https://github.com/quinn-rs/quinn/tree/main/quinn-udp/src

folkertdev pushed a commit that referenced this issue Nov 16, 2023
Expanded readme to better introduce current state of project.
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

3 participants