Re: New filter 'flow' bug?

almaop@poczta.fm wrote:

quoted

quoted

almaop@poczta.fm wrote:

quoted

quoted

quoted

From: almaop@poczta.fm

quoted

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

quoted

quoted

sfq qdisc (tc qdisc add dev $DEV parent 1:2 handle 2: sfq - in my

example).

quoted

quoted

When there is no traffic in this qdisc for about 45 seconds (shorter

time

quoted

quoted

when there is no traffic at all on the interface) - it stalls. Other

qdiscs

quoted

quoted

stall also. So there is no packet flow on that interface. Removing

filters

quoted

quoted

('flow' filters) does'nt help. I have to remove (all) sfq qdiscs. And

then

quoted

quoted

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