DPDK patches and discussions
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [Bug 996] DPDK:20.11.1: net/ena crash while fetching xstats
Date: Wed, 27 Apr 2022 11:04:37 +0000	[thread overview]
Message-ID: <bug-996-3-YFtLSsIV1q@http.bugs.dpdk.org/> (raw)
In-Reply-To: <bug-996-3@http.bugs.dpdk.org/>

https://bugs.dpdk.org/show_bug.cgi?id=996

Michal Krawczyk (mk@semihalf.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #3 from Michal Krawczyk (mk@semihalf.com) ---
Hey Amiya,

sorry for the late reply, I was OOO for one week.

Thank you for providing us with more details. 

If you aren't calling any API that needs to use the ENA admin queue from the
secondary process, the situation you're seeing shouldn't happen.

I just executed simple application on DPDK v20.11.1 in MP mode - the main
process is fetching the xstats, the secondary process is simply performing the
packets forwarding. The application is not crashing for my case.

From what I understand, the crash happens, because:

1. The ENA admin queue is not using the shared memory
2. The secondary process sends the request and saves it in the secondary
process memory
3. The primary process receives the interrupt and executes the completion
handler 
4. The completion handler cannot find the relevant request (as it's in the
secondary process memory) and the app crashes.

Please double check if:

1. The xstats aren't being fetched from the secondary process
2. You aren't calling any of API below from the secondary process, which also
uses the ENA admin queue:
  - rte_eth_dev_set_mtu()
  - rte_eth_dev_rss_reta_update()
  - rte_eth_dev_rss_reta_query()

The point 1. is much more likely as you've described it's a regression in
v20.11, and indeed - the xstats were extended after v19.11 release.

If none of the above is true, every other information that could potentially
get us closer to the core of the issue may be helpful (we can't reproduce this
on our side).

Thanks,
Michal

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

  parent reply	other threads:[~2022-04-27 11:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18  8:50 [Bug 996] PDK:20.11.1: " bugzilla
2022-04-19 20:35 ` [Bug 996] DPDK:20.11.1: " bugzilla
2022-04-27 11:04 ` bugzilla [this message]
2023-08-20 11:03 ` bugzilla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-996-3-YFtLSsIV1q@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).