p4 spec v1.1 (1185620), страница 9
Текст из файла (страница 9)
The compiler must raise an error if the counter name is referenced478.2 Meters8 COUNTERS, METERS AND REGISTERSby actions used in another table.The instance_count attribute indicates the number of instances (cells) of the counterto allocate. The instance_count attribute is required if the counter is not declaredwith the direct attribute. The compiler should raise an error if both instance_countand direct are specified together, or if neither direct nor instance_count are specified.A bytes type counter gets incremented by the packet length in bytes whenever thecount action is executed either implicitly (in case of direct) or explictly (in case ofstatic) for the counter. A packets type counter gets incremented by just one whenever the count action is executed for the counter.
A bytes_and_packets type counter iscomprised of two sub-counters internally, and each sub-counter is incremented by thepacket length and by one respectively.8.2 MetersMeter declarations follow those of counters.meter_declaration ::=meter meter_name {type : meter_type ;[ result : field_ref ; ][ direct_or_static ; ][ instance_count : const_expr ; ]}meter_type ::= bytes | packetsMeters are stateful objects that measure the data rate, either in packets or bytes persecond, and output the result as one of three colors: red, yellow or green, which areencoded as a 2-bit-wide field.The encoding of these values is target-specific. It is, however, expected that each targetwill define the appropriate constants: P4_METER_COLOR_RED, P4_METER_COLOR_YELLOW,and P4_METER_COLOR_GREEN, which are understood by the compiler and hence can beused in a portable P4 program.P4 specification does not currently mandate any specific metering algorithm for themeter implementations, and hence ascribing the detailed semantics of the colors is beyond the scope of P4.
While the three-color marking algorithms, specified in RFC 2697and RFC 2698 serve as good references, other options are also possible. Subsequently,488.3 Registers8 COUNTERS, METERS AND REGISTERSmeter configuration also remains target-specific and not defined in P48 .If the meter is declared with the direct attribute, one meter is associated with eachentry in the named table. In this case, no meter action needs to be given for the table actions; the meters are automatically updated whenever the corresponding entry isapplied, and the meter result (i.e., color) is stored in the field specified by the result attribute.
Hence, the result attribute is required if a meter is declared with the direct attribute. Consequently meter names declared as direct are not allowed to be referencedin the execute_meter primitive, and a compiler must raise an error if this occurs.If the meter is declared with the static attribute, it may only be referenced by actionsinvoked in the indicated table via the execute_meter primitive. The compiler must raisean error if a different table attempts to invoke an action with this meter.The instance_count attribute indicates the number of instances (cells) of the meter toallocate.
The instance_count attribute is required if the meter is not declared with thedirect attribute.8.3 RegistersRegisters are stateful memories whose values can be read and written in actions. Theyare like counters, but can be used in a more general way to keep state.A simple example use might be to verify that a "first packet" was seen for a particulartype of flow. A register cell would be allocated to the flow, initialized to "clear". Whenthe protocol signalled a "first packet", the table would match on this value and updatethe flow’s cell to "marked". Subsequent packets in the flow could would be mapped tothe same cell; the current cell value would be stored in metadata for the packet and asubsequent table could check that the flow was marked as active.Register declarations are similar to those of meters and counters. Registers may be declared either with a width or with a header type layout.register_declaration ::=register register_name {width_or_layout ;[ direct_or_static ; ][ instance_count : const_expr ; ][ attribute_list ; ]}width_or_layout ::= width_declaration | layout_declarationwidth_declaration ::= width : const_expr8In general, any run-time configuration aspects related to the control plane are currently out of scopeof this P4 spec.
In future, the P4 community may address these issues in a separate spec.499 MATCH+ACTION TABLE OVERVIEWlayout_declaration ::= layout : header_type_nameattribute_list ::= attributes : attr_entryattr_entry ::= signed | attr_entry , attr_entryField names must be listed in the fields attribute of the header declaration.The instance_count attribute indicates the number of instances (cells) of the registerto allocate. The instance_count attribute is required if the register is not declared withthe direct attribute.Although registers cannot be used directly in matching, they may be used as the sourceof a modify_field action allowing the current value of the register to be copied to apacket’s metadata and be available for matching in subsequent tables.If a register is declared with a layout declaration, the header type must be fixed length(no varbit fields).A register reference is done with array syntax.register_ref ::=register_name "[" const_expr "]" [.field_name]If the register is declared with a layout, then the reference can be refined with a fieldname as indicated.9Match+Action Table OverviewP4 allows the specification of table instances with the table declaration.
This declaration defines the exact set of fields that should be examined to find a match (a "hit"). Associated with each entry is an indication of an action to take should the entry match.If no entry is found that matches the current packet, the table is said to "miss"; in thiscase a default action for the table may be applied.Each entry in a match+action table has the following parts:• The match values for comparison with the Parsed Representation of the packet.The format of these values determined by the table declaration.• A reference to an action function, if the entry should match.
The set of allowedaction functions is specified in the table declaration.• Parameter values to pass to the action when the action function is called. The format of these parameters is determined by the particular action function selected5010 ACTIONSby the entry.10ActionsIn P4, actions are declared imperatively as functions. These function names are usedwhen populating the table at run time to select the action associated with each entry.These are called compound actions to differentiate them from primitive actions, or simply actions when the context is clear.Action functions take typed and annotated parameters.
P4 assumes the copy-in copyout evaluation semantics for the action parameters. When action parameters alias oneanother in a P4 program, the target may introduce undefined behaviors. Hence, the P4authors are recommended not to introduce parameter aliasing. In addition, a compilermay generate an error upon detecting parameter aliasing.The values passed to these parameters are programmed into the table entry by the runtime API.
When that entry is selected due to a match, those parameters are passed to theaction. The P4 table declarations might be used to generate run-time APIs which wouldhave parameters corresponding to the action parameters for the entry’s action. Typically, the compiler would be responsible for ensuring that the values in the run-timeAPIs are properly mapped to and consistent with the P4 program specification.In addition to values from the matching table entry, the action operation has access toheaders and metadata in the Parsed Representation.Action functions are built from primitive actions.
A standard set of primitive actions arelisted in the following section, although a target may support additional target-specificprimitive actions. Using target-specific primitive actions limits the portability of theresulting program.Here are two example functions from the mTag example. The first indicates a copy ofthe packet should be sent to the CPU.
The parameters cpu_code and bad_packet areexposed to the run time API and will be set according to the values provided when atable entry is added.// Copy the packet to the CPU;action common_copy_pkt_to_cpu(in bit<8> cpu_code, in bit bad_packet) {modify_field(local_metadata.copy_to_cpu, 1);modify_field(local_metadata.cpu_code, cpu_code);modify_field(local_metadata.bad_packet, bad_packet);}This function sets up the mTag. It would only be invoked on an edge switch.5110.1 Primitive Actions10 ACTIONS// Add an mTag to the packet; select egress spec based on up1action add_mTag(in bit<8> up1, in bit<8> up2,in bit<8> down1, in bit<8> down2)add_header(mtag);// Copy VLAN ethertype to mTagmodify_field(mtag.ethertype, vlan.ethertype);// Set VLAN’s ethertype to signal mTagmodify_field(vlan.ethertype, 0xaaaa);// Add the tag source routing informationmodify_field(mtag.up1, up1);modify_field(mtag.up2, up2);modify_field(mtag.down1, down1);modify_field(mtag.down2, down2);// Set the destination egress port as well from the tag infomodify_field(standard_metadata.egress_spec, up1);}10.1 Primitive ActionsP4 supports an extensible set of primitive actions.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
