From patchwork Thu Jan 31 11:25:40 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 217161 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 050992C007B for ; Thu, 31 Jan 2013 22:21:42 +1100 (EST) Received: from localhost ([::1]:45712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0sD5-0005sD-If for incoming@patchwork.ozlabs.org; Thu, 31 Jan 2013 06:21:39 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0sCw-0005rc-Kd for qemu-devel@nongnu.org; Thu, 31 Jan 2013 06:21:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0sCu-0003vD-1t for qemu-devel@nongnu.org; Thu, 31 Jan 2013 06:21:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0sCt-0003v7-Og for qemu-devel@nongnu.org; Thu, 31 Jan 2013 06:21:27 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0VBLRAU032165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Jan 2013 06:21:27 -0500 Received: from redhat.com (vpn1-5-97.ams2.redhat.com [10.36.5.97]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id r0VBLP3M010301; Thu, 31 Jan 2013 06:21:25 -0500 Date: Thu, 31 Jan 2013 13:25:40 +0200 From: "Michael S. Tsirkin" To: Gal Hammer Message-ID: <20130131112540.GD520@redhat.com> References: <510A2797.8070101@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <510A2797.8070101@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: amit.shah@redhat.com, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] How many msi-x vectors should be allocated for the virtio-serial device? X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Thu, Jan 31, 2013 at 10:13:11AM +0200, Gal Hammer wrote: > Hi, > > How many msi-x vectors should be allocated for the virtio-serial device? > > I'm asking this as it seems that a proposed patch > (http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02094.html) > was not accepted and I re-encountered this issue while trying to > upgrade the virtio-serial's Windows driver to use msi-x vectors. > > The virtio-serial's Linux module tries to use one vector per > virtqueue (every serial port have two virtqueues) with a fall back > to using only two vectors > (http://lxr.linux.no/linux+v3.7.2/drivers/virtio/virtio_pci.c#L539). > The problem is that qemu's virtio-pci device allocate less vectors > than the modules expects. So, for example, if a serial device have > 16 ports, 17 vectors are allocated. The module tries to use 34 > vectors, fails and choose to use only 2, leaving 15 unused vectors. > > Is it possible to increase the vectors number from > "proxy->serial.max_virtserial_ports + 1" to > "(proxy->serial.max_virtserial_ports + 1) * 2"? > > Thanks, > > Gal. Allocated MSI-X vectors on x86 are a limited resource. Let's not waste them. From what you say virtio serial works fine with two vectors and I do not see any reason to let us use more until someone can show an important workload where this helps. So I think we need something like the below, but we also need to handle 1.3 and older compatibility so the patch below shouldn't be applied. Want to try writing up the complete patch? --> serial: use 2 vectors by default Guests only utilize 2 vectors and this seems to be enough, so let's only allocate as much. serial is likely not so performance intensive to require more, but if yes users can always override the nvectors property. Signed-off-by: Michael S. Tsirkin diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index 9abbcdf..bb0f60e 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -975,8 +975,7 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev) if (!vdev) { return -1; } - vdev->nvectors = proxy->nvectors == DEV_NVECTORS_UNSPECIFIED - ? proxy->serial.max_virtserial_ports + 1 + vdev->nvectors = proxy->nvectors == DEV_NVECTORS_UNSPECIFIED ? 2 : proxy->nvectors; virtio_init_pci(proxy, vdev); proxy->nvectors = vdev->nvectors;