bits 0x2d - Calender Week 45, 2023

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

good reads

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 paper1. 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 limit2.
  • 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 merged3.

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 server4. 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 …


  1. https://dl.acm.org/doi/pdf/10.1145/3281411.3281443 ↩︎

  2. since kernel 5.2 this limit is 1 million. And a UDP payload can be up to 65527 bytes. ↩︎

  3. https://lkml.kernel.org/netdev/87o8usg92d.fsf@toke.dk/t/ ↩︎

  4. who in their right mind drives a rolling release on the production server! well, I do, don’t ask me why. ↩︎

[+] click to leave a comment [+]
the comment system on this blog works via email. The button
below will generate a mailto: link based on this page's url 
and invoke your email client - please edit the comment there!

[optional] even better, encrypt the email with my public key

- don't modify the subject field
- specify a nickname, otherwise your comment will be shown as   
  anonymous
- your email address will not be disclosed
- you agree that the comment is to be made public.
- to take down a comment, send the request via email.

        
>> SEND COMMENT <<
[BITS] - the weekly archive -
bits 0x54 - Week 35~?, 2024 (WIP)
bits 0x53 - Week 28~35, 2024
bits 0x52 - Week 17~27, 2024 [VOID]
bits 0x51 - Calender Week 17, 2024
bits 0x50 - Calender Week 16, 2024
bits 0x49 - Calender Week 15, 2024
bits 0x48 - Calender Week 14, 2024
bits 0x47 - Calender Week 13, 2024
bits 0x46 - Calender Week 12, 2024
bits 0x45 - Calender Week 11, 2024
bits 0x44 - Calender Week 10, 2024
bits 0x43 - Calender Week 09, 2024 [VOID]
bits 0x42 - Calender Week 08, 2024 [VA]
bits 0x41 - Calender Week 07, 2024 [VOID]
bits 0x40 - Calender Week 06, 2024 [VOID]
bits 0x39 - Calender Week 05, 2024
bits 0x38 - Calender Week 04, 2024
bits 0x37 - Calender Week 03, 2024
bits 0x36 - Calender Week 02, 2024 [VA]
bits 0x35 - Calender Week 01, 2024
bits 0x34 - Calender Week 52, 2023
bits 0x33 - Calender Week 51, 2023
bits 0x32 - Calender Week 50, 2023 [VOID]
bits 0x31 - Calender Week 49, 2023
bits 0x30 - Calender Week 48, 2023
bits 0x2f - Calender Week 47, 2023
bits 0x2e - Calender Week 46, 2023
bits 0x2d - Calender Week 45, 2023
bits 0x2c - Calender Week 44, 2023
bits 0x2b - Calender Week 43, 2023
bits 0x2a - Calender Week 42, 2023