EP2035928A2 - Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire - Google Patents

Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire

Info

Publication number
EP2035928A2
EP2035928A2 EP07799125A EP07799125A EP2035928A2 EP 2035928 A2 EP2035928 A2 EP 2035928A2 EP 07799125 A EP07799125 A EP 07799125A EP 07799125 A EP07799125 A EP 07799125A EP 2035928 A2 EP2035928 A2 EP 2035928A2
Authority
EP
European Patent Office
Prior art keywords
handler
data packet
protocol
handlers
classification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07799125A
Other languages
German (de)
English (en)
Inventor
Zeljko Bajic
Ajay Malik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Symbol Technologies LLC
Original Assignee
Symbol Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/479,687 external-priority patent/US20080002681A1/en
Priority claimed from US11/479,686 external-priority patent/US20080002702A1/en
Application filed by Symbol Technologies LLC filed Critical Symbol Technologies LLC
Publication of EP2035928A2 publication Critical patent/EP2035928A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Definitions

  • the present invention generally relates to computing devices, and, more particularly, to processing data packets in computing devices that incorporate single or multiple processing cores.
  • Wireless switches are now commonly used to provide access to digital networks (such as the Internet or a corporate/campus network) via various wireless access points.
  • a wireless switch remains in communication with one or more wireless access points via the network to facilitate wireless communications between the access point and digital network.
  • a wireless switch infrastructure based upon products available from SYMBOL TECHNOLOGIES INC. of San Jose, California is shown in United States Patent Publication No. 2005/0058087A1.
  • network infrastructure devices commonly include a network interface, a processor, digital memory and associated software or firmware instructions that direct the transfer of data from a source to a destination.
  • network infrastructure devices have historically been built using commercially-available microprocessor chips, such as those produced and sold by INTEL CORP. of Santa Clara, California, FREESCALE SEMICONDUCTOR CORP. of Austin, Texas, AMD CORP. of Sunnyvale, California, INTERNATIONAL BUSINESS MACHINES of Armonk, New York, and/or RAZA MICROELECTRONICS INC. of Cupertino, California, as well as many others.
  • microprocessor and microcontroller circuitry have been significant.
  • an emerging trend in microprocessor design is the so-called "multi-core" processor, which effectively combines the circuitry of two or more processors onto a common semiconductor die.
  • Many conventional data processing systems that are based upon single processing cores can be limited in throughput in comparison to systems built upon multiple cores. By combining the power of multiple processing cores, however, the speed and efficiency of the computing chip is increased significantly.
  • MCAL multicore abstraction layer
  • a classification handler initially classifies the data packet.
  • a plurality of protocol handlers each associated with a data protocol processes the data packet if the classification of the data packet matches the data protocol associated with the protocol handler, and one of several application handlers each associated with a user applications processes the data packet if the classification of the data packet matches the user application associated with the application handler.
  • the MCAL is configured to send the data packet to the classification handler after the packet is initially received, and to subsequently direct the packet toward one of the protocol or application handlers in response to the classification of the data packet.
  • the MCAL contains a set of the containers for handlers. Real application, protocol and classification handlers register with MCAL and are modules developed outside of the MCAL. See the attached figure with containers. BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram of an exemplary embodiment of an abstracted packet processing system
  • FIG. 2 is a block diagram of an exemplary embodiment of an abstracted packet processing system executing across multiple processing cores
  • FIG. 3 is a block diagram of a multi-core packet processing system
  • FIG. 4 is a block diagram of an exemplary memory allocation scheme
  • FIG. 5 is a flowchart of an exemplary process for processing data packets
  • FIG. 6 is a flowchart of an exemplary classification process
  • FIG. 7 is a block diagram of an exemplary implementation of a multi-core wireless switch.
  • a multicore abstraction layer 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.
  • 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.
  • an exemplary data processing system 100 suitably includes an abstracted operating system layer 102, a classification handler 104, a protocol handler 106A-C for each communications protocol handled by system 100, and an application handler 108 A-C for each control application executing on system 100.
  • application handlers 108A-C process data relating to control functions
  • protocol handlers 106A-C manage data simple data transactions.
  • system 100 is shown as a wireless switch device capable of routing data packets formatted according to wireless protocols (e.g.
  • RFID radio frequency identification
  • the system 100 shown in FIG. 1 could be implemented within any conventional single-processor general-purpose computing system that executes any suitable operating system.
  • the LINUX operating system for example, is freely available from a number of commercial and non-commercial sources, and is highly configurable to facilitate the features described herein.
  • Equivalent embodiments could be built upon any version of the MacOS, SOLARIS, UNIX, WINDOWS or other operating systems. Each of these operating systems provide kernel space 101 as well as user space 103 as appropriate. In other embodiments, however, it is not necessary to separate kernel and user space. To the contrary, equivalent embodiments to those described above could be implemented within any sort of operating system framework, including those with "flat" memory architectures that do not differentiate between kernel and user space. In such embodiments, the MCAL 102 and the various handlers would all reside within the flat memory space.
  • Kernel space 101 as shown in FIG. 1 is any operating system portion capable of providing a multicore abstraction layer (MCAL) 102 to facilitate communication between hardware and software. Kernel 101 also provides software facilities that are provided to applications executing in user space 103 such as process abstractions, interprocess communication and system calls. Again, various equivalent embodiments may not differentiate between kernel space 101 and user space 103, but may nevertheless provide the functionality of MCAL 102 within any convenient memory addressing structure.
  • MCAL 102 suitably contains any hardware-specific code for system 100, and provides for communication between the various handlers 104, 106A-C, 108A-C.
  • MCAL 102 typically includes a set of containers 11 OA-C for representing various types of data handler modules 104, 106, 108 (described more fully below).
  • Containers 11 OA-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.
  • 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.
  • 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.
  • 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 108 A-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.
  • 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 108 A-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
  • 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.
  • FIG. 1 shows only one classification handler 104, alternate embodiments may include two or more classification handlers 104 as desired. Additional detail about an exemplary classification handler 104 is provided below in conjunction with FIG. 6.
  • 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 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.
  • OSI Open Systems Interconnect
  • 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.
  • the send and receive processes could be split into separate protocol handlers 106, as desired.
  • Application handlers (AH) 108 A-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.
  • wireless application handler 108 A processes control functions (e.g. 802.11 signaling and management functions ( authentication, association etc), 802. Ix authentication, administrative functions, logging, and the like) associated with the transfer of wireless (e.g. 802.11) data.
  • control functions e.g. 802.11 signaling and management functions ( authentication, association etc), 802. Ix authentication, administrative functions, logging, and the like
  • Multiple application handlers 108 could be provided for separate control features, if desired.
  • classification handler 104 assigns a classification to the packet and optionally forwards the packet to the appropriate protocol handler 106A-C and/or application handler 108 A-C according to the classification.
  • Inter-process communication and any interfacing to system hardware is provided using MCAL 102.
  • an exemplary implementation of a multi-core data processing system 200 suitably includes a control processor 201 in addition to one or more data handling processors 203 A-C.
  • Control processor 201 typically executes the base operating system (e.g. LINUX or the like), whereas the data handling processors 203A-C execute the various handler logic (e.g. classification handler 104, protocol handler 106, application handler 108 shown in FIG. 1).
  • the overall throughput of system 200 can be markedly improved in many embodiments.
  • processor can refer to a physical processor, to a processing core of a multi-core processing chip, or to a so-called “virtual machine” running within a processor or processing core. That is, the MCAL 102 is created to adapt system 200 to available hardware so that the individual handler modules 104, 106, 108 need not be individually tailored to the particular hardware environment used to implement system 200. Similarly, any number of control and/or data handling processors 201, 203 could be used in a wide array of alternate embodiments.
  • Data handler modules 104/106/108 may be assigned to the various processors 201, 204 in any manner.
  • handler modules 104/106/108 are statically assigned to available hardware by pre-configuring the modules loaded at system startup or reset.
  • modules 104/106/108 can be dynamically assigned to reduce any performance bottlenecks that may arise during operation.
  • 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.
  • 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.
  • MCAL 202 suitably includes any number of container structures 11 OA-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 (FIG. 1) as appropriate.
  • FIG. 3 an exemplary data processing system 300 is shown in increasing detail.
  • This system 300 suitably includes separate processors 201, 203 A-C for control and data handling functions (respectively), with each processor 201, 203 executing any number of concurrent threads 302 A-D as shown.
  • System 300 also includes a digital memory 305 such as any sort of RAM, ROM or FLASH memory for storing data and instructions, in addition to any available mass storage device such as an sort of magnetic or optical storage medium.
  • An optional coprocessor 304 may be provided to perform specialized tasks such as cryptographic functions, compression, authentication and/or the like.
  • the various components of system 300 intercommunicate with each other via any sort of logical or physical bus 306 as appropriate.
  • each control and data handling processor contains several "virtual" or logical machines 302A-D that are each capable of acting as a separate processor.
  • a software image containing data handlers 104/106/108 is executed within each active logical machine 302 A-D as a separate thread that can be processed by data handler.
  • 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 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 302 A-D running on each of the various processing cores 201, 203.
  • System 300 suitably includes one or more network interface ports 31 OA-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 31 OA-D to accommodate significant traffic loads.
  • NIC network interface card
  • data handlers may be assigned to the various processing cores 203 A-C and the various processing threads 302 A-D using any sort of static or dynamic process.
  • a packet distribution engine 308 is provided to initially distribute packets received via the network interface ports 31 OA-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 31 OA-D.
  • 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 31 OA-D are directed toward an appropriate classification handler 104 executing on one of the data handler processors 203 A- C.
  • ASIC application specific integrated circuit
  • each network port 31 OA-D has an associated classification handler 104 executing as a separate thread 302 on one of the data handling processors 203 A-C.
  • packets arriving at any port 31 OA-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 203 A-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 302 A-D on each processor 203 A-C executes common software to provide the various data handling functions. This feature is optional, however, and not necessarily found in all embodiments.
  • 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 303 A- 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.
  • 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
  • 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.
  • SSL secure socket
  • protocol handlers 106 typically provide processing of actual data
  • application handlers 108 typically provide control-type functionality.
  • MCAL 102 assigns the various processors 201, 203 and threads 302 to each data handler 104/106/108 on a static, dynamic or other basis as appropriate.
  • MCAL 102 typically maps each handler to the same processor 201 that is running the operating system.
  • MCAL 102 may physically reside within either processor 201, or any of processors 203 A-C.
  • the various functions performed by the MCAL 102 can be split across the various processors 201, 203 as appropriate.
  • 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 302 A-D executing on the multiple processing cores 301, 303 A-C.
  • an exemplary memory and addressing scheme 600 includes a pool 405 of memory space suitable for storing received data packets 409A-E, along with a packet descriptor 407 that contains a brief summary of relevant information about the data packet itself.
  • This descriptor 407 may be created, for example, by a classification handler 104 (FIGS. 1-4), and includes such information as packet type 404, a pointer 406 to a source address, a pointer 408 to a destination address, a pointer 410 to the beginning of the packet, a copy 412 of any relevant message headers, and any relevant description 414 of the packet payload (e.g. the length of the payload in bytes).
  • Source and destination address pointers 406, 408 may be obtained in any manner; in various embodiments, this information is obtained from a lookup table 402 or other appropriate data structure maintained within system memory 305. This information may be looked up in one handler (e.g. the classification handler), for example, and pointers to the relevant addresses may be maintained in the packet descriptor 407 to reduce or eliminate the need for subsequent lookups, thereby improving processing speed. With momentary reference again to FIG. 3, the data packet 409A-E and its associated data descriptor 407 can be maintained within system memory 305, where this information is readily accessible to each thread 302A-D executing on each processing core 301, 303 A-C.
  • an exemplary generic process 500 for routing a data packet (e.g. packets 407A-E) through a data processing system suitably includes the broad steps of receiving the data packet (step 502), determining an appropriate recipient handler (steps 506-510), and then "sending" the message to the destination handler (step 514).
  • Process 500 is intended to illustrate the logical tasks performed by the data processing system; it is not intended as a literal software implementation. A practical implementation may arrange the various steps shown in FIG. 5 in any order, and/or may supplement or group the steps differently as appropriate.
  • process 500 does represent a logical technique for routing data packets that could be implemented using any type of digital computing hardware, and that could be stored in any type of digital storage medium, including any sort of RAM, ROM, FLASH memory, magnetic media, optical media and/or the like.
  • the process outlined in FIG. 5 may be logically incorporated into the MCAL 102 best seen in FIGS. 1-2, for example, or may be otherwise implemented as appropriate.
  • 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 31 OA-C in FIG. 3), then the handler is typically a classification handler 104 as described above (step 508). Otherwise, the destination handler can be determined from examination of the packet descriptor (see discussion of FIG 4 above) contained within memory 305 (FIG. 3). [0038] 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).
  • 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 108 A-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.
  • 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).
  • 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.
  • 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.
  • an exemplary process 600 for classifying data packets suitably includes the broad steps of classifying the incoming packets (steps 602-618) and performing pre-processing by formatting and storing the packet as appropriate (step 622) to facilitate direction toward a particular protocol or application handler.
  • process 600 is intended to illustrate various features carried out by an exemplary process, and is not intended as a literal software implementation. Nevertheless, process 600 may be stored in any digital storage media (such as those described above) and may be executed on any processing module 201, 203 as appropriate.
  • the exemplary process 600 shown in FIG. 6 illustrates multiple protocol implementation using the examples of wireless communication and RFID communication. Alternate embodiments could be built to support any number (e.g. one or more) protocols, without regard to whether the protocols are wired, wireless or otherwise.
  • 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 FIG.
  • 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 FIG. 4 above, and/or taking other steps as appropriate. In various embodiments, classification process 600 may include performing lookups to tables 402 (FIG. 4) to identify source, destination or other information about the packet.
  • step 622 shows step 622 as occurring only after the packet has been classified, in practice some or all of the data formatting, storing and/or gathering may equivalently take place prior to or concurrent with the classification process.
  • device 700 may be any type of bridge, switch, router, gateway or the like capable of processing any number of protocols, and any type of wired or wireless protocols using any type of hardware and software resources.
  • alternate embodiments of the switch 700 could be readily formulated in many different ways; the particular data processing handlers 104/106/108, for example, could reside within any processing threads 302 executed by any of the data handling processors 203.
  • Wireless switch 700 suitably includes four processing cores 201 and 203 A-C, with core 201 running the LINUX operating system in threads 302C-D of control core 201.
  • Application handlers 108 A-B providing control path handling for wireless access and RFID protocols, respectively, are shown executing within threads 302 A-B of processing core 201, although alternate embodiments may move the application handlers 108 A-B to available threads 302 on data handling cores 303A-C as appropriate.
  • Threads 302A-B of processor 203 A are shown assigned to classification handlers 104A-B, and threads 302C-D of processor 203 A are shown assigned to protocol handlers 106A associated with RFID protocols.
  • Thread 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 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.
  • data packets arrive at wireless switch 700 via one or more network interface ports 31 OA-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 or other data, and selects and appropriate protocol handler 106 or application handler 108 as appropriate.
  • a classification handler e.g. handlers 104A-B on processing core 203A
  • 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 classifies the data packet as wireless, RFID, control or other
  • 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.
  • 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.
  • 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.

Abstract

Il est possible d'améliorer grandement la souplesse générale et la facilité de conception grâce à l'emploi d'une couche d'abstraction multi-mémoire (MCAL) à l'interface entre la plate-forme matérielle multimémoire, le dispositif d'exploitation de dispositif et les fonctions de transfert de paquets. Sont décrits ici des systèmes et des procédés de traitement d'un paquet de données reçues à l'interface réseau d'un dispositif d'infrastructure réseau (tel qu'un commutateur sans fil) ou autre système de calcul utilisant en particulier des processeurs multimémoire. Un gestionnaire de classement classe le paquet de données. Une pluralité de processus de protocole associés chacun à un protocole de données traite le paquet de données si la classement dudit paquet correspond au protocole de données associé au gestionnaire de protocole, et l'un des divers gestionnaires d'application associés chacun à une application utilisateur traite le paquet de données si le classement dudit paquet correspond à l'application utilisateur associée au gestionnaire d'applications. Le MCAL est conçu pour transmettre le paquet de données au gestionnaire de classement après réception dudit paquet, puis de diriger ce paquet vers le gestionnaire de protocoles ou le gestionnaire d'applications en fonction du classement du paquet de données. De plus, le MCAL contient un ensemble de réceptacles pour les gestionnaires. Les gestionnaires réels d'applications, de protocoles et de classement sont enregistrés auprès de MCAL et sont des modules élaborés en dehors de MCAL.
EP07799125A 2006-06-30 2007-06-27 Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire Withdrawn EP2035928A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/479,687 US20080002681A1 (en) 2006-06-30 2006-06-30 Network wireless/RFID switch architecture for multi-core hardware platforms using a multi-core abstraction layer (MCAL)
US11/479,686 US20080002702A1 (en) 2006-06-30 2006-06-30 Systems and methods for processing data packets using a multi-core abstraction layer (MCAL)
PCT/US2007/072349 WO2008005793A2 (fr) 2006-06-30 2007-06-27 Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire

Publications (1)

Publication Number Publication Date
EP2035928A2 true EP2035928A2 (fr) 2009-03-18

Family

ID=38895339

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07799125A Withdrawn EP2035928A2 (fr) 2006-06-30 2007-06-27 Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire

Country Status (2)

Country Link
EP (1) EP2035928A2 (fr)
WO (1) WO2008005793A2 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8634302B2 (en) * 2010-07-30 2014-01-21 Alcatel Lucent Apparatus for multi-cell support in a network
US20120093047A1 (en) * 2010-10-14 2012-04-19 Alcatel-Lucent USA Inc. via the Electronic Patent Assignment System (EPAS) Core abstraction layer for telecommunication network applications
US8504744B2 (en) * 2010-10-28 2013-08-06 Alcatel Lucent Lock-less buffer management scheme for telecommunication network applications
US8737417B2 (en) 2010-11-12 2014-05-27 Alcatel Lucent Lock-less and zero copy messaging scheme for telecommunication network applications
US8730790B2 (en) 2010-11-19 2014-05-20 Alcatel Lucent Method and system for cell recovery in telecommunication networks
US8861434B2 (en) 2010-11-29 2014-10-14 Alcatel Lucent Method and system for improved multi-cell support on a single modem board
US9357482B2 (en) 2011-07-13 2016-05-31 Alcatel Lucent Method and system for dynamic power control for base stations
DE102012217085A1 (de) 2012-09-21 2014-05-28 Continental Automotive Gmbh Kommunikationssystem
EP3264711B1 (fr) * 2016-06-28 2018-09-19 Virtual Open Systems Commutateur virtuel pour communications critiques du réseau mixte à compartiments multiples
DE102016214140A1 (de) * 2016-08-01 2018-02-01 Continental Teves Ag & Co. Ohg Fahrzeug-zu-X-Kommunikationsmodul

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2226499A (en) * 1998-01-16 1999-08-02 Symbol Technologies, Inc. Infrastructure for wireless lanss
US7248585B2 (en) * 2001-10-22 2007-07-24 Sun Microsystems, Inc. Method and apparatus for a packet classifier
US7602792B2 (en) * 2001-12-14 2009-10-13 California Institute Of Technology Reconfigurable protocols and architectures for wireless networks
US7957401B2 (en) * 2002-07-05 2011-06-07 Geos Communications, Inc. System and method for using multiple communication protocols in memory limited processors
US8533716B2 (en) * 2004-03-31 2013-09-10 Synopsys, Inc. Resource management in a multicore architecture

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008005793A3 *

Also Published As

Publication number Publication date
WO2008005793A3 (fr) 2008-05-02
WO2008005793A2 (fr) 2008-01-10

Similar Documents

Publication Publication Date Title
US20080002702A1 (en) Systems and methods for processing data packets using a multi-core abstraction layer (MCAL)
US20080002681A1 (en) Network wireless/RFID switch architecture for multi-core hardware platforms using a multi-core abstraction layer (MCAL)
WO2008005793A2 (fr) Systèmes et procédé de traitement de paquets de données au moyen d'une couche d'abstraction multi-mémoire
US11677851B2 (en) Accelerated network packet processing
US20210117360A1 (en) Network and edge acceleration tile (next) architecture
EP2647163B1 (fr) Procédé et système permettant un support multicellule amélioré sur une seule carte modem
US9654406B2 (en) Communication traffic processing architectures and methods
US20070083924A1 (en) System and method for multi-stage packet filtering on a networked-enabled device
US8406230B2 (en) Method and system for classifying packets in a network interface card and interface for performing the same
US20080043765A1 (en) Method and system for automatically reflecting hardware resource allocation modifications
Watanabe et al. Accelerating NFV application using CPU-FPGA tightly coupled architecture
Freitas et al. A survey on accelerating technologies for fast network packet processing in Linux environments
US7697434B1 (en) Method and apparatus for enforcing resource utilization of a container
US10599441B2 (en) Code sequencer that, in response to a primary processing unit encountering a trigger instruction, receives a thread identifier, executes predefined instruction sequences, and offloads computations to at least one accelerator
US20200336573A1 (en) Network switching with co-resident data-plane and network interface controllers
US7675920B1 (en) Method and apparatus for processing network traffic associated with specific protocols
Hong et al. Kafe: Can os kernels forward packets fast enough for software routers?
Lin et al. VPN gateways over network processors: Implementation and evaluation
WO2002005494A1 (fr) Architecture de traitement par paquets a grande vitesse
US7613133B2 (en) Method, system and computer program product for processing packets at forwarder interfaces
US20230040655A1 (en) Network switching with co-resident data-plane and network interface controllers
Ruf et al. Towards high-performance active networking
US20230185624A1 (en) Adaptive framework to manage workload execution by computing device including one or more accelerators
US20230367655A1 (en) Method and apparatus for controlling servicing of multiple queues
Kundel Design of QoS-Aware Network Functions

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081210

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

DAX Request for extension of the european patent (deleted)
18W Application withdrawn

Effective date: 20090917