* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-05 16:14 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, netdev
In-Reply-To: <20050704.160034.55511095.davem@davemloft.net>
David S. Miller a écrit :
> SMP system? What platform and 570x chip revision?
>
dual opterons 248,
Ethernet controller: Broadcom Corporation NetXtreme BCM5702 Gigabit Ethernet (rev 02)
> Does the stock driver in 2.6.12 hang as well?
Stock driver in 2.6.11 or 2.6.12 cause hangs (crashes ?) too, but no kernel mesages are logged on disk.
I think this is crashing in cache_grow() (slab code), not sure because I dont have access to the console.
The 2.6.13-rc1 tg3 driver seems to survive (running for 18 hours now), and the cpu used by network activity
was cut down :)
rx-usecs: 500
rx-frames: 30
rx-usecs-irq: 500
rx-frames-irq: 20
tx-usecs: 490
tx-frames: 53
tx-usecs-irq: 490
tx-frames-irq: 5
About 1200 IRQ/second now, with 30000 recv packs/s and 25000 xmit pack/s
Thank you
Eric
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-05 15:58 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050705134805.GH16076@postel.suug.ch>
Thomas Graf a écrit :
>>OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop :
>
>
> Because you don't specify -funroll-loop
I'm using vanilla 2.6.12 : no -funroll-loop in it. Maybe in your tree, not on 99.9% of 2.6.12 trees.
Are you suggesting everybody should use this compiler flag ?
Something like :
net/sched/Makefile:
CFLAGS_sch_generic.o := -funroll-loops
?
>
> [...]
>
>
>>Please give us the code your compiler produces,
>
>
> Unrolled version:
>
> pfifo_fast_dequeue:
> pushl %esi
> xorl %edx, %edx
> pushl %ebx
> movl 12(%esp), %esi
> movl 128(%esi), %eax
> leal 128(%esi), %ecx
> cmpl %ecx, %eax
> je .L132
> movl %eax, %edx
> movl (%eax), %eax
> decl 8(%ecx)
> movl $0, 8(%edx)
> movl %ecx, 4(%eax)
> movl %eax, 128(%esi)
> movl $0, 4(%edx)
> movl $0, (%edx)
> .L132:
> testl %edx, %edx
> je .L131
> movl 96(%edx), %ebx
> movl 80(%esi), %eax
> decl 40(%esi)
> subl %ebx, %eax
> movl %eax, 80(%esi)
> movl %edx, %eax
> .L117:
> popl %ebx
> popl %esi
> ret
> .L131:
> movl 20(%ecx), %eax
> leal 20(%ecx), %edx
> xorl %ebx, %ebx
> cmpl %edx, %eax
> je .L137
> movl %eax, %ebx
> movl (%eax), %eax
> decl 8(%edx)
> movl $0, 8(%ebx)
> movl %edx, 4(%eax)
> movl %eax, 20(%ecx)
> movl $0, 4(%ebx)
> movl $0, (%ebx)
> .L137:
> testl %ebx, %ebx
> je .L147
> .L146:
> movl 96(%ebx), %ecx
> movl 80(%esi), %eax
> decl 40(%esi)
> subl %ecx, %eax
> movl %eax, 80(%esi)
> movl %ebx, %eax
> jmp .L117
> .L147:
> movl 40(%ecx), %eax
> leal 40(%ecx), %edx
> xorl %ebx, %ebx
> cmpl %edx, %eax
> je .L142
> movl %eax, %ebx
> movl (%eax), %eax
> decl 8(%edx)
> movl $0, 8(%ebx)
> movl %edx, 4(%eax)
> movl %eax, 40(%ecx)
> movl $0, 4(%ebx)
> movl $0, (%ebx)
> .L142:
> xorl %eax, %eax
> testl %ebx, %ebx
> jne .L146
> jmp .L117
>
OK thanks, but you dont give the code for my version :) shorter and unrolled as you can see, and with nice predicted branches.
00000fc0 <pfifo_fast_dequeue>:
fc0: 56 push %esi
fc1: 89 c1 mov %eax,%ecx
fc3: 53 push %ebx
fc4: 8d 98 a0 00 00 00 lea 0xa0(%eax),%ebx
fca: 39 98 a0 00 00 00 cmp %ebx,0xa0(%eax)
fd0: 89 da mov %ebx,%edx
fd2: 75 22 jne ff6 <pfifo_fast_dequeue+0x36>
fd4: 8d 90 c4 00 00 00 lea 0xc4(%eax),%edx
fda: 39 90 c4 00 00 00 cmp %edx,0xc4(%eax)
fe0: 89 d3 mov %edx,%ebx
fe2: 75 12 jne ff6 <pfifo_fast_dequeue+0x36>
fe4: 8d 98 e8 00 00 00 lea 0xe8(%eax),%ebx
fea: 31 f6 xor %esi,%esi
fec: 39 98 e8 00 00 00 cmp %ebx,0xe8(%eax)
ff2: 89 da mov %ebx,%edx
ff4: 74 27 je 101d <pfifo_fast_dequeue+0x5d>
ff6: 8b 32 mov (%edx),%esi
ff8: 39 d6 cmp %edx,%esi
ffa: 74 26 je 1022 <pfifo_fast_dequeue+0x62>
ffc: 8b 06 mov (%esi),%eax
ffe: ff 4b 08 decl 0x8(%ebx)
1001: c7 46 08 00 00 00 00 movl $0x0,0x8(%esi)
1008: 89 50 04 mov %edx,0x4(%eax)
100b: 89 02 mov %eax,(%edx)
100d: c7 46 04 00 00 00 00 movl $0x0,0x4(%esi)
1014: c7 06 00 00 00 00 movl $0x0,(%esi)
101a: ff 49 28 decl 0x28(%ecx)
101d: 5b pop %ebx
101e: 89 f0 mov %esi,%eax
1020: 5e pop %esi
1021: c3 ret
1022: ff 49 28 decl 0x28(%ecx)
1025: 31 f6 xor %esi,%esi
1027: eb f4 jmp 101d <pfifo_fast_dequeue+0x5d>
>
> I just noticed that this is a local modification of my own, so in
> the vanilla tree it indeed doesn't have any impact on the code
> generated.
>
> Still, your patch does not make sense to me. The latest tree
> also includes my pfifo_fast changes wich modified the code to
> maintain a backlog and made it easy to add more fifos at compile
> time. If you want the loop unrolled then let the compiler do it
> via -funroll-loop. These kind of optimization seem as uncessary
> to me as all the loopback optimizations.
>
I dont want change compiler flags in my tree and loose this optim when 2.6.13 is released.
I dont know about loopback optimization, I am not involved with this stuff, maybe you think I'm another guy ?
It seems to me you give unrelated arguments.
I dont know what are your plans, but mine were not to say you are writing bad code.
Just to give my performance analysis and feedback, I'm sorry if it hurts you.
Eric Dumazet
^ permalink raw reply
* Re: [PATCH] multipath routing algorithm, better patch
From: Patrick Jenkins @ 2005-07-05 15:17 UTC (permalink / raw)
To: linux-kernel, netdev
>Thomas Graf wrote:
>> * Patrick McHardy <42C4919A.5000009@trash.net> 2005-07-01 02:43
>>
>>>If it isn't set correctly its an iproute problem. Did you actually
>>>experience any problems?
>>
>> Well, my patch for iproute2 to enable multipath algorithm selection
>> is currently being merged to Stephen together with the ematch bits.
>> We had to work out a dependency on GNU flex first (the berkley
>> version uses the same executable names) so the inclusion was
>> delayed a bit.
>
>So its no problem but simply missing support. BTW, do you know if
>Stephen's new CVS repository is exported somewhere?
Yes, we did experience a problem. The routing doesnt work as advertised
(i.e. it wont utilize the multiple routes). Patrick is correct in saying
its missing support.
>From what you are saying it seems the problem will be corrected by a new
feature in iproute2 that allows the user to select this ability. Is this
correct? Also, does this mean my patch is not needed? It seems to me that
it should be supported somehow in the kernel seeing as how everyone might
not utilize iproute2.
Once again, please cc me in the reply because I am not a member of the
list.
Thanks,
Patrick Jenkins
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 13:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <42CA8555.9050607@cosmosbay.com>
* Eric Dumazet <42CA8555.9050607@cosmosbay.com> 2005-07-05 15:04
> Thomas Graf a écrit :
> >* Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> >
> >>[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> >>better code.
> >> (Using skb_queue_empty() to test the queue is faster than trying to
> >> __skb_dequeue())
> >> oprofile says this function uses now 0.29% instead of 1.22 %, on a
> >> x86_64 target.
> >
> >
> >I think this patch is pretty much pointless. __skb_dequeue() and
> >!skb_queue_empty() should produce almost the same code and as soon
> >as you disable profiling and debugging you'll see that the compiler
> >unrolls the loop itself if possible.
> >
> >
>
> OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop :
Because you don't specify -funroll-loop
[...]
> Please give us the code your compiler produces,
Unrolled version:
pfifo_fast_dequeue:
pushl %esi
xorl %edx, %edx
pushl %ebx
movl 12(%esp), %esi
movl 128(%esi), %eax
leal 128(%esi), %ecx
cmpl %ecx, %eax
je .L132
movl %eax, %edx
movl (%eax), %eax
decl 8(%ecx)
movl $0, 8(%edx)
movl %ecx, 4(%eax)
movl %eax, 128(%esi)
movl $0, 4(%edx)
movl $0, (%edx)
.L132:
testl %edx, %edx
je .L131
movl 96(%edx), %ebx
movl 80(%esi), %eax
decl 40(%esi)
subl %ebx, %eax
movl %eax, 80(%esi)
movl %edx, %eax
.L117:
popl %ebx
popl %esi
ret
.L131:
movl 20(%ecx), %eax
leal 20(%ecx), %edx
xorl %ebx, %ebx
cmpl %edx, %eax
je .L137
movl %eax, %ebx
movl (%eax), %eax
decl 8(%edx)
movl $0, 8(%ebx)
movl %edx, 4(%eax)
movl %eax, 20(%ecx)
movl $0, 4(%ebx)
movl $0, (%ebx)
.L137:
testl %ebx, %ebx
je .L147
.L146:
movl 96(%ebx), %ecx
movl 80(%esi), %eax
decl 40(%esi)
subl %ecx, %eax
movl %eax, 80(%esi)
movl %ebx, %eax
jmp .L117
.L147:
movl 40(%ecx), %eax
leal 40(%ecx), %edx
xorl %ebx, %ebx
cmpl %edx, %eax
je .L142
movl %eax, %ebx
movl (%eax), %eax
decl 8(%edx)
movl $0, 8(%ebx)
movl %edx, 4(%eax)
movl %eax, 40(%ecx)
movl $0, 4(%ebx)
movl $0, (%ebx)
.L142:
xorl %eax, %eax
testl %ebx, %ebx
jne .L146
jmp .L117
> and explain me how
> disabling oprofile can change the generated assembly. :)
> Debugging has no impact on this code either.
I just noticed that this is a local modification of my own, so in
the vanilla tree it indeed doesn't have any impact on the code
generated.
Still, your patch does not make sense to me. The latest tree
also includes my pfifo_fast changes wich modified the code to
maintain a backlog and made it easy to add more fifos at compile
time. If you want the loop unrolled then let the compiler do it
via -funroll-loop. These kind of optimization seem as uncessary
to me as all the loopback optimizations.
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-05 13:04 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050705115108.GE16076@postel.suug.ch>
Thomas Graf a écrit :
> * Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
>
>>[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
>>better code.
>> (Using skb_queue_empty() to test the queue is faster than trying to
>> __skb_dequeue())
>> oprofile says this function uses now 0.29% instead of 1.22 %, on a
>> x86_64 target.
>
>
> I think this patch is pretty much pointless. __skb_dequeue() and
> !skb_queue_empty() should produce almost the same code and as soon
> as you disable profiling and debugging you'll see that the compiler
> unrolls the loop itself if possible.
>
>
OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop :
Original 2.6.12 gives :
ffffffff802a9790 <pfifo_fast_dequeue>: /* pfifo_fast_dequeue total: 2904054 1.9531 */
258371 0.1738 :ffffffff802a9790: lea 0xc0(%rdi),%rcx
273669 0.1841 :ffffffff802a9797: xor %esi,%esi
12533 0.0084 :ffffffff802a9799: mov (%rcx),%rdx
292315 0.1966 :ffffffff802a979c: cmp %rcx,%rdx
11717 0.0079 :ffffffff802a979f: je ffffffff802a97d1 <pfifo_fast_dequeue+0x41>
4474 0.0030 :ffffffff802a97a1: mov %rdx,%rax
6238 0.0042 :ffffffff802a97a4: mov (%rdx),%rdx
41 2.8e-05 :ffffffff802a97a7: decl 0x10(%rcx)
6089 0.0041 :ffffffff802a97aa: test %rax,%rax
126 8.5e-05 :ffffffff802a97ad: movq $0x0,0x10(%rax)
39 2.6e-05 :ffffffff802a97b5: mov %rcx,0x8(%rdx)
6974 0.0047 :ffffffff802a97b9: mov %rdx,(%rcx)
2841 0.0019 :ffffffff802a97bc: movq $0x0,0x8(%rax)
366 2.5e-04 :ffffffff802a97c4: movq $0x0,(%rax)
14757 0.0099 :ffffffff802a97cb: je ffffffff802a97d1 <pfifo_fast_dequeue+0x41>
288 1.9e-04 :ffffffff802a97cd: decl 0x40(%rdi)
94 6.3e-05 :ffffffff802a97d0: retq
970400 0.6526 :ffffffff802a97d1: inc %esi
982402 0.6607 :ffffffff802a97d3: add $0x18,%rcx
4 2.7e-06 :ffffffff802a97d7: cmp $0x2,%esi
1 6.7e-07 :ffffffff802a97da: jle ffffffff802a9799 <pfifo_fast_dequeue+0x9>
59754 0.0402 :ffffffff802a97dc: xor %eax,%eax
561 3.8e-04 :ffffffff802a97de: data16
:ffffffff802a97df: nop
:ffffffff802a97e0: retq
And new code (2.6.12-ed):
ffffffff802b1020 <pfifo_fast_dequeue>: /* pfifo_fast_dequeue total: 153139 0.2934 */
27388 0.0525 :ffffffff802b1020: lea 0xc0(%rdi),%rdx
42091 0.0806 :ffffffff802b1027: cmp %rdx,0xc0(%rdi)
:ffffffff802b102e: jne ffffffff802b1052 <pfifo_fast_dequeue+0x32>
474 9.1e-04 :ffffffff802b1030: lea 0xd8(%rdi),%rdx
5571 0.0107 :ffffffff802b1037: cmp %rdx,0xd8(%rdi)
2 3.8e-06 :ffffffff802b103e: jne ffffffff802b1052 <pfifo_fast_dequeue+0x32>
1 1.9e-06 :ffffffff802b1040: lea 0xf0(%rdi),%rdx
20030 0.0384 :ffffffff802b1047: xor %eax,%eax
6 1.1e-05 :ffffffff802b1049: cmp %rdx,0xf0(%rdi)
6 1.1e-05 :ffffffff802b1050: je ffffffff802b1086 <pfifo_fast_dequeue+0x66>
:ffffffff802b1052: mov (%rdx),%rcx
11796 0.0226 :ffffffff802b1055: xor %eax,%eax
:ffffffff802b1057: cmp %rdx,%rcx
8 1.5e-05 :ffffffff802b105a: je ffffffff802b1083 <pfifo_fast_dequeue+0x63>
3146 0.0060 :ffffffff802b105c: mov %rcx,%rax
12 2.3e-05 :ffffffff802b105f: mov (%rcx),%rcx
118 2.3e-04 :ffffffff802b1062: decl 0x10(%rdx)
4924 0.0094 :ffffffff802b1065: movq $0x0,0x10(%rax)
65 1.2e-04 :ffffffff802b106d: mov %rdx,0x8(%rcx)
725 0.0014 :ffffffff802b1071: mov %rcx,(%rdx)
11493 0.0220 :ffffffff802b1074: movq $0x0,0x8(%rax)
194 3.7e-04 :ffffffff802b107c: movq $0x0,(%rax)
2995 0.0057 :ffffffff802b1083: decl 0x40(%rdi)
19607 0.0376 :ffffffff802b1086: nop
2487 0.0048 :ffffffff802b1087: retq
Please give us the code your compiler produces, and explain me how disabling oprofile can change the generated assembly. :)
Debugging has no impact on this code either.
Thank you
Eric
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 12:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <20050705115108.GE16076@postel.suug.ch>
* Thomas Graf <20050705115108.GE16076@postel.suug.ch> 2005-07-05 13:51
> * Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> > [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> > better code.
> > (Using skb_queue_empty() to test the queue is faster than trying to
> > __skb_dequeue())
> > oprofile says this function uses now 0.29% instead of 1.22 %, on a
> > x86_64 target.
>
> I think this patch is pretty much pointless. __skb_dequeue() and
> !skb_queue_empty() should produce almost the same code and as soon
> as you disable profiling and debugging you'll see that the compiler
> unrolls the loop itself if possible.
... given one enables it of course.
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 11:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <42CA390C.9000801@cosmosbay.com>
* Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> better code.
> (Using skb_queue_empty() to test the queue is faster than trying to
> __skb_dequeue())
> oprofile says this function uses now 0.29% instead of 1.22 %, on a
> x86_64 target.
I think this patch is pretty much pointless. __skb_dequeue() and
!skb_queue_empty() should produce almost the same code and as soon
as you disable profiling and debugging you'll see that the compiler
unrolls the loop itself if possible.
^ permalink raw reply
* [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-05 7:38 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050704.160140.21591849.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates better code.
(Using skb_queue_empty() to test the queue is faster than trying to __skb_dequeue())
oprofile says this function uses now 0.29% instead of 1.22 %, on a x86_64 target.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: patch.sch_generic --]
[-- Type: text/plain, Size: 1022 bytes --]
--- linux-2.6.12/net/sched/sch_generic.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12-ed/net/sched/sch_generic.c 2005-07-05 09:11:30.000000000 +0200
@@ -333,18 +333,23 @@
static struct sk_buff *
pfifo_fast_dequeue(struct Qdisc* qdisc)
{
- int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
struct sk_buff *skb;
- for (prio = 0; prio < 3; prio++, list++) {
- skb = __skb_dequeue(list);
- if (skb) {
- qdisc->q.qlen--;
- return skb;
- }
+ for (;;) {
+ if (!skb_queue_empty(list))
+ break;
+ list++;
+ if (!skb_queue_empty(list))
+ break;
+ list++;
+ if (!skb_queue_empty(list))
+ break;
+ return NULL;
}
- return NULL;
+ skb = __skb_dequeue(list);
+ qdisc->q.qlen--;
+ return skb;
}
static int
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 23:01 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9BEF6.4080402@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:57:58 +0200
> Eric Dumazet a écrit :
>
> > Very easy way to lock it :
> >
> > ping -f some_destination.
>
>
> Arg. False alarm. Sorry.
>
> Time for me to sleep.
Oh well...
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 23:00 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9BE69.2070008@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:55:37 +0200
> David S. Miller a écrit :
>
> > Please don't ever do stuff like that :-( That makes the driver
> > version, and any other information you report completely meaningless
> > and useless. You've just wasted a lot of our time.
> >
>
> Yes. But if you dont want us to test your patches, dont send them to
> the list.
The case here is that you didn't even mention that you had
the patch applied. If you don't say what changes you've applied
to the stock driver we can't properly debug anything.
> For your information, 2.6.13-rc1 locks too.
>
> Very easy way to lock it :
>
> ping -f some_destination.
SMP system? What platform and 570x chip revision?
Does the stock driver in 2.6.12 hang as well?
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9BE69.2070008@cosmosbay.com>
Eric Dumazet a écrit :
>
> For your information, 2.6.13-rc1 locks too.
>
> Very easy way to lock it :
>
> ping -f some_destination.
Arg. False alarm. Sorry.
Time for me to sleep.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:55 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, netdev
In-Reply-To: <20050704.154712.63128211.davem@davemloft.net>
David S. Miller a écrit :
> Please don't ever do stuff like that :-( That makes the driver
> version, and any other information you report completely meaningless
> and useless. You've just wasted a lot of our time.
>
Yes. But if you dont want us to test your patches, dont send them to the list.
For your information, 2.6.13-rc1 locks too.
Very easy way to lock it :
ping -f some_destination.
> I have no idea to even know _WHICH_ IRQ spinlock patch you applied.
>
> The one that ended up in Linus's tree has many bug fixes and
> refinements. The ones which were posted on netdev had many bugs and
> deadlocks which needed to be cured before pushing the change upstream.
>
>
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9B8DB.7020403@cosmosbay.com>
Eric Dumazet a écrit :
>
>
> Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all
> hw IRQ handler spinlocks.
> (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
>
> Maybe I should revert to stock 2.6.12 tg3 driver ?
>
> Eric
>
>
Oh well, I checked 2.6.13-rc1 and it contains this line in tg3_netif_stop() :
+ tp->dev->trans_start = jiffies; /* prevent tx timeout */
So I am trying driver 3.32 June 24, 2005, included in 2.6.13-rc1
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 22:47 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9B8DB.7020403@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:31:55 +0200
> Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks.
> (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
>
> Maybe I should revert to stock 2.6.12 tg3 driver ?
Please don't ever do stuff like that :-( That makes the driver
version, and any other information you report completely meaningless
and useless. You've just wasted a lot of our time.
I have no idea to even know _WHICH_ IRQ spinlock patch you applied.
The one that ended up in Linus's tree has many bug fixes and
refinements. The ones which were posted on netdev had many bugs and
deadlocks which needed to be cured before pushing the change upstream.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9AC97.1020902@cosmosbay.com>
Eric Dumazet a écrit :
> David S. Miller a écrit :
>
>> From: Eric Dumazet <dada1@cosmosbay.com>
>> Date: Mon, 04 Jul 2005 23:22:12 +0200
>>
>>
>>> But it seems something is wrong because when network load becomes
>>> high I get :
>>>
>>> Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>> Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>> Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>> Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>> Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>
>>
>>
>> Does this happen without changing the coalescing settings
>> at all?
>>
>>
> Not easy to answer because I have to rebuild a kernel and reboot. Will
> do that shortly.
>
>
>
Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks.
(Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
Maybe I should revert to stock 2.6.12 tg3 driver ?
Eric
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 21:49 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9AC97.1020902@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 04 Jul 2005 23:39:35 +0200
> Not easy to answer because I have to rebuild a kernel and
> reboot. Will do that shortly.
Thanks.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 21:39 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, netdev
In-Reply-To: <20050704.142604.18592223.davem@davemloft.net>
David S. Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Mon, 04 Jul 2005 23:22:12 +0200
>
>
>>But it seems something is wrong because when network load becomes high I get :
>>
>>Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>
>
> Does this happen without changing the coalescing settings
> at all?
>
>
Not easy to answer because I have to rebuild a kernel and reboot. Will do that shortly.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 21:26 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9A884.1030906@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 04 Jul 2005 23:22:12 +0200
> But it seems something is wrong because when network load becomes high I get :
>
> Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
> Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
> Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Does this happen without changing the coalescing settings
at all?
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 21:22 UTC (permalink / raw)
To: Michael Chan; +Cc: David S. Miller, netdev
In-Reply-To: <1119467012.5325.15.camel@rh4>
Michael Chan a écrit :
> On Wed, 2005-06-22 at 17:25 +0200, Eric Dumazet wrote:
>
>
>>Is there anything I can try to tune the coalescing ?
>>Being able to handle 100 packets each interrupt instead of one or two would certainly help.
>>I dont mind about latency. But of course I would like not to drop packets :)
>>But maybe the BCM5702 is not able to delay an interrupt ?
>>
>
>
> On the 5702 that supports CLRTCKS mode, you need to play around with the
> following parameters in tg3.h. To reduce interrupts, you generally have
> to increase the values.
>
> #define LOW_RXCOL_TICKS_CLRTCKS 0x00000014
> #define LOW_TXCOL_TICKS_CLRTCKS 0x00000048
> #define LOW_RXMAX_FRAMES 0x00000005
> #define LOW_TXMAX_FRAMES 0x00000035
> #define DEFAULT_RXCOAL_TICK_INT_CLRTCKS 0x00000014
> #define DEFAULT_TXCOAL_TICK_INT_CLRTCKS 0x00000014
> #define DEFAULT_RXCOAL_MAXF_INT 0x00000005
> #define DEFAULT_TXCOAL_MAXF_INT 0x00000005
>
>
>
Thanks Michael
I tried various settings.
# ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off TX: off
stats-block-usecs: 1000000
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 500
rx-frames: 20
rx-usecs-irq: 500
rx-frames-irq: 20
tx-usecs: 600
tx-frames: 53
tx-usecs-irq: 600
tx-frames-irq: 20
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
But it seems something is wrong because when network load becomes high I get :
Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:29 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:34 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:34 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:39 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:39 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:44 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:44 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:49 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:49 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:54 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:54 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:59 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:59 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:04 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:04 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:09 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:09 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:14 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:14 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:29 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:34 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:34 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:39 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:39 dada1 kernel: tg3: eth0: transmit timed out, resetting
Then the machine crashes at this point.
tg3.c :
#define DRV_MODULE_VERSION "3.31"
#define DRV_MODULE_RELDATE "June 8, 2005"
# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 511
RX Mini: 0
RX Jumbo: 255
TX: 0
Current hardware settings:
RX: 400
RX Mini: 0
RX Jumbo: 40
TX: 511
Thank you
Eric Dumazet
^ permalink raw reply
* Re: [2.6 patch] fix IP_FIB_HASH kconfig warning
From: Roman Zippel @ 2005-07-04 18:27 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20050703222002.GQ5346@stusta.de>
Hi,
On Mon, 4 Jul 2005, Adrian Bunk wrote:
> --- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old 2005-07-02 20:07:25.000000000 +0200
> +++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig 2005-07-02 20:13:05.000000000 +0200
> @@ -58,8 +58,9 @@
> depends on IP_ADVANCED_ROUTER
> default IP_FIB_HASH
>
> -config IP_FIB_HASH
> +config ASK_IP_FIB_HASH
> bool "FIB_HASH"
> + select IP_FIB_HASH
> ---help---
> Current FIB is very proven and good enough for most users.
>
> @@ -84,12 +85,9 @@
>
> endchoice
>
> -# If the user does not enable advanced routing, he gets the safe
> -# default of the fib-hash algorithm.
> config IP_FIB_HASH
> bool
> - depends on !IP_ADVANCED_ROUTER
> - default y
> + default y if !IP_ADVANCED_ROUTER
>
> config IP_MULTIPLE_TABLES
> bool "IP: policy routing"
I'd prefer to do it without select.
config IP_FIB_HASH
def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
bye, Roman
^ permalink raw reply
* Re: ipw2100: more cleanups
From: Pavel Machek @ 2005-07-04 7:05 UTC (permalink / raw)
To: Zhu Yi; +Cc: jketreno, netdev, jbohac, jbenc
In-Reply-To: <1120456146.27821.85.camel@debian.sh.intel.com>
Hi!
> > More cleanups (relative to ipw2100-1.1.0 version). Highlights include
> > removing of two printk wrappers.
>
> [snip]
>
> > -static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL);
>
> Any special reason to remove these driver sysfs entries?
Umm, yes, they should not be needed and we do not want to maintain
them in /sys forever. /sys should be "one value per file", and
definitely not for debugging stuff like this. (See debugfs)
Anyway I think I did drop that patch from newer cleanup attempts.
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
^ permalink raw reply
* Re: ipw2100: more cleanups
From: Zhu Yi @ 2005-07-04 5:49 UTC (permalink / raw)
To: Pavel Machek; +Cc: jketreno, netdev, jbohac, jbenc
In-Reply-To: <20050513214025.GA1863@elf.ucw.cz>
On Fri, 2005-05-13 at 23:40 +0200, Pavel Machek wrote:
> More cleanups (relative to ipw2100-1.1.0 version). Highlights include
> removing of two printk wrappers.
[snip]
> -static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL);
Any special reason to remove these driver sysfs entries?
Thanks,
-yi
^ permalink raw reply
* [2.6 patch] fix IP_FIB_HASH kconfig warning
From: Adrian Bunk @ 2005-07-03 22:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, zippel
[ This time with a subject... ]
This patch fixes the following kconfig warning:
net/ipv4/Kconfig:92:warning: defaults for choice values not supported
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
I've Cc'ed Roman because I might have missed a more elegant solution.
--- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old 2005-07-02 20:07:25.000000000 +0200
+++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig 2005-07-02 20:13:05.000000000 +0200
@@ -58,8 +58,9 @@
depends on IP_ADVANCED_ROUTER
default IP_FIB_HASH
-config IP_FIB_HASH
+config ASK_IP_FIB_HASH
bool "FIB_HASH"
+ select IP_FIB_HASH
---help---
Current FIB is very proven and good enough for most users.
@@ -84,12 +85,9 @@
endchoice
-# If the user does not enable advanced routing, he gets the safe
-# default of the fib-hash algorithm.
config IP_FIB_HASH
bool
- depends on !IP_ADVANCED_ROUTER
- default y
+ default y if !IP_ADVANCED_ROUTER
config IP_MULTIPLE_TABLES
bool "IP: policy routing"
^ permalink raw reply
* Реклама для Вас
From: Лариса @ 2005-07-03 17:52 UTC (permalink / raw)
To: netdev
Оперативная доставка рекламы
на электронные ящики потенциальных клиентов.
Мы поможем и вам стать известными!
icq - 2 9 2 5 9 3 9 7 3
site - 9911.ws
tel +7 (905) 203~90~72
Operativnaja dostavka reklamy
na elektronnye jashiki potencial'nyh klientov.
My pomoj`em i vam stat' izvestnymi!
^ permalink raw reply
* [-mm patch] net/ieee80211/: remove pci.h #include's
From: Adrian Bunk @ 2005-07-02 23:51 UTC (permalink / raw)
To: jgarzik; +Cc: jkmaline, hostap, netdev, linux-kernel
I was wondering why editing pci.h triggered the rebuild of three files
under net/, and as far as I can see, there's no reason for these three
files to #include pci.h .
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 30 May 2005
- 1 May 2005
net/ieee80211/ieee80211_module.c | 1 -
net/ieee80211/ieee80211_rx.c | 1 -
net/ieee80211/ieee80211_tx.c | 1 -
3 files changed, 3 deletions(-)
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c.old 2005-04-30 23:23:14.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c 2005-04-30 23:23:18.000000000 +0200
@@ -40,7 +40,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c.old 2005-04-30 23:23:25.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c 2005-04-30 23:23:32.000000000 +0200
@@ -33,7 +33,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-04-30 23:23:42.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c 2005-04-30 23:23:46.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox