mlx5: ignore QP max_recv_wr when SRQ is used

[FujiZ]

According to the manual, max_recv_wr and max_recv_sge are ignored by ibv_create_qp if the QP is to be associated with an SRQ. Fix the bug where ibv_create_qp may return EINVAL when attr->cap.max_recv_wr > cap.max_recv_wr even if the QP is to be associated with SRQ.

The code snippet to reproduce this issue:

#include <stdio.h>
#include <stdlib.h>
#include <infiniband/verbs.h>

int main() {
    struct ibv_device **dev_list;
    struct ibv_context *context;
    struct ibv_pd *pd;
    struct ibv_srq_init_attr srq_init_attr = {0};
    struct ibv_srq *srq;
    struct ibv_qp_init_attr qp_init_attr = {0};
    struct ibv_qp *qp;

    dev_list = ibv_get_device_list(NULL);
    if (!dev_list) {
        perror("Failed to get IB devices list");
        return -1;
    }

    context = ibv_open_device(dev_list[0]);
    if (!context) {
        perror("Failed to open IB device");
        return -1;
    }

    pd = ibv_alloc_pd(context);
    if (!pd) {
        perror("Failed to allocate PD");
        return -1;
    }

    srq_init_attr.attr.max_wr  = 1;
    srq_init_attr.attr.max_sge = 1;
    srq = ibv_create_srq(pd, &srq_init_attr);
    if (!srq) {
        perror("Failed to create SRQ");
        return -1;
    }
    printf("SRQ created successfully\n");

    struct ibv_cq* cq = ibv_create_cq(context, 10, NULL, NULL, 0);
    if (!cq) {
        perror("Failed to create CQ");
        return -1;
    }

    qp_init_attr.qp_type    = IBV_QPT_RC;
    qp_init_attr.srq        = srq;
    qp_init_attr.send_cq    = cq;
    qp_init_attr.recv_cq    = cq;
    qp_init_attr.cap.max_send_wr  = 1;
    // fill in random value for max_recv_wr, which should be ignored
    qp_init_attr.cap.max_recv_wr  = UINT32_MAX;
    qp_init_attr.cap.max_send_sge = 1;
    qp_init_attr.cap.max_recv_sge = 0;

    qp = ibv_create_qp(pd, &qp_init_attr);
    if (!qp) {
        perror("Failed to create QP");
        return -1;
    }
    printf("QP created using SRQ successfully\n");
    return 0;
}

[rleon]

do we have resolution here?

[yishaih]

I would expect another general solution that will fit all drivers and close this one.

[jgunthorpe]

Maybe the general code should be zeroing the ignored fields before calling the drivers?