The "quantum" attribute of HTB is documented as: Number of bytes to serve from this class before the scheduler moves to the next class. Since v1.3.2-rc1~225 we compute what we think is the appropriate value and pass it on the TC command line. But kernel and subsequently TC use uint32_t to store this value. If we compute value outside of this type then TC fails and prints usage which we then interpret as an error message. Needlessly long error message. While there's not much we can do about the latter, we can put a cap on the value and stop tickling this behavior of TC. Fixes: 065054daa71f645fc83aff0271f194d326208616 Resolves: https://issues.redhat.com/browse/RHEL-34112 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/util/virnetdevbandwidth.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/util/virnetdevbandwidth.c b/src/util/virnetdevbandwidth.c index ec41666f67..7f5714a33f 100644 --- a/src/util/virnetdevbandwidth.c +++ b/src/util/virnetdevbandwidth.c @@ -46,6 +46,7 @@ virNetDevBandwidthCmdAddOptimalQuantum(virCommand *cmd, const virNetDevBandwidthRate *rate) { const unsigned long long mtu = 1500; + const unsigned long long r2q_limit = (1ULL << 32) -1; unsigned long long r2q; /* When two or more classes compete for unused bandwidth they are each @@ -60,6 +61,11 @@ virNetDevBandwidthCmdAddOptimalQuantum(virCommand *cmd, if (!r2q) r2q = 1; + /* But there's an internal limit in TC (well, kernel's implementation of + * HTB) for quantum: it has to fit into u32. Put a cap there. */ + if (r2q > r2q_limit) + r2q = r2q_limit; + virCommandAddArg(cmd, "quantum"); virCommandAddArgFormat(cmd, "%llu", r2q); } -- 2.43.2 _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
