[DPDK/ethdev Bug 1848] Using maximum RX descriptor causes 100% imiss

[DPDK/ethdev Bug 1848] Using maximum RX descriptor causes 100% imiss

[bugzilla]

http://bugs.dpdk.org/show_bug.cgi?id=1848

            Bug ID: 1848
           Summary: Using maximum RX descriptor causes 100% imiss
           Product: DPDK
           Version: 22.11
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: canary.overflow@gmail.com
  Target Milestone: ---

I have a server using the following setup:

NIC card:MT27800 (ConnectX-5)
DPDK version: 22.11
driver: mlx5_core
version: 5.7-1.0.2
firmware: 16.35.4506 (MT_0000000011)

Issue: 100% imiss was observed when I tried to use rx_desc=32768 (32768 is the
maximum supported by the NIC)

testpmd command:
dpdk-testpmd -l 1-10 -n 4 -a 0000:45:00.0,rxq_comp_en=1,rxq_pkt_pad_en=1 -– -i
–-max_pkt_len=4096 –-rxq=8 -–txq=8 --nb_cores=8 -–rxd=32768 -–enable_drop_en
–-enable_scatter

After tracing through the DPDK source code, I came across this code:

drivers/net/mlx5/mlx5_devx.c

/*
* For vectorized Rx, it must not be doubled in order to
* make cq_ci and rq_ci aligned.
*/
if (mlx5_rxq_check_vec_support(rxq_data) < 0)
    cqe_n *= 2;


The above code doubles the amount of CQE for non-vectorized RX and I'm not sure
if this will affect other drivers or the NIC firmware. In addition, I also saw
a few functions where `cqe_n` was assigned to a uint16_t which will cause
overflow (e.g. rxq_sync_cq(), mlx5_rx_err_handle()).

I further confirmed that imiss is not 100% in vectorized mode (MTU=1500) but
100% imiss in non-vectorized mode (MTU=4096) where rx_desc=32768.

I have also tried upgrading my setup to use the latest version of DPDK
library(25.11) but same observations were made.

As I am not very familiar with the MLX5 driver, can someone assist to check if
the doubling of rx desc from 32768 to 65536 in non-vectorized mode will result
in other issues in the NIC firmware or driver?

-- 
You are receiving this mail because:
You are the assignee for the bug.