DHCP performance

One of the things we wanted from networkd was reasonably fast network configuration.

Most of today's machines (be it phones, laptops, container instances or servers) are only really useful for their purpose once they have a network connection. It does not matter much that we are able to boot in one second, if it takes several times that to establish a network connection.

This is especially important for container instances that we can boot in, say 100ms, and therefore reasonably start on demand.

A couple of weeks ago I started profiling networkd's DHCP client library, and found that we compared relatively favorably to the 'competition', but were still adding way too much to boot-time to be acceptable in containers. Acquiring a DHCP lease from the same host (so no network latency) took about 500ms.

Quite a bit of low-hanging fruit later we were down to 50ms, but with one big bottle-neck remaining. Today, with lots of help from +Kay Sievers and a crucial suggestion from Daniel Borkmann, I finally killed off the last obvious bottle-neck and we are now able to acquire a lease in about 750 micro seconds (so almost 1000x improvement :)).

The tests were pretty synthetic (our DHCP client and server libraries talking to each other over a veth pair from the same process), so let's finish off with two real-world tests:

Deploying networkd as the DHCP client in an nspawn container started with --network-veth, the time from we get link-sense to the network is fully configured is roughly 5ms.

Using networkd together with wpa_supplicant on my laptop on my crappy home wifi, the time from link-sense to fully configured network is roughly 50ms (most of that obviously spent on network latency due to the two round-trips a lease acquisition requires).

Overall, I'm pretty happy with these results, and am even tempted to say that this is good enough. A few obvious improvements can still be made: employ BPF to avoid getting woken up by lots of bogus packets that we have to discard, and optimize our IP/UDP checsum algoritm, which is still pretty naive, and which currently takes up most of our CPU time.

If anyone is interested in working on further optimizations, do get in touch!
Shared publiclyView activity