On Sat, 2006-03-11 at 09:01 -0500, jamal wrote:
> > sample never worked 100% of the time with that hash. It works _most_ of
> > the time with 256 buckets. Infact it will work some of the time as it is
> > right now with 2.6.x. Can you post the output of tc -s filter ls on 2.6
> > with and without your user space change?
> > 
> > Heres how you should fix this:
> > Patch1) fix kernel 2.4.x to be like 2.6.x
> > patch 2) fix iproute2 to have the same syntax as for 2.6 and put a big
> > bold note in the code that if anyone changes that part of the code to
> > look at the kernel u32_hash_fold() routine.
> > no need for the utsname check.
> 
> Just played a little with it: Even for 2.6.x, for the commonly used
> cases - such as the one you posted - it never breaks. Can you provide a
> sample script that _doesnt_ work in 2.6.x? 

I am still composing a reply to your earlier email.  That
is going to take a little while as you have asked me to
patch and unpatch things.

However, assuming you are referring to the hashing function
here - as it happens the 2.4 and 2.6 functions always
hash to the same thing when you are hashing one byte.
They differ when you hash two or more non-zero bytes.

Just for reference, the 2.4 hashing function is an XOR or
all the bytes in the value.  Although the 2.6 hashing
function is very simple, I can't think of a short but
precise way to describe it in English.  The best I can 
do is to say it uses least significant byte of the value
after masking.  But perhaps you wrote it, and so are
familiar with it (?)

Anyway, to give you a feel how familiar I am (or am not,
as the case may be) with the the U32 filter, here is a 
URL to some doco I wrote.  I did it for my own use as
there wasn't (and still isn't, as far as I know) - any
decent U32 doco.  I did pass it onto Bert Hubert, but
nothing came of that as far as I know.

http://www.stuart.id.au/russell/files/tc/cls_u32.txt

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to