Hi On Tue, Oct 9, 2018 at 6:13 PM Daniel P. Berrangé <[email protected]> wrote: > > On Tue, Oct 09, 2018 at 05:59:46PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Tue, Oct 9, 2018 at 4:57 PM Daniel P. Berrangé <[email protected]> > > wrote: > > > > > > The XTS cipher mode is significantly slower than CBC mode. This series > > > approximately doubles the XTS performance which will improve the I/O > > > rate for LUKS disks. > > > > > > Daniel P. Berrangé (6): > > > crypto: expand algorithm coverage for cipher benchmark > > > crypto: remove code duplication in tweak encrypt/decrypt > > > crypto: introduce a xts_uint128 data type > > > crypto: convert xts_tweak_encdec to use xts_uint128 type > > > crypto: convert xts_mult_x to use xts_uint128 type > > > crypto: annotate xts_tweak_encdec as inlineable > > > > > > crypto/xts.c | 147 ++++++++++++++----------------- > > > tests/benchmark-crypto-cipher.c | 149 +++++++++++++++++++++++++++----- > > > 2 files changed, 191 insertions(+), 105 deletions(-) > > > > By using a constant amount of data to process, it's easier to measure > > perfomance with perf stat: > > The problem is that the different encryption modes have wildly > different performance. eg while XTS gets 400 MB/s, ECB gets > 3000 MB/s. I want the test to run long enough to minimize the > noise, and picking a data size large enough for best ECB > perf while not being excessively large for XTS is hard. THus > I prefer to have a fixed execution time for each test.
I understand, I was just giving you some nice numbers to back your patches ;) Otoh, I think having a fixed-size work for benchmark is more reliable, even if the test runs quickly. I wouldn't rely on the current benchmark results, they are quite unpredictable on my system. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Marc-André Lureau
