netdev - Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw

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:   Fri, 29 Jun 2018 15:05:29 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     David Ahern <dsahern@...il.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        john.hurley@...ronome.com, mlxsw@...lanox.com,
        sridhar.samudrala@...el.com
Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates
 support with offloading to mlxsw

Fri, Jun 29, 2018 at 02:54:36PM CEST, dsahern@...il.com wrote:
>On 6/29/18 6:48 AM, Jiri Pirko wrote:
>> Fri, Jun 29, 2018 at 02:12:21PM CEST, jhs@...atatu.com wrote:
>>> On 29/06/18 04:39 AM, Jiri Pirko wrote:
>>>> Fri, Jun 29, 2018 at 12:25:53AM CEST, xiyou.wangcong@...il.com wrote:
>>>>> On Thu, Jun 28, 2018 at 6:10 AM Jiri Pirko <jiri@...nulli.us> wrote:
>>>>>> Add a template of type flower allowing to insert rules matching on last
>>>>>> 2 bytes of destination mac address:
>>>>>> # tc chaintemplate add dev dummy0 ingress proto ip flower dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF
>>>>>>
>>>>>> The template is now showed in the list:
>>>>>> # tc chaintemplate show dev dummy0 ingress
>>>>>> chaintemplate flower chain 0
>>>>>>    dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff
>>>>>>    eth_type ipv4
>>>>>>
>>>>>> Add another template, this time for chain number 22:
>>>>>> # tc chaintemplate add dev dummy0 ingress proto ip chain 22 flower dst_ip 0.0.0.0/16
>>>>>> # tc chaintemplate show dev dummy0 ingress
>>>>>> chaintemplate flower chain 0
>>>>>>    dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff
>>>>>>    eth_type ipv4
>>>>>> chaintemplate flower chain 22
>>>>>>    eth_type ipv4
>>>>>>    dst_ip 0.0.0.0/16
>>>>>
>>>>> So, if I want to check the template of a chain, I have to use
>>>>> 'tc chaintemplate... chain X'.
>>>>>
>>>>> If I want to check the filters in a chain, I have to use
>>>>> 'tc filter show .... chain X'.
>>>>>
>>>>> If you introduce 'tc chain', it would just need one command:
>>>>> `tc chain show ... X` which could list its template first and
>>>>> followed by filters in this chain, something like:
>>>>>
>>>>> # tc chain show dev eth0 chain X
>>>>> template: # could be none
>>>>> ....
>>>>> filter1
>>>>> ...
>>>>> filter2
>>>>> ...
>>>>>
>>>>> Isn't it more elegant?
>>>>
>>>> Well, that is just another iproute2 command. It would use the same
>>>> kernel uapi. Filters+templates. Sure, why not. Can be easily introduced.
>>>> Let's do it in a follow-up iproute2 patch.
>>>>
>>>
>>> Half a dozen or 6 - take your pick, really.
>>> I would call the template an attribute as opposed to a stand alone
>>> object i.e A chain of filters may have a template. If you have to
>>> introduce a new object then Sridhar's suggested syntax seems appealing.
>> 
>> I think what I have makes sense. Maps nicely to what it really is inside
>> kernel. What Cong proposes looks like nice extension of userspace app to
>> do more things in one go. Will address that in followup iproute2 patch.
>
>The resolution of the syntax affect the uapi changes proposed. You are
>wanting to add new RTM commands which suggests new objects. If a
>template is an attribute of an existing object then the netlink API
>should indicate that.

There is no existing "chain" object. So no, no uapi changes.