P4-16语言规范：编程网络设备的数据平面

需积分: 9 154 浏览量更新于2024-07-09 收藏 1.32MB PDF 举报

P4-16-v1.0.0-spec.pdf 是 P4 语言的 1.0.0 版本规格文档，由 P4 Language Consortium 出版于 2017 年 5 月 22 日。P4 是一种用于编程网络设备数据平面的语言，旨在提供对网络硬件进行高级定制和优化的能力。该文档的目标读者包括 P4 编程器，他们需要编写编译器、模拟器、集成开发环境（IDE）和调试器，以及想要深入理解 P4 语法和语义的开发者。 1. **语言概述** (Section 3): 文档首先介绍了 P4 的优势，强调了它如何通过提供灵活性和性能优化来简化网络设备的设计和编程。它对比了 P4 1.0 和 1.1 版本的演变，展示新版本在功能和改进方面的进步。 2. **架构模型** (Section 4): P4 的架构模型包括标准架构，如解析器、数据平面接口和外部对象与函数。这部分详细描述了数据平面的不同组件，如仲裁器、解析器运行时块（负责处理输入数据包并提取相关信息）、分组器（决定数据包的转发路径），以及可用的外部块（可能包含硬件加速或来自外部模块的功能）。 3. **示例：非常简单的交换机** (Section 5): 为了帮助理解，文档提供了一个名为“Very Simple Switch”的示例。这个设计展示了如何用 P4 语言构建一个基础的数据包处理流程，包括解析器用于读取和解码数据包头，以及分路逻辑来将数据包导向不同的输出端口。通过这个例子，读者可以直观地看到 P4 在实际网络设备中的应用。 4. **术语、定义和符号** (Section 2): 在文档的开头部分，作者列出了关键术语和定义，确保读者对语言的各个方面有统一的理解。这包括核心概念如表项（table entries）、匹配字段（match fields）、行为（actions）等。 5. **语言规范** (Section 4.1-4.3): 该文档详细阐述了 P4 1.6 版本的语法结构，包括数据包处理的基本单元，如控制流语句、数据类型，以及如何组织和调用这些单元以构建复杂的处理逻辑。 P4-16-v1.0.0-spec.pdf 是一份详尽的指南，对于网络设备编程者、研究者以及对该领域感兴趣的人士来说，提供了关于 P4 语言的全面了解，涵盖了其语法、语义、架构模型和实际应用示例。通过阅读这份文档，用户能够掌握如何使用 P4 语言创建高性能和灵活的网络数据平面解决方案。

package VSS<H>

A type variable indicates a type yet unknown that must be provided by the user at a later time. In this

case H is the type of the set of headers that the user program will be processing; the parser will pro-

duce the parsed representation of these headers, and the match-action pipeline will update the input

headers in place to produce the output headers.

• e package VSS declaration has three complex parameters, of types Parser, Pipe, and Deparser

respectively; which are exactly the declarations we have just described. In order to program the

target one has to supply values for these parameters.

• In this program the inCtrl and outCtrl structures represent control registers. e content of the

headers structure is stored in general-purpose registers.

• e extern Checksum16 declaration describes an extern object whose services can be invoked to

compute checksums.

5.2. Very Simple Switch Architecture Description

In order to fully understand VSS's behavior and write meaningful P4 programs for it, and for imple-

menting a control plane, we also need a full behavioral description of the xed-function blocks. is

section can be seen as a simple example illustrating all the details that have to be handled when writ-

ing an architecture description. e P4 language is not intended to cover the description of all such

functional blocks—the language can only describe the interfaces between programmable blocks and

the architecture. For the current program, this interface is given by the Parser, Pipe, and Deparser dec-

larations. In practice we expect that the complete description of the architecture will be provided as an

executable program and/or diagrams and text; in this document we will provide informal descriptions

in English.

5.2.1. Arbiter block

e input arbiter block performs the following functions:

• It receives packets from one of the physical input Ethernet ports, from the control plane, or from

the input recirculation port.

• For packets received from Ethernet ports, the block computes the Ethernet trailer checksum and

veries it. If the checksum does not match, the packet is discarded. If the checksum does match,

it is removed from the packet payload.

• Receiving a packet involves running an arbitration algorithm if multiple packets are available.

• If the arbiter block is busy processing a previous packet and no queue space is available, input

ports may drop arriving packets, without indicating the fact that the packets were dropped in any

way.

• After receiving a packet, the arbiter block sets the inCtrl.inputPort value that is an input to the

parser with the identity of the input port where the packet originated. Physical Ethernet ports are

numbered 0 to 7, while the input recirculation port has a number 13 and the CPU port has the

number 14.

5.2.2. Parser runtime block

e parser runtime block works in concert with the parser. It provides an error code to the match-

action pipeline, based on the parser actions, and it provides information about the packet payload

(e.g., the size of the remaining payload data) to the demux block. As soon as a packet's processing is

completed by the parser, the match-action pipeline is invoked with the associated metadata as inputs

(packet headers and user-dened metadata).

5.2.3. Demux block

e core functionality of the demux block is to receive the headers for the outgoing packet from the

deparser and the packet payload from the parser, to assemble them into a new packet and to send the

result to the correct output port. e output port is specied by the value of outCtrl.ouputPort, which

is set by the match-action pipeline.

• Sending the packet to the drop port causes the packet to disappear.

• Sending the packet to an output Ethernet port numbered between 0 and 7 causes it to be emitted

on the corresponding physical interface. e packet may be placed in a queue if the output inter-

face is already busy emitting another packet. When the packet is emitted, the physical interface

computes a correct Ethernet checksum trailer and appends it to the packet.

• Sending a packet to the output CPU port causes the packet to be transferred to the control plane.

In this case, the packet that is sent to the CPU is the original input packet, and not the packet

received from the deparser—the latter packet is discarded.

• Sending the packet to the output recirculation port causes it to appear at the input recirculation

port. Recirculation is useful when packet processing cannot be completed in a single pass.

• If the outputPort has an illegal value (e.g., 9), the packet is dropped.

• Finally, if the demux unit is busy processing a previous packet and there is no capacity to queue

the packet coming from the deparser, the demux unit may drop the packet, irrespective of the

output port indicated.

Please note that some of the behaviors of the demux block may be unexpected—we have highlighted

them in bold. We are not specifying here several important behaviors related to queue size, arbitration,

and timing, which also inuence the packet processing.

e arrow shown from the parser runtime to the demux block represents an additional information

ow from the parser to the demux: the packet being processed as well as the oset within the packet

where parsing ended (i.e., the start of the packet payload).

5.2.4. Available extern blocks

e VSS architecture provides an incremental checksum extern block, called Checksum16. e check-

sum unit has a constructor and four methods:

• clear(): prepares the unit for a new computation

• update<T>(in T data): add some data to be checksummed. e data must be either a bit-string, a

header-typed value, or a struct containing such values. e elds in the header/struct are con-

catenated in the order they appear in the type declaration.

• get(): returns the 16-bit one's complement checksum. When this function is invoked the check-

sum must have received an integral number of bytes of data.

剩余128页未读，继续阅读

felix905

粉丝: 1
资源: 6

P4-16语言规范：编程网络设备的数据平面

hibernate-jpa-2.1-api-1.0.0.final-sources.jar

hibernate-jpa-2.1-api-1.0.0.Final.jar

CIS-Apple-iOS-13-and-iPadOS-13-Benchmark-v1.0.0.pdf

android-pdfview-sample-1.0.0.jar

xjar-agent-hibernate-v1.0.0.jar

easybeans-example-timerservice-1.0.0.rc2-jonas-sources.jar

easybeans-war-openjpa-1.0.0.rc2-sources.jar

easybeans-examples-statefulbean-1.0.0.rc2-jonas.jar

easybeans-example-timerservice-1.0.0.rc2-jonas.jar

easybeans-uberjar-openjpa-1.0.0.rc2-jonas.jar

最新资源