On Wed, 2007-04-04 at 16:50 +0200, Patrick McHardy wrote:
> Anyway, we can't return NET_XMIT_SUCCESS, so how about just returning
> NET_XMIT_BYPASS in all cases where the packet was stolen/dropped/...
> by TC actions?
Ok, I think i get you now. Yes, that would work, but:
for the dropped case, you
jamal wrote:
> On Wed, 2007-04-04 at 16:13 +0200, Patrick McHardy wrote:
>
>>This seems to be due to be caused by act_mirred returning TC_ACT_STOLEN,
>>which is translated to NET_XMIT_SUCCESS within prio, causing HTB to
>>increase the q.qlen counter and activating the class despite no packet
>>bee
On Wed, 2007-04-04 at 16:13 +0200, Patrick McHardy wrote:
> This seems to be due to be caused by act_mirred returning TC_ACT_STOLEN,
> which is translated to NET_XMIT_SUCCESS within prio, causing HTB to
> increase the q.qlen counter and activating the class despite no packet
> beeing queued.
>
>
Denys wrote:
> I have some interesting thing:
>
> Rules:
> tc qdisc del dev eth0.5 root
> tc qdisc add dev eth0.5 handle 1: root htb
> tc class add dev eth0.5 parent 1:0 classid 1:2 htb rate 128Kbit
>
> tc qdisc add dev eth0.5 parent 1:2 handle 2: prio
>
> tc filter add dev eth0.5 parent 1: prot
