From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "arshdeep.kaur@intel.com" <arshdeep.kaur@intel.com>,
"Gowda, Sandesh" <sandesh.gowda@intel.com>,
Reshma Pattan <reshma.pattan@intel.com>, nd <nd@arm.com>,
nd <nd@arm.com>
Subject: RE: Issues around packet capture when secondary process is doing rx/tx
Date: Tue, 9 Jan 2024 01:30:44 +0000 [thread overview]
Message-ID: <DBAPR08MB581494BD9D8BB3C4FE772CA1986A2@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20240107175900.1276c0a5@hermes.local>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, January 7, 2024 7:59 PM
> 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
>
> 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.
This is not specific to packet capture. This is a generic problem and we should look to solve it generically.
>
> 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.
Yes, would prefer this. Let the application call additional APIs to register the call backs in secondary process.
>
> 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.
>
prev parent reply other threads:[~2024-01-09 1:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 1:59 Stephen Hemminger
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 [this message]
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=DBAPR08MB581494BD9D8BB3C4FE772CA1986A2@DBAPR08MB5814.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=arshdeep.kaur@intel.com \
--cc=dev@dpdk.org \
--cc=nd@arm.com \
--cc=reshma.pattan@intel.com \
--cc=sandesh.gowda@intel.com \
--cc=stephen@networkplumber.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).