From: Vladimir Oltean <olteanv@gmail.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
linux-mips@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
"Allan W. Nielsen" <allan.nielsen@microchip.com>,
Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
hongbo.wang@nxp.com
Subject: Re: [PATCH net-next v3 1/2] net: mscc: ocelot: Add support for tcam
Date: Sat, 26 Sep 2020 15:37:16 +0300 [thread overview]
Message-ID: <20200926123716.5n7mvvn4tmj2sdol@skbuf> (raw)
In-Reply-To: <20200926112002.i6zpwi26ong2hu4q@soft-dev3.localdomain>
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
next prev parent reply other threads:[~2020-09-26 12:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 7:16 [PATCH net-next v3 0/2] Add hw offload of TC flower on MSCC Ocelot Horatiu Vultur
2019-05-31 7:16 ` [PATCH net-next v3 1/2] net: mscc: ocelot: Add support for tcam Horatiu Vultur
2020-02-24 10:38 ` Vladimir Oltean
2020-02-24 11:03 ` Horatiu Vultur
2020-02-24 11:32 ` Vladimir Oltean
2020-04-22 21:26 ` Vladimir Oltean
2020-04-23 8:29 ` Horatiu Vultur
2020-04-23 9:18 ` Vladimir Oltean
2020-09-24 23:39 ` Vladimir Oltean
2020-09-26 11:20 ` Horatiu Vultur
2020-09-26 12:37 ` Vladimir Oltean [this message]
2020-09-26 18:55 ` Horatiu Vultur
2020-09-26 19:06 ` Vladimir Oltean
2019-05-31 7:16 ` [PATCH net-next v3 2/2] net: mscc: ocelot: Hardware ofload for tc flower filter Horatiu Vultur
2019-06-02 20:50 ` [PATCH net-next v3 0/2] Add hw offload of TC flower on MSCC Ocelot David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200926123716.5n7mvvn4tmj2sdol@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=allan.nielsen@microchip.com \
--cc=hongbo.wang@nxp.com \
--cc=horatiu.vultur@microchip.com \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.org \
--cc=xiaoliang.yang_1@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).