Summary:
Previously, the user would call functions like `getXskBuffer` and `writeXskBuffer` on the `XskContainer`. Now, I'm changing it so that we call `pickXsk`, and then call the relevant functions on the `XskSender`.
The reason I'm making this change is that it makes things cleaner with versions of the `XskContainer` that don't use hashing, since they don't need the source and destination addresses as input for all functions.
Reviewed By: hanidamlaj
Differential Revision: D53536905
fbshipit-source-id: 026fcdcb94b3f60bb905467998c0b3ce11880cdd
Summary: We currently crash if there are no free UMEM frames. With the change in this diff, we handle errors more gracefully by logging an error and returning the result, which is similar to how we handle other errors during packet building and transmission.
Reviewed By: hanidamlaj
Differential Revision: D53289685
fbshipit-source-id: fbb3c973ec4182f8d40e42ab75cd8b7b30054a69
Summary: In this commit, I'm making the `XskPacketGroupWriter`, which is a child of the abstract class `PacketGroupWriter`. This is responsible for writing packets through AF_XDP rather than UDP sockets.
Reviewed By: mjoras
Differential Revision: D53016965
fbshipit-source-id: b4c4fae68d8c3743349f17eab7c2e120a2978170
Summary:
In this commit, I'm creating a `PacketGroupWriter`, which is an abstract class that has APIs for packet writing. I'm also creating a `UdpSocketPacketGroupWriter` which inherits from it.
The abstract `PacketGroupWriter` enables us to use different mechanisms to write packets, and is a prelude to us using AF_XDP for packet writing.
Note that this diff doesn't change any existing functionality.
Reviewed By: mjoras
Differential Revision: D52978211
fbshipit-source-id: 1d24f984f819d25f91c6fd762a5a40003b4c86ce
Summary: This is similar to the previous commit. We use a stack-based IOBuf instead of allocating one on the heap. This saves CPU because allocations/deallocations on the stack are a lot cheaper.
Reviewed By: hanidamlaj
Differential Revision: D53101722
fbshipit-source-id: dd59a7eca6498db19472a62f954db3e2f2f27a42
Summary: Creating an IOBuf on the heap when we use `folly::IOBuf::wrapBuffer` is expensive.
Reviewed By: hanidamlaj
Differential Revision: D52506216
fbshipit-source-id: eed2b77beae0419b542b0461303785cc175e3518
Summary:
This is the major transition that updates mvfst code to use the new interfaces. The new Folly implementations of the interfaces maintain all the existing behavior of folly types so this should not introduce any functional change. The core changes are:
- Update the BatchWriters to use the new interfaces.
- Update the FunctionLooper to use the new interfaces.
- Change QuicServerTransport to take the folly types and wrap them in the new types for use in the QuicTransportBase.
The rest of the diff is for updating all the existing uses of the QuicTrasnport to initialize the necessary types and pass them to the QUIC transport instead of directly passing folly types.
Reviewed By: mjoras
Differential Revision: D51413481
fbshipit-source-id: 5ed607e12b9a52b96148ad9b4f8f43899655d936
Summary:
This diff changes `QuicAsyncUDPSocketWrapper` so that it is an abstraction layer that inherits from `QuicAsyncUDPSocketType`, instead of simply being a container with aliases.
- Key changes in `QuicAsyncUDPSocketWrapper.h`, the rest of the updates switch us from using `QuicAsyncUDPSocketType` to `QuicAsyncUDPSocketWrapper`.
- It's difficult to mock the UDP socket today given that we expose the entire `folly::AsyncUDPSocket` type to the higher layers of the QUIC stack. This complicates testing and emulation because any mock / fake has to implement low level primitives like `recvmmsg`, and because the `folly::AsyncUDPSocket` interface can change over time.
- Pure virtual functions will be defined in `QuicAsyncUDPSocketWrapper` in a follow up diff to start creating an interface between the higher layers of the mvfst QUIC stack and the UDP socket, and this interface will abstract away lower layer details such as `cmsgs` and `io_vec`, and instead focus on populating higher layer structures such as `NetworkData` and `ReceivedPacket` (D48714615). This will make it easier for us to mock or fake the UDP socket.
This diff relies on changes to `folly::MockAsyncUDPSocket` introduced in D48717389.
--
This diff is part of a larger stack focused on the following:
- **Cleaning up client and server UDP packet receive paths while improving testability.** We currently have multiple receive paths for client and server. Capabilities vary significantly and there are few tests. For instance:
- The server receive path supports socket RX timestamps, abet incorrectly in that it does not store timestamp per packet. In comparison, the client receive path does not currently support socket RX timestamps, although the code in `QuicClientTransport::recvmsg` and `QuicClientTransport::recvmmsg` makes reference to socket RX timestamps, making it confusing to understand the capabilities available when tracing through the code. This complicates the tests in `QuicTypedTransportTests`, as we have to disable test logic that depends on socket RX timestamps for client tests.
- The client currently has three receive paths, and none of them are well tested.
- **Modularize and abstract components in the receive path.** This will make it easier to mock/fake the UDP socket and network layers.
- `QuicClientTransport` and `QuicServerTransport` currently contain UDP socket handling logic that operates over lower layer primitives such `cmsg` and `io_vec` (see `QuicClientTransport::recvmmsg` and `...::recvmsg` as examples).
- Because this UDP socket handling logic is inside of the mvfst transport implementations, it is difficult to test this logic in isolation and mock/fake the underlying socket and network layers. For instance, injecting a user space network emulator that operates at the socket layer would require faking `folly::AsyncUDPSocket`, which is non-trivial given that `AsyncUDPSocket` does not abstract away intricacies arising from the aforementioned lower layer primitives.
- By shifting this logic into an intermediate layer between the transport and the underlying UDP socket, it will be easier to mock out the UDP socket layer when testing functionality at higher layers, and inject fake components when we want to emulate the network between a mvfst client and server. It will also be easier for us to have unit tests focused on testing interactions between the UDP socket implementation and this intermediate layer.
- **Improving receive path timestamping.** We only record a single timestamp per `NetworkData` at the moment, but (1) it is possible for a `NetworkData` to have multiple packets, each with their own timestamps, and (2) we should be able to record both userspace and socket timestamps.
Reviewed By: jbeshay, hanidamlaj
Differential Revision: D48717388
fbshipit-source-id: 4f34182a69ab1e619e454da19e357a6a2ee2b9ab
Summary: This allows us to not reserve for the DSR path.
Reviewed By: hanidamlaj
Differential Revision: D46787596
fbshipit-source-id: dcd97b1190f4559b8798b1a78b1508effee84753
Summary: There's no point in doing this for the DSR backend, as we don't use the frame metadata.
Reviewed By: hanidamlaj
Differential Revision: D46787595
fbshipit-source-id: 027fdc0dfe2e45b8b82d506446c8be9090cef939
Summary:
This improves the performance of DSR packet writing. The thread local contiguous buffer is transparently allocated on the first write.
We store the relevant data in a fake connection state so as to not change the existing (somewhat janky) batch writer interface. In the future we should refactor this so it's less ugly.
Reviewed By: kvtsoy
Differential Revision: D46765252
fbshipit-source-id: cf0bb66a3c4ea7b76ade4e99cb65ce42774ed810
Summary: As in title. The comment here was right all along. In practice this doesn't matter that much, but it matters significantly to synthetic performance tests like tperf.
Reviewed By: shodoco
Differential Revision: D46726195
fbshipit-source-id: fe22d12a7ac3a237a30b5d0d19cc9a0fd7a21e11
Summary: This is a pretty obvious thing to do. There's not really any reason to have the data and metadata separately since we don't need to reallocate.
Reviewed By: jbeshay
Differential Revision: D36237370
fbshipit-source-id: 093ad7fb2c54b596ea5cc327ffcc24de1748d362
Summary: Currently writePacketsGroup returns the number of packets it sent. Update it to return the number of bytes has been sent too.
Reviewed By: mjoras
Differential Revision: D34280604
fbshipit-source-id: 5cc4047401a00054a2bc0a0e7429a3beaa046f44
Summary: This makes the RequestGroup its own struct so we don't have so much redundant information in the requests.
Reviewed By: shodoco
Differential Revision: D32175496
fbshipit-source-id: 7365f55133f2eeebd16b8a534e7e4ce08842d327
Summary: This doesn't belong in the generic state. Untangling it is a little difficult, but I think this solution is cleaner than having it in the generic state.
Reviewed By: JunqiWang
Differential Revision: D29856391
fbshipit-source-id: 1042109ed29cd1d20d139e08548d187b469c8398
