Method and device for updating programmable data plane at runtime

Abstract

The present application relates to the field of computer network technology, and in particular to a method and device for updating protocols, updating functions, inserting and deleting flow tables, and modifying flow table specifications at runtime in a programmable data plane. The method includes: based on a distributed on-demand parser, splitting a parsing graph into multiple parsing subgraphs, and distributing each parsing subgraph to each corresponding physical stage in the pipeline; based on a template processor and a virtual pipeline, directly configuring the processor function through configuration parameters, and adjusting the order between any two processors by configuring the interconnection network according to the insertion instruction; based on a decoupled resource pool, separating and pooling the flow table resources of each physical stage, and creating a new flow table, recycling a flow table, or modifying the flow table specifications at runtime; updating the configuration of the processor and deleting an empty processor. Thus, the problem of how to freely add, delete, and modify protocols, freely configure functions, create flow tables, recycle flow tables, and modify flow table specifications at runtime is solved.

Description

Technical Field

[0001] The present application relates to the field of computer network technology, and in particular to a method and device for updating a programmable data plane at runtime. Background Art

[0002] With the development of the concept of SDN (Software Defined Networking), programmable switches have gradually become commercially available and have become mainstream. The core of programmability is the programmable data plane, which is responsible for protocol parsing and reverse parsing, data packet processing, and the external controller is responsible for issuing parsing rules and flow table matching rules. Programmability has brought major changes to the relationship between equipment suppliers and network operators.

[0003] When launching new features on programmable devices, operators do not need to wait for the years-long release cycle of traditional network equipment, and network operators can use the programming interface of programmable devices to directly and quickly deploy new features. However, different types of networks require different sets of features, new protocols and functions are constantly emerging, and the network environment's demand for throughput is increasing. It is becoming increasingly uneconomical to integrate all the required features and functions into a single chip. In the future, the network is expected to develop towards autonomy, with self-configuration, self-diagnosis, and self-healing capabilities, which will make network operations more dynamic and automated.

[0004] However, in an increasingly volatile network environment, the programmable data plane needs to have runtime programmability, that is, the ability to update data plane functions and protocols and add, delete, and modify flow tables at runtime without interrupting services. Summary of the invention

[0005] The present application provides a method, device, electronic device and storage medium for updating a programmable data plane at runtime to solve the problems of how to freely add, delete and modify protocols, freely configure functions, create flow tables, recycle flow tables and modify flow table specifications at runtime.

[0006] The first aspect of the present application provides a method for updating a programmable data plane at runtime, wherein the programmable data plane includes a distributed on-demand parser, a template processor, a virtual pipeline, a decoupled resource pool, and a fast update controller, wherein the method includes the following steps: based on the distributed on-demand parser, splitting a parsing graph into multiple parsing subgraphs, and distributing each parsing subgraph to each corresponding physical stage in the pipeline, wherein the parsing subgraph of each physical stage is used to indicate a local parsing process, and at runtime, parse out a user-specified protocol, and configure the parsing subgraph to perform an add protocol action, a delete protocol action, and / or a modify protocol action at a target physical stage; based on the template processor, The invention relates to a method for adjusting the order between any two processors by configuring an interconnection network according to an insertion instruction, wherein any processor among all template processors serves as a physical stage of an inlet pipeline or a physical stage of an outlet pipeline; performing free configuration actions by configuring parameters of the template processor; separating and pooling the flow table resources of each physical stage based on the decoupled resource pool, and creating a new flow table, recycling a flow table or modifying the specifications of the flow table at runtime; pausing the data packet processing before the template processor that needs to be updated based on the fast update controller, and configuring the template processor or deleting the template processor from the pipeline when there is no data packet in the template processor.

[0007] Furthermore, the method further includes: placing the template processor in a preset low power consumption mode when the template processor is not inserted into the pipeline for execution.

[0008] Furthermore, the execution of the free configuration action includes: by separating primitives and parameters, each physical stage is a general skeleton composed of primitives, so that when the user configures, the corresponding parameters are downloaded to the skeleton according to the added functions.

[0009] Furthermore, before separating and pooling the flow table resources of each physical stage, the method further includes: interconnecting the physical stage and the storage resources using a statically reconfigurable cross switch so as to reconfigure the cross switch when the template processor or the flow table is updated.

[0010] Furthermore, based on the fast update controller, the data packet processing before the template processor that needs to be updated is suspended. When the template processor has no data packet, the template processor is configured or deleted from the pipeline. When configuring the template processor, the template processors that need to be updated are configured sequentially downward along the pipeline, wherein the data packet processing before the first template processor that needs to be configured is suspended. When the template processor has no data packet, the template processor is configured, and the template processors that need to be updated are configured sequentially downward along the pipeline; after the configuration is updated, all template processors with empty configurations are deleted downward along the pipeline, wherein when deleting the template processor with empty configuration, the data packet processing before the template processor with empty configuration is suspended, and when the data in the template processor with empty configuration is empty, the template processor with empty configuration is deleted from the pipeline by configuring a configurable cross switch.

[0011] Furthermore, the programmable data plane also includes a pipeline-by-pipeline update controller, and also includes: based on the pipeline-by-pipeline update controller, updating the pipelines in the data plane one by one, when updating any pipeline configuration, pausing data packets from entering any pipeline, when there is no data packet in any pipeline, updating any pipeline, and after the update is completed, the data packet enters any pipeline normally, and selects the pipeline that has not been updated for updating.

[0012] According to a second aspect of the present application, there is provided an apparatus for updating a programmable data plane at runtime, wherein the programmable data plane includes a distributed on-demand parser, a template processor, a virtual pipeline, a decoupled resource pool, and a fast update controller, wherein the apparatus includes: a parsing module for splitting a parsing graph into a plurality of parsing subgraphs based on the distributed on-demand parser, and distributing each parsing subgraph to each corresponding physical stage in the pipeline, wherein the parsing subgraph of each physical stage is used to indicate a local parsing process, and parse out a user-specified protocol at runtime, and configure the parsing subgraph to perform an add protocol action, a delete protocol action, and / or a modify protocol action at a target physical stage; a processing module for performing a parsing operation based on the template processor and the physical stage; The virtual pipeline adjusts the order between any two processors by configuring the interconnection network according to the insertion instruction, wherein any processor among all the template processors serves as the physical stage of the inlet pipeline or the physical stage of the outlet pipeline; the free configuration action is performed by configuring the parameters of the template processor; the storage module is used to separate and pool the flow table resources of each physical stage based on the decoupled resource pool, and to create a new flow table, recycle the flow table or modify the specifications of the flow table at runtime; the fast update module is used to suspend the data packet processing before the template processor that needs to be updated based on the fast update controller, and when the template processor has no data packet, configure the template processor or delete the template processor from the pipeline.

[0013] Furthermore, it also includes: a setting module, which is used to put the template processor into a preset low power consumption mode when the template processor is not inserted into the pipeline for execution.

[0014] Furthermore, the processing module is further used to separate primitives and parameters, and form a general skeleton composed of each physical stage as a primitive, so that when configured by the user, corresponding parameters can be downloaded into the skeleton according to the added functions.

[0015] Furthermore, it also includes: a cross switch module, which is used to interconnect the physical stage and the storage resources using a static reconfigurable cross switch before separating and pooling the flow table resources of each physical stage, so as to reconfigure the cross switch when the template processor or the flow table is updated.

[0016] Furthermore, the fast update module is further used to: when configuring the template processor, sequentially configure the template processors that need to be updated along the pipeline downward, wherein the data packet processing before the first template processor that needs to be configured is suspended, and when there is no data packet in the template processor, configure the template processor, and sequentially configure the template processors that need to be updated along the pipeline downward; after updating the configuration, delete all empty-configured template processors along the pipeline downward, wherein when deleting the empty-configured template processor, the data packet processing before the empty-configured template processor is suspended, and when the data in the empty-configured template processor is empty, the empty-configured template processor is deleted from the pipeline by configuring a configurable cross switch.

[0017] Furthermore, the programmable data plane also includes a pipeline-by-pipeline update controller, and also includes: a pipeline-by-pipeline update module, which is used to update the pipelines in the data plane one by one based on the pipeline-by-pipeline update controller, and when updating any pipeline configuration, pausing data packets from entering any pipeline, and when there is no data packet in any pipeline, updating any pipeline, and after the update is completed, the data packet enters any pipeline normally, and selects the pipeline that has not been updated for updating.

[0018] The third aspect of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for updating the programmable data plane at runtime as described in the above embodiment.

[0019] The fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the method for updating the programmable data plane at runtime as described in the above embodiments.

[0020] Therefore, this application has at least the following beneficial effects:

[0021] Protocols can be added, deleted, and modified at runtime, which is beneficial for users to test or deploy new protocols, and to delete outdated or redundant protocols; functional logic can be added, deleted, and modified at runtime. For network devices that provide multi-tenant application services, network operators can add new user services without affecting other users, or directly delete the functions of a user when the service of a user expires; flow tables can be created, recycled, and flow table specifications can be modified at runtime to improve the utilization rate of storage resources in network devices. This solves the problems of how to freely add, delete, and modify protocols, freely configure functions, create flow tables, recycle flow tables, and modify flow table specifications at runtime.

[0022] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] Figure 1 This is the RMT technical architecture diagram in the related technology;

[0025] Figure 2 This is the dRMT technical architecture diagram in the related technology;

[0026] Figure 3 The overall architecture diagram of IPSA provided according to the embodiment of the present application;

[0027] Figure 4 A flowchart of a method for updating a programmable data plane at runtime according to an embodiment of the present application;

[0028] Figure 5 A schematic diagram of the structure of a distributed on-demand parser provided according to an embodiment of the present application;

[0029] Figure 6 A schematic diagram of the structure of a template processor provided according to an embodiment of the present application;

[0030] Figure 7 A schematic diagram of a virtual pipeline provided according to an embodiment of the present application;

[0031] Figure 8 A schematic diagram of a decoupled resource pool provided according to an embodiment of the present application;

[0032] Fig. 9 A schematic diagram of a runtime programming process provided according to an embodiment of the present application;

[0033] Fig.10 This is an example diagram of non-interruption updating provided according to an embodiment of the present application;

[0034] Fig.11 A block diagram of a device for updating a programmable data plane at runtime provided according to an embodiment of the present application;

[0035] Fig.12 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0036] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0037] In the related art, RMT (Reconfigurable Match Tables) is the technical prototype of the existing programmable switch Tofino, such as Figure 1 As shown in the figure, RMT provides the underlying abstraction of "parser-pipeline-inverse parser". Users can program the underlying architecture by writing a protocol-independent language P4 program, so as to achieve the programmable goal of freely customizing the protocol, flow table and function of the device. The programmable parser specifies the parsing state transition diagram by the user before running. After the data packet arrives at the ingress port, the parser parses out the protocol and field; the pipeline consists of a series of serial physical stages, each of which contains multiple MAUs (Match Action Units). MAU is the basic reconfigurable unit of the prototype. Users can specify the flow table specification and action primitives in the P4 program to program the MAU, that is, what flow table the data packet needs to query in this physical stage, and what processing logic should be executed after the query result is obtained. MAU has different logical behaviors under different configurations, thereby realizing user-specific processing and forwarding functions; the programmable inverse parser reassembles the protocol into the data packet payload according to the protocol sequence specified by the user.

[0038] Based on RMT technology, network functions can be freely customized through the protocol-independent language P4 during design. However, after compilation and deployment, the underlying configuration of the programmable device is determined. Reconfiguration requires suspending packet processing, recompiling the program, downloading, and replacing the underlying configuration. For mainstream applications such as multi-tenant service updates, stateful application updates, and hot-swappable computing in the network, downtime configuration greatly affects service quality. According to statistics, a Tofino switch with 64 100G ports requires 50ms of downtime for updates, which will lose 37GiB of data at full speed, and it will take longer to re-download the flow table.

[0039] POF (Protocol-Oblivious Forwarding) uses the abstraction of "offset + length" to represent a protocol, downplaying the specific content of the protocol, eliminating the dependency between protocols, and achieving complete protocol independence, thereby realizing a programmable data plane, and users can freely customize their own protocols. At the same time, POF uses a specific instruction set to adapt to the "offset + length" protocol abstraction, enhance the data plane's packet processing capabilities, and use simple instruction switching to achieve functional updates. In POF, each function is a module, and users can hot-swap the module through programming and the underlying instruction set to achieve runtime reconfiguration. However, the processing speed of POF implemented on a software network processor is far slower than that of an ASIC hardware switch, and therefore cannot be used on a large scale.

[0040] Based on RMT, dRMT (disaggregated Reconfigurable Match-Action Table) decouples flow table resources from packet processing logic resources. The processor accesses the flow table resources in the memory cluster through the switching network. Figure 2 As shown. Different from the RMT pipeline packet processing method, dRMT uses a multi-processor parallel method to process packets. Each processor contains a complete packet processing program, and uses a scheduler to avoid memory access conflicts between different processors. dRMT builds a flow table resource pool, which solves the problem that a physical stage in RMT cannot accommodate a large flow table, improves the programmability of the data plane, and supports more network applications; at the same time, dRMT's resource pooling approach is conducive to runtime reconfiguration, that is, creating flow tables, recycling flow tables, and modifying flow table specifications at runtime. However, dRMT adopts the "Run-to-Completion" (RTC) packet processing mode, which essentially does not support runtime modification of protocols, functions, and flow tables. The system design of dRMT does not involve runtime reconfiguration and cannot provide users with a runtime reconfiguration interface.

[0041] To this end, the embodiments of the present application propose a method and device for implementing a programmable switching chip and fast, non-interruptible update during runtime, which mainly solve the following three technical problems:

[0042] (1) How to design the underlying architecture so that the device can support runtime updates of protocols, packet processing functions, and flow tables, that is, adding, deleting, and modifying protocols, adding, deleting, and modifying packet processing logic, creating flow tables, reclaiming flow tables, and modifying flow table specifications at runtime;

[0043] (2) How to support users to perform runtime reconfiguration of the runtime reconfiguration data plane;

[0044] (3) How to quickly and without interruption update the underlying equipment.

[0045] The following will describe the update method, device, electronic device and storage medium of the programmable data plane at runtime of the embodiment of the present application with reference to the accompanying drawings. The programmable data plane includes a distributed on-demand parser, a template processor, a virtual pipeline, a decoupled resource pool and a fast update controller, wherein the fast update controller is responsible for controlling the update of the template processor and the update of the entire pipeline. Specifically: In order to solve the problem of updating the data plane protocol, function and flow table specifications at runtime, the embodiment of the present application proposes the following Figure 3 The programmable data plane IPSA (In-situ Programmable Switch Architecture) shown can enable the data plane to support runtime updates. IPSA is mainly composed of four parts: distributed on-demand parser, template processor, virtual pipeline, and decoupled resource pool.

[0046] The following will be combined Figure 4 A method for updating a programmable data plane at runtime is described, including the following steps:

[0047] In step S101, based on the distributed on-demand parser, the parsing graph is split into multiple parsing sub-graphs, and each parsing sub-graph is distributed to each corresponding physical stage in the pipeline, wherein the parsing sub-graph of each physical stage is used to indicate the local parsing process, and parse out the user-specified protocol at runtime, and configure the parsing sub-graph to perform adding protocol actions, deleting protocol actions and / or modifying protocol actions in the target physical stage.

[0048] It can be understood that the embodiments of the present application can configure the parsing subgraph of a specific template processor to execute the action of adding a protocol, deleting a protocol and / or modifying a protocol, and can add, delete and modify protocols at runtime, which is beneficial for users to test or deploy new protocols, while deleting outdated or redundant protocols, thereby solving the problem of freely adding, deleting and modifying protocols at runtime.

[0049] Specifically, modularization is the basis for realizing runtime programmability, because there may be multiple functions in the data plane, and adding, deleting, and modifying functional modules cannot affect the normal operation of other functions. In the related art, the protocol parsing is placed before all functions, which only realizes the decoupling of protocol parsing and functions, that is, vertical decoupling, resulting in relative coupling between multiple functions, which is not conducive to adding, deleting, and modifying a function separately.

[0050] The new architecture of the embodiment of the present application eliminates the front-end parser of the traditional programmable data plane, splits the complete parsing graph into sub-graphs and distributes them to each stage in the pipeline, ensuring the self-sufficiency of each pipeline stage and avoiding unnecessary parsing. The parsing cost is shared among the various stages of the pipeline, and the data plane throughput is not limited by the complexity of the parsing graph, making the design more scalable. When updating a function, if the relevant protocol is involved, only the functional module needs to be updated without affecting the normal operation of other functions.

[0051] like Figure 5 As shown in the figure, the parsing subgraph of each stage is used to indicate the local parsing process. What circulates in the pipeline is a fixed number of bytes of the data packet plus the parsing result. When it reaches the corresponding physical stage, the specified protocol will be parsed out. The parsing result is the indication information of each message header, that is, a set of two tuples of {message header ID, message header length}; when the field inside the message header is needed, the configuration parameter {field internal offset, field length} is used to obtain the field. The parsing result is passed to the subsequent stages to avoid unnecessary re-parsing. At runtime, if the user adds the IPv6 protocol to the physical stage 3, the data plane can support not only IPv4 routing, but also IPv6 routing. This design not only cancels the front-end parser but also avoids the reassembly of the message header by the back-end reverse parser.

[0052] In this embodiment, when the processing logic inserts or deletes the message header, it also includes: using the offset management module to update the parsing result.

[0053] It is understandable that in order to ensure the correctness of the transmitted information, when the message length changes (for example, the pushing and popping of the MPLS label), the offset management module is used to update the parsing result.

[0054] In step S102, based on the template processor and the virtual pipeline, the order between any two processors is adjusted by configuring the interconnection network according to the insertion instruction, wherein any processor among all the template processors serves as the physical stage of the inlet pipeline or the physical stage of the outlet pipeline; and the template parameters are configured to perform free configuration actions.

[0055] It can be understood that the embodiments of the present application can add, delete or modify functional logic at runtime. For network devices that provide multi-tenant application services, network operators can add new user services without affecting other users, or directly delete the user's functions when a user's service expires, thereby solving the problem of freely configuring functions at runtime.

[0056] It should be noted that, for the virtual pipeline, the implementation of the present application can use different types of interconnection networks, such as crossbars, CLOS, Bens, etc. to implement the virtual pipeline; different scales of interconnection networks can also be used to implement the virtual pipeline. For example, when there are 32 template processors, a 32*32 crossbar interconnection network is used, or two 16*16 crossbar interconnection networks are used, etc., so as to meet different resource consumption and flexibility requirements.

[0057] Specifically, each physical stage of the programmable data plane in the related art consists of two parts: field matching and logic execution, namely MAU. The embodiment of the present application adopts a distributed on-demand parser, such as Figure 6 As shown in the figure, each physical stage consists of three sub-modules: parser, matcher and executor. The functions of the matcher and executor are similar to the matching operation and execution operation in the RMT architecture. The parser is responsible for parsing the user-specified protocol and expressing {offset, length} in a protocol-independent format. The physical stages of the new architecture pipeline are loosely coupled, so the controller can program each physical stage separately.

[0058] In this embodiment, a free configuration action is performed, including: by separating primitives and parameters, each physical stage is a general skeleton composed of primitives, so that when the user configures, the corresponding parameters are downloaded to the skeleton according to the added functions.

[0059] Specifically, if Figure 6 In the embodiment of the present application, by separating primitives from parameters, each physical stage becomes a parameterized skeleton. The user configures the stage to add functions, which is equivalent to downloading the corresponding parameters into the skeleton. For the key elements required in each stage, the new architecture makes the following abstractions: (1) The message header field is abstracted as {offset, length} to achieve complete protocol independence; (2) The flow table is abstracted as {flow table type, flow table depth, flow table item width, matching key}, so that users can achieve the purpose of matching different flow tables by modifying the flow table abstraction; (3) The execution action is abstracted as a set of ordered execution primitives and execution parameters. Users can also configure the execution parameters to achieve the purpose of modifying the execution action. The embodiment of the present application calls this design a template-based stage processor (abbreviated as: Templated-based StageProcessor, TSP). TSP is a key part of implementing runtime updates and configurations.

[0060] Furthermore, after solving the problem of configuring a single TSP at runtime, it is necessary to solve the problem of flexible placement of physical stages on the entire pipeline. In view of the fact that the physical stages of the RMT architecture are hard-wired and cannot implement function insertion and deletion, the embodiment of the present application can adopt a virtual pipeline, that is, a reconfigurable non-blocking interconnection network (for example, a cross switch, a CLOS network, etc.) is used between the template processors TSP to achieve the normal operation of the pipeline. The processors in the RMT architecture are in a series relationship, which will have a negative impact on the insertion of new functions. When using a virtual pipeline, the order between the processors is floating, that is, the user can adjust the order between any two processors by configuring the interconnection network to achieve the purpose of flexibly inserting new functions.

[0061] like Figure 7 As shown in FIG. 1 , by adding the packet input / output module and the traffic management scheduler module to the interconnection network, any virtual pipeline can be dynamically generated, that is, any two template processors, the template processor and the packet input / output module, and the template processor and the traffic manager can be connected to each other. Figure 7 The pipeline order in is “input-TSP1-TSP4-TSP2-scheduler-TSP5-output”. Any template processor can be used as a physical stage of the ingress pipeline or as a physical stage of the egress pipeline, which improves the flexibility of the data plane ingress and egress design.

[0062] In this embodiment, the method of the embodiment of the present application also includes: when the template processor is not inserted into the pipeline for execution, placing the template processor in a preset low power consumption mode.

[0063] Among them, the preset low power consumption mode can be set according to actual conditions, and no specific limitation is made for comparison.

[0064] It will be appreciated that when the template processor has no pipeline stages executing, the processor may be placed in a low power mode.

[0065] In step S103, based on the decoupled resource pool, the flow table resources of each physical stage are separated and pooled, and during runtime, new flow tables are created, flow tables are recycled, or the specifications of flow tables are modified.

[0066] It can be understood that the embodiments of the present application can create flow tables, recycle flow tables, and modify flow table specifications at runtime, thereby improving the utilization rate of storage resources in network devices, thereby using a decoupled resource pool, and storage resource blocks can be freely combined to create new flow tables, solving the problem of creating flow tables, reclaiming flow tables, and modifying flow table specifications at runtime.

[0067] Specifically, updating the flow table at runtime refers to the flexible creation of flow tables, recycling flow tables, and modification of flow table specifications without interrupting existing traffic, rather than the addition, deletion, and modification of flow table items. In the programmable data plane architecture of the related art, storage resources (TCAM and SRAM) are evenly distributed among all physical stages, and the resources required for each stage may be different. Therefore, this resource allocation method has the disadvantages of uneven resource utilization and inability to perform incremental updates. In order to implement runtime update of flow tables, the embodiments of the present application can adopt the technology of decoupled storage resource pools to separate and pool the original flow table resources of each physical stage to improve the flexibility of flow table management; and the storage resource blocks are arbitrarily combined and split in the decoupled resource pool to implement runtime creation and recycling of flow tables.

[0068] In this embodiment, before separating and pooling the flow table resources of each physical stage, it also includes: interconnecting the physical stage and the storage resources using a static reconfigurable crossbar switch so that when the template processor or the flow table is updated, the crossbar switch can be reconfigured.

[0069] Specifically, if Figure 8 As shown, the embodiments of the present application can be based on the storage decoupling method, and the physical stage and the storage resources are interconnected using a static reconfigurable cross switch. The update of the template processor or the flow table requires reconfiguration of the cross switch. IPSA provides an interface for modifying the resource pool. When a new flow table needs to be created, the user controls the resource pool through the interface to create a new flow table, that is, to combine multiple SRAM blocks or TCAM blocks. For example, a flow table with a specification of 2w*4d is required, and the specification of each SRAM block is w*d, then 8 SRAM blocks need to be combined to implement the user-specified flow table. The same is true for deleting flow tables and modifying flow table specifications. In order to improve the scalability of the architecture, the template processor and storage resources are divided into multiple clusters, and each cluster has a "template processor-storage resource" cross switch. The one-to-one mapping relationship between the processor and the flow table avoids the problem of memory access conflicts.

[0070] Furthermore, after introducing the technical principles and system architecture of implementing the programmable data plane at runtime in the above embodiment, the network programming language and configuration interface for users to reconfigure at runtime will be described below, as follows:

[0071] In the related art, programmable switches support the P4 language to configure the underlying forwarding processing functions. When the switch is running, the runtime environment provided by P4 only supports the addition, deletion and modification of flow table items, and does not provide addition, deletion and modification of protocols, flow tables and logical processing functions. After designing the IPSA data plane, the embodiment of the present application expands the P4 language and designs the IPSA control plane. The overall programming process is as follows Fig. 9 As shown:

[0072] First, the P4 program written by the user is translated into an intermediate representation P4IR through the P4 front-end compiler, and then the intermediate representation is handed over to the rP4 compiler. First, the P4IR is translated into an rP4 file through the rP4 front-end compiler for runtime modification, and then the rP4 back-end compiler compiles rP4 into a json configuration file specific to the IPSA device and sends it to the IPSA data plane for execution. At runtime, the IPSA data plane provides users with an interface for adding, deleting, and modifying protocols, functions, and flow tables. Users write incremental rP4 code and corresponding configuration instructions. After compilation by the rP4 back-end compiler, the updated configuration is sent to the data plane, and the updated part is written back to the rP4 program for future updates.

[0073] rP4 language is an extension of P4 language. rP4 divides a physical stage into three parts: "parser-matcher-executor". Users can provide specific parameters for the templates of the three parts to support specific functions. At the same time, rP4 supports code snippet programming. Users can write specific functions into rP4 code snippets without considering constraints similar to P4, and load the functions represented by the code snippets into the underlying device through instructions.

[0074] In step S104, based on the fast update controller, the data packet processing before the template processor that needs to be updated is suspended, and when the template processor has no data packet, the template processor is configured or deleted from the pipeline.

[0075] It is understandable that the embodiments of the present application can be updated quickly and without interruption: the data plane functions, protocols and flow tables can be updated in the shortest possible time without interrupting normal data packet processing and forwarding in the process.

[0076] Among them, step S104 includes updating the configuration of the processor and deleting the empty processor. In this embodiment, step S104 includes: when configuring the template processor, configuring the template processors that need to be updated in sequence along the pipeline downward, wherein the data packet processing before the first template processor that needs to be configured is suspended, and when there is no data packet in the template processor, the template processor is configured, and the template processors that need to be updated are configured in sequence downward along the pipeline; after updating the configuration, deleting all template processors with empty configurations downward along the pipeline, wherein when deleting the template processor with empty configurations, the data packet processing before the template processor with empty configurations is suspended, and when the data in the template processor with empty configurations is empty, the template processor with empty configurations is deleted from the pipeline by configuring a configurable cross switch.

[0077] It can be understood that the embodiments of the present application can be based on a fast update controller to suspend the data packet processing before the template processor that needs to be updated in the pipeline, and update the template processor when there is a template processor with an empty configuration in the pipeline. In the same way, when the empty configuration processor has no data packet, the empty configuration processor is deleted from the pipeline by configuring a reconfigurable switching network.

[0078] Specifically, the IPSA architecture supports runtime updates of underlying functions, and uses the runtime interface provided by rP4 for users to make runtime modifications. In addition to the above, an update mechanism is also needed so that the update can take effect quickly and will not affect the normal operation of the traffic. Each function has a different mapping method in the underlying physical stage. A function may be mapped in one physical stage or in different physical stages. When mapped to multiple physical stages, these physical stages may be adjacent or non-adjacent. When updating a function, the consistency of data packet processing must be guaranteed, that is, the data packet is either processed by the new function or by the old function, and cannot be processed by part of the new function and part of the old function at the same time. The present invention proposes a bubble-based pipeline physical stage update scheme.

[0079] like Fig.10 As shown, TSP2 and TSP4 together constitute the source MAC address learning function. If the user wants to delete this function, first suspend the data packet processing before TSP2. After TSP2 processes the remaining data packets, TSP2 is empty, that is, the large bubble exists in TSP2. At this time, the internal configuration of TSP2 is deleted, and the previous processing of TSP2 is released. When the new data packet arrives at TSP2, it will no longer be processed by the original configuration; the large bubble located in TSP2 moves backward along the pipeline, and when it reaches the TSP to be updated, it is directly updated. In this way, the new data packet will not be processed by the old function, and the old data packet will not be processed by the new function. The large bubble update method proposed in this patent only needs to occupy (T+d) more capacity in the cache, T is the number of clock cycles to empty the TSP that needs to be updated, and d is the number of clock cycles to configure the TSP. In addition, the update method proposed in this patent also takes effect for (T+d) clock cycles.

[0080] After updating the configuration, you need to reorganize the pipeline, that is, delete the TSPs without configuration. Repeat the above operation, that is, when you want to delete a TSP, suspend the data packet processing before the TSP. During this period, the newly entered data packets are taken over by the cache. When the TSP to be deleted is empty, delete the TSP; follow the pipeline downward until all the TSPs with empty configurations are deleted. This step is updated as a background update and will not affect the normal processing of data packets.

[0081] Furthermore, the programmable data plane also includes a pipeline-by-pipeline update controller. The method of the embodiment of the present application also includes: based on the pipeline-by-pipeline update controller, updating the pipelines in the data plane one by one, when updating any pipeline configuration, pausing the data packet from entering any pipeline, when any pipeline has no data packet, updating any pipeline, and after the update is completed, the data packet enters any pipeline normally, and selects the pipeline that has not been updated for updating.

[0082] It can be understood that based on the pipeline-by-pipeline update controller, the user can select this update method to update the pipelines in the programmable data plane one by one. Specifically: first select a pipeline and pause the flow of data packets into the pipeline. When there is no data packet to be processed in the pipeline, update the configuration in the pipeline. After the update is completed, the data packet enters the pipeline normally; continue to select pipelines that have not been updated and repeat the above steps until all pipelines have completed the update.

[0083] In summary, the embodiments of the present application propose to use technologies such as distributed on-demand parsers, template-based stage processors, virtual pipelines, and decoupled resource pools to achieve runtime updates of the switch data plane, and propose a system architecture IPSA that supports runtime updates of protocols, functions, and flow tables; propose an rP4 language that extends the P4 language to provide an interface for runtime reconfiguration of protocols, functions, and flow tables; propose a large bubble-based pipeline update method to achieve real-time, uninterrupted updates of underlying devices.

[0084] According to the programmable data plane update method at runtime proposed in the embodiment of the present application, protocols can be added, deleted or modified at runtime, which is beneficial for users to test or deploy new protocols and delete outdated or redundant protocols at the same time; functional logic can be added, deleted or modified at runtime. For network devices that provide multi-tenant application services, network operators can add new user services without affecting other users, or directly delete the functions of a user when the service of a user expires; flow tables can be created, flow tables can be recycled, and flow table specifications can be modified at runtime to improve the utilization rate of storage resources in network devices; users perform runtime updates through rP4, which is an extension of P4, and users can implement runtime updates simply and conveniently; the update process will not affect the normal data packet processing process, and can implement real-time and uninterrupted updates, and functions take effect immediately.

[0085] Next, a device for updating a programmable data plane at runtime according to an embodiment of the present application will be described with reference to the accompanying drawings.

[0086] Fig.11 It is a block diagram of a device for updating a programmable data plane at runtime according to an embodiment of the present application.

[0087] The programmable data plane includes distributed on-demand parsers, template processors, virtual pipelines, decoupled resource pools, and fast update controllers, among which, Fig.11 As shown, the updating device 10 of the programmable data plane at runtime includes: a parsing module 100 , a processing module 200 , a storage module 300 and a fast updating module 400 .

[0088] Among them, the parsing module 100 is used to split the parsing graph into multiple parsing sub-graphs based on a distributed on-demand parser, and distribute each parsing sub-graph to each corresponding physical stage in the pipeline, wherein the parsing sub-graph of each physical stage is used to indicate the local parsing process, and parse the user-specified protocol at runtime to perform the action of adding protocol, deleting protocol and / or modifying protocol; the processing module 200 is used to adjust the order between any two processors by configuring the interconnection network according to the insertion instruction based on the template processor and the virtual pipeline, wherein the template processor serves as the physical stage of the inlet pipeline or the physical stage of the outlet pipeline; to perform free configuration actions; the storage module 300 is used to separate and pool the flow table resources of each physical stage based on the decoupled resource pool, and create a new flow table, recycle the flow table or modify the specifications of the flow table at runtime; the update module 400 is used to suspend the data packet processing before the template processor that needs to be updated based on the fast update controller, and when the template processor has no data packet, configure the template processor or delete the template processor from the pipeline.

[0089] Furthermore, the apparatus 10 of the embodiment of the present application further includes: a setting module, wherein the setting module is used to place the template processor in a preset low power consumption mode when the template processor is not inserted into the pipeline for execution.

[0090] Furthermore, the device 10 of the embodiment of the present application further includes: a detection module. The detection module is used to detect whether the message length has changed after parsing the user-specified protocol; when the message length has changed, the offset management module is used to update the parsing result.

[0091] Furthermore, the processing module 200 is further used to separate primitives and parameters, and form a general skeleton composed of each physical stage as a primitive, so that when configured by the user, corresponding parameters can be downloaded into the skeleton according to the added functions.

[0092] Furthermore, the apparatus 10 of the embodiment of the present application further includes: a crossbar switch module. The crossbar switch module is used to interconnect the physical stage and the storage resource using a static reconfigurable crossbar switch before separating and pooling the flow table resources of each physical stage, so as to reconfigure the crossbar switch when the template processor or the flow table is updated.

[0093] Furthermore, the fast update module 400 is specifically used for: when configuring the template processor, sequentially configuring the template processors that need to be updated along the pipeline downwards, wherein the data packet processing before the first template processor that needs to be configured is suspended, and when there is no data packet in the template processor, the template processor is configured, and sequentially configuring the template processors that need to be updated along the pipeline downwards; after updating the configuration, deleting all empty-configured template processors along the pipeline downwards, wherein when deleting an empty-configured template processor, the data packet processing before the empty-configured template processor is suspended, and when the data in the empty-configured template processor is empty, the empty-configured template processor is deleted from the pipeline by configuring a configurable cross switch.

[0094] Furthermore, the programmable data plane also includes a pipeline-by-pipeline update controller, and the device 10 of the embodiment of the present application also includes: a pipeline-by-pipeline update module. The pipeline-by-pipeline update module is used to update the pipelines in the data plane one by one based on the pipeline-by-pipeline update controller, and when updating the configuration of any pipeline, suspend the data packet from entering any pipeline, and when there is no data packet in any pipeline, update any pipeline, and after the update is completed, the data packet enters any pipeline normally, and selects the pipeline that has not been updated for update.

[0095] It should be noted that the above explanation of the embodiment of the method for updating the programmable data plane at runtime is also applicable to the device for updating the programmable data plane at runtime of this embodiment, and will not be repeated here.

[0096] According to the programmable data plane update device at runtime proposed in the embodiment of the present application, protocols can be added, deleted or modified at runtime, which is beneficial for users to test or deploy new protocols and delete outdated or redundant protocols at the same time; functional logic can be added, deleted or modified at runtime. For network devices that provide multi-tenant application services, network operators can add new user services without affecting other users, or directly delete the functions of a user when the service of a user expires; flow tables can be created, flow tables can be recycled, and flow table specifications can be modified at runtime, thereby improving the utilization rate of storage resources in network devices; users perform runtime updates through rP4, which is an extension of P4, and users can implement runtime updates simply and conveniently; the update process will not affect the normal data packet processing process, and can implement real-time and uninterrupted updates, and functions take effect immediately.

[0097] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0098] A memory 1201 , a processor 1202 , and a computer program stored in the memory 1201 and executable on the processor 1202 .

[0099] When the processor 1202 executes the program, the method for updating the programmable data plane at runtime provided in the above embodiment is implemented.

[0100] Furthermore, the electronic device further comprises:

[0101] The communication interface 1203 is used for communication between the memory 1201 and the processor 1202 .

[0102] The memory 1201 is used to store computer programs that can be executed on the processor 1202 .

[0103] The memory 1201 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0104] If the memory 1201, the processor 1202 and the communication interface 1203 are implemented independently, the communication interface 1203, the memory 1201 and the processor 1202 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0105] Optionally, in a specific implementation, if the memory 1201, the processor 1202 and the communication interface 1203 are integrated on a chip, the memory 1201, the processor 1202 and the communication interface 1203 can communicate with each other through an internal interface.

[0106] The processor 1202 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0107] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned method for updating the programmable data plane at runtime.

[0108] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. 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 this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0109] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0110] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0111] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or N wirings (electronic devices), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0112] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0113] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0114] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0115] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for updating a programmable data plane at runtime, characterized in that: The programmable data plane includes a distributed on-demand parser, a template processor, a virtual pipeline, a decoupled resource pool, a fast update controller, and a pipeline-by-pipeline update controller, wherein the method includes the following steps: Based on the distributed on-demand parser, the parsing graph is split into multiple parsing subgraphs, and each parsing subgraph is distributed to each corresponding physical stage in the pipeline, wherein the parsing subgraph of each physical stage is used to indicate the local parsing process, and at runtime, the user-specified protocol is parsed, and the parsing subgraph is configured to perform the adding protocol action, deleting the protocol action and / or modifying the protocol action in the target physical stage; Based on the template processor and the virtual pipeline, adjusting the order between any two processors by configuring the interconnection network according to the instruction, wherein any processor among all the template processors serves as a physical stage of the inlet pipeline or a physical stage of the outlet pipeline; and performing free configuration actions by configuring template parameters; Based on the decoupled resource pool, the flow table resources of each physical stage are separated and pooled, and at runtime, a new flow table is created, a flow table is recycled, or the specification of the flow table is modified; Based on the fast update controller, suspend the data packet processing before the template processor that needs to be updated, and when the template processor has no data packet, configure the template processor or delete the template processor from the pipeline; Based on the pipeline-by-pipeline update controller, the pipelines in the data plane are updated one by one. When updating the configuration of any pipeline, the data packet is paused from entering any pipeline. When there is no data packet in any pipeline, the any pipeline is updated. After the update is completed, the data packet enters any pipeline normally, and the pipeline that has not been updated is selected for updating.

2. The method according to claim 1, characterized in that Also includes: When the template processor is not inserted into the pipeline for execution, the template processor is placed in a preset low power consumption mode.

3. The method according to claim 1, characterized in that: The executing free configuration action includes: By separating primitives from parameters, each physical stage is a general skeleton composed of primitives, so that when configured by the user, the corresponding parameters are downloaded to the skeleton according to the added functions.

4. The method according to any one of claims 1 to 3, characterized in that: Before separating and pooling the flow table resources of each physical stage, the following steps are also included: A statically reconfigurable crossbar switch is used to interconnect the physical stage and the storage resources, so that the crossbar switch can be reconfigured when the template processor or the flow table is updated.

5. The method according to claim 1, characterized in that The method of suspending the data packet processing before the template processor that needs to be updated based on the fast update controller, and configuring the template processor or deleting the template processor from the pipeline when the template processor has no data packet, includes: When configuring the template processor, the template processors that need to be updated are configured in sequence downward along the pipeline, wherein the data packet processing before the first template processor that needs to be configured is suspended, and when there is no data packet in the template processor, the template processor is configured, and the template processors that need to be updated are configured in sequence downward along the pipeline; After the configuration is updated, all template processors with empty configurations are deleted downward along the pipeline, wherein when deleting the template processor with empty configurations, the data packet processing before the template processor with empty configurations is suspended, and when the data in the template processor with empty configurations is empty, the template processor with empty configurations is deleted from the pipeline by configuring a configurable cross switch.

6. A device for updating a programmable data plane at runtime, characterized in that: The programmable data plane includes a distributed on-demand parser, a template processor, a virtual pipeline, a decoupled resource pool, a fast update controller and a pipeline-by-pipeline update controller, wherein the device includes: A parsing module, for splitting a parsing graph into multiple parsing subgraphs based on the distributed on-demand parser, and distributing each parsing subgraph to each corresponding physical stage in the pipeline, wherein the parsing subgraph of each physical stage is used to indicate a local parsing process, and at runtime, parses out a user-specified protocol, and configures the parsing subgraph to perform an add protocol action, a delete protocol action, and / or a modify protocol action at a target physical stage; A processing module, configured to adjust the order between any two processors by configuring an interconnection network according to an insertion instruction based on the template processor and the virtual pipeline, wherein any processor among all the template processors serves as a physical stage of an inlet pipeline or a physical stage of an outlet pipeline; and to perform a free configuration action by configuring parameters of the template processor; and A storage module, used to separate and pool the flow table resources of each physical stage based on the decoupled resource pool, and to create a new flow table, recycle a flow table, or modify the specifications of the flow table during runtime; A fast update module, used for suspending the data packet processing before the template processor that needs to be updated based on the fast update controller, and when the template processor has no data packet, configuring the template processor or deleting the template processor from the pipeline; A pipeline-by-pipeline update module is used to update the pipelines in the data plane one by one based on the pipeline-by-pipeline update controller. When updating the configuration of any pipeline, the data packet is suspended from entering the any pipeline. When there is no data packet in any pipeline, the any pipeline is updated. After the update is completed, the data packet enters the any pipeline normally, and the pipeline that has not been updated is selected for updating.

7. The device according to claim 6, characterized in that Also includes: The setting module is used to place the template processor in a preset low power consumption mode when the template processor is not inserted into the pipeline for execution.

8. The device according to claim 6, characterized in that The processing module is further used to separate primitives and parameters, and form a general skeleton composed of each physical stage as a primitive, so that when configured by the user, corresponding parameters can be downloaded into the skeleton according to the added functions.

9. The device according to any one of claims 6 to 8, characterized in that: Also includes: A crossbar switch module is used to interconnect the physical stage and the storage resources using a static reconfigurable crossbar switch before separating and pooling the flow table resources of each physical stage, so as to reconfigure the crossbar switch when the template processor or the flow table is updated.

10. The device according to claim 6, characterized in that The fast update module is specifically used for: When configuring a template processor, the template processors that need to be updated are configured in sequence downward along the pipeline, wherein the data packet processing before the first template processor that needs to be configured is suspended, and when there is no data packet in the template processor, the template processor is configured, and the template processors that need to be updated are configured in sequence downward along the pipeline; after the configuration is updated, all template processors with empty configurations are deleted downward along the pipeline, wherein when deleting the template processor with empty configurations, the data packet processing before the template processor with empty configurations is suspended, and when the data in the template processor with empty configurations is empty, the template processor with empty configurations is deleted from the pipeline by configuring a configurable cross switch.

11. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method for updating the programmable data plane at runtime as described in any one of claims 1 to 5.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the method for updating the programmable data plane at runtime as described in any one of claims 1 to 5.

Images