TECHNICAL FIELD

[0001] This disclosure relates to flow pinning in a server on a chip.

BACKGROUND

[0002] In computing networks, an Ethernet interface can receive packets from many different Ethernet connections or flows. In some systems, these flows of packets are processed serially, as they are received by a dedicated processor. In other traditional systems, these flows of packets are processed by peripheral network interface cards that enqueue the packets and/or flows to specific queues that are associated with a given CPU (central processing unit) in a multi-core processor. Network interface cards are expensive however, both in terms of cost, power, and latency, as well as taking up a lot of space in a system.

[0003] The above-described description merely provides a contextual overview of current techniques for performing flow pinning in a system on a chip and is not exhaustive.

SUMMARY

[0004] In an example embodiment, a server on a chip comprises a first data structure, executed by a processor configured for extracting a metadata string from a packet. The server on a chip includes a second data structure, executed by the processor, configured for associating the packet with a result database based on the metadata string. The server on a chip includes an Ethernet direct memory access engine configured for assigning the packet to a queue based on the result database, wherein the queue is associated with a respective core of a multiprocessor.

[0005] In another example embodiment, a computer implemented method for flow pinning a packet stream to a core of a multiprocessor comprises extracting, by a processor executing a first data structure, a metadata string from a packet. The method comprises associating, by the processor executing a second data structure, the packet with a respective result database based on the metadata string. The method includes assigning, by an Ethernet direct memory access engine, the packet to a queue based on the result database, wherein the queue is associated with a respective core of the multiprocessor.

In another example embodiment, a server on a chip comprises means for extracting a metadata string from a packet and means for associating the packet with a respective core of a multiprocessor based on the metadata string. The server on a chip can include means for assigning the packet to a queue associated with the processor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a block diagram illustrating an embodiment of a system that performs flow pinning.

[0007] FIG. 2 is a block diagram illustrating an embodiment of a system that performs flow pinning.

[0008] FIG. 3 is a block diagram illustrating an embodiment of a system that performs metadata extraction from a packet header.

[0009] FIG. 4 is a block diagram illustrating an embodiment of a system that performs packet enqueuing.

[0010] FIG. 5 is a block diagram illustrating an embodiment of a system that performs flow pinning.

[0011] FIG. 6 illustrates a flow diagram of an embodiment of a method for flow pinning.

[0012] FIG. 7 illustrates a flow diagram of an embodiment of means for extracting a metadata string from a packet data.

[0013] FIG. 8 illustrates a flow diagram of an embodiment of means for associating packet with a processor based on a metadata string.

[0014] FIG. 9 illustrates a flow diagram of an embodiment of means for assigning a packet to a queue associated with a processor. [0015] FIG. 10 illustrates a block diagram of an electronic computing environment.

[0016] FIG. 11 illustrates a block diagram of a data communication network.

DETAILED DESCRIPTION

[0017] Various embodiments provide for a system on a chip or a server on a chip that performs flow pinning, where packets or streams of packets are enqueued to specific queues, wherein each queue is associated with a

respective core in a multiprocessor/multi-core system or server on a chip. With each stream of packets, or flow, assigned to a particular processor, the server on a chip can process and intake packets from multiple queues from multiple streams from the same single Ethernet interface in parallel. Each of the queues can issue interrupts to their assigned processors, allowing each of the

processors to receive packets from their respective queues at the same time. Packet processing speed is therefore increased by receiving and processing packets in parallel for different streams.

[0018] Performing flow pinning in this way, where each queue is associated with a respective core allows the throughput of incoming traffic with multiple streams to be increased. Cache and CPU utilization are also increased, as each core is used, and each core can access its own cache memory. This allows hardware costs to be reduced, while efficiently increasing system throughput.

[0019] FIG. 1 illustrates a system 100 that performs flow pinning in accordance with embodiments described herein. System 100 includes a system and/or server on a chip (SoC) 102 that includes an Ethernet interface 104.

Ethernet interface 104 receives incoming packets over a network. The packets can form one or more streams or flows of data that are associated with one or more other computing devices on the network. In some embodiments, multiple flows of packets can be received from a single computing device, and in other embodiments, multiple flows of packets can be received from corresponding computing devices. The computing devices that the packets are received from include, but are not limited to, routers, switches, directly from other SoCs, and the packets can be received via the local network, intranet, or Internet. In some embodiments, SoC 102 can include multiple Ethernet interfaces.

[0020] Ethernet interface 04 can pass the streams and/or flows of packets to a flow pinning component 106. Based on layer 3 and/or layer 4 header data and/or metadata information associated with the packets, the flow pinning component 106 can associate flows of packets with one or more cores of system CPU 110. Each flow can be assigned to a respective core of system CPU 110, or alternatively, each of core of system CPU 110 can be assigned one of, or a set of, the packet streams received at the Ethernet interface 104.

[0021] Once the streams/flows of packets are assigned to respective cores of system CPU 110, the flow pinning component 106 can pass packets or packet header information to queue manager 118, which enqueues the packet and/or packet header information into queues 112, 114, 116, and 118 that are each associated with a respective one of the cores of system CPU 110. In an embodiment, packets are stored in a memory (shown in more detail in FIG. 4 and FIG. 5) while descriptor messages associated with packets are enqueued in queues 112, 114, 116, and 118. The descriptor messages, when system CPU 110 receives their interrupts from queue manager 108, provide information about memory address of packets that were stored in memory.

[0022] While the embodiment shown in FIG. 1 depicts 4 cores in system CPU 110, in other embodiments, other numbers of cores are possible, and the number of queues can correspond to the number of cores.

[0023] FIG. 2, illustrates a block diagram of an embodiment of a system 200 that performs flow pinning. System 200 includes a flow pinning component 202 (e.g. flow pinning component 106) that can be configured for associating packets and/or packet streams with respective cores based on metadata associated with packets.

[0024] Flow pinning component 202 can include first data structure 206 that in an embodiment can be a patricia tree. Patricia tree 206 can be a space optimized tree data structure where each node with only one child is merged with its child. Patricia trees in general are useful for constructing associative arrays with keys that can be expressed as strings. In an embodiment of the disclosure, patricia tree 206 can be configured for extracting a metadata string from a packet or packet header. The metadata string extracted by patricia tree 206 can be a 4- tuple string that includes a source internet protocol address, a destination internet protocol address, a source port and a destination port. Patricia tree 206 can be preprogrammed with what packet data it needs to extract, and in other embodiments can extract a metadata string with other values. In an

embodiment, the metadata string can be a 12 byte string of data, but other sizes of metadata strings are possible, where the size of the metadata strings can depend on the information that is extracted. In an embodiment, AVL search tree 204 can be preprogrammed with all the supporting sessions, current and otherwise.

[0025] In an embodiment, patricia tree 206 and flow pinning component 202 receive the packet headers alone while the packets are held until AVL search tree 204 determines which buffer pools to copy the packets to. In other embodiments, flow pinning component 202 receives the packets, and on onboard Ethernet direct memory access engine copies the packets to the memory based on the results of the AVL search tree 204 determination.

[0026] FIG. 3 illustrates an embodiment of a system 300 that performs metadata extraction from a packet header. System 300 provides additional details for metadata string extraction described in reference to FIG. 2. Patricia tree 304 receives a packet header 302. The packet header can contain information about where the packet originated from, where it is headed, and its mode of transportation. Patricia tree 304, based on a preprogrammed

determination of the type of data to extract, can then extract, and form a metadata string of 4 values (shown as [W,X,Y,Z] in packet header 306). The values [W,X,Y,Z] can correspond to source IP address, destination IP address, source port, and destination port. [0027] In other embodiments the values can correspond to other information about the packets. Additionally, in other embodiments, the metadata string can include fewer than 4 values, or greater than 4 values.

[0028] FIG. 4 illustrates an embodiment of a system 400 that performs packet enqueuing. System 400 includes SoC 402 that receive packet 404 via SoC 402's Ethernet interface. Packet 404 includes a packet header 406 with a metadata string [W,X,Y,Z] that a patricia tree (e.g., patricia tree 206 and 304) has extracted. AVL search tree 410 uses the metadata string extracted by the patricia tree to determine the associated result database 414 for packet header 406 and packet 404.

[0029] The associated result databases include the information such as which free buffer pool (418, 420, 422, and/or 422) in a memory 416 to copy the packet to, and which of the queues in which to enqueue the message to inform the CPU of a new packet. AVL search tree 410 thus correlates the source and destination addresses and the source and destination ports with the result database 414 in order to determine which core of the CPU the packet 404 should be associated with and/or otherwise assigned to. In an embodiment, AVL search tree 410 can be preprogrammed with all supporting sessions, current and otherwise.

[0030] Once AVL search tree 410 determines which result database 414 packet 404 and packet header 406 are associated with, Ethernet DMA engine 412 can be configured to assign and/or copy packet 404 to buffer pool 418, 410, 422, or 424 that packet 404 is associated with. Each of buffer pools 418, 410, 422, and 424 can be associated with one or more of the respective cores of the system CPU.

[0031] The Ethernet DMA engine 412 can also be configured to assign the packet to a queue based on the result database, wherein the queue is associated with a respective core of the CPU. Once assigned, Ethernet DMA engine 412 enqueues a descriptor message to the assigned queue.

[0032] FIG. 5 illustrates an embodiment of a system 500 that performs flow pinning. System 500 includes SoC 502 that receive a packet via SoC 402's Ethernet interface. The packet can includes a packet header with a metadata string [W,X,Y,Z] that a flow pinning component 506 (e.g. patricia tree 206 or 304 and AVL search tree 204 or 410) can extract and be used to associate the packet with a result database and buffer pool in memory 504.

[0033] An Ethernet DMA engine on SoC 502 (not shown) can then copy the packet to the associated buffer pool in memory 504, while also sending a descriptor message to queue manager 508. The descriptor message can be enqueued in one of queues 512, 514, 516, or 518 that correspond to the core of system CPU 510 that the packet has been assigned to. Each of queues 512, 514, 516, and 518 can be configured to issue a unique interrupt to their respective core of system CPU 510. Once interrupted, the descriptor message provides details about the presence of the packet, and where it is located in memory 504.

[0034] SoC 502 and its components are capable of receiving multiple packets in parallel. As the different flows are simultaneously received, descriptor messages are enqueued in queues 512, 514, 516, and 518 in parallel, and thus each of the cores of system CPU 510 receive their associated packet streams in parallel. This avoids the need for using global locking to prevent multiple cores reading a single queue since there are multiple queues, each dedicated to each processor of system CPU 510.

[0035] FIGs. 6-9 illustrate processes in connection with the

aforementioned systems. The process in FIG. 6-9 can be implemented for example by systems 100, 200, 300, 400, and 500 and illustrated in FIGs. 1-5 respectively. While for purposes of simplicity of explanation, methods are shown and described as a series of blocks, it is to be understood that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methods described hereinafter. [0036] FIG. 6 illustrates a flow diagram of an embodiment of a computer implemented method for performing flow pinning of a packet stream to a core of a multiprocessor.

[0037] Method 600 can start at 602, where extraction of a metadata string from a packet can be performed by a first processor executing a first data structure. The first data structure can be a patricia tree (e.g., patricia tree 206 or 304). The patricia tree can be a space optimized trie data structure where each node with only one child is merged with its child. Patricia trees in general are useful for constructing associative arrays with keys that can expressed as strings. In an embodiment, the patricia tree can be configured for extracting a metadata string from a packet or packet header. The metadata string extracted by the patricia tree can be a 4-tuple string that includes a source internet protocol address, a destination internet protocol address, a source port and a destination port. The patricia tree can be preprogrammed with what packet data it needs to extract, and in other embodiments can extract a metadata string with other values.

[0038] At 604, the packet can be associated with a respective result database by the processor executing a second data structure, wherein the associating is based on the metadata string. The second data structure can be a AVL search tree (e.g., AVL search tree 204 or 410). The AVL search tree is a second data structure that then uses the metadata string extracted by the patricia tree to determine the associated result database for each packet/packet header. The associated result databases include the information such as which free buffer pool in a memory to copy the packet to, and which of the queues in which to enqueue the message to inform the CPUs of a new packet. The AVL search tree thus correlates the source and destination addresses and the source and destination ports with the result databases in order to determine which CPU the packet should be associated with and/or otherwise assigned to. In an

embodiment, the AVL search tree associates the packet with the associated result database based on indexing a lookup table with the metadata string. [0039] At 606, the packet can be assigned, by an Ethernet DMA engine (e.g., Ethernet DMA engine 412) to a queue based on the result database, wherein the queue is associated with a respective core of a multiprocessor. The Ethernet DMA engine can copy the packet to a free buffer pool determined by the result database, and also enqueue in the queues a descriptor message for the CPUs. The descriptor message provides details about the presence of the packet, and where it is located in the memory.

[0040] FIG. 7 illustrates a flow diagram of an embodiment of means for extracting a metadata string from a packet data. At 702, a packet is received from a MAC module of an Ethernet interface (e.g., Ethernet interface 104). The Ethernet interface can have one or more Ethernet lines attached to it, and in an embodiment, can also be coupled to a wireless (e.g., WIFI 802.11a/b/g/n/ac) adapter. The Ethernet interface can receive incoming packets over a network. The packets can form one or more streams or flows of data that are associated with one or more other computing devices on the network. In some

embodiments, multiple flows of packets can be received from a single computing device, and in other embodiments, multiple flows of packets can be received from corresponding computing devices. The computing devices that the packets are received from can include one or more of routers, switches, directly from other SoCs, and the packets can be received via the local network, intranet, or Internet.

[0041] At 704, a header of the packet can be fed into a patricia tree. At 706, a metadata string is extracted from the header of the packet based on a predetermine programming of the patricia tree. The metadata string extracted by the patricia tree can be a 4-tuple string that includes a source internet protocol address, a destination internet protocol address, a source port and a destination port.

[0042] FIG. 8 illustrates a flow diagram of an embodiment of a means for associating the packet with a respective processor based on the metadata string. At 802, a metadata string is received that specifies a source IP, a destination IP, a source port, and a destination port. This information can be used to determine where the packet originated from, the intended recipient, also something about the nature of the packet contents (based on the port).

[0043] At 804, an associated results database is looked up based on the metadata string. The lookup can be performed by an AVL search tree data structure. In an embodiment, the AVL search tree looks up one single entry per flow, and can be programmed with all the supporting sessions.

[0044] At 806, an associated processor can be determined based on the associated results table. The AVL search tree can associated the packet with the based on indexing a lookup table with the metadata string.

[0045] FIG. 9 illustrates a flow diagram of an embodiment of means for assigning the packet to a queue associated with the processor. At 902, an associated results data base is determined based on the metadata string. The AVL search tree can associated the packet with the based on indexing a lookup table with the metadata string.

[0046] At 904, a descriptor queue can be determined based on the metadata string, wherein the descriptor queue is associated with a processor. By correlating the metadata string with the associated results database, the processor that the packet belongs to, or should be assigned to can be

determined. Since each queue is associated with a respective processor, the packet can be delivered to the appropriate descriptor queue.

[0047] At 906, a message is sent to the descriptor queue indicating that a packet has arrived. The message can be sent by an Ethernet DMA engine, and can indicate the location of the packet, and which buffer pool the packet has been stored in.

[0048] Advantageously, the techniques described herein can be applied to any device where it is desirable to facilitate the execution of flow pinning.

Therefore, handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the various non- limiting embodiments. Accordingly, the below general purpose remote computer described below in FIG. 9 is but one example, and the disclosed subject matter can be implemented with any client having network/bus interoperability and interaction. Thus, the disclosed subject matter can be implemented in an environment of networked hosted services in which very little or minimal client resources are implicated, e.g., a networked environment in which the client device serves merely as an interface to the network/bus, such as an object placed in an appliance.

[0049] FIG. 10 illustrates an example of a computing system environment 1000 in which aspects of the disclosed subject matter can be implemented, although the computing system environment 1000 is only one example of a computing environment for a device and is not any intended limitation. Neither should the computing environment 1000 be interpreted as having any

dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 1000.

[0050] FIG. 10 depicts an exemplary device for implementing the disclosed subject matter includes a general-purpose computing device in the form of a computer 1010. Components of computer 1010 may include any of a processing unit 1020, a system memory 030, and a system bus 1021 that couples various system components including the system memory to the processing unit 1020.

[0051] Computer 1010 typically includes a variety of computer readable media which can be used to store the desired information and which can be accessed by computer 1010.

[0052] The computer 1010 can operate in a networked or distributed environment using logical connections to one or more other remote computer(s), such as remote computer 1070, which can in turn have media capabilities different from device 1010. The remote computer 1070 can be a personal computer, a server, a router, a network PC, a peer device, personal digital assistant (PDA), cell phone, handheld computing device, a projection display device, a viewing device, or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 1010. The logical

connections depicted in FIG. 10 include network 1071 , such local area network (LAN) or a wide area network (WAN), but can also include other networks/buses, either wired or wireless. Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets and the Internet.

[0053] FIG. 11 provides a schematic diagram of an exemplary networked or distributed computing environment. Each computing object 1110, 1112, etc. and computing objects or devices 1120, 1122, 1124, 1126, 1128, etc. can communicate with one or more other computing objects 1110, 1112, etc. and computing objects or devices 1120, 1122, 1124, 1126, 1128, etc. by way of the communications network 1142, either directly or indirectly.

[0054] As another example, an architecture can include an arrangement of electronic hardware (e.g., parallel or serial transistors), processing instructions and a processor, which implement the processing instructions in a manner suitable to the arrangement of electronic hardware.

[0055] The disclosed subject matter can be implemented as a method, apparatus, or article of manufacture using typical manufacturing, programming or engineering techniques to produce hardware, firmware, software, or any suitable combination thereof to control an electronic device to implement the disclosed subject matter. In addition, the media can include non-transitory media, or transport media. In one example, non-transitory media can include computer readable hardware media.