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

Maxime Coquelin maxime.coquelin at redhat.com
Thu Apr 27 10:32:40 CEST 2017



On 04/27/2017 10:24 AM, Yang, Zhiyong wrote:
> Hi, Maxime:
> 
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
>> Sent: Thursday, April 27, 2017 4:05 PM
>> To: Yang, Zhiyong <zhiyong.yang at intel.com>; dev at dpdk.org
>> Cc: yuanhan.liu at linux.intel.com; Loftus, Ciara <ciara.loftus at intel.com>; Marc-
>> André Lureau <mlureau at redhat.com>
>> Subject: Re: [PATCH] vhost: fix MQ fails to startup
>>
>>
>>
>> On 04/27/2017 09:56 AM, 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.
>>
>> Oh, sorry, I get it now.
>> Are you working for a fix in Qemu, or have you already reported the problem?
> 
> I will send bug fix patch to Qemu.
> The same wrong code has also been used when Qemu2.9 introduce the MTU negotiation with DPDK.
> I will fix them at the same time in qemu.

I think the problem must be fixed generally and not per request.
Maybe in vhost_user_write() if one-time request, just clear the
VHOST_USER_NEED_REPLY flag. Then, in process_message_reply(), return
early if this flag isn't set.

But that is not enough because as said, even if fixed, the backend has
no way to know about it.

> Thanks
> Zhiyong
> 
>>
>> Thanks,
>> Maxime


More information about the dev mailing list