This actually allows malloc bdev to chain multiple accel operations
together. And, since the last operation will always be a copy, accel
should remove that copy by modifying previous operation's dst/src.
On my system, it improved bdevperf performance (single core, qd=4,
bs=128k, bdev_crypto on top of bdev_malloc, crypto_sw):
randread: 5668M/s -> 8201M/s
randwrite: 5148M/s -> 7856M/s
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I5b9173fa70a42ee56f56c496a34037d46d2f420f
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17202
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
This only changes the interface bdev_malloc uses for scheduling the copy
to appends, but it won't chain those copies to an existing sequence, as
bdev_malloc doesn't report support for accel sequences yet. That will
be changed in one of the subsequent patches.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I6db2c79b15cb96a1b07c6cf5514004c76b9d2e92
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17198
Community-CI: Mellanox Build Bot
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@nvidia.com>
This test sends several read/write requests and verifies the expected
number of accel operations have been executed.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: Idda46ef00dc5bcc0a176d3dfb39f3f3861964741
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17193
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Aleksey Marchuk <alexeymar@nvidia.com>
