From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7A9B0C25B67 for ; Fri, 27 Oct 2023 10:13:44 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id A85382A8FC for ; Fri, 27 Oct 2023 10:13:43 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 85C33986A95 for ; Fri, 27 Oct 2023 10:13:43 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 6E3B9986A8C; Fri, 27 Oct 2023 10:13:43 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 5E319986A8D for ; Fri, 27 Oct 2023 10:13:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: swsXnqhwML6SW0194zM2Qw-1 From: Cornelia Huck To: Parav Pandit , "Michael S. Tsirkin" Cc: Eugenio Perez Martin , "virtio-comment@lists.oasis-open.org" , "hengqi@linux.alibaba.com" , "xuanzhuo@linux.alibaba.com" , Shahaf Shuler In-Reply-To: Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: <20231025062207-mutt-send-email-mst@kernel.org> <20231026013059-mutt-send-email-mst@kernel.org> <20231026051240-mutt-send-email-mst@kernel.org> <20231026052637-mutt-send-email-mst@kernel.org> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Fri, 27 Oct 2023 12:13:27 +0200 Message-ID: <87msw4s794.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage On Thu, Oct 26 2023, Parav Pandit wrote: >> From: Michael S. Tsirkin >> Sent: Thursday, October 26, 2023 2:58 PM >> >> On Thu, Oct 26, 2023 at 09:24:06AM +0000, Parav Pandit wrote: >> > >> > > From: Michael S. Tsirkin >> > > Sent: Thursday, October 26, 2023 2:46 PM >> > >> > > > So, this will still provide the unified approach when/if needed on >> > > > other >> > > devices. >> > > >> > > What do you want to know? Whether dynamically adding/deleting queues >> > > is useful generally? For example, queue per CPU is not uncommon to >> > > avoid need for locks. In the presence of CPU hotplug, the natural >> > > thing to do is to add/delete them. >> > So for those devices who care for such performance, it is reasonable for them >> to have the cvq providing channel for complex and dynamic commands. >> >> Again, let's please not waste time adding this piecemeal to each device type, >> this is clearly a generic thing that belongs in the core. > > Maybe I didn't explain well. > > I am proposing a generic way for all device types as following. > 1. create cvq as main communication channel for resource create/destroy > 2. create resource dynamically using this cvq > > These are common commands defined across all device types in basic facilities section. > Those devices which has cvq, they define how to transport these generic defined commands. > Those devices which do not have cvq, but when they need dynamic resources, they will define and create one cvq. > As such devices will likely need more than just dynamic vq creation, for which it will need cvq anyway. I think that is too complicated: not all devices will want to add a control vq for resource management, especially if other mechanisms are already in use. Just using a generic mechanism guarded by a feature bit seems much simpler. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/