p4 spec v1.1 (1185620), страница 18
Текст из файла (страница 18)
Instead, the intent is to allow target providers to introducedifferent target architectures (which are heterogeneous compositions of programmableand non-programmable regions) for their targets, while allowing the users of the targets to program any of the programmable regions in the targets in P4. In doing this,an important goal is to make it possible to write portable P4 code, with ways to easily combine that portable code into programs for specific architectures. While targetspecific extensions will be allowed, the mission is to encourage portable programs andportable implementations.
To ensure portability, the P4 working groups will define oneor more standard architecture(s). A P4 program written for a standard architecture will11517.7 Addendum for Version 1.1.017 APPENDICESbe portable across all the targets conforming to the standard architecture. It is expectedthat target vendors will implement extensions with the expectation of (some of) thoseextensions may make their way into future versions of the standard architecture.17.7.2 TargetsA machine that can run a P4 program is called target. While P4 provides a standardlanguage for describing the logic within programmable regions of a forwarding element, the programmable regions that are actually available and the data flow betweenthose regions can vary from target to target. For example, one target may consist of aparser, ingress match+action pipeline and egress match+action pipeline, connected insequence.
Another target may consist of several parser-pipeline pairs, which the packetmay flow through in any order by setting appropriate control signals.With architecture-language separation, the P4 language itself would address only thecontents of each programmable region. Then the overall P4 framework would providethe setting for target providers and standards bodies to define architectures that complement the standard architecture(s). To accomplish this, each target would conformto a Target Architecture, specified partially as a collection of P4 code, and partially as aset of specifications that describe the P4-programmable regions of the target and howthose regions interact with each other.
The latter specifications may involve non-P4(or possibly extended P4 in the future) rigorous written descriptions and/or simulationmodels. Examples of programmable regions would be packet parsers, and pipelines oftables and actions. The existing P4 abstract forwarding model would be one example ofa standard architecture.In addition to the Target Architecture specification, there is a Target-Specific Libraryspecification. This provides definitions of available P4 extern object types (Section 16),which represent the processing capabilities of the target beyond the standard P4 primitive actions.
The functional specifications of these objects may involve non-P4 (or possibly extended P4 in the future) rigorous written descriptions and/or simulation models. Examples of these capabilities could include arithmetic functions and checksumgenerators.17.7.3 Target Architecture StructureThe P4 portion of a target architecture description provides prototypes for the programmable regions of the target. These prototypes specify the input and output interfaces to each region, including the format of metadata passed across each interface.These interfaces form the connection between the region of P4 code in question andthe surrounding non-P4-programmable regions. For instance, a region of code may11617.7 Addendum for Version 1.1.017 APPENDICESreceive intrinsic metadata reporting a packet’s ingress port and length, and may writeintrinsic metadata controlling the packet’s egress port and queue priority.Together with this P4-described portion, the additional non-P4 specification clarifiesthe meaning of the context for the P4 portion of the architecture and explains howthese portions fit together.
Initially, this is envisaged to be mostly human-languagedocumentation and visual diagrams to show the flow of data between programmableregions, though it may also contain pseudocode or simulation models to specify rigorously the behavior of logic not expressible in P4. Looking further out, there has alreadybeen experimentation with some extension of P4 itself, to allow rigorous specificationof the interaction between regions in terms of established P4 mindset and terminology.17.7.4 Target Architecture SelectionA program’s target architecture is selected by including that architecture’s P4 prototypesin the source code, and then writing structures that conform to the prototypes it specifies. These structures can make use of the extern object types that are provided in theaccompanying target-specific library.No one architecture is mandated by the P4 spec, and a given physical target may support multiple architectures.
Some architectures may be written by a target provider andhighly specialized to the underlying machinary, while others may be standardized andintentionally abstract to allow greater portability and ease-of-use. A particular exampleof the latter is that a standard architecture will be defined based on the existing abstractforwarding model.An important aspect is that all P4 programs written for a given architecture are portableacross all targets that faithfully implement that architecture (assuming that enough resources are available). P4 conformance of a target is defined as follows: if a specifictarget supports a given target architecture, then a program written to that architectureand executed on the target must provide exactly the same behavior as the same program executed on an abstract machine with infinite resources.In general, P4 programs are not expected to be portable across different architectures.For example, executing a P4 program that controls packet broadcast by writing specialintrinsic metadata will not work on a target that provides no such intrinsic metadata.Further, particular targets may not support fully some P4 language constructs (for example, some targets may not support features necessary for IPv4 options processing orarbitrary-length stacked protocol headers).
Ideally any restrictions on the P4 languageimposed by a specific target should be clearly documented by the target architecture.At the very least, restrictions have to be conveyed to P4 programmers using clear compiler error messages when attempting to compile programs that use unsupported fea-11717.7 Addendum for Version 1.1.017 APPENDICEStures.17.7.5 Programmable blocksProgrammable blocks are user-defined blocks of P4 code that can be instantiated multiple times within a program, and interact with the enclosing target architecture by occupying its programmable regions. Each instance of a programmable block matches aP4-described prototype in the architecture specification.Programmable block types. A programmable block type is comprised of a signatureand code body.
The body forms a new scope that can contain any normal P4 declaration. The enclosed code is lexically scoped and additionally has access to the externalmetadata parameters declared by its input-output signature.Similarly to header types for example, the objects declared inside a programmable blocktype do not actually "exist" inside the program until the block is instantiated. In thissense, a programmable block type is declaring a "template" of P4 code that can bestamped down into the program.Programmable block instances. An instance of a programmable block type represents concrete resource declarations of the contents of the block. Because of this, blockscannot be instantiated dynamically at run time: they are static, compile-time declarations.When creating an instance, the programmer must bind all of the input-output parameters in the type’s signature either to constants or other object names that are currentlyin scope.Multiple instances of the same block type create completely separate instances of thetype’s component objects which the surrounding architecture and/or a runtime API canrefer to using dotted notation.Programmable block prototypes.
Target architectures use programmable blocks tosegment P4 code into the various programmable regions of the underlying target. Thearchitecture specifies the prototypes of the blocks it expects to be filled in by the program. These prototypes specify the signature of a block but leave its implementationundefined. They are expected to be paired with a concrete programmable block declaration that has a matching signature.Prototypes may also include type variables, which are resolved to concrete types whenthe prototype is paired with its implementation.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
