Re: [dpdk-dev] [PATCH v4 2/3] event/octeontx2: support crypto adapter forward mode

["Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>]

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Tuesday, April 6, 2021 8:31 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> hemant.agrawal@nxp.com; nipun.gupta@nxp.com;
> sachin.saxena@oss.nxp.com; matan@nvidia.com; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; g.singh@nxp.com; Carrillo, Erik G
> <erik.g.carrillo@intel.com>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; Akhil Goyal <gakhil@marvell.com>; Shijith
> Thotton <sthotton@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 <sthotton@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?

> 
> 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]