p4 spec v1.1 (1185620), страница 8
Текст из файла (страница 8)
This process is called deparsing as it reverses the process of parsing.P4 takes the approach that any format which should be generated on egress should berepresented by the parser used on ingress. Thus, the parse graph represented in the P4program is used to determine the algorithm used to produce the serialized packet fromthe Parsed Representation. Note the following considerations:• Only headers which are valid are serialized.• For some parse graphs it is impossible to infer a deparser that produces headersin the same order as they may appear in the input packets. For example, considerthe case when two headers A and B may appear in either order in the input packet.The exact deparsing behavior in such a case is currently un-defined6 .• Metadata fields are not serialized directly (as they are not parsed). Metadata fieldsmay be copied to packet header fields in match+action processing, allowing themto be serialized for egress.7Standard Intrinsic MetadataMetadata is state associated with each packet.
It can be treated like a set of variablesassociated with each packet, read and written by actions executed by tables. However,some metadata has special significance to the operation of the target. This is calledintrinsic metadata as it has semantics intrinsic to the operation of the target machine.Examples include the ingress port number or the egress selection. The first is an example of read only data which is set by the target when the packet arrives; the second isset by table actions, but then is processed by the Buffer Mechanism and results in thepacket being sent to a particular egress port or ports.This specification identifies standard intrinsic metadata fields for which support is mandatory for P4 compliant targets.
Although these fields are mandatory, the format of these6We recognize this problem and intend address it in the upcoming spec release by introducing anoptional feature via which one can specify the desired deparsing behavior explicitly.437 STANDARD INTRINSIC METADATAfields may be target specific. The definition for these formats must be provided by thetarget, either as a header to be automatically included by a compiler, or internally in thecompiler’s implementation.Standard intrinisic metadata is called out in this section either because it is automatically populated (ingress_port for instance) or because it is necessary to describe howthe abstract machine operates (egress_port for instance).Targets may provide their own definitions of intrinsic metadata in addition to the standard intrinsic metadata, although programs which depend on such definitions may notbe portable.This table shows the fields defined for the metadata instance standard_metadata7 .7We will thoroughly specify the details of these metadata – including their exact meaning and specificavailability scope (within a target) – in the next spec revision.
See Section 17.7 for our current tentativeapproach.447 STANDARD INTRINSIC METADATAFieldingress_portpacket_lengthegress_specegress_portegress_instanceinstance_typeparser_statusparser_error_locationNotesThe port on which the packet arrived. Set prior toparsing. Always defined. Read only.The number of bytes in the packet. For Ethernet,does not include the CRC. Set prior to parsing. Cannot be used for matching or referenced in actions ifthe switch is in "cut-through" mode. Read only.Specification of an egress. Undefined until set bymatch+action during ingress processing. This isthe “intended” egress as opposed to the committedphysical port(s) (see egress_port below).
May be aphysical port, a logical interface (such as a tunnel, aLAG, a route, or a VLAN flood group) or a multicastgroup.The physical port to which this packet instance iscommitted. Read only. This value is determinedby the Buffering Mechanism and so is valid only foregress match+action stages. See Section 14 below.Read only.An opaque identifier differentiating instances of areplicated packet. Read only.
Like egress_port, thisvalue is determined by the Buffering Mechanismand is valid only for egress match+action stages. SeeSection 14 below.Represents the type of instance of the packet:• normal• ingress clone• egress clone• recirculatedResult of the parser. 0 means no error. Otherwise,the value indicates what error occurred during parsing. Specific representation is TBD.If a parser error occurred, this is an indication of thelocation in the parser program where the error occurred. Specific representation is TBD.Table 12: Standard Intrinsic Metadata Fields458 COUNTERS, METERS AND REGISTERS8Counters, Meters and RegistersCounters, meters and registers maintain state for longer than one packet.
Together theyare called stateful memories. They require resources on the target and hence are managed by a compiler.In this section, we refer to an individual counter, meter or register as a cell. In P4, stateful memories are organized into named arrays of cells (all of the same type of object).A cell is referenced by its array name and index. Cells are accessed or updated by theactions applied by a table. Targets may have limitations on the amount of computationthat can be done to determine the index of the cell being accessed. They may also havelimitations on the updates that can be done to the cell’s contents.For example:counter ip_pkts_by_dest {type : packets;direct : ip_host_table;}declares a set of counters attached to the table named ip_host_table.
It allocates onecounter cell for each entry in that table.Another example:meter customer_meters {type : bytes;instance_count : 1000;}declares an array of 1000 meters named customer_meters. These may be referencedfrom the actions of any table (though usually only one or two tables will be likely toreference them).P4 allows stateful memory resources to be global – that is, referenced by any table – or tobe static – bound to one table instance.
Normally, multiple table entries, whether or notthey are in the same table, may refer to the same cell. This is called indirect access. P4also allows direct access where the stateful memory resource is bound to one table andeach entry in the table is allocated its own dedicated cell in that memory. An exampleof this is where every table entry has its own counter.A compiler will attempt to allocate the resources required by the program accordingto availability on the target.
However, target constraints may make this impossible;for example, a target may not allow references to the same global resource in both the468.1 Counters8 COUNTERS, METERS AND REGISTERSingress and egress pipelines.Counters and meters are referenced in special primitive actions as defined in Section 10.1.Registers may be used as arguments to the same primitive actions that modify headerfields.8.1 CountersCounters are declared as follows.counter_declaration ::=counter counter_name {type : counter_type ;[ direct_or_static ; ][ instance_count : const_expr ; ][ min_width : const_expr ; ][ saturating ; ]}counter_type ::= bytes | packets | bytes_and_packetsdirect_or_static ::= direct_attribute | static_attributedirect_attribute ::= direct : table_namestatic_attribute ::= static : table_nameThe min_width attribute indicates the minimum number of bits required for each cell.The compiler or target may allocate more bits to each cell.The saturating attribute indicates that the counter will stop counting if it reaches itsmaximum value (based on its actual bit-width).
Otherwise the counter will wrap.If the counter is declared with the direct attribute, one counter is associated with eachentry in the named table. In this case, no count action needs to be given for the tableactions; they are automatically updated whenever the corresponding entry is applied.As a result, counter names declared as direct are not allowed to be referenced in thecount primitive and a compiler must raise an error if this occurs.Run time APIs should be provided to indicate the actual width of a given counter. Thisis necessary for calculating the maximum value a counter may take (which is necessaryfor properly managing saturation or roll over).If the counter is not declared direct, actions must reference the counter by name andindex.If the counter is declared with the static attribute, the counter resource is dedicated tothe indicated table.