On 10/12/17 11:17 AM, Jiri Pirko wrote: > So back to the example. First, we create 2 qdiscs. Both will share > block number 22. "22" is just an identification. If we don't pass any > block number, a new one will be generated by kernel: > > $ tc qdisc add dev ens7 ingress block 22 > ^^^^^^^^ > $ tc qdisc add dev ens8 ingress block 22 > ^^^^^^^^ > > Now if we list the qdiscs, we will see the block index in the output: > > $ tc qdisc > qdisc ingress ffff: dev ens7 parent ffff:fff1 block 22 > qdisc ingress ffff: dev ens8 parent ffff:fff1 block 22 > > Now we can add filter to any of qdiscs sharing the same block: > > $ tc filter add dev ens7 parent ffff: protocol ip pref 25 flower dst_ip > 192.168.0.0/16 action drop > > > We will see the same output if we list filters for ens7 and ens8, including > stats: > > $ tc -s filter show dev ens7 ingress > filter protocol ip pref 25 flower chain 0 > filter protocol ip pref 25 flower chain 0 handle 0x1 > eth_type ipv4 > dst_ip 192.168.0.0/16 > not_in_hw > action order 1: gact action drop > random type none pass val 0 > index 1 ref 1 bind 1 installed 39 sec used 2 sec > Action statistics: > Sent 3108 bytes 37 pkt (dropped 37, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > > $ tc -s filter show dev ens8 ingress > filter protocol ip pref 25 flower chain 0 > filter protocol ip pref 25 flower chain 0 handle 0x1 > eth_type ipv4 > dst_ip 192.168.0.0/16 > not_in_hw > action order 1: gact action drop > random type none pass val 0 > index 1 ref 1 bind 1 installed 40 sec used 3 sec > Action statistics: > Sent 3108 bytes 37 pkt (dropped 37, overlimits 0 requeues 0) > backlog 0b 0p requeues 0
This seems like really odd semantics to me ... a filter added to one device shows up on another. Why not make the shared block a standalone object that is configured through its own set of commands and then referenced by both devices?
