Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Daniel P. Berrange]

On Thu, Feb 09, 2017 at 07:03:57PM +0800, Longpeng (Mike) wrote:
> Hi Daniel,
> 
> On 2017/2/9 18:11, Daniel P. Berrange wrote:
> 
> > On Thu, Feb 09, 2017 at 10:58:55AM +0800, Longpeng (Mike) wrote:
> >> Hi Daniel,
> 
> 
> >>
> >> So...you prefer approach 1 with a driver-table dispatch layer, right?
> >> And this implies that we must either rename some public methods in
> >> cipher-gcrypt.c/cipher-nettle.c, or change them to 'static'.
> > 
> > I'd suggest both - renaming them to have 'gcrypt' or 'nettle' in their
> > name, and also make them static.
> > 
> 
> 
> OK.
> 
> >> I also have some other ideas:
> >>
> 
> >> 2) *maybe we need a heuristic policy*
> >>
> >> I added some speed test in test-crypto-cipher/hash and found that for big
> >> packets AF_ALG is much faster than library-impl while library-impl is 
> >> better
> >> when the packets is small:
> >>
> >> packet(bytes)      AF_ALG(MB/sec, intel QAT)       Library-impl(MB/sec)
> >> 512                53.68                           127.82
> >> 1024               98.39                           133.21
> >> 2048               167.56                          134.62
> >> 4096               276.21                          135.10
> >> 8192               410.80                          135.82
> >> 16384              545.08                          136.01
> >> 32768              654.49                          136.30
> >> 65536              723.00                          136.29
> >>
> >> If a @alg is both supported by AF_ALG and library-impl, I think we should 
> >> decide
> >> to use which one dynamically.
> > 
> > What exactly are you measuring here?
> > 
> > Is this comparing encryption of a fixed total size of data, and
> > varying the packet size. ie sending 1024 * 512 byte packets against
> > 256  * 2048 byte packages.
> > 
> > Or is it sending a constant number of packets eg 1024 * 512 byte
> > packets against 1024 * 2048 byte packets ?
> > 
> 
> 
> The testcase encrypts data for 5 seconds and then calculates how many MBs it 
> can
> encrypt per second, as below:
> 
>     g_test_timer_start();
>     do {
>         g_assert(qcrypto_cipher_setiv(cipher,
>                                       iv, niv,
>                                       &err) == 0);
> 
>         g_assert(qcrypto_cipher_encrypt(cipher,
>                                         plaintext,
>                                         ciphertext,
>                                         chunk_size,
>                                         &err) == 0);
>         total += chunk_size;
>     } while (g_test_timer_elapsed() < 5.0);
> 
>     total /= 1024 * 1024; /* to MB */
>     g_print("Testing cbc(aes128): ");
>     g_print("Encrypting in chunks of %ld bytes: ", chunk_size);
>     g_print("done. %.2f MB in %.2f secs: ", total, g_test_timer_last());
>     g_print("%.2f MB/sec\t", total / g_test_timer_last());
> 
> chunk_size = 512/1024/2048/.../65536 bytes.
> 
> Some other projects (ie. cryptodev-linux, libkcapi) also use this way to test 
> speed.

I'd be interested to know if there's any different in the results if
you put the qcrypto_cipher_setiv() call outside of the loop.

Depending on the way the API is used, you might set an IV, and then
write many chunks of data before setting the next IV.

Of course for LUKS, we set a new IV every 512 bytes of data, since IVs
are tied to disk sectors, so we'd be hitting the small chunk size
code path.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|