3 ms·
Fair queuing would be extremely difficult to support while maintaining overall peak performance. Way too much shared state.
by xxpor 3y ago
Fair queuing would be extremely difficult to support while maintaining overall peak performance. Way too much shared state.
- mhandley 3y agoI can think of ways to approximate FQ on an input-queued switch while maintaining performance, but it doesn't really help because the total number of queues being a function of the traffic still opens you up to resource exhaustion attacks.
- muxamilian 3y agoFair queuing shouldn't be necessary in the core. If every base station/WiFi router/client device support fair queuing that should be enough.
- dtaht 3y agoI think FQ helps everywhere, and FQ + aqm is needed at every fast->slow transition on the network. Ideally the core is over provisioned... except where it is not.
- dtaht 3y agoPushing CAKE to 10Gbit/xeon core in libreqos currently (the bottleneck is on the read path actually). Or, 10k ISP subscribers per $2k xeon box.
- xxpor 3y ago10 gbit per xeon core is bad though
- dtaht 3y agoThe bottleneck is mostly on the read path,even leveraging xdp heavily. dpdk/vpp would be faster. In the case however of an ISP 10k subscribers/network segment at 25Gbit is more than enough and busies 40% of 20 cores, on libreqos. Others are making boxes capable of more using smarter ethernet cards. If only more ISPs cared about QoE, we could cause a run on ebay on slightly obsolete Xeons and finish up fixing the bufferbloat problem right quick!