[dpdk-dev] [PATCH] vhost: fix MQ fails to startup

Maxime Coquelin maxime.coquelin at redhat.com
Thu Apr 27 10:52:20 CEST 2017

On 04/27/2017 10:20 AM, Yuanhan Liu wrote:
> On Thu, Apr 27, 2017 at 09:56:47AM +0200, Maxime Coquelin wrote:
>> Hi Zhiyong,
>> +Marc-André
>> On 04/27/2017 08:34 AM, Zhiyong Yang wrote:
>>> vhost since dpdk17.02 + qemu2.7 and above will cause failures of
>>> new connection when negotiating to set MQ. (one queue pair works
>>> well).Because there exist some bugs in qemu code when introducing
>>> VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. when dealing with the vhost
>>> message VHOST_USER_SET_MEM_TABLE for the second time, qemu indeed
>>> doesn't send the messge (The message needs to be sent only once)but
>>> still will be waiting for dpdk's reply ack, then, qemu is always
>>> freezing. DPDK code works in the right way.
>> I'm looking at Qemu's vhost_user_set_mem_table() function, but fail to
>> see how it could wait for the reply-ack if it didn't send the
>> VHOST_USER_SET_MEM_TABLE request before.
>>> But the feature
>>> VHOST_USER_PROTOCOL_F_REPLY_ACK has to be disabled by default at the
>>> dpdk side in order to avoid the feature support of DPDK + qemu at
>>> the same time. if doing like that, MQ can works well. Once Qemu bugs
>>> have been fixed and upstreamed, we can enable it.
>> The problem is for DPDK to detect whether bug is fixed in Qemu.
>> Maybe only way would be to have a new protocol feature flag, which is
>> not really its role.
> Wouldn't that be an overkill, judging that REPLY_ACK is not a must
> feature?

Yes, maybe. But it was introduced to fix (possible) race conditions:

Note that I planned to use this feature for the device IOTLB
implementation to let the backend decide whether it wants the IOTLB
misses synchronous or asynchronous. But I can still change the protocol
spec to make this behavior specific to this request.

> 	--yliu

More information about the dev mailing list