netdev - Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 6 Jan 2018 13:02:57 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jiri Pirko <jiri@...nulli.us>, David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        xiyou.wangcong@...il.com, mlxsw@...lanox.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, matanb@...lanox.com, leonro@...lanox.com,
        idosch@...lanox.com, jakub.kicinski@...ronome.com,
        simon.horman@...ronome.com, pieter.jansenvanvuuren@...ronome.com,
        john.hurley@...ronome.com, alexander.h.duyck@...el.com,
        ogerlitz@...lanox.com, john.fastabend@...il.com,
        daniel@...earbox.net
Subject: Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share
 filter block instances

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