Re: [dpdk-dev] [PATCH] vdpa/mlx5: fix notification timing

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 7/27/20 4:00 PM, Matan Azrad wrote:
> The issue is relevant only for the timer event modes: 0 and 1.
> 
> When the HW finishes to consume a burst of the guest Rx descriptors,
> it creates a CQE in the CQ.
> When traffic stops, the mlx5 driver arms the CQ to get a notification
> when a specific CQE index is created - the index to be armed is the
> next CQE index which should be polled by the driver.
> 
> The mlx5 driver configured the kernel driver to send notification to
> the guest callfd in the same time of the armed CQE event.
> It means that the guest was notified only for each first CQE in a
> poll cycle, so if the driver polled CQEs of all the virtio queue
> available descriptors, the guest was not notified again for the rest
> because there was no any new CQE to trigger the guest notification.
> 
> Hence, the Rx queues might be stuck when the guest didn't work with
> poll mode.
> 
> Remove prior kernel notification, and do manual notification after CQ
> polling.
> 
> Fixes: a9dd7275a149 ("vdpa/mlx5: optimize notification events")
> 
> Signed-off-by: Matan Azrad <matan@mellanox.com>
> Acked-by: Xueming Li <xuemingl@mellanox.com>

Applied to dpdk-next-virtio/master

Thanks,
Maxime