commit 7e67f01d296f9a57f63ca41af665f7b354078772
author bnc <bnc@google.com> Wed Mar 15 07:45:06 2023 -0700
committer Copybara-Service <copybara-worker@google.com> Wed Mar 15 07:46:26 2023 -0700
tree 348f95b4813760e0f4adcff9bc6f228da26c5358
parent 43b21e0a3d87ec56531f08c2013bf538411a352b

Disable batched write in QuicWriteBlockedList.

As a reminder, HTTP/3 streams have two priority-related parameters received from
the clien in PRIORITY_UPDATE frames: urgency (int) and incremental (bool).

Writes can be continuous or round-robin. With continuous writes, if data is
written on a given stream, writing contiues as long as there is data for that
stream. Round-robin writes can be batched or not. If batched, writing on a
stream can continue if less than 16 kB of data has been written continuously on
that stream. If not batched, other streams with same urgency get a turn after a
single write. In any case, the size of a single write is not limited by
QuicWriteBlockedList.

This applies to streams with the same urgency value. Streams always yield to
streams with higher priority (lower urgency value).

Incremental streams are always written round-robin. If
--gfe2_reloadable_flag_quic_priority_respect_incremental is
false, non-incremental streams are also written round-robin. If it is true, they
are written continuously. This was introduced in cl/511587715.

This CL introduces --gfe2_reloadable_flag_quic_disable_batch_write. If false,
round-robin writes are batched. If true, they are not batched. This applies to
incremental streams, and if
--gfe2_reloadable_flag_quic_priority_respect_incremental is false, then to
non-incremental streams as well.

An additional optimization is to prioritize the non-incremental stream with the
last write over incremental streams even if there was a write on the incremental
stream in the meanwhile (due to the non-incremental stream not having data to
write).  While this sounds unfair (in the sense that incremental streams may be
starved), this is no worse than incremental streams being blocked by a
non-incremental stream that can provide write data continuously.  The rationale
is that data on a non-incremental stream is useless for the client until all of
it is received, so once some of it was sent, send all of it.  (Note that
incremental streams do not immediately yield to other non-incremental streams
that have started writing, only to the most recent one.  They get at least one
turn to write their own data.)

Protected by FLAGS_quic_reloadable_flag_quic_disable_batch_write.

PiperOrigin-RevId: 516822305