From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 03 Nov 2017 09:31:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,339,1505804400"; d="scan'208";a="145655210" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga004.jf.intel.com with ESMTP; 03 Nov 2017 09:31:20 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 3 Nov 2017 16:31:19 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.67]) by IRSMSX156.ger.corp.intel.com ([169.254.3.33]) with mapi id 14.03.0319.002; Fri, 3 Nov 2017 16:31:19 +0000 From: "Kavanagh, Mark B" To: Thomas Monjalon , "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" Thread-Topic: [dpdk-dev] [PATCH v3 01/19] Revert "vhost: workaround MQ fails to startup" Thread-Index: AQHTU76vC7rpfuSDo02ih6oUyiR3pqMCyxcAgAAGICA= Date: Fri, 3 Nov 2017 16:31:18 +0000 Message-ID: References: <20171005083627.27828-1-maxime.coquelin@redhat.com> <75505790.2g3V0bmUOS@xps> In-Reply-To: <75505790.2g3V0bmUOS@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODE2ODE4MmEtNzgzMS00MmYxLTg4ZmItNGEwYTQxNWQ3OWY3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJKYXhFV2RWSjlKUExuSWVOYlNhT2VIdWJRQ0hWVFc0cWFXb3R1Z0FcL0taXC9Nang1c0hXNE50RTFYa0ZVSysrQ0YifQ== dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 16:31:23 -0000 >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