How to handle QoS（traffic control） based on physical interface of virtual bridge？

I have a requirement to limit the traffic rate based on different interfaces of the router, such as controlling the upload speed of ssid1 to 10mbps, download speed to 20mbps, lan1 upload speed to 30mbps, download speed to 50mbps... The upstream interface is eth1, and all downstream interfaces are abstracted into virtual bridge br-lan (including ssid1, ssid2, lan1...).

Now I'm trying to use the tc tool to limit the traffic rate, using the physdev module of iptables to mark the traffic from different physical interfaces, and using the marked value to limit the upload speed of a physical interface in the qdisc of eth1.

The current condition of the network bridge is as follows(eth0.2 corresponds to lan1):

root@cpe:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.00001228802a       no              eth0.2
                                                        usbnet0
                                                        wlan0

My configuration codes are as follows:

sysctl -w net.bridge.bridge-nf-call-iptables=1

tc qdisc add dev eth1 root handle 1:0 htb default 1
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 100Mbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit
tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 666 fw classid 1:10

iptables -t mangle -N HAHA
iptables -t mangle -I PREROUTING -m physdev --physdev-in eth0.2 -j HAHA
iptables -t mangle -A HAHA -s 0.0.0.0/0 -j MARK --set-mark 666

root@cpe:~# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 140 packets, 12806 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  100 10152 HAHA       all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in eth0.2

Chain HAHA (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 100 10152 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            MARK set 0x29a

eth0.2    Link encap:Ethernet  HWaddr 00:55:80:5C:34:76  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:125556 errors:0 dropped:0 overruns:0 frame:0
          TX packets:119526 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:98887328 (94.3 MiB)  TX bytes:114959454 (109.6 MiB)

It looks like the iptables rules have matched and marked the packets, but the number of matches is very small (compared to the packets produced in my tests). Whether or not my tc rule for speed limiting is wrong, iptables shouldn't match so few packets in theory, and I don't know why.

Today I try to mark packages with ebtables，but it still doesn't work.

eth0.2    Link encap:Ethernet  HWaddr 00:22:96:F5:AB:7C  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59511 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66029 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34341259 (32.7 MiB)  TX bytes:76007190 (72.4 MiB)

root@cpe:~# ebtables -L --Lc
Bridge table: filter
Bridge chain: INPUT, entries: 1, policy: ACCEPT
-i eth0.2 -j mark --mark-set 0x8 --mark-target CONTINUE, pcnt = 450 -- bcnt = 24918

ebtables -t filter -A INPUT -i eth0.2 -j mark --mark-set 8 --mark-target CONTINUE

What is the reason for the small number of packets that iptables matches? What can I do to fix this problem? Or are there better ways to do QoS based on physical interface of virtual bridge？

Alright，I have got the reason. It doesn't work because I haven't closed bypass_fastpath.after I input command or remove mfp.ko as following，it works.

echo 1 > /sys/kernel/fastpath/fp_forward/bypass_fastpath

#or

rm /lib/modules/3.10.33/mfp.ko