What is the semantics of a `ternary` match on `bool` and `error` types?

[jaehyun1ee]

Two tests in p4c use a ternary match on bool and error types. However, it is unclear what its semantics should be.

The specification mentions about ternary as:

a ternary match kind on a key field means that the field in the table specifies a set of values for the key field using a value and a mask. The meaning of the (value, mask) pair is similar to the P4 mask expressions, as described in Section 8.15.3: a key field k matches the table entry when k & mask == value & mask.

Thus, a ternary match makes sense for numeric types, but I'm not sure what its semantics is for non-numeric types, and whether they should be allowed at the first place.

Below are the two tests in p4c that exhibit such use case:

• metrics/metrics_test_4.p4

struct meta_t {
        /* ... omitted ... */
        error err_field; // error code
}

control ingress(
    inout headers_t hdr,
    inout meta_t meta,
    inout standard_metadata_t standard_metadata)

    table custom_table {
        key = {
            /* ... omitted ... */
            meta.err_field : ternary;
        }
        actions = {
            set_output;
            set_headers;
            my_drop;
        }
        default_action = my_drop();
    }
}

meta.err_field has error type, matched with ternary in custom_table.

• psa-bool-ternary-const-entry-bmv2.p4

    table test_table {
        key = {
            hdr.ethernet.isValid() : ternary;
        }
        actions = {
            DummyAction;
            NoAction;
        }
        const entries = {
            (true) : DummyAction();
        }
    }

hdr.ethernet.isValid() has bool type, matched with ternary in test_table.

[jafingerhut]

Doing a ternary match against a field with type error, or any non-serializable enum type, doesn't semantically make sense from the language spec perspective, since the spec does not define any bit pattern representation for those types, explicitly and by design. It would be better if attempting to compile such a program gave an error.

For type bool, the spec does define the behavior of casts from type bool to type bit<1>, and perhaps also casting type bit<1> to bool. Thus if there is an implicit cast from type bool to bit<1> in the ternary match field hdr.ethernet.isValid() in program psa-bool-ternary-const-entry-bmv2.p4, it would be well-defined and follow the spec. I do not recall whether there is such an implicit cast in the spec for that scenario, though. Adding an explicit (bit<1>) cast to that key field would be well-defined per the current spec, for sure.

[jaehyun1ee]

Yes, I agree that a ternary match against an error type does not make semantic sense.

Also, for bool, the spec allows explicit cast from bool to bit<1> and vice-versa, but not implicitly. I've checked over both P4-SpecTec and p4c that explicitly adding a cast to bit<1> for the table key (hdr.ethernet.isValid()) works:

    table test_table {
        key = {
            ((bit<1>) hdr.ethernet.isValid()) : ternary @name("isValid");
        }
        actions = {
            DummyAction;
            NoAction;
        }
        const entries = {
            ((bit<1>) true) : DummyAction();
        }
    }

[rcgoodfellow]

LDWG discussion: recommendation is to make bools serializable. For the error issue, there should be a bug filed against P4C to not allow it. In the example case, match type can be optional.

[jaehyun1ee]

@rcgoodfellow Thank you for the summary, I've made a PR to p4-spec on bool and reported an issue to p4c on error.

[ChrisDodd]

I can conceive of a target that uses some kind of 1-hot binary representation for error codes, where a ternary match might make sense (allows match on multiple errors at once)