Conversation
|
Looks good, however I have a question, if for testing I want to enforce single queue cake how do I do this? |
|
Also MQ_IFB seems purely informational, could we make this a tri state instead where an initial -1 means force single queue? and 0 means auto select the cake variant. I am all for the automatic selection, I just want a simple way to switch this off easily while helping others debug their sqm setup. |
|
moeller0 ***@***.***> writes:
moeller0 left a comment (tohojo/sqm-scripts#181)
Looks good, however I have a question, if for testing I want to
enforce single queue cake how do I do this?
Hmm, yeah, maybe we should make this configurable... Will push an update...
|
Add support for creating IFB devices with one queue per CPU in the system, if the USE_MQ config variable is set. This will be used to support installing the cake_mq qdisc on ingress. The USE_MQ variable defaults to 1 and can be set from configuration to turn off the use of MQ. However, .qos scripts must also declare their support for using multi-queue devices before sourcing defaults.sh, or it will be turned off. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
|
Also MQ_IFB seems purely informational, could we make this a tri state
instead where an initial -1 means force single queue? and 0 means auto
select the cake variant. I am all for the automatic selection, I just
want a simple way to switch this off easily while helping others debug
their sqm setup.
See the updated version, which supports this :)
|
|
This looks pretty nice! I have a question though (something I will try to test eventually) Assume a 2 core machine for simplicity, ewhere each core is able to shape up to 50% of total capacity well, but, as cake dies, will show increasing latency when trying to sahape > 50%. Now with mukltiple flows that hash well between the queues even at close to 100% each core will be around its comfort zone of 50%. But in the degenerate case of a single bulk flow we can end up in a situation where one core tries to shape >> 50% and that cake instance will end outside its comfort zone with large RTT increases. So I wolnder does cake_mq already have or should it grow a maximum_rate_per_core safety toggle? |
Support automatically selecting cake_mq in the layer_cake and piece_of_cake QoS scripts. On egress, cake_mq will be used if the device has multiple queues. On ingress, set MQ_IFB to ensure that the IFB devices are created as multi-queue, which will also allow us to use cake_mq there. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
| name=$1 | ||
| args= | ||
|
|
||
| num_procs=$(grep -c processor /proc/cpuinfo) |
There was a problem hiding this comment.
Probably this should only count 'real' cores, not threads. E.g. still very common mt7621 will report 4 CPUs in this case.
Add the required patches in order to backport cake-mq from Linux 7.0. Many thanks to Toke Høiland-Jørgensen for providing the git trees with backports for both 6.12 and 6.18. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> Link: #21964 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (cherry picked from commit 105eb9c)
3 participants
This PR adds support of automatically selecting cake_mq where appropriate, when
using the layer_cake and piece_of_cake QoS scripts.