Patent Application
20080002681
A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.
The following detailed description is merely illustrative in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.
The invention may be described herein in terms of functional and/or logical block components and various processing steps. It should be appreciated that such block components may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions.
To enable portability between single core and multi-core systems, a multicore abstraction layer (MCAL) provides a framework that obscures the operating system executed by the system hardware to higher-level program code. Program code uses the MCAL to access system resources and for inter-process communication rather than accessing the operating system directly. By isolating system-specific code into the MCAL, higher level system code can be made more generic, thereby improving portability across single processor, multi-core processor, and/or multi-processor systems. Access to additional hardware (e.g. hardware co-processors) can also be provided through the abstraction layer, thereby further improving software flexibility and ease of design.
Turning now to the drawing figures and with initial reference now to
The system 100 shown in
Kernel space 101 as shown in
As noted above and below, MCAL 102 suitably contains any hardware-specific code for system 100, and provides for communication between the various handlers 104, 106A-C, 108A-C. To that end, MCAL 102 typically includes a set of containers 110A-C for representing various types of data handler modules 104, 106, 108 (described more fully below). Containers 110A-C are any logical structures capable of facilitating inter-process data communications between modules. These communications structures may include, for example, message queues, shared memory, and/or the like. During system configuration and/or startup (or at any other suitable time), handler modules 104, 106, 108 register with MCAL 102. MCAL 102 subsequently provides abstracted version of the system hardware and/or operating system resources to each handler 104, 106, 108 so that the various handlers need not be customized to the particular hardware present in any particular system. That is, handler modules 104, 106, 108 need not be customized or otherwise specially configured for multi-core or multi-processor operation, since such features are abstracted and provided within MCAL 102. In various embodiments, then, the same code used to implement handlers 104, 106, 108 can be run in both single and multi-core environments, with MCAL 102 concealing the hardware specific features from the various handlers. MCAL 102 also initializes hardware components of system 102 as appropriate; such components may include networking interfaces, co-processors (e.g. special processors providing cryptography, compression or other features), and/or the like. MCAL also manages the downloading of handler code to the CPUs, as well as handler starting, stopping, monitoring, and other features. The various functions carried out by MCAL 102 may vary from embodiment to embodiment.
Classification handler (CH) 104 is any hardware, software or other logic capable of recognizing data packets of various protocols and of assigning a classification to the data packet. This classification may identify the particular data type (e.g. wireless, TCP/IP, RFID, etc) based upon header information or other factors, and may further identify a suitable protocol handler 106A-C or application handler 108A-C for processing the data based upon data type, source, destination or any other criteria as appropriate. Classification module 104 therefore acts as a distribution engine, in a sense, that identifies suitable destinations for the various data packets. In various further embodiments, classification handler 104 may further distribute (or initiate distribution) of data packets to the proper handlers using message send constructs provided by MCAL 102, as appropriate. Although
Protocol handlers (PH) 106A-C are any software modules, structures or other logic capable of managing the data stack of one or more data communications protocols. An exemplary wireless handler 106A, for example, could terminate Open Systems Interconnect (OSI) layer 2 and/or layer 3 encapsulation (using, e.g., the CAPWAP, WISP or similar protocol) for packets received from wireless access points, and may also terminate 802.11, 802.16, RFID or any other wireless or wired protocols, including any security protocols, to extract data packets that could be transferred on a local area or other wired network. Conversely, wireless handler 106A could initiate encapsulation of data received on the wired network for transmittal to a wireless client via a remote access point, as appropriate. In other embodiments, the send and receive processes could be split into separate protocol handlers 106, as desired.
Application handlers (AH) 108A-C are any software programs, applets, modules or other logic capable of hosting any type of application or control path features of one or more protocols. In the example shown in
In operation, then, data packets arriving at a network interface or other source are initially provided to classification handler 104, which assigns a classification to the packet and optionally forwards the packet to the appropriate protocol handler 106A-C and/or application handler 108A-C according to the classification. Inter-process communication and any interfacing to system hardware is provided using MCAL 102.
Turning now to
Data handler modules 104/106/108 may be assigned to the various processors 201, 204 in any manner. In various embodiments, handler modules 104/106/108 are statically assigned to available hardware by pre-configuring the modules loaded at system startup or reset. Alternatively, modules 104/106/108 can be dynamically assigned to reduce any performance bottlenecks that may arise during operation. In such embodiments, MCAL 102 (or another portion of system 100) suitably assigns modules to available processing resources based upon available load. Load may be determined, for example, through periodic or aperiodic polling of the various processing cores 203, through observation of data throughput rates, and/or through any other manner. In various embodiments, MCAL 102 periodically polls each processing core to determine a then-current loading value, and then re-assigns over or under-utilized handler modules 104/106/108 in real time based upon the results of the polling. As noted above, MCAL 202 suitably includes any number of container structures 110A-C for facilitating inter-process communications between each of the various handler modules executing on the various and/or to otherwise abstract the multi-core hardware structure from particular software modules 104, 106, 108 (
With reference now to
In various embodiments, each control and data handling processor contains several “virtual” or logical machines 302A-D that are each capable of acting as a separate processor. In such cases, a software image containing data handlers 104/106/108 is executed within each active logical machine 302A-D as a separate thread that can be processed by data handler. Typically, each processing core 201, 203 includes its own “level 1” data and instruction cache that is available only to threads operating on that core. Memory 305, however, typically represents a memory subsystem that is shared between each of the processing cores 201, 203 found on a common chip. Memory 305 may also provide “level 2” cache that is readily accessible to all of the threads 302A-D running on each of the various processing cores 201, 203.
System 300 suitably includes one or more network interface ports 310A-D that receive data packets from a digital network via a network interface. The network interface may be any sort of network interface card (NIC) or the like, and various systems 300 may have several physical and/or logical interface ports 310A-D to accommodate significant traffic loads. As noted above, data handlers may be assigned to the various processing cores 203A-C and the various processing threads 302A-D using any sort of static or dynamic process.
In many embodiments, a packet distribution engine 308 is provided to initially distribute packets received via the network interface ports 310A-D to the appropriate classification handler 104. Packet distribution engine 308 is any hardware, software or other logic capable of initially providing access to data packets received from ports 310A-D. In various embodiments, packet distribution engine 308 may be implemented in an application specific integrated circuit (ASIC) for increased speed, for example, or the functionality could be readily combined with one or more classification handlers 104 using software or firmware logic. In either case, data packets arriving from network ports 310A-D are directed toward an appropriate classification handler 104 executing on one of the data handler processors 203A-C. This direction may take place in any manner; in various embodiments, each network port 310A-D has an associated classification handler 104 executing as a separate thread 302 on one of the data handling processors 203A-C. Alternatively, packets arriving at any port 310A-D are initially directed toward a common classification handler 104.
Classification, protocol and application handlers 104/106/108 are contained within a software image that is executed on each of the available data handling processors 203A-C, and operating system software is executed on the control plane 201. That is, the various data handlers 104/106/108 can be combined into a common software image so that each thread 302A-D on each processor 203A-C executes common software to provide the various data handling functions. This feature is optional, however, and not necessarily found in all embodiments.
As noted above, classification handlers 104 suitably classify and dispatch incoming data packets to an appropriate destination handler, such as a operating system thread on control processor 301 or a protocol or application handler on data handling processors 303A-C. Each protocol handler 106 typically runs a thread of a specific protocol supported by system 300 (e.g. 802.11 wireless, RFID, 802.16, any other wireless protocol, and/or any security protocols such as IPSec, TCP/IP or the like), and each application handler 108 runs an appropriate processing application to provide a feature such as location tracking, RFID identification, secure sockets layer (SSL) encryption and/or the like. As described above, protocol handlers 106 typically provide processing of actual data, whereas application handlers 108 typically provide control-type functionality. As noted above, MCAL 102 (
In various further embodiments, a co-processor module 304 may also be provided. This module may be implemented with custom hardware, for example, to provide a particular computationally-intense feature such as cryptographic functions, data compression and/or the like. Co-processor module 304 may be addressed using the message send and receive capabilities of the MCAL 102 just as the various threads 302A-D executing on the multiple processing cores 301, 303A-C.
Referring to
Turning now to
As data packets are received at the message queue (step 502), the MCAL 102 first determines the appropriate handler to process the received message (step 506). In the event that the data packet is newly received from the network port (e.g. ports 310A-C in
In various embodiments that maintain a common code image running in all threads, the classification handler 104, protocol handlers 106 and application handlers 108 are optionally invoked within the packet routing function 300 (step 512). In such embodiments, a switch-type data structure or the like identifies the destination as the classification handler 104, the appropriate protocol hander 106A-C for the particular protocol carried by the data packet, or the application handler 108A-C for the application type identified by the data packet. This feature is not required in all embodiments; to the contrary, step 512 may be omitted entirely in alternate but equivalent embodiments in which a common code image is not provided.
Upon determination of the appropriate destination for the data packet, the message is directed or “sent” (step 514) using any appropriate technique. The term “sent” is used colloquially here because the entire data packet need not be transported to the receiving module. To the contrary, a pointer to the packet or packet descriptor (see below) in memory 305 could be transmitted to the receiving module without transporting the packet itself, or any other indicia or pointer to the appropriate data could be equivalently provided.
Process 500 may be repeated as appropriate (step 516). In various embodiments, the “packet receive” feature is a blocking function provided by the MCAL 102 that holds execution of process 500 at step 502 (or another appropriate point) until a message is received in the message queue. As noted above, message queuing, as well as message send and receive features are typically provided within the MCAL 102 to make use of operating system and hardware-specific features.
Turning now to
Process 600 generally identifies packets as wireless (steps 602, 604, 606), RFID (steps 608, 610), application (steps 612, 614) or management/control (steps 616, 618, 620). These determinations are made based upon any appropriate factors, such as header information contained within the data packet itself, the source of the packet, the nature of the packet (e.g. packet size), and/or any other relevant factors. As the type of packet is identified, a classification is assigned to the packet (steps 606, 610, 614, 618, 620) to direct the packet toward its appropriate destination processing module. In the example of
Classification process 600 also involves performing preprocessing (step 622) on the data packet. Pre-processing may involve creating and/or populating the data descriptor 407 for the packet described in conjunction with
With final reference now to
Wireless switch 700 suitably includes multiple processing cores 201 and 203A-C, with core 201 running an operating system (e.g. LINUX) in threads 302C-D. Application handlers 108A-B providing control path handling for wireless access and RFID protocols, respectively, are shown executing within threads 302A-B of processing core 201, although alternate embodiments may move the application handlers 108A-B to available threads 302 on data handling cores 303A-C as appropriate. Threads 302A-B of processor 203A are shown assigned to classification handlers 104A-B, and threads 302C-D of processor 203A are shown assigned to protocol handlers 106A associated with RFID protocols. The remaining threads 302A-D on processing cores 303C-D are shown assigned to protocol handlers 106 for wireless communications, with each thread having assigned wireless access points (APs). Thread 302A of processor core 203B, for example, is assigned to process wireless data emanating from access points 1 and 9, whereas thread 302B of core 203B processes wireless data emanating from APs 2 and 10. Access points need not be assigned to particular protocol handlers 106 in this manner, but doing so may aid in load balancing, troubleshooting, logging and other functions.
In operation, then data packets arrive at wireless switch 700 via one or more network interface ports 310A-D from a local area or other digital network. These packets are initially directed toward a classification handler (e.g. handlers 104A-B on processing core 203A) by packet distribution engine 308. Alternatively, distribution engine 308 provides a portion of the classification function by storing the received packet in memory 305, and providing a pointer to the relevant packet to classification handler 104A or 104B. The classification handler 104, in turn, classifies the data packet as wireless, RFID, control and/or the like, and selects and appropriate protocol handler 106 or application handler 108 as appropriate. The relevant handler subsequently receives a pointer or other notification of the packet's location in memory 105, and processes the packet normally. Optionally, MCAL 102 monitors the loads on each processing core during operation, and re-assigns one or more handlers to keep loads on the various processing cores relatively balanced during operation.
As noted at the outset, the MCAL framework allows for efficient code design, since code can be designed to work within the framework, rather than being created for particular hardware platforms. Moreover, legacy code can be made to work with emerging hardware platforms by simply modifying the code to work within the abstraction constructs rather than addressing the hardware directly. Other embodiments may provide other benefits as well.
While at least one example embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of equivalents exist. It should also be appreciated that the example embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the invention as set forth in the appended claims and the legal equivalents thereof.
