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:   Thu, 28 Jun 2018 16:17:18 +0200
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, jakub.kicinski@...ronome.com,
        simon.horman@...ronome.com, john.hurley@...ronome.com,
        dsahern@...il.com, mlxsw@...lanox.com
Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates
 support with offloading to mlxsw

Thu, Jun 28, 2018 at 03:54:17PM CEST, jhs@...atatu.com wrote:
>On 28/06/18 09:22 AM, Jiri Pirko wrote:
>> Thu, Jun 28, 2018 at 03:13:30PM CEST, jhs@...atatu.com wrote:
>> > 
>> > On 26/06/18 03:59 AM, Jiri Pirko wrote:
>> > > From: Jiri Pirko <jiri@...lanox.com>
>> > > 
>> > > For the TC clsact offload these days, some of HW drivers need
>> > > to hold a magic ball. The reason is, with the first inserted rule inside
>> > > HW they need to guess what fields will be used for the matching. If
>> > > later on this guess proves to be wrong and user adds a filter with a
>> > > different field to match, there's a problem. Mlxsw resolves it now with
>> > > couple of patterns. Those try to cover as many match fields as possible.
>> > > This aproach is far from optimal, both performance-wise and scale-wise.
>> > > Also, there is a combination of filters that in certain order won't
>> > > succeed.
>> > > 
>> > > 
>> > > Most of the time, when user inserts filters in chain, he knows right away
>> > > how the filters are going to look like - what type and option will they
>> > > have. For example, he knows that he will only insert filters of type
>> > > flower matching destination IP address. He can specify a template that
>> > > would cover all the filters in the chain.
>> > > 
>> > 
>> > Is this just restricted to hardware offload? Example it will make sense
>> > for u32 in s/ware as well (i.e flexible TCAM like TCAM based
>> > classification). i.e it is possible that rules the user enters
>> > end up being worst case a linked list lookup, yes? And allocating
>> > space for a tuple that is not in use is a waste of space.
>> 
>> I'm afraid I don't understand clearly what you say.
>
>Well - I was trying to understand what you said ;->
>
>I think what you are getting at is two issues:
>a) space in the tcams - if the user is just going to enter
>rules which use one tuple (dst ip for example) the hardware
>would be better off told that this is the case so it doesnt
>allocate space in anticipation that someone is going to
>specify src ip later on.

Yes.

>b) lookup speed in tcams - without the template hint a
>selection of rules may end up looking like a linked list
>which is not optimal for lookup

Well. Not really, but wider keys have bigger overheads in general. So
the motivation is to have the keys as small as possible for both
performance and capacity reasons.

>
>> This is not
>> restricted to hw offload. The templates apply to all filters, no matter
>> if they are offloaded or not.
>> 
>
>Do you save anything with flower(in s/w) if you only added a template
>with say dst ip/mask? I can see it will make sense for u32 which is more
>flexible and protocol independent.

No benefit for flower s/w path at this point. Perhaps the hashtables
could be organized in more optimal way with the hint. I didn't look at
it.

>
>cheers,
>jamal