On 18-01-06 04:48 AM, Jiri Pirko wrote: [..]
Or, do you think it should work like: $ tc qdisc add dev ens8 ingress $ tc qdisc qdisc ingress ffff: dev ens8 parent ffff:fff1
>
$ tc qdisc add dev ens7 ingress block 22
>
$ tc qdisc qdisc ingress ffff: dev ens7 parent ffff:fff1 block 22 qdisc ingress ffff: dev ens8 parent ffff:fff1 And the only shareable block is the one which I spefify block index for? And for that, I have to always use block index handle for filter add/del/get?
This is more explicit and better IMO (assuming syntax for sharing is as shown earlier - adding via ens7 is going to be rejected). Another thing to consider: ens8 to join in the sharing i.e something like: tc qdisc change/replace dev ens8 ingress block 22 And this to replace the local block created earlier (with any old filters destroyed in the process). BTW: From your output, DavidA, i noticed something strange: two flower filters with the same handle id 0x1 (different prios) and also two filters with the same prio (but different handles). I see one was added using :dev .." - how were the other 2 added? Consequence of patch, maybe? Note: Expected behavior is two filters of same kind on the same chain should be distinguished by priority. There are filters like u32 (which hide hash tables under the same priority) which may allow the same prio for multiple handles - just dont see that fit with flower, but maybe missing something. cheers, jamal
