DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Shijith Thotton <sthotton@marvell.com>,
	"Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>,
	Jerin Jacob <jerinjacobk@gmail.com>,
	"Hemant Agrawal" <hemant.agrawal@nxp.com>,
	Nipun Gupta <nipun.gupta@nxp.com>
Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
Date: Wed, 23 Feb 2022 10:13:05 +0000	[thread overview]
Message-ID: <BN0PR11MB5712E32BAE49D041B2E1238BD73C9@BN0PR11MB5712.namprd11.prod.outlook.com> (raw)
In-Reply-To: <SJ0PR18MB4429257EB9B65E16974ABC9BD93C9@SJ0PR18MB4429.namprd18.prod.outlook.com>

> -----Original Message-----
> From: Shijith Thotton <sthotton@marvell.com>
> Sent: Wednesday, February 23, 2022 10:02 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>; Hemant
> Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org
> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
> 
> 
> 
> >-----Original Message-----
> >From: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> >Sent: Wednesday, February 23, 2022 2:32 PM
> >To: Shijith Thotton <sthotton@marvell.com>; Van Haaren, Harry
> ><harry.van.haaren@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>; Hemant
> >Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>
> >Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org
> >Subject: [EXT] RE: [PATCH v5] app/eventdev: add crypto producer mode
> >
> >External Email
> >
> >----------------------------------------------------------------------
> >
> >
> >> -----Original Message-----
> >> From: Shijith Thotton <sthotton@marvell.com>
> >> Sent: Tuesday, February 22, 2022 12:34 PM
> >> To: Van Haaren, Harry <harry.van.haaren@intel.com>; Gujjar, Abhinandan S
> >> <abhinandan.gujjar@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> >> Hemant Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta
> >> <nipun.gupta@nxp.com>
> >> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; dev@dpdk.org
> >> Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode
> >>
> >> >> >
> >> >> > + @Van Haaren, Harry
> >> >
> >> >Hi All,
> >> >
> >> >I have been away on vacation for the last week - hence the delay in
> >> >reply on this thread.
> >> >
> >> ><snip discussion>
> >> >
> >> >> > > [1]
> >> >> > > Steps to reproduce:
> >> >> > > * Clone https://urldefense.proofpoint.com/v2/url?u=http-
> >> >3A__dpdk.org_git_next_dpdk-2Dnext-
> >> >2Deventdev&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=G9w4KsPaQLAC
> >> BfGCL
> >> >35PtiRH996yqJDxAZwrWegU2qQ&m=-yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=lZjsn2zecck8IBBQRA7fId7
> >> BXSYKk
> >> >U8Tjj10gNQLB6U&e=
> >> >> > > * Apply [v5] app/eventdev: add crypto producer mode
> >> >> > >   git-pw --server
> >> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> >> Q&r=G
> >> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >> >yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> >> SneOm
> >> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> >> > > patch apply 107645
> >> >> > > * Apply [RFC] app/eventdev: add software crypto adapter support
> >> >> > >   git-pw --server
> >> >> > > https://urldefense.proofpoint.com/v2/url?u=https-
> >> >3A__patches.dpdk.org_api_1.2_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtf
> >> Q&r=G
> >> >9w4KsPaQLACBfGCL35PtiRH996yqJDxAZwrWegU2qQ&m=-
> >> >yaLm_cvg5cKTbBy3OoUs719W-
> >> >E3ARETajJQmUvoE4aSAPjcEn1kulkRNxTn841D&s=VBQtpQ8vwHt9BnMrPLz
> >> SneOm
> >> >zhLdP5bfyLuY42fCnak&e=  --project dpdk
> >> >> > > patch apply 107029
> >> >> > > * meson x86_build_debug  -Dc_args='-g -O0' -
> >> Ddisable_drivers="*/cnxk"
> >> >> > > * ninja -C x86_build_debug
> >> >> > > * Command to reproduce crash
> >> >> > >   sudo ./x86_build_debug/app/dpdk-test-eventdev -l 0-8 -s 0xf0
> >> >> > > --vdev=event_sw0  --vdev="crypto_null" -- --prod_type_cryptodev
> >> >> > > --crypto_adptr_mode 0 --test=perf_queue --stlist=a --wlcores 1
> >> >> > > --plcores 2
> >> >
> >> >Can confirm that these steps indeed cause segfault as reported.
> >> >
> >> >In debugging, it seems like there are *zero* NEW events, and large
> >> >numbers of RELEASE events are enqueued... if so, this is not compliant to
> >> the Eventdev API.
> >> >Can somebody confirm that?
> >> >
> >> >The SW PMD is being told there are events to release, but there aren't any.
> >> >Eventually, this leads to a mismatch in credit allocations, which then
> >> >causes the IQ-chunks datastructure to corrupt.
> >> >
> >> >All in all, I'm not convinced this is a SW PMD issue yet - initial
> >> >testing points to incorrect event OP NEW/FWD/RELEASE usage. Can we
> >> >verify that the OPs being sent are correct?
> >> >
> >>
> >> Looks like an issue in crypto adapter service. The service is starting with
> >> OP_FORWARD, if RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE is set.
> >> Abhinandan can confirm.
> >
> >The service is started with what application is requesting for from the adapter.
> >The app can request either OP_NEW or FWD mode. Adapter while creating a
> new
> >instance
> >requests for evendev caps & based on that adapter enqueues events back to
> >evdev
> >in FWD or NEW mode. All events are triggered by application and adapter is
> >transparent here. Could you please explain me how this creating an issue?
> >
> 
> In lib/eventdev/rte_event_crypto_adapter.c:
> ...
> eca_ops_enqueue_burst(struct event_crypto_adapter *adapter,
> ...
>                 rte_memcpy(ev, &m_data->response_info, sizeof(*ev));
>                 ev->event_ptr = ops[i];
>                 ev->event_type = RTE_EVENT_TYPE_CRYPTODEV;
>                 if (adapter->implicit_release_disabled)
>                         ev->op = RTE_EVENT_OP_FORWARD;
>                 else
>                         ev->op = RTE_EVENT_OP_NEW;
>  ...
> 
> op and event_type is set in the service. Changing FORWARD to NEW will fix the
> crash.

Yes, I think that is true, but lets ensure we're all understanding the reason.

The crash reported occurs when events with FORWARD are sent into the SW PMD,
and later those are RELEASED. Notice, the event was never *NEW*.

Eventdev demands that when adding "new" things (e.g. events not previously seen
by the PMD) into the Eventdev instance, the type of the event must be NEW. The NEW
op type consumes "credits" in the SW PMD, and causes tracking for the NEW events.

I think that here the events *starts* with FORWARD events (should be NEW), and hence
the crash occurs, because the NEW type was never enqueued first.

Shijith suggests changing FORWARD to NEW to fix the crash, I believe that may *fix*
the crash here, but doing so without consideration for "implicit-release" mode may break
things elsewhere.

Is the better fix to ensure that any events being enqueued into Eventdev for the first time
are of a NEW type, and once circulated, either FORWARD or NEW can be used in a valid way?


> I think, we should update the spec with what all values are used in response info.
> I will remove setting op/event_type field of response info in the application.
> PMD/service can take care of it.

I'm not familiar with how the adapter/pmd/service interact - no input from me.


  reply	other threads:[~2022-02-23 10:13 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 19:53 [PATCH] " Shijith Thotton
2021-12-21  8:51 ` [PATCH v2] " Shijith Thotton
2021-12-30 11:56   ` Gujjar, Abhinandan S
2022-01-03  6:04     ` Shijith Thotton
2022-01-03  8:46       ` Gujjar, Abhinandan S
2022-01-03  9:14         ` Shijith Thotton
2022-01-04 15:28           ` Aaron Conole
2022-01-04 15:49             ` [EXT] " Shijith Thotton
2022-01-04 10:30   ` [PATCH v3] " Shijith Thotton
2022-01-21 12:25     ` Jerin Jacob
2022-01-23 16:56       ` Gujjar, Abhinandan S
2022-01-23 18:44     ` Gujjar, Abhinandan S
2022-01-24  6:09       ` Shijith Thotton
2022-01-24  6:59       ` Shijith Thotton
2022-01-25 14:15         ` Gujjar, Abhinandan S
2022-01-25 13:39       ` Gujjar, Abhinandan S
2022-02-08 17:00         ` Shijith Thotton
2022-02-14 15:26           ` Jerin Jacob
2022-02-14 15:31             ` Gujjar, Abhinandan S
2022-02-08 16:33     ` [PATCH v4] " Shijith Thotton
2022-02-15  6:03       ` Gujjar, Abhinandan S
2022-02-15 16:08         ` Shijith Thotton
2022-02-15 16:46           ` Gujjar, Abhinandan S
2022-02-15 16:56       ` [PATCH v5] " Shijith Thotton
2022-02-16  4:47         ` Gujjar, Abhinandan S
2022-02-16  7:08           ` Shijith Thotton
2022-02-16  7:49             ` Gujjar, Abhinandan S
2022-02-16  8:44               ` Jerin Jacob
2022-02-16  8:54                 ` Jerin Jacob
2022-02-17  5:33                   ` Gujjar, Abhinandan S
2022-02-21 13:10                     ` Van Haaren, Harry
2022-02-22  7:03                       ` Shijith Thotton
2022-02-23  9:02                         ` Gujjar, Abhinandan S
2022-02-23 10:02                           ` Shijith Thotton
2022-02-23 10:13                             ` Van Haaren, Harry [this message]
2022-02-23 16:33                               ` Gujjar, Abhinandan S
2022-02-23 17:02                                 ` Shijith Thotton
2022-02-17  6:56         ` [EXT] " Akhil Goyal
2022-02-18 12:00           ` Shijith Thotton
2022-02-18 12:11         ` [PATCH v6] " Shijith Thotton
2022-02-24  4:46           ` [PATCH v7] " Shijith Thotton
2022-02-24  6:18             ` Gujjar, Abhinandan S
2022-02-24  7:58               ` Jerin Jacob

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=BN0PR11MB5712E32BAE49D041B2E1238BD73C9@BN0PR11MB5712.namprd11.prod.outlook.com \
    --to=harry.van.haaren@intel.com \
    --cc=abhinandan.gujjar@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=nipun.gupta@nxp.com \
    --cc=sthotton@marvell.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).