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.
