Benjamin Saunders

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

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

> have been thrilled with how easy it's been to get up and going with Quinn's nice API. Glad to hear it! > Our scenario is small packets sent by...

Quinn supports the multithreaded runtime well, and already uses channels to communicate between tasks. Depending on exact workload, you may see better performance in different configurations. If you'd like help...

> If you are interested we could wrote and propose a PR to add support for Datagram in perf_client and perf_server allowing benchmarking Stream or Datagram or a mix of...

It looks like you're sending datagrams as fast as possible? That will always lead to many dropped datagrams; it's the intended behavior. The purpose of pacing is to avoid overwhelming...

That would have limited usefulness because in practice, the local QUIC stack's buffer is not the bottleneck; you should be far more concerned about packets being dropped by a router...

Marginal differences in latency over loopback are not meaningful, so this data doesn't say much. What type of performance is your actual application concerned about? Note io_uring is unlikely to...

> This latency diffs is not marginal for me What is your application such that the difference between e.g. 76us ±31.328 and 72us ±30.648 matters? Note the variance is much...

The last two results show a 7μs difference with about the same variance; those are still very close. Latencies at that scale are going to be very sensitive to the...