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"). 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]
