Hi Stephen,
Does this explain the results you were seeing earlier with the memstore
testing?
Mark
On 01/26/2015 12:00 PM, Blinick, Stephen L wrote:
Good to know, I was wondering why the spec file defaulted to lib-nss.. the dpkg-build for debian packages just uses whatever configuration you had built, and I believe that will use libcryptopp if the dependency is installed on the build machine (last I looked).
I forgot to mention the numbers below were based on v.91.
Thanks,
Stephen
-----Original Message-----
From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil
Sent: Monday, January 26, 2015 10:24 AM
To: Blinick, Stephen L
Cc: andreas.bluemle@xxxxxxxxxxx; ceph-devel@xxxxxxxxxxxxxxx
Subject: RE: wip-auth
On Mon, 26 Jan 2015, Blinick, Stephen L wrote:
I noticed that the spec file for building RPM's defaults to building with libnss, instead of libcrypto++. Since the measurements I'd done so far were from those RPM's I rebuilt with libcrypto++.. so FWIW here is the difference between those two on my system, memstore backend with a single OSD, and single client.
Dual socket Xeon E5 2620v3, 64GB Memory, RHEL7
Kernel: 3.10.0-123.13.2.el7
100% 4K Writes, 1xOSD w/ Rados Bench
libnss | Cryptopp
# QD IOPS Latency(ms) | IOPS Latency(ms) IOPS Improvement %
16 14432.57 1.11 | 18896.60 0.85 30.93%
100% 4K Reads, 1xOSD w/ Rados Bench
libnss | Cryptopp # QD IOPS Latency(ms) | IOPS Latency(ms) IOPS
Improvement % 16 19532.53 0.82 | 25708.70 0.62 31.62%
Yikes, 30%! I think this definitely worth some effort. We switched to libnss because it has the weird government certfiications that everyone wants and is more prevalent. crypto++ is also not packaged for Red Hat distros at all (presumably for that reason).
I suspect that most of the overhead is in the encryption context setup and can be avoided with a bit of effort..
sage
Thanks,
Stephen
-----Original Message-----
From: ceph-devel-owner@xxxxxxxxxxxxxxx
[mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Sage Weil
Sent: Thursday, January 22, 2015 4:56 PM
To: andreas.bluemle@xxxxxxxxxxx
Cc: ceph-devel@xxxxxxxxxxxxxxx
Subject: wip-auth
Hi Andreas,
I took a look at the wip-auth I mentioned in the security call last week... and the patch didn't work at all. Sorry if you wasted any time trying it.
Anyway, I fixed it up so that it actually worked and made one other optimization. It would be great to hear what latencies you measure with the changes in place.
Also, it might be worth trying --with-cryptopp (or --with-nss if you
built cryptopp by default) to see if there is a difference. There is
a ton of boilerplate setting up encryption contexts and key structures
and so on that I suspect could be cached (perhaps stashed in the
CryptoKey struct?) with a bit of effort. See
https://github.com/ceph/ceph/blob/master/src/auth/Crypto.cc#L99-L213
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel"
in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
