Method and electronic device for data packet flow distribution in multi-core processor

Abstract

Embodiments herein provide a method of data packet flow distribution in a multi-core processor (130) by an electronic device (100). The method includes receiving data packets to be processed by a multi-core processor (130), determining whether to acquire a flow lock of a data flow critical zone at a core, and upon successful acquisition of the flow lock, determining whether to process a threshold number of data packets from a flow queue at the core. Further, the method includes determining pending data packets to be processed in the flow queue when processing the threshold number of data packets from the flow queue, and creating a new trigger packet or event when determining pending data packets to be processed in the flow queue. The method includes releasing a flow lock of a critical zone and enqueueing new trigger packets / events into a generic queue to be processed by other cores.

Description

Technical Field

[0001] The present disclosure relates to an electronic device, and for example, to a method for distributing data packet streams in a multi-core processor and the electronic device. Background Art

[0002] To improve the performance of electronic devices, the use of multi-core processors has increased significantly. Multi-core processors process multiple events or packets across multiple data streams. Each core of a multi-core processor subscribes to a queue or ring list from which it receives events or packets. To maximize parallel processing and improve system throughput, data plane event or packet processing for a stream is subdivided into non-critical and critical sections. Critical section processing for a stream requires sequential execution using a stream-specific critical section lock called a stream lock (also known as a critical section flow lock). A critical section is a section of event or packet processing for a stream that can only be executed by one core at a time. Sequence number assignment and stream-specific state variable updates are examples of critical sections. Each critical section of a stream is protected by a stream lock, preventing multiple parallel cores from executing or processing the critical section simultaneously. Non-critical section processing for a stream is performed in parallel by multiple cores of a multi-core processor. Non-critical sections are sections of event or packet processing for a stream that can be processed in parallel by multiple cores. Examples of non-critical sections include checking event or packet validity, processing and removing network headers, and sending events or packets.

[0003] Hardware and software schedulers are two types of schedulers that can be used to distribute events or packets between cores in a multicore processor, based on queue or ring subscriptions. Alternatively, each core can poll a list of queues or rings and retrieve events or packets for processing. A core identifies each event or packet based on a flow identifier (ID). Each core identifies a flow based on the contents of the packet (for example, the call ID or bearer ID in the packet). Each core continuously polls events or packets from multiple queues or rings, hardware schedulers, or software schedulers. If a core receives an event or packet containing a critical section for processing, it attempts to acquire a flow lock, called a try lock. If the core successfully acquires the flow lock, it continues processing the critical section of the event or packet.

[0004] Failure to acquire the stream lock means that some other core must hold the critical section lock for that stream, and the core that failed to acquire the lock will enqueue the event or packet into a stream queue. Each stream queue is located in the memory of the electronic device, and the memory can be accessed based on the stream ID. The stream queue is a queue for each stream that manages pending events or packets for critical section processing. Enqueuing and dequeuing from a stream queue are performed using a stream queue lock to avoid multiple cores attempting to enqueue and dequeue at the same time. A producer core is a core in a multi-core processor that enqueues events or packets into a stream queue when it fails to acquire the stream lock. A consumer core is a core in a multi-core processor that successfully acquires the stream lock for a stream and processes events or packets in the stream queue in sequence. The cores of a multi-core processor are not strictly divided into producer cores and consumer cores, but this division is based on the current work distributed to each core.

[0005] Figure 1 A flowchart (10) illustrating an existing method of acquiring and releasing a critical section stream lock.

[0006] In operation 11, the method includes dequeuing packets from the general queue and the core-specific queue. In operation 12, the method includes performing initial verification on the packet. In operation 13, the method includes determining whether an event with a flow lock is required. In operation 14, when it is determined that a flow lock is not required, the method includes processing the event and continuing with operation 11. In operation 15, when it is determined that a flow lock is required, the method includes determining whether acquisition of the critical section flow lock is successful or failed. In operation 16, when acquisition of the critical section flow lock fails, the method includes enqueuing the event into the flow queue and continuing with operation 11. In operation 17, when acquisition of the critical section flow lock succeeds, the method includes processing a new event. In operation 18, the method includes determining whether the flow queue is empty. In operation 19, when the flow queue is not empty, the method includes processing the event. In operation 20, when the flow queue is empty, the method includes releasing the critical section flow lock.

[0007] In one scenario, a consumer core processes events in a stream queue one by one until the queue is empty. During this time, the consumer core cannot obtain events dedicated to that consumer core. Events that are dedicated or specific to a consumer core are called core-dedicated or specific events, such as timer events. For example, when a timer event is triggered for a specific core, since the timer event is associated with that specific core, the timer event must be processed on the same specific core. Core-dedicated or specific events will remain unprocessed until the stream queue is empty. If a consumer core must obtain a core-specific event, the consumer core must stop processing the stream queue. In addition, since the core-specific event may belong to another stream, the consumer core loses the context of the stream and releases the critical section stream lock.

[0008] In another scenario, when the rate at which packets are enqueued to a flow queue is very high, resulting in high core load on the consumer core, the consumer core may become completely busy processing events or packets for the flow by dequeuing pairs from the flow queue. The consumer core may have to stop processing the critical section of one flow and start processing the critical section of another flow to achieve load balancing across flows or cores. If a consumer core stops processing the critical section of a flow, a problem arises: there should be a mechanism to process the remaining events or packets in the flow queue of the currently processing flow. Consider a scenario where a consumer core stops processing the critical section of a flow and releases the flow lock, but there are still some pending events or packets in the flow queue. If a core receives a new event or packet for the same flow and no core is processing the critical section for that flow, it can process the new packet after acquiring the flow lock identified by the flow ID, and then process the pending events or packets in the flow queue. If no new events or packets for the same flow arrive, the pending events or packets are not processed at all, which can lead to buffer exhaustion.

[0009] Since multiple producer processor cores process non-critical sections in parallel, the number of packets entering the flow queue can be very large compared to the processing rate, which leads to a scenario where the consumer core with the flow lock becomes busy, resulting in higher core utilization or load compared to other producer cores, causing uneven core load distribution.

[0010] Therefore, there needs to be a mechanism to process core-dedicated or specific events with higher priority and distribute the core load evenly among multiple cores of a multi-core processor.

[0011] The above information is provided as background information only to assist in understanding the present disclosure. No determination has been made, and no assertion is made, as to whether the above content may be prior art with respect to the present disclosure. Summary of the Invention

[0012] Solution to the problem

[0013] The present disclosure provides a method and electronic device for distributing packet flows in a multi-core processor. The method achieves better load balancing by distributing single-flow critical section processing across multiple cores of the multi-core processor.

[0014] The present disclosure relates to prioritizing and efficiently processing core-dedicated or specific events on a multi-core processor while holding a critical section flow lock and processing packets from a flow queue, without losing the context of the flow queue (i.e., information about pending data packets) and the entry order of packets in the flow queue.

[0015] The present disclosure is directed to avoiding using a core as a scheduler of a multi-core processor and making all cores of the multi-core processor available for data plane data packet processing to obtain additional throughput gain.

[0016] In an example embodiment, a method for an electronic device to distribute data packet streams in a multi-core processor is provided. The method includes: receiving, by the electronic device, a data packet to be processed by the multi-core processor. The method includes: determining, by the electronic device, whether a flow lock for a critical section of the data flow can be acquired at one core of the multi-core processor. The method includes: upon successfully acquiring the flow lock, determining, by the electronic device, whether to process a threshold number of data packets from a flow queue at the core. The method includes: upon processing a threshold number of data packets from a flow queue, determining, by the electronic device, pending data packets to be processed in the flow queue. The method includes: upon determining that there are pending data packets to be processed in the flow queue, creating, by the electronic device, a new trigger packet or event. The method includes: releasing, by the electronic device, the flow lock for the critical section. The method includes: enqueuing, by the electronic device, the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor.

[0017] In an example embodiment, cores of a multi-core processor process data packets from a data stream of queues in parallel.

[0018] In an example embodiment, wherein the threshold number of data packets is configured based on core-specific or event-specific criticality and average processing cycles per packet.

[0019] In an example embodiment, where the new triggering packet or event is a buffer comprising a message type as a trigger, wherein the message or buffer comprises a flow identifier.

[0020] In an example embodiment, the electronic device determines, by the electronic device, that a threshold number of data packets from a flow queue are processed at the core, including: determining, by the electronic device, whether a received data packet is a new trigger packet or event; upon determining that the received data packet is a new trigger packet or event, determining, by the electronic device, a flow from the new trigger packet or event; acquiring, by the electronic device, a flow lock; upon successfully acquiring the flow lock, processing the new trigger packet or event; and dequeuing, by the electronic device, data packets from the flow queue one by one and processing them until a threshold number of data packets are processed or the flow queue is empty.

[0021] In an example embodiment, after acquiring the critical section lock, processing a threshold number of data packets of a data stream from a flow queue includes: determining, by the electronic device, whether the received data packet is a new event or packet or a triggering packet or event; upon determining that the received data packet is a new data packet or event, determining, by the electronic device, whether the flow queue is empty; upon determining that the flow queue is not empty, enqueuing, by the electronic device, the new data packet or event at the tail of the flow queue; and processing, by the electronic device, the data packets from the flow queue one by one until the threshold number of data packets are processed or the flow queue is empty.

[0022] In an example embodiment, the method includes: upon determining that the flow queue is not empty, after a threshold number of data packets have been processed, creating, by the electronic device, a new trigger event with a flow identifier; releasing, by the electronic device, the flow lock; and enqueuing, by the electronic device, the trigger event in a general queue.

[0023] In an example embodiment, wherein the method includes discarding, by the electronic device, the new trigger packet or event when the stream lock cannot be acquired.

[0024] In an example embodiment, the new trigger packet or event is a linked list of data packets with flow identifiers to be processed.

[0025] In an example embodiment, determining by the electronic device that a threshold number of data packets from a flow queue are processed at the core includes: determining by the electronic device whether a received data packet is a new packet or event or a triggered packet or event; upon determining that the received data packet is a new triggered packet or event with a pending event or packet list, determining by the electronic device a data flow from the new triggered packet or event; determining by the electronic device whether a flow lock can be acquired; upon failing to acquire the flow lock, enqueuing by the electronic device the pending data packets or events in the pending event or packet list at the head of the flow queue; or, upon successfully acquiring the flow lock, processing a new triggered packet or event, and enqueuing the events or packets in the pending list at the head of the flow queue and processing them one by one until a threshold number of data packets are processed or the flow queue is empty.

[0026] In an example embodiment, the method includes: upon determining that the flow queue is not empty, after a threshold number of data packets have been processed, creating, by the electronic device, a new trigger event using the pending data packets or event list and the flow identifier. The method also includes: releasing, by the electronic device, the flow lock. The method also includes: enqueuing, by the electronic device, the trigger event in a general queue.

[0027] In an example embodiment, wherein, after the core acquires the flow lock, determining by the electronic device that a threshold number of data packets from the flow queue are processed includes: determining by the electronic device that a threshold number of data packets are processed, and taking out, by the electronic device, core-specific events or time-critical events from a general queue or a core-dedicated queue.

[0028] In an example embodiment, the method includes: determining, by the electronic device, a corresponding stream for the acquired event. The method also includes: adding, by the electronic device, the acquired event to a common queue when determining that the acquired events belong to different streams. The method also includes: processing, by the electronic device, the acquired event when determining that the acquired events belong to the same stream.

[0029] In an example embodiment, the method includes: determining, by the electronic device, a number of data packets in a flow queue; dequeuing, by the electronic device, data packets from the flow queue until the flow queue is empty; and processing, by the electronic device, the data packets.

[0030] In an example embodiment, all enqueue and dequeue operations on the stream queue are performed after acquiring the stream lock.

[0031] In an exemplary embodiment, an electronic device for distributing data packet streams in a multi-core processor is provided. The electronic device includes a stream processing controller, a memory, and a multi-core processor, wherein the stream processing controller is coupled to the memory and the multi-core processor. The stream processing controller is configured to receive data packets to be processed by the multi-core processor. The stream processing controller is configured to determine whether a stream lock for a critical section of a data stream can be acquired at a core of the multi-core processor. The stream processing controller is configured to determine whether a threshold number of data packets from a stream queue can be processed at the core upon successfully acquiring the stream lock. The stream processing controller is configured to determine pending data packets to be processed in the stream queue upon processing the threshold number of data packets from the stream queue. The stream processing controller is configured to create a new trigger packet or event upon determining that there are pending data packets to be processed in the stream queue. The stream processing controller is configured to release the stream lock for the critical section. The stream processing controller is configured to enqueue the new trigger packet or event into a general queue to be processed by other cores of the multi-core processor.

[0032] In an example embodiment, a non-transitory computer-readable memory is provided. The non-transitory computer-readable memory stores instructions that, when executed by a processor of an electronic device, cause the electronic device to perform the following operations: receive a data packet to be processed by a multi-core processor (130); determine whether to acquire a flow lock for a critical section of a data flow at a core of the multi-core processor (130); upon successfully acquiring the flow lock, determine whether to process a threshold number of data packets from a flow queue at the core; upon processing the threshold number of data packets from the flow queue, determine pending data packets to be processed in the flow queue; upon determining that there are pending data packets to be processed in the flow queue, create a new trigger packet or event; release the flow lock for the critical section; and enqueue the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor (130). To further illustrate the advantages and features of the present disclosure, a more detailed description will be given with reference to various example embodiments thereof, which are illustrated in the accompanying drawings. It should be understood that these drawings depict only example embodiments of the present disclosure and should not be considered to limit its scope. The present disclosure will be described and explained with further specificity and detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which like characters represent like parts throughout the drawings, and in which:

[0034] Figure 1 A flow chart showing an existing method for acquiring and releasing a critical section stream lock according to the prior art is shown;

[0035] Figure 2 is a block diagram of an electronic device for distributing data packet streams in a multi-core processor according to an embodiment disclosed herein;

[0036] Figure 3 A flow chart of a method for distributing data packet flows in a multi-core processor according to an embodiment disclosed herein is shown;

[0037] Figure 4 A flowchart of a method for distributing data packet flows in a multi-core processor by creating a new trigger event according to an embodiment disclosed herein is shown;

[0038] Figure 5A 、 Figure 5B 、 Figure 5C 、 Figure 5D 、 Figure 5E 、 Figure 5F 、 Figure 5G 、 Figure 5H 、 Figure 5I 、 Figure 5J 、 Figure 5K 、 Figure 5L 、 Figure 5M 、 Figure 5N 、 Figure 5O 、 Figure 5P 、 Figure 5Q 、 Figure 5R 、 Figure 5S 、 Figure 5T and Figure 5U is a schematic diagram illustrating an example scenario of distributing data packet flows in a multi-core processor according to an embodiment disclosed herein;

[0039] Figure 6 A flowchart of a method for distributing data packet flows in a multi-core processor by creating a pending data packet list according to an embodiment disclosed herein is shown;

[0040] Figure 7 A flowchart illustrating a method for distributing data packet flows in a multi-core processor by processing intermediate core-specific events according to an embodiment disclosed herein; and

[0041] Figure 8 Examples of trigger packets, pending data packet lists, and new flow-specific events are shown according to embodiments disclosed herein.

[0042] Furthermore, those skilled in the art will appreciate that the elements in the drawings are illustrated for simplicity and are not necessarily drawn to scale. For example, the flow charts illustrate the methods in terms of the operations involved to facilitate an understanding of various aspects of the present disclosure. Furthermore, with respect to the configuration of the device, one or more components of the device may be represented in the drawings using conventional symbols, and the drawings may show specific details that are relevant to understanding the various exemplary embodiments of the present disclosure, so as not to obscure the drawings with details that would be readily apparent to those skilled in the art. DETAILED DESCRIPTION

[0043] It may be helpful to define certain words and phrases used in this patent document. The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether those elements are in physical contact with each other. The terms "send," "receive," and "communicate," and their derivatives, encompass both direct and indirect communication. The terms "include," "comprise," and their derivatives, mean to include, but are not limited to. The term "or" is inclusive, meaning and / or. The phrase "associated with..." and its derivatives mean to include, be included within, be interconnected with, contain, be contained within, be connected to or connected with, be coupled to or coupled with, be communicable with, collaborate with, be interleaved, juxtaposed, be close to, be bound to or bound with, have, have the property of, have a relationship to or with, etc. The term "controller" means any device, system, or part thereof that controls at least one operation. Such a controller can be implemented in hardware or a combination of hardware and software and / or firmware. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether local or remote. The phrase "at least one of" when used with a list of items means that different combinations of one or more of the listed items can be used, and that only one of the items in the list may be required. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A, B, and C.

[0044] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed of computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, related data, or portions thereof, suitable for implementation in suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as read-only memory (ROM), random-access memory (RAM), hard drives, compact disks (CDs), digital video disks (DVDs), or any other type of memory. "Non-transitory" computer-readable media excludes wired, wireless, optical, or other communication links that transmit transitory electrical or other signals. Non-transitory computer-readable media includes both media capable of permanently storing data and media capable of storing data and later rewriting it, such as rewritable optical disks or erasable memory devices.

[0045] Definitions for certain other words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

[0046] As is conventional in the art, embodiments may be described and illustrated in terms of modules that perform the described functions. These modules, which may be referred to herein as managers, units, modules, hardware components, and the like, are physically implemented using analog and / or digital circuitry (such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuitry, and the like), and may optionally be driven by firmware. For example, these circuits may be embodied in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry comprising a module may be implemented using dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware that performs certain functions of the module and a processor that performs other functions of the module. Each module of an embodiment may be physically separated into two or more interacting and discrete modules without departing from the scope of this disclosure. Similarly, the modules of an embodiment may be physically combined into more complex modules without departing from the scope of this disclosure.

[0047] The accompanying drawings are used to help facilitate understanding of various technical features. It should be understood that the embodiments presented herein are not limited by the accompanying drawings. Therefore, the present disclosure should be interpreted as extending to any changes, equivalents, and substitutes other than those specifically listed in the accompanying drawings. Although terms such as first and second may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.

[0048] Throughout this disclosure, the terms "data packet," "packet," "event," and "data" are used interchangeably and have the same meaning. Throughout this disclosure, the terms "stream lock" and "critical section stream lock" are used interchangeably and have the same meaning. Throughout this disclosure, the terms "stream" and "data stream" are used interchangeably and have the same meaning.

[0049] Therefore, an embodiment of the present invention provides a method for distributing data packet streams in a multi-core processor by an electronic device. The method includes receiving, by the electronic device, a data packet to be processed by the multi-core processor. The method includes determining, by the electronic device, whether a flow lock for a critical section of a data flow can be acquired at a core of the multi-core processor. The method includes, upon successfully acquiring the flow lock, determining, by the electronic device, whether a threshold number of data packets from a flow queue are processed at the core. The method includes, upon processing a threshold number of data packets from a flow queue, determining, by the electronic device, that there are pending data packets to be processed in the flow queue. The method includes, upon determining that there are pending data packets to be processed in the flow queue, creating, by the electronic device, a new trigger packet or event with a flow identifier. The method includes releasing, by the electronic device, the critical section flow lock. The method includes enqueuing, by the electronic device, the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor.

[0050] Therefore, embodiments herein provide an electronic device for distributing data packet streams in a multi-core processor. The electronic device includes a stream processing controller, a memory, and a multi-core processor, wherein the stream processing controller is coupled to the memory and the multi-core processor. The stream processing controller is configured to receive data packets to be processed by the multi-core processor. The stream processing controller is configured to determine whether a stream lock for a critical section of a data stream can be acquired at a core of the multi-core processor. Upon successfully acquiring the stream lock, the stream processing controller is configured to determine whether a threshold number of data packets from a stream queue can be processed at the core. The stream processing controller is configured to determine, upon processing a threshold number of data packets from a stream queue, that there are pending data packets to be processed in the stream queue. Upon determining that there are pending data packets to be processed in the stream queue, the stream processing controller is configured to create a new trigger packet or event with a stream identifier. The stream processing controller is configured to release the critical section stream lock. The stream processing controller is configured to enqueue the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor.

[0051] This disclosure proposes an efficient packet flow distribution method that terminates processing of a flow by creating a new trigger event or pending packet list with a flow identifier and sending the new trigger event or pending packet list as a new event to other cores for processing. This allows other cores of a multi-core processor to process the remaining packets or events of the flow. After processing a threshold number (e.g., 200) of data packets or events, the multi-core processor core holding the critical section lock for the flow stops processing packets for the flow and checks core-specific events or other flow events for appropriate load balancing.

[0052] In an example embodiment of a packet flow distribution method, multiple cores process packets from a flow in parallel. During a sequential section of packet processing by one of the cores holding a critical section flow lock, a flow processing controller, after processing a threshold number of packets from a flow queue, creates a new trigger packet including a flow identifier and enqueues it in a general ring or queue. The enqueued new trigger packet can be dequeued and further processed by other cores after acquiring the critical section flow lock, thereby continuing to process packets from the flow queue. If the flow processing controller fails to acquire the flow lock, the core releases the trigger packet.

[0053] In an example embodiment of a packet flow distribution method, multiple cores process packets from a flow in parallel. During a sequential region of packet processing by a core holding a critical region flow lock, a flow processing controller creates a pending packet list containing pending packets and a flow identifier called a pending list as a triggering event, and enqueues it to a general ring or queue after processing a threshold number of packets in the flow queue. Any core can dequeue a new pending list from the general ring or queue and process it. When the flow lock fails to be acquired, the core enqueues the pending packets or events in the pending event or packet list at the head of the flow queue to maintain orderly processing. When the flow lock is successfully acquired, the core processes the new triggering packet or event, enqueues the events or packets in the pending list at the head of the flow queue, and processes the events or packets one by one.

[0054] In an example embodiment of a packet flow distribution method, multiple cores process packets from a flow in parallel. During a sequential period of packet processing by a core holding a critical section flow lock, and after processing a threshold number of packets from a flow queue, a flow processing controller checks for a core-specific event on the core. If the core-specific event belongs to the same flow as the acquired critical section flow lock, the core-specific event is processed. If the core-specific event belongs to a different flow, the flow processing controller creates a new event containing the core-specific event and a flow identifier and enqueues it in a general ring or queue. Other cores can then dequeue and process the event.

[0055] This approach is useful in scenarios where one core of a multicore processor holds the flow lock, continuously processing packets from a specific flow queue, and is unable to process pending core-specific events. The flow processing controller preserves the context (i.e., order) of pending packets in a flow queue by creating and enqueuing trigger events or a list of pending packets. The trigger events or the list of pending packets contain the flow identifier. When the trigger event or the list of pending packets is dequeued from the queue, the core retrieves the flow context, acquires the flow lock, and continues processing the critical section. The proposed approach minimizes packet reordering in this scenario by processing the list of pending packets or events first, followed by new packets.

[0056] Unlike existing methods and systems, the flow processing controller is essential for supporting core pool deployment in environments that do not use software or hardware schedulers. In such environments, cores take packets from queues or rings and use multiple cores of a multi-core processor to achieve high traffic throughput, provide efficient load balancing, and facilitate the deployment of energy-saving schemes.

[0057] Unlike existing methods and systems, the stream processing controller never selects a single core in a multicore processor for software event scheduling. This allows all cores to be used for data plane packet processing, achieving additional throughput gains. The stream processing controller enables timely processing of core-specific events and efficient load distribution across multiple cores. It also facilitates the deployment of energy-saving load balancing schemes without disrupting in-order packet processing.

[0058] Discussed below Figures 2 to 8 The various embodiments used to describe the principles of the present disclosure in this patent document are intended to be illustrative only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will understand that the principles of the present disclosure can be implemented in any suitably arranged system or device.

[0059] Figure 2 is a block diagram of an electronic device (100) for data packet stream distribution in a multi-core processor (130) according to example embodiments disclosed herein.

[0060] Examples of electronic devices (100) include, but are not limited to, smartphones, tablet computers, personal digital assistants (PDAs), desktop computers, Internet of Things (IoT), wearable devices, and the like. In an example embodiment, the electronic device (100) includes a stream processing controller (110), a memory (120), a multi-core processor (130), and a communicator (140), wherein the stream processing controller (110) is coupled to the memory (120) and the multi-core processor (130) via the communicator (140). In another embodiment, the electronic device (100) includes a memory (120), a multi-core processor (130), and a communicator (140), wherein each core (e.g., core 1 to core n) includes a stream processing controller (110). The stream processing controller (110) is implemented by processing circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, and can optionally be driven by firmware. For example, these circuits may be embodied in one or more semiconductor chips, or on a substrate support such as a printed circuit board.

[0061] The memory (120) includes all types of queues. The memory (120) stores instructions to be executed by the multi-core processor (130). The memory (120) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or in the form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Furthermore, in some examples, the memory (120) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (120) is non-removable. In some examples, the memory (120) may be configured to store a larger amount of information than its storage space. In some examples, the non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache). The memory (120) may be an internal storage unit of the electronic device (100), or an external storage unit, cloud storage, or any other type of external storage.

[0062] The multi-core processor (130) is configured to execute instructions stored in the memory (120). The multi-core processor (130) may be a general-purpose processor, such as a central processing unit (CPU), an application multi-core processor (AP), or a unit used only for graphics processing, such as a graphics processing unit (GPU), a visual processing unit (VPU), or the like. The multi-core processor (130) includes multiple cores (e.g., core 1 to core n) to execute instructions. In an embodiment, the multiple cores of the multi-core processor (130) process data packets of a data flow from a flow queue in parallel.

[0063] The communicator (140) is configured to communicate internally between hardware components within the electronic device (100). Furthermore, the communicator (140) is configured to facilitate communication between the electronic device (100) and other devices via one or more networks (e.g., radio technologies). The communicator (140) includes electronic circuitry specific to a standard for implementing wired or wireless communication.

[0064] A stream processing controller (110) receives data packets of a stream to be processed by a multi-core processor (130). Furthermore, the stream processing controller (110) attempts to acquire a stream lock for a critical section of the data stream at a core of the multi-core processor (130). Furthermore, upon successfully acquiring the stream lock, the stream processing controller (110) determines that a threshold number of data packets from a stream queue are processed at the core. In an embodiment, the threshold number of data packets is configured based on a criticality of a core-specific event and an average processing cycle per packet. In an embodiment, a new trigger packet or event is a buffer including a message type as a trigger, wherein the message or buffer includes a stream identifier.

[0065] The flow processing controller (110) determines whether the received data packet is a new event or packet, or a trigger packet or event. In addition, when it is determined that the received data packet is a new data packet or event, the flow processing controller (110) determines whether the flow queue is empty. In addition, when it is determined that the flow queue is not empty, the flow processing controller (110) enqueues the new packet or event at the tail of the flow queue. In addition, the flow processing controller (110) processes the data packets from the flow queue one by one until a threshold number of data packets are processed. The flow processing controller (110) determines that there are pending data packets to be processed in the flow queue. In addition, when it is determined that there are pending data packets in the flow queue, the flow processing controller (110) creates a new trigger packet or event with a flow identifier. In addition, the flow processing controller (110) releases the flow lock of the critical section. The flow processing controller (110) enqueues the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor (130).

[0066] Upon determining that the received data packet is a trigger event, the flow processing controller (110) discards the new trigger packet or event when failing to acquire the flow lock. Upon successfully acquiring the flow lock, the flow processing controller (110) processes the new trigger packet or event. In addition, the flow processing controller (110) dequeues data packets one by one from the flow queue until a threshold number of packets are processed. In addition, when the packets are processed, the flow processing controller (110) releases the flow lock.

[0067] In another embodiment, the new trigger packet or event is a linked list of packets to be processed with a flow identifier. In order to determine that a threshold number of data packets from the flow queue are processed at the core, the flow processing controller (110) determines whether the received data packet is a new packet or event or a trigger packet or event. In addition, when it is determined that the received data packet is a new trigger packet or event with a list of pending events or packets, the flow processing controller (110) determines the data flow from the new trigger packet or event. Further, the flow processing controller (110) determines whether the flow lock can be acquired. In addition, when the flow lock cannot be acquired, the flow processing controller (110) enqueues the pending packets or events in the pending event or packet list at the head of the flow queue. In addition, when the flow lock is successfully acquired, the flow processing controller (110) processes the new trigger packet or event, enqueues the events or packets in the pending list into the flow queue, and processes them one by one until the threshold number of events are processed or the flow queue is empty. The flow processing controller (110) determines the pending data packets to be processed in the flow queue. Furthermore, when determining that there is a pending data packet in the flow queue, the flow processing controller (110) creates a new trigger packet or event pending list with the flow identifier. Furthermore, the flow processing controller (110) releases the critical section flow lock. The flow processing controller (110) queues the new trigger packet or event into a general queue to be processed by other cores of the multi-core processor (130).

[0068] In another embodiment, in order to determine that a threshold number of data packets from the flow queue are processed after acquiring the flow lock at the core, the flow processing controller (110) determines that a threshold number of data packets are processed. In addition, the flow processing controller (110) dequeues core-specific events or time-critical events (i.e., acquired events) from the general queue. In addition, the flow processing controller (110) determines the corresponding stream of the acquired event. When it is determined that the acquired event belongs to a different stream, the flow processing controller (110) enqueues the acquired event to the general queue. When it is determined that the acquired event belongs to the same stream, the flow processing controller (110) processes the acquired event and continues to dequeue the core-specific event until all core-specific events are processed, and this process continues until the flow queue is empty.

[0069] The flow processing controller (110) determines the number of data packets in the flow queue. In addition, the flow processing controller (110) dequeues data packets from the flow queue and processes the data packets until the flow queue is empty.

[0070] In the above embodiment, the stream processing controller (110) enqueues data packets into the stream queue and dequeues data packets from the stream queue after acquiring the stream queue lock.

[0071] although Figure 2 The hardware components of the electronic device (100) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the electronic device (100) may include fewer or more components. In addition, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially similar data packet stream distribution functions in the multi-core processor (130).

[0072] Figure 3 A flow chart of a method for distributing data packet flows in a multi-core processor (130) according to an example embodiment disclosed herein is shown. In an example embodiment, the method allows a flow processing controller (110) to perform operations 301-307 of the flow chart (300).

[0073] In operation 301, the method includes receiving a data packet to be processed by a multi-core processor (130). In operation 302, the method includes attempting to acquire a flow lock for a critical section of a data flow at a core of the multi-core processor (130). In operation 303, the method includes determining that a threshold number of data packets from a flow queue are processed at the core upon successfully acquiring the flow lock. In operation 304, the method includes determining pending data packets to be processed in the flow queue. In operation 305, the method includes creating a new trigger packet or event upon determining that there are pending data packets in the flow queue. In operation 306, the method includes releasing the flow lock for the critical section. In operation 307, the method includes enqueuing the new trigger packet or event in a general queue to be processed by other cores of the multi-core processor (130).

[0074] Figure 4 A flowchart (400) is shown of a method for distributing data packet flows in a multi-core processor (130) by creating a new trigger event according to an example embodiment disclosed herein.

[0075] At 401, the flow processing controller (110) dequeues and receives packets from the general queue and the core-specific queue. At 402, the flow processing controller (110) performs initial validation of the packet by identifying to which flow the packet belongs. At 403, the flow processing controller (110) determines whether the received packet is a core-specific event, a new event, or a trigger packet requiring a flow lock. At 404, when the received packet is not a core-specific event, a new event, or a trigger packet requiring a flow lock, the flow processing controller (110) configures the core to process the received packet and continues execution at 401.

[0076] At 405, when it is determined that a flow lock is required, the flow processing controller (110) determines whether the core succeeds or fails to acquire the critical section flow lock. At 419, when the critical section lock acquisition fails, the flow processing controller (110) checks the trigger packet. At 406, if the packet is not a trigger packet, the flow processing controller (110) enqueues the packet into the flow queue and continues to execute 401. At 420, if the packet is a trigger packet, since other cores have already started processing this flow by acquiring the lock, the flow processing controller (110) will discard the packet and continue to execute 401. At 407, the flow processing controller (110) determines whether the received packet is a new event or a core-specific event.

[0077] At 408, when the received packet is not a new event or a core-specific event, the flow processing controller (110) processes the trigger packet and executes 409. The flow processing controller (110) identifies the flow to which the trigger packet belongs. At 409, the flow processing controller (110) checks whether the flow queue is empty. Furthermore, at 413, when the flow queue is empty, the flow processing controller (110) releases the critical section flow lock.

[0078] At 410-411, if the flow queue is not empty, the flow processing controller (110) dequeues packets from the queue and configures the core to process packets in the flow queue one by one until the queue is empty or a threshold number of data packets are processed. At 412, the flow processing controller (110) creates a trigger packet. Furthermore, at 417, the flow processing controller (110) releases the critical section lock. At 418, the flow processing controller (110) enqueues the trigger packet into the general queue.

[0079] At 414, when the received packet is a new event or a core-specific event, the flow processing controller (110) determines whether the flow queue is empty. At 415, when the flow queue is not empty, the flow processing controller (110) enqueues the new packet at the end of the flow queue and continues to execute 409. At 416, when the flow queue is empty, the flow processing controller (110) processes the event and continues to execute 409.

[0080] In an example embodiment, upon receiving a packet, the core checks whether the received packet is a trigger packet. A trigger event is a buffer consisting of a message type as a trigger, wherein the buffer consists of a flow ID. The flow processing controller (110) uses parameters in the packet (e.g., call ID, radio bearer (RB) ID, cell number) to deduce the flow ID. The threshold number of data packets is configured based on the criticality of the core-specific event and the average processing cycle per packet. For example, if the event is a timer type and the timer duration is 10ms, then a processing time of + / - 0.01 milliseconds will not have a significant impact. If the average processing cycle per packet is 2000 and the system frequency is 2 GHz, then we can keep the threshold at 100.

[0081] After the core receives a non-triggering packet for a flow, and if the critical section flow lock can be acquired, the core checks the flow queue to find pending packets belonging to the same flow ID. When a pending data packet to be processed is found, the flow processing controller (110) enqueues the non-triggering packet at the end of the flow queue.

[0082] After the core receives the trigger packet, the flow processing controller (110) checks the critical section flow lock. In an embodiment, if the critical section flow lock cannot be obtained, the trigger packet may be discarded.

[0083] In another embodiment, if the critical section stream lock cannot be acquired, the stream processing controller (110) enqueues the pending packet in the pending list trigger event at the head of the stream queue.

[0084] In an example embodiment, the stream processing controller (110) continuously processes the stream queue and checks for time-critical events from the general queue.

[0085] Figure 5A - 5U is an example scenario illustrating data packet flow distribution in a multi-core processor (130) according to the embodiments disclosed herein. Figure 5A Consider an example scenario where a multi-core processor (130) includes three cores: core 1, core 2, and core 3. A general queue or ring is configured to provide packets in flow 1 to each core in parallel, and a core-specific event queue of each core is configured to provide core-specific events to the corresponding core. Flow 1 includes "n" packets. Assume that the threshold number of packets is configured to be 100. As Figure 5B As shown, core 1 receives packet 1 from the general queue or ring and processes the non-critical section (non-CS) of packet 1. In addition, core 1 detects the CS of packet 1, acquires the flow lock, and starts processing the CS.

[0086] like Figure 5CAs shown, core 2 receives packet 2 from the general queue or ring and processes the non-CS of packet 2. In addition, core 2 detects the CS of packet 2, but fails to acquire the flow lock because core 1 has already acquired the flow lock. Figure 5D As shown in , when the acquisition of the flow lock fails, core 2 enqueues packet 2 into the flow queue of flow 1 (flow queue 1). Similarly, packets 3 to 99 are processed in a similar manner to packet 2 and are enqueued into the flow queue 1. Figure 5E As shown, core 3 receives packet 100 from the general queue or ring and processes the non-CS of packet 100. In addition, core 3 detects packet 100 CS, and core 3 fails to acquire the flow lock because core 1 has already acquired the flow lock. Figure 5F As shown, when the acquisition of the flow lock fails, core 3 enqueues packet 100 into the flow queue of flow 1 (i.e., flow queue 1). Figure 5G As shown, the core dedicated event queue 1 receives the timer event of the core 1, wherein the timer event is a core dedicated event generated in the core dedicated event queue 1 and not processed by the core 1. Figure 5H As shown, core 1 pauses processing timer events because it is processing the CS of flow 1. The core processes packet 2.

[0087] like Figure 5I As shown, core 2 receives packet 101 from the general queue or ring and processes the non-CS of packet 101. In addition, core 2 detects the CS of packet 101, and since core 1 has already acquired the flow lock, core 2 fails to acquire the flow lock. Figure 5J As shown, when the acquisition of the flow lock fails, core 2 enqueues packet 101 into the flow queue of flow 1 (i.e., flow queue 1). Figure 5K As shown in , core 1 does not process the timer event until it has processed a threshold number of packets (i.e., 100 packets). Figure 5L As shown in FIG, after processing packet 100 (i.e., the threshold number of packets), core 1 creates a trigger event for flow 1, referred to as trigger event flow 1, and suspends processing of the CS of the remaining data packets in the flow queue. Figure 5M As shown, after processing a threshold number of data packets, core 1 releases the flow lock and sends the trigger event flow 1 to the general queue or ring to save the context of flow 1 data packets.

[0088] like Figure 5N As shown, core 1 processes timer events. Figure 5O As shown, a general queue or ring provides a stream of trigger events 1 to a core 2. Figure 5P As shown, core 2 receives trigger event flow 1 from the general queue or ring and processes the non-CS of trigger event flow 1. In addition, core 2 identifies the packet from which CS processing needs to be resumed (i.e., packet 101) based on the trigger event flow 1 processing, acquires the flow lock, and starts processing the CS of the packet in the flow queue. Figure 5QAs shown, core 1 receives packet n from the general queue or ring and processes the non-CS of packet n. In addition, core 1 detects the CS of packet n, but fails to acquire the flow lock because the flow lock has been acquired by core 2.

[0089] like Figure 5R As shown, when the acquisition of the flow lock fails, core 1 queues packet n into the flow queue of flow 1 (flow queue 1). Figure 5S As shown, core 2 receives packet 101 from flow queue 1 and processes the CS in packet 101. Figure 5T As shown, core 2 continues to process the CS of packets in the flow queue of flow 1 until the threshold number of packets is reached or the flow queue of flow 1 is cleared, and processes the CS in the received packets. Figure 5U As shown, after processing the CS of all packets in the 1st flow queue, core 2 releases the CS flow lock.

[0090] Figure 6 A flowchart (600) is shown of a method for distributing data packet flows in a multi-core processor (130) by creating a pending packet list according to example embodiments disclosed herein.

[0091] At 601, the flow processing controller (110) dequeues and receives packets from the general queue and the core-specific queue. At 602, the flow processing controller (110) performs initial validation of the packet by identifying the flow to which the packet belongs. At 603, the flow processing controller (110) determines whether the received packet is a core-specific event, a new event, or a pending list with a flow lock. At 604, when the received packet is not a core-specific event, a new event, or a pending list with a flow lock requirement, the flow processing controller (110) configures the core to process the received packet and continues execution at 601. At 605, when it is determined that a flow lock is required, the flow processing controller (110) determines whether the core succeeded or failed to acquire the critical section flow lock. At 618, when the acquisition of the critical section lock fails, the flow processing controller (110) checks the pending list.

[0092] At 606, when the packet is not on the pending list, the flow processing controller (110) enqueues the packet or event to the flow queue and continues to execute 601. At 619, when the data packet is on the pending list, the flow processing controller (110) enqueues the packet in the pending list to the head of the flow queue and continues to execute 601. At 607, the flow processing controller (110) determines whether the received packet is a new event or a core-specific event. At 608, when the received packet is not a new event or a core-specific event, the flow processing controller (110) processes the pending list. At 609, the flow processing controller (110) identifies the flow to which the pending list packet belongs and enqueues the packet in the pending list to the head of the flow queue to maintain the packet order. In addition, if the received packet is not on the pending list, the flow processing controller (110) executes 615. At 615, if the packet is a dedicated core event, a new packet, or a non-pending list packet, the flow processing controller (110) processes the critical section of the received packet and continues to dequeue packets one by one from the flow queue until the queue is empty or a threshold number of processed data packets is reached. At 610-612, the flow processing controller (110) processes packets in the flow queue one by one until the queue is empty or a threshold number of processed data packets is reached.

[0093] At 610, the stream processing controller (110) checks whether the stream queue is empty. At 614, when the stream queue is empty, the stream processing controller (110) releases the critical section stream lock. At 613, when the stream queue is not empty, the stream processing controller (110) creates a group list. At 616, the stream processing controller (110) releases the critical section stream lock. Furthermore, at 617, the stream processing controller (110) enqueues the pending list to the general queue.

[0094] The pending event list is a buffer consisting of a message type as a pending list, where the buffer consists of a flow ID and a list of pending events or packets. The threshold number of data packets is configured based on the criticality of the core-specific event and the average processing cycle per packet. For example, if the event is a timer type and the timer duration is 10ms, then processing of + / - 0.01 milliseconds will not have a significant impact. If the average processing cycle per packet is 2000 and the system frequency is 2 GHz, the threshold number of packets is 100. After receiving a packet, the core checks whether the packet is in the list of pending events.

[0095] After receiving the pending event list, the core obtains the corresponding flow ID and checks the critical section flow lock. If the critical section flow lock is available, the flow processing controller (110) adds the packets in the pending list to the head of the flow queue corresponding to the flow ID and processes the packets one by one.

[0096] After receiving the pending event list, the core checks the critical section flow lock. If the critical section flow lock is not available, the flow processing controller (110) queues the pending packet list at the head of the flow queue corresponding to the flow ID so that the core holding the critical section flow lock can process it next.

[0097] Figure 7 A flowchart (700) is shown of a method for distributing data packet flows in a multi-core processor (130) by processing intermediate dedicated events according to example embodiments disclosed herein.

[0098] At 701, the flow processing controller (110) dequeues and receives packets from the general queue and the core-specific queue. At 702, the flow processing controller (110) performs initial verification of the packet by identifying to which flow the packet belongs. At 703, the flow processing controller (110) determines whether the received packet is a core-specific event or a new event with a flow lock. At 704, when the received packet is not a core-specific event or a new event with a flow lock, the flow processing controller (110) configures the core to process the received packet and continues to execute 701. At 705, when it is determined that a flow lock is required, the flow processing controller (110) determines whether the core succeeded or failed to obtain the critical section flow lock. At 706, when the critical section flow lock failed, the flow processing controller (110) enqueues the event into the flow queue and continues to execute 701.

[0099] At 707 , when the core successfully acquires the critical section stream lock, the stream processing controller ( 110 ) detects a new event and configures the core to process the new event and performs an inspection.

[0100] At 708, the stream processing controller (110) checks whether the stream queue is empty. At 709, when the stream queue is empty, the stream processing controller (110) releases the critical section stream lock. At 710-711, when the stream queue is not empty, the stream processing controller (110) dequeues and processes packets from the stream queue one by one until the stream queue is empty or a threshold number of data packets are processed. At 712, if the threshold number of data packets are processed, the stream processing controller (110) checks core-specific events one by one until there are no pending such events to be processed. At 713, the stream processing controller (110) checks whether the core-specific events belong to the same stream. At 714, if the core-specific events belong to the same stream, the stream processing controller (110) processes the core-specific event. At 715, if the core-specific events do not belong to the same stream, the stream processing controller (110) creates a new stream-specific event and adds the new stream-specific event to the general queue to be processed by other available cores. The flow processing controller (110) performs 708 to inspect and further process the packets or events from the flow queue.

[0101] The various actions, behaviors, modules, operations, etc. in the flowcharts (300, 400, 600, and 700) may be performed in the order shown, in a different order, or simultaneously. In addition, in some embodiments, certain actions, behaviors, modules, operations, etc. may be omitted, added, modified, or skipped without departing from the scope of this disclosure.

[0102] Figure 8 1 shows an example of a trigger packet, a pending packet list, and a new flow-specific event according to an example embodiment disclosed herein. Reference numeral 801 is an example of a trigger packet. Reference numeral 802 is an example of a pending packet list. Reference numeral 803 is an example of a new flow-specific event.

[0103] The embodiments disclosed herein may use at least one hardware device to control these elements.

[0104] While the present disclosure has been illustrated and described with reference to various exemplary embodiments, it should be understood that the various exemplary embodiments are intended to be illustrative rather than restrictive. Those skilled in the art will further understand that various changes in form and details may be made without departing from the true spirit and full scope of the present disclosure, including the appended claims and their equivalents. It should also be understood that any embodiment described herein may be used in combination with any other embodiment described herein.

Claims

1. A method for distributing data packet streams in a multi-core processor (130) by an electronic device (100), comprising: Receiving, by the electronic device (100), at least one data packet to be processed by the multi-core processor (130); The electronic device (100) determines whether to acquire a stream lock of a data stream critical section at a core of the multi-core processor (130); Upon successful acquisition of the flow lock, determining by the electronic device (100) whether a threshold number of data packets from the flow queue are processed at the core; Upon processing a threshold number of data packets from a flow queue, determining, by the electronic device (100), pending data packets to be processed in the flow queue; When determining that there is a pending data packet to be processed in the flow queue, the electronic device (100) creates a new trigger packet or event; The electronic device (100) releases the stream lock of the critical section; as well as The electronic device (100) enqueues a new trigger packet or event into a general queue to be processed by other cores of the multi-core processor (130).

2. The method according to claim 1, wherein The cores of the multi-core processor (130) process data packets of the data flows from the flow queues in parallel.

3. The method according to claim 1, wherein The threshold number of data packets is configured based on the criticality of the core specific event and the average processing cycle per packet.

4. The method according to claim 1, wherein A new trigger packet or event is a buffer containing the message type that is the trigger. wherein the message or the buffer includes a stream identifier, Acquiring a stream lock and processing a threshold number of data packets of a data stream from a stream queue includes: The electronic device (100) determines whether a stream lock can be acquired based on a stream identifier in a new event or packet or a triggering packet or event; Determining, by the electronic device (100), whether the received data packet is a new event or packet or a triggering packet or event; After determining that the received data packet is a trigger packet or event, when the stream lock cannot be acquired, the electronic device (100) discards the received data packet; and After determining that the received data packet is a new event or packet or a triggering packet or event, the received data packet is processed by the electronic device (100) when the stream lock is successfully acquired.

5. The method according to claim 4, wherein: After determining that the received data packet is a new event or packet, upon successfully acquiring the stream lock, the electronic device (100) processes the received data packet, including: When it is determined that the stream queue is not empty, the new event or packet is queued at the end of the stream queue; When the flow queue is determined to be empty, new events or packets are processed; Data packets are dequeued from the flow queue and processed one by one until a threshold number of data packets are processed or the flow queue is empty.

6. The method of claim 4, wherein: After determining that the received data packet is a trigger packet or event, when the stream lock is successfully acquired, the electronic device (100) processes the received data packet including: Determining, by the electronic device (100), a data flow from a new trigger packet or event; dequeueing data packets one by one from the flow queue by the electronic device (100); and Data packets from the flow queue are processed one by one by the electronic device (100) until a threshold number of data packets are processed or the flow queue is empty.

7. The method of claim 4, wherein: Processing of the received data packet by the electronic device (100) includes: When determining that the flow queue is not empty, after processing a threshold number of data packets, creating a new trigger event by the electronic device (100) using the flow identifier; releasing the stream lock of the critical section by the electronic device (100); and The electronic device (100) enqueues a new trigger packet or event into a general queue to be processed by other cores of the multi-core processor (130).

8. The method of claim 1, wherein: The new trigger packet or event is a received data packet including a list of pending packets or events with a flow identifier, wherein acquiring a flow lock and processing a threshold number of data packets of a data flow from a flow queue comprises: The electronic device (100) determines whether the received data packet is a new packet or event or a triggered packet or event; The electronic device (100) determines whether to acquire a stream lock based on a stream identifier in a received trigger packet or event; After determining that the received data packet is a trigger packet or event or a new packet or event, the received trigger packet or event is processed by the electronic device (100).

9. The method of claim 8, wherein: After determining that the received data packet is a trigger packet or event, the electronic device (100) processes the received trigger packet or event, including: When the stream lock cannot be acquired, the pending data packets or events in the pending packet or event list are queued at the head of the stream queue; When the flow lock is successfully acquired, the received trigger packets or events are processed, the processed trigger packets or events in the pending packets or events list are enqueued at the head of the flow queue, and processed one by one from the flow queue until a threshold number of data packets are processed or the flow queue is empty.

10. The method of claim 8, wherein: After determining that the received data packet is a new packet or event, the electronic device (100) processes the received data packet including: Upon successful acquisition of the flow lock, the received data packets are processed by the electronic device (100), one by one from the flow queue until a threshold number of data packets are processed or the flow queue is empty.

11. The method of claim 8, wherein: Processing by the electronic device (100) includes: Upon determining that the flow queue is not empty, after processing a threshold number of data packets, creating, by the electronic device (100), a new trigger event using the pending packet or event list and the flow identifier; releasing the stream lock of the critical section by the electronic device (100); and The electronic device (100) enqueues a new trigger packet or event into a general queue to be processed by other cores of the multi-core processor (130).

12. The method of claim 1, wherein: Upon successfully acquiring the flow lock, determining, by the electronic device (100), whether a threshold number of data packets from the flow queue are being processed at the core, comprises: determining, by the electronic device (100), that a threshold number of data packets are processed; Dequeueing core-specific events or time-critical events from a stream queue by the electronic device (100); The electronic device (100) determines a corresponding stream of the acquired event; When it is determined that the acquired event belongs to a different stream, the electronic device (100) queues the acquired event into a universal queue; When it is determined that the acquired events belong to the same stream, the electronic device (100) processes the acquired events; Determining, by the electronic device (100), the number of data packets in the flow queue; dequeuing data packets from the flow queue by the electronic device (100) until the flow queue is empty; and The data packets are processed by the electronic device (100).

13. The method of claim 1, wherein: All enqueues and dequeues to the stream queue are performed after acquiring the stream lock.

14. An electronic device (100) for distributing data packet flows in a multi-core processor (130), comprising: Memory (120); Multi-core processor (130); as well as A stream processing controller (110), coupled to a memory (120) and a multi-core processor (130), is configured to: receiving at least one data packet to be processed by a multi-core processor (130), determining whether to acquire a stream lock for a data stream critical section at a core of the multi-core processor (130); upon successfully acquiring the flow lock, determining whether a threshold number of data packets from the flow queue are being processed at the core; upon processing a threshold number of data packets from the flow queue, determining pending data packets to be processed in the flow queue; When it is determined that there is a pending data packet to be processed in the flow queue, a new trigger packet or event is created; Release the stream lock of the critical section; as well as New trigger packets or events are enqueued to a general queue to be processed by other cores of the multi-core processor (130).

15. A non-transitory computer-readable medium storing instructions that, when executed by a processor of an electronic device (100), cause the electronic device to: receiving at least one data packet to be processed by a multi-core processor (130), determining whether to acquire a stream lock for a data stream critical section at a core of the multi-core processor (130); upon successfully acquiring the flow lock, determining whether a threshold number of data packets from the flow queue are being processed at the core; upon processing a threshold number of data packets from the flow queue, determining pending data packets to be processed in the flow queue; When it is determined that there is a pending data packet to be processed in the flow queue, a new trigger packet or event is created; Release the stream lock of the critical section; as well as New trigger packets or events are enqueued to a general queue to be processed by other cores of the multi-core processor (130).

Images