Fri, Oct 13, 2017 at 04:20:38PM CEST, dsah...@gmail.com wrote: >On 10/13/17 12:26 AM, Jiri Pirko wrote: >> Thu, Oct 12, 2017 at 11:37:30PM CEST, dsah...@gmail.com wrote: >>> 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 is it odd? They share the same block, so it is natural that rule >> added to one shows in list of rules for all devices that share the same >> block. >> >> >>> >>> Why not make the shared block a standalone object that is configured >>> through its own set of commands and then referenced by both devices? >> >> I was thinking about that for a long time. That would require entirely >> new set of netlink api and internal kernel handling just for this. Lots >> of duplications. The reason is, the current API is strictly build around >> ifindex. But the new API would not solve anything. As a user, I still >> want so see shared rules in individial device listing, because they >> would get processed for the device. So I believe that the proposed >> behaviour is correct. >> > >netconf has NETCONFA_IFINDEX_ALL to keep the device concept but to relay >information that applies to more than 1 device. You could have something >similar for tc and shared blocks. Admin is done on this device index >(e.g., your shared block 22 becomes dev index -22) and the filters are >attached to another device for sharing using the 'qdisc add' command above.
It can be extended like this I guess. But still, the original rule adding has to work.
