p4 spec v1.1 (1185620), страница 12
Текст из файла (страница 12)
The valuespassed to that API would then be set in the table entry being added so that they couldbe passed to this action for packets that hit that entry.action route_ipv4(in bit<48> dst_mac,in bit<48> src_mac,in bit<16> vid) {modify_field(ethernet.dst_addr, dst_mac);modify_field(ethernet.src_addr, src_mac);modify_field(vlan_tag.vid, vid);modify_field(ipv4.ttl, ipv4.ttl-1);}10.2.1 Sequential Execution SemanticsActions across different tables are assumed to execute sequentially, where the sequenceis determined by the control flow, described in Section 13.
As an example, consider thecode fragment given below, repeated from Section 13.control main {apply(check_mtag);apply(identify_port);}Here, the check_mtag table and its associated actions are applied first, followed by theidentify_port table and its actions.The body of a compound action is also assumed to execute sequentially – i.e. thefirst primitive action executes to completion, and then the second executes to completion.
Concretely, consider the two primitive actions modify_field(hdr.fieldA, 1)and modify_field(hdr.fieldB, hdr.fieldA) appearing within the compound actioncompound as shown below.6711 ACTION PROFILE DECLARATIONSaction compound1() {modify_field(hdr.fieldA, 1);modify_field(hdr.fieldB, hdr.fieldA);}Let’s say hdr.fieldA started with a value of 0. The first statement is completed first,leaving 1 in fieldA. Then, the second instruction is executed, propagating 1 to fieldB.While the language permits arbitrarily-long dependency chain of primitive actions withina compound action, each target can choose to impose its own restrictions for performance.
For instance, a target might introduce a limit to the maximum length of a dependency chain it supports. In such cases, the target compiler must infer dependenciesbetween primitive actions and reject compound actions that strictly require primitiveactions to be sequenced one after another longer than the target’s limit.As an example, action compound1 above might be rejected by a target compiler on thegrounds that there is no capability to write a header field (fieldA) and then read it intoanother header field within the same table. At the same time, the compiler could acceptthe action below (action compound2) because there is no dependency between the twoprimitive actions and both can execute in parallel.action compound2() {modify_field(hdr.fieldX, hdr.fieldY);modify_field(hdr.fieldB, hdr.fieldC);}The compiler may also choose to rewrite code while preserving correctness to removespurious dependencies.
For instance, the code in action compound1 is equivalent to thecode in action compound3 below, which has no dependencies between primitive actionsand hence can be run on a constrained target.action compound3() {modify_field(hdr.fieldA, 1);modify_field(hdr.fieldB, 1);}11Action profile declarationsIn some instances, action parameter values are not specific to a match entry but couldbe shared between different entries.
Some tables might even want to share the same set6811 ACTION PROFILE DECLARATIONSof action parameter values. This can be expressed in P4 with action profiles. Action profiles are declarative structures specifying a list of potential actions, and possibly otherattributes.Entries are inserted at run time to specify the single action to be run if that entry ischosen - among the candidates included in the action profile declaration-, as well asthe action parameter values to use.Instead of statically binding one particular action profile entry to each match entry,one might want to associate multiple action profile entries with a match entry and letthe system (i.e., data plane logic) dynamically bind one of the action profile entries toeach class of packets. The dynamic_action_selection attribute enables such behavior.
When dynamic_action_selection is specified, action profile entries can be bundled into groups by the run time, and a match entry can then tied to a group of actionprofile entries. To dictate a specific data-plane mechanism that chooses a particular action profile entry in a group, one should provide an action selector. An action selectorchooses a particular action profile entry for each packet by either pseudo-randomly orpredictably deriving a decision from header fields and/or metadata.Here is the BNF for an action profile declaration:action_profile_declaration ::=action_profile action_profile_name {action_specification[ size : const_expr ; ][ dynamic_action_selection : selector_name ; ]}action_specification ::=actions { [ action_name ; ] + }action_selector_declaration ::=action_selector selector_name {selection_key : field_list_calculation_name ;}Action profiles are declared and applied with the following conventions:• The size attribute indicates the number of entries required for the action profile.
If this cannot be supported, an error will be signaled when the declaration isprocessed. If this attribute is omitted, there is no guarantee as to the number ofentries that the action profile will be able to accomodate at run time.6912 TABLE DECLARATIONS12Table DeclarationsTables are declarative structures specifying match and action operations, and possiblyother attributes. The action specification in a table indicates which action functions areavailable to this table’s entries.Note that masks may be specified for the match fields (i.e., lookup keys) in the table declaration.
This enables table lookup with arbitrary sub-fields, rather than only with thewhole fields. These masks are applied statically to the fields prior to the table-lookupoperation and hence should not be confused with the value mask for a field with thefield-match type ternary.The table key matches an entry if the conjunction (AND) of all fields in the key matchtheir corresponding values in the table entry.Here is the BNF for a table declaration:table_declaration ::=table table_name {[ reads { field_match + } ]table_actions[ min_size : const_expr ; ][ max_size : const_expr ; ][ size : const_expr ; ][ support_timeout : bool_value ; ]}field_match ::= field_or_masked_ref : field_match_type ;field_or_masked_ref ::=header_ref | field_ref | field_ref mask const_exprfield_match_type ::= exact | ternary | lpm | index | range | validtable_actions ::=action_specification | action_profile_specificationaction_profile_specification ::=action_profile : action_profile_name ;This example is from the mTag edge switch program.
It maps the packet’s L2 destinationto an mTag. If it fails to find a map, it may copy the packet to the CPU.// Check if the packet needs an mtag and add one if it does.table mTag_table {7012 TABLE DECLARATIONSreads {ethernet.dst_addr: exact;vlan.vid: exact;}actions {add_mTag;// Action called if pkt needs an mtag.common_copy_pkt_to_cpu; // If no mtag, send to the CPUno_op;}max_size: 20000;}For an implementation of ECMP using an action profile with an action selector, pleasesee 17.6.3.Match types have the following meanings.• exact: The field value is matched against the table entry and the values must beidentical for the entry to be considered.• ternary: A mask provided with each entry in the table.
This mask is ANDed withthe field value before a comparison is made. The field value and the table entryvalue need only agree on the bits set in the entry’s mask. Because of the possibilities of overlapping matches, a priority must be associated with each entry in atable using ternary matches.• lpm: This is a special case of a ternary match. Each entry’s mask selects a prefix byhaving a divide between 1s in the high order bits and 0s in the low order bits. Thenumber of 1 bits gives the length of the prefix which is used as the priority of theentry.• index: The field value is used as the index of a table entry.• range: Each entry specifies a low and high value for the entry and the field matchesonly if it is in this range. Range end points are inclusive. Signedness of the field isused in evaluating the order.• valid: Only applicable to packet header fields or header instances (not metadatafields), the table entry must specify a value of true (the field is valid) or false (thefield is not valid) as match criteria.Tables are defined and applied with the following conventions:• Header references for matching may only be used with the valid match type.• Exactly one of the actions indicated in either the action_specification or theaction_profile_specification will be run when a table processes a packet.7112 TABLE DECLARATIONS– Entries are inserted at run time and each rule specifies the single action tobe run if that entry is matched.– Actions in the list should be compound actions.• At run time, the table entry insert operation (not part of P4) must specify:– Values for all fields specified in the reads entry along with optional valuemasks, prefix lengths, and an entry priority, depending on the field-matchtype.
The value mask and entry priority are necessary for the ternary matchtype, and the prefix length for the lpm match type.– The name of the action from the action_specification or the action_profile_specification and the parameters to be passed to the action function when it is called.• A table must not have entries with the same key. In other words, looking up a tablemust lead to either one or zero match entry. This means, for an exact match-typekey, a table is not allowed to have more than one entry with the same key value.Similarly, for a ternary (lpm respectively) match-type key, a table is not allowedto have more than one entry with the same key value and mask (prefix lengthrespectively).• A default action is taken when no table entry matches.
This action is specified atrun time. If no default action is specified and no entry matches, the table does notaffect the packet, and processing continues according to the imperative controlflow.• If reads is not present, the table will always execute the default action. If no default action has been specified, the table has no effect on the packet.• The keyword mask may be used for a field to indicate that only the indicated bitsshould be used in the match.
This mask is applied once to the Parsed Representation’s field prior to any comparisons (compared to the per-entry mask which maydiffer from entry to entry).• The match type valid indicates that the field’s parent header (or, in the case ofmetadata, the field itself ) should be tested for validity. The value of 1 will matchwhen the header is valid; 0 will match when the header is not valid. Note thatmetadata fields are always valid.• Using an invalid field or header as a match key may lead to an undefined behavior.• The match type index cannot be used with other match types.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
