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