Hardware independence specification for data packet processing pipelines

Abstract

The present disclosure relates to hardware independence specification of data packet processing pipelines. A method includes providing a library of hardware independent data packet processing functions. A hardware independence specification of functionality of a data packet processing pipeline for use in a network device is received from a user. The specification is defined in terms of one or more data packet processing functions extracted from the library. A hardware specific design of the data packet processing pipeline suitable for a given hardware is derived from the specification.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Patent Application 63 / 274,553, filed November 2, 2021, the disclosure of which is incorporated herein by reference. TECHNICAL FIELD

[0003] The present invention relates generally to data packet processing, and in particular to hardware independence specification of a data packet processing pipeline. BACKGROUND

[0004] Network devices, such as switches, routers, and network adapters in a communication network, typically use a data packet processing pipeline to process communication data packets.

[0005] U.S. Patent 11,271,874 discloses a network adapter that includes a host interface configured to communicate with a host, a network interface configured to communicate with a communication network, and a data packet processing circuit. The data packet processing circuit is configured to receive a data packet from the host via the host interface or from the communication network via the network interface, receive an indication of a network time to synchronize network elements in the communication network, match the data packet to a rule that includes a condition and an action, and perform the action in response to the data packet satisfying the condition, where one or more of (i) the condition in the rule and (ii) the action in the rule are dependent on the network time.

[0006] U.S. Patent 10,841,243 discloses a network interface controller connected to a host and a data packet communication network. The network interface controller includes an electrical circuit configured as a data packet processing pipeline having a plurality of stages. At least a portion of the stages of the pipeline are determined in the network interface controller to be acceleration-defined stages. Data packets are processed in the pipeline by sending data from the acceleration-defined stages to an accelerator, performing corresponding acceleration tasks on the sent data in the accelerator, and returning the processed data from the accelerator to a receiving stage of the pipeline. SUMMARY

[0007] Embodiments of the invention described herein provide a method that includes providing a library of hardware-independent data packet processing functions. A hardware- independent specification of functionality of a data packet processing pipeline for use in a network device is received from a user. The specification is defined in terms of one or more data packet processing functions extracted from the library. A hardware-specific design of a data packet processing pipeline suitable for a given hardware is derived from the specification.

[0008] In some embodiments, providing the library includes exposing an application programming interface (API) to the user for using the library to define the specification. In various embodiments, the hardware-independent packet processing function performs one or more of access control list (ACL) functions, longest prefix match (LPM), match table functions, encryption, decryption, packet modification, packet mirroring, packet metering, packet counting, connection tracking, packet aging, and packet forwarding.

[0009] In one embodiment, the at least one hardware-independent packet processing function includes a user-configurable packet parsing operation, and receiving the specification from the user includes receiving a configuration of the packet parsing operation. In one disclosed embodiment, the at least one hardware-independent packet processing function includes a user-configurable action, and receiving the specification from the user includes receiving a configuration of the action. In some embodiments, deriving the hardware-specific design of the packet processing pipeline includes deriving a design of one of a switch, a router, a gateway, a network adapter, a firewall, and a user plane function (UPF).

[0010] According to one embodiment described herein, there is additionally provided a device including a memory and a processor. The memory is configured to store a library of hardware-independent packet processing functions. The processor is configured to provide the library to a user, receive from the user a hardware-independent specification of functionality of a packet processing pipeline for use in a network device, the specification being defined in terms of one or more packet processing functions extracted from the library, and derive from the specification a hardware-specific design of a packet processing pipeline suitable for a given hardware.

[0011] According to one embodiment described herein, there is additionally provided a computer software product. The product includes a tangible, non-transitory computer-readable medium having program instructions stored therein, the instructions, when read by a processor, causing the processor to store a library of hardware-independent packet processing functions, provide the library to a user, receive from the user a hardware-independent specification of functionality of a packet processing pipeline for use in a network device, the specification being defined in terms of one or more packet processing functions extracted from the library, and derive from the specification a hardware-specific design of a packet processing pipeline suitable for a given hardware.

[0012] The present application will be more fully understood from the following detailed description of embodiments thereof, taken together with the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 is a block diagram schematically illustrating a system for design of a pipeline-based packet processing system, in accordance with an embodiment of the present application;

[0014] Figure 2is a flow diagram that schematically illustrates a method for designing a pipeline-based packet processing system, in accordance with an embodiment of the present application;

[0015] Figure 3 is a block diagram that schematically illustrates a data center on a chip architecture (DOCA) flow pipe, in accordance with an embodiment of the present application;

[0016] Figure 4 is a block diagram that schematically illustrates a communication switch for DOCA flow generation, in accordance with an embodiment of the present application;

[0017] Figure 5 is a block diagram that schematically illustrates a configuration of conversion software that converts a hardware-agnostic API database to hardware-dependent circuit descriptions, in accordance with an embodiment of the present application;

[0018] Figure 6 is a block diagram that schematically illustrates a hardware-agnostic description generation parser circuit, in accordance with an embodiment of the present application;

[0019] Figure 7 is a block diagram that schematically illustrates a hybrid hardware-software circuit for DOCA flow generation, in accordance with an embodiment of the present application;

[0020] Figure 8 is a block diagram that schematically illustrates a configuration of a user plane function (UPF) for DOCA flow generation, in accordance with an embodiment of the present application; and

[0021] Figure 9 is a block diagram that schematically illustrates a configuration of a packet processing device for DOCA flow generation that includes a combination of hardware and software, in accordance with an embodiment of the present application. DETAILED DESCRIPTION

[0022] SUMMARY

[0023] Network devices, such as network switches, routers, network adapters, and other devices, transmit packets over a communication network, such as an Ethernet or InfiniBand TM ) network. Network devices typically receive packets from the network through ingress ports and can forward some or all of the packets onto the network through egress ports according to forwarding / routing rules. Alternatively, some packets can be forwarded to a virtual machine (VM), container, or other entity running on the same host.

[0024] In practice, considerable similarities can be found between basic packet processing functions that constitute different types of pipelines in different network devices.

[0025] Embodiments of the invention described herein provide improved methods and systems for specifying packet processing pipelines. The disclosed technology aims to decouple the initial specification of a packet processing pipeline from the target hardware on which the pipeline will eventually run. In this way, a user is able to specify a packet processing pipeline from a completely functional perspective. At a later stage, the user's specification can be mapped onto the desired target hardware.

[0026] In some embodiments, a user is provided with a library of hardware-agnostic packet processing functions. Such hardware-agnostic packet processing functions can include, for example, access control list (ACL) functions, longest prefix match (LPM) functions, match table functions, encryption / decryption functions, packet modification functions, mirroring functions, metering functions, aging functions, deep packet inspection (DPI) functions, packet forwarding functions, and the like. In some embodiments, two or more of the above functions can be merged into a single function. For example, packet modification, mirroring, and metering can be merged into a single packet processing function of the library.

[0027] The library can be exposed to the user, for example, using a suitable application programming interface (API).

[0028] The user uses the packet processing functions in the library as building blocks and connects and configures them to specify a packet processing pipeline. Many types of pipelines can be specified using such building blocks in a completely hardware-agnostic manner. Examples of packet processing pipelines include switches, routers, gateways, network adapters, firewalls, and user plane functions (UPFs), to name just a few.

[0029] Once a hardware-agnostic specification is defined, a processor can use it to derive a hardware-specific design of a packet processing pipeline that is suitable for a given hardware technology. This process can be completely automated or assisted by the user.

[0030] The disclosed technology provides a very effective tool for enabling a user to specify the functionality of a packet processing pipeline while hiding the underlying complexity and constraints of the target hardware. This decoupled approach simplifies the user's specification task. Furthermore, the same hardware-agnostic specification can be mapped to different hardware technologies with minimal user involvement.

[0031] System Description

[0032] Network devices, such as network switches, routers, and adapters, receive and process packets from a communication network, such as an Ethernet or InfiniBand TM ) network. In modern high-speed networks, packet processing is typically done in one or more hardware and software pipelines that process multiple packets concurrently.

[0033] The design of such pipelines, including the interfaces between the pipes, can be complex and tightly coupled to the chosen hardware technology.

[0034] To simplify the design of the pipeline, a hardware-independent processing function library and underlying automation tools are provided. The library, automation tools, and steering engine are referred to as the Data Center Architecture Flow (DOCA Flow) on-chip.

[0035] Figure 1 is a block diagram that schematically illustrates a system 100 for designing a pipeline-based packet processing system according to an embodiment of the present application. A user 102 (e.g., an electronic engineer) of a work station 104 communicates with a computer 106 to input his or her packet processing design. In embodiments, the work station 104 can include a screen, keyboard, and mouse that communicate with the computer 106, for example, through a Universal Serial Bus (USB) interface. In other embodiments, the computer 106 can be embedded in the work station 104. In some embodiments, the computer 106 can be remote, interfacing with the work station 104 over a communications network (e.g., Ethernet). In other embodiments, the computer 106 can be a cloud computing resource.

[0036] The computer 106 includes a processor 108 and a memory 110. The memory includes a hardware-independent packet processing function library 112 (hereinafter "the library"). In embodiments, the library can include functions such as access control lists (ACLs), longest prefix match (LPM) functions, and many other functions (a partial list of functions is detailed below).

[0037] To design the packet processing hardware / software, the user 102 runs an application programming interface (API) 114 (e.g., a graphical user interface (GUI), or, as another example, API code). The user selects elements from the library, configures the elements (e.g., using a script or using a pop-up menu), and interconnects the elements to form an interconnected function list 116.

[0038] The interconnected function list is hardware-independent and can be reused for various target hardware technologies, including (but not limited to) ASIC process technologies, FPGA families, and the like. To generate a hardware-specific implementation, the user 102 specifies the hardware technology in a hardware technology file 122 according to a predetermined format (e.g., a Synopsys techfile (.tf), or a Cadence LEF file (.techlef)). For example, in some embodiments, the technology file can include a list of primitive gates.

[0039] Memory 110 further includes a conversion program 120 (sometimes referred to as a DOCA flow compiler) that is configured to convert the list of interconnected functions to a hardware netlist according to hardware technology files 122. The conversion generates a target netlist file 124 that can then be used to generate a design hardware and software (for the purposes of the present disclosure, the term "netlist" includes multiple levels of abstraction, including ASIC layout graphics design system 2 (GDSII), gate level hardware definition language (HDL), behavioral HDL, structural HDL, FPGA programming bitstream, and others, including combinations of more than one level). When new hardware is available, user 102 can re-run conversion program 120 to generate an updated version of the same design.

[0040] Thus, according to Figure 1 the example embodiments shown in FIG. 1 and described above, a user is able to design complex packet processing hardware and hardware / software combinations without regard to implementation technology, saving design time and minimizing design errors.

[0041] Figure 1 The configuration of block diagram 100 shown in FIG. 1 and described above is an example by way of illustration. Other embodiments can be used in alternative embodiments. For example, in some embodiments, the user can provide a script that defines the configuration and interconnection of selected processing functions of library 112; in one embodiment, an intermediate level of abstraction can be used in which multiple interconnected library functions form a flow pipe that can be coupled to other flow pipes, library functions, and inlet or outlet ports.

[0042] Figure 2 FIG. 2 is a flowchart 200 that schematically illustrates a method for designing a pipeline-based packet processing system according to one embodiment of the present application. The method is performed by computer 106, operated by user 102. Figure 1

[0043] The method begins with an acquire library operation 106 in which the computer is provided with a library 112 of hardware-independent packet processing functions Figure 1 Next, in an acquire function list operation 204, the computer receives from the user, via an API, a list of selected library functions, the configuration of the functions, and the connections between the functions.

[0044] At this point, the hardware-independent portion of the design has been completed. The computer is now able to generate implementation files for a selected implementation technology. In an acquire target implementation technology operation 206, the processor receives a technology file for a target hardware technology, and in a generate hardware / software design operation 208, design files (e.g., netlists and C code) are created.

[0045] Figure 2 ​The flowcharts shown in FIG. 6 and described above are referenced by way of example. Other flowcharts can be used in alternative embodiments. For example, in one embodiment, operation 204 includes defining hardware-independent flow pipes, each flow pipe including a set of library functions; in another embodiment, after operation 204, the computer stores the interconnected and configured functions in intermediate format; and, in another embodiment, operation 208 can include a front-end portion that runs separately for each function or group of functions, and a back-end portion that compiles the complete network.

[0046] Data packet processing functions

[0047] In embodiments, the elements of the hardware-independent data packet processing library include some or all of the following:

[0048] 1. Access control list (ACL) functions - processing functions that decide the action to be applied to a data packet (typically in response to a data packet header).

[0049] 2. Longest prefix match (LPM) functions that select the best matching entry for a string from a table.

[0050] 3. Match table functions that generate a table of comparison values.

[0051] 4. Encryption functions (e.g., AES256).

[0052] 5. Decryption functions.

[0053] 6. Data packet modification functions that modify data packets according to preset rules, and can include data packet encryption / decryption, adding / removing tunnels (e.g., encapsulation / decapsulation), and other modifications.

[0054] 7. Data packet mirroring functions that generate a mirror data packet for a given data packet.

[0055] 8. Data packet metering functions that measure preset statistics for a given data packet.

[0056] 9. Data packet counting functions that count data packets that meet preset criteria.

[0057] 10. Data packet aging functions that send an age measurement for a given data packet.

[0058] 11. Deep packet inspection (DPI) functions that inspect data packets using DPI algorithms.

[0059] 12. Data packet forwarding functions that forward data packets to the next data packet processing function.

[0060] 13. Connection tracking functions.

[0061] Other functions can be used in alternative embodiments, either in addition to or instead of the list above.

[0062] The set of interconnected packet processing functions form one or more packet processing flows (sometimes referred to below as "pipes"). In embodiments, a packet processing flow can include multiple packet processing sub-flows that process a set of packet processing functions.

[0063] Figure 3 is a block diagram schematically illustrating a data center on a chip architecture (DOCA) flow pipe 300 according to an embodiment of the application. The flow pipe includes two parallel sub-flows (e.g., for faster operation); each sub-flow includes a match function 302, a policing function 304 (which can include packet metering), a Packer-Modify function that modifies packet fields by setting, adding or copying metadata, and a Forward function 308 that forwards the output to the next packet processing flow, port or software. In embodiments, the match function 302 is programmable and can be enhanced by adding more match criteria. In some embodiments, the policing function 304 includes counting, bandwidth limiting, sampling (e.g., forwarding samples to software) and mirroring predefined packets.

[0064] A user can select functions 302, 304, 306 and 308 from a hardware-agnostic library, set parameters for these functions and define the interconnection of the functions in the pipeline flow.

[0065] Figure 3 The configuration of the flow pipe 300 illustrated in and described above is by way of example. Other configurations can be used in alternative embodiments. For example, in one embodiment, the flow pipe 300 includes more than two parallel sub-flows; in embodiments, some or all of the sub-flows are identical while others are not.

[0066] Figure 4 is a block diagram schematically illustrating a communication switch 400 according to an embodiment of the application that generates DOCA flow pipes. The design includes five flow pipes, each including interconnected and parameterized hardware-agnostic functions that a user selects from a library 112 Figure 1 ) of interconnected and parameterized hardware-agnostic functions.

[0067] The strip channel flow pipe 402 receives ingress packets and decapsulates the packets to recover and map the internally encapsulated packets, which are then sent by the strip channel to the connection tracking flow pipe 404. The connection tracking flow pipe 404 is configured to decide whether to accept the packets or send the packets to the policy flow pipe 406. The internal tables of the connection tracking flow pipe 404 typically make the decision by comparing packet header fields to built-in tables.

[0068] The policy flow pipe 406 uses predefined policies to interpret the packet header and determine whether the packet should be allowed or rejected. If the policy flow pipe decides that the packet is to be rejected, the packet is discarded.

[0069] In embodiments, the policy-based interpretation is much slower than the processing done by the connection tracking flow pipe 404; to improve speed, the decisions made by the policy flow pipe on packet headers are then stored in internal tables of the connection tracking flow pipe 404, so that future occurrences of the same packet header (or packet headers with the same predefined set of characteristics) will be processed more quickly without having to go into the policy flow pipe.

[0070] The connection tracking flow pipe 404 sends accepted packets to the routing flow pipe 408, which determines the destination of the packet and sends the packet with the destination indication to the forwarding information base (FIB) flow pipe 410, which then forwards the packet to the destination (e.g., an egress port).

[0071] Thus, according to Figure 4 In the example embodiments shown and described above, a user can design a complete switch using hardware-agnostic functions without having to consider implementation technology.

[0072] The configuration of the communication switch 400 is referenced by way of example only, to demonstrate the capabilities of the hardware-agnostic communication switch design according to embodiments. Other configurations can be used in alternative embodiments. For example, in one embodiment, the policy flow pipe 406 can send accepted packets directly to the routing flow pipe 408; in another embodiment, the connection tracking 404 can store identifiers for packets to be rejected and discard such packets directly (rather than sending the packets to the policy flow pipe 406).

[0073] Application Programming Interface (API)

[0074] In embodiments, a user employs an API to generate a hardware-agnostic representation of flow pipes in a packet processing system. Using the API, the user can select, configure, and interconnect hardware-agnostic functions from the library of functions 112 Figure 1 ). The API stores the interconnected combination of functions in an internal database. In some embodiments, the user can further compile the API database to produce a hardware-agnostic low-level (e.g., binary) representation of the flow pipes.

[0075] To generate a hardware-specific implementation, the flow pipe back-end program first converts the low-level representation to a suitable representation format that can be used by an implementation engine to generate a circuit description (e.g., a netlist or HDL) that is compatible with the target hardware technology.

[0076] Figure 5is a block diagram that schematically illustrates the configuration of the conversion software 500 that converts hardware-independent stream pipes (into a hardware-dependent circuit description. The stream pipes are represented by a suitable API database. The software includes API instances 502 that describe the stream pipes. A user API compiler 504 compiles the API database into a low-level hardware-independent representation of the stream pipes.

[0077] To convert the low-level code into a hardware description that is compatible with the target hardware technology, a stream pipe backend program 506 converts the low-level code into an intermediate representation that is input to a DOCA stream engine 508 to generate a hardware-dependent circuit database.

[0078] In embodiments, the above-described process is incremental; to add another stream pipe via the API 510, the stream pipe is compiled by the user API engine 504 and then processed by the stream pipe backend 506, which converts the added function into additional input to the DOCA stream engine 508.

[0079] It is noted that the original stream pipes can have been created a priori by the user API 502, compiled into a low-level representation by the API engine 504, and converted into DOCA stream engine input by the DOCA stream backend 506. To add a new function, or stream pipe, the user repeats the above-described steps only for the added function or stream pipe; only the last stage - the DOCA stream backend engine - must be run on the complete circuit.

[0080] Thus, the disclosed technology allows efficient addition of hardware-independent functions in a hardware description.

[0081] Figure 5 The configuration of the conversion software 500 illustrated in and described above is by way of example. Other configurations can be used in alternative embodiments. For example, in some embodiments, there is no API compiler (504); instead, the stream pipe backend program 506 converts the stream pipe descriptions generated by the APIs 502 and 510 directly into a format compatible with the DOCA stream engine 508.

[0082] Figure 6 is a block diagram that schematically illustrates the generation of a parser circuit from a hardware-independent description according to an embodiment of the present application. A user writes hardware-independent parser code 602 using match and action primitives that can be compatible with P4. In some embodiments, a special language is used to describe the parser. A DOCA stream compiler 604 then generates a hardware-specific implementation 606 that can include C structures and hardware netlists that implement the required matches and actions defined in the parser code 602 in the target hardware technology and software code.

[0083] Target function for software implementation

[0084] In some embodiments, the DOCA flow compiler can generate hybrid target circuits, including hardware implementations of some flow pipes and software implementations of other flow pipes (or functions within flow pipes). In one embodiment, the software implementations can be done by one or more fast embedded processors (e.g., a set of high performance embedded reduced instruction set (eRCV) processors) that are tightly coupled with the hardware flow pipes for minimal call and parameter passing overhead.

[0085] In another embodiment, the DOCA flow can be targeted for a data path accelerator (DPA), typically including a general purpose processor (or multiple processors). The DPA can be invoked by hardware generated exceptions.

[0086] In one embodiment, to improve speed, the processor (DPA and / or eRVC) feeds the software execution results back to the hardware flow pipe so that future occurrences of the same packet type will be handled by hardware only.

[0087] Figure 7 is a block diagram schematically illustrating a hybrid hardware-software circuit 700 generated from a DOCA flow according to one embodiment of the present application. The circuit is configured to perform parsing 702, and related actions 704. The implementation includes interconnected flow pipes 706, eRVCs 708 tightly coupled with the flow pipes, and software exception handling 710 performed by one or more general purpose processors. The general purpose processors are configured to update tables within the flow pipes so that further occurrences of the same packet type will be handled by the flow pipes without software intervention.

[0088] Figure 8 is a block diagram schematically illustrating a configuration of a user plane function (UPF) 800 generated from a DOCA flow according to one embodiment of the present application. The UPF can be, for example, a Fifth Generation (5G) UPF.

[0089] The UPF 800 includes a packet detection rule (PDR) flow pipe 802 configured to detect packets according to a predetermined rule set, and a PDR action flow pipe 804 configured to perform actions on the packets according to a predetermined rule set. When the UPF PDR flow pipe 802 encounters a packet that is not covered by the rule set of the PDR flow pipe, the PDR flow pipe asserts and exceptions, which are input to a general purpose processor 806; the general purpose processor is configured to evaluate the required packet processing and the required packet actions. The general purpose processor 806 is further configured to update the rule sets in both the UPF PDR flow pipe 802 and the PDR action flow pipe 804.

[0090] The PDR action flow pipe 804 next forwards the modified packet to a next hop flow pipe 808, which is configured to forward the packet to the destination according to a pre-set FIB.

[0091] Figure 9 is a block diagram schematically showing a configuration of a packet processing device 900 including a combination of hardware and software according to an embodiment of the present application. The processing device includes a connection tracking flow pipe 902 configured to receive a packet and inspect the packet according to a pre-set rule set. If the packet (typically a packet header) is covered by the rule set, the connection tracking flow pipe sends the packet to an action flow pipe 904, which is configured to perform an action on the packet according to the packet header.

[0092] If the packet is not covered by the rule set, the connection tracking flow pipe signals an exception to a general purpose processor 906, which will evaluate the packet using software. According to Figure 9 In the example embodiment shown, the general purpose processor can use a side acceleration engine 908 in order to perform special cases (e.g., for evaluating regular expressions) more quickly.

[0093] After evaluating the packet, the general purpose processor injects the evaluated packet back into hardware, and can update the rule set of the connection tracking flow pipe 902 in an embodiment.

[0094] It should be mentioned that while the pipes are typically defined a priori, it is also possible to use APIs to modify the pipes and / or to add new pipes on the fly and / or to remove pre-defined pipes.

[0095] The configuration of the system 100, including the hardware-agnostic library 112; the method of the flowchart 200; the structure of the flow pipes 300, 402, 404, 406, 408, and 410; the configuration of the translation software 500, the configuration of the parser hardware generation 600, the configuration of the hybrid hardware-software circuit 700, the configuration of the UPF 800 of DOCA flow generation, and the configuration of the packet processing device 900 of DOCA flow generation, are example configurations, methods, and devices shown purely for conceptual clarity. Any other suitable configurations, methods, and devices can be used in alternative embodiments.

[0096] In various embodiments, the target implementation of the DOCA flow generation can include suitable hardware, such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs), or a combination of ASICs and FPGAs.

[0097] The processor 108 (refer to Figure 1 ) used to run the DOCA flow software, as well as the target processor described above (refer to Figure 7 ,Figure 8 and Figure 9 ) typically comprise one or more general purpose processors that are programmed in software to perform the packet processing functions. The software can be downloaded to the processors in electronic form, over a network, for example, or it can alternatively or additionally be provided and / or stored on non-transitory tangible media, such as magnetic, optical or electronic memory.

[0098] It will be understood, therefore, that the embodiments described above are cited by way of example, and that the present application is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present application includes both combinations and sub-combinations of the various features described above, as well as variations and modifications such as would be obvious to a person of ordinary skill in the art upon reading the foregoing description. The documents incorporated by reference into this patent application are to be regarded as part of the disclosure only to the extent that the incorporated material does not conflict with the explicit or implicit definitions and / or limitations of the present application.

Claims

1. A method for deriving hardware-specific designs, comprising: providing a library of hardware-agnostic packet processing functions; receiving from a user a hardware-agnostic specification of functionality of a packet processing pipeline for use in a network device, the specification defined in terms of one or more of the packet processing functions extracted from the library; and deriving from the specification a hardware-specific design of the packet processing pipeline suitable for a given hardware.

2. The method of claim 1, wherein providing the library comprises: exposing to the user an application programming interface (API) for defining the specification using the library.

3. The method of claim 1, wherein the hardware-agnostic packet processing functions perform one or more of: access control list (ACL) functionality; longest prefix match (LPM); match table functionality; encryption; decryption; packet modification; packet mirroring; packet metering; packet counting; connection tracking; packet aging; and packet forwarding.

4. The method of claim 1, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable packet parsing operation, and wherein receiving the specification from the user comprises receiving a configuration of the packet parsing operation.

5. The method of claim 1, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable action, and wherein receiving the specification from the user comprises receiving a configuration of the action.

6. The method of claim 1, wherein deriving the hardware-specific design of the packet processing pipeline comprises deriving a design of one of a switch, a router, a gateway, a network adapter, a firewall, and a user plane function (UPF).

7. An apparatus for deriving hardware-specific designs, comprising: a memory to store a library of hardware-agnostic packet processing functions; and a processor to: provide the library to a user; receive from the user a hardware-agnostic specification of functionality of a packet processing pipeline for use in a network device, the specification defined in terms of one or more of the packet processing functions extracted from the library; and derive from the specification a hardware-specific design of the packet processing pipeline suitable for a given hardware.

8. The apparatus of claim 7, wherein the processor is to expose to the user an application programming interface (API) for defining the specification using the library.

9. The apparatus of claim 7, wherein the hardware-agnostic packet processing functions perform one or more of: access control list (ACL) functionality; longest prefix match (LPM); match table functionality; encryption; decryption; packet modification; packet mirroring; packet metering; packet counting; connection tracking; packet aging; and packet forwarding.

10. The apparatus of claim 7, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable packet parsing operation, and wherein in receiving the specification from the user, the processor is to receive a configuration of the packet parsing operation. ​ 11. The apparatus of claim 7, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable action, and wherein in receiving the specification from the user, the processor is to receive a configuration of the action.

12. The apparatus of claim 7, wherein the processor is to derive from the specification a hardware-specific design of one of a switch, a router, a gateway, a network adapter, a firewall, and a user plane function (UPF).

13. A computer software product, the product comprising a tangible, non-transitory computer-readable medium having stored therein program instructions that, when read by a processor, cause the processor to: store a library of hardware-agnostic packet processing functions; provide the library to a user; receive from the user a hardware-agnostic specification of functionality of a packet processing pipeline for use in a network device, the specification defined in terms of one or more of the packet processing functions extracted from the library; and derive from the specification a hardware-specific design of the packet processing pipeline suitable for a given hardware.

14. The product of claim 13, wherein the instructions cause the processor to expose to the user an application programming interface (API) for defining the specification using the library.

15. The product of claim 13, wherein the hardware-agnostic packet processing functions perform one or more of: access control list (ACL) functionality; longest prefix match (LPM); match table functionality; encryption; decryption; packet modification; packet mirroring; packet metering; packet counting; connection tracking; packet aging; and packet forwarding.

16. The product of claim 13, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable packet parsing operation, and wherein the instructions cause the processor to receive from the user a configuration of the packet parsing operation.

17. The product of claim 13, wherein at least one of the hardware-agnostic packet processing functions comprises a user-configurable action, and wherein the instructions cause the processor to receive from the user a configuration of the action.

18. The product of claim 13, wherein the instructions cause the processor to derive from the specification a hardware-specific design of one of a switch, a router, a gateway, a network adapter, a firewall, and a user plane function (UPF).

Images