On Thu, Mar 10, 2022 at 2:19 PM Michael Baum <michae...@nvidia.com> wrote: > > The mlx5_rx_intr_vec_enable() function allocates queue vector and fill > FD list for Rx interrupts. > > The driver wrongly configured the FD with a non-blocking flag which > prevent waiting on this FD. > > This patch removes O_NONBLOCK flag adding.
- Maybe I deserve a Reported-by: credit on this issue. I sent a proposal to make use of Rx interrupts in OVS https://patchwork.ozlabs.org/project/openvswitch/patch/20220304161132.22065-1-david.march...@redhat.com/. And that's when I noticed that mlx5 rx fds were waking OVS too often and reported it to mlx5 maintainers. - Testing this patch by starting dpdk-l3fwd-power example (and no traffic sent at all): # strace -r -f ./dpdk-dir/v21.11/examples/dpdk-l3fwd-power --lcores 0@3,1@5 -a 0000:82:00.0 --in-memory -- -p 0x1 -P --config '(0,0,1)' ... [pid 534983] 0.000348 epoll_wait(26, [], 1, 10) = 0 [pid 534983] 0.010082 read(24, For some reason, there is an event available for fd 18 right away (which is the issue in the first place). When reading this fd, read() blocks until an actual packet is received. Then, I send exactly one packet: [pid 534983] 0.010082 read(24, "@\217:\370\21\0\0\0", 136) = 8 [pid 534983] 9.228478 epoll_wait(26, [], 1, 10) = 0 [pid 534983] 0.010082 read(24, That makes mlx5 rx interrupts unusable for an application that does more than just polling one rxq. -- David Marchand
