Re: New filter 'flow' bug?

Re: New filter 'flow' bug?

[almaop]

> > From: almaop@poczta.fm
> > Date: 29 Oct 2008 08:27:05 +0100
> >> My configuration: gentoo, kernel 2.6.26.7 + imq patch + l7 patch, glibc
> 2.7, iproute2 2.6.26. Shaping is done on ethernet (e1000 card) but as I see
> on the ifb nothing changes.
> >> There are htb 3 classes with sfq as their qdiscs. It is simple,
> something like:
> >>
> >> tc qdisc add dev $DEV root handle 1: htb default 4 tc class add dev
> $DEV parent 1: classid 1:1 htb rate 78kbps ceil 78kbps overhead 0 linklayer
> atm
> >>
> >> tc class add dev $DEV parent 1:1 classid 1:2 htb rate 20kbps ceil
> 20kbps overhead 0 linklayer atm prio 3
> >> tc class add dev $DEV parent 1:1 classid 1:3 ...
> >> tc class add dev $DEV parent 1:1 classid 1:4 ...
> >>  
> >> tc qdisc add dev $DEV parent 1:2 handle 2: sfq quantum 64
> >> tc qdisc add dev $DEV parent 1:3 handle 3: sfq
> >> tc qdisc add dev $DEV parent 1:4 handle 4: sfq
> >>
> >> tc filter add dev $DEV parent 1: ....
> >> ....
> >>  
> >> tc filter add dev $DEV parent 2: protocol ip handle 1 prio 12 flow 
> >> hash keys dst,proto,proto-dst divisor 128
> >>
> >> tc filter add dev $DEV parent 3: protocol ip handle 1 prio 12 flow 
> >> hash keys dst,proto,proto-dst divisor 128
> >>
> >> tc filter add dev $DEV parent 4: protocol ip handle 1 prio 12 flow 
> >> hash keys nfct-src,nfct-dst,proto,nfct-proto-src,nfct-proto-dst divisor
> 128
> >>
> >> I'm not sure where is the bug - in the flow filter or in the sfq
> qdisc.
> 
> Which SFQ qdisc is stalling?
> 
Thanks for reply.
So I've done few tests. I've removed quantum 64 (it  was qdisc with small packets). It made no difference. It looks like the key is the first sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my example). When there is no traffic in this qdisc for about 45 seconds (shorter time when there is no traffic at all on the interface) - it stalls. Other qdiscs stall also. So there is no packet flow on that interface. Removing filters ('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And then the traffic is resumed.
Regards.

Krzysiek

Re: New filter 'flow' bug?

[Patrick McHardy]

almaop@poczta.fm wrote:
>>> From: almaop@poczta.fm
>>>> I'm not sure where is the bug - in the flow filter or in the sfq
>> qdisc.
>>
>> Which SFQ qdisc is stalling?
>>
> Thanks for reply.
> So I've done few tests. I've removed quantum 64 (it  was qdisc with small packets). It made no difference. It looks like the key is the first sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my example). When there is no traffic in this qdisc for about 45 seconds (shorter time when there is no traffic at all on the interface) - it stalls. Other qdiscs stall also. So there is no packet flow on that interface. Removing filters ('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And then the traffic is resumed.

Please capture the output of "tc -s -d qdisc show dev <dev>" and
"tc -s -d class show dev <dev>" immediately after it stalls.
I'm interested in the amount of bytes/packets queued at the moment.

Re: New filter 'flow' bug?

[almaop]

> almaop@poczta.fm wrote:
> >> almaop@poczta.fm wrote:
> >>>>> From: almaop@poczta.fm
> >>>>>> I'm not sure where is the bug - in the flow filter or in the sfq
> >>>> qdisc.
> >>>>
> >>>> Which SFQ qdisc is stalling?
> >>>>
> >>> Thanks for reply.
> >>> So I've done few tests. I've removed quantum 64 (it  was qdisc with
> >> small packets). It made no difference. It looks like the key is the
> first
> >> sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my
> example).
> >> When there is no traffic in this qdisc for about 45 seconds (shorter
> time
> >> when there is no traffic at all on the interface) - it stalls. Other
> qdiscs
> >> stall also. So there is no packet flow on that interface. Removing
> filters
> >> ('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And
> then
> >> the traffic is resumed.
> >>
> >> Please capture the output of "tc -s -d qdisc show dev <dev>" and
> >> "tc -s -d class show dev <dev>" immediately after it stalls.
> >> I'm interested in the amount of bytes/packets queued at the moment.
> >>
> > 
> > I've captured it eve
> > It looks like this:
> > Example 1:
> > 
> > ...
> 
> In both cases there are no packets queued, so its not the qdiscs
> which are stalling. My shot in the dark is  is that your classifier
> rules are incorrect and don't handle ARP packets.

I've removed 'tc qdisc add htb .... default x'
                                    ^^^^^^^^^^
And now it works, so you are right. Sorry for taking your time.
Regards.

Krzysiek

----------------------------------------------------------------------
Dzwon taniej na zagraniczne komorki!
Sprawdz >> http://link.interia.pl/f1f6a

Re: New filter 'flow' bug?

[almaop]

> almaop@poczta.fm wrote:
> >>> From: almaop@poczta.fm
> >>>> I'm not sure where is the bug - in the flow filter or in the sfq
> >> qdisc.
> >>
> >> Which SFQ qdisc is stalling?
> >>
> > Thanks for reply.
> > So I've done few tests. I've removed quantum 64 (it  was qdisc with
> small packets). It made no difference. It looks like the key is the first
> sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my example).
> When there is no traffic in this qdisc for about 45 seconds (shorter time
> when there is no traffic at all on the interface) - it stalls. Other qdiscs
> stall also. So there is no packet flow on that interface. Removing filters
> ('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And then
> the traffic is resumed.
> 
> Please capture the output of "tc -s -d qdisc show dev <dev>" and
> "tc -s -d class show dev <dev>" immediately after it stalls.
> I'm interested in the amount of bytes/packets queued at the moment.
> 

I've captured it eve
It looks like this:
Example 1:

qdisc htb 1: root r2q 10 default 4 direct_packets_stat 3 ver 3.17
 Sent 1206781 bytes 12855 pkt (dropped 0, overlimits 10539 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 2: parent 1:2 limit 127p quantum 1514b flows 127/1024 
 Sent 647460 bytes 9862 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 3: parent 1:3 limit 127p quantum 1514b flows 127/1024 
 Sent 449824 bytes 2745 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 4: parent 1:4 limit 127p quantum 1514b flows 127/1024 
 Sent 109233 bytes 244 pkt (dropped 1, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
class htb 1:1 root rate 624000bit ceil 624000bit burst 1912b/8 mpu 0b overhead 0b cburst 1912b/8 mpu 0b overhead 0b level 7 
 Sent 1206583 bytes 12852 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 19104bit 13pps backlog 0b 0p requeues 0 
 lended: 4987 borrowed: 0 giants: 0
 tokens: 22624 ctokens: 22624

class htb 1:2 parent 1:1 leaf 2: prio 3 quantum 1500 rate 120000bit ceil 160000bit burst 1659b/8 mpu 0b overhead 0b cburst 1679b/8 mpu 0b overhead 0b level 0 
 Sent 647460 bytes 9862 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 4552bit 9pps backlog 0b 0p requeues 0 
 lended: 5451 borrowed: 4411 giants: 0
 tokens: 101172 ctokens: 79297

class htb 1:3 parent 1:1 leaf 3: prio 4 quantum 3000 rate 240000bit ceil 560000bit burst 1719b/8 mpu 0b overhead 0b cburst 1880b/8 mpu 0b overhead 0b level 0 
 Sent 449824 bytes 2745 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 2976bit 2pps backlog 0b 0p requeues 0 
lended: 2177 borrowed: 568 giants: 0
 tokens: 53386 ctokens: 24763

class htb 1:4 parent 1:1 leaf 4: prio 5 quantum 1500 rate 120000bit ceil 560000bit burst 1659b/8 mpu 0b overhead 0b cburst 1880b/8 mpu 0b overhead 0b level 0 
 Sent 109299 bytes 245 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 11568bit 3pps backlog 0b 0p requeues 0 
 lended: 237 borrowed: 8 giants: 0
 tokens: 101172 ctokens: 24763


Example 2:
(with longer txqueue)

qdisc htb 1: root r2q 10 default 4 direct_packets_stat 0 ver 3.17
 Sent 17205588 bytes 211080 pkt (dropped 0, overlimits 199620 requeues 5) 
 rate 0bit 0pps backlog 0b 0p requeues 5 
qdisc sfq 2: parent 1:2 limit 127p quantum 1514b flows 127/1024 
 Sent 11256846 bytes 179165 pkt (dropped 1200, overlimits 0 requeues 5) 
 rate 0bit 0pps backlog 0b 0p requeues 5 
qdisc sfq 3: parent 1:3 limit 127p quantum 1514b flows 127/1024 
 Sent 5225274 bytes 30009 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 4: parent 1:4 limit 127p quantum 1514b flows 127/1024 
 Sent 723468 bytes 1906 pkt (dropped 8, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
class htb 1:1 root rate 624000bit ceil 624000bit burst 1912b/8 mpu 0b overhead 0b cburst 1912b/8 mpu 0b overhead 0b level 7 
 Sent 17207118 bytes 211085 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 41968bit 42pps backlog 0b 0p requeues 0 
 lended: 85962 borrowed: 0 giants: 0
 tokens: 12267 ctokens: 12267

class htb 1:2 parent 1:1 leaf 2: prio 3 quantum 1500 rate 120000bit ceil 160000bit burst 1659b/8 mpu 0b overhead 0b cburst 1679b/8 mpu 0b overhead 0b level 0 
 Sent 11256846 bytes 179165 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 16496bit 37pps backlog 0b 0p requeues 0 
 lended: 95202 borrowed: 83968 giants: 0
 tokens: 101172 ctokens: 79297

class htb 1:3 parent 1:1 leaf 3: prio 4 quantum 3000 rate 240000bit ceil 560000bit burst 1719b/8 mpu 0b overhead 0b cburst 1880b/8 mpu 0b overhead 0b level 0 
 Sent 5225274 bytes 30009 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 1576bit 1pps backlog 0b 0p requeues 0 
 lended: 28163 borrowed: 1846 giants: 0
 tokens: 510 ctokens: 24763

class htb 1:4 parent 1:1 leaf 4: prio 5 quantum 1500 rate 120000bit ceil 560000bit burst 1659b/8 mpu 0b overhead 0b cburst 1880b/8 mpu 0b overhead 0b level 0 
 Sent 723468 bytes 1906 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 23880bit 4pps backlog 0b 0p requeues 0 
 lended: 1758 borrowed: 148 giants: 0
 tokens: 3049 ctokens: 7974


Krzysiek

----------------------------------------------------------------------
Wymysl wierszyk, wygraj cyfrowke!
Sprawdz >>> http://link.interia.pl/f1f5a

Re: New filter 'flow' bug?

[Patrick McHardy]

almaop@poczta.fm wrote:
>> almaop@poczta.fm wrote:
>>>>> From: almaop@poczta.fm
>>>>>> I'm not sure where is the bug - in the flow filter or in the sfq
>>>> qdisc.
>>>>
>>>> Which SFQ qdisc is stalling?
>>>>
>>> Thanks for reply.
>>> So I've done few tests. I've removed quantum 64 (it  was qdisc with
>> small packets). It made no difference. It looks like the key is the first
>> sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my example).
>> When there is no traffic in this qdisc for about 45 seconds (shorter time
>> when there is no traffic at all on the interface) - it stalls. Other qdiscs
>> stall also. So there is no packet flow on that interface. Removing filters
>> ('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And then
>> the traffic is resumed.
>>
>> Please capture the output of "tc -s -d qdisc show dev <dev>" and
>> "tc -s -d class show dev <dev>" immediately after it stalls.
>> I'm interested in the amount of bytes/packets queued at the moment.
>>
> 
> I've captured it eve
> It looks like this:
> Example 1:
> 
> ...

In both cases there are no packets queued, so its not the qdiscs
which are stalling. My shot in the dark is  is that your classifier
rules are incorrect and don't handle ARP packets.

Re: New filter 'flow' bug?

[David Miller]

From: almaop@poczta.fm
Date: 29 Oct 2008 08:27:05 +0100

Deeply technical questions are almost certainly going to get zero
response on linux-net.  So using netdev is generally a better idea
since that actually gets to the networking developers.

Added to CC:

> Hi. I'm using this new "flow" filter:
> (http://www.mail-archive.com/netdev@vger.kernel.org/msg60638.html). It is configuration as above: tc filter flow classify packets in the sfq. It works (as it seems) fine. But only until there is some traffic in the queue. When there is some interruption in the packets flow (for a while) something goes wrong and the queue blocks. From that moment onward nothing goes trough. It is very annoying. You have to remove sfq to resume traffic.
> Is anybody using this new filter which sfq?
> My configuration: gentoo, kernel 2.6.26.7 + imq patch + l7 patch, glibc 2.7, iproute2 2.6.26. Shaping is done on ethernet (e1000 card) but as I see on the ifb nothing changes.
> There are htb 3 classes with sfq as their qdiscs. It is simple, something like:
> 
> tc qdisc add dev $DEV root handle 1: htb default 4 tc class add dev $DEV parent 1: classid 1:1 htb rate 78kbps ceil 78kbps overhead 0 linklayer atm
> 
> tc class add dev $DEV parent 1:1 classid 1:2 htb rate 20kbps ceil 20kbps overhead 0 linklayer atm prio 3
> tc class add dev $DEV parent 1:1 classid 1:3 ...
> tc class add dev $DEV parent 1:1 classid 1:4 ...
>  
> tc qdisc add dev $DEV parent 1:2 handle 2: sfq quantum 64
> tc qdisc add dev $DEV parent 1:3 handle 3: sfq
> tc qdisc add dev $DEV parent 1:4 handle 4: sfq
> 
> tc filter add dev $DEV parent 1: ....
> ....
>  
> tc filter add dev $DEV parent 2: protocol ip handle 1 prio 12 flow \
> hash keys dst,proto,proto-dst divisor 128
> 
> tc filter add dev $DEV parent 3: protocol ip handle 1 prio 12 flow \
> hash keys dst,proto,proto-dst divisor 128
> 
> tc filter add dev $DEV parent 4: protocol ip handle 1 prio 12 flow \
> hash keys nfct-src,nfct-dst,proto,nfct-proto-src,nfct-proto-dst divisor 128
> 
> I'm not sure where is the bug - in the flow filter or in the sfq qdisc.
> 
> Regards
> 
> Krzysiek
> 
> 
> ----------------------------------------------------------------------
> Wymysl wierszyk, wygraj cyfrowke!
> Sprawdz >>> http://link.interia.pl/f1f5a
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New filter 'flow' bug?

[Patrick McHardy]

> From: almaop@poczta.fm
> Date: 29 Oct 2008 08:27:05 +0100
>> My configuration: gentoo, kernel 2.6.26.7 + imq patch + l7 patch, glibc 2.7, iproute2 2.6.26. Shaping is done on ethernet (e1000 card) but as I see on the ifb nothing changes.
>> There are htb 3 classes with sfq as their qdiscs. It is simple, something like:
>>
>> tc qdisc add dev $DEV root handle 1: htb default 4 tc class add dev $DEV parent 1: classid 1:1 htb rate 78kbps ceil 78kbps overhead 0 linklayer atm
>>
>> tc class add dev $DEV parent 1:1 classid 1:2 htb rate 20kbps ceil 20kbps overhead 0 linklayer atm prio 3
>> tc class add dev $DEV parent 1:1 classid 1:3 ...
>> tc class add dev $DEV parent 1:1 classid 1:4 ...
>>  
>> tc qdisc add dev $DEV parent 1:2 handle 2: sfq quantum 64
>> tc qdisc add dev $DEV parent 1:3 handle 3: sfq
>> tc qdisc add dev $DEV parent 1:4 handle 4: sfq
>>
>> tc filter add dev $DEV parent 1: ....
>> ....
>>  
>> tc filter add dev $DEV parent 2: protocol ip handle 1 prio 12 flow \
>> hash keys dst,proto,proto-dst divisor 128
>>
>> tc filter add dev $DEV parent 3: protocol ip handle 1 prio 12 flow \
>> hash keys dst,proto,proto-dst divisor 128
>>
>> tc filter add dev $DEV parent 4: protocol ip handle 1 prio 12 flow \
>> hash keys nfct-src,nfct-dst,proto,nfct-proto-src,nfct-proto-dst divisor 128
>>
>> I'm not sure where is the bug - in the flow filter or in the sfq qdisc.

Which SFQ qdisc is stalling?