Hm Oregon? So at an Intel facility and basically with Intel-controlled setup? Would have liked instead: Texas. ;-)
Would also have liked a comparison of price/performance when competing against lz4- or zstd-compression. At 43 cores 8393 MB/s is shown for compression level 1. So zlib at 200 MByte/sec per core. Not too shabby, but zstd can do 500-700 MByte/s compressing and a whopping 1700 MB/s decompressing, per core. See the table on hxxs://github.com/facebook/zstd. It stands to reason that decompression speed is the more important metric, because it happens more often - compress once, read many, like in a filesystem. A 6-core CPU will beat the card. Also how about latency: Storage is latency sensitive. How much for pure assembly-optimized CPU code and how much for QAT?
For the crypto test AES128-CBC HMAC-SHA1 was chosen. Is that even secure? Wireguard would like a word. TLS 1.3 got rid of CBC because of all the padding oracle failure modes. Remember POODLE... instead of raw low-security AES tests I would have liked to see a more secure AES mode like GCM.
As for the nginx-test, why let the card shine with legacy RSA-offload. I would have liked to see a head-to-head comparison with TLS 1.3 using ECDSA for authentication, i.e. with ECDHE-ECDSA-AES256GCM as the cipher suite.
Finally, what about security? Side-channels? Who audited this card? Who audits updates? OpenSSL took a million code changes to have really time-invariant RSA or AES. Or how about the DEFLATE implementation... there could be externally supplied (compressed) data, fed into an opaque zlib-implementation by Chipzilla. Same company who brought you Meltdown and CVE-2017-5689. Same company who tells you about latest CPU exploit a year or so later, give or take. If at all.
Long version of me saying: Unless you are a legacy institution that needs to check boxes, don't buy it.
