Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> I thought we support intel x86 cpus in both 32 and 64bit modes...?
Yes we do, but the original patch had ugly ifdefs that did the
same thing.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Pa
On Fri 2008-08-08 21:35:30, Herbert Xu wrote:
> Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> >
> > I think you want to use
> >
> > #define SCALE_F sizeof(unsigned long)
>
> Yeah in general that's what we should do. However, this driver
> is specific to Intel x86 CPUs.
I thought we support intel
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>
> I think you want to use
>
> #define SCALE_F sizeof(unsigned long)
Yeah in general that's what we should do. However, this driver
is specific to Intel x86 CPUs.
However if someone were to post a patch to do this I would happily
apply it.
Cheers,
--
On Tue, Aug 5, 2008 at 10:23 PM, Austin Zhang
<[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_X86_64
> +#define REX_PRE "0x48, "
> +#define SCALE_F 8
> +#else
> +#define REX_PRE
> +#define SCALE_F 4
> +#endif
[...]
> +static u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
> len)
On Wed, Aug 06, 2008 at 02:14:52PM +0200, Pavel Machek wrote:
> On Wed 2008-08-06 07:05:27, Austin Zhang wrote:
> > Paval,
> >
> > Thanks for your comments.
> >
> > On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> > > Copyright / GPL?
> > Yes, as : ???+MODULE_LICENSE("GPL");
>
> Well, i
On Wed 2008-08-06 07:05:27, Austin Zhang wrote:
> Paval,
>
> Thanks for your comments.
>
> On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> > Copyright / GPL?
> Yes, as : ???+MODULE_LICENSE("GPL");
Well, it should normally go to comment at the beggining of file.
On Wed, Aug 06, 2008 at 07:17:24PM +0800, Herbert Xu wrote:
> On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote:
> >
> > > > + return -1;
> > >
> > > That's supposed to be errno, right?
> > Are you suggest "ENODEV"? It's a feature from the device but the device is
> > exa
On Wed, 2008-08-06 at 19:17 +0800, Herbert Xu wrote:
> On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote:
> >
> > > > + return -1;
> > >
> > > That's supposed to be errno, right?
> > Are you suggest "ENODEV"? It's a feature from the device but the device is
> > exact here
On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote:
>
> > > + return -1;
> >
> > That's supposed to be errno, right?
> Are you suggest "ENODEV"? It's a feature from the device but the device is
> exact here.
Yes I think this should be ENODEV to be consistent with the
existing
Paval,
Thanks for your comments.
On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> Copyright / GPL?
Yes, as : +MODULE_LICENSE("GPL");
> > +#ifdef CONFIG_X86_64
> > +#define REX_PRE "0x48, "
> > +#define SCALE_F 8
> > +#else
> > +#define REX_PRE
> > +#define SCALE_F 4
> > +#endif
>
> Ou
On Wed, Aug 06, 2008 at 11:42:26AM +0200, Pavel Machek wrote:
>
> > +static int crc32c_intel_final(struct ahash_request *req)
> > +{
> > + u32 *crcp = ahash_request_ctx(req);
> > +
> > + *(__le32 *)req->result = ~cpu_to_le32p(crcp);
> > + return 0;
>
> This is not user visible, so le32 shoul
On Wed, Aug 06, 2008 at 01:23:31AM -0400, Austin Zhang wrote:
> Revised by comments:
> Add 'static' for limitation namespace;
> Resend for fixing lines-folded by adjusting evolution config;
> (The patch was created against 2.6.27-rc1)
Applied to cryptodev-2.6. Thanks a lot Austin!
--
Visit Ope
Hi!
> ??Revised by comments:
> Add 'static' for limitation namespace;
> Resend for fixing lines-folded by adjusting evolution config;
> (The patch was created against 2.6.27-rc1)
>
> >From NHM processor onward, Intel processors can support hardware accelerated
> CRC32c algorithm with the new
Revised by comments:
Add 'static' for limitation namespace;
Resend for fixing lines-folded by adjusting evolution config;
(The patch was created against 2.6.27-rc1)
>From NHM processor onward, Intel processors can support hardware accelerated
CRC32c algorithm with the new CRC32 instruction in SS
On Tue, Aug 05, 2008 at 01:10:25PM +0200, Helge Hafting wrote:
>
> How about making crc32c an inline function then?
> On processors that have this feature, this compiles to that single
> instruction, plus whatever setup it needs. Nice and efficient.
> On other processors, either inline the algorith
On Tue, Aug 05, 2008 at 08:39:44PM +0800, Herbert Xu wrote:
> Hi Austin:
>
> On Tue, Aug 05, 2008 at 07:56:43AM -0400, Austin Zhang wrote:
> > Revised by comments:
> > Move hardware feature detect into module init;
> > Revise dependency in Kconfig;
> > Revise variable type;
> > Add information out
Hi Austin:
On Tue, Aug 05, 2008 at 07:56:43AM -0400, Austin Zhang wrote:
> Revised by comments:
> Move hardware feature detect into module init;
> Revise dependency in Kconfig;
> Revise variable type;
> Add information output while module loading failed;
>
>
> >From NHM processor onward, Intel
Revised by comments:
Move hardware feature detect into module init;
Revise dependency in Kconfig;
Revise variable type;
Add information output while module loading failed;
>From NHM processor onward, Intel processors can support hardware
accelerated
CRC32c algorithm with the new CRC32 instructi
Herbert Xu wrote:
On Tue, Aug 05, 2008 at 01:10:17AM +0800, Herbert Xu wrote:
I don't see why you couldn't do that for the crypto API too
if you wanted to. That way it would benefit all crypto users
rather than just the crc32c (note the extra c) users.
Anyway, the point here is the cr
On Tue, Aug 05, 2008 at 05:59:11AM -0400, Austin Zhang wrote:
>
> How about:
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> + depends on X86
> +select CRYPTO_ALGAPI
> +help
> + In Intel processor with SSE4.2 supported, the pro
On Mon, 2008-08-04 at 10:27 -0700, Randy Dunlap wrote:
> On Mon, 04 Aug 2008 05:35:07 -0400 Austin Zhang wrote:
>
> > diff -Naurp linux-2.6/crypto/Kconfig linux-2.6-patch/crypto/Kconfig
> > --- linux-2.6/crypto/Kconfig2008-08-04 01:08:00.0 -0400
> > +++ linux-2.6-patch/crypto/Kconf
On Mon, 2008-08-04 at 22:19 +0800, Herbert Xu wrote:
> On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
> >
> > +config CRYPTO_CRC32C_INTEL
> > +tristate "CRC32c INTEL hardware acceleration"
> > +select CRYPTO_HASH
>
> You need some sort of a dependency here. See what
On Mon, 2008-08-04 at 15:13 +0100, David Woodhouse wrote:
> Am I missing something here, or are you registering the crypto algorithm
> _unconditionally_ and then just causing init requests for it to fail on
> older hardware? Wouldn't it be better to register the driver _only_
> when the hardware i
Benoit Boissinot <[EMAIL PROTECTED]> wrote:
>
> Since I couldn't find any ahash user in the tree (outside of tcrypt.c), can
> you
> provide some example source code as to how to use it (especially
> synchonously).
>
> For example the code for the digest_null testing would be fine.
Sure, here i
On Mon, Aug 4, 2008 at 5:42 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Chris Mason <[EMAIL PROTECTED]> wrote:
>>
>>>From a performance point of view I'm probably reading the crypto API
>> code wrong, but it looks like my choices are to either have a long
>> standing context and use locking around
On Mon, 04 Aug 2008 05:35:07 -0400 Austin Zhang wrote:
> diff -Naurp linux-2.6/crypto/Kconfig linux-2.6-patch/crypto/Kconfig
> --- linux-2.6/crypto/Kconfig 2008-08-04 01:08:00.0 -0400
> +++ linux-2.6-patch/crypto/Kconfig2008-08-04 01:59:00.0 -0400
> @@ -221,6 +221,17 @@ config
On Mon, Aug 04, 2008 at 10:06:05AM -0700, Arjan van de Ven wrote:
>
> well you still have that indirect function call
>
> for libcrc32 we could alternatives() that...
I don't see why you couldn't do that for the crypto API too
if you wanted to. That way it would benefit all crypto users
rather
On Tue, Aug 05, 2008 at 01:10:17AM +0800, Herbert Xu wrote:
>
> I don't see why you couldn't do that for the crypto API too
> if you wanted to. That way it would benefit all crypto users
> rather than just the crc32c (note the extra c) users.
Anyway, the point here is the crc32c is nothing speci
On Tue, 05 Aug 2008 00:45:34 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On the other hand, one of the advantages of doing it through the
> crypto API is that this kind of selection is useful for quite a
> few operations, e.g., xor or even memcpy.
well you still have that indirect function call
Chris Mason <[EMAIL PROTECTED]> wrote:
>
> Great to hear, that solves my main concern then. There is still the
> embedded argument against needing all of crypto api just for libcrc32c.
The existing users are iSCSI, SCTP, Infiniband, all of which are
clearly crucial in the embedded space :)
> It
On Mon, 2008-08-04 at 23:42 +0800, Herbert Xu wrote:
> Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> >>From a performance point of view I'm probably reading the crypto API
> > code wrong, but it looks like my choices are to either have a long
> > standing context and use locking around the digest/ha
Chris Mason <[EMAIL PROTECTED]> wrote:
>
>>From a performance point of view I'm probably reading the crypto API
> code wrong, but it looks like my choices are to either have a long
> standing context and use locking around the digest/hash calls to protect
> internal crypto state, or create a new co
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote:
> On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote:
> > On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
> > > You could perhaps just use 'unsigned long' here, to avoid the ifdef.
> > Thanks.
> > > And it would be nice if we c
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008 22:04:35 +0800
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
>> There only three crc32c users in the kernel tree and the crypto
>> interface will serve the perfectly.
>
> isn't it a bit heavy for something as simple as a crc?
> (which a
On Mon, Aug 04, 2008 at 03:49:01PM +0100, David Woodhouse wrote:
>
> And even for people who don't care about that, it doesn't look
> particularly good. It looks like btrfs would need either to keep setting
> up a crypto context and then tearing it down, or have a pool of
> long-standing contexts a
On Mon, 2008-08-04 at 07:20 -0700, Arjan van de Ven wrote:
> On Mon, 4 Aug 2008 22:04:35 +0800
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> > There only three crc32c users in the kernel tree and the crypto
> > interface will serve the perfectly.
>
> isn't it a bit heavy for something as simple as
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
>
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> +select CRYPTO_HASH
You need some sort of a dependency here. See what the other
assembly algorithms do it.
Cheers,
--
Visit Openswan a
On Mon, 4 Aug 2008 22:04:35 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> There only three crc32c users in the kernel tree and the crypto
> interface will serve the perfectly.
isn't it a bit heavy for something as simple as a crc?
(which after all is one instruction now ;0)
--
If you want to r
On Mon, Aug 04, 2008 at 03:13:34PM +0100, David Woodhouse wrote:
>
> > +static int __init crc32c_intel_mod_init(void)
> > +{
> > + return crypto_register_alg(&alg);
> > +}
> > +
>
> Am I missing something here, or are you registering the crypto algorithm
> _unconditionally_ and then just causing
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
>
> +static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
> +{
> + u32 *key = crypto_tfm_ctx(tfm);
> +
> + *key = ~0;
> +
> + tfm->crt_ahash.reqsize = sizeof(u32);
> +
> + if (cpu_has_xmm4_2)
> + return 0;
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
> +static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
> +{
> + u32 *key = crypto_tfm_ctx(tfm);
> +
> + *key = ~0;
> +
> + tfm->crt_ahash.reqsize = sizeof(u32);
> +
> + if (cpu_has_xmm4_2)
> + return 0;
> +
On Mon, Aug 04, 2008 at 11:45:26AM +0100, David Woodhouse wrote:
>
> Are we deprecating libcrc32c, then? Or just turning it into a wrapper
> around the crypto code?
It will be removed.
> Either way, does it really make sense to force all crc32 users to pull
> in the whole crypto framework? Some
On Mon, 2008-08-04 at 06:58 -0400, Austin Zhang wrote:
> BTW, why did I always got each email on this thread twice:(? (the same
> email twice)
You're probably subscribed to the linux-kernel list, and you're also
being Cc'd directly.
Normally, your filters should notice the copy which has a Retur
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote:
> Are we deprecating libcrc32c, then? Or just turning it into a wrapper
> around the crypto code?
Maybe I can pick up crc32c_intel_le_hw_byte and crc32c_intel_le_hw
into
one arch-related file and make the current new crypto interface and
On Mon, Aug 04, 2008 at 12:25:57PM +0200, Sebastian Siewior wrote:
>
> I'm not sure if I remeber correctly but I thing Herbert was planning to
> convert all users over to the crypto API to avoid compile time
> dependency.
Yes that's the plan. I've been busy with the crypto testing
stuff but I'll
On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote:
> On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
> > You could perhaps just use 'unsigned long' here, to avoid the ifdef.
> Thanks.
> > And it would be nice if we could make libcrc32c use this too, rather
> > than just the 'crypto'
On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote:
> You could perhaps just use 'unsigned long' here, to avoid the ifdef.
Thanks.
> And it would be nice if we could make libcrc32c use this too, rather
> than just the 'crypto' users.
>From previous discussing, herbert would like to transfer
On Mon, 2008-08-04 at 12:25 +0200, Sebastian Siewior wrote:
> * David Woodhouse | 2008-08-04 11:12:05 [+0100]:
> >And it would be nice if we could make libcrc32c use this too, rather
> >than just the 'crypto' users.
>
> I'm not sure if I remeber correctly but I thing Herbert was planning to
> conv
* David Woodhouse | 2008-08-04 11:12:05 [+0100]:
>On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
>> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
>> len)
>> +{
>> + unsigned int iquotient = len / SCALE_F;
>> + unsigned int iremainder = len % SCALE_F;
>>
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
> len)
> +{
> + unsigned int iquotient = len / SCALE_F;
> + unsigned int iremainder = len % SCALE_F;
> +#ifdef CONFIG_X86_64
> + u64 *ptmp = (u64 *)p;
>
>From Nehalem processor onward, Intel processors can support hardware
accelerated CRC32c algorithm with the new CRC32 instruction in SSE 4.2
instruction set.
The patch detects the availability of the feature, and chooses the
most proper way to calculate CRC32c checksum.
Byte code instructions ar
51 matches
Mail list logo
