Re: [dpdk-dev] [PATCH v3 01/19] Revert "vhost: workaround MQ fails to startup"

["Kavanagh, Mark B" <mark.b.kavanagh@intel.com>]

>From: Thomas Monjalon [mailto:thomas@monjalon.net]
>Sent: Friday, November 3, 2017 3:35 PM
>To: Kavanagh, Mark B <mark.b.kavanagh@intel.com>; yliu@fridaylinux.org
>Cc: dev@dpdk.org; Maxime Coquelin <maxime.coquelin@redhat.com>; Horton, Remy
><remy.horton@intel.com>; Bie, Tiwei <tiwei.bie@intel.com>; mst@redhat.com;
>jfreiman@redhat.com; vkaplans@redhat.com; jasowang@redhat.com; Mcnamara, John
><john.mcnamara@intel.com>; Loftus, Ciara <ciara.loftus@intel.com>; Stokes, Ian
><ian.stokes@intel.com>
>Subject: Re: [dpdk-dev] [PATCH v3 01/19] Revert "vhost: workaround MQ fails 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 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.
>

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. 
My concern here was purely proactive - however, without concrete data to back it up, and in the light of Thomas' point regarding 2.5.0/DPDK 2.2.0, perhaps my concerns are unfounded.

It may be sufficient therefore, to simply document compatible versions of QEMU as part of the OvS documentation.

Thanks to all involved for your input,
Mark