This change modifies quinn-proto to allow callers to submit a list
of one or more owned `Bytes` chunks for transmission instead of
pure byte slices. This will provide a more efficient zero-copy
interface for applications which already make use of owned
`Bytes` buffers.
The internals of quinn-proto have been refactored in order to keep
the ability to pass `&[u8]` buffers and defer the conversion into
`Bytes` as long as possible, in order to avoid unnecessary allocations
if no data can be stored due to flow control.
Since the loop was not exited after a close frame was transmitted,
other data in the same space could have been transmitted after
the frame. This adds a `break` to fix this.
The TestEndpoint so far tried to send a single big datagram instead of using
proper GSO sending to emit multiple datagrams.
In order to avoid relying on platform GSO support, this change will simply
split up GSO transmissions into multiple Transmits in the endpoint.
This change implements an initial version of GSO support [1][2][3]
for Linux, which improves the effiency of sending data.
The approach taken in this change is to create a buffer which contains
multiple datagrams in `Connection::poll_transmit`. This was picked
over trying to merge packets in the endpoint task, since packets
seem to need to be padded to a common segment size in order to
make them sendable via GSO.
In order to to this in an efficient fashion, the `poll_transmit`
method was restructred. Instead of selecting spaces upfront, it
will now loop through all possible packet spaces, check if there is
pending data to send and create packets and datagrams out of this.
The last packet which was written to a datagram buffer is not
finalized until it is clear whether follow-up packets need to be
written, since we need to know whether this packet should get padded
to MTU length or not.
This change doesn't enable GSO yet, since it will only produce a
single datagram. I will create a separate change for this.
Performance measurements:
**No GSO:**
```
Sent 1073741824 bytes on 1 streams in 4.31s (237.66 MiB/s)
```
**With GSO (up to 8 packets):**
```
Sent 1073741824 bytes on 1 streams in 3.02s (339.18 MiB/s)
```
[1] http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-paper-DRAFT-1.pdf
[2] http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-presentation-20181104.pdf
[3] https://lwn.net/Articles/752956/
This change defers padding packets as a runtime decision
while the packet is populated.
For individual packets, we store in `SentFrames` whether a padding is
required. If padding is required a `min_datagram_size` variable is
increased, which will later on assure that only the last packet in a
datagram gets padded.
Dirkjan Ochtman