On 20/05/2019 16:38, Jamal Hadi Salim wrote: > That is fine then if i could do: > > tc actions add action drop index 104 > then > followed by for example the two filters you show below.. That seems to work.
> Is your hardware not using explicit indices into a stats table? No; we ask the HW to allocate a counter and it returns us a counter ID (which bears no relation to the action index). So I have an rhashtable keyed on the cookie (or on the action-type & action_index, when using the other version of my patches) which stores the HW counter ID; and the entry in that hashtable is what I attach to the driver's action struct. > Beauty. Assuming the stats are being synced to the kernel? > Test 1: > What does "tc -s actions ls action drop index 104" show? It produces no output, but `tc -s actions get action drop index 104` or `tc -s actions list action gact index 104` shows the same stats as `tc -s filter show ...` did for that action. > Test 2: > Delete one of the filters above then dump actions again as above. Ok, that's weird: after I delete one, the other (in `tc -s filter show ...`) no longer shows the shared action. # tc filter del dev $vfrep parent ffff: pref 49151 # tc -stats filter show dev $vfrep parent ffff: filter protocol arp pref 49152 flower chain 0 filter protocol arp pref 49152 flower chain 0 handle 0x1 eth_type arp skip_sw in_hw in_hw_count 1 action order 1: vlan push id 100 protocol 802.1Q priority 0 pipe index 1 ref 1 bind 1 installed 180 sec used 180 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 action order 2: mirred (Egress Mirror to device $pf) pipe index 101 ref 1 bind 1 installed 180 sec used 169 sec Action statistics: Sent 256 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Sent software 0 bytes 0 pkt Sent hardware 256 bytes 4 pkt backlog 0b 0p requeues 0 action order 3: vlan pop pipe index 2 ref 1 bind 1 installed 180 sec used 180 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 # Yet `tc -s actions get` still shows it... # tc -s actions get action drop index 104 total acts 0 action order 1: gact action drop random type none pass val 0 index 104 ref 2 bind 1 installed 812 sec used 797 sec Action statistics: Sent 534 bytes 7 pkt (dropped 7, overlimits 0 requeues 0) Sent software 0 bytes 0 pkt Sent hardware 534 bytes 7 pkt backlog 0b 0p requeues 0 # tc filter show dev $vfrep parent ffff: filter protocol arp pref 49152 flower chain 0 filter protocol arp pref 49152 flower chain 0 handle 0x1 eth_type arp skip_sw in_hw in_hw_count 1 action order 1: vlan push id 100 protocol 802.1Q priority 0 pipe index 1 ref 1 bind 1 action order 3: vlan pop pipe index 2 ref 1 bind 1 # tc -s actions get action mirred index 101 total acts 0 action order 1: mirred (Egress Mirror to device $pf) pipe index 101 ref 1 bind 1 installed 796 sec used 785 sec Action statistics: Sent 256 bytes 4 pkt (dropped 0, overlimits 0 requeues 0) Sent software 0 bytes 0 pkt Sent hardware 256 bytes 4 pkt backlog 0b 0p requeues 0 # Curiouser and curiouser... it seems that after I delete one of the rules, TC starts to get very confused and actions start disappearing from rule dumps. Yet those actions still exist according to `tc actions list`. I don't *think* my changes can have caused this, but I'll try a test on a vanilla kernel just to make sure the same thing happens there. -Ed
