RE: [PATCH] common/mlx5: fix QP ack timeout configuration

[Raslan Darawsheh <rasland@nvidia.com>]

Hi,

> -----Original Message-----
> From: Yajun Wu <yajunw@nvidia.com>
> Sent: Monday, February 14, 2022 8:03 AM
> To: Ori Kam <orika@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Matan Azrad <matan@nvidia.com>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>; Raslan Darawsheh <rasland@nvidia.com>; Roni
> Bar Yanai <roniba@nvidia.com>; stable@dpdk.org
> Subject: [PATCH] common/mlx5: fix QP ack timeout configuration
> 
> VDPA driver creates two QPs(1 queue pair include 1 send queue and 1
> receive queue) per virtio queue to get traffic events from NIC to SW.
> Two QPs(called FW QP and SW QP) are created as loopback QP and FW QP'SQ
> is connected to SW QP'RQ internally.
> 
> When packet receive or send out, HW will send WQE by FW QP'SQ, then SW
> will get CQE from the CQ of SW QP.
> 
> With large scale and heavy traffic, the SQ's request may fail to get ACK from
> RQ HW, because HW is busy.
> SQ will retry the request with qpc.retry_count times and each time wait for
> 4.096 uS *2^(ack_timeout) for the response. If still can’t get RQ’s HW
> response, SQ will go to an error state.
> 
> 16 is experienced value. It should not be too high or too low.
> Too high will make QP waits too long in case it’s packet drop.
> Too low will cause QP to go to an error state(retry-exceeded) easily.
> 
> Fixes: 15c3807e86a ("common/mlx5: support DevX QP operations")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Yajun Wu <yajunw@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh