Hi, > -----Original Message----- > From: Yajun Wu <[email protected]> > Sent: Monday, February 14, 2022 8:03 AM > To: Ori Kam <[email protected]>; Slava Ovsiienko > <[email protected]>; Matan Azrad <[email protected]> > Cc: [email protected]; NBU-Contact-Thomas Monjalon (EXTERNAL) > <[email protected]>; Raslan Darawsheh <[email protected]>; Roni > Bar Yanai <[email protected]>; [email protected] > 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: [email protected] > > Signed-off-by: Yajun Wu <[email protected]> > Acked-by: Matan Azrad <[email protected]>
Patch applied to next-net-mlx, Kindest regards, Raslan Darawsheh
