> almaop@xxxxxxxxx wrote:
> >> almaop@xxxxxxxxx wrote:
> >>>>> From: almaop@xxxxxxxxx
> >>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
