linux-kernel - Re: [PATCH net-next v3 1/2] net: mscc: ocelot: Add 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]

Date:   Sat, 26 Sep 2020 15:37:16 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc:     Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>, linux-mips@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>, hongbo.wang@....com
Subject: Re: [PATCH net-next v3 1/2] net: mscc: ocelot: Add support for tcam

Hi Horatiu,

On Sat, Sep 26, 2020 at 01:20:02PM +0200, Horatiu Vultur wrote:
> To be honest, I don't remember precisely. I will need to setup a board
> and see exactly. But from what I remember:
> - according to this[1] in chapter 3.8.6, table 71. It says that the full
>   entry of IS2 is 384. And this 384 represent a full entry. In this row,
>   can be also sub entries like: half entry and quater entries. And each
>   entry has 2 bits that describes the entry type. So if you have 2 bits
>   for each possible entry then you have 8 bits describing each type. One
>   observation is even if you have a full entry each pair of 2 bits
>   describing the type needs to be set that is a full entry.

But if I have a single entry per row, I have a single Type-Group value,
so I only need to subtract 2, no?

>   Maybe if you have a look at Figure 30, it would be a little bit more
>   clear. Even there is a register called VCAP_TG_DAT that information
>   is storred internally in the VCAP_ENTRY_DAT.

See, this is what I don't understand. You're saying that the Type-Group
is stored as part of the entry inside the TCAM, even if you're accessing
it through a different set of cache registers? What else is stored in a
TCAM row sub-word? The key + mask + Type-Group are stored in the same
sub-word, I assume?

> - so having those in mind, then VCAP_IS2_ENTRY_WIDTH is the full entry
>   length - 8 bits. 384 - 8 = 376.

But there are 4 Type-Group (and therefore 4 entries per row) only if the
entries are for quarter keys, am I not correct? And the IS2 code
currently uses half keys. Does this variable need to be set differently
according to the key size?

> - then if I remember correctly then VCAP_CONST_ENTRY_WIDTH should be
>   384? or 12 if it is counting the words.

Yes, it is 384 and the VCAP core version is 0.

> Does it make sense or am I completly off?

So, in simple words, what is the physical significance of
(VCAP_CONST_ENTRY_WIDTH - VCAP_CONST_ENTRY_TG_WIDTH * VCAP_CONST_ENTRY_SWCNT)?
To my understanding, it means the size used by all key+mask entries
within a TCAM row (therefore without the length of Type-Group fields)
when that row contains 4 quarter keys. Divide this number by 2, you get
the length of the key, or the length of the mask, for a single sub-word,
BUT only assuming that quarter keys are used.
So, why does this value have any significance to a driver that is not
using quarter keys?

Am _I_ completely off? This is so confusing.

Thanks,
-Vladimir