vdpa/mlx5: fix notification timing
authorMatan Azrad <matan@mellanox.com>
Mon, 27 Jul 2020 14:00:44 +0000 (14:00 +0000)
committerFerruh Yigit <ferruh.yigit@intel.com>
Wed, 29 Jul 2020 22:41:23 +0000 (00:41 +0200)
commitca4cc612d7b0faf1b93db57e303d8ca351c97f90
tree90f059fa60339510386d9cb32f66eb534e549fa4
parentd2a58c24029ccd35f56701e774c94060904bc774
vdpa/mlx5: fix notification timing

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>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
drivers/vdpa/mlx5/mlx5_vdpa_event.c