On 02/26/2014 01:29 AM, Jan Beulich wrote:
>
> or it would be (with parameter order kept and argument order
> swapped)
>
> static inline u32 crc32_u32(u32 crc, u32 val)
> seed = crc32_u32(seed, *p32++);
> seed = crc32_u32(seed, tmp);
> seed = crc32_u32(se
>>> On 25.02.14 at 21:37, "H. Peter Anvin" wrote:
> On 02/25/2014 12:34 PM, Daniel Borkmann wrote:
>> On 02/25/2014 09:26 PM, H. Peter Anvin wrote:
>>> On 02/21/2014 02:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at t
On 02/25/2014 12:34 PM, Daniel Borkmann wrote:
> On 02/25/2014 09:26 PM, H. Peter Anvin wrote:
>> On 02/21/2014 02:33 AM, Jan Beulich wrote:
>>> ... to match its two callers (i.e. the alternative would have been to
>>> swap the arguments at the call sites).
>>>
>>> Signed-off-by: Jan Beulich
>>> C
On 02/25/2014 09:26 PM, H. Peter Anvin wrote:
On 02/21/2014 02:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David
On 02/21/2014 02:33 AM, Jan Beulich wrote:
> ... to match its two callers (i.e. the alternative would have been to
> swap the arguments at the call sites).
>
> Signed-off-by: Jan Beulich
> Cc: Francesco Fusco
> Cc: Daniel Borkmann
> Cc: Thomas Graf
> Cc: David S. Miller
> ---
> arch/x86/lib/
On a totally different note, it would probably be a good idea to use
intrinsics more in the kernel where possible. Intrinsics do allow the
compiler to generate better scheduling.
The trick of course is that we'd want to have machinery that can fall
back to inline assembly if the compiler does
On 02/24/2014 02:01 PM, H. Peter Anvin wrote:
On 02/24/2014 04:51 AM, H. Peter Anvin wrote:
On 02/24/2014 04:41 AM, Jan Beulich wrote:
So I'm guessing this hash is deliberately using the CRC32 instruction
"backwards", which would actually make sense: an actual CRC is actually
a pretty poor has
>>> On 24.02.14 at 14:01, "H. Peter Anvin" wrote:
> I never expected that the CRC32 operation would be commutative. Very
> fascinating.
Neither did I, which is why I was very surprised for Daniel to say that
things worked with the apparently wrong order.
Jan
--
To unsubscribe from this list:
On 02/24/2014 04:51 AM, H. Peter Anvin wrote:
On 02/24/2014 04:41 AM, Jan Beulich wrote:
So I'm guessing this hash is deliberately using the CRC32 instruction
"backwards", which would actually make sense: an actual CRC is actually
a pretty poor hash due to linearity.
OK, it really is even mo
On 02/24/2014 04:41 AM, Jan Beulich wrote:
So I'm guessing this hash is deliberately using the CRC32 instruction
"backwards", which would actually make sense: an actual CRC is actually
a pretty poor hash due to linearity.
OK, it really is even more confusing than that.
It does seem like the
>>> On 24.02.14 at 13:32, "H. Peter Anvin" wrote:
> On 02/24/2014 03:46 AM, Daniel Borkmann wrote:
>>>
>>> --- 3.14-rc3-x86-hash-crc32.orig/arch/x86/lib/hash.c
>>> +++ 3.14-rc3-x86-hash-crc32/arch/x86/lib/hash.c
>>> @@ -37,7 +37,7 @@
>>> #include
>>> #include
On 02/24/2014 12:03 AM, Jan Beulich wrote:
rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
as opposed to
static inline u32 crc32_u32(u32 crc, u32 val)
(quite obviously data <-> val and crc <-> init_val, supported
by the second argument in each caller being named "seed").
"Quite obvious
On 02/24/2014 03:46 AM, Daniel Borkmann wrote:
--- 3.14-rc3-x86-hash-crc32.orig/arch/x86/lib/hash.c
+++ 3.14-rc3-x86-hash-crc32/arch/x86/lib/hash.c
@@ -37,7 +37,7 @@
#include
#include
-static inline u32 crc32_u32(u32 crc, u32 val)
+static inline u32 crc32_u32(u32 val, u32 crc)
{
>>> On 24.02.14 at 12:46, Daniel Borkmann wrote:
> On 02/24/2014 11:53 AM, Jan Beulich wrote:
> On 24.02.14 at 11:22, Daniel Borkmann wrote:
>>> On 02/24/2014 09:03 AM, Jan Beulich wrote:
>>> On 22.02.14 at 13:09, Daniel Borkmann wrote:
> On 02/21/2014 11:33 AM, Jan Beulich wrote:
>>
On 02/24/2014 11:53 AM, Jan Beulich wrote:
On 24.02.14 at 11:22, Daniel Borkmann wrote:
On 02/24/2014 09:03 AM, Jan Beulich wrote:
On 22.02.14 at 13:09, Daniel Borkmann wrote:
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
sw
>>> On 24.02.14 at 11:22, Daniel Borkmann wrote:
> On 02/24/2014 09:03 AM, Jan Beulich wrote:
> On 22.02.14 at 13:09, Daniel Borkmann wrote:
>>> On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the
On 02/24/2014 09:03 AM, Jan Beulich wrote:
On 22.02.14 at 13:09, Daniel Borkmann wrote:
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc:
>>> On 22.02.14 at 13:09, Daniel Borkmann wrote:
> On 02/21/2014 11:33 AM, Jan Beulich wrote:
>> ... to match its two callers (i.e. the alternative would have been to
>> swap the arguments at the call sites).
>>
>> Signed-off-by: Jan Beulich
>> Cc: Francesco Fusco
>> Cc: Daniel Borkmann
>> Cc:
On 02/21/2014 11:33 AM, Jan Beulich wrote:
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c |2 +-
... to match its two callers (i.e. the alternative would have been to
swap the arguments at the call sites).
Signed-off-by: Jan Beulich
Cc: Francesco Fusco
Cc: Daniel Borkmann
Cc: Thomas Graf
Cc: David S. Miller
---
arch/x86/lib/hash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
20 matches
Mail list logo
