DPDK patches and discussions
 help / color / mirror / Atom feed
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.
> 


      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).