From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kavanagh, Mark B" Subject: Re: [PATCH v3 01/19] Revert "vhost: workaround MQ fails to startup" Date: Fri, 3 Nov 2017 16:31:18 +0000 Message-ID: References: <20171005083627.27828-1-maxime.coquelin@redhat.com> <75505790.2g3V0bmUOS@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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" To: Thomas Monjalon , "yliu@fridaylinux.org" Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 0767E1B2DA for ; Fri, 3 Nov 2017 17:31:22 +0100 (CET) In-Reply-To: <75505790.2g3V0bmUOS@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >From: Thomas Monjalon [mailto:thomas@monjalon.net] >Sent: Friday, November 3, 2017 3:35 PM >To: Kavanagh, Mark B ; yliu@fridaylinux.org >Cc: dev@dpdk.org; Maxime Coquelin ; Horton, Re= my >; Bie, Tiwei ; mst@redhat.com; >jfreiman@redhat.com; vkaplans@redhat.com; jasowang@redhat.com; Mcnamara, J= ohn >; Loftus, Ciara ; Stokes,= Ian > >Subject: Re: [dpdk-dev] [PATCH v3 01/19] Revert "vhost: workaround MQ fail= s to >startup" > >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 t= his >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 tes= ting >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 QE= MU >(typically, v2.7.0), and are likely un[able|willing] to move. With this pa= tch, >a hard dependency on QEMU v2.10 is created for users who want to use the v= HU >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. > To be honest, I don't have hard data to back this up, apart from anecdotal = reports that "some customers use 'older' versions of QEMU". I understand that this is not the most solid foundation upon which to build= an argument. >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 Hmm, that's an interesting data point. > >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? I'm afraid that I don't have an answer for this.=20 My concern here was purely proactive - however, without concrete data to ba= ck it up, and in the light of Thomas' point regarding 2.5.0/DPDK 2.2.0, per= haps my concerns are unfounded. It may be sufficient therefore, to simply document compatible versions of Q= EMU as part of the OvS documentation. Thanks to all involved for your input, Mark