On Wed, Apr 07, 2021 at 03:06:16PM +0000, Gujjar, Abhinandan S wrote: > > > > -----Original Message----- > > From: Anoob Joseph <[email protected]> > > Sent: Tuesday, April 6, 2021 8:31 PM > > To: Gujjar, Abhinandan S <[email protected]> > > Cc: [email protected]; Jerin Jacob Kollanukkaran <[email protected]>; > > [email protected]; [email protected]; > > [email protected]; [email protected]; Zhang, Roy Fan > > <[email protected]>; [email protected]; Carrillo, Erik G > > <[email protected]>; Jayatheerthan, Jay > > <[email protected]>; Pavan Nikhilesh Bhagavatula > > <[email protected]>; Van Haaren, Harry > > <[email protected]>; Akhil Goyal <[email protected]>; Shijith > > Thotton <[email protected]>; [email protected] > > 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 <[email protected]> > > > > [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]
