• Håkon Bugge's avatar
    IB/mlx4: Fix starvation in paravirt mux/demux · 7fd1507d
    Håkon Bugge authored
    The mlx4 driver will proxy MAD packets through the PF driver. A VM or an
    instantiated VF will send its MAD packets to the PF driver using
    loop-back. The PF driver will be informed by an interrupt, but defer the
    handling and polling of CQEs to a worker thread running on an ordered
    work-queue.
    
    Consider the following scenario: the VMs will in short proximity in time,
    for example due to a network event, send many MAD packets to the PF
    driver. Lets say there are K VMs, each sending N packets.
    
    The interrupt from the first VM will start the worker thread, which will
    poll N CQEs. A common case here is where the PF driver will multiplex the
    packets received from the VMs out on the wire QP.
    
    But before the wire QP has returned a send CQE and associated interrupt,
    the other K - 1 VMs have sent their N packets as well.
    
    The PF driver has to multiplex K * N packets out on the wire QP. But the
    send-queue on the wire QP has a finite capacity.
    
    So, in this scenario, if K * N is larger than the send-queue capacity of
    the wire QP, we will get MAD packets dropped on the floor with this
    dynamic debug message:
    
    mlx4_ib_multiplex_mad: failed sending GSI to wire on behalf of slave 2 (-11)
    
    and this despite the fact that the wire send-queue could have capacity,
    but the PF driver isn't aware, because the wire send CQEs have not yet
    been polled.
    
    We can also have a similar scenario inbound, with a wire recv-queue larger
    than the tunnel QP's send-queue. If many remote peers send MAD packets to
    the very same VM, the tunnel send-queue destined to the VM could allegedly
    be construed to be full by the PF driver.
    
    This starvation is fixed by introducing separate work queues for the wire
    QPs vs. the tunnel QPs.
    
    With this fix, using a dual ported HCA, 8 VFs instantiated, we could run
    cmtime on each of the 18 interfaces towards a similar configured peer,
    each cmtime instance with 800 QPs (all in all 14400 QPs) without a single
    CM packet getting lost.
    
    Fixes: 3cf69cc8 ("IB/mlx4: Add CM paravirtualization")
    Link: https://lore.kernel.org/r/20200803061941.1139994-5-haakon.bugge@oracle.comSigned-off-by: default avatarHåkon Bugge <haakon.bugge@oracle.com>
    Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
    7fd1507d
mad.c 67.3 KB