3 ms·

1. buffersize requirements are not that simple 2. fq_* is meant for end-/edge-routers where the number of flows is rather small https://web.stanford.edu/~sars

• dtaht 3y ago
  fq+ we have been running at 25+gbit or more, for quite some time. There are typically 32k FQ_codels in a 10gbit system. I am pretty sure, that we would not have scaled past 10gbit as well as we did, without having made fq_codel and sch_fq (which does pacing), had we not. We run up to 10k instances of cake (4k queues each) in libreqos. Amazing results.
  • sambazi 3y ago
    impressive and interesting i assume performance optimizations for the fast-path were successful, or is this scale-up rooted in advances with multithreading and packetsteering?
    • dtaht 3y ago
      fq_codel was successfully offloaded in a few products, however, no offload here, just a xeon with a ton of cores and a big L3. On the libreqos case we leveraged some ebpf to do packet steering in what we call the heimdal bridge, and also kathie nichol´s wonderful passive ping concept: https://github.com/thebracket/cpumap-pping https://github.com/thebracket/cpumap-pping src here: https://github.com/LibreQoE/LibreQoS/ https://github.com/LibreQoE/LibreQoS/ You can get a transparent high speed bridge with shaping capability up pretty rapidly with supported hardware. I still long for an ethernet card that can do a trie lookup natively! The flamegraphs are mostly getting the right packet to the right cpu, still.