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

[Shijith Thotton]

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