On Wed, Apr 07, 2021 at 03:06:16PM +0000, Gujjar, Abhinandan S wrote: > > > > -----Original Message----- > > From: Anoob Joseph <ano...@marvell.com> > > Sent: Tuesday, April 6, 2021 8:31 PM > > To: Gujjar, Abhinandan S <abhinandan.guj...@intel.com> > > Cc: tho...@monjalon.net; Jerin Jacob Kollanukkaran <jer...@marvell.com>; > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; > > sachin.sax...@oss.nxp.com; ma...@nvidia.com; Zhang, Roy Fan > > <roy.fan.zh...@intel.com>; g.si...@nxp.com; Carrillo, Erik G > > <erik.g.carri...@intel.com>; Jayatheerthan, Jay > > <jay.jayatheert...@intel.com>; Pavan Nikhilesh Bhagavatula > > <pbhagavat...@marvell.com>; Van Haaren, Harry > > <harry.van.haa...@intel.com>; Akhil Goyal <gak...@marvell.com>; Shijith > > Thotton <sthot...@marvell.com>; dev@dpdk.org > > Subject: RE: [PATCH v4 2/3] event/octeontx2: support crypto adapter > > forward mode > > > > Hi Abhinandan, > > > > Please see inline. > > > > Thanks, > > Anoob > > > > > > > > > > Advertise crypto adapter forward mode capability and set crypto > > > > adapter enqueue function in driver. > > > > > > > > Signed-off-by: Shijith Thotton <sthot...@marvell.com> > > > > [snip] > > > > > > + > > > > + if (!ev->sched_type) > > > > + otx2_ssogws_head_wait(tag_op); > > > > + if (qp->ca_enable) > > > > + return cdev->enqueue_burst(qp, &crypto_op, 1); > > > > + > > > > +free_op: > > > > + rte_pktmbuf_free(crypto_op->sym->m_src); > > > > + rte_crypto_op_free(crypto_op); > > > > + return 0; > > > > +} > > > > > > I am trying to understand this in requirement perspective. This > > > enqueue function is same as SW adapter's enqueue function. > > > Currently, application could directly enqueue to cryptodev in NEW > > > mode. By having this in PMD, how is FORWARD mode taken care? > > > > > > > [Anoob] Difference is the ordering point when used with ORDERED flows. > > > > If application is working on an ORDERED flow, with OP_NEW, application > > would require to queue to an ATOMIC queue before submitting to cryptodev > > (to maintain ordering). But with OP_FORWARD, application can provide an > > event to the event PMD and internally it can take care of ordering as well > > enqueue to crypto "hardware". This becomes particularly useful when event > > hardware can support ordering while enqueueing to crypto hardware(and > > hence the "internal port"). > Got it. > Referring to the above code, if qp->ca_enable is not enabled, the ops and > mbuf will be freed and returned 0. Does not this make the application/worker > to think that enqueue is not successful and it should retry enqueuing same > buffers again? >
Thanks for pointing out. Will use proper error number for failures in next version. > > > > With the current spec, OP_FORWARD would allow application to enqueue > > crypto_op as an event to event device. But this event doesn't have any > > additional information which would indicate it is destined to crypto. The > > new API would solve this issue. > > > > [snip]
