aa8c53a20d
In order to achieve concurrency within `connlib`, we needed to create a way for IP packets to own the piece of memory they are sitting in. This allows us to concurrently read IP packets and them batch-process them (as opposed to have a dedicated buffer and reference it). At the moment, those IP packets are defined on the stack. With a size of ~1300 bytes that isn't very large but still causes _some_ amount of copying. We can avoid this copying by relying on a buffer pool: 1. When reading a new IP packet, we request a new buffer from the pool. 2. When the IP packet gets dropped, the buffer gets returned to the pool. This allows us to reuse an allocation for a packet once it finished processing, resulting in less CPU time spent on copying around memory. This causes us to make more _individual_ heap-allocations in the beginning: Each packet is being processed by `connlib` is allocated on the heap somewhere. At some point during the lifetime of the tunnel, this will settle in an ideal state where we have allocated enough slots to cover new packets whilst also reusing memory from packets that finished processing already. The actual `IpPacket` data type is now just a pointer. As a result, the channels to and from the TUN thread (where we were holding multiple of these packets) are now significantly smaller, leading to roughly the same memory usage overall. In my local testing on Linux, the client still only uses about ~15MB of RAM even with multiple concurrent speedtests running.
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.