"Zero priority for ternary match" error when inserting exact entries into tables with optional keys.

[fruffy]

Trying to run a PTF test on the attached program fails with the message

Zero priority for ternary match

This is the table:

    table acl_ingress_table {
        key = {
            h.ethernet.dst_addr                       : exact @name("dst_mac");
            h.ipv4.src_addr                           : exact @name("src_ip");
            h.ipv4.dst_addr                           : exact @name("dst_ip");
            h.ipv4.ttl                                : optional @name("ttl");
            h.ipv4.dscp                               : optional @name("dscp");
            h.ipv4.ecn                                : optional @name("ecn");
            h.ipv4.protocol                           : optional @name("ip_protocol");
        }
        actions = {
            acl_drop(s);
            @defaultonly NoAction;
        }
        const default_action = NoAction;
    }

The PTF test omits the optional keys as they are, well, optional. However, the P4Runtime server still seems to expect some entry. Since any entry on tables with optional keys needs a priority but no priority is provided the response is an error. Is this behavior intended? Is it always required to supply a priority even though no optional key is present?

bmv2_table_opt.p4.txt

bmv2_table_opt.json.txt
bmv2_table_opt.p4info.txt
bmv2_table_opt.py.txt
ptf.log
switchlog.txt

[jafingerhut]

The P4Runtime API should require a priority value for any entries added to a table that has at least one field with match_kind ternary, range, or optional.

If the optional match_kind field should be a "match any value" in the entry, then the P4Runtime API spec says that the field should not be included in the TableEntry message, but the priority value must, as should any other key fields that are not completely wild-card in their match criteria.

[jafingerhut]

Rationale for why the priority value must be included, in case it is not already obvious: If there are multiple table entries added, more than one of them could match the same lookup key. The data plane needs a way to determine which rule should win and have its action executed.

[fruffy]

Thanks for clarifying!