- Jul 06, 2005
-
-
Herbert Xu authored
This patch adds hooks for cipher algorithms to implement multi-block ECB/CBC operations directly. This is expected to provide significant performance boots to the VIA Padlock. It could also be used for improving software implementations such as AES where operating on multiple blocks at a time may enable certain optimisations. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
The VIA Padlock device is able to perform much better when multiple blocks are fed to it at once. As this device offers an exceptional throughput rate it is worthwhile to optimise the infrastructure specifically for it. We shift the existing page-sized fast path down to the CBC/ECB functions. We can then replace the CBC/ECB functions with functions provided by the underlying algorithm that performs the multi-block operations. As a side-effect this improves the performance of large cipher operations for all existing algorithm implementations. I've measured the gain to be around 5% for 3DES and 15% for AES. Signed-off-by:
-
Jesper Juhl authored
Checking a pointer for NULL before calling kfree() on it is redundant. This patch removes such checks from crypto/ Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
-
- Jun 22, 2005
-
-
Herbert Xu authored
After using this facility for a while to test my changes to the cipher crypt() layer, I realised that I should've listend to Dave and made this thing use CPU cycle counters :) As it is it's too jittery for me to feel safe about relying on the results. So here is a patch to make it use CPU cycles by default but fall back to jiffies if the user specifies a non-zero sec value. Signed-off-by:
-
Herbert Xu authored
The existing keys used in the speed tests do not pass the 3DES quality check. This patch makes it use the template keys instead. Other algorithms can supply template keys through the same interface if needed. Signed-off-by:
-
Harald Welte authored
From: Reyk Floeter <reyk@vantronix.net> I recently had the requirement to do some benchmarking on cryptoapi, and I found reyk's very useful performance test patch [1]. However, I could not find any discussion on why that extension (or something providing a similar feature but different implementation) was not merged into mainline. If there was such a discussion, can someone please point me to the archive[s]? I've now merged the old patch into 2.6.12-rc1, the result can be found attached to this email. [1] http://lists.logix.cz/pipermail/padlock/2004/000010.html Signed-off-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
-
Herbert Xu authored
It seems that bad code tends to get copied (see test_cipher_speed). So let's kill this idiom before it spreads any further. Signed-off-by:
-
Herbert Xu authored
Signed-off-by:
-
- May 23, 2005
-
-
Herbert Xu authored
The netlink gfp_any() problem made me double-check the uses of in_softirq() in crypto/*. It seems to me that we should be checking in_atomic() instead of in_softirq() in crypto_yield. Otherwise people calling the crypto ops with spin locks held or preemption disabled will get burnt, right? Signed-off-by:
-
- May 17, 2005
-
-
Patrick McHardy authored
null_encrypt() needs to copy the data in case src and dst are disjunct, null_compress() needs to copy the data in any case as far as I can tell. I joined compress/decompress and encrypt/decrypt to avoid duplicating code. Without this patch ESP null_enc packets look like this: IP (tos 0x0, ttl 64, id 23130, offset 0, flags [DF], length: 128) 10.0.0.1 > 10.0.0.2: ESP(spi=0x0f9ca149,seq=0x4) 0x0000: 4500 0080 5a5a 4000 4032 cbef 0a00 0001 E...ZZ@.@2...... 0x0010: 0a00 0002 0f9c a149 0000 0004 0000 0000 .......I........ 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 .. IP (tos 0x0, ttl 64, id 256, offset 0, flags [DF], length: 128) 10.0.0.2 > 10.0.0.1: ESP(spi=0x0e4f7b51,seq=0x2) 0x0000: 4500 0080 0100 4000 4032 254a 0a00 0002 E.....@.@2%J.... 0x0010: 0a00 0001 0e4f 7b51 0000 0002 a8a8 a8a8 .....O{Q........ 0x0020: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0030: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0040: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0050: a8a8 .. Signed-off-by:Patrick McHardy <kaber@trash.net> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- May 01, 2005
-
-
Paolo 'Blaisorblade' Giarrusso authored
We want to make possible, for the user, to enable the i586 AES implementation. This requires a restructure. - Add a CONFIG_UML_X86 to notify that we are building a UML for i386. - Rename CONFIG_64_BIT to CONFIG_64BIT as is used for all other archs - Tell crypto/Kconfig that UML_X86 is as good as X86 - Tell it that it must exclude not X86_64 but 64BIT, which will give the same results. - Tell kbuild to descend down into arch/i386/crypto/ to build what's needed. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
- Apr 16, 2005
-
-
Artem B. Bityuckiy authored
In the deflate_[compress|uncompress|pcompress] functions we call the zlib_[in|de]flateReset function at the beginning. This is OK. But when we unload the deflate module we don't call zlib_[in|de]flateEnd to free all the zlib internal data. It looks like a bug for me. Please, consider the attached patch. Signed-off-by:
Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by:
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-
