10/03/2022 16:12, David Marchand: > 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.
Excuse me, I don't understand this trace. What is the first read? Having a second read after epoll_wait is normal if a packet is received, isn't it?
