On 3/14/23 09:59, David Marchand wrote:
On Thu, Mar 9, 2023 at 1:38 PM David Marchand <david.march...@redhat.com> wrote:
In the situation when a port was started while no virtio driver was
connected, Rx interrupts were broken.
They were also broken after a virtio driver reconnects.
There were several issues mixed in:
- this driver was not exposing a fixed file descriptor per Rx queue,
If a virtio driver was not connected yet, each Rx queue vector was
pointing at a -1 fd, and an application could interpret this as a lack
of Rx interrupt support,
- when a virtio driver later (re)connected, this net/vhost driver was
hacking into the EAL layer epoll fd to remove a old vring kickfd and
insert the new vring kickfd. This hack constitutes a layer violation
plus users of rte_eth_dev_rx_intr_ctl_q_get_fd() were not notified of
this change,
- in the case of reconnection, because the interrupt handle was
reallocated, a 0 fd was failing to be removed from the EAL layer
epoll fd, which resulted in never fixing the EAL epoll fd,
To fix Rx interrupts:
- allocating (eth_vhost_install_intr) / releasing
(eth_vhost_uninstall_intr) the interrupt handle is moved when
starting / closing the port, while setting / resetting per rxq fd is
triggered by vhost events via some new helpers (see
eth_vhost_configure_intr and eth_vhost_unconfigure_intr),
- a "proxy" epoll fd is created per Rx queue at the time the interrupt
handle is allocated, so applications can start waiting for events on
those fds, even before a virtio driver initialises,
- when available, vring kickd are populated in the "proxy" epoll fd,
Maxime, Chenbo,
Dukai confirms this series fix it, we can mark this patch as fixing:
Bugzilla ID: 1135
Do you want me to respin a series or can you fix when applying?
I can do it while preparing the pull request.
Thanks,
Maxime
Fixes: 3f8ff12821e4 ("vhost: support interrupt mode")
Fixes: 3d4cd4be577c ("net/vhost: fix interrupt mode")
Fixes: d61138d4f0e2 ("drivers: remove direct access to interrupt handle")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand <david.march...@redhat.com>
Thanks.
