From: "Dilger, Andreas" <andreas.dilger@intel.com>
To: Tim Chen <tim.c.chen@linux.intel.com>,
Alexander Boyko <alexander_boyko@xyratex.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v4] crypto api: add crc32 pclmulqdq implementation and wrappers for table implementation
Date: Fri, 11 Jan 2013 00:39:39 +0000 [thread overview]
Message-ID: <CD14ACF3.1403F%andreas.dilger@intel.com> (raw)
In-Reply-To: <1357848481.17632.140.camel@schen9-DESK>
On 2013/10/01 1:08 PM, "Tim Chen" <tim.c.chen@linux.intel.com> wrote:
>On Thu, 2013-01-10 at 23:26 +0400, Alexander Boyko wrote:
>> 1/10/13 9:54 PM, Tim Chen пишет:
>> >
>> > On Thu, 2013-01-10 at 18:54 +0400, Alexander Boyko wrote:
>> >> From: Alexander Boyko <alexander_boyko@xyratex.com>
>> >>
>> >> This patch adds crc32 algorithms to shash crypto api. One is wrapper
>>to
>> >> gerneric crc32_le function. Second is crc32 pclmulqdq
>>implementation. It
>> >> use hardware provided PCLMULQDQ instruction to accelerate the CRC32
>>disposal.
>> >> This instruction present from Intel Westmere and AMD Bulldozer CPUs.
>> >>
>> >> For intel core i5 I got 450MB/s for table implementation and
>>2100MB/s
>> >> for pclmulqdq implementation (
>> > Alexander,
>> >
>> > Wonder if you have a chance to test performance of our PCLMULQDQ
>> > implementation for crc32c that's in the current code (see
>> > crc32c-pcl-intel-asm_64.asm). The throughput will probably be
>>comparable
>> > with your implementation.
>>
>> I have no chance to test crc32c pclmul, but I tested previous crc32c
>> implementation on crc32 instruction, the speed was about 2500 MB/s. So,
>> I think, the newest version should be faster.
>
>It will be troublesome to maintain two separate versions of PCLMUL
>crc32c code. So we should find out if there's performance benefit of
>your PCLMUL code over the one in the codebase. Testing should be
>straight forward by enabling the CRYPTO_CRC32C_INTEL option in kernel
>and inserting the crc32c-intel module.
Maybe there is some confusion here? The submitted patch is for CRC32,
while you are referring to CRC32C (note trailing "C")? Are they not
different CRC functions, or can both CRCs be computed by the same code
if there are different constants loaded?
>You may also want to add check in your glue code for support of the
>PCLMUL feature before calling the pclmul version. You probably also
>don't want to use this feature if the data size is small, as
>kernel_fpu_begin and kernel_fpu_end takes significant time. In that
>case, using the crc32c hw instructions in a loop is faster (see
>crc32c-intel_glue.c).
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
next prev parent reply other threads:[~2013-01-11 0:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50EED427.2040309@xyratex.com>
2013-01-10 14:54 ` [PATCH v4] crypto api: add crc32 pclmulqdq implementation and wrappers for table implementation Alexander Boyko
2013-01-10 17:54 ` Tim Chen
2013-01-10 19:26 ` Alexander Boyko
2013-01-10 20:08 ` Tim Chen
2013-01-10 20:26 ` Alexander Boyko
2013-01-10 21:57 ` Tim Chen
2013-01-11 0:39 ` Dilger, Andreas [this message]
2013-01-11 17:26 ` Tim Chen
2013-01-20 0:13 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD14ACF3.1403F%andreas.dilger@intel.com \
--to=andreas.dilger@intel.com \
--cc=alexander_boyko@xyratex.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=tim.c.chen@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.