Stateful programmable data plane system and chip based on predictive execution

Abstract

The application relates to the technical field of programmable data planes, in particular to a state-bearing programmable data plane system and chip based on prediction execution, wherein the data plane structure comprises: a plurality of stage processors, the plurality of stage processors form a pipeline for data processing, and each stage processor processes one pipeline stage; a side ring, the side ring comprises a plurality of ring nodes, each ring node is connected with each stage processor in one-to-one correspondence; a read processor reads the state required by a state-bearing data packet; a write processor writes the state required by the state-bearing data packet, identifies a data packet which needs to be resubmitted after being modified, uploads the resubmitted data packet to a corresponding ring node, sends the resubmitted data packet to a corresponding ring node of the read processor through the side ring, and the read processor downloads the resubmitted data packet from the corresponding ring node. Thus, the problems that the pipeline technology in the related art cannot support relatively complex state-bearing operations and has high development cost are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of programmable data plane, and in particular to a stateful programmable data plane system and chip based on prediction execution. BACKGROUND

[0002] A programmable switch includes a programmable data plane and a control plane, the data plane is responsible for protocol analysis and reverse analysis, data packet processing, and the control plane is responsible for issuing analysis rules and flow table matching rules. From custom protocol forwarding to supporting in-network computing applications, high-performance programmable switch chips further tap the potential of data plane devices. The demand for high throughput makes hardware pipeline the main choice for switch chip architecture. Although the pipeline has unparalleled throughput, it assumes a forward processing flow, which hinders the effective support of stateful functions essential to many valuable applications.

[0003] Stateful data plane functions can be summarized as EFSM (extended finite state machine). The state of the data packet is read from the flow state table; according to the current state and input, the corresponding operation is performed; the operation may cause state update, which will be written back to the flow state table. The contradiction between the operation of writing back the flow state table and the forward processing flow of the pipeline makes it impossible for existing pipeline technology to support more complex stateful operations. SUMMARY

[0004] The present application provides a stateful programmable data plane system and chip based on prediction execution to solve the problems of the pipeline technology in the related art that cannot support more complex stateful operations and high development cost.

[0005] The first aspect of the present application provides a stateful programmable data plane system based on prediction execution, comprising: a plurality of stage processors, wherein the plurality of stage processors constitute a pipeline of data processing, and each stage processor processes a pipeline stage; a side ring, wherein the side ring includes a plurality of ring nodes, and the plurality of ring nodes are connected one by one with each stage processor; any stage processor in the plurality of stage processors is configured as a read processor or a write processor, the read processor reads the state required to be read by at least one stateful data packet and predicts that the state of the stateful data packet is unchanged; the write processor writes the state required to be written by the stateful data packet, identifies the data packet that needs to be resubmitted due to the modified state, uploads the data packet that needs to be resubmitted to the ring node corresponding to the write processor, and sends it to the ring node corresponding to the read processor through the side ring, and the read processor downloads the data packet that needs to be resubmitted from the corresponding ring node.

[0006] Optionally, the stage processor comprises a configurable scheduling module, wherein the configurable scheduling module of the read processor is configured as a read scheduling module, the configurable scheduling module of the write processor is configured as a write scheduling module, and the configurable scheduling modules of other stage processors are not activated.

[0007] Optionally, the read scheduling module and the write scheduling module each comprise a dirty table stored in a content addressable memory, and the key matched in the dirty table is a state table index of a flow, wherein the dirty table of the write scheduling module contains a table of keys, and the dirty table of the read scheduling module contains a table of keys and corresponding data; the write scheduling module writes a flow corresponding to a data packet in a modified state into the dirty table, and sends a write-back control signal to the read scheduling module through the side ring; and the read scheduling module writes the flow corresponding to the data packet in the modified state into the dirty table according to the write-back control signal.

[0008] Optionally, the read processor further comprises a re-submission buffer for saving re-submitted data packets; the read scheduling module further comprises a data packet buffer for saving data packets that hit the dirty table, and data packets of each flow are linked in a first chain table and a second chain table, the first chain table is used for storing newly arrived data packets on the pipeline, and the second chain table is used for storing data packets that need to be re-submitted; and the in-order check module is used for scheduling data packets of the data packet buffer, and when the data packets of the data packet buffer are scheduled, whether data packets that need to be re-submitted of a flow to which the scheduled data packet belongs have all arrived at the re-submission buffer and have all been moved to the second chain table of the data packet buffer.

[0009] Optionally, the in-order check module is further used for starting a timer until the timer expires, and determining that the data packets that need to be re-submitted have all arrived at the re-submission buffer.

[0010] Optionally, a heartbeat address field is arranged on a bus of the side ring, the heartbeat address field is independent of other fields on the bus, and each pipeline stage occupies one bit of the heartbeat address field, and a signal carrying a heartbeat is written into the heartbeat address field; and when the timer receives the signal carrying the heartbeat from the corresponding write processor, the timer advances by one time.

[0011] Optionally, the in-order check module is further used for writing a sequence number of each data packet into a counter table at each data packet read state; and if the sequence number of the data packet that needs to be re-submitted is equal to the sequence number in the counter table, it is determined that the data packets that need to be re-submitted have all arrived at the re-submission buffer.

[0012] Optionally, the read processor is further used for writing a cleaning signal into a corresponding ring node when data packets of one flow in the data packet buffer start to be scheduled, sending the cleaning signal to the corresponding ring node of the write processor through the side ring, and downloading the cleaning signal to the write processor; and the write processor removes the corresponding flow from the dirty table according to the cleaning signal.

[0013] Optionally, the read scheduling module comprises first to third levels of state consistency, wherein the first level of state consistency comprises that a read operation of a data packet is after write operations of all data packets before the data packet; the second level of state consistency comprises that on a flow where a target data packet is located, read operations of K data packets after the target data packet are allowed to be before write operations of the K data packets, and from the K+1 data packet, a read operation of a data packet is after write operations of all data packets before the data packet; and the third level of state consistency comprises that a read operation of a data packet is in any order with a write operation.

[0014] The second aspect embodiment of the present application provides a programmable switching chip, comprising: the state-based programmable data plane system with prediction execution of any one of the above embodiments.

[0015] Therefore, the present application comprises the following beneficial effects:

[0016] The embodiment of the present application adds a simple side ring to the pipeline, so that each pipeline stage is connected thereto. On the side ring, the direction of data flow is opposite to that of the pipeline, thereby providing a fast backward communication path. A read processor reads the state required by a data packet with state, and a write processor writes back the state required to modify the data packet, so that the state is written back across stages, which is very convenient and efficient, and supports complex state-based functions, thereby reducing the development cost, deployment cost and maintenance cost of in-network computing applications as a whole. Therefore, the problem that the pipeline technology in the related art cannot support relatively complex state-based operations and has high development cost and the like is solved.

[0017] Additional aspects and advantages of the present application will be made apparent from the following description, which, taken in conjunction with the accompanying drawings, that will be part hereof. BRIEF DESCRIPTION OF DRAWINGS

[0018] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description, taken in conjunction with the accompanying drawings, in which:

[0019] Figure 1 It is the technical architecture of Banzai in the related art;

[0020] Figure 2 It is the atomic operation circuit diagram of Banzai in the related art;

[0021] Figure 3 It is the technical architecture diagram of the distributed reconfigurable matching table in the related art;

[0022] Figure 4 It is the block diagram of the state-based programmable data plane system with prediction execution provided according to the embodiment of the present application;

[0023] Figure 5 A structure diagram of a scheduling module provided according to an embodiment of the present application is provided.

[0024] Figure 6 A state diagram of a finite state machine under bounded staleness consistency provided according to an embodiment of the present application is provided. DETAILED DESCRIPTION

[0025] Embodiments of the present application are described in detail below with reference to the accompanying drawings. The embodiments of the present application, which are shown in the drawings, are examples and are intended to explain the present application, and cannot be understood as limiting the present application.

[0026] A stateful programmable data plane system and chip based on prediction execution provided by an embodiment of the present application are described below with reference to the accompanying drawings. In view of the problems mentioned in the above background, the present application provides a stateful programmable data plane system based on prediction execution, which adds a simple side ring to the pipeline, so that each pipeline stage is connected thereto. On the side ring, the data flow is opposite to the direction of the pipeline, providing a fast backward communication path. The read processor reads the state required by the stateful packet, and the write processor writes back the state required to modify the stateful packet, so that the state can be written back across stages. The whole process is very convenient and efficient, and supports complex stateful functions, thereby reducing the development cost, deployment cost and maintenance cost of in-network computing applications as a whole. Thus, the problem that the pipeline technology in the related art cannot support relatively complex stateful operations and has high development cost and the like is solved.

[0027] Before introducing the specific content of the present application, the related technologies involved in the present application are described in detail, including the following:

[0028] 1. Related art

[0029] As shown in Figure 1 , Banzai is a technical prototype of the programmable switch Tofino launched by Intel. Users program the protocols and functions carried by Tofino by writing a protocol-independent language, and operate the flow table and state table on the chip through the runtime software provided by Intel. As shown in Figure 1As shown, Banzai parses the header fields of incoming data packets using a programmable parser and processes the headers through two pipelines: an inlet pipeline and an outlet pipeline. These two identical pipelines constitute Banzai's programmable packet processing logic. Each pipeline consists of a series of stages, namely the Match-Operation Table (MAT), which is the basic programmable unit of this prototype. Users program the MAT in two ways using a protocol-independent language: which flow table the data packet needs to query at that stage, and what processing logic should be executed after the query results are obtained.

[0030] In Banzai, the processing logic at each stage is performed using a set of parallel atomic operations. The circuitry used for these atomic operations is as follows: Figure 2 As shown, it can perform a "read-add / subtract-write-back" function. The object of an atomic operation can be a field in the packet header or a register in the state table. However, due to the simplicity of atomic operations, only simple stateful functions (e.g., counters) can be implemented using atomic operations. For more complex functions, the logic for determining the next state may involve a series of operations and table accesses, which cannot be implemented using atomic operations. To avoid pipeline bottlenecks, this technical solution cannot support these stateful functions simply by extending the atomic operation circuitry or enhancing the atomic operation functionality. Due to the unidirectional nature of the pipeline, there is no effective mechanism to write state data back to an earlier stage. The only way is to re-loop (i.e., resend the packet to the pipeline header for processing again), but this method may disrupt the order of packets in the same stream within the pipeline, resulting in unavoidable read-after-write (WAR) conflicts and causing state consistency problems (i.e., reading outdated states).

[0031] 2. Related Technology II

[0032] Distributed Reconfigurable Matching Tables (dRMTs) utilize multi-core, multi-threaded Run-to-Complete (RTC) processors that support stateful functionality. dRMTs decouple on-chip memory from the processor, allowing the processor to access memory resources in the memory cluster via the switching network, such as... Figure 3 As shown. If dRMT uses shared memory to store the state table, it needs to handle state consistency issues through access scheduling and locking, leading to unpredictable wait times on some processors. This undermines the deterministic latency assumption presupposed by its integer linear programming-based compilation algorithm, making the program uncompilable. If each processor maintains its own copy of the state table, it requires complex synchronization mechanisms and consumes a large amount of additional memory.

[0033] 3. Related Technologies

[0034] FlowBlaze uses a queue and scheduling mechanism to guarantee state consistency. In each stage of FlowBlaze, a packet queries whether its flow is being processed in the current stage in a separate flow context table; once a packet enters the stateful function processing flow (matches and executes operations on the ESFM table), FlowBlaze blocks subsequent packets of the same flow, thereby guaranteeing state consistency. The approach of FlowBlaze actually assumes that all packets entering the stateful function may change the state, which may cause the pipeline to stall and thus cause a performance bottleneck. In fact, the stateful function may only be applied to a subset of flows; different flows under stateful processing may access different states; and packets of the same flow may not change the state. This makes it less likely that consecutive packets read and update the same state. In addition, the additional flow context table and scheduling module will occupy a large chip area; FlowBlaze also cannot provide support for more complex stateful functions that cannot be completed through a single EFSM table.

[0035] Specifically, Figure 4 A block diagram of a stateful programmable data plane system based on predictive execution provided by an embodiment of the present application.

[0036] As Figure 4 shown, the stateful programmable data plane system based on predictive execution includes a plurality of stage processors, a side ring, a plurality of ring nodes, and the like.

[0037] Among them, the plurality of stage processors constitute a pipeline of data processing, and each stage processor processes a pipeline stage; the side ring includes a plurality of ring nodes, and the plurality of ring nodes are connected one by one with each stage processor; any stage processor in the plurality of stage processors is configured as a read processor or a write processor, the read processor reads the state required to be read by at least one stateful packet and predicts that the state of the stateful packet is unchanged; the write processor writes the state required to be written by the stateful packet, identifies the data packet that needs to be resubmitted due to modified state, uploads the data packet that needs to be resubmitted to the write processor corresponding ring node, sends it to the read processor corresponding ring node through the side ring, and the read processor downloads the data packet that needs to be resubmitted from the corresponding ring node.

[0038] In an embodiment of the present application, the stage processor includes a configurable scheduling module, wherein the configurable scheduling module of the read processor is configured as a read scheduling module, the configurable scheduling module of the write processor is configured as a write scheduling module, and the configurable scheduling module of other stage processors is not activated.

[0039] It can be understood that the present application embodiment proposes a low-cost and high-performance data plane architecture supporting cross-stage data write-back: RAPID (Ring-Augmented Pipeline Dataplane). The overall technical architecture of RAPID is shown in Figure 4 In RAPID, the present application embodiment can add a simple side ring to the pipeline and connect each pipeline stage to it. As a specific example, on the side ring, the data flow can be opposite to the direction of the pipeline, thereby providing a fast backward communication path. In addition, the data flow can be the same as the direction of the pipeline, or a bidirectional data path is adopted, that is, data can flow bidirectionally between adjacent nodes; a person skilled in the art can specifically select or set, and is not limited.

[0040] Secondly, the present application embodiment proposes a "local read-remote write" behavior abstraction in RAPID. For a complex stateful function, it involves a series of stage processors in the pipeline. The first processor in the series stores the flow state table, and the data packet reads the state on the first processor, and after processing by several processors, writes back the state across stages on the last processor in the series. The control signal, address and data of cross-stage write-back are transmitted by the last processor to its corresponding ring node, sent to the ring node corresponding to the first processor through the side ring, and then written into the state table stored by the first processor.

[0041] In order to ensure state consistency, a configurable scheduling module is installed on each stage processor of the present application embodiment, as shown in Figure 5 According to the user program, the module can be reconfigured as a read scheduling module or a write scheduling module. In a "local read-remote write" series of processors, the scheduling module on the read processor is configured as a read scheduling module, the scheduling module on the write processor is configured as a write scheduling module, and the scheduling module on the intermediate processor is not activated. With the data prefetching technology, the scheduling module is implemented as a bypass and is not inserted into the pipeline, so that the activated scheduling module does not introduce additional delay for pipeline processing. When the user program does not need cross-stage data write-back, the scheduling module and its connected side ring are lossless to the pipeline performance.

[0042] Further, the read scheduling module and the write scheduling module of the embodiment of the present application each include a dirty table stored in a content addressable memory, wherein the key matched in the dirty table is the state table index of a flow, the dirty table of the write scheduling module contains a table of keys, and the dirty table of the read scheduling module contains a table of keys and corresponding data; the write scheduling module writes a flow corresponding to a data packet in a modified state into the dirty table and sends a write-back control signal to the read scheduling module through a side ring, and the read scheduling module writes the flow corresponding to the data packet in the modified state into the dirty table according to the write-back control signal.

[0043] It can be understood that the read scheduling module and the write scheduling module of the embodiment of the present application are each installed with a small content addressable memory as a dirty table, for registering a "dirty" flow that is currently being processed with a state. The key matched in the dirty table is the state table index of a flow (for example, a hash value of a flow ID). The dirty table in the write scheduling module is a table containing only keys, and the dirty table in the read scheduling module further contains related data.

[0044] Further, the read processor of the embodiment of the present application further includes a re-submission buffer for saving data packets that need to be re-submitted, and the read scheduling module further includes a data packet buffer for saving data packets that hit the dirty table, and data packets of each flow are linked in a first chain table and a second chain table, the first chain table is used for storing newly arrived data packets on a pipeline, and the second chain table is used for storing data packets that need to be re-submitted.

[0045] In the embodiment of the present application, data packets of a flow not in the dirty table are processed without blocking, and data packets of a dirty flow that are re-submitted and blocked are only opportunistically scheduled in an idle pipeline period. Therefore, data packets that are re-submitted and blocked need a re-submission buffer (RB). Under normal traffic conditions, the load of a switch pipeline is light, and there are enough idle periods to process buffered data packets. Data packets newly arrived from the pipeline and hitting the dirty table in the read scheduling module are saved in a data packet buffer (PB) of the read scheduling module.

[0046] Wherein, the RB and the PB are both queues, and once the first data packet in the RB has an opportunity to enter the pipeline, it will be moved from the RB to the PB. Data packets of each flow in the PB are linked in two chain tables, which are a first chain table (NL) for storing newly arrived data packets on the pipeline and a second chain table (RL) for storing re-submitted data packets. Metadata of the two chain tables is maintained in the dirty table, and the link pointer of each chain table node is stored by a dedicated register group.

[0047] Second, to guarantee state consistency, the order in which the data packets of a flow are processed by the state function should be the same as the order in which they arrive at the switch. To maintain the order of the data packets, the read scheduling module of the embodiment of the application further comprises an order maintaining checking module for scheduling the data packets of the data packet buffer and detecting whether all the data packets of the flow to which the data packet to be scheduled belong have arrived at the re-submission buffer and have all been moved to the second linked list (RL) of the data packet buffer when the data packet of the data packet buffer is scheduled.

[0048] The read scheduling module can only schedule the data packets of a flow in the PB under the following conditions:

[0049] Condition (1) : there is no data packet of the flow on the pipeline between the local read and the remote write, i.e. all have been re-submitted to the RB;

[0050] Condition (2) : all the data packets of the flow that need to be re-submitted in the RB have been moved to the PB.

[0051] Condition (2) can only be met after condition (1) is met. Condition (2) is guaranteed by the re-submission data packet counter maintained in the dirty table. The corresponding counter is increased each time the RB receives a data packet that needs to be re-submitted and is decreased each time a data packet that needs to be re-submitted is moved from the RB to the PB. A counter value of 0 means that condition (2) is met. When a flow meets both (1) and (2), the RL is inserted in its entirety before the NL to be scheduled, and the new RL is reset to an empty linked list.

[0052] Further, the embodiment of the application designs two different checking schemes for condition (1) to ensure that the data packets read from the stale state before the data packets of a flow in the PB are scheduled have all been re-submitted to the read processor, which are as follows:

[0053] Scheme 1 : a timer-based solution, in which a timer is started until it expires, determining that all the data packets that need to be re-submitted have arrived at the re-submission buffer.

[0054] Specifically, the timer-based solution maintains a timer field on the dirty table of the read scheduling module. When the read scheduling module receives a remote write signal sent back, the flow corresponding to the data packet with the modified state is written to the dirty table, and the timer is started. The timer is a countdown that continuously decreases over time, and when the timer expires, it means that enough time has passed for all the data packets sent out previously to return to the RB.

[0055] Because the pipeline of the data plane is not blocked, the time of a data packet between reading locally and writing remotely on the pipeline only relates to the pipeline parameters and the number of stages between them, which is a constant (in the number of master clock cycles) that a compiler can determine. At the same time, the time of a data packet from the write processor to the read processor via the side ring without being blocked is also determined in advance by the compiler. The timer is initialized to the sum of the two values when it starts, so if there is no blocking on the side ring, the value of the timer advances by 1 time per cycle, which can exactly guarantee that all data packets previously sent reach the RB.

[0056] As can be seen, the timer-based solution guarantees that the value of the timer only decreases in a non-blocking cycle by designing the communication protocol on the side ring, so that in the case of blocking on the side ring, it can still be guaranteed that all data packets previously sent reach the RB when the timer times out. The side ring can transmit three signals: cross-stage state write back, data packets that need to be resubmitted, and a cleaning signal. In addition to the control tags, addresses, and data buses required by the three signals, the bus on the side ring of the embodiment of the application additionally adds a field to represent the heartbeat address.

[0057] The heartbeat address is a bitmap, and each bit corresponds to a stage on the chip. The write scheduling module continuously sends heartbeats to the read scheduling module, because the heartbeat of each pipeline stage only occupies one bit of the heartbeat address field, and the heartbeat address field is independent of other fields in the bus, so any signal (when the bus is idle, it is considered an empty signal) can carry any number of heartbeats at the same time. At each ring node on the side ring, the signals from the side ring compete with the signals uploaded to the ring node by the current stage. In addition to the empty signal, which is discarded directly, the other signals are stored in the queue buffer in two directions, and the bus is arbitrated by the scheduler. When the signal carrying the heartbeat is blocked at a certain ring node, it will cause the read scheduling module to fail to receive the heartbeat in a cycle. The timer of the read scheduling module advances by 1 time only when it receives the heartbeat, thereby achieving accurate timing. Whether the idle cycle is blocked does not affect the accuracy of timing, and the heartbeat carried by the empty signal can be directly handed over to another signal when it is discarded.

[0058] Solution 2: The counter-based solution, the order-preserving checking module of the embodiment of the application is further configured to write the sequence number of each data packet into the counter table at the reading state of each data packet; and if the sequence number of the data packet that needs to be resubmitted is equal to the sequence number in the counter table, it is determined that the data packet that needs to be resubmitted has all arrived at the read processor.

[0059] In particular, the counter-based solution adds a small amount of memory at each pipeline stage. These memories are used to store the counter table on the read processor, and the dirty table is modified by the read scheduler module when it receives a remote write signal back, writing the corresponding flow for the packet with modified state. The counter table maintains a sequence number for each flow. A metadata field is used to store the sequence number for each packet, which is written and incremented when the packet enters the pipeline, while the sequence number maintained by the counter table is the maximum sequence number of the passing in-flight packets. The sequence number of the packet that needs to be resubmitted is compared with the sequence number in the local counter table, and if they are equal, it means that all the previously issued packets have returned to the RB.

[0060] It should be noted that the above two solutions correspond to two different use scenarios. The timer-based solution only needs to add an additional field in the dirty table, and has advantages in chip area and power consumption; the counter-based solution is relatively simple to implement and does not depend on accurate counting of time, and has better scalability.

[0061] In an embodiment of the present application, the read processor is further configured to, when a packet of a flow in the packet buffer starts to be scheduled, write a clean-up signal to the corresponding ring node, send the clean-up signal to the corresponding ring node of the write processor through the side ring, and download the clean-up signal to the write processor; and the write processor is configured to remove the corresponding flow from the dirty table according to the clean-up signal.

[0062] It can be understood that when the write scheduling module finds that a certain packet will cause the state of its flow to change (i.e., a remote write is triggered), the flow will be registered in the dirty table of the write scheduling module. When the write-back control signal arrives at the target processor from the side ring, the read scheduling module on the processor is simultaneously notified to register the flow in its own dirty table. Subsequent packets that hit the dirty table of the write scheduling module indicate a prediction error, and the packets will be uploaded to the side ring, re-sent to the read processor, and re-enter the local read-remote write in-flight state processing procedure. On the read processor side, the flows registered in the dirty table of the read scheduling module serve as a protective measure to prevent newly arrived packets of the flow from entering the stateful processing. During its residence, any packet of the flow that has been allowed to pass will undergo a prediction failure and be resubmitted to the read processor. When all the prediction-failed packets of a flow have been resubmitted, the read scheduling module sends a clean-up signal to notify the write scheduling module to remove the flow from its dirty table. After all the backlog packets have been sent, the flow will be removed from the local dirty table of the read scheduling module.

[0063] Because the dirty table records hash values instead of flow IDs themselves, there is a possibility of hash collision. In the case of hash collision, a flow that is actually not dirty can be hit by the dirty table, thus being blocked and re-submitted wrongly, causing a certain degree of performance loss. Under normal traffic and hash functions, the probability of hash collision is very low, and thus the impact of hash collision on the overall packet processing performance can be almost negligible.

[0064] In an embodiment of the present application, the read scheduling module includes first to third levels of state consistency, wherein the first level of state consistency includes that a read operation of a data packet is after write operations of all data packets before the data packet; the second level of state consistency includes that on a flow where a target data packet is located, read operations of K data packets after the target data packet are allowed to be before write operations of the K data packets, and starting from the K+1 data packet, a read operation of a data packet is after write operations of all data packets before the data packet; and the third level of state consistency includes that a read operation of a data packet is in any order with a write operation.

[0065] The first level of state consistency can be strong consistency, the third level of state consistency can be weak consistency, and the second level of state consistency can be bounded stale consistency. The target data packet can be any data packet, and a state of the flow where the target data packet is located is subject to the bounded stale consistency requirement. The preset number can be specified according to actual conditions, such as being set to K.

[0066] Specifically, it can not be worth the cost of performance loss to implement strong consistency for all applications, and thus embodiments of the present application can allow a user to specify a state consistency level of each application by himself / herself. Strong consistency means that a data packet is never allowed to read a stale state, i.e., a read operation of a data packet must be after write operations of all data packets before the data packet. Weak consistency means that a data packet is allowed to read a stale state, i.e., a read operation of a data packet can be in any order with a write operation. Bounded stale consistency means that at most K data packets are allowed to ignore reading of a stale state, and when K is reached, synchronization to a new state is required, where K is a constant specified by the user.

[0067] It can be understood that embodiments of the present application can use a prediction execution technique to process data packets. By default, a read processor always predicts that a data packet with a state will not modify its state. When a data packet does not modify a state, it will not cause a state consistency problem, and thus does not need to block processing of subsequent data packets, thereby not affecting packet processing performance of a switch chip. However, when a data packet needs to modify a state, it means that a previous prediction is wrong, and thus not only state data needs to be written back across stages, but also a state consistency guarantee mechanism needs to be triggered.

[0068] In particular, for strong consistency, every packet that hits the dirty table in the write scheduler module should be re-submitted. For weak consistency, when a packet causes a state change, only the new state is written back, and the flow is not registered in the dirty table, thus preventing re-submission of subsequent packets, which is applicable to scenarios where the state eventually converges even if some packets read stale state (e.g., a flow rate limiter).

[0069] For bounded-stale consistency, a finite state machine (FSM) is used to guide the behavior of the write scheduler module under bounded-stale consistency, as shown in Figure 6 In the "normal" state, a flow is not registered in the dirty table of the write scheduler module and can pass through without re-submission. When a packet causes a state change, the FSM transitions to the "about-to-expire" state, and a decreasing counter is initialized to K. In this state, up to K packets of the flow can pass through without re-submission. When the counter reaches 0, the FSM transitions to the "expired" state, and the flow is registered in the dirty table, starting a round of strict state synchronization. Only a clean-up signal from the read scheduler module can remove the flow from the dirty table of the write scheduler module and restore the state of the flow to the "normal" state.

[0070] In actual implementation, the embodiment of the present application can be based on P4_16 language, and enhanced by introducing a new abstract structure - muTable, which is equivalent to table in P4. Compared with table, muTable can be modified by the data plane, so it can be used to implement the flow state table. The user-written program can apply read and write primitives to the muTable object to customize the processing logic with state function. When compiling the application program, the compiler decides whether it can be implemented in a single stage or multiple stages according to the complexity of the state function with state. Simple state functions that can be implemented atomically will be compiled into a single stage, without enabling cross-stage data write-back function; complex state functions that cannot be implemented atomically will be compiled into multiple stages, using cross-stage data write-back implementation.

[0071] If the stateful processing involves modifying certain data (for example, reducing the TTL field in the IPv4 protocol), packet re-submission may cause the data to be modified multiple times, resulting in a write-after-read conflict, thus leading to incorrect results. The compiler uses the "field renaming" technique to solve this problem. For a field that is modified between local read and remote write, the compiler creates a copy of the field in the metadata. When reading the field between local read and remote write, only the location of the copy is read, and not the location of the field itself, which may have been modified once.

[0072] In summary, the application implements a low-cost and high-performance data plane structure to support complex stateful functions, and can offload more in-network computing applications from servers or middleboxes to programmable switches, thereby reducing the communication delay of in-network computing, reducing the use of network bandwidth, reducing the demand of network system on servers or middleboxes, simplifying the programming method of in-network computing application, and thereby reducing the development cost, deployment cost and maintenance cost of in-network computing application as a whole.

[0073] The stateful programmable data plane system based on prediction execution of the embodiments of the application will be described in detail below in combination with several specific application scenarios:

[0074] 1) Application scenario 1:

[0075] Load balancer (LB) is an indispensable function in cloud network. At present, more and more data centers use stateful LB to replace stateless LB. In stateful LB, client data packets are sent to a virtual target IP address, and the LB allocates a physical IP address for each data packet. If the input data packet finds an existing mapping from the flow where it comes from to the physical IP address in the state table, the address is used for forwarding; otherwise, a certain strategy or algorithm is applied to select a physical IP address for the data packet, and a new mapping from the data packet flow to the physical IP address is written back to the state table.

[0076] Determining the physical server for a newly arrived flow can require complex logic. The related art is to let the controller software loaded on the server make a decision, and then write the result back to the flow state table. Multiple forwarding and communication delays can cause pressure on the data packet buffer on the switch, thereby reducing the throughput. The embodiments of the application can offload the logic of determining the physical IP of the stateful LB to the data plane by cross-stage write-back, thereby effectively improving the LB performance.

[0077] 2) Application scenario 2:

[0078] DDoS attacks (such as DNS flooding, TCP SYN flooding and amplification attacks) have always been a major challenge for networks. Traditional server or middlebox-based solutions are costly and have limited throughput. The cross-stage data write-back function provided by the application provides a high-performance DDoS detection solution, which can be implemented on the data plane of the switch:

[0079] First, incoming packets are classified by accessing lists (e.g., blacklists, whitelists, and graylists for attack flows, normal flows, and suspicious flows, respectively), and then analyzed by a detection / analysis module according to the list search results. This module can be a sketch or a series of header field checks. If a packet on the whitelist is deemed suspicious, the decision module moves the corresponding flow from the whitelist to the graylist by updating the list. Similar moves between other lists are also possible.

[0080] 3) Application Scenario 3:

[0081] Traffic shaping and policy control are crucial in enforcing quality of service (QoS) policies and ensuring optimal bandwidth allocation. In this process, packets are first classified according to user-defined header fields, and then evaluated by some rate control or scheduling algorithm according to the current queue or link state. Next, packets are queued or dropped, and the queue state is updated (i.e., written back to the evaluation module). In this case, the write-back will be from the egress pipeline to the ingress pipeline. Since the pioneering work of PIFO, many efforts have been made to make packet scheduling programmable. However, most of them cannot avoid cross-stage data write-back. On today's pipeline-based chips, these schemes have to use packet recirculation or approximation methods, which affect the scheduling performance or accuracy.

[0082] 4) Application Scenario 4:

[0083] Stateful firewalls can use finite state machines to track and monitor active network connections and detect malicious traffic based on flow context. Compared with stateless firewalls, it provides higher security and stronger attack mitigation capabilities. In a stateful firewall, the state table is first checked to determine whether the packet belongs to an existing connection. If so, the connection state and related timeout value are updated; otherwise, the packet is evaluated according to the predefined firewall rules to determine whether the connection should be allowed or denied, and the matching rule is applied. If a new connection is allowed, the state table is updated with the connection information (e.g., flow ID and connection state). Due to the complex state transitions and message passing between different modules, if this scheme is to be implemented on a pure data plane pipeline, the cross-stage data write-back support provided by the present application is also needed.

[0084] 5) Application Scenario 5:

[0085] Top-K flow detection can be used for traffic-aware routing, traffic engineering, and real-time network monitoring. Since the hash tables used by Top-K flow detection exceed the storage space of a single pipeline stage, in order to use Top-K detection in the data plane, the tables need to be distributed across stages. Packets first need to go through each stage to get the appropriate location, and then write data back to the selected stage. In current pipeline devices, such operations have to resort to a controller or packet recirculation. The cross-stage data writeback provided by the present application can make the process very convenient and more efficient.

[0086] The stateful programmable data plane system based on prediction execution provided by the embodiments of the present application adds a simple side ring to the pipeline, so that each pipeline stage is connected with it. On the side ring, the data flow is opposite to the direction of the pipeline, providing a fast backward communication path. The read processor reads the state required by the stateful packet, and the write processor can cross-stage write back the state when writing back the packet that needs to modify the state. The whole process is very convenient and more efficient, and supports complex stateful functions, thereby reducing the development cost, deployment cost and maintenance cost of in-network computing applications as a whole. Thus, the problem of the pipeline technology in the related art that cannot support relatively complex stateful operations and has high development cost is solved.

[0087] In addition, the embodiments of the present application also provide a programmable switch chip, which comprises the stateful programmable data plane system based on prediction execution of the above embodiments.

[0088] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms is not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples without contradiction.

[0089] In addition, the terms "first", "second" are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "N" is at least two, for example, two, three, etc., unless otherwise explicitly specified.

[0090] Although the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are exemplary and are not to be construed as limiting the present application, and that changes, modifications, substitutions and variations can be made by those skilled in the art without departing from the scope of the present application.

Claims

1. A stateful programmable data plane system based on predictive execution, characterized in that, The application relates to a data processing system, comprising: a plurality of stage processors, wherein the plurality of stage processors constitute a pipeline of data processing, each stage processor processes one pipeline stage, and each stage processor is configured as a read processor or a write processor; a side ring, wherein a plurality of ring nodes are arranged on the side ring, and the plurality of ring nodes are connected to the stage processors one by one; any stage processor in the plurality of stage processors is configured as a read processor or a write processor, the read processor reads the state required by at least one stateful data packet and predicts that the state of the stateful data packet is unchanged, the write processor writes the state required by the stateful data packet, identifies a data packet that needs to be resubmitted due to modified state, uploads the data packet to a ring node corresponding to the write processor, and sends the data packet to a ring node corresponding to the read processor through the side ring, and the read processor downloads the data packet from the ring node.

2. The prediction execution based state programmable data plane system of claim 1, wherein, The stage processor comprises a configurable scheduling module, wherein the configurable scheduling module of the read processor is configured as a read scheduling module, the configurable scheduling module of the write processor is configured as a write scheduling module, and the configurable scheduling modules of other stage processors are not activated.

3. The prediction execution based state programmable data plane system of claim 2, wherein, The read scheduling module and the write scheduling module each comprise: a dirty table stored in a content addressable memory, and the key matched in the dirty table is a state table index of a flow, wherein the dirty table of the write scheduling module comprises a key table, and the dirty table of the read scheduling module comprises a key table and corresponding data; the write scheduling module writes a flow corresponding to a data packet with modified state into the dirty table, and sends a write-back control signal to the read scheduling module through the side ring, and the read scheduling module writes the flow corresponding to the data packet with modified state into the dirty table according to the write-back control signal.

4. The prediction execution based state programmable data plane system of claim 3, wherein, The read processor further comprises a resubmission buffer for saving resubmitted data packets, and the read scheduling module further comprises: a data packet buffer for saving data packets that hit the dirty table, and data packets of each flow are linked in a first chain table and a second chain table, the first chain table is used for storing newly-arrived data packets on the pipeline, and the second chain table is used for storing the data packets that need to be resubmitted; a sequence preserving checking module for scheduling data packets in the data packet buffer, and detecting whether data packets that need to be resubmitted in a flow to which the data packets belong have all arrived at the resubmission buffer and have all been moved to the second chain table of the data packet buffer when the data packets are scheduled.

5. The prediction execution based state programmable data plane system of claim 4, wherein, The sequence preserving checking module is further used for: starting a timer, and determining that the data packets that need to be resubmitted have all arrived at the resubmission buffer when the timer expires.

6. The prediction execution based state programmable data plane system of claim 5, wherein, A heartbeat address field is arranged on a bus of the side ring, the heartbeat address field is independent of other fields on the bus, each pipeline stage occupies one bit of the heartbeat address field, and a signal carrying a heartbeat is written into the heartbeat address field; the timer advances by 1 time unit when the signal carrying the heartbeat is received from the corresponding write processor.

7. The prediction execution based state programmable data plane system of claim 4, wherein, The order-preserving checking module is further configured to: write the sequence number of each data packet into a counter table at each data packet read state; if the sequence number of the data packet needing resubmission is equal to the sequence number in the counter table, determine that the data packet needing resubmission has all arrived at the resubmission buffer.

8. The prediction execution based state programmable data plane system of claim 4, wherein, The read processor is further configured to write a clean signal into a corresponding ring node through the side ring to a corresponding ring node of the write processor and download to the write processor when data packets of one flow in the data packet buffer start to be scheduled; the write processor removes the corresponding flow from the dirty table according to the clean signal.

9. The prediction execution based state programmable data plane system of claim 4, wherein, The read scheduling module includes first to third levels of state consistency, wherein, the first level of state consistency includes that read operations of data packets are after write operations of all data packets before the data packets; the second level of state consistency includes that on a flow where a target data packet is located, read operations of K data packets after the target data packet are allowed to be before write operations of the K data packets, and from the K+1 data packet, read operations of data packets are after write operations of all data packets before the data packets; the third level of state consistency includes that read operations of data packets are in any order with write operations.

10. A programmable switch chip, comprising: A state programmable data plane system based on predictive execution, including the system as claimed in any one of claims 1-9.

Images