From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 3DDA51B6B3 for ; Fri, 3 Nov 2017 16:34:54 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B4CD620CA6; Fri, 3 Nov 2017 11:34:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 03 Nov 2017 11:34:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=7ozgShpUoOzbcXeYUv3JYL/+Fu VX70qDZOsb9ZczApU=; b=XJD+CW+v7xAqf9qCNn7zv9CN0JDvSJmkgGvCpDEXx9 QqYWksyuHY2UQlDkP1jAJSiO/luyHnVTg73/jBxSGbPTRqRuZjlVr7Tg8Ue/cim2 0701ItipFX2xSt1Lewjye75+J7DFz7cUbkAErVQsgZgz8XV6LydnOUsajvykJ+me U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7ozgSh pUoOzbcXeYUv3JYL/+FuVX70qDZOsb9ZczApU=; b=pKu7JPxCLCjllL1GgpkZLC 2kK5Zug6J4MDw1TCOekI/OjmvxCIeX3G/abgFoy44BE+g694CClVW7IcwkuDpsYl ADHdm9Qx5dPs0WJPmLIl00aPNhZjRlZRIoVbKT7J1SwCZUZNxBFwQSA+cGfz1d9G KLfLnHmLP4vfuSNfof1ncX3MTfqJGFBtCvz/8OYLPOb/TGZUBdpG4TeINW7ORJQW xd1XDeRo8c3s1P+XAqERkv83yRL2kj79QK5di5r/+MnK1Ll/QezpuxaZ9MtnVqrJ f6GLmMJwME+b7GX4TqxCduRQs+aXWGIeBa3xrQpc1sqv6STm1KUjCKGfgba/OFlw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 63CA12494B; Fri, 3 Nov 2017 11:34:53 -0400 (EDT) From: Thomas Monjalon To: "Kavanagh, Mark B" , "yliu@fridaylinux.org" Cc: dev@dpdk.org, Maxime Coquelin , "Horton, Remy" , "Bie, Tiwei" , "mst@redhat.com" , "jfreiman@redhat.com" , "vkaplans@redhat.com" , "jasowang@redhat.com" , "Mcnamara, John" , "Loftus, Ciara" , "Stokes, Ian" Date: Fri, 03 Nov 2017 16:34:52 +0100 Message-ID: <75505790.2g3V0bmUOS@xps> In-Reply-To: References: <20171005083627.27828-1-maxime.coquelin@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 01/19] Revert "vhost: workaround MQ fails to startup" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 15:34:54 -0000 02/11/2017 10:40, Maxime Coquelin: > Hi Mark, > > On 11/01/2017 06:11 PM, Kavanagh, Mark B wrote: > > Hi Maxime, > > > > First off, apologies for the lateness of this reply - I realize that this patch has already been upstreamed. > > No worries, great to see DPDK integration being tested before v17.11 is > released. Is the v17.11 upgrade patch available somewhere? > > > Unfortunately, during OvS-DPDK regression testing for DPDK v17.11-rc2 just today, a regression involving vHost multiq was detected, and pinpointed to this patch. > > > > Version info for the components involved during the aforementioned testing is as follows: > > DPDK: v17.11-rc2 > > OvS: af2e40c ("sparse: eliminate "duplicate initialization") + DPDK v17.11 upgrade patch > > QEMU: v2.7.0 [...] > > Moving from QEMU v2.7.0 to v2.10.0 resolves the issue. However, herein lies the issue: QEMU v2.10.0 was only released in August of this year; anecdotally, we know that many OvS-DPDK customers use older versions of QEMU (typically, v2.7.0), and are likely un[able|willing] to move. With this patch, a hard dependency on QEMU v2.10 is created for users who want to use the vHU multiq feature in DPDK v17.11 (and subsequently, the upcoming OvS v2.9.0), which IMO will likely be unacceptable for many. > > Do you mean that upstream Qemu v2.7.0 is used in production? > I would expect the customers to use a distro Qemu which should contain > relevant fixes, or follow upstream's stable branches. Me too, I would expect they integrate the fixes. > FYI, Qemu v2.9.1 contains a backport of the fix. But you know, some users do not want to upgrade anything in production, as in the old time of hardware networking equipments. Curiously, the case considered here seems to be users sticked to old Qemu while willing to consider the switch as an upgradable software. It is really really strange, but let's consider such constraint. If I remember well, we have integrated the vhost multiqueue feature as soon as a Qemu release was almost ready. For the record, it was Qemu 2.5.0 (released in Dec 2015): https://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg02731.html https://wiki.qemu.org/ChangeLog/2.5#virtio And it was supported in DPDK 2.2.0 (released one day before): http://dpdk.org/ml/archives/announce/2015-December/000073.html http://dpdk.org/doc/guides/rel_notes/release_2_2.html Nowadays, Qemu 2.10 is ready to let us enable IOMMU support. But you ask to wait more. How much time should we wait? Is there a policy to agree or are we just waiting for someone to approve?