lpm literally is an abbreviation for “longest prefix match”.

If you want the match behavior to include the length of the prefix as the criteria for determining the “winner” among multiple matching entries, then I personally do not see how that makes any sense at all if you allow a table with one lpm key field, and another key field that is any of lpm, ternary, or range. How would you define which entry should “win” among multiple possible matching entries? I have never seen anyone propose such a rule.

If you have such a proposed rule, then great, propose one and we can discuss it. If not, then let us NOT discuss a table with one lpm key field, and another key field that is any of lpm, ternary, range, or optional. That leaves you with the restriction that if one key field is lpm, then either there are no other key fields at all, or all others have exact match kinds, and I have described in my comment above how that makes perfectly good sense (to me, at least), in how you can define it.

If you have key fields where some are ternary, some are range, some are optional, and some are exact (but none of them are lpm), then the rule for whether a lookup key matches an entry installed by the control plane is that the condition for each field of the lookup key must match the ternary, optional, range or exact condition installed by the control plane for that one field, and that must be true for all lookup key fields, not only some of them. That determines whether the lookup key matches one installed entry.

Now conceptually imagine that you determine for each lookup key, the complete set of all installed entries that match that lookup key. There might be 0, 1, or more than one of them. If 0, then the lookup is a miss. If more than one, then every entry must have a numeric priority installed with it when the control plane added the entry, and that priority determines which of the multiple matching entries is the winner, and only the winning entry’s action is executed.

There is usually more than one way to implement any given idea, but one way to implement range matches is also to use a TCAM. If the range happens to be a “power of 2 aligned range”, i.e. it looks like [A x 2^B, (A+1) x 2^B - 1] for some integers A and B, then that range can be implemented with one TCAM value/mask, that will be a prefix mask, i.e. a mask that is exact match on some number of the most significant bits, and wildcard on the least significant bits.

For a range that is not “power of 2 aligned”, you can always break it up into multiple ranges that are “power of 2 aligned”, e.g. the range [0, 5] is [0, 3] plus [4, 5], and each of those smaller ranges is power of 2 aligned.

Suppose that you had a P4 table with field f1 that was range match kind, and field f2 was ternary match kind. If the control plane added a rule where f1 was range [0, 5], and field f2 was value V with mask M, then a system that used power-of-2-aligned TCAM entries to implement the range match kind would install 2 TCAM entries for this control plane rule:

(1) f1 has the value/mask that matches range [0,3], f2 has value/mask V, M

(2) f1 has the value/mask that matches range [4,5], f2 has value/mask V, M

Any lookup key that matches the original control plane rule must match exactly one of those two TCAM entries.

For a single field that was match kind range, implemented in this way, the number of TCAM entries required depends upon the precise range you want to match, but it turns out that for a W-bit field, the maximum number of TCAM entries required is 2*W-2.

There can be a scaling issue with this, however, if you have 2 or more fields that are both match kind range: you have to do this breaking up into power-of-2-aligned ranges for all of the fields, and then install as many TCAM entries as are in the “cross product” of each field by itself.

For example, suppose field f1 and f2 are both match kind range, and the control plane installs a rule where the range for field f1, by itself, requires 7 power-of-2-aligned ranges to represent it with TCAM value/masks, and field f2, by itself, requires 10 power-of-2-aligned ranges to represent it with TCAM value/masks. Then adding that one rule from the control plane would require 7*10 TCAM entries to represent all possible pairs of value/masks for field f1 and f2.

I mentioned above that there is usually more than one way to solve problems. There are specially designed hardware TCAMs that can support [min, max] ranges directly in the hardware. These are typically more expensive and custom than a regular TCAM hardware design. Basically inside of the TCAM logic for each entry, you can mark specific sets of bits as part of a range field, and instead of configuring a (value,mask) for those bits and the hardware does the calculation (lookup_key & mask) == value when the TCAM is searched, instead it does the calculation (min_value <= lookup_key) && (lookup_key <= max_value). Such special TCAM designs typically can do that for more than one field, but it requires that the hardware designer took into account this desire, and added extra logic gates into every single TCAM entry that could implement it. So it is a bigger TCAM design for the same number of entries, and thus more expensive than a “vanilla” TCAM that can only do value/mask matches.