[dpdk-dev] [dpdk-dev v10 2/4] cryptodev: add raw crypto data-path APIs

[Zhang, Roy Fan]

Hi Akhil,

> > rte_cryptodev_raw_configure_dp_context creates a shadow copy of the
> queue
> > pair data with in ctx, where rte_cryptodev_raw_attach_session sets the
> function
> > handler based on the session data. Using of the same PMD callback
> function is
> > to
> > save one function pointer stored in the dev_ops. If you don't like it I can
> create
> > 2 callback functions no problem.
> 
> I don't like the idea of having 2 APIs.
> 
> Why do you need to create a shadow copy of the queue data? Why it can't
> be
> Done in the attach API by the driver? In v9 it was doing that, why is it changed?
> 

The reason for creating shadow copy is for enqueue_done and dequeue_done. 
As explained if external application uses a data structure similar to
rte_crypto_sym_vec and expect all ops or no ops are enqueued/dequeued, 
it is impossible to do so with rte_cryptodev_enqueue/dequeue_burst. The
local queue pair shadow copy helps temporary caching what is already pushed
into the HW queue but the driver has yet to issue "start processing command"
to the device. Once the application finds out not all ops can be enqueued or
dequeued the temp shadow copy can be reset by issuing
rte_cryptodev_raw_configure_dp_context again. 

In v9 rte_cryptodev_raw_configure_dp_context has another job - to write the
function pointers to ctx. So if we are to use the same ctx for AES-CBC and AES-GCM but
we don't want to erase the shadow copy data again we need the "is_update" flag
to let the driver know not to erase the queue pair shadow data but updating the
function pointers only.  As you suggested in v9 "is_update" is not needed -
to avoid using "is_update" I used 2 APIs instead, one for initializing queue pair
shadow copy, one for writing function pointers by parsing the session.

Regards,
Fan