From: Florian Zumbiehl <[EMAIL PROTECTED]>
Date: Tue, 31 Jul 2007 13:05:47 +0200
> A few variations I tried back when I created the patch, using larger
> things than a char for accumulating the pieces and then folding down
> from that, turned out to be slower than what I finally submitted, at
> le
Hi,
> > > Actually it might be simpler and more efficient to just make
> > > PPPOE_HASH_SHIFT be 8.
> >
> > SHIFT? SIZE? BITS?
>
> You know what I meant :-)
>
> PPPOE_HASH_BITS.
Actually, I wasn't sure, for "SHIFT" looks more similar to "SIZE"
than to "BITS", plus numbers are somewhat same ord
From: Florian Zumbiehl <[EMAIL PROTECTED]>
Date: Tue, 31 Jul 2007 11:01:59 +0200
> Assuming that it was supposed to read s/head/hash/: Same disclaimers
> apply, but I'd say this considers only addr&0xff0fff0f000f and
> sid&0x0fff, so, well, yes, it's better, but still not quite what I
> think it s
Hi,
> > Erm, I'd say this not only produces different results than the old
> > version, but it also produces "wrong" results, in that it ignores quite
> > a bit of the data that's supposed to be hashed. If I didn't overlook
> > something, it only considers addr&0x0f0f0f0f0f00 and sid&0x0f0f, given
Hi,
> > -static int hash_item(unsigned long sid, unsigned char *addr)
> > +#if 8%PPPOE_HASH_BITS
> > +#error 8 must be a multiple of PPPOE_HASH_BITS
> > +#endif
>
> Since PPPOE_HASH_BITS is "4" I would think this check will break the
> build. :-)
Erm, I thought that 8 was 4*2, but maybe I didn't
From: Florian Zumbiehl <[EMAIL PROTECTED]>
Date: Tue, 31 Jul 2007 10:07:19 +0200
> Erm, I'd say this not only produces different results than the old
> version, but it also produces "wrong" results, in that it ignores quite
> a bit of the data that's supposed to be hashed. If I didn't overlook
> s
From: Florian Zumbiehl <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 08:04:23 +0200
> Hi,
>
> I'm not sure whether this is really worth it, but it looked so
> extremely inefficient that I couldn't resist - so let's hope providers
> will keep PPPoE around for a while, at least until terabit dsl ;-)
>
Hi,
I'm not sure whether this is really worth it, but it looked so
extremely inefficient that I couldn't resist - so let's hope providers
will keep PPPoE around for a while, at least until terabit dsl ;-)
The new code produces the same results as the old version and is
~ 3 to 6 times faster for 4
Hi,
I'm not sure whether this is really worth it, but it looked so
extremely inefficient that I couldn't resist - so let's hope providers
will keep PPPoE around for a while, at least until terabit dsl ;-)
The new code produces the same results as the old version and is
~ 3 to 6 times faster for 4
