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?
--yliu
