quinn_proto example with io_uring

[espoal]

Dear all,

I'm writine some io_uring examples in rust, and I would like to add QUIC. The idea is to try and benchmark some advanced options like batching, zero copy, AF_XDP, eBPF, ....

I guess my best option is to try quinn-proto, as it's advertised for custom event loops. Is there any example, maybe in the tests, maybe a simplified one? Do you think it's doable?

Any advice is welcome, before I will try to dive in the codebase :)

[djc]

Would be great to have this! I think the cool version of this in 0.9 would be to try to implement quinn::AsyncUdpSocket on top of io_ring, but just basic quinn-proto would be nice to. I guess it should be doable? Would be interesting to find out where you hit any snags.

I'd particularly love an implementation on top of tokio-uring.

[Ralith]

If you do go with quinn-proto, the discussion on using it in https://github.com/quinn-rs/quinn/issues/1441 may be helpful. The async interface is a lot more ergonomic, but may be harder to demonstrate interesting performance results with.

[espoal]

@djc At some point we will for sure have an implementation in tokio uring, but before that we need to analyze all the io_uring options and decide which opcodes needs to be implemented in tokio. E.g.: Zero copy? It reduces memory bandwidth usage but also increases latency on big packets. Sqpoll? again it reduces CPU usage but increases latency. And many other options to test. My goal for now is to do a very simple implementation, like this one, that will allow us to have a clearer picture on what are the best practices.

I gave a quick look to quinn::AsyncUdpSocket but still I can't visualize how would I plug it in io_uring. With uring I can read/recv packets, how would I pass them to quinn::AsyncUdpSocket?

@Ralith , thank you for the link that's what I needed, I will try to follow it and then I will make more questions :) Maybe I could build a plain UDP server with all the configuration options, and then ask again for your help. If I understood correctly, I should use quinn_proto::Endpoint::handle with the data I receive from the socket, and then the library will do its magic somehow :D (more investigation needed)

Some more questions:

• is there a difference for QUIC if I use read/write or send/recv?

[Ralith]

QUIC needs a bunch of advanced socket functionality to get optimal behavior out of UDP. In the conventional API, this is only possible using the sendmsg family of functions. See quinn-udp/src/unix.rs for examples. I'm not familiar with the specifics of the operations supported by io_uring, but I'd guess there's a similar distinction there.

[Icelk]

Something like this seems feasible. We can actually also send headers to the syscall. It'd however require tokio-uring to open up it's API, so we can send headers.

Then, there's also the problem of tokio-uring giving an opaque future, while we expect poll methods. I guess we'll have to make a generic struct which stores the active future?