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