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

[Thomas Monjalon <thomas@monjalon.net>]

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?