On Thu, Nov 02, 2017 at 10:40:26AM +0100, Maxime Coquelin wrote:
> >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.
>
> FYI, Qemu v2.9.1 contains a backport of the fix.
>
> >One potential solution to this problem is to introduce a compile-time option
> >that would allow the user to [dis|en]able the
> >VHOST_USER_PROTOCOL_F_REPLY_ACK feature - is that something that would be
> >acceptable to you Maxime?
>
> Yes, that's one option, but:
> 1. VHOST_USER_PROTOCOL_F_REPLY_ACK enabled should be the default
> 2. VHOST_USER_PROTOCOL_F_REPLY_ACK disabled will be less extensively
> tested.
>
> Yuanhan, what do you think?
My suggestion is to still disable it by default. Qemu 2.7 - 2.9 (inclusive)
is a pretty big range, that I think quite many people would hit this issue.
--yliu
