On 02/12/16 14:57, Bruce Richardson wrote:
On Fri, Dec 02, 2016 at 03:31:24PM +0100, Thomas Monjalon wrote:
2016-12-02 14:15, Fan Zhang:
This patch provides the initial implementation of the scheduler poll mode
driver using DPDK cryptodev framework.
Scheduler PMD is used to schedule and enqueue the crypto ops to the
hardware and/or software crypto devices attached to it (slaves). The
dequeue operation from the slave(s), and the possible dequeued crypto op
reordering, are then carried out by the scheduler.
The scheduler PMD can be used to fill the throughput gap between the
physical core and the existing cryptodevs to increase the overall
performance. For example, if a physical core has higher crypto op
processing rate than a cryptodev, the scheduler PMD can be introduced to
attach more than one cryptodevs.
This initial implementation is limited to supporting the following
scheduling modes:
- CRYPTO_SCHED_SW_ROUND_ROBIN_MODE (round robin amongst attached software
slave cryptodevs, to set this mode, the scheduler should have been
attached 1 or more software cryptodevs.
- CRYPTO_SCHED_HW_ROUND_ROBIN_MODE (round robin amongst attached hardware
slave cryptodevs (QAT), to set this mode, the scheduler should have
been attached 1 or more QATs.
Could it be implemented on top of the eventdev API?
Not really. The eventdev API is for different types of scheduling
between multiple sources that are all polling for packets, compared to
this, which is more analgous - as I understand it - to the bonding PMD
for ethdev.
To make something like this work with an eventdev API you would need to
use one of the following models:
* have worker cores for offloading packets to the different crypto
blocks pulling from the eventdev APIs. This would make it difficult to
do any "smart" scheduling of crypto operations between the blocks,
e.g. that one crypto instance may be better at certain types of
operations than another.
* move the logic in this driver into an existing eventdev instance,
which uses the eventdev api rather than the crypto APIs and so has an
extra level of "structure abstraction" that has to be worked though.
It's just not really a good fit.
So for this workload, I believe the pseudo-cryptodev instance is the
best way to go.
/Bruce
As Bruce says this is much more analogous to the ethdev bonding driver,
the main idea is to allow different crypto op scheduling mechanisms to
be defined transparently to an application. This could be load-balancing
across multiple hw crypto devices, or having a software crypto device to
act as a backup device for a hw accelerator if it becomes
oversubscribed. I think the main advantage of a crypto-scheduler
approach means that the data path of the application doesn't need to
have any knowledge that scheduling is happening at all, it is just using
a different crypto device id, which is then manages the distribution of
crypto work.
