netdev - Re: Centralizing support for TCAM?

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]

Message-ID: <4e871929-b8fb-b1c9-6909-218460e21e76@mojatatu.com>
Date:   Tue, 6 Sep 2016 07:17:10 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jiri Pirko <jiri@...nulli.us>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, jiri@...lanox.com, idosh@...lanox.com,
        john.fastabend@...el.com, ast@...nel.org, davem@...emloft.net,
        ecree@...arflare.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com
Subject: Re: Centralizing support for TCAM?

On 16-09-05 11:44 PM, Alexei Starovoitov wrote:

> lol :)
> compiling bpf into fixed pipeline asic is definitely not easy.
> The problem with adding new cls classifieris and actions to match
> what configurable hw does isn't pretty either. The fixed pipeline
> isn't interesting beyond l2/l3 and flow-based hw features are mostly
> useless in the tor.

openflow cargo cult grew around those ACLs (before pragmatism
of table sizes and that there is more reality to networking
than some silly ACLs or defining everything as a table).
But that doesnt make things outside of L2/3 useless. A few
players like google are using those ASIC ACLs quiet effectively.

>I'm not against adding new classifiers, since it's
> better than sdk, but we won't be using such tc features either.

We are seeing use of those ACLs on TORs and spines (with tc). Yes, tiny
table spaces are a problem but new hardware allows for expansion
and people who use those tables are factoring in these issues.
You are not going to beat the performance numbers these things
offer. There is a lifespan of maybe 3-4 years where you are
not going to beat those numbers with s/ware without spending
more $ and space.

> Since this thread about tcam... my 0.02 here is it's pretty bad in
> the nic(host) due to power consumption and in the tor it's only good as
> a part of algorithmic lpm solutions. There it won't be even seen as tcam.
> Instead the fancy algorithms will use exact match + tcam + aux data to pack
> as many routes into such 'algorithmic lpm' as possible, so I cannot see
> what tcam as actual tcam can be good for.
>

Agreed on tcams.

cheers,
jamal