Summary:
Comparing (operator<) for default PriorityQueue::Priority vs HTTPPriorityQueue::Priority was not correctly using the default HTTP priority - instead it would interpret 0xffffffff as u=7, i=1, which is the lowest priority. Also constructing or assigning HTTPPriorityQueue::Priority from PriorityQueue::Priority was suboptimal.
1) Make order a uint32_t. From HTTPPriorityFunctions, it looks like we could only set this to a max of 2^31-1 anyways.
2) Add an 'uninitialized' bit to HTTPPriority. Since the default is 1 initialized in the base class, only fully initialized HTTPPriority will return true for `isInitializedFast`
3) Implement new constructor and assignment operator
4) Return a static default uint64 for uninitialized priority in `toUnit64`, this fixes `operator<`
5) Streamline `operator==`
Reviewed By: hanidamlaj
Differential Revision: D73685997
fbshipit-source-id: 5c6cd2404d6506f661aa29983c5ded3cf913758c
Summary:
This is an API break, but it should mostly be a manageable one. We want to be able to compile mvfst internally without exceptions, and folly::Optional is one dependency that makes this challenging. Additionally, we already have an imported secondary optional type for performance/struct size reasons, tiny-optional.
This second optional interface is mostly compatible in an API sense (including the use of std::nullopt) with std::optional. Thus our approach is to remove the dependency on folly::Optional, and offer a quic::Optional instead.
The next diff will properly vendor tiny-optional so that quic::Optional is an independent version of it.
Reviewed By: sharmafb, kvtsoy
Differential Revision: D74133131
fbshipit-source-id: 715f8bb5043ba3bb876cacfe54236887e0686b30
Summary:
fix for OSS issue reported in https://github.com/facebook/mvfst/issues/382
UndefinedBehaviorSanitizer: dynamic-type-mismatch buck-out/v2/gen/fbcode/12f4c1ea6c843aab/quic/priority/__http_priority_queue__/buck-headers/quic/priority/HTTPPriorityQueue.h:133:9
buck-out/v2/gen/fbcode/12f4c1ea6c843aab/quic/priority/__http_priority_queue__/buck-headers/quic/priority/HTTPPriorityQueue.h:76:23: runtime error: member call on address 0x51a0000026b8 which does not point to an object of type 'quic::HTTPPriorityQueue::Priority'
0x51a0000026b8: note: object is of type 'quic::PriorityQueue::Priority'
be be be be 10 1b 13 02 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'quic::PriorityQueue::Priority'
#0 0x000000e36302 in quic::HTTPPriorityQueue::Priority::operator==(quic::HTTPPriorityQueue::Priority const&) const fbcode/quic/priority/HTTPPriorityQueue.h:76
```
Reviewed By: mjoras
Differential Revision: D73674107
fbshipit-source-id: 4934e404cf6298d6351d4b45f676a8a83838f91f
Summary: This will be needed by logging components - eg QLog
Reviewed By: hanidamlaj
Differential Revision: D72476485
fbshipit-source-id: 3b7f3e81e87fc6cc2a252293208863d33bd5df50
Summary:
This is a reimplementation of the HTTP priority queue with the new API. The new design is:
A single vector-based heap for sequential streams across all levels and an array of 8 RoundRobin's that hold incremental streams.
Getting the highest priority element doesn't require iterating through empty levels - it's right at the front of `heap_` or `roundRobins_[lowestRoundRobin_]`.
There's an index map which incremental streams always use, the value is an index into roundRobins_. When there are a large number of sequential streams in the heap_, we also index those (with their array index).
The benchmarks (next diff) show that this is 2x faster for 8 streams and 20% slower for large numbers of sequential streams (96). The break-even point is 40 streams.
Reviewed By: mjoras
Differential Revision: D68641759
fbshipit-source-id: 30ea5c719e998ead20d8762ee5ddad10111ea7e5
