bits 0x2d - Calender Week 45, 2023

Have been pretty worn out. Not so much content here.

# good reads

• Journeying into XDP: Part 0 By Luuk Hendriks https://blog.apnic.net/2020/09/02/journeying-into-xdp-part-0/

• Accelerate TURN Services with eBPF/XDP By Tamás Lévai et. al. https://conferences.sigcomm.org/sigcomm/2023/files/workshop-ebpf/5-TURN.pdf and https://dl.acm.org/doi/pdf/10.1145/3609021.3609296 Insight: (on slide 18/Sec.3.3), updating UDP checksum can be a challenge.

# I learned something?

I was doing a friend a favor to check her XDP program, which, I’ve never played with before. But that seems like a rather easy one so I went through some tutorials and also the XDP paper¹. XDP (eXpress Data Path) is a “framework” based on eBPF, with which you can build program that can be inserted into the kernel’s network stack (just as any eBPF program does, it’s specific for network packets and you don’t need to worry about the drivers). The XDP program can is executed upon every incoming L3 (ethernet) packet. The program could:

• parse the packets by mapping the data buffer into different L3+ data structures such as IP headers or UDP payloads
• modify the packet
• accept the packet, with or without modification
• reject (DROP) the packet
• resend the packet: this is often done after changing the IP’s dest and src address.

From what I’ve read and experienced, XDP makes it easy to play with the network stack with high performance because your program is effectively inserted into the kernel and there’s no need for user/kernel switching. However it’s also limited in several ways:

• Inherited limitation from eBPF: the XDP program must be bonded to a certain number of instructions. This means that any loop must be statically constrained.
• For the same reason, re-calculating the checksum of a (for example UDP) packet is challenging. If the previous checksum is known and the modified parts are bounded, updating the checksum can be done with some helper function such as bpf_csum_diff. But calculating the whole checksum is tricky (and sometimes impossible). Because it’s hard to make sure the loop (which iterates over the payload and the pseudo IP header) is bounded to to the instruction limit².
• The kernel’s implementation for XDP is only for incoming packets. There was a patch that also implements XDP for egress packets but that was never merged³.

# Moving away from arch (to what?)

I have been using arch for perhaps 8+ years and I have been tempted to move away. Here are some reflections (and stuffs to consider when do the hopping):

To what extent do I rely on the AUR?

$ pacman -Qm | wc -l
> 95

For a complete list see https://shrik3.com/misc/pkgs/aur_pkgs_nov_2023.txt
I could, probably, find most of these packages already ported to whatever distro I’m about to hopping to. But will it be as smooth?

What the price for convenience?
AUR is great, but there is a risk: you are essentially putting your trust in whoever maintains the package, (popular) packages are “attested” by the community but that’s not a guarantee! And in that regard, when things go bad, things go go really bad.

Also there is price to pay for rolling release: fixing the version of a certain software is not trivial. You can let pacman skip some certain packages but that’s not “the way”. As archwiki says, partial update is not supported. When you hit an issue with some certain software, you are expected to do a full system update (-Syu) before asking question. Normally I have no issue with this on my desktop environment. But that’s a different story if you have a lot of system software to manage, especially on a server⁴. For example the postgresql major version updates normally introduce breaking changes that requires you to do manual migration of your databases.

How good is a distro maintained?
There are some 70-ish core maintainers, maintaining 14336 packages! That’s amazing dedication (thank you, arch maintainers!). But on the other hand, every core maintainer is responsible of 200+ packages. And on a rolling release basis that sounds really intensive. That’s why I will not use a distro with a small community (and dev team). I believe they are very capable, but I doubt if a handful of devs could keep up, especially when they are not funded (my respect!).

How good are things documented?
People criticize arch community for being elitism, that’s completely nonsense. The archwiki is a great (if not the greatest) source for system related infos.

I hate documentations like “[very vaguely describing] do this and that, then you are done – wait you don’t know how to do this and that? That’s your problem!”

Why I want to move away from arch
Actually I don’t have a real motivation to move away. I don’t hate arch to the slightest. (But I don’t like people flexing around “I use arch” in the /r/unixporn, but who cares). I simply want to try new things… Or to give myself some challenges …