quinn_proto example with io_uring about quinn

[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 #1441 may be helpful. The async interface is a lot more ergonomic, but may be harder to demonstrate interesting performance results with.

[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.

[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?

[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?