RE: [EXT] [dpdk-dev v5] lib/cryptodev: multi-process IPC request handler

[Akhil Goyal <gakhil@marvell.com>]

> As some cryptode PMDs have multiprocess support, the secondary
> process needs queue-pair to be configured by the primary process before
> to use. This patch adds an IPC register function to help the primary
> process to register IPC action that allow secondary process to configure
> cryptodev queue-pair via IPC messages during the runtime.

Why are we forcing user another alternate API for secondary process to work?
Can we not register the IPC inside rte_cryptodev_queue_pair_setup() ?

As I understand till now, 
You have introduced another API rte_cryptodev_mp_request_register(),
Which will be called by application if primary-secondary communication is required.
And if it is registered, rte_cryptodev_ipc_request() will be called from somewhere(not sure when this will be called).
And the call to rte_cryptodev_queue_pair_setup() from the secondary will do nothing.

Is this a correct understanding? If it is correct, then it is an unnecessary overhead for the application.
We should update the rte_cryptodev_queue_pair_setup instead to handle primary and secondary configuration.
IMO, you do not need to change anything in the library.
Everything can be handled in the PMD. When the queue_pair_setup is called for particular qp_id,
Store the getpid() of the calling process into the priv data of queue pair if it is not already configured
And if configured return failure.
And in case of release you can also check the same.

The configuration of queues for multi process is specific to PMDs.
There may be PMDs which may support same queue pair to be used by different processes.
Rx queue from the qp by one process and Tx queue from the qp by another process.
This will be needed if one process is doing only enqueue and the other only dequeue on the same qp.
So in that case, your implementation will not work.

> After setup, a new "qp_in_used_pid" param stores the PID to provide
> the ownership of the queue-pair so that only the PID matched queue-pair
> free request is allowed in the future.
> 
qp_in_used_pid looks very cryptic, I believe this should be part of queue pair private data of PMD.
Adding this in cryptodev data is not justified. This property is per queue and not per crypto device.
Hence adding in device data does not make sense to me.