:12 -0800
Subject: [PATCH] [PKT_SCHED] CLS_U32: Fix endianness problem with u32
classifier hash masks.
From: Radu Rendec [EMAIL PROTECTED]
While trying to implement u32 hashes in my shaping machine I ran into
a possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c
] CLS_U32: Fix endianness problem with u32
classifier hash masks.
From: Radu Rendec [EMAIL PROTECTED]
While trying to implement u32 hashes in my shaping machine I ran into
a possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks
On Wed, 2007-11-07 at 01:22 -0800, David Miller wrote:
I've grown impatient and done the work for you :-) I've applied
the patch below to my tree, thank you!
If someone wants to send me the ffs() thing relative to this,
I'd appreciate it. Thanks again!
Thanks again for making the patch
On Wed, 2007-11-07 at 08:42 -0500, jamal wrote:
On Wed, 2007-07-11 at 01:22 -0800, David Miller wrote:
@@ -615,7 +615,7 @@ static int u32_change(struct tcf_proto *tp, unsigned
long base, u32 handle,
n-handle = handle;
{
u8 i = 0;
- u32 mask = s-hmask;
+ u32 mask =
On Wed, 2007-07-11 at 01:22 -0800, David Miller wrote:
@@ -615,7 +615,7 @@ static int u32_change(struct tcf_proto *tp, unsigned long
base, u32 handle,
n-handle = handle;
{
u8 i = 0;
- u32 mask = s-hmask;
+ u32 mask = ntohl(s-hmask);
Is this line needed? Radu?
On Tue, 2007-11-06 at 01:02 +0100, Jarek Poplawski wrote:
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
On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
Yup, you're right. Bitwise anding is the same regardless of the byte
ordering of the operands. As long as you don't have one operand in host
order and the other in net order, it's ok.
Ok
However, Jarek's computations with his mask and
On Tue, Nov 06, 2007 at 08:34:31AM -0500, jamal wrote:
On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
Yup, you're right. Bitwise anding is the same regardless of the byte
ordering of the operands. As long as you don't have one operand in host
order and the other in net order, it's
On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
Yes, it saves one htonl() on the slow path!
Would it feel better to say grew down exponentially from version 1 to
3? ;-
Please give yourself a little pat on the back for me.
Wait a minute! Don't forget to take a picture or
On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
Yes, it saves one htonl() on the slow path!
Would it feel better to say grew down exponentially from version 1 to
3? ;-
Not only it saves one htonl(), but also keeps the code
Radu Rendec wrote, On 11/06/2007 06:00 PM:
On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
Yes, it saves one htonl() on the slow path!
Would it feel better to say grew down exponentially from version 1 to
3? ;-
Sure, but I felt
On Sun, Nov 04, 2007 at 06:58:13PM -0500, jamal wrote:
On Sun, 2007-04-11 at 02:17 +0100, Jarek Poplawski wrote:
So, even if not full ntohl(), some byte moving seems to be
necessary here.
I thinking you were close. I am afraid my brain is congested, even the
esspresso didnt help my
Jarek, thanks for replying my message on the list and pointing it to the
right direction.
Your example with 1 bits laying on exact nibble boundary is much
easier to analyze than my original example. And your computation seems
to be right: u32_hash_fold() would return 00.f0.00.0f (and would be cut
On Mon, 2007-05-11 at 14:59 +0200, Radu Rendec wrote:
Jarek, thanks for replying my message on the list and pointing it to the
right direction.
Your example with 1 bits laying on exact nibble boundary is much
easier to analyze than my original example. And your computation seems
to be
On Mon, Nov 05, 2007 at 02:59:21PM +0200, Radu Rendec wrote:
...
Jamal, I am aware that any computation on the fast path involves some
performance loss. However, I don't see any speed gain with your patch,
because you just moved the ntohl() call inside u32_hash_fold(). Since
u32_hash_fold() is
On Mon, 2007-05-11 at 10:12 +0100, Jarek Poplawski wrote:
BTW: when looking around this I think, maybe, in u32_change():
1) if (--divisor 0x100) should be probably =,
Does it really matter? Divisor can be max of 0xff.
but is it really needed to check this 2 times (including tc)?
I dont
On Mon, 2007-05-11 at 14:52 +0100, Jarek Poplawski wrote:
It seems this performance loss shouldn't be so big because ntohl()
is probably quite well optimized in assembler. But, as I've written,
since there is max. 1 byte meaningful to us there is some additional
possibility to get it other
On Mon, Nov 05, 2007 at 08:47:06AM -0500, jamal wrote:
On Mon, 2007-05-11 at 10:12 +0100, Jarek Poplawski wrote:
BTW: when looking around this I think, maybe, in u32_change():
1) if (--divisor 0x100) should be probably =,
Does it really matter? Divisor can be max of 0xff.
But,
On Mon, Nov 05, 2007 at 08:43:32AM -0500, jamal wrote:
On Mon, 2007-05-11 at 14:59 +0200, Radu Rendec wrote:
Jarek, thanks for replying my message on the list and pointing it to the
right direction.
Your example with 1 bits laying on exact nibble boundary is much
easier to analyze than
On Mon, 2007-11-05 at 15:49 +0100, Jarek Poplawski wrote:
Yes, that example i believe would work just fine today as is with no
changes.
...
Please try the patch i sent since it is simpler. It is your work more or
less - so you should get the credit as author.
Jamal + Houston, we have
On Mon, 2007-11-05 at 09:06 -0500, jamal wrote:
On Mon, 2007-05-11 at 14:52 +0100, Jarek Poplawski wrote:
...
If we manage to convince Jamal, IMHO a patch to something current like
2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some
options to diff to get function names etc.
Radu Rendec wrote, On 11/05/2007 06:31 PM:
On Mon, 2007-11-05 at 09:06 -0500, jamal wrote:
On Mon, 2007-05-11 at 14:52 +0100, Jarek Poplawski wrote:
...
If we manage to convince Jamal, IMHO a patch to something current like
2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some
Jarek Poplawski wrote, On 11/05/2007 10:06 PM:
Radu Rendec wrote, On 11/05/2007 06:31 PM:
...
Jarek, because I have to test anyway, I'll include ffs(mask) in my patch
and have it tested too.
Thanks! But, I did it wrong: + 1 is unnecessary. And since, ffs() checks
for 0 anyway, this
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
jamal wrote, On 11/05/2007 11:27 PM:
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
Jarek Poplawski wrote, On 11/06/2007 01:02 AM:
...
on little endian (net order):
f0.0f.00.00 4 gives: 0f.00.0f.00 then ntohl: 00.0f.00.0f with lsb: 0f
should be:
f0.0f.00.00 4 gives: 0f.00.f0.00 then ntohl: 00.f0.00.0f with lsb: 0f
Jarek Sleeping P.
-
To unsubscribe from this list: send
On Sun, 2007-04-11 at 02:17 +0100, Jarek Poplawski wrote:
So, even if not full ntohl(), some byte moving seems to be
necessary here.
I thinking you were close. I am afraid my brain is congested, even the
esspresso didnt help my thinking.
It could be done with just fshift on the slow path
jamal wrote, On 11/03/2007 12:23 AM:
On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
Radu Rendec wrote:
Hi,
While trying to implement u32 hashes in my shaping machine I ran into a
possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs
Jarek Poplawski wrote, On 11/04/2007 12:39 AM:
...
OOPS!!! Went too early! I've tried to save not send. Probably my
bad pronunciation...
But, it seems this could be something like this (instead of Radu's
change in u32_classify()). The change of hmask is needed.
But it needs more checking...
Jarek Poplawski wrote, On 11/04/2007 12:58 AM:
Jarek Poplawski wrote, On 11/04/2007 12:39 AM:
...
OOPS!!! Went too early! I've tried to save not send. Probably my
bad pronunciation...
But, it seems this could be something like this (instead of Radu's
change in u32_classify()). The
Jarek Poplawski wrote, On 11/04/2007 01:30 AM:
Jarek Poplawski wrote, On 11/04/2007 12:58 AM:
...
Other changes seem to be not needed.
But it needs more checking...
But not much more: it's a piece of fshit!
So, even if not full ntohl(), some byte moving seems to be
necessary here.
Sorry
Radu Rendec wrote:
Hi,
While trying to implement u32 hashes in my shaping machine I ran into a
possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks that extend over the octet
boundary, on little endian machines (where
On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
Radu Rendec wrote:
Hi,
While trying to implement u32 hashes in my shaping machine I ran into a
possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks that
Hi,
While trying to implement u32 hashes in my shaping machine I ran into a
possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks that extend over the octet
boundary, on little endian machines (where htonl() actually does
34 matches
Mail list logo
