proto: write outgoing packets to caller-supplied memory

[Ralith]

Connection::poll_transmit allocates and immediately returns a Vec<u8>. There's no reason it couldn't instead take a &mut [MaybeUninit<u8>] or similar, giving the caller much greater flexibility to reduce allocations/copies, particularly when working with e.g. registered io_uring buffers.

[lmpn]

This PR #1545 seems to have addressed this issue

[Ralith]

It has not; refer to the signature of Connetion::poll_transmit.

[lmpn]

I'm giving it a try 👍

[cameronelliott]

Just surfing by, and saw this.
I'm just going to dump my two cents for what it's worth.
Please ignore if it is not relevant for you.

This type of issue is super important for io_uring, AF_XDP, DPDK, (Networking APIs to get to 100Gbits/sec++)

Actually to take Quinn or any Rust Quic stack to the next level the whole RX & TX hot paths should be allocation-free except by the consumer of the Quic stack.

It would be great to have a Rust Quic stack that allows caller-supplied buffers for both the RX & TX paths, and is allocation-free on the hot path.
(When I say RX, I mean the post-decryption RX destination, a sans-io Quic has the caller do the raw RX)

[Ralith]

This was fixed by @lmpn's generous contribution in #1697.

I mean the post-decryption RX destination

We already decrypt in-place in caller-supplied memory, and only alloc/copy on the receive path when needed to reduce memory usage. Memory allocation is not currently a bottleneck for Quinn; if you want to hit massive throughput, parallelism and encryption are your main bottlenecks. If you're interested in hitting demanding performance targets with Quinn, feel free to open a new issue to discuss any obstacles you encounter.