Hello Eduardo,
First of all, welcome to the forum!
Let me first answer a general question that you seem to be asking, specifically how to think about the TCAM tables in general and how to interpret the numbers the vendors might be quoting.
First of all, it is important to understand that the match-action table entries generally consist of 3 sections:
- The key (what we match on)
- The action (e.g. a pointer or some other indicator to the code that needs to be executed if an entry is hit)
- The action data (optional data that the action code can use as additional operands)
When TCAM is used to implement a match-action table, typically out of these 3 parts only the key is stored in the TCAM, whereas the other two portions (action and the action data) are typically stored in SRAM, DRAM or other traditional memory. The reason is that TCAM is very expensive and there is no advantage using it to store anything but the key. Also, it is usually slower to program, does not support error correction, etc.
Thus, even though you identified that your example table has a 32-bit-wide key that consists of a 32-bit-wide value and a 32-bit-wide mask that need to go into the TCAM, the 8-bit port value (and probably some extra bits for the action, etc.) should not.
Speaking of the extra bits, many table technologies (including a TCAM) require at least one extra bit to indicate the entry validity. How many bits are required by a specific implementation depends on the vendor.
How, let’s talk about how to interpret the numbers that you can see in the vendor’s datasheets, e.g. that some device has N bits of TCAM. While it is true that to match on 1 bit of information you need to store 2 bits (one the value and one the mask), all vendors I’ve seen so far do not play this game. In other words, when they claim to have N bits of TCAM, they mean that they can match on N bits of information. That means that they have space to store N bits of the value and N bits of the mask. Sometimes, people use the word “trit” (a ternary value) to make things clearer. A trit is an abstract representation of a ternary value (0, 1, don’t care) regardless of representation. You can safely state that most vendors who provide their TCAM capacity in bits actually mean trits 
The last thing you have in mind, I believe is a “simple” procedure (e.g. division) where you can take the given TCAM capacity (in trits), the table declaration and make a determination about the potential number of entries that can be stored there. This is, unfortunately, where things become vendor-specific and not suitable for this forum. Speaking of Tofno, I can say the following:
- There is a post on this forum (you might’ve already found it if you used the search function) that points you to the proper resources
- Intel provides a special tool (you can see a quick public demo here) that allows its customers to see the resources, consumed by the tables and other P4 objects on Tofino
Last, but not least, keep in mind that LPM match can be implemented in a variety of other ways that do not use TCAMs (or use it just a little). In this case, everything we just discussed becomes totally irrelevant.
Happy hacking,
Vladimir