The state of fq_codel and cake in 2022
blog.cerowrt.org
The state of fq_codel and cake in 2022
1–8 of 8 posts
Re: The state of fq_codel and cake in 2022
#2Given that VPP is ~10x faster than Linux routing, it may be the only path to good performance on low-end SoCs.
Re: The state of fq_codel and cake in 2022
#3Given that VPP is ~10x faster than Linux routing, it may be the only path to good performance on low-end SoCs.
tnsr (vpp) on a 4C c3558 will do 5.01Mpps at 438 CPU cycles/packet. Simple IMIX can forwarded at line rate in one direction on a 10Gbit link on one core.
Linux on the same platform will only forward 642.71 Kpps.
Using 3 of the four cores for VPP yields 15.1Mpps forwarded IPv4 while consuming 19W.
tnsr with a GUI as a “new pfSense” is being worked on now.
No idea (yet) what I’m going to do about codel / PIE / cake though.
Re: The state of fq_codel and cake in 2022
#4Given that VPP is ~10x faster than Linux routing, it may be the only path to good performance on low-end SoCs.
tnsr (vpp) on a 4C c3558 will do 5.01Mpps at 438 CPU cycles/packet. Simple IMIX can forwarded at line rate in one direction on a 10Gbit link on one core. Linux on the same platform will only forward 642.71 Kpps. Using 3 of the four cores for VPP yields 15.1Mpps forwarded IPv4 while consuming 19W. tnsr with a GUI as a “new pfSense” is being worked on now. No idea (yet) what I’m going to do about codel / PIE / cake tho…
The principal use case for any AQM is when stepping down from one speed to another, in the case of wireless, wildly variable rates, or in the case of 10Gbit to 1Gbit on a port (rfc7567), or shaping to customer rates via middlebox, like libreQos does (using XDP, currently).
In the non-shaping case, say going two 10Gbit ports into one...
what I had expected (in the future I saw in 2015) was that the FQ/AQM would be offloaded to hardware, and that vpp/ddpk would also get a timestamp and 5 tuple hash from the receive path's HW.
Re: The state of fq_codel and cake in 2022
#5Earlier quoted context omitted.
tnsr (vpp) on a 4C c3558 will do 5.01Mpps at 438 CPU cycles/packet. Simple IMIX can forwarded at line rate in one direction on a 10Gbit link on one core. Linux on the same platform will only forward 642.71 Kpps. Using 3 of the four cores for VPP yields 15.1Mpps forwarded IPv4 while consuming 19W. tnsr with a GUI as a “new pfSense” is being worked on now. No idea (yet) what I’m going to do about codel / PIE / cake tho…
The principal use case for any AQM is when stepping down from one speed to another, in the case of wireless, wildly variable rates, or in the case of 10Gbit to 1Gbit on a port (rfc7567), or shaping to customer rates via middlebox, like libreQos does (using XDP, currently). In the non-shaping case, say going two 10Gbit ports into one... what I had expected (in the future I saw in 2015) was that the FQ/AQM would be off…
The 5 tuple hash is easy. The timestamp is a clock read, which can be expensive.
Re: The state of fq_codel and cake in 2022
#6Earlier quoted context omitted.
The principal use case for any AQM is when stepping down from one speed to another, in the case of wireless, wildly variable rates, or in the case of 10Gbit to 1Gbit on a port (rfc7567), or shaping to customer rates via middlebox, like libreQos does (using XDP, currently). In the non-shaping case, say going two 10Gbit ports into one... what I had expected (in the future I saw in 2015) was that the FQ/AQM would be off…
The 5 tuple hash is easy. The timestamp is a clock read, which can be expensive.
At least some hardware provides the timestamp for you. Ideally if that's carried along with the packet, it measures the load on the whole system, so when you start dropping packets it's not just a function of network congestion but running out of cpu.
This would be a plus for a userspace router implementation, as presently in linux we timestamp on entry to the exit queue, not on all the overheads of routing lookup, and other processing from the read from the rx ring.
Re: The state of fq_codel and cake in 2022
#7I'm super happy to see fq_codel and cake in actual consumer/prosumer hardware now - I've gone from needing a fairly power hungry x86 box as my home router to cope with 1000/115 + pppoe + cake to being able to use a much lower power mikrotik rb5009.
Having cake on the upstream means I can push containers, send horribly large backups with multiple TCP streams, etc - all without choking meeting calls - it really makes the internet so much better to use when you do more than one thing at once.
Re: The state of fq_codel and cake in 2022
#8Using fq_codel on ubnt edge router x and it is working really good ! Thanks for all people are involved.