* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-03 16:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Fabio Checconi, Luigi Rizzo, netdev
In-Reply-To: <20110228171738.2cc8c9a0@nehalam>
Le lundi 28 février 2011 à 17:17 -0800, Stephen Hemminger a écrit :
> +static int qfq_dump_class_stats(struct Qdisc *sch, unsigned long arg,
> + struct gnet_dump *d)
> +{
> + struct qfq_class *cl = (struct qfq_class *)arg;
> + struct tc_qfq_stats xstats;
> +
> + memset(&xstats, 0, sizeof(xstats));
> +
> + xstats.weight = ONE_FP/cl->inv_w;
> + xstats.lmax = cl->lmax;
> +
cl->qdisc->qstats.qlen = cl->qdisc->q.qlen;
> + if (gnet_stats_copy_basic(d, &cl->bstats) < 0 ||
> + gnet_stats_copy_rate_est(d, NULL, &cl->rate_est) < 0 ||
> + gnet_stats_copy_queue(d, &cl->qdisc->qstats) < 0)
> + return -1;
> +
> + return gnet_stats_copy_app(d, &xstats, sizeof(xstats));
> +}
> +
using
gnet_stats_copy_rate_est(d, &cl->bstats, &cl->rate_est) < 0
is better : We avoid dumping null rate estimation, if admin never asked
a rate estimation...
^ permalink raw reply
* Re: bonding...
From: Andy Gospodarek @ 2011-03-03 16:04 UTC (permalink / raw)
To: Neil Horman; +Cc: David Miller, fubar, netdev
In-Reply-To: <20110303114539.GB5146@hmsreliant.think-freely.org>
On Thu, Mar 03, 2011 at 06:45:39AM -0500, Neil Horman wrote:
> On Wed, Mar 02, 2011 at 09:49:10PM -0800, David Miller wrote:
> >
> > Hey, if someone could step up and help with bonding maintainence
> > in some tangible way, I'd really appreciate it.
> >
> > Currently the situation is that many people work on bonding patches,
> > and whilst I do try and wait for some ACKs to arrive, I am the person
> > who has to sort out when changes are ready, decide to apply them, and
> > poke for review when things fall through the cracks.
> >
> > Sometimes patches go for weeks without ACKs, and in that situation
> > I have to either try to understand the changes myself, or wait
> > potentially forever for someone with bonding knowledge to take a
> > good look at the patch and properly review it.
> >
> > It was nearly 2 weeks before Oleg V. Ukhno's 802.3ad round-robin patch
> > got looked at by anyone with bonding knowledge. And it only happened
> > because I got tired of seeing his poor patch rot in patchwork
> > and had to explicitly asked for review the other day.
> >
> > This is unacceptable, people are submitting multiple bonding patches
> > every single day now. It needs a clueful bonding person looking at
> > these submissions on a constant basis.
> >
> > This is a serious problem and is backlogging the netdev patch queue.
> >
> > So if someone would become an active bonding patch-accumulator, and
> > send me sets of patches that are ready to apply, I would really
> > appreciate it.
> >
> > Thanks.
> I nominate gospo. If he doesn't want to, I can do it
> Neil
>
I would be willing to do it, but my one of my goals would be to prevent
some of the feature creep we are currently seeing with bonding (as Ben
has suggested). That doesn't mean I want to stop all new features, but
at this point things are starting to get out of control. I suspect this
is why Jay has struggled to keep up with the patches.
I would also want to look at a restructuring of the configuration. The
lines are starting to blur between some of the modes and output port
selection for other modes and that needs to be cleared up.
How does that sound?
-andy
^ permalink raw reply
* Re: Bug inkvm_set_irq
From: Michael S. Tsirkin @ 2011-03-03 15:55 UTC (permalink / raw)
To: Jean-Philippe Menil; +Cc: netdev, kvm, virtualization
In-Reply-To: <4D6FB313.1010400@univ-nantes.fr>
On Thu, Mar 03, 2011 at 04:26:11PM +0100, Jean-Philippe Menil wrote:
> Le 03/03/2011 15:47, Michael S. Tsirkin a écrit :
> >On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote:
> >>so this time the bug is:
> >>
> >>[17882.612303] BUG: unable to handle kernel paging request at
> >>0000000000002458
> >>[17882.612342] IP: [<ffffffffa03898a0>] kvm_set_irq+0x30/0x140 [kvm]
> >>
> >>markup_oops give me this:
> >>
> >>root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m
> >>/lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
> >>/boot/vmlinuz-2.6.37.2-dsiun-110105+
> >>vmaoffset = 18446744072102621184 ffffffffa0389871: 48 89 e5 mov
> >>%rsp,%rbp
> >> ffffffffa0389874: 41 57 push %r15
> >> ffffffffa0389876: 41 89 cf mov %ecx,%r15d | %r15
> >>=> 1 %ecx = 1
> >> ffffffffa0389879: 41 56 push %r14 | %r14
> >>=> ffffffffa038aad0
> >> ffffffffa038987b: 41 55 push %r13
> >> ffffffffa038987d: 49 89 fd mov %rdi,%r13 | %edi
> >>= 0 %r13 => 0
> >> ffffffffa0389880: 41 54 push %r12 | %r12 => 0
> >> ffffffffa0389882: 53 push %rbx
> >> ffffffffa0389883: 89 d3 mov %edx,%ebx | %ebx => 1a
> >> ffffffffa0389885: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
> >> ffffffffa038988c: 8b 15 00 00 00 00 mov 0x0(%rip),%edx
> >># ffffffffa0389892<kvm_set_irq+0x22>
> >> ffffffffa0389892: 89 b5 3c ff ff ff mov %esi,-0xc4(%rbp) |
> >>%esi = 0
> >> ffffffffa0389898: 85 d2 test %edx,%edx | %edx => 0
> >> ffffffffa038989a: 0f 85 d5 00 00 00 jne ffffffffa0389975
> >><kvm_set_irq+0x105>
> >>*ffffffffa03898a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax |
> >>%eax = 0 %r13 = 0<--- faulting instruction
> >> ffffffffa03898a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
> >> ffffffffa03898ad: 73 61 jae ffffffffa0389910
> >><kvm_set_irq+0xa0>
> >> ffffffffa03898af: 89 db mov %ebx,%ebx
> >> ffffffffa03898b1: 48 8b 84 d8 30 01 00 mov 0x130(%rax,%rbx,8),%rax
> >> ffffffffa03898b8: 00
> >> ffffffffa03898b9: 48 85 c0 test %rax,%rax
> >> ffffffffa03898bc: 74 52 je ffffffffa0389910
> >><kvm_set_irq+0xa0>
> >> ffffffffa03898be: 48 8d 95 40 ff ff ff lea -0xc0(%rbp),%rdx
> >> ffffffffa03898c5: 31 db xor %ebx,%ebx
> >> ffffffffa03898c7: 48 8b 08 mov (%rax),%rcx
> >> ffffffffa03898ca: 83 c3 01 add $0x1,%ebx
> >> ffffffffa03898cd: 0f 18 09 prefetcht0 (%rcx)
> >> ffffffffa03898d0: 48 8b 48 e0 mov -0x20(%rax),%rcx
> >> ffffffffa03898d4: 48 89 0a mov %rcx,(%rdx)
> >> ffffffffa03898d7: 48 8b 48 e8 mov -0x18(%rax),%rcx
> >> ffffffffa03898db: 48 89 4a 08 mov %rcx,0x8(%rdx)
> >> ffffffffa03898df: 48 8b 48 f0 mov -0x10(%rax),%rcx
> >> ffffffffa03898e3: 48 89 4a 10 mov %rcx,0x10(%rdx)
> >> ffffffffa03898e7: 48 8b 48 f8 mov -0x8(%rax),%rcx
> >> ffffffffa03898eb: 48 89 4a 18 mov %rcx,0x18(%rdx)
> >>
> >>wich correspond to offset 68a0 (from objdump):
> >>
> >>kvm_set_irq():
> >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
> >> 68a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax
> >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162
> >> 68a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
> >>
> >>root@ayrshire:~# addr2line -e
> >>/lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
> >>0x68a0
> >>/usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
> >>
> >>So here kvm->irq_routing is null.
> >>
> >>How can it be?
> >>
> >>Regards.
> >Not null, this seems to be invalid.
> >I suspect use after free where the kvm pointer is
> >pointing at some random memory. Use after free?
> >Could you please try enabling a slab debugger,
> >recompile and rerun the test?
> >
> Hi,
>
> I'm not sure to activate the right thing.
> Is that what you want?
>
> CONFIG_SLAB=y
> CONFIG_SLABINFO=y
> CONFIG_DEBUG_SLAB=y
> CONFIG_DEBUG_SLAB_LEAK=y
>
> Regards.
Yes, maybe disable SLAB_LEAK.
> --
> Jean-Philippe Menil - Pôle réseau Service IRTS
> DSI Université de Nantes
> jean-philippe.menil@univ-nantes.fr
> Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-03 15:39 UTC (permalink / raw)
To: Fabio Checconi
Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev,
Paolo Valente
In-Reply-To: <1299166292.2983.112.camel@edumazet-laptop>
Le jeudi 03 mars 2011 à 16:31 +0100, Eric Dumazet a écrit :
> Le jeudi 03 mars 2011 à 16:25 +0100, Eric Dumazet a écrit :
>
> > qfq_dump_class_stats() probably miss one line :
> >
> > scl->bstats.qlen = cl->qdisc->q.qlen;
> >
> >
>
> Hmm,
>
> cl->qdisc->qstats.qlen = cl->qdisc->q.qlen;
>
> It should be better ;)
>
>
Indeed, 'packet count' is now correct in qfq classes
# tc -s -d qdisc show dev dummy0
qdisc cbq 1: root refcnt 2 rate 1000Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 1000Mbit allot 1514b
level 2 ewma 5 avpkt 1000b maxidle 0us
Sent 800 bytes 4 pkt (dropped 0, overlimits 83 requeues 0)
backlog 0b 86p requeues 0
borrowed 0 overactions 0 avgidle 125 undertime 0
qdisc qfq 11: parent 1:11
Sent 800 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
rate 360bit 0pps backlog 0b 86p requeues 0
qdisc pfifo 8001: parent 11:1 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2400b 12p requeues 0
qdisc pfifo 8002: parent 11:2 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2000b 10p requeues 0
qdisc pfifo 8003: parent 11:3 limit 30p
Sent 200 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 3400b 17p requeues 0
qdisc pfifo 8004: parent 11:4 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 1200b 6p requeues 0
qdisc pfifo 8005: parent 11:5 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2400b 12p requeues 0
qdisc pfifo 8006: parent 11:6 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 1400b 7p requeues 0
qdisc pfifo 8007: parent 11:7 limit 30p
Sent 400 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 1400b 7p requeues 0
qdisc pfifo 8008: parent 11:8 limit 30p
Sent 200 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 3000b 15p requeues 0
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-03 15:31 UTC (permalink / raw)
To: Fabio Checconi
Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev,
Paolo Valente
In-Reply-To: <1299165940.2983.111.camel@edumazet-laptop>
Le jeudi 03 mars 2011 à 16:25 +0100, Eric Dumazet a écrit :
> qfq_dump_class_stats() probably miss one line :
>
> scl->bstats.qlen = cl->qdisc->q.qlen;
>
>
Hmm,
cl->qdisc->qstats.qlen = cl->qdisc->q.qlen;
It should be better ;)
^ permalink raw reply
* Re: Bug inkvm_set_irq
From: Jean-Philippe Menil @ 2011-03-03 15:26 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, kvm, virtualization
In-Reply-To: <20110303144715.GA12400@redhat.com>
Le 03/03/2011 15:47, Michael S. Tsirkin a écrit :
> On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote:
>> so this time the bug is:
>>
>> [17882.612303] BUG: unable to handle kernel paging request at
>> 0000000000002458
>> [17882.612342] IP: [<ffffffffa03898a0>] kvm_set_irq+0x30/0x140 [kvm]
>>
>> markup_oops give me this:
>>
>> root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m
>> /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
>> /boot/vmlinuz-2.6.37.2-dsiun-110105+
>> vmaoffset = 18446744072102621184 ffffffffa0389871: 48 89 e5 mov
>> %rsp,%rbp
>> ffffffffa0389874: 41 57 push %r15
>> ffffffffa0389876: 41 89 cf mov %ecx,%r15d | %r15
>> => 1 %ecx = 1
>> ffffffffa0389879: 41 56 push %r14 | %r14
>> => ffffffffa038aad0
>> ffffffffa038987b: 41 55 push %r13
>> ffffffffa038987d: 49 89 fd mov %rdi,%r13 | %edi
>> = 0 %r13 => 0
>> ffffffffa0389880: 41 54 push %r12 | %r12 => 0
>> ffffffffa0389882: 53 push %rbx
>> ffffffffa0389883: 89 d3 mov %edx,%ebx | %ebx => 1a
>> ffffffffa0389885: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
>> ffffffffa038988c: 8b 15 00 00 00 00 mov 0x0(%rip),%edx
>> # ffffffffa0389892<kvm_set_irq+0x22>
>> ffffffffa0389892: 89 b5 3c ff ff ff mov %esi,-0xc4(%rbp) |
>> %esi = 0
>> ffffffffa0389898: 85 d2 test %edx,%edx | %edx => 0
>> ffffffffa038989a: 0f 85 d5 00 00 00 jne ffffffffa0389975
>> <kvm_set_irq+0x105>
>> *ffffffffa03898a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax |
>> %eax = 0 %r13 = 0<--- faulting instruction
>> ffffffffa03898a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
>> ffffffffa03898ad: 73 61 jae ffffffffa0389910
>> <kvm_set_irq+0xa0>
>> ffffffffa03898af: 89 db mov %ebx,%ebx
>> ffffffffa03898b1: 48 8b 84 d8 30 01 00 mov 0x130(%rax,%rbx,8),%rax
>> ffffffffa03898b8: 00
>> ffffffffa03898b9: 48 85 c0 test %rax,%rax
>> ffffffffa03898bc: 74 52 je ffffffffa0389910
>> <kvm_set_irq+0xa0>
>> ffffffffa03898be: 48 8d 95 40 ff ff ff lea -0xc0(%rbp),%rdx
>> ffffffffa03898c5: 31 db xor %ebx,%ebx
>> ffffffffa03898c7: 48 8b 08 mov (%rax),%rcx
>> ffffffffa03898ca: 83 c3 01 add $0x1,%ebx
>> ffffffffa03898cd: 0f 18 09 prefetcht0 (%rcx)
>> ffffffffa03898d0: 48 8b 48 e0 mov -0x20(%rax),%rcx
>> ffffffffa03898d4: 48 89 0a mov %rcx,(%rdx)
>> ffffffffa03898d7: 48 8b 48 e8 mov -0x18(%rax),%rcx
>> ffffffffa03898db: 48 89 4a 08 mov %rcx,0x8(%rdx)
>> ffffffffa03898df: 48 8b 48 f0 mov -0x10(%rax),%rcx
>> ffffffffa03898e3: 48 89 4a 10 mov %rcx,0x10(%rdx)
>> ffffffffa03898e7: 48 8b 48 f8 mov -0x8(%rax),%rcx
>> ffffffffa03898eb: 48 89 4a 18 mov %rcx,0x18(%rdx)
>>
>> wich correspond to offset 68a0 (from objdump):
>>
>> kvm_set_irq():
>> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
>> 68a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax
>> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162
>> 68a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
>>
>> root@ayrshire:~# addr2line -e
>> /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
>> 0x68a0
>> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
>>
>> So here kvm->irq_routing is null.
>>
>> How can it be?
>>
>> Regards.
> Not null, this seems to be invalid.
> I suspect use after free where the kvm pointer is
> pointing at some random memory. Use after free?
> Could you please try enabling a slab debugger,
> recompile and rerun the test?
>
Hi,
I'm not sure to activate the right thing.
Is that what you want?
CONFIG_SLAB=y
CONFIG_SLABINFO=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
Regards.
--
Jean-Philippe Menil - Pôle réseau Service IRTS
DSI Université de Nantes
jean-philippe.menil@univ-nantes.fr
Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-03 15:25 UTC (permalink / raw)
To: Fabio Checconi
Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev,
Paolo Valente
In-Reply-To: <20110303150744.GB29685@gandalf.sssup.it>
Le jeudi 03 mars 2011 à 16:07 +0100, Fabio Checconi a écrit :
> A question on the data below:
>
> > After a stress (and no more trafic) I still have some packets in
> > backlog:
> >
> > (8 packets here)
> >
> ...
> > class qfq 11:10 root weight 1600 maxpkt 2048
> > Sent 200 bytes 1 pkt (dropped 18181, overlimits 0 requeues 0)
> > rate 0bit 0pps backlog 200b 0p requeues 0
>
> Any other reason, apart from a bug in QFQ, why there could be 200b and
> 0p of backlog? A packet count out of sync could explain also why you
> were experiencing problems with pfifo in presence of drops...
My packets are all 200 bytes (from my packet generator)
qfq_dump_class_stats() probably miss one line :
scl->bstats.qlen = cl->qdisc->q.qlen;
^ permalink raw reply
* A misbehavior of handling TCP out of band data ?
From: Li Yu @ 2011-03-03 15:24 UTC (permalink / raw)
To: netdev
Hi,
In my words, if we did not turn on SO_OOBINLINE at receiver,
any OOB bytes do not have to be read from regular TCP byte stream.
But in below extreme case: the sender process have a loop to
send 1 OOB byte 'O' and 1 byte normal data 'D', the receiver ignore
all OOB data, so if OOB feature works well, the receiver should
receive 'D' only, However, in fact, the receiver still can see OOB
bytes by recv() syscall without MSG_OOB flag.
I found that we may send "ODODODODODOD...." in a tcp segment,
and tcp_sendmsg() has no special code to avoid this.
Well, I know that it seem that above case is too extreme to
use in actual environment, but above is simplified from our actual
scenario.
Anyway, I think that overwriting or skip previous OOB bytes is
acceptable, but leave them in regular TCP byte stream likely is a bug.
En, probably, the disabled SO_OOBINLINE just is a feature of receiver
side, sender do not need to have to guarantee it?
Thanks.
Yu
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-03 15:18 UTC (permalink / raw)
To: Fabio Checconi
Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev,
Paolo Valente
In-Reply-To: <1299148820.2983.56.camel@edumazet-laptop>
Le jeudi 03 mars 2011 à 11:40 +0100, Eric Dumazet a écrit :
> Le jeudi 03 mars 2011 à 09:27 +0100, Eric Dumazet a écrit :
>
> > I am going to test an updated version, thanks for all these hints !
> >
>
> Same problem in qfq_qlen_notify()
>
> Should use :
>
> struct qfq_sched *q = qdisc_priv(sch);
>
>
> After a stress (and no more trafic) I still have some packets in
> backlog:
>
> (8 packets here)
>
> # tc -s -d qdisc show dev dummy0
> qdisc cbq 1: root refcnt 2 rate 1000Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 1000Mbit allot 1514b
> level 2 ewma 5 avpkt 1000b maxidle 0us
> Sent 109916000 bytes 549580 pkt (dropped 350412, overlimits 1180608 requeues 0)
> backlog 0b 8p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> qdisc qfq 11: parent 1:11
> Sent 109916000 bytes 549580 pkt (dropped 350412, overlimits 0 requeues 0)
> rate 2848bit 2pps backlog 0b 8p requeues 0
> # tc -s -d class show dev dummy0
> class cbq 1:11 parent 1:1 leaf 11: rate 40000Kbit cell 128b mpu 64b (bounded) prio 2/2 weight 40000Kbit allot 20000b
> level 0 ewma 5 avpkt 1400b maxidle 0us
> Sent 109916000 bytes 549580 pkt (dropped 350412, overlimits 675712 requeues 0)
> rate 1516Kbit 947pps backlog 0b 8p requeues 0
> borrowed 0 overactions 285254 avgidle -22 undertime -24
> class cbq 1: root rate 1000Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 1000Mbit allot 1514b
> level 2 ewma 5 avpkt 1000b maxidle 0us
> Sent 109916000 bytes 549580 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> class cbq 1:1 parent 1: rate 1000Mbit cell 64b mpu 64b (bounded) prio 1/1 weight 1000Mbit allot 10000b
> level 1 ewma 5 avpkt 1500b maxidle 0us
> Sent 109916000 bytes 549580 pkt (dropped 0, overlimits 0 requeues 0)
> rate 1516Kbit 947pps backlog 0b 0p requeues 0
> borrowed 0 overactions 0 avgidle 125 undertime 0
> class qfq 11:10 root weight 1600 maxpkt 2048
> Sent 200 bytes 1 pkt (dropped 18181, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:1 root weight 100 maxpkt 1100
> Sent 2731200 bytes 13656 pkt (dropped 40889, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:2 root weight 200 maxpkt 1200
> Sent 10899800 bytes 54499 pkt (dropped 47, overlimits 0 requeues 0)
> rate 24bit 0pps backlog 0b 0p requeues 0
> class qfq 11:3 root weight 300 maxpkt 1300
> Sent 12714400 bytes 63572 pkt (dropped 65, overlimits 0 requeues 0)
> rate 32bit 0pps backlog 0b 0p requeues 0
> class qfq 11:4 root weight 400 maxpkt 1400
> Sent 400 bytes 2 pkt (dropped 36362, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:5 root weight 500 maxpkt 1500
> Sent 400 bytes 2 pkt (dropped 45452, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:6 root weight 600 maxpkt 1600
> Sent 800 bytes 4 pkt (dropped 27269, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:7 root weight 700 maxpkt 1700
> Sent 600 bytes 3 pkt (dropped 45452, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:8 root weight 800 maxpkt 1800
> Sent 1000 bytes 5 pkt (dropped 72722, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:9 root weight 900 maxpkt 1900
> Sent 1200 bytes 6 pkt (dropped 63631, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
> class qfq 11:a root weight 1000 maxpkt 2000
> Sent 14535200 bytes 72676 pkt (dropped 51, overlimits 0 requeues 0)
> rate 32bit 0pps backlog 0b 0p requeues 0
> class qfq 11:b root weight 1100 maxpkt 2048
> Sent 14531200 bytes 72656 pkt (dropped 72, overlimits 0 requeues 0)
> rate 32bit 0pps backlog 0b 0p requeues 0
> class qfq 11:c root weight 1200 maxpkt 2048
> Sent 10905800 bytes 54529 pkt (dropped 16, overlimits 0 requeues 0)
> rate 24bit 0pps backlog 0b 0p requeues 0
> class qfq 11:d root weight 1300 maxpkt 2048
> Sent 14538200 bytes 72691 pkt (dropped 36, overlimits 0 requeues 0)
> rate 32bit 0pps backlog 0b 0p requeues 0
> class qfq 11:e root weight 1400 maxpkt 2048
> Sent 18162200 bytes 90811 pkt (dropped 96, overlimits 0 requeues 0)
> rate 40bit 0pps backlog 0b 0p requeues 0
> class qfq 11:f root weight 1500 maxpkt 2048
> Sent 10895000 bytes 54475 pkt (dropped 71, overlimits 0 requeues 0)
> rate 24bit 0pps backlog 0b 0p requeues 0
>
>
>
With debugging, I see dequeue() returns early because bitmaps[ER] is
null
if (!q->bitmaps[ER]) {
pr_err("qfq_dequeue bitmaps[ER] is null, return NULL\n");
return NULL;
}
[ 3319.540984] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.544098] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.547184] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.550272] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.553354] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.556435] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.559533] qfq calc_index: W = 1, L = 2048, I = 19
[ 3319.562627] qfq calc_index: W = 1, L = 2048, I = 19
[ 3322.993412] qfq_enqueue: cl = 110004
[ 3322.993457] qfq enqueue: new state 0 0x80000 S 0 F 214748364800 V 0
[ 3322.993493] qfq dequeue: cl ffff880077d45380 len 200 F 214748364800 now 1638400
[ 3322.993543] qfq slot_scan: grp 19 full 0x0
[ 3322.993575] qfq_enqueue: cl = 110007
[ 3322.993603] qfq enqueue: new state 0 0x80000 S 1638400 F 214750003200 V 1638400
[ 3322.993653] qfq_enqueue: cl = 110006
[ 3322.993684] qfq dequeue: cl ffff880077d45100 len 200 F 214750003200 now 3276800
[ 3322.993735] qfq slot_scan: grp 19 full 0x1
[ 3322.993766] qfq_enqueue: cl = 110003
[ 3322.993797] qfq dequeue: cl ffff88011d10e080 len 200 F 214751641600 now 4915200
[ 3322.993847] qfq slot_scan: grp 19 full 0x1
[ 3322.993877] qfq_enqueue: cl = 110002
[ 3322.993906] qfq dequeue: cl ffff880077d45c00 len 200 F 214753280000 now 6553600
[ 3322.997895] qfq slot_scan: grp 19 full 0x1
[ 3322.997925] qfq_enqueue: cl = 110003
[ 3322.997956] qfq_enqueue: cl = 110004
[ 3322.997989] qfq dequeue: cl ffff880077d45380 len 200 F 429496729600 now 8192000
[ 3322.998040] qfq slot_scan: grp 19 full 0x1
[ 3322.998070] qfq_enqueue: cl = 110006
[ 3322.998099] qfq_enqueue: cl = 110008
[ 3322.998130] qfq_enqueue: cl = 110002
[ 3322.998160] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998192] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998224] qfq_enqueue: cl = 110002
[ 3322.998249] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998276] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998305] qfq_enqueue: cl = 110007
[ 3322.998333] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998363] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998395] qfq_enqueue: cl = 110001
[ 3322.998421] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998449] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998478] qfq_enqueue: cl = 110004
[ 3322.998502] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998530] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998558] qfq_enqueue: cl = 110006
[ 3322.998585] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998616] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998649] qfq_enqueue: cl = 110004
[ 3322.998677] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998708] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998739] qfq_enqueue: cl = 110007
[ 3322.998763] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998790] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998832] qfq_enqueue: cl = 110004
[ 3322.998875] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998907] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998937] qfq_enqueue: cl = 110001
[ 3322.998964] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.998997] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999029] qfq_enqueue: cl = 110003
[ 3322.999057] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999087] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999120] qfq_enqueue: cl = 110007
[ 3322.999147] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999178] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999210] qfq_enqueue: cl = 110001
[ 3322.999234] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999261] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999290] qfq_enqueue: cl = 110005
[ 3322.999316] qfq_dequeue bitmaps[ER] is null, return NULL
[ 3322.999343] qfq_dequeue bitmaps[ER] is null, return NULL
[...]
Only 5 packets sent ...
qdisc cbq 1: root refcnt 2 rate 1000Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 1000Mbit allot 1514b
level 2 ewma 5 avpkt 1000b maxidle 0us
Sent 1000 bytes 5 pkt (dropped 0, overlimits 82 requeues 0)
backlog 0b 85p requeues 0
borrowed 0 overactions 0 avgidle 125 undertime 0
qdisc qfq 11: parent 1:11
Sent 1000 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 85p requeues 0
qdisc pfifo 8011: parent 11:1 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2600b 13p requeues 0
qdisc pfifo 8012: parent 11:2 limit 30p
Sent 200 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2400b 12p requeues 0
qdisc pfifo 8013: parent 11:3 limit 30p
Sent 200 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2200b 11p requeues 0
qdisc pfifo 8014: parent 11:4 limit 30p
Sent 400 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2400b 12p requeues 0
qdisc pfifo 8015: parent 11:5 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2000b 10p requeues 0
qdisc pfifo 8016: parent 11:6 limit 30p
Sent 200 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2000b 10p requeues 0
qdisc pfifo 8017: parent 11:7 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 2400b 12p requeues 0
qdisc pfifo 8018: parent 11:8 limit 30p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 1000b 5p requeues 0
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Fabio Checconi @ 2011-03-03 15:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev,
Paolo Valente
In-Reply-To: <1299148820.2983.56.camel@edumazet-laptop>
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, Mar 03, 2011 11:40:20AM +0100
>
> Le jeudi 03 mars 2011 à 09:27 +0100, Eric Dumazet a écrit :
>
> > I am going to test an updated version, thanks for all these hints !
> >
>
> Same problem in qfq_qlen_notify()
>
> Should use :
>
> struct qfq_sched *q = qdisc_priv(sch);
>
Absolutely right, as you're right about qfq_drop(). I'll be able to take
a look when I'm back from work this evening.
A question on the data below:
> After a stress (and no more trafic) I still have some packets in
> backlog:
>
> (8 packets here)
>
...
> class qfq 11:10 root weight 1600 maxpkt 2048
> Sent 200 bytes 1 pkt (dropped 18181, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 200b 0p requeues 0
Any other reason, apart from a bug in QFQ, why there could be 200b and
0p of backlog? A packet count out of sync could explain also why you
were experiencing problems with pfifo in presence of drops...
Thanks for your help, fixes, and testing,
fabio
^ permalink raw reply
* Re: Bad performance when CUBIC HyStart enabled
From: Eric Dumazet @ 2011-03-03 15:03 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110303142229.GA9262@xanadu.blop.info>
Le jeudi 03 mars 2011 à 15:22 +0100, Lucas Nussbaum a écrit :
> Hi,
>
> I'm experiencing bad performance transferring data over a large BDP
> network with CUBIC when HyStart is enabled. Disabling HyStart fixes the
> problem.
>
> Test setup:
> I'm transfering a 2-GB file between two machines using netcat. On both
> machines, /dev/shm is used to store the data.
> On the sending side, I use:
> /dev/shm# while true; do dd if=foo bs=10M | nc -l -p 2222 -q 0; done
> On the receiving side, I use:
> /dev/shm# /usr/bin/time nc 131.254.203.6 2222 > foo
> Both machines are on Gigabit ethernet networks, and the RTT between them
> is 11.3ms.
> The default sysctl values are used.
> I use nload -i 1000000 -o 1000000 -u m eth0 to visualize the transfer
> rate.
>
> With a 2.6.26 kernel, everything is fine. The bandwidth quickly gets to
> ~940 Mbps, and I get the following in nload:
> ..................................
> .##################################
> ###################################
> ###################################
> ###################################
> ####################################
> ####################################
> ####################################
> ####################################
> ####################################
> ####################################
> ####################################
> ####################################
> ####################################
> The transfer time is 18.2s, which is reasonable for a 2-GB file.
>
> With a 2.6.32 kernel (Debian's) or with a 2.6.37 kernel (on the sending
> side only), with the default HyStart parameters, I get the following:
> ..........................
> |##########################.
> |############################
> |#############################
> |##############################
> |###############################
> .#################################
> |##################################|
> |#####################################
> ..||#######################################
> ....|##############################################
> .#####################################################
> The transfer time is 26.8s. (There's one character every 0.5s on the
> graph above)
>
> Disabling hystart on the sending machine with:
> echo 0 > /sys/module/tcp_cubic/parameters/hystart
> Fixes the problem.
>
> It seems that waiting for some time (or rebooting) fixes the problem for
> some time, so I'm suspecting that the problem is caused by a cache of
> some sort. However, doing:
> echo 1 > /proc/sys/net/ipv4/route/flush
> doesn't fix the problem.
>
> Ideas? I could arrange to give access to the testbed if needed.
> (https://www.grid5000.fr/)
eventually, after fresh boot of both sender/receiver, it would be nice
to have "netstat -s" results after one transfert with said problems.
^ permalink raw reply
* Re: Bug inkvm_set_irq
From: Michael S. Tsirkin @ 2011-03-03 14:47 UTC (permalink / raw)
To: Jean-Philippe Menil; +Cc: netdev, kvm, virtualization
In-Reply-To: <4D6D0510.4060300@univ-nantes.fr>
On Tue, Mar 01, 2011 at 03:39:12PM +0100, Jean-Philippe Menil wrote:
> so this time the bug is:
>
> [17882.612303] BUG: unable to handle kernel paging request at
> 0000000000002458
> [17882.612342] IP: [<ffffffffa03898a0>] kvm_set_irq+0x30/0x140 [kvm]
>
> markup_oops give me this:
>
> root@ayrshire:~# cat bug-0103.txt | perl markup_oops.pl -m
> /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
> /boot/vmlinuz-2.6.37.2-dsiun-110105+
> vmaoffset = 18446744072102621184 ffffffffa0389871: 48 89 e5 mov
> %rsp,%rbp
> ffffffffa0389874: 41 57 push %r15
> ffffffffa0389876: 41 89 cf mov %ecx,%r15d | %r15
> => 1 %ecx = 1
> ffffffffa0389879: 41 56 push %r14 | %r14
> => ffffffffa038aad0
> ffffffffa038987b: 41 55 push %r13
> ffffffffa038987d: 49 89 fd mov %rdi,%r13 | %edi
> = 0 %r13 => 0
> ffffffffa0389880: 41 54 push %r12 | %r12 => 0
> ffffffffa0389882: 53 push %rbx
> ffffffffa0389883: 89 d3 mov %edx,%ebx | %ebx => 1a
> ffffffffa0389885: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
> ffffffffa038988c: 8b 15 00 00 00 00 mov 0x0(%rip),%edx
> # ffffffffa0389892 <kvm_set_irq+0x22>
> ffffffffa0389892: 89 b5 3c ff ff ff mov %esi,-0xc4(%rbp) |
> %esi = 0
> ffffffffa0389898: 85 d2 test %edx,%edx | %edx => 0
> ffffffffa038989a: 0f 85 d5 00 00 00 jne ffffffffa0389975
> <kvm_set_irq+0x105>
> *ffffffffa03898a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax |
> %eax = 0 %r13 = 0 <--- faulting instruction
> ffffffffa03898a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
> ffffffffa03898ad: 73 61 jae ffffffffa0389910
> <kvm_set_irq+0xa0>
> ffffffffa03898af: 89 db mov %ebx,%ebx
> ffffffffa03898b1: 48 8b 84 d8 30 01 00 mov 0x130(%rax,%rbx,8),%rax
> ffffffffa03898b8: 00
> ffffffffa03898b9: 48 85 c0 test %rax,%rax
> ffffffffa03898bc: 74 52 je ffffffffa0389910
> <kvm_set_irq+0xa0>
> ffffffffa03898be: 48 8d 95 40 ff ff ff lea -0xc0(%rbp),%rdx
> ffffffffa03898c5: 31 db xor %ebx,%ebx
> ffffffffa03898c7: 48 8b 08 mov (%rax),%rcx
> ffffffffa03898ca: 83 c3 01 add $0x1,%ebx
> ffffffffa03898cd: 0f 18 09 prefetcht0 (%rcx)
> ffffffffa03898d0: 48 8b 48 e0 mov -0x20(%rax),%rcx
> ffffffffa03898d4: 48 89 0a mov %rcx,(%rdx)
> ffffffffa03898d7: 48 8b 48 e8 mov -0x18(%rax),%rcx
> ffffffffa03898db: 48 89 4a 08 mov %rcx,0x8(%rdx)
> ffffffffa03898df: 48 8b 48 f0 mov -0x10(%rax),%rcx
> ffffffffa03898e3: 48 89 4a 10 mov %rcx,0x10(%rdx)
> ffffffffa03898e7: 48 8b 48 f8 mov -0x8(%rax),%rcx
> ffffffffa03898eb: 48 89 4a 18 mov %rcx,0x18(%rdx)
>
> wich correspond to offset 68a0 (from objdump):
>
> kvm_set_irq():
> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
> 68a0: 49 8b 85 58 24 00 00 mov 0x2458(%r13),%rax
> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:162
> 68a7: 3b 98 28 01 00 00 cmp 0x128(%rax),%ebx
>
> root@ayrshire:~# addr2line -e
> /lib/modules/2.6.37.2-dsiun-110105+/kernel/arch/x86/kvm/kvm.ko
> 0x68a0
> /usr/src/GIT/linux-2.6-stable/arch/x86/kvm/../../../virt/kvm/irq_comm.c:161
>
> So here kvm->irq_routing is null.
>
> How can it be?
>
> Regards.
Not null, this seems to be invalid.
I suspect use after free where the kvm pointer is
pointing at some random memory. Use after free?
Could you please try enabling a slab debugger,
recompile and rerun the test?
--
MST
^ permalink raw reply
* Bad performance when CUBIC HyStart enabled
From: Lucas Nussbaum @ 2011-03-03 14:22 UTC (permalink / raw)
To: netdev; +Cc: Sangtae Ha
Hi,
I'm experiencing bad performance transferring data over a large BDP
network with CUBIC when HyStart is enabled. Disabling HyStart fixes the
problem.
Test setup:
I'm transfering a 2-GB file between two machines using netcat. On both
machines, /dev/shm is used to store the data.
On the sending side, I use:
/dev/shm# while true; do dd if=foo bs=10M | nc -l -p 2222 -q 0; done
On the receiving side, I use:
/dev/shm# /usr/bin/time nc 131.254.203.6 2222 > foo
Both machines are on Gigabit ethernet networks, and the RTT between them
is 11.3ms.
The default sysctl values are used.
I use nload -i 1000000 -o 1000000 -u m eth0 to visualize the transfer
rate.
With a 2.6.26 kernel, everything is fine. The bandwidth quickly gets to
~940 Mbps, and I get the following in nload:
..................................
.##################################
###################################
###################################
###################################
####################################
####################################
####################################
####################################
####################################
####################################
####################################
####################################
####################################
The transfer time is 18.2s, which is reasonable for a 2-GB file.
With a 2.6.32 kernel (Debian's) or with a 2.6.37 kernel (on the sending
side only), with the default HyStart parameters, I get the following:
..........................
|##########################.
|############################
|#############################
|##############################
|###############################
.#################################
|##################################|
|#####################################
..||#######################################
....|##############################################
.#####################################################
The transfer time is 26.8s. (There's one character every 0.5s on the
graph above)
Disabling hystart on the sending machine with:
echo 0 > /sys/module/tcp_cubic/parameters/hystart
Fixes the problem.
It seems that waiting for some time (or rebooting) fixes the problem for
some time, so I'm suspecting that the problem is caused by a cache of
some sort. However, doing:
echo 1 > /proc/sys/net/ipv4/route/flush
doesn't fix the problem.
Ideas? I could arrange to give access to the testbed if needed.
(https://www.grid5000.fr/)
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Changli Gao @ 2011-03-03 14:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Patrick McHardy, Eric Dumazet, Andrian Nord, lxc-users,
Linux Netdev List
In-Reply-To: <4D6E8D80.3090907@free.fr>
On Thu, Mar 3, 2011 at 2:33 AM, Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>
> One last question. In the case of broadcast packets with maclvan in bridge
> mode.
> We will have the packets going through each macvlan port and also to the
> lower-device, right ?
> For the latter, don't we have a problem if the packet is flagged
> CHECKSUM_UNNECESSARY ?
>
> Shouldn't we restore the ip_summed field before sending through
> dev_queue_xmit ?
>
> ---
> drivers/net/macvlan.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux-next/drivers/net/macvlan.c
> ===================================================================
> --- linux-next.orig/drivers/net/macvlan.c
> +++ linux-next/drivers/net/macvlan.c
> @@ -222,10 +222,13 @@ static int macvlan_queue_xmit(struct sk_
>
> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
> const struct ethhdr *eth = (void *)skb->data;
> + __u8 ip_summed = skb->ip_summed;
> + skb->ip_summed; = CHECKSUM_UNNECESSARY;
You added a additional ";".
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] sctp: fix the fast retransmit limit
From: Vladislav Yasevich @ 2011-03-03 14:16 UTC (permalink / raw)
To: Wei Yongjun
Cc: David Miller, netdev@vger.kernel.org, lksctp, Mingyuan Zhu,
Neil Horman
In-Reply-To: <4D6F5F83.705@cn.fujitsu.com>
On 03/03/2011 04:29 AM, Wei Yongjun wrote:
> If chunk is still lost after fast retransmit, SCTP stack will
> never allow the second fast retransmit of this chunk, even if
> the peer need we do this. This chunk will be retransmit until
> the rtx timeout. This limit is introduce by the following patch:
> sctp: reduce memory footprint of sctp_chunk structure
> (c226ef9b83694311327f3ab0036c6de9c22e9daf)
>
> This patch revert this limit and removed useless SCTP_DONT_FRTX.
NACK. Please read the spec and how fast recovery is specified.
-vlad
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> include/net/sctp/structs.h | 1 -
> net/sctp/outqueue.c | 4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index cc9185c..82a0f84 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -751,7 +751,6 @@ struct sctp_chunk {
>
> #define SCTP_CAN_FRTX 0x0
> #define SCTP_NEED_FRTX 0x1
> -#define SCTP_DONT_FRTX 0x2
> __u16 rtt_in_progress:1, /* This chunk used for RTT calc? */
> has_tsn:1, /* Does this chunk have a TSN yet? */
> has_ssn:1, /* Does this chunk have a SSN yet? */
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 8c6d379..7ed5862 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -657,7 +657,7 @@ redo:
> * after it is retransmitted.
> */
> if (chunk->fast_retransmit == SCTP_NEED_FRTX)
> - chunk->fast_retransmit = SCTP_DONT_FRTX;
> + chunk->fast_retransmit = SCTP_CAN_FRTX;
>
> q->empty = 0;
> break;
> @@ -679,7 +679,7 @@ redo:
> if (rtx_timeout || fast_rtx) {
> list_for_each_entry(chunk1, lqueue, transmitted_list) {
> if (chunk1->fast_retransmit == SCTP_NEED_FRTX)
> - chunk1->fast_retransmit = SCTP_DONT_FRTX;
> + chunk1->fast_retransmit = SCTP_CAN_FRTX;
> }
> }
>
^ permalink raw reply
* Re: [PATCH] sctp: do not mark chunk abandoned if peer has no PRSCTP capable
From: Vladislav Yasevich @ 2011-03-03 14:14 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev@vger.kernel.org, lksctp, David Miller
In-Reply-To: <4D6F1723.5030909@cn.fujitsu.com>
On 03/02/2011 11:20 PM, Wei Yongjun wrote:
> Chunk is marked abandoned if the chunk is expires, and it not be
> retransmited even if the peer has no PRSCTP capable, but the peer
> will still wait for retransmit it to update CTSN.
> This patch disable mark chunk abandoned if peer has no PRSCTP
> capable.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> net/sctp/chunk.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> index 6c85564..0d4832d 100644
> --- a/net/sctp/chunk.c
> +++ b/net/sctp/chunk.c
> @@ -347,6 +347,9 @@ int sctp_chunk_abandoned(struct sctp_chunk *chunk)
> {
> struct sctp_datamsg *msg = chunk->msg;
>
> + if (!chunk->asoc->peer.prsctp_capable)
> + return 0;
> +
> if (!msg->can_abandon)
> return 0;
>
The trouble is that timetolive can be set on a message independent of Partial Reliability.
The difference in behavior is that when PR can't be used, a chunk can only be abandoned
if it has not yet been transmitted. With PR enabled, the chunk can be abandoned at any time.
So, you can't blindly disallow abandonment.
-vlad
^ permalink raw reply
* Re: [PATCH 01/27] HFI: skeleton driver
From: Christoph Hellwig @ 2011-03-03 14:07 UTC (permalink / raw)
To: dykmanj
Cc: netdev, Piyush Chaudhary, Fu-Chung Chang, William S. Cadden,
Wen C. Chen, Scot Sakolish, Jian Xiao, Carol L. Soto,
Sarah J. Sheppard
In-Reply-To: <1299100213-8770-1-git-send-email-dykmanj@linux.vnet.ibm.com>
On Wed, Mar 02, 2011 at 04:09:47PM -0500, dykmanj@linux.vnet.ibm.com wrote:
> From: Jim Dykman <dykmanj@linux.vnet.ibm.com>
>
> Device driver Makefile & Kconfig plumbing plus simple mod_init and mod_exit
It would help a lot if you could explain what the heck HFI is.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix BT_L2CAP and BT_SCO in Kconfig
From: John W. Linville @ 2011-03-03 14:05 UTC (permalink / raw)
To: David Miller
Cc: padovan-Y3ZbgMPKUGA34EUeqzHoZw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110302.215433.39198854.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, Mar 02, 2011 at 09:54:33PM -0800, David Miller wrote:
> From: "Gustavo F. Padovan" <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
> Date: Fri, 25 Feb 2011 22:41:25 -0300
>
> > If we want something "bool" built-in in something "tristate" it can't
> > "depend on" the tristate config option.
> >
> > Report by DaveM:
> >
> > I give it 'y' just to make it happen, for both, and afterways no
> > matter how many times I rerun "make oldconfig" I keep seeing things
> > like this in my build:
> >
> > scripts/kconfig/conf --silentoldconfig Kconfig
> > include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
> > include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP
> >
> > Reported-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > Signed-off-by: Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
>
> I think this approach is fine since it mirrors what we use in other similar
> situations.
>
> I am assuming this patch will propagate via bluetooth --> wireless --> me.
Yes, I have it queued.
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH (sh-2.6) 1/4] clksource: Generic timer infrastructure
From: Arnd Bergmann @ 2011-03-03 13:55 UTC (permalink / raw)
To: Peppe CAVALLARO
Cc: Thomas Gleixner, Stuart MENEFY, linux-sh@vger.kernel.org,
netdev@vger.kernel.org, John Stultz, linux-kernel@vger.kernel.org,
linux@arm.linux.org.uk
In-Reply-To: <4D6F6C96.1010303@st.com>
On Thursday 03 March 2011, Peppe CAVALLARO wrote:
> This logic is already in the driver, indeed.
> What I've seen on our embedded systems is that the
> cost of RX interrupts is very hight and NAPI partially helps.
> Typically, in an IP-STB, I receive a burst of UDP pkt
> and this means that many interrupts occur (~99% of CPU
> usage on slow platforms).
> With the ext timer I was able to reduce the CPU usage in
> these kind of scenarios to ~50%.
I don't understand. Shouldn't the interrupts be stopped as long
as the system is busy? This sounds like a bug in your NAPI
handling, or maybe you just need to use a lower NAPI_WEIGHT
so you stay in polling mode longer.
Arnd
^ permalink raw reply
* Re: [RFC PATCH] net/core: fix skb handling on netif serves for both bridge and vlan
From: Ben Hutchings @ 2011-03-03 13:53 UTC (permalink / raw)
To: Xiaotian Feng
Cc: netdev, linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert
In-Reply-To: <1299149713-18740-1-git-send-email-dfeng@redhat.com>
On Thu, 2011-03-03 at 18:55 +0800, Xiaotian Feng wrote:
> Consider network topology as follows:
>
> eth0 eth1
> |_____|
> |
> bond0 --- br0
> |
> vlan0 --- br1
>
> bond0 serves for both br0 and vlan0, if a vlan tagged packet was sent
> to br1 through bond0, bridge handling code is seeing the packet on bond0
> and handing it off to my "legacy" bridge before vlan_tx_tag_present
> and vlan_hwaccel_do_receive even haven't a chance to look at it.
[...]
This used to work if the underlying device (bond0 in your example)
implemented VLAN tag extraction, because the VLAN group would be checked
before the bridge. But it never worked for devices without VLAN tag
extraction. Perhaps we should just prevent this configuration.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: r8169 disable ASPM patch
From: Ben Hutchings @ 2011-03-03 13:48 UTC (permalink / raw)
To: hayeswang
Cc: 'Francois Romieu', 'David Miller', netdev,
sgruszka
In-Reply-To: <A671CA7371854B808BAB6DA0BA7B050B@realtek.com.tw>
On Thu, 2011-03-03 at 19:35 +0800, hayeswang wrote:
[...]
> > > Is there going to be a MAINTAINERS patch that adds Hayes? If so what
> > > is stalling that?
>
> Realtek would continue handling the kernel. However, the person may be different
> for different period. Therefore, I think keeping the current mode is better.
[...]
Perhaps you could add a contact alias address, like our
linux-net-drivers@solarflare.com.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: bonding...
From: Ben Hutchings @ 2011-03-03 13:46 UTC (permalink / raw)
To: David Miller; +Cc: fubar, netdev
In-Reply-To: <20110302.214910.112578818.davem@davemloft.net>
On Wed, 2011-03-02 at 21:49 -0800, David Miller wrote:
[...]
> This is unacceptable, people are submitting multiple bonding patches
> every single day now. It needs a clueful bonding person looking at
> these submissions on a constant basis.
[...]
And preferably saying 'no' to most new features...
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next-2.6] net_sched: reduce fifo qdisc size
From: Eric Dumazet @ 2011-03-03 13:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Because of various alignements [SLUB / qdisc], we use 512 bytes of
memory for one {p|b}fifo qdisc, instead of 256 bytes on 64bit arches and
192 bytes on 32bit ones.
Move the "u32 limit" inside "struct Qdisc" (no impact on other qdiscs)
Change qdisc_alloc(), first trying a regular allocation before an
oversized one.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/sch_generic.h | 1 +
net/sched/sch_fifo.c | 34 +++++++++++-----------------------
net/sched/sch_generic.c | 18 +++++++++++-------
3 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 16626a0..1934634 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -83,6 +83,7 @@ struct Qdisc {
struct gnet_stats_queue qstats;
struct rcu_head rcu_head;
spinlock_t busylock;
+ u32 limit;
};
static inline bool qdisc_is_running(const struct Qdisc *qdisc)
diff --git a/net/sched/sch_fifo.c b/net/sched/sch_fifo.c
index be33f9d..66effe2 100644
--- a/net/sched/sch_fifo.c
+++ b/net/sched/sch_fifo.c
@@ -19,15 +19,9 @@
/* 1 band FIFO pseudo-"scheduler" */
-struct fifo_sched_data {
- u32 limit;
-};
-
static int bfifo_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
- struct fifo_sched_data *q = qdisc_priv(sch);
-
- if (likely(sch->qstats.backlog + qdisc_pkt_len(skb) <= q->limit))
+ if (likely(sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit))
return qdisc_enqueue_tail(skb, sch);
return qdisc_reshape_fail(skb, sch);
@@ -35,9 +29,7 @@ static int bfifo_enqueue(struct sk_buff *skb, struct Qdisc *sch)
static int pfifo_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
- struct fifo_sched_data *q = qdisc_priv(sch);
-
- if (likely(skb_queue_len(&sch->q) < q->limit))
+ if (likely(skb_queue_len(&sch->q) < sch->limit))
return qdisc_enqueue_tail(skb, sch);
return qdisc_reshape_fail(skb, sch);
@@ -45,9 +37,7 @@ static int pfifo_enqueue(struct sk_buff *skb, struct Qdisc *sch)
static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
- struct fifo_sched_data *q = qdisc_priv(sch);
-
- if (likely(skb_queue_len(&sch->q) < q->limit))
+ if (likely(skb_queue_len(&sch->q) < sch->limit))
return qdisc_enqueue_tail(skb, sch);
/* queue full, remove one skb to fulfill the limit */
@@ -60,7 +50,6 @@ static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc *sch)
static int fifo_init(struct Qdisc *sch, struct nlattr *opt)
{
- struct fifo_sched_data *q = qdisc_priv(sch);
bool bypass;
bool is_bfifo = sch->ops == &bfifo_qdisc_ops;
@@ -70,20 +59,20 @@ static int fifo_init(struct Qdisc *sch, struct nlattr *opt)
if (is_bfifo)
limit *= psched_mtu(qdisc_dev(sch));
- q->limit = limit;
+ sch->limit = limit;
} else {
struct tc_fifo_qopt *ctl = nla_data(opt);
if (nla_len(opt) < sizeof(*ctl))
return -EINVAL;
- q->limit = ctl->limit;
+ sch->limit = ctl->limit;
}
if (is_bfifo)
- bypass = q->limit >= psched_mtu(qdisc_dev(sch));
+ bypass = sch->limit >= psched_mtu(qdisc_dev(sch));
else
- bypass = q->limit >= 1;
+ bypass = sch->limit >= 1;
if (bypass)
sch->flags |= TCQ_F_CAN_BYPASS;
@@ -94,8 +83,7 @@ static int fifo_init(struct Qdisc *sch, struct nlattr *opt)
static int fifo_dump(struct Qdisc *sch, struct sk_buff *skb)
{
- struct fifo_sched_data *q = qdisc_priv(sch);
- struct tc_fifo_qopt opt = { .limit = q->limit };
+ struct tc_fifo_qopt opt = { .limit = sch->limit };
NLA_PUT(skb, TCA_OPTIONS, sizeof(opt), &opt);
return skb->len;
@@ -106,7 +94,7 @@ nla_put_failure:
struct Qdisc_ops pfifo_qdisc_ops __read_mostly = {
.id = "pfifo",
- .priv_size = sizeof(struct fifo_sched_data),
+ .priv_size = 0,
.enqueue = pfifo_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
@@ -121,7 +109,7 @@ EXPORT_SYMBOL(pfifo_qdisc_ops);
struct Qdisc_ops bfifo_qdisc_ops __read_mostly = {
.id = "bfifo",
- .priv_size = sizeof(struct fifo_sched_data),
+ .priv_size = 0,
.enqueue = bfifo_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
@@ -136,7 +124,7 @@ EXPORT_SYMBOL(bfifo_qdisc_ops);
struct Qdisc_ops pfifo_head_drop_qdisc_ops __read_mostly = {
.id = "pfifo_head_drop",
- .priv_size = sizeof(struct fifo_sched_data),
+ .priv_size = 0,
.enqueue = pfifo_tail_enqueue,
.dequeue = qdisc_dequeue_head,
.peek = qdisc_peek_head,
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 0da09d5..a854cab 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -550,21 +550,25 @@ struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
{
void *p;
struct Qdisc *sch;
- unsigned int size;
+ unsigned int size = QDISC_ALIGN(sizeof(*sch)) + ops->priv_size;
int err = -ENOBUFS;
- /* ensure that the Qdisc and the private data are 64-byte aligned */
- size = QDISC_ALIGN(sizeof(*sch));
- size += ops->priv_size + (QDISC_ALIGNTO - 1);
-
p = kzalloc_node(size, GFP_KERNEL,
netdev_queue_numa_node_read(dev_queue));
if (!p)
goto errout;
sch = (struct Qdisc *) QDISC_ALIGN((unsigned long) p);
- sch->padded = (char *) sch - (char *) p;
-
+ /* if we got non aligned memory, ask more and do alignment ourself */
+ if (sch != p) {
+ kfree(p);
+ p = kzalloc_node(size + QDISC_ALIGNTO - 1, GFP_KERNEL,
+ netdev_queue_numa_node_read(dev_queue));
+ if (!p)
+ goto errout;
+ sch = (struct Qdisc *) QDISC_ALIGN((unsigned long) p);
+ sch->padded = (char *) sch - (char *) p;
+ }
INIT_LIST_HEAD(&sch->list);
skb_queue_head_init(&sch->q);
spin_lock_init(&sch->busylock);
^ permalink raw reply related
* Re: [PATCH] mv643xx_eth: Use netdev_<level> and pr_<level>
From: Lennert Buytenhek @ 2011-03-03 13:18 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1299124235.4208.129.camel@Joe-Laptop>
On Wed, Mar 02, 2011 at 07:50:35PM -0800, Joe Perches wrote:
> Use the current logging styles.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
> I don't know if this module is still being maintained.
Maintained, yes, actively developed, no, but that's just because
there's not much left to be done, as it works pretty well (AFAICT).
^ permalink raw reply
* Re: [BUG] VPN broken in net-next
From: Julian Anastasov @ 2011-03-03 13:09 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <alpine.LFD.2.00.1103031414240.1677@ja.ssi.bg>
Hello,
On Thu, 3 Mar 2011, Julian Anastasov wrote:
> May be the problem is in inet_hash_insert(), it should
> hash ifa_local, not ifa_address. May be they are equal for
... and of course the new __ip_dev_find should use
ifa_local too.
> the common case but not for peer addresses. In devinet_ioctl()
> we can see they are equal initially:
>
> ifa->ifa_address = ifa->ifa_local = sin->sin_addr.s_addr;
>
> but later SIOCSIFDSTADDR can change ifa_address which
> is destination address from the same prefix:
>
> ifa->ifa_address = sin->sin_addr.s_addr;
While checking for ifa_address usage I see other
two places that look suspicious:
- inet_gifconf() exposes address from ifa_local but then
devinet_ioctl() matches by ifa_address in the
'if (tryaddrmatch)' block. I think, we should use ifa_local.
- IN_DEV_ARP_NOTIFY: announces ifa_address instead of ifa_local.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ 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