Summary:
As it turns out, the extra indirection from storing a unique_ptr is not worse than the gain from using an `F14ValueMap` versus an `F14VectorMap`.
This reduces the `find` cost measurably in profiles, and doesn't appear to have any real negative effects otherwise.
Reviewed By: yangchi
Differential Revision: D20923854
fbshipit-source-id: a75c4649ea3dbf0e6c89ebfe0d31d082bbdc31fd
Summary: This isn't a huge source of cycles, but the flushing of the cache does show up in tperf. Turns out this is very easy to do, and exposed another minor problem which is that we were misusing `clear()` on the `IOBufQueue`. Instead we should have been using `move()` to reset it to being empty.
Reviewed By: siyengar
Differential Revision: D18758922
fbshipit-source-id: 6dcbc29e8bebd93b5787939176799e3df90ed94d
Summary:
The retransmission buffer tracks stream frame data we have sent that is currently unacked. We keep this as a sorted `deque`. This isn't so bad for performance, but we can do better if we break ourselves of the requirement that it be sorted (removing a binary search on ACK).
To do this we make the buffer a map of offset -> `StreamBuffer`.
There were two places that were dependent on the sorted nature of the list.
1. For partial reliablity we call `shrinkBuffers` to remove all unacked buffers less than an offset. For this we now have to do it with a full traversal of the retransmission buffer instead of only having to do an O(offset) search. In the future we could make this better by only lazily deleting from the retransmission buffer on ACK or packet loss.
2. We used the start of the retransmission buffer to determine if a delivery callback could be fired for a given offset. We need some new state to track this. Instead of tracking unacked buffers, we now track acked ranges using the existing `IntervalSet`. This set should be small for the typical case, as we think most ACKs will come in order and just cause existing ranges to merge.
Reviewed By: yangchi
Differential Revision: D18609467
fbshipit-source-id: 13cd2164352f1183362be9f675c1bdc686426698
Summary: The state machine logic is quite abstruse, this modifies it to make it more readable.
Reviewed By: siyengar
Differential Revision: D18488301
fbshipit-source-id: c6fd52973880931e34904713e8b147f56d0c4629
Summary:
The idea of having a sorted deque to do this makes some sense, but it ends up extremely inefficient for workloads that churn through a lot of streams.
Mitigate this by instead tracking the open streams with a `FastSet`. For a very small number of streams this will probably be slightly less efficient, but not measurably.
Reviewed By: kvtsoy
Differential Revision: D18409885
fbshipit-source-id: 2214640682926b4b4525700df85627f6125cabe8
Summary:
F14 should be faster and have lower memory urilization for near-empty sets and maps. For most H3 connections these are mosotly going to be near-empty, so CPU wins will likely be minimal.
For usecases that have extremely high numbers of streams, there are likely going to be CPU wins.
Reviewed By: yangchi
Differential Revision: D18484047
fbshipit-source-id: 7f5616d6d6c8651ca5b03468d7d8895d1f51cb53
Summary:
This will allow to be able to create different kind of handshake going forward.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/59
Reviewed By: siyengar
Differential Revision: D18088574
Pulled By: mjoras
fbshipit-source-id: 0732bb63a9e243fef77cdaf4f76e711fcb09ecdc
Summary: For protocols like HTTP/3, lacking an actual priority scheme, it's a good idea to write control streams before non control streams. Implement this in a round robin fashion in the same way we do for other streams.
Reviewed By: afrind
Differential Revision: D18236010
fbshipit-source-id: faee9af7fff7736679bfea262ac18d677a7cbf78
Summary:
The function indeed compares a Stream frame to a buffer, not an Ack
frame to a buffer.
Reviewed By: sharma95
Differential Revision: D18000632
fbshipit-source-id: fbbc36378404f8f52a199114af48b9020d0569e8
Summary:
Implement sending stream limit updates in a windowed fashion, so that as a peer exhausts its streams we will grant it additional credit. This is implemented by having the stream manager check if an update is needed on removing streams, and the api layer potentially sending an update after it initiates the check for closed streams.
This also makes some driveby changes to use `std::lower_bound` instead of `std::find` for the sorted collections in the stream manager.
Reviewed By: yangchi
Differential Revision: D16808229
fbshipit-source-id: f6e3460d43e4d165e362164be00c0cec27cf1e79
Summary:
With partial reliability we adjust retransmission queue on skips; we need to account for that when we match buffers in retransmission queue.
In fully reliable mode an ack frame must always match a single buffer from re-tranmission queue (offset, length and eom).
In partially reliable mode we can run into two more scenarios in addition to the above:
* re-transmisison buffer for which the ack frame arrived has been removed fully
* re-transmisison buffer for which the ack frame arrived has been removed partially
If full buffer is missing - ignore the ack.
If part of the buffer is missing, make sure that the adjusted offset and length match to that found in the ack frame.
Reviewed By: yangchi
Differential Revision: D15301304
fbshipit-source-id: f281fa30957c1c13c42c05684984f9a1acaa4e34
Summary: This is step 1 for removing reset on reset, since the send side may need to transition to waiting for a reset ack while the read side is an any state.
Reviewed By: lnicco
Differential Revision: D15075849
fbshipit-source-id: 1e094942a8a1ca9a01d4161cd6309b4136a9cfbf
