quic: apply multiple fixes to flow control signaling - #65309
Conversation
Signed-off-by: James M Snell <jasnell@gmail.com> Assisted-by: Opencode/Opus
|
Review requested:
|
This comment was marked as outdated.
This comment was marked as outdated.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65309 +/- ##
==========================================
- Coverage 90.34% 90.31% -0.04%
==========================================
Files 751 751
Lines 250330 250510 +180
Branches 47321 47350 +29
==========================================
+ Hits 226171 226243 +72
- Misses 15557 15619 +62
- Partials 8602 8648 +46
🚀 New features to boost your workflow:
|
| backpressure_listeners_.begin(), backpressure_listeners_.end()); | ||
| for (auto* listener : listeners) { | ||
| if (backpressure_listeners_.contains(listener)) { | ||
| listener->EntryRead(amount); |
There was a problem hiding this comment.
I wonder if it is guaranteed that the DataQueueImpl object is still not destroyed after exiting from EntryRead ?
There was a problem hiding this comment.
Well this was also a point for the older code..
| backpressure_listeners_.begin(), backpressure_listeners_.end()); | ||
| for (auto* listener : listeners) { | ||
| if (backpressure_listeners_.contains(listener)) { | ||
| listener->BeforePull(); |
| if (session().is_destroyed()) return; | ||
| Session::SendPendingDataScope send_scope(&session()); | ||
| session().Consume(id(), amount); | ||
| uncredited_bytes_ -= std::min<uint64_t>(uncredited_bytes_, amount); |
There was a problem hiding this comment.
Sorry, I do not understand this.
If the amount is zero, then uncreduted_bytes_ will be set to zero. Is this the intended behavior?
| // This is the only place we notify — not on every ReceiveData call — | ||
| // so the reader only wakes up when there is a well-sized entry to | ||
| // consume. | ||
| if (reader_) reader_->NotifyPull(); |
There was a problem hiding this comment.
What if only tiny data packets arrive, maybe with a temporal distance of a second? Would this lead to stalls?
| // it past the final size) so the bytes have been dropped. They will | ||
| // never reach a reader, which means EntryRead() will never fire for | ||
| // them -- return their flow control credit here instead of leaking it. | ||
| uncredited_bytes_ -= std::min<uint64_t>(uncredited_bytes_, flushed); |
| // Number of received bytes that are still holding inbound flow control | ||
| // credit -- that is, bytes that ngtcp2 has delivered to us but that have | ||
| // not yet been handed to the JavaScript consumer (they are sitting in | ||
| // recv_accumulator_ or in the inbound_ DataQueue). This is incremented |
There was a problem hiding this comment.
May be it can also be in nghttp3, so it does not hold data?
| }, | ||
| maxStreamWindow: kStreamWindow, | ||
| maxWindow: kConnWindow, | ||
| }); |
There was a problem hiding this comment.
Does this test h3 or pure quic. As h3 is the default.
| initialMaxStreamDataBidiRemote: kStreamWindow, | ||
| initialMaxData: kConnWindow, | ||
| // Allow all streams to be open at once; the point is contention. | ||
| initialMaxStreamsBidi: kStreams, |
|
Great addition to find more stalls in the pipeline. |
Fixing up the QUIC flow control signaling and closed stream handling, expand tests.
Update the flow control handling after the iter streams byte-budget based flow control updates.
@nodejs/quic @pimterry @martenrichter