Summary: Cleaned up extra semicolons for compatibility with other projects enforcing the flag, included flag in build
Reviewed By: lnicco, JunqiWang
Differential Revision: D21794945
fbshipit-source-id: ae2ee637aadeef35a99d89f9b8deaa2e7d636ed7
Summary: SendmmsgGSOPacketBatchWriter - try to batch more based on dest addr (map)
Reviewed By: mjoras
Differential Revision: D21110682
fbshipit-source-id: 1be2eb26ec33c8256f1d4bbe7e3d6fae19eb7146
Summary:
as title. Instead of checking against the packet size limit, this
leaves a 10 bytes room since we have a bug that writes out packets that's
slightly larger than udpSendPacketLen. Most of such packet will be 1-2 bytes
larger than original packets.
Reviewed By: mjoras
Differential Revision: D21642386
fbshipit-source-id: 6ca68d48828cb7f8ee692e0d5f452f5389a56bfd
Summary: As in title. Also explicitly do some copying of values out of the stream manger.
Reviewed By: yangchi
Differential Revision: D21705460
fbshipit-source-id: 2399b8561a2aa3b6d2b64d154f56ceff22c40186
Summary:
otherwise we keep encoding packet headers and potentially write into
the write buffer without actually generating a packet. It leaves a trail of bad
headers inside the buffer
Reviewed By: mjoras
Differential Revision: D21626733
fbshipit-source-id: 3bdcf6277beccb09b390a590ba2bb0eb8e68e6c1
Summary: There's no particular reason to wait for the drain period before removing state. By doing this a failed migration will immediately trigger the server to drop state, triggered a stateless reset signal to the client sooner.
Reviewed By: yangchi, lnicco
Differential Revision: D21643179
fbshipit-source-id: a60ca2c92935a3e6ba773d7936c25317733f7b97
Summary:
To make sure the writer maker function actually return the Inplace
writer
Reviewed By: lnicco
Differential Revision: D21613419
fbshipit-source-id: da7e59b43785b13fd91cc1a737db87af7dfb1c8f
Summary:
as title
(Note: this ignores all push blocking failures!)
Reviewed By: lnicco
Differential Revision: D21595158
fbshipit-source-id: f0061d525852a1b0881ebf4c56923faa58ddae08
Summary:
During PTO, when we try to write new data, we have been limiting to
only stream data and crypto data. This diff adds a few more types of data to
write during probes if they are available: Simple frame, Window updates, Rst
and Blocked frames.
Right now Acks won't be included here.
Reviewed By: mjoras
Differential Revision: D21460861
fbshipit-source-id: d75a296e96375690eee5e609efd7d1b5c103e8da
Summary: This is just in wrong place. There can be multiple frames per packet that we may be implicitly ACKing.
Reviewed By: lnicco
Differential Revision: D21493553
fbshipit-source-id: 89befab01c5a27d400089478717110bca8137d99
Summary: Without doing this the loss buffer can potentially carry data indefinitely.
Reviewed By: yangchi
Differential Revision: D21484470
fbshipit-source-id: 85ac9f274c9badb51eb431b85f67a654c399a018
Summary:
Becuase when we clone an existing packet, the logic inside the current
writetStreamFrameHeader is no longer correct.
Reviewed By: mjoras
Differential Revision: D21383828
fbshipit-source-id: 8e6bbb048eefd97ca7cf17b89edc2f395f274a73
Summary: The spec suggests doing this, and it is a better semantic than only considering the local one.
Reviewed By: yangchi
Differential Revision: D21433433
fbshipit-source-id: c38abc04810eb8807597991ce8801d81f9edc462
Summary:
Now we won't have a zero PTO and we will properly clear out the outstanding packets.
Note that this cipher dropping is not what the draft prescribes, instead dropping both the initial and handshake ciphers when we know 1-rtt communication is functioning.
Reviewed By: yangchi
Differential Revision: D20388737
fbshipit-source-id: 0b89eb80c8faa796ab09eda3eaa10a00dcf7bae9
Summary:
It doesn't depend on the state of the IOBufQuicBatch. Move it out so
other writers can use this function in the future
Reviewed By: mjoras
Differential Revision: D21005960
fbshipit-source-id: b09f41f715a7908f74e490ca24eaec0e41f58a2c
Summary:
as title
(Note: this ignores all push blocking failures!)
Reviewed By: mjoras
Differential Revision: D21303116
fbshipit-source-id: 5e76e02a618a5f79867adae0a78e0174630ce039
Summary:
Currently the packet builder contructor will encode the packet
builder. This is fine when the builder creates its own output buffer. If later
on we decides not to use this builder, or it fails to build packet, the buffer
will be thrown away. But once the builder uses a buffer provided by caller, and
will be reused, we can no longer just throw it away if we decide not to use
this builder. So we have to delay the header encoding until we know we will use
the builder.
This is still not enough to solve the case where we want to use this builder,
it builds, then it fails . For that, we will need to retreat the tail position
of the IOBuf.
Reviewed By: mjoras
Differential Revision: D21000658
fbshipit-source-id: 4d758b3e260463b17c870618ba68bd4b898a7d4c
Summary:
In D20494128 we fixed the direct use of `[[nodiscard]]` in quic, but more cases have apparently gotten into the codebase since. The reason we don't see more errors in fbsource is that clang is lenient allowing this in `-std=c++14` mode, but it causes a mismatch when the flag is honored for MSVC.
Note: quic and other parts of xplat need to stay in `-std=c++14` mode for the time being. See abandoned diff D20377630 for details on the last attempt to switch to `-std=c++17`.
Reviewed By: yangchi
Differential Revision: D21280601
fbshipit-source-id: 78a1956d644f5f95d892b1fd82c5e899823c8e84
Summary:
Add support for variable number of addrs so we can send data to multiple destinations.
(Note: this ignores all push blocking failures!)
Reviewed By: kevin-vigor
Differential Revision: D21032857
fbshipit-source-id: f73b98d44f5d7d92f3692dfddb9b1c76ebcc51c5
Summary: This is useful when you want to ensure that the IOBuf you pass in is encrypted inplace, as opposed to potentially creating a new one.
Reviewed By: yangchi
Differential Revision: D21135253
fbshipit-source-id: 89b6e718fc8da1324685c390c721a564bb77d01d
Summary:
Move the Initial padding code into main scheduler so that ack packets
in Initial space will also be padded.
Reviewed By: mjoras
Differential Revision: D21090338
fbshipit-source-id: dd92c2a1c4d00c58bf2470e2b070c43881a70187
Summary: It may be desirable for some applications to limit the number of streams written to a single packet, for example if they are treating streams like individual messages.
Reviewed By: yangchi
Differential Revision: D21067175
fbshipit-source-id: 75edcb1051bf7f1eb2c9b730806350f9857eabec
Summary:
Some of these are relevant to performance, others are just cleanups of the API usage.
The performance diffs are generally eschewing multiple lookups into the underlying structures, by reusing the iterator from `find`.
The cleanups are mostly getting rid of checks against `getStream`, which cannot return `nullptr`.
Reviewed By: yangchi
Differential Revision: D20987998
fbshipit-source-id: 1b95fd8b14da934fc921527aa858dcebf80ec8e9
Summary:
We always add stuff into peekable streams set since everything with a
read buffer is peekable. This makes the this set potentially big, and the
find_if quite expensive. For apps that isn't interested in peeking, this is a
waste of time.
Reviewed By: mjoras, lnicco
Differential Revision: D20972192
fbshipit-source-id: d696ded936140c622e019d608c72a646df405111
Summary:
Other frames have been using the BufQueue version of frame writing.
Change this for Crypto streams as well
Reviewed By: mjoras
Differential Revision: D20947921
fbshipit-source-id: 1cfa0f3806e8d74e8c8a4864498e1c06b55d5292
Summary:
Now all the schdulings are via main FrameScheduler or
CloningScheduler, this API is no longer used anywhere.
Reviewed By: mjoras
Differential Revision: D20899649
fbshipit-source-id: 89b34c6e8178a3abad10c594b24feae8308e3768
Summary:
To prepare for another configuration of this chain. With this, now we
can land all the outstanding GSO optimization diffs without having to worry
about breaking the production code.
Reviewed By: mjoras
Differential Revision: D20838453
fbshipit-source-id: 807a0c546305864e0d70f8989f31d3de3b812278
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: Doing an extra lookup here is wasteful.
Reviewed By: yangchi, lnicco
Differential Revision: D20848227
fbshipit-source-id: 8a1fee28597fae3cf1ac284a1bd781936ddff931
