Re: Endianness problem with u32 classifier hash masks

[jamal <hadi@cyberus.ca>]

On Mon, 2007-05-11 at 22:06 +0100, Jarek Poplawski wrote:
> Radu Rendec wrote, On 11/05/2007 06:31 PM:

> > But still, Jamal, I need more explanations on what you meant by "cutdown
> > on the conversion in u32_change()". 

I meant that it didnt seem necessary to me you have to do the conversion
back and forth of the hmask as you do in the u32_change(). The basis of
the patch i posted - which is based on yours - is to remove that change.
If that doesnt work, please just send your patch as is and we can think
of optimization later.

> > And, before proceeding, I'd like to
> > see your reply to Jarek's last email (at 15:49 +0100) about not getting
> > 0xff in the end.

On paper i get the same result with the new or old scheme for the bucket selection.
As i stated on the patch - i never did test the theory.

> Radu, as far as I know Jamal (from reading) he most probably is busy with
> some conference! 

I actually have a day job and have to show up and meet TheMan, Jarek;->
Most of the days at work, i dont have time to look at external email
account - but you can bet all horses you own i will get back to you
within a few hours if you CC me on email.

> Since these patches aren't so big I think you could
> try Jamal's at first, and if it doesn't work, and nothing new from Jamal
> in the meantime, resend your version. Cutdown in u32_change() seems to
> add more to the fastpath, but maybe Jamal thinks about something else.

I mean do most work on slow/config path.

> > Jarek, because I have to test anyway, I'll include ffs(mask) in my patch
> > and have it tested too.

Lets have two patches - one for the le/be bucket selection and another
for ffs.

cheers,
jamal