From nobody Sat May 18 08:35:46 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 17140269392991021.4595696894701; Wed, 24 Apr 2024 23:35:39 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 0A136225D; Thu, 25 Apr 2024 02:35:38 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id A95C11E4E; Thu, 25 Apr 2024 02:35:05 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 453CA1E27; Thu, 25 Apr 2024 02:35:02 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 799F21DDA for ; Thu, 25 Apr 2024 02:35:00 -0400 (EDT) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-QjOWETDnOsWOQLR9-im4ng-1; Thu, 25 Apr 2024 02:34:58 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2384E1C0F473 for ; Thu, 25 Apr 2024 06:34:58 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id C2D182166B31 for ; Thu, 25 Apr 2024 06:34:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: QjOWETDnOsWOQLR9-im4ng-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH] virnetdevbandwidth.c: Put a limit to "quantum" Date: Thu, 25 Apr 2024 08:34:57 +0200 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: 5FIMR6RKHG6G3R2GFKMAA6W7ZOSML63N X-Message-ID-Hash: 5FIMR6RKHG6G3R2GFKMAA6W7ZOSML63N X-MailFrom: mprivozn@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8"; x-default="true" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1714026939432100001 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 Reviewed-by: Peter Krempa --- 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 =3D 1500; + const unsigned long long r2q_limit =3D (1ULL << 32) -1; unsigned long long r2q; =20 /* When two or more classes compete for unused bandwidth they are each @@ -60,6 +61,11 @@ virNetDevBandwidthCmdAddOptimalQuantum(virCommand *cmd, if (!r2q) r2q =3D 1; =20 + /* 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 =3D r2q_limit; + virCommandAddArg(cmd, "quantum"); virCommandAddArgFormat(cmd, "%llu", r2q); } --=20 2.43.2 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org