Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rte_eth_rx_queue_count() -95 error for Mellanox NIC and being depreciated in DPDK #724

Open
swatson314159 opened this issue Feb 2, 2021 · 3 comments

Comments

@swatson314159
Copy link

low.checkRSSPacketCount() AKA rte_eth_rx_queue_count() returns -95, error not supported, when using Mellanox ConnectX-4 NIC and NFF-Go v0.9.2. This seems to break the scheduler functionality for me. I'm experiencing packet loss without any debug counters reporting it. I'm still troubleshooting, but this intermediate error seemed worth sharing with the community.

I'm wondering about the merit of adding an error check on this DPDK API call. However, it appears this API call has been deprecated in the latest version of DPDK. So whether my problem is vendor dependent, NFF-Go needs an alternate method for getting the queue count when upgrading to the latest version of DPDK. I'm interested in doing this work, at least in my fork. Does anyone have a recommendation for the ideal DPDK method for determining queue capacity?

Side-Note: I thought maybe I introduced the error by adding DPDK Flow API support in my fork. I retested without my changes and the same error occurs. Besides a relatively small amount of packet loss, I'm getting very good performance from NFF-Go. I'll be putting in some effort this week attempting to use the latest version of DPDK and fixing my mysterious packet loss.

@vipinpv85
Copy link

Hi @swatson314159 I am not sure why the API rte_eth_queue_count is used to fetch number of supported RX queues in nff-go. Because the following is my understanding.

  1. API rte_eth_dev_info_get will get NIC level details
  2. max_rx_queues returns maximum number of RX queues that can be configured for the device
  3. nb_rx_queues returns current RX queues configured
  4. rte_eth_rx_queue_count as per DPDK documentation returns number of descriptors configured per qeueue

So if one needs the descriptor for a NIC and if rte_eth_rx_queue_count is returning as not supported; can you try using rte_eth_dev_info_get to retrieve rx_desc_lim which has min-max descirptors?

@swatson314159
Copy link
Author

It looks like I was wrong about deprecation of rte_eth_rx_queue_count since it's still part of the API in 21.02.0-rc1. I based my deprecation assertion on this thread, but maybe conditions for deprecation just haven't been reached yet. Also, I think we have a different idea of the purpose of this function. The link above describes rte_eth_rx_queue_count as:

Get the number of used descriptors of a rx queue

Mellanox does implement the API call for the version of DPDK used by NFF-Go v0.9.2 here, here and here

So now I'm out of ideas for why the -95 error code is being reported, but I'm going to try adding some printouts. I'm also planning to try the advice in this troubleshooting guide, which encouragingly mentions rte_eth_dev_info_get. I'll report back if I get it working. Thanks for your response!

@vipinpv85
Copy link

@swatson314159 I did some digging into mxl5 driver code,, only place rte_eth_rx_queue_count return -ENOTSUPP is when dev->rx_pkt_burst != mlx5_rx_burst. There can be 2 reasons for the same

  1. the user has not initialized the mxl5 and is invoking rte_eth_rx_queue_count or
  2. mxl5 is initialized with either mlx5_rx_burst_mprq or mlx5_rx_burst_vec

if latter is your case, can you try changing the code for mlx5_rx_queue_count from if (dev->rx_pkt_burst != mlx5_rx_burst) { to if ((dev->rx_pkt_burst != mlx5_rx_burst) && (mlx5_rx_burst_mprq) && (mlx5_rx_burst_vec)){

note: there might be a reason for which the mellanox driver vendors forcefully only check for single rx_burst (and not mxq or vector). But at least it is a clue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants