SYSTEM AND METHOD FOR SCALING DATA PROCESSING WITH OFFLOAD ENGINES AT THE TAX PLACE

Abstract

A network switch (200, 500, 530), comprising: Hardware-based packet processing logic for processing received packets; a processing unit (202, 502, 532) and an offload engine (222, 224, 300, 400, 514, 518, 546, 550) coupled with the processing unit; wherein the offload engine serves to offload packet processing operations associated with a subset of received packets from the processing unit; wherein the offload engine comprises a processor core (302) executing a set of unmodified extended Berkeley packet filtering (eBPF) instructions without an operating system implementation, one or more hardware packet processing accelerators (312) for performing the packet processing operations, and a function helper logic (310, 440) for forming an interface between the processor core and the hardware packet processing accelerators; where the function helper logic serves to parse an eBPF function call executed by the processor core and to send information associated with the eBPF function call to a corresponding hardware packet processing accelerator; the offload engine further includes an instruction memory (304) for storing the unmodified eBPF instructions; where the unmodified eBPF instructions are loaded into instruction memory by the processing unit; and where the processor core within the offload engine is configured to access the instruction memory to execute the unmodified eBPF instructions.

Description

BACKGROUND area

[0001] This disclosure generally relates to data processing in network switches. More specifically, this disclosure relates to a system and method for implementing hardware-based offload engines embedded in the switches.

[0002] The scale of new computing paradigms poses a challenge for computing in hardware architectures at the network edge. Energy consumption and compute power limit what can be achieved in edge applications with traditional software stacks, such as Linux-based systems-on-chips (SoCs). On the other end of the spectrum, custom integrated circuits or FPGA (field-programmable gate array)-based solutions, while efficient, offer very little flexibility in development and deployment compared to traditional software stacks.

[0003] One such compromise exists in hardware architectures with high-speed data interfaces in network switches. The switch's data plane (e.g., the hardware that performs packet-forwarding processes and operations) can operate at speeds of several terabits per second with limited flexibility. However, when flexible packet processing (e.g., in exceptional cases) is required, the data plane hardware can forward these packets to the control plane CPU for processing. The challenge is that the speed difference between the data plane hardware and the control plane CPU is several orders of magnitude. This difference increases further as the processing speed of the data plane hardware (e.g., the switch's application-specific integrated circuits (ASICs)) increases.

[0004] US 2019 / 0 050 273 A1 describes the registration of a device driver with an operating system, including the registration of available hardware offloads.

[0005] US 2020 / 0 274 ​​952 A1 relates to technologies for programming flexible accelerated network pipelines comprising a computing device with a network controller.

[0006] MIANO, S. [et al.]: Introducing SmartNICs in Server-Based Data Plane Processing: The DDoS Mitigation Use Case. In: IEEE Access, Vol. 7, 2019, pp. 107161–107170. DOI: 10.1109 / ACCESS.2019.2933491 presents an analysis of the different approaches that can be used for the introduction of SmartNICs in server-based data processing and evaluates the achievable results, particularly for the DDoS mitigation use case, under various alternatives. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an exemplary scenario for packet processing by a network switch according to the state of the art. Fig. 2 shows an exemplary scenario for processing packets by a network switch, according to one aspect of this application. Fig. 3 shows an exemplary block diagram of an eBPF engine according to an aspect of this application. Fig. 4A shows an exemplary hardware implementation of an eBPF engine according to one aspect of the present application. Fig. Figure 4B shows the function helper logic in detail according to one aspect of the present application. Fig. 5A shows an exemplary network switch according to one aspect of the present application. Fig. 5B shows an exemplary network switch according to one aspect of the present application. Fig. 6 shows a flowchart illustrating an exemplary packet processing operation according to one aspect of the present application.

[0007] In the figures, like numbers refer to the same elements of the figure. DETAILED DESCRIPTION

[0008] The following description is intended to enable one skilled in the art to make and use the examples and is provided in the context of a specific application and its requirements. Various modifications to the examples shown will be readily apparent to one skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the examples shown, but is intended to achieve the widest possible scope consistent with the principles and features disclosed herein.

[0009] The presented examples provide solutions to the technical problem of accelerating CPU-assisted datapath operations. Although capable of processing packets at high speed, switch ASICs must forward packets requiring supported datapath operations to the switch CPU, which primarily handles control path operations and has limited processing speed. To accelerate the processing of packets requiring flexible datapath operations, hardware-based offload engines can be provided for the CPUs (e.g., embedded in the switch ASIC) so that certain packet processing operations can be offloaded to the hardware. In some examples, the hardware-based offload engines may include processor cores executing the Extended Berkeley Packet Filter (eBPF) instruction set. Such processor cores do not run an operating system and can therefore be compact and power-efficient.The parallel implementation of multiple processor cores enables scaling.

[0010] Fig. Figure 1 shows an example scenario for packet processing by a network switch, as is the case with state-of-the-art technology. Fig. 1, the network switch 100 includes a CPU 102, which is typically a general-purpose CPU located in the control plane and handles control plane operations such as handling the network protocol, populating the routing table, and making routing decisions. The network switch 100 also includes a number of special-purpose ICs (e.g., the fabric ASIC chip 104, the switch port ASIC chips 106 and 108) located in the data plane and handle high-speed packet forwarding. Note that each switch port ASIC chip (e.g., chip 106 or 108) can control a number of ports and handle the processing of packets entering or exiting the ports. The fabric ASIC chip 104, on the other hand, manages the connection between the switch ports via the fabric links 110 and 112.

[0011] The switch ASICs (e.g., fabric ASIC chip 104, switch port ASIC chips 106 and 108) are specifically designed for high-speed packet processing and are often referred to as the "fast path" for packets. However, they lack certain flexibility in packet processing. For example, they are unable to handle exceptions. In such a case, the switch ASICs must send the packets to the CPU 102 for processing (e.g., via CPU ports 114 and 116). In addition to handling exceptions, the CPU 102 also performs other operations, such as packet scanning, security processes, learning operations, metrics collection, etc. As previously mentioned, software-based processing is orders of magnitude slower than the fast path. It is therefore often referred to as the "slow path" for packets. In addition to the lower speed, the slow path also has other problems, such as:the lack of real-time guarantees and the inability to scale linearly with the number of switch ASICs.

[0012] The speed difference between the fast and slow paths and the inability of the general-purpose CPU to increase the speed become a bottleneck for increasing the packet processing speed of the network switch. The CPU must frequently throttle traffic from the switch port, which can lead to protocol timeouts and thus performance degradation. Several solutions have been proposed to address this problem. One solution is to integrate flexible logic into the data plane pipelines (e.g., the switch ASICs) using microcode. However, such an approach is not suitable for large-scale general-purpose data processing, and the flexible logic cannot be reused in other ASIC designs. Another solution is to incorporate CPUs or microcontrollers into the data plane.However, this can incur additional costs and typically requires a custom real-time operating system (RTOS), which also lacks reusability and standard interfaces for communicating with the higher layers of the software stack.

[0013] In some examples included in this disclosure, a hardware component is provided as a packet-processing offload engine for the control plane CPU. The hardware component can be used across multiple designs (ASIC or FPGA) and provides a production-quality development environment. To facilitate interaction with higher layers of the software stack, the hardware component includes standardized interfaces. In one example, the hardware component may include one or more cores implementing the Extended Berkeley Packet Filter (eBPF) instruction set.

[0014] Unlike other instruction sets, eBPF is designed to execute secure code within the Linux kernel on a limited number of requests, thus offering particular advantages for offload engines. It features a mature software stack (e.g., compilers, debuggers, etc.) and a golden reference model within the Linux kernel. eBPF applications in the kernel include tracing, monitoring, security, networking, and analytics. The eBPF instruction set is maintained by an active open-source community, and the architecture provides support for hardware offloading. Furthermore, eBPF programs are very simple and resource-constrained, comprising 4 KB of instructions and a fixed-size 512-byte stack, but provide a set of standard interfaces for interacting with other software (e.g., hash tables, histograms). This resource constraint reduces the cost of hardware implementation.

[0015] Fig. Figure 2 shows an exemplary scenario for packet processing by a network switch, according to one aspect of this application. Similar to the Fig. In the switch 100 shown in Figure 1, the switch 200 includes a control plane CPU 202 and a number of switch ASICs, such as the fabric ASIC 204 and the port ASICs 206 and 208. In addition, the switch 200 also includes a number of offload engines (e.g., offload engines 222 and 224). These offload engines are located in the data path between the control plane CPU 202 and the port ASICs. For example, the offload engine 222 is located on data path 226 between the control plane CPU 202 and the port ASIC 206, and the offload engine 224 is located on data path 228 between the control plane CPU 202 and the port ASIC 208. These engines can offload certain packet processing operations (e.g., exception handling) from the control plane CPU 202. Note that the offload engines are hardware-based and can operate at higher speeds compared to the software-based operations of the CPU 202.

[0016] For example, while processing incoming packets, port ASIC 222 may encounter an exception that it cannot handle. Port ASIC 222 then forwards the affected packet to CPU 202 and requests CPU 202 to perform further, more flexible processing. On its way to CPU 202, such a packet reaches offload engine 222, which was previously programmed by CPU 202 to perform flexible processing of the exception packet. After processing, offload engine 222 may return the packet to port ASIC 206 for forwarding and report the processing result to CPU 202. In certain situations, the logic of offload engine 222 may also determine that certain packets require operations that the offload engine cannot handle and allow those packets to pass through without processing. In such situations, these packets are ultimately processed by CPU 202.In some examples, the logic of an offload engine for determining whether a packet should be processed by the offload engine or CPU 202 can be programmed by CPU 202. The ability of offload engines to offload certain operations from CPU 202 reduces the number of packets arriving at CPU 202, increasing efficiency. In addition to processing exception packets, the offload engines can also be programmed to collect analysis information from packet flows and pass aggregated data to higher software layers.

[0017] In addition to the data path (e.g., path 226 or 228) between a port ASIC and the control plane CPU 202, there is also a control path between the corresponding offload engine and the control plane CPU 202. In Fig. 2, the control paths (e.g., paths 230 and 232) are represented by dashed lines. The control path between an offload engine and the control plane CPU 202 enables the CPU 202 to load programs (e.g., eBPF instructions) into the offload engine (e.g., into its instruction memory). More specifically, the CPU 202 can access the context or data memory within the offload engine to write and read state from memory, thereby providing a conduit for configuration or data collection in both directions. Note that the offload engine is different from the Programming Protocol-independent Packet Processors (P4) program, which describes forwarding behavior but does not specify control plane behavior.

[0018] Offload engines differ from embedded CPUs, which can be bulky and consume relatively high levels of power. Unlike embedded CPUs, offload engines do not run an operating system (OS). Instead, they are simple packet processors that run to completion (e.g., processing each packet with a single thread). Eliminating the operating system allows offload engines to be compact and energy-efficient.

[0019] As mentioned earlier, it is advantageous to implement eBPF instructions in offload engines because of their limited set of instructions that can provide standard interfaces. In some examples, the offload engine for the control plane CPU may include a complex of cores that natively execute eBPF instructions.

[0020] Fig. Figure 3 shows an exemplary block diagram of an eBPF engine according to one aspect of this application. The eBPF engine 300 may include a number of eBPF cores (e.g., eBPF core 302), an instruction memory 304, a context memory 306, a control interface 308, a functional support logic block 310, and a number of packet processing hardware accelerators 312.

[0021] Each eBPF core may be a processor that executes eBPF instructions stored in instruction memory 304. An external CPU (e.g., the control plane CPU) may load programs (e.g., eBPF instructions) into instruction memory 304 via control interface 308.

[0022] In the Fig. In the example shown in Figure 3, there are multiple eBPF cores. Since each eBPF core is small (they do not need to run an operating system and therefore have a simpler structure), it is possible to include a large number (e.g., dozens or hundreds) of eBPF cores in the eBPF engine 300. Two different implementations (the parallel implementation and the pipelined implementation) can be used. In the parallel implementation, the multiple eBPF cores can perform the same operation (i.e., executing the same eBPF instructions on different packets) in parallel. In the pipelined implementation, different eBPF cores can execute different instructions (i.e., processing a packet may involve operations performed by multiple cores). It is also possible to divide the eBPF cores into different groups, with some groups handling parallel processing and some groups handling pipelined processing.

[0023] The external CPU can similarly access context memory 306. In some examples, context memory 306 can store status information and data that can be retrieved by the external CPU. In addition, context memory 306 can temporarily store packets that require flexible processing. For example, if the switch ASIC determines that certain packets require processing beyond its capabilities, the switch ASIC forwards such packets to the control plane CPU. Because the eBPF engine 300 is located on the data path between the switch ASIC and the control plane CPU, these packets first arrive at the eBPF engine 300 and are placed in context memory 306. By executing the eBPF instructions, the eBPF core can determine whether processing of a packet should be offloaded to hardware or performed by the control plane CPU.If it is determined that the packet should be processed by the control plane CPU, the packet may pass through the context memory 306 to be sent to the control plane CPU without processing.

[0024] On the other hand, if it is determined that processing of the packet should be offloaded to hardware, the packet may be processed by one or more packet processing hardware accelerators 312.

[0025] The function support logic block 310 manages the offloading functions, including the interaction between the eBPF cores and the packet-processing hardware accelerators 312. In other words, the function support logic block 310 bridges the connection between the eBPF cores and the packet-processing hardware accelerators 312 by providing a hardware interface to each respective hardware accelerator. In conventional eBPF implementations, when a specific operation is to be performed outside the eBPF program, the eBPF program can call an external program using the standard "call" convention, such as a function call. Such software behavior can be mimicked by the hardware using the function support logic block 310. In particular, the eBPF core can execute the calling function as usual (without any modification).After the calling function arrives at the function support logic block 312, it is parsed, and the relevant content (e.g., the packet payload or the header, or both) extracted from the context store 306 can be sent to a suitable hardware accelerator via a corresponding hardware interface at the function support logic block 310. In other words, offloading the packet processing operations to the hardware accelerator 312 can be transparent to the eBPF cores.

[0026] Both the eBPF cores (e.g., eBPF core 302) and the functional support logic 310 can access shared memory areas (e.g., instruction memory 304 and context memory 306) in which states can be stored and read. The layout and access ports of the memories must be organized to be compatible with the operation of the unmodified eBPF programs, but ways must also be found to minimize the memory requirements in the hardware implementation. In other words, the behavior of the eBPF programs (e.g., how they access the memories) can be the same as when the eBPF programs are executed within the Linux kernel. No modification of the eBPF instructions is required. To increase memory efficiency, the instruction memory 304 can be shared by all eBPF cores, instead of allocating a separate memory area to each core, as in Fig. 3. Different cores executing the same code can access the same memory area in which that code is stored. At the same time, the instruction memory 304 can also be configured to be flexibly divided into different areas for storing different codes.

[0027] Packet processing hardware accelerators 312 may include a number of hardware accelerators that perform various packet processing operations, including, but not limited to: packet encryption / decryption, packet encapsulation / decapsulation, packet filtering operations (e.g., TCAM-based packet filtering operations), flow identification operations, data analysis operations, etc.

[0028] Fig. 4A shows an exemplary hardware implementation of an eBPF engine according to one aspect of the present application. In Fig. 4A, the eBPF engine 400 includes an instruction fetch stage 402, an instruction decode stage 404, an execution stage 406, a memory access stage 408, and a write-back stage 410.

[0029] Instruction fetch stage 402 may include an instruction memory 412 and a program counter (PCReg 414). Instruction memory 412 stores the eBPF instruction set, which can be loaded and modified by an external CPU (e.g., in the event of a software upgrade). PCReg 414 contains the address supplied to instruction memory 412. During one clock cycle, the instruction is read from instruction memory 412, and a calculation is performed to determine the next program counter. The eBPF instruction set contains a limited set of instructions. Therefore, instruction memory 412 can be quite small (e.g., 4 KB).

[0030] Instruction decode stage 404 may include a register file 416, sign extension logic blocks 418 and 420, and a control logic block 422. Different bits of the instructions (which are typically 64-bit instructions) may be sent separately to register file 416, sign extension logic blocks 418 and 420, and control logic block 422. For example, the first eight bits of an instruction may contain an opcode sent to control logic block 422, and the next eight bits may be sent to register file 416 to identify two registers to be read. Other bits of the instruction may be extended by sign extension logic blocks 418 and 420. Note that eBPF engine 400 is designed to accommodate instructions of up to 64 bits. However, LDDW (load double words from memory) instructions are an exception to the rule and can be 128 bits long.In one example, the 128-bit LDDW instruction can be recognized and interpreted as two consecutive 64-bit instructions. By interpreting one LDDW instruction as two instructions, the eBPF engine 400 can execute the LDDW instruction without requiring any software modification. This differs from traditional approaches that modify the software instruction to maximize efficiency in hardware.

[0031] The actual calculation takes place in the execution stage 406 and may include an arithmetic logic unit (ALU) 424. To simplify the illustration, other components (e.g., an operand selector) in the execution stage are Fig. 4A not shown.

[0032] In the memory access stage 408, the context memory 426 is accessed. As previously mentioned, the packets to be processed may be temporarily stored in the context memory 426 and processed through the pipeline by loading them into the register file 416 and then used by the ALU 424 for calculations. The result of the calculation may be stored in the context memory 426. In addition to the context memory 426, the memory access stage 406 may also include function support logic 428 and accelerators 430. The function support logic 428 includes hardware interfaces to the accelerators 430 so that certain packet processing operations can be offloaded to the accelerators 430. In the write-back stage 410, the processing results of the instructions write their results, including the results received from the function support logic 428, to the register file 416.

[0033] Fig. 4B illustrates the functional support logic in detail according to one aspect of the present application. The functional support logic 440 may be a hardware logic block including a command interface 442 and a series of hardware interfaces (e.g., hardware interfaces 444-452). The command interface 442 receives commands from the eBPF core along with data to be processed (e.g., a packet to be encrypted). The hardware interfaces 444-452 facilitate the coupling between the functional support logic 440 and a series of hardware accelerators so that the data to be processed can be sent to the appropriate hardware accelerator for processing.For example, an encryption / decryption accelerator 454 is coupled to the functional support logic 440 via the hardware interface 444, an encapsulation / decapsulation accelerator 456 is coupled to the functional support logic 440 via the hardware interface 446, a packet filtering accelerator 458 is coupled to the functional support logic 440 via the hardware interface 448, a flow identification accelerator 460 is coupled to the functional support logic 440 via the hardware interface 450, and a data analysis accelerator 462 is coupled to the functional support logic 440 via the hardware interface 452. Each hardware interface can be specifically designed based on the type and implementation of the coupled hardware accelerator.

[0034] In the Fig. In the example shown in Figure 2, the offload engines are standalone devices placed on the path (e.g., a connecting cable) between a switch ASIC and the corresponding CPU port. Note that in the rare situation where multiple (e.g., two) paths connect the switch ASIC and the CPU's network port, multiple offload engines are required, one per path. This is to ensure that all packets destined for the control plane CPU can be offloaded to the hardware as much as possible.

[0035] An offload engine can not only be a standalone device, but can also be embedded in the port ASIC or the CPU network port. Fig. 5A shows an exemplary network switch according to one aspect of this application. In Fig. 5A, a network switch 500 includes a control plane CPU 502 and a number of switch ASIC chips, such as the fabric ASIC chip 504 and the port ASIC chips 506 and 508. The CPU 502 includes network ports 510 and 512 for communication with the port ASIC chips 506 and 508.

[0036] Each port ASIC contains not only standard packet forwarding logic, but also an eBPF engine. Thus, port ASIC chip 506 contains an eBPF engine 514 and packet forwarding logic 516, and port ASIC chip 508 contains an eBPF engine 518 and packet forwarding logic 520. Packet forwarding logic 516 and 520 may contain standard switch port logic for forwarding packets. eBPF engines 514 and 518 may be similar to the Fig. 3 and can be implemented in a similar manner as in Fig. 4A. Each eBPF engine can be an integrated part of the port ASIC chip.

[0037] Fig. 5B shows an exemplary network switch according to one aspect of this application. In Fig. 5B, a network switch 530 includes a control plane CPU 532 and a number of switch ASIC chips, such as the fabric ASIC chip 534 and the port ASIC chips 536 and 538. The CPU 532 includes network ports 540 and 542 for communication with the port ASIC chips 536 and 538.

[0038] Each network port of the CPU contains not only the standard logic to facilitate communication between the CPU and the port ASICs, but also an eBPF engine. For example, network port 540 contains port logic 544 and an eBPF engine 546, and network port 542 contains port logic 548 and an eBPF engine 550. Port logic 544 and 548 can contain standard network communication logic. eBPF engines 546 and 550 can be Fig. 3 and can be used in a similar manner as in Fig. 4A. Each eBPF engine can be an integrated part of the CPU network port.

[0039] Fig. Figure 6 shows a flowchart illustrating an exemplary packet processing process according to one aspect of the present application. During operation, a network switch receives a packet at one of its switch ports (operation 602). The standard switch ASIC at the switch port determines whether flexible processing of the packet is required (operation 604). Note that the standard switch ASIC is designed to simply forward packets according to a predetermined set of rules and is not flexible enough to handle specific exceptions to the forwarding rule or perform additional operations on the packets, such as encryption / decryption, encapsulation / decapsulation, flow detection, etc.

[0040] If flexible processing is not required, the standard switch ASIC processes the packet (operation 606), and the switch port forwards the packet accordingly (operation 608). However, if flexible processing of the packet is required, the standard switch ASIC forwards the packet to an eBPF engine located on the data path between the standard switch ASIC and the control plane CPU (operation 610). As previously mentioned, a standard switch ASIC on the switch port can be modified to include the eBPF engine (for example, as an integrated logic block within the switch ASIC). Alternatively, the eBPF engine can be a standalone device on the path between the switch ASIC and the control plane CPU or embedded in the network port of the control plane CPU.

[0041] The eBPF engine can then determine whether the load on the control plane CPU is below a predetermined threshold or whether the required processing cannot be offloaded to the hardware (operation 612). Note that the term "CPU load" typically refers to the number of programs using or waiting for the processor core. Here, the term "load" can refer to the number of packets waiting to be processed by the CPU. If the CPU load is below the threshold, the eBPF engine forwards the packet to the CPU (operation 614). Note that if the CPU load is below a predetermined threshold, the CPU's processing of the packet does not impact performance (i.e., does not slow down the packets). On the other hand, the variety of hardware accelerators included in the eBPF engine may be limited and may not meet the current packet processing needs (e.g.,a new type of encryption). In such situations, the control plane CPU can perform the required operations. The CPU then processes the packet (operation 616) and returns the processing result (operation 618). For example, if the operation is to encapsulate the packet, the encapsulated packet is returned from the CPU to the switch ASIC. The switch port then forwards the processed packet (operation 608).

[0042] On the other hand, if the CPU load is not below the threshold and the eBPF engine determines that the operations can be offloaded to hardware, the eBPF engine can offload the required packet processing operations to hardware accelerators (operation 620). In one example, operations that can be offloaded to hardware can include, but are not limited to, packet encryption / decryption, packet encapsulation / decapsulation, packet filtering operations (e.g., TCAM-based packet filtering operations), flow identification operations (which can be performed based on packet headers), data analysis operations (e.g., data mining), etc.It should be noted that the hardware accelerators are part of the eBPF engine, and that a function helper logic block included in the eBPF engine provides interfaces to the hardware accelerators, so that when an unmodified eBPF instruction calls a specific function, the operation is offloaded to a corresponding hardware accelerator. Regardless of whether the operation is to be performed by the hardware accelerator or the control-plane CPU, the eBPF core can execute the same, unmodified eBPF instruction.

[0043] After the operation is performed, the corresponding hardware accelerator returns the result of the packet processing (operation 618), and the switch port forwards the packet accordingly (operation 608).

[0044] In the Fig. 3 - Fig.In the examples shown in Figure 6, the offload engine is an eBPF offload engine, which contains an eBPF core that executes eBPF instructions. In practice, the offload engines can also implement technologies other than eBPF, as long as the offload technology enables the smooth offloading of software operations to hardware accelerators. In particular, the function helper logic contained in the offload engine is designed to mimic the "function call" behavior of the software, so that no change is made to the software code (i.e., the instructions executed by the offload engine) when the actual operation is transferred to the hardware accelerators. This can ensure a smooth transition between software-based operation and hardware-based operation. It should be noted that if the auxiliary functions in the software change (e.g.,(Each kernel version contains newer helper functions), the function helper logic in the offload engine must be redesigned. However, the basic building blocks within the offload engine can be retained.

[0045] One aspect provides a network switch. The network switch includes hardware-based packet processing logic for processing received packets, a processing unit, and an offload engine coupled to the processing unit. The offload engine is configured to offload packet processing operations associated with a subset of the received packets from the processing unit. The offload engine includes a processor core, at least one hardware packet processing accelerator for executing the packet processing operations, and functional support logic for interfacing between the processor core and the hardware packet processing accelerator.

[0046] In a variation of this aspect, the offload engine processor core executes unmodified extended Berkeley packet filter (eBPF) instructions without implementing an operating system.

[0047] In a variation of this aspect, the offload engine and the hardware-based packet processing logic are housed on the same application-specific integrated circuit (ASIC).

[0048] In a variation of this aspect, the processing unit includes a network port that enables communication between the processing unit and the hardware-based packet processing logic, and the offload engine is embedded in the network port.

[0049] In a variation of this aspect, the offload engine comprises one or more of the following elements: a packet encryption / decryption accelerator, a packet encapsulation / decapsulation accelerator, a packet filtering accelerator, a flow identification accelerator, and a data analysis accelerator.

[0050] In a variation of this aspect, the offload engine includes an instruction memory for storing instructions to be executed by the processor core, and the instruction memory is accessible to the processing unit, allowing the processing unit to load instructions into the instruction memory or update instructions stored in the instruction memory.

[0051] In a variation of this aspect, the offload engine includes multiple processor cores that execute instructions in parallel.

[0052] In a variation of this aspect, the offload engine comprises multiple processor cores that execute instructions in a pipelined mode.

[0053] In a variation of this aspect, the offload engine is configured not to offload packet processing operations if it detects that the processing unit load is below a predetermined threshold.

[0054] In a variation of this aspect, the offload engine processor core is configured to interpret a double-word load (LDDW) instruction as two consecutive instructions, allowing the LDDW instruction to be executed without modification.

[0055] One aspect provides a method for processing a network packet by a switch. The method may include: determining, by the switch, whether a received packet requires a packet processing operation external to hardware-based packet processing logic; and forwarding the packet to a processing unit on the switch via an offload engine for the processing unit in response to the packet requiring the packet processing operation. The offload engine includes a processor core, at least one hardware packet processing accelerator, and functional support logic interfacing between the processor core and the hardware packet processing accelerator. The method further includes offloading the packet processing operation to the hardware packet processing accelerator via the functional support logic.

[0056] In a variation of this aspect, offloading the packet processing operation involves executing unmodified extended Berkeley packet filter (eBPF) instructions by the processor core.

[0057] In a variation of this aspect, the offload engine and the hardware-based packet processing logic are housed on the same application-specific integrated circuit (ASIC).

[0058] In a variation of this aspect, forwarding the packet to the processing unit comprises forwarding the packet to a network port on the processing unit, wherein the offload engine is embedded in the network port.

[0059] In a variation of this aspect, the offload engine comprises one or more of the following elements: a packet encryption / decryption accelerator, a packet encapsulation / decapsulation accelerator, a packet filtering accelerator, a flow identification accelerator, and a data analysis accelerator.

[0060] In a variant of this aspect, the method comprises one or more of the following steps: storing instructions to be executed by the processor core in an instruction memory in the offload engine; loading instructions into the instruction memory by the processing unit; and updating instructions stored in the instruction memory by the processing unit.

[0061] In a variation of this aspect, the offload engine includes multiple processor cores that execute instructions in parallel.

[0062] In a variation of this aspect, the offload engine comprises multiple processor cores that execute instructions in a pipelined mode.

[0063] In a variation of this aspect, the method comprises: in response to determining that a load of the processing unit is below a predetermined threshold, bypassing the offload engine to enable the processing unit to perform the packet processing operation.

[0064] In a variation of this aspect, the offload engine processor core is configured to interpret a double-word load (LDDW) instruction as two consecutive instructions, allowing the LDDW instruction to be executed without modification.

[0065] The methods and processes described in the "Detailed Description" section may be embodied as code and / or data that may be stored in a computer-readable storage medium, as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and code stored in the computer-readable storage medium.

[0066] Furthermore, the methods and processes described above can be integrated into hardware modules or devices. The hardware modules or devices can include, but are not limited to, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), dedicated or shared processors that execute a specific software module or piece of code at a specific time, and other known or later developed programmable logic devices. When activated, the hardware modules or devices execute the methods and processes contained within them.

[0067] The foregoing descriptions of examples are for purposes of illustration and description only. They are not intended to be exhaustive or to limit the scope of this disclosure to the forms disclosed. Accordingly, many modifications and variations will be apparent to those skilled in the art.

Claims

[1] A network switch (200, 500, 530) comprising: hardware-based packet processing logic for processing received packets; a processing unit (202, 502, 532) and an offload engine (222, 224, 300, 400, 514, 518, 546, 550) coupled to the processing unit; wherein the offload engine is operable to offload packet processing operations associated with a subset of the received packets from the processing unit; wherein the offload engine comprises a processor core (302) executing a set of unmodified extended Berkeley packet filter (eBPF) instructions without implementing an operating system, one or more hardware packet processing accelerators (312) for executing the packet processing operations, and functional support logic (310, 440) for interfacing between the processor core and the hardware packet processing accelerators; wherein the function helper logic is operable to parse an eBPF function call executed by the processor core and to send information associated with the eBPF function call to a corresponding hardware packet processing accelerator; wherein the offload engine further comprises an instruction memory (304) for storing the unmodified eBPF instructions; wherein the unmodified eBPF instructions are loaded into the instruction memory by the processing unit; and wherein the processor core within the offload engine is configured to access the instruction memory to execute the unmodified eBPF instructions. [2] The network switch of claim 1, wherein the offload engine and the hardware-based packet processing logic are located on the same ASIC (application specific integrated circuit) chip (506, 508). [3] The network switch of claim 1, wherein the processing unit comprises a network port (540, 542) that enables communication between the processing unit and the hardware-based packet processing logic, and wherein the offload engine is embedded in the network port. [4] The network switch of claim 1, wherein the hardware packet processing accelerators include one or more of the following elements: a packet encryption / decryption accelerator (454); a packet encapsulation / decapsulation accelerator (456); a packet filtering accelerator (458); a flow identification accelerator (460) and a data analysis accelerator (462). [5] The network switch of claim 1, wherein the processing unit is further configured to update the unmodified eBPF commands stored in the command memory. [6] The network switch of claim 1, wherein the offload engine comprises multiple processor cores that execute instructions in parallel. [7] The network switch of claim 1, wherein the offload engine comprises multiple processor cores that execute the unmodified eBPF instructions in a pipelined mode. [8] The network switch of claim 1, wherein the offload engine is configured not to offload the packet processing operations if it determines that a load of the processing unit is below a predetermined threshold. [9] The network switch of claim 1, wherein the processor core of the offload engine is configured to interpret a double word load (LDDW) instruction as two consecutive instructions, thereby enabling the LDDW instruction to be executed without modification. [10] A method for processing a network packet by a switch (200, 500, 530), comprising: Determining, by hardware-based packet processing logic on the switch, whether a received packet requires a packet processing operation outside of the hardware-based packet processing logic; in response to the packet requiring the packet processing operation, forwarding the packet to a processing unit (202, 502, 532) on the switch via an offload engine (222, 224, 300, 400, 514, 518, 546, 550) coupled to the processing unit, the offload engine comprising a processor core (302) executing a set of unmodified extended Berkeley packet filter (eBPF) instructions without implementing an operating system, one or more hardware packet processing accelerators (312), and functional support logic (310, 440) for interfacing between the processor core and the hardware packet processing accelerators; Offloading the packet processing operation to a corresponding hardware packet processing accelerator via the function support logic, comprising parsing an eBPF function call executed by the processor core and sending information associated with the eBPF function call to the corresponding hardware packet processing accelerator by the function support logic; wherein the offload engine further comprises an instruction memory (304) for storing the unmodified eBPF instructions; wherein the unmodified eBPF instructions are loaded into the instruction memory by the processing unit; and wherein the processor core within the offload engine is configured to access the instruction memory to execute the unmodified eBPF instructions. [11] The method of claim 10, wherein the offload engine and the hardware-based packet processing logic are located on the same ASIC (application specific integrated circuit) chip (506, 508). [12] The method of claim 10, wherein forwarding the packet to the processing unit comprises forwarding the packet to a network port (540, 542) on the processing unit, wherein the offload engine is embedded in the network port. [13] The method of claim 10, wherein the hardware packet processing accelerators include one or more of the following elements: a packet encryption / decryption accelerator (454); a packet encapsulation / decapsulation accelerator (456); a packet filtering accelerator (458); a flow identification accelerator (460) and a data analysis accelerator (462). [14] The method of claim 10, further comprising: Updating unmodified eBPF instructions stored in instruction memory by the processing unit. [15] The method of claim 10, wherein the offload engine comprises multiple processor cores that execute instructions in parallel. [16] The method of claim 10, wherein the offload engine comprises multiple processor cores that execute the unmodified eBPF instructions in a pipelined mode. [17] The method of claim 10, further comprising: in response to determining that a load of the processing unit is below a predetermined threshold, bypassing the offload engine to enable the processing unit to perform the packet processing operation. [18] The method of claim 10, wherein the processor core of the offload engine is configured to interpret a double word load (LDDW) instruction as two consecutive instructions, thereby enabling the LDDW instruction to be executed without modification.

Images