Wed, Dec 13, 2017 at 05:54:35PM CET, dsah...@gmail.com wrote: >On 12/13/17 8:10 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 >> >> To make is more visual, the situation looks like this: >> >> ens7 ingress qdisc ens7 ingress qdisc >> | | >> | | >> +----------> block 22 <----------+ >> >> Unlimited number of qdiscs may share the same block. >> >> Now we can add filter to any of qdiscs sharing the same block: >> >> $ tc filter add dev ens7 ingress protocol ip pref 25 flower dst_ip >> 192.168.0.0/16 action drop > >I still say this is very odd user semantic - making changes to device M >and the changes magically affect device N. Operating on the shared block >as a separate object makes it is much more direct and clear.
I plan to do it as a follow-up patch. But this is how things are done now and have to continue to work. Also changes done on dev block X for dev A has to appear in block X for dev B. Block X is share between A and B.
