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 patc
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;
> >
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? Rad
will be enough to check
on some bush at least!
>
> From 8e36263f10a054479636b57943cdeaf37470acc5 Mon Sep 17 00:00:00 2001
> From: Radu Rendec <[EMAIL PROTECTED]>
> Date: Wed, 7 Nov 2007 01:20:12 -0800
> Subject: [PATCH] [PKT_SCHED] CLS_U32: Fix endianness problem with u32
&g
om 8e36263f10a054479636b57943cdeaf37470acc5 Mon Sep 17 00:00:00 2001
From: Radu Rendec <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 01:20:12 -0800
Subject: [PATCH] [PKT_SCHED] CLS_U32: Fix endianness problem with u32
classifier hash masks.
From: Radu Rendec <[EMAIL PROTECTED]>
While tryin
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, bu
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
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 som
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
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, 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
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:
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 ne
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
bac
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,
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 (p
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 name
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
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
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 0xf
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, 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)?
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 b
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()
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 cu
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
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 (co
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.
S
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()). Th
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...
Ja
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).
>
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 ha
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 (wh
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
something)
34 matches
Mail list logo
