p4-spec
p4-spec copied to clipboard
Modular match fields for tables.
For P4 LDWG, I promised I'd produce a toy example to illustrate this need, but I found a real example of ours from a year or so ago was open-sourced (though it looks much worse now).
Some possible thoughts on how I might like it to look:
- Literally make tables modifiable within their control block and allow something like 'AddAction' and 'AddKey':
table acl_ingress_table {
key = {
*All the shared keys*
}
actions = {
*All the shared actions*
}
}
if ([some_metadata_saying_that_this_is_a_middleblock] == true) {
acl_ingress_table.AddKey(
headers.arp.target_proto_addr : ternary @name("arp_tpa") @id(16)
@composite_field(
@sai_udf(base=SAI_UDF_BASE_L3, offset=24, length=2),
@sai_udf(base=SAI_UDF_BASE_L3, offset=26, length=2)
) @format(IPV4_ADDRESS);
)
}
...
- Make tables themselves parameterizable on variables with different types. I think we'd want something like
bit<0>
to effectively act as a non-match key in this world:
table acl_ingress_table(my_icmp_key) {
key = {
*All the shared keys*
my_icmp_type : ternary @name("icmp_type") @id(19)
@sai_field(SAI_ACL_TABLE_ATTR_FIELD_ICMP_TYPE);
...
}
}
bit<0> dummy_match_key;
if ([some_metadata_saying_that_this_is_a_middleblock] == true) {
acl_ingress_table.apply(dummy_match_key);
} else {
acl_ingress_table.apply(headers.icmp.type);
}
...
- Make the control parameterizable on variables with different types and add the same
bit<0>
behavior as above. I'm actually not sure where this would fail today:
control acl_ingress(in my_icmp_key, ...) {
table acl_ingress_table {
key = {
*All the shared keys*
my_icmp_type : ternary @name("icmp_type") @id(19)
@sai_field(SAI_ACL_TABLE_ATTR_FIELD_ICMP_TYPE);
...
}
}
}
control middleblock_ingress(...) {
bit<0> dummy_match_key;
apply {
...
acl_ingress.apply(dummy_match_key, ...);
}
}
control fbr_ingress(...) {
apply {
...
acl_ingress.apply(headers.icmp.type, ...);
}
}