From nobody Mon Feb 9 23:15:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1581697615516366.946026355256; Fri, 14 Feb 2020 08:26:55 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-44-53ws-cFrNkK3mXGJxBDVxg-1; Fri, 14 Feb 2020 11:26:52 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EDF80800D5A; Fri, 14 Feb 2020 16:26:43 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B0DB889F3C; Fri, 14 Feb 2020 16:26:43 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 5F1CD8B2CC; Fri, 14 Feb 2020 16:26:43 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 01EGQY5l028542 for ; Fri, 14 Feb 2020 11:26:34 -0500 Received: by smtp.corp.redhat.com (Postfix) id CA4041001E91; Fri, 14 Feb 2020 16:26:34 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.43.2.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1E65F1001DDE; Fri, 14 Feb 2020 16:26:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581697614; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=KMMHxERKgGDj1987q9duuWLTqcShMKA+eV8Yuw3nHZ4=; b=HUJ7+Ln9SrBEjBbEnlTmy96BlBfLArdxAJoJUR5b3ms8kOdUKXnbUuZ+DG0ybveJXqYd5u JbZLOQu/FGHPvB6YhF/9gl8VPSRpKByRHDRg4v1boWa+7bnkyO7akRwT7dCdJ7snkp1Sdu aap0PcUxChbG7geVinBNS55zgZ/O2o8= From: Pavel Mores To: libvir-list@redhat.com Subject: [libvirt PATCH v2 5/6] qemu: call networkPlugBandwidth() for all types of network Date: Fri, 14 Feb 2020 17:26:23 +0100 Message-Id: <20200214162624.147825-6-pmores@redhat.com> In-Reply-To: <20200214162624.147825-1-pmores@redhat.com> References: <20200214162624.147825-1-pmores@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Cc: Pavel Mores X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: 53ws-cFrNkK3mXGJxBDVxg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" To fix the actual bug, it was necessary to make networkPlugBandwidth() be called also for 'bridge'-type networks implemented using macvtap's 'bridge' mode (previously it was only called for those implemented on top of an existing bridge). However, it seems beneficial to call it for other network types as well, at least because it removes an inconsistency in types of bandwidth configurati= on changes permissible in inactive and active domain configs. It should also = be safe as the function pretty much amounts to NOP if no QoS is requested and = the new behaviour should not be any worse than before if it is. Signed-off-by: Pavel Mores --- src/network/bridge_driver.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 72220e1c64..c8f7f07acb 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -4571,8 +4571,6 @@ networkAllocatePort(virNetworkObjPtr obj, return -1; } =20 - if (networkPlugBandwidth(obj, &port->mac, port->bandwidth, &port->= class_id) < 0) - return -1; break; =20 case VIR_NETWORK_FORWARD_HOSTDEV: { @@ -4637,8 +4635,6 @@ networkAllocatePort(virNetworkObjPtr obj, } } =20 - if (networkPlugBandwidth(obj, &port->mac, port->bandwidth, &po= rt->class_id) < 0) - return -1; break; } =20 @@ -4736,6 +4732,11 @@ networkAllocatePort(virNetworkObjPtr obj, return -1; } =20 + + if (networkPlugBandwidth(obj, &port->mac, port->bandwidth, + &port->class_id) < 0) + return -1; + if (virNetworkObjMacMgrAdd(obj, driver->dnsmasqStateDir, port->ownername, &port->mac) < 0) return -1; --=20 2.24.1