<br><br>
<div><span class="gmail_quote">On 4/13/09, <b class="gmail_sendername">Milan Broz</b> <<a href="mailto:mbroz@redhat.com">mbroz@redhat.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Tomasz Chmielewski wrote:<br>> Currently, the trend with CPUs is to add more cores rather than increase<br>
> the speed of a single core.<br>><br>> This does not scale very well with certain things in the Linux kernel.<br>> One of them is kcryptd.<br>><br>><br>> A system able to deliver data with a speed of ~200 MB/s from a RAID<br>
> array, will be only able to deliver a fraction of it (i.e. ~40 MB/s in<br>> my case) when reads are being done from a dm-crypt device.<br>><br>> This is because kcryptd is not SMP-aware: it performs all calculations<br>
> on a single logical CPU only.<br>><br>> Are there any plans to change it?<br><br>Yes, I think I already commented this in some thread,<br>there are basically 2 possible approaches:<br><br>1) create several "encryption" threads in dm-crypt (e.g. per CPU core) or<br>
2) parallelize async crypto requests processing (in crypto layer)<br><br>I have some patches for 1) but the result is not what I expected<br>- performance highly depends on write pattern for example.<br>In short, the code need more thought.</blockquote>

<div> </div>
<div>This is a golden opportunity. So many times, code (e.g. barriers) that still may "need more thought" has been rushed into production, leaving headaches that apparently last forever. I think this is a chance to get everyone in at the design stage. Can you publish a short sketch of the proposed design approaches for 1) and 2), with their advantages and drawbacks?</div>

<div> </div>
<div>Larry Dickson</div>
<div>Cutting Edge Networked Storage</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">(I tried to parallelize sector encryption _vs_ whole bio request encryption,<br>and there are still some problem with both. Also barriers and reordering<br>
of requests can be problem here.)<br><br>Another problem with 1) is what happens when there is hw acceleration -<br>multiple threads are useful only if main cpu runs encryption,<br>for hw & async crypto requests it can cause problems.<br>
<br>The crypto driver is completely transparent - dm-crypt have no idea<br>if encryption runs on main cpu or in an accelerator hw<br>(=> solution 2) is more generic).<br><br>Anyway, it is not highest priority currently... but still in slow progress.<br>
(but I guess high speed SSDs will increase priority for this too,<br>currently it is real problem only for RAID arrays:-)<br><br>Milan<br>--<br><a href="mailto:mbroz@redhat.com">mbroz@redhat.com</a><br><br>--<br>dm-devel mailing list<br>
<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/dm-devel">https://www.redhat.com/mailman/listinfo/dm-devel</a><br></blockquote></div><br>