How do I calculate memory consumption for an IPv4 entry in TCAM?

Hi folks,

Firstly, I apologize if this is not the right place for this kind of question.

I’ve been struggling lately to understand how to calculate the memory consumption of TCAM entries in a programmable ASIC (e.g., Tofino ASIC). For example, do I need to consider both mask and value bits to calculate the memory consumption of an IPv4 prefix using TCAM memory? In other words, if we simplify and consider an IPv4 prefix with its basic components (e.g., 32 bits for the destination IP, 32 bits for the mask, and 8 bits for the output port), is it correct to say that such a prefix requires 72 bits? If so, in a 50 MB TCAM, we can store approximately 5.5 million IPv4 prefixes (50 MB / 72 bits), right? I know there is some other information that needs to be included in the calculation, such as the action data. But, in summary, I would like to know if the TCAM memory in a given ASIC (e.g., 50 MB of TCAM) includes the space necessary to store the masks or if the space for storing masks is not taken into account in the total amount of memory available.

Thanks in advance.

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:

  1. The key (what we match on)
  2. The action (e.g. a pointer or some other indicator to the code that needs to be executed if an entry is hit)
  3. 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 :slight_smile:

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:

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

1 Like

Thank you so much Vladimir.