On Mon, Sep 08, 2008 at 01:44:55PM +0200, Milan Broz wrote: > Current status is (after some recent discussion): > - dm-crypt need mechanism to add more than one encryption thread > - # of threads should be configurable (maybe even runtime using dm message) > - implementation must support planned barrier support for device-mapper > > (Also note, if there is any hw doing the encryption, more threads become > ineffective - it is limited by crypto hw capabilities, not by main processors > count.) > > So already on TODO, but not with the highest priority:-) Hi, Since it seems from recent posts to this list that there are many people who are interested in having this feature (and I'm one of them), and at least I would be willing to pledge some money for implementing this feature, I'm considering starting a project for this on http://micropledge.com/ (that's what I found after some googling, let me know if there's something better - although their terms seem very reasonable, it's free for OSS projects save for Paypal fees). Before doing that, I'd like however your (where "you" includes potential pledgers, potential implementers and those dm-crypt developers that are not interested in taking the project) input on at least: 1. Whether you think the idea of a pledge fund for implementing multi-threaded crypto in dm-crypt for one device is constructive at all? If all this does is start a flame war and alienate developers, it's probably best that we forget the idea. 2. What should the requirements be? The form for starting a fund (or a "project" in micropledge terms) is at http://micropledge.com/dream . (Note: I wonder if and how the micropledge.com system works for a group of developers willing to take the job together.) For requirements, I'm thinking along the lines of: a. It must be good enough that it can be accepted by the dm-crypt team for inclusion in dm-crypt proper, and it at least must have no substantial issues why it would never be accepted by kernel developers; (Note: This probably subsumes many smaller issues, like maintainability and issues like those listed in the above quotation by Milan Broz; however I feel those things are best left open in this spec for further discussion and consensus by the dm-crypt developers.) b. It must be licensed so to be legally includable in the kernel (i.e. compatible with GPLv2); c. It must show performance improvement when running on an SMP computer, even if only in an artifical benchmark, assuming that disk is fast enough to not be a problem. To show that it utilizes multiple processors, it needs to be demonstrated that: i. On a dual core computer (say, Intel Core 2), the performance is at least 1.3x the performance of the current implementation on a single core of the same computer; ii. On a quad core computer, the performance is at least 2.3x the performance of the current implementation on a single core of the same computer; and iii. From a technical point of view, it is reasonable to say that the performance gains come from using multiple CPUs or cores and not from single-threaded code optimizations. (Note: I think the 1.3x and 2.3x requirements should not be very hard, but essentially they demonstrate that the implementation really uses multiple CPUs to its advantage, and if it's good enough to also pass requirement (a), well, at least it's a beginning.) What do you think? Sami --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
