[Bug 282115] GELI + QAT - 8955 performance is less than software encoding for block device acceleration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282115

Mark Johnston <markj@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markj@FreeBSD.org
             Status|New                         |Open

--- Comment #1 from Mark Johnston <markj@FreeBSD.org> ---
While a 40% hit is steep, it's not totally surprising that QAT is worse here. 
The general tradeoff of using an offload engine is that crypto request latency
will go up, but you spend less CPU resources, and offload engines, QAT in
particular, can service many requests in parallel.  That is, if your benchmark
is to dispatch one crypto request at a time, wait for it to complete, and
measure how long that takes, handling requests on the CPU will probably win
out.

Here it looks like you're dd'ing to a GELI disk device, so each I/O is getting
executed serially, i.e., you're not getting any advantage from parallelism.  Is
that right?  What kinds of numbers do you get if there is a lot of concurrent
background I/O load (e.g., from running dd loops in the background) or CPU load
(e.g., from running some CPU-intensive process, like a kernel build)?

How much CPU usage do you get in your benchmark with and without QAT?

Have you tried similar experiments using the QAT driver on Linux?  More
generally, what kinds of results were you expecting?

-- 
You are receiving this mail because:
You are the assignee for the bug.