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  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 20:55:36 +0200
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     Vladimir Oltean <olteanv@...il.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

The 09/26/2020 15:37, Vladimir Oltean wrote:
> 
> Hi Horatiu,

Hi Vladimir,

> 
> 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?

No, you will always have 4 Type-Group values regardless of number of
entries per row(1, 2 or 4). If you have a full key, then you need to set
all 4 Type-Group to be full key. If you have only a half key, you need
to set only the 2 Type-Group values of the half key. So the other 2 can
be used for another key. The same is for quater key.
For example. If you have a quater key on column 0 and one on column 3,
then the type group will have the valux 0bXX0000XX. (I forgot what is
the Type-Group for quater keys).
If you have a full key, then you need to replicate the value of type
group for full key for all 4 type-groups in the row. So if type group
for full entry is 0x1, then type group will look like this: 0b01010101.

> 
> >   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?

I am not sure how is store the mask. But regarding the key and the type
group you can see it like this.

| subword 3 | TG 3 | subwork 2 | TG 2 | subword 1 | TG 1 | subword 0 | TG 0 |

Where subwork is 96 bits and TG is 2 bits.
So when you access VCAP_ENTRY_DAT you access only the subwords, when you
access VCAP_TG_DAT you access TG. When you set the VCAP_ENTRY_DAT you
don't need to take in consideration that after 96 bits you start to
shift everything to left by 2. The internal implementation does that.
And that is the reason why the VCAP_CONST_ENTRY_WIDTH is 384 and
VCAP_IS2_ENTRY_WIDTH is 376.

> 
> > - 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?

I think what I wrote above answer these questions.

> 
> > - 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.

Well, I still remember it :)
> 
> > 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)?

I am not sure that I understand what you want to achive with this or
something is still wrong.

> 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.

I hope the first part explain a little bit better this. Maybe we should
ignore the internal representation and try to see it like this. Each
quater key has a type-group, then a full key is composed of 4 quater
keys therefore it has 4 type-groups. In case of a full key then all 4
type-groups in VCAP_TG_DAT needs to have the same value. In case of quater
key you need to set only the bits in VCAP_TG_DAT of the column where is
the quater key. In case of half entry then only first or last 4 bits in
VCAP_TG_DAT needs to be set.

> 
> Thanks,
> -Vladimir

-- 
/Horatiu

Powered by blists - more mailing lists