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
