I do not understand all the negativity, I think it is a solid alternative in the ecosystem, and choice is a good thing.

Maybe, just maybe, they're having fun? FOSS is not only about corporate open-source, but also genuine curiosity. Both can have their place.

> no wonder that nobody younger than 40 was attending the conference. The next generation is doing something else and rightly so.

I saw a lot of students at FOSDEM, attending, presenting and helping the at organization.

In my opinion, the pragmatic solution I use is:

1) use a specialized distribution (I use yunohost but there are others). This makes configuring SPF, DKIM, TLS and more a breeze

2) use a reputable relay to send your emails (I use OVH but again there are plenty of other choices)

Of course it means you are not "pure" because emails you send will go trough a 3rd party (the relay) but it solved the delivery issue entirely for me, so that I can continue to benefit from all the other benefits of self-hosting.

Why this is the case while web-crawlers have been scrapping the web for the last 30 years is a mystery to me. This should be a solved problem. But it looks like this field is full of wrongly behaving companies with complete disregards toward common goods.

  ~# sudo apt install qemu-user-static debootstrap
  ~# mkdir /tmp/arm
  ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian
  ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/
  ~# chroot /tmp/arm   # from that point, you're running ARM!
  ~# /debootstrap/debootstrap --second-stage

Edit: spelling

This must be tracked by kernel, because not all syscalls go through libc, you can issue the open syscall directly from a process.

There might be other reasons, but I'd bet it's the main one.

IOW, one of their strong claim is that PacketMill is innovative because it avoids copying/converting uneeded metadata, but VPP is already doing that since years.

Finally, their claim to break the 100Gbps on single core @2.3GHz is cute, but again I'm afraid they're late to the party. They claim 12-13Mpps per core for 64-bytes packets for example but VPP can achieve 20+Mpps per core already for L3 forwarding (routing).

Again, benchmarking is hard, but I keep reading there claims over and over in academic papers when they're factually wrong for area I know about. I can only imagine what is happening for area I don't know :(

Part of the problem I think is that they have to compare to other existing solutions (click, VPP etc) otherwise everybody will ask, but at the same time it is very difficult to do a fair comparison.

I'm a VPP developer hence I'm both biased and a knowledge-domain expert, but focusing on what I know, which is VPP: figure 11b, they compare VPP to PacketMill for some L2 patch workload. They claim their approach is fare because they use automated tooling to benchmark, good and we also do for VPP, but our results don't necessarily match theirs - and, surprisingly, our results are higher than what they claim for VPP.

PacketMill paper figure 11b for VPP for L2 patch for 64-bytes packets at 1.2GHz using DPDK MLX5 driver [1]: ~5Gbps

VPP for similar configuration [2]: ~7.5Gbps (already a 50% error margin?)

VPP using a more optimized NIC driver (native AVF vs DPDK MLX5) [3]: ~18Gbps (almost 2x what they seem to claim for PacketMill...)

All this to say comparing different solutions is terribly hard, and I'm not sure of the value of this kind of benchmarks.

For VPP we built CSIT [4] which is opensource under the Linux Foundation Networking to automate tests in the same environments, to compare between VPP and DPDK between releases and platforms.

[1] https://packetmill.io/docs/packetmill-asplos21.pdf

[2] http://csit.fd.io/report/#eNp1kd0OwiAMhZ8Gb0zN6MRdeaHuPQxidS...

[3] http://csit.fd.io/report/#eNp1kd0OgjAMhZ9m3pgaVkS88ULlPcwcVU...

[4] http://csit.fd.io/

And VPP is targeting high-end system and uses plenty of AVX512 (we demonstrated 1TBps of IPsec traffic on Intel Icelake for example). It's just very scalable to both small and big systems.

  - amortizing cache misses are you mentioned

  - better use of out-of-order, superscalar processors: by processing multiple independent packets in parallel, the processor can fill more execution units

  - enable the use of vector instructions (SSE/AVX, VMX etc): again, processing multiple independent packets in parallel means you can leverage SIMD. SIMD instructions are used pervasively in VPP

What you're talking about is referred to as source address validation [2] also known as strict reverse path forwarding (RPF) [3].

[1] https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.7

[2] https://datatracker.ietf.org/doc/html/rfc1812#section-5.3.8

[3] https://datatracker.ietf.org/doc/html/rfc3704#section-2.2