P4 syntax for a static LPM entry in a table - network-programming

Question

This is a question about the P4 language, the language for programing the data plane in networks.
Imagine I have the following simple header:
header ipv4_header_t {
bit<8> ttl;
bit<32> dst_addr;
}
struct headers_t {
ipv4_header_t ipv4_header;
}
And imagine I have a simple table that does a longest prefix match (LPM) lookup on the destination address.
table ipv4_fib {
key = {
headers.ipv4_header.dst_addr: lpm;
}
actions = {
act_miss;
act_hit;
}
const default_action = act_miss();
}
What is the P4 syntax for adding some static LPM entries to the table?
entries = {
????: act_hit(); // Want entry for 0.0.0.0/0
????: act_hit(); // Want entry for 10.0.0.0/8
????: act_hit(); // Want entry for 10.1.2.3/32
}

Answer 1

The following answer is courtesy of Vladimir Gurevich who answered the question in a conversation on the P4 slack channel (see discussion https://p4-lang.slack.com/archives/C8ZR5EN3F/p1587830767153100)
To add static entries to a longest prefix match (lpm) table, you must use the same syntax as a ternary entry, using the &&& syntax to provide a value and a mask:
table ipv4_fib {
key = {
headers.ipv4_header.dst_addr: lpm;
}
actions = {
act_miss;
act_hit;
}
const default_action = act_miss();
const entries = {
32w0x0a010203 &&& 32w0xffffffff: act_hit(1); // 10.1.2.3/32 -> 1
32w0x0a010200 &&& 32w0xffffff00: act_hit(2); // 10.1.2.0/24 -> 2
32w0x0a010000 &&& 32w0xffff0000: act_hit(3); // 10.1.0.0/16 -> 3
32w0x0a000000 &&& 32w0xff000000: act_hit(4); // 10.0.0.0/8 -> 4
}
}
A longest prefix match can be considered to be a special case of a ternary match, where the mask consists of a contiguous series of ones (1s) followed by a contiguous series of zeroes (0s).
On some (but not all) platforms a longest prefix match is actually implemented as a ternary match "under the hood".
Note 1: when you provide static entries in a table, the entries MUST be const, and hence it is no longer possible for the software to add or remove dynamic entries to or from the table. Since lpm tables are most typically used for dynamic forwarding tables, it is quite rare to see an lpm table with static entries.
Note 2: I have been told that some platforms use the order of the entries in a lpm table as the priority order for matching the entries. Thus, it is important to put the more specific entires (e.g. 10.1.0.0/16) before the less specific aggregate entries (e.g. 10.0.0.0/8). Technically, this could be considered a "bug" because in an lpm table the longest prefix match must always be preferred. This behavior is due to the fact that on some platforms an lpm table is actually implemented under the hood as a ternary table. I have also been told that the open source v1model does match the longest prefix (most specific) key, regardless of the order of the entries in the table (i.e. it does not have the "bug").
Note 3: if you try to add a default entry with an all-zeroes mask (example below) you will get an error (also given below). Use the default_action instead. There is a subtle different, though, between a default entry in the table and a default action: in the former case table.apply() will indicate result hit, and in the latter case it will indicate miss. An alternative approach is to use key _. The fact that a default entry causes an error might be considered a bug, and if so, that bug could be fixed in a later release of the P4 compiler:
const entries = {
32w0x0a010203 &&& 32w0xffffffff: act_hit(1); // 10.1.2.3/32 -> 1
32w0x0a000000 &&& 32w0xff000000: act_hit(2); // 10.0.0.0/8 -> 2
32w0x00000000 &&& 32w0x00000000: act_hit(3); // 0.0.0.0/0 -> 3
}
}
The error is:
$ p4c complex.p4
./complex.p4i(838): [--Werror=invalid] error: &&&: Invalid mask for LPM key
32w0x00000000 &&& 32w0x00000000: act_hit(3); // 0.0.0.0/0 -> 3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^