netdev - Re: [patch net-next v7 00/13] 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:   Thu, 11 Jan 2018 15:27:27 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jamal Hadi Salim <jhs@...atatu.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, dsahern@...il.com
Subject: Re: [patch net-next v7 00/13] net: sched: allow qdiscs to share
 filter block instances

Thu, Jan 11, 2018 at 02:19:16PM CET, jhs@...atatu.com wrote:
>On 18-01-09 09:07 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>> 
>> Currently the filters added to qdiscs are independent. So for example if you
>> have 2 netdevices and you create ingress qdisc on both and you want to add
>> identical filter rules both, you need to add them twice. This patchset
>> makes this easier and mainly saves resources allowing to share all filters
>> within a qdisc - I call it a "filter block". Also this helps to save
>> resources when we do offload to hw for example to expensive TCAM.
>> 
>> So back to the example. First, we create 2 qdiscs. Both will share
>> block number 22. "22" is just an identification:
>> $ tc qdisc add dev ens7 ingress block 22
>>                                  ^^^^^^^^
>> $ tc qdisc add dev ens8 ingress block 22
>>                                  ^^^^^^^^
>> 
>> If we don't specify "block" command line option, no shared block would
>> be created:
>> $ tc qdisc add dev ens9 ingress
>> 
>> 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
>> qdisc ingress ffff: dev ens9 parent ffff:fff1
>> 
>> 
>> 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 using the block index:
>> 
>> $ tc filter add block 22 protocol ip pref 25 flower dst_ip 192.168.0.0/16 action drop
>> 
>> 
>> Note we cannot use the qdisc for filter manipulations of shared blocks:
>> 
>> $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop
>> Error: This filter block is shared. Please use the block index to manipulate the filters.
>> 
>> 
>> We will see the same output if we list filters for ingress qdisc of
>> ens7 and ens8, also for the block 22:
>> 
>> $ tc filter show block 22
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>> 
>> $ tc filter show dev ens7 ingress
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>> 
>> $ tc filter show dev ens8 ingress
>> filter block 22 protocol ip pref 25 flower chain 0
>> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
>> ...
>> 
>
>Somewhere here mention the egress issue we talked about, something
>like:

I don't understand why to mention something that is not supported and
future thinking and work needs to be done in order to support it. Let's
leave that text for a cover letter of that patchset, could we?


>----
>At the moment on ingress and clsact_xxx are well supported by the
>block infrastructure. For this to work well with egress qdisc,
>all the ports/qdiscs sharing the block will have to be symmetric.
>e.g. if ens8 and ens9 root qdiscs shared a block at their (egress)
>root qdiscs, then those qdiscs would both need to have the same
>handle id. An example of a symettric shared block setup would like like:
>
>tc qdisc add dev ens8 root block 22 handle 1:0 prio
>tc qdisc add dev ens9 root block 22 handle 1:0 prio
>----
>
>I am confident the above would work. You said you are thinking of
>getting this to always work (I cant think of a simple way to do it),
>but for the moment the above is fine.
>Most people who want this would probably use clsact egress and not
>care about queues (so it may never be "fixed")
>
>cheers,
>jamal