> -----Original Message----- > From: Shijith Thotton <sthot...@marvell.com> > Sent: Wednesday, February 23, 2022 10:02 AM > To: Gujjar, Abhinandan S <abhinandan.guj...@intel.com>; Van Haaren, Harry > <harry.van.haa...@intel.com>; Jerin Jacob <jerinjac...@gmail.com>; Hemant > Agrawal <hemant.agra...@nxp.com>; Nipun Gupta <nipun.gu...@nxp.com> > Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org > Subject: RE: [PATCH v5] app/eventdev: add crypto producer mode > > > > >-----Original Message----- > >From: Gujjar, Abhinandan S <abhinandan.guj...@intel.com> > >Sent: Wednesday, February 23, 2022 2:32 PM > >To: Shijith Thotton <sthot...@marvell.com>; Van Haaren, Harry > ><harry.van.haa...@intel.com>; Jerin Jacob <jerinjac...@gmail.com>; Hemant > >Agrawal <hemant.agra...@nxp.com>; Nipun Gupta <nipun.gu...@nxp.com> > >Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org > >Subject: [EXT] RE: [PATCH v5] app/eventdev: add crypto producer mode > > > >External Email > > > >---------------------------------------------------------------------- > > > > > >> -----Original Message----- > >> From: Shijith Thotton <sthot...@marvell.com> > >> Sent: Tuesday, February 22, 2022 12:34 PM > >> To: Van Haaren, Harry <harry.van.haa...@intel.com>; Gujjar, Abhinandan S > >> <abhinandan.guj...@intel.com>; Jerin Jacob <jerinjac...@gmail.com>; > >> Hemant Agrawal <hemant.agra...@nxp.com>; Nipun Gupta > >> <nipun.gu...@nxp.com> > >> Cc: Jerin Jacob Kollanukkaran <jer...@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.
