From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Cc: arshdeep.kaur@intel.com, "Gowda,
Sandesh" <sandesh.gowda@intel.com>,
Reshma Pattan <reshma.pattan@intel.com>
Subject: Issues around packet capture when secondary process is doing rx/tx
Date: Sun, 7 Jan 2024 17:59:00 -0800 [thread overview]
Message-ID: <20240107175900.1276c0a5@hermes.local> (raw)
I have been looking at a problem reported by Sandesh
where packet capture does not work if rx/tx burst is done in secondary process.
The root cause is that existing rx/tx callback model just doesn't work
unless the process doing the rx/tx burst calls is the same one that
registered the callbacks.
An example sequence would be:
1. dumpcap (or pdump) as secondary tells pdump in primary to register callback
2. secondary process calls rx_burst.
3. rx_burst sees the callback but it has pointer pdump_rx which is not necessarily
at same location in primary and secondary process.
4. indirect function call in secondary to bad location likely causes crash.
Some possible workarounds.
1. Keep callback list per-process: messy, but won't crash. Capture won't work
without other changes. In this primary would register callback, but secondaries
would not use them in rx/tx burst.
2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have
a capture flag. (i.e. don't use indirection). Likely ABI problems.
Basically, ignore the rx/tx callback mechanism. This is my preferred
solution.
3. Some fix up mechanism (in EAL mp support?) to have each process fixup
its callback mechanism.
4. Do something in pdump_init to register the callback in same process context
(probably need callbacks to be per-process). Would mean callback is always
on independent of capture being enabled.
5. Get rid of indirect function call pointer, and replace it by index into
a static table of callback functions. Every process would have same code
(in this case pdump_rx) but at different address. Requires all callbacks
to be statically defined at build time.
The existing rx/tx callback is not safe id rx/tx burst is called from different process
than where callback is registered.
next reply other threads:[~2024-01-08 1:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 1:59 Stephen Hemminger [this message]
2024-01-08 10:41 ` Morten Brørup
2024-04-03 11:43 ` Ferruh Yigit
2024-01-08 15:13 ` Konstantin Ananyev
2024-01-08 17:02 ` Stephen Hemminger
2024-01-08 17:55 ` Stephen Hemminger
2024-01-09 23:06 ` Stephen Hemminger
2024-01-09 23:07 ` Stephen Hemminger
2024-04-03 12:11 ` Ferruh Yigit
2024-01-10 20:11 ` Konstantin Ananyev
2024-04-03 12:20 ` Ferruh Yigit
2024-04-04 13:26 ` Konstantin Ananyev
2024-04-04 14:28 ` Ferruh Yigit
2024-04-04 15:21 ` Stephen Hemminger
2024-04-04 16:18 ` Konstantin Ananyev
2024-04-03 0:14 ` Stephen Hemminger
2024-04-03 11:42 ` Ferruh Yigit
2024-01-09 1:30 ` Honnappa Nagarahalli
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=20240107175900.1276c0a5@hermes.local \
--to=stephen@networkplumber.org \
--cc=arshdeep.kaur@intel.com \
--cc=dev@dpdk.org \
--cc=reshma.pattan@intel.com \
--cc=sandesh.gowda@intel.com \
/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).