Flow control method, electronic device, storage medium, chip system, and program product

Abstract

Embodiments of the present application provide a flow control method, an electronic device, a storage medium, a chip system and a program product, which are applied to the field of communication technology. The method is applied to a first processor core. In the method, the first processor core receives service data sent by a second processor core at a first speed, and the second processor core is different from the first processor core. The first processor core detects whether to perform flow control according to a data amount of the service data received in a first time period. In the case of detecting that flow control is to be performed, the first processor core sends a flow control message to the second processor core, and the flow control message indicates a sending speed of the service data. The first processor core receives service data sent by the second processor core at a second speed, and the second speed is determined by the second processor core based on the flow control message, and the second speed is less than the first speed. Thus, data loss and / or data delay during flow control can be reduced, and the reliability of data transmission is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a flow control method, electronic device, storage medium, chip system, and program product. Background Technology

[0002] To achieve efficient parallel computing and multitasking capabilities, electronic devices (such as mobile phones and wearable devices) are typically equipped with multi-core processors. A multi-core processor can include multiple cores capable of independently processing tasks. Communication between different cores (hereinafter referred to as inter-core communication) is the foundation for the efficient collaborative work of multi-core processors. For the communication process between different cores, electronic devices can perform flow control (also known as management or flow control) to reduce data loss and thus improve the reliability of data transmission.

[0003] Currently, most electronic devices employ a dual-core architecture with inter-core communication, where the two cores have a master-slave relationship. When the two cores communicate, the master core can control the opening and closing of the communication channel between them. For example, the slave core can monitor its own buffer usage in real time. When the master core continuously sends a large amount of business data to the slave core at high speed, the slave core's buffer usage rises rapidly. When the slave core's buffer usage exceeds or equals a preset flow control threshold, the slave core sends flow control information to the master core. Based on this flow control information, the master core closes the communication channel between the master and slave cores.

[0004] However, during the period when the communication channel is closed, the two cores cannot communicate with each other, which causes the main core to fail to send data and results in significant data loss. As a result, the reliability of data transmission between the two cores remains poor. Summary of the Invention

[0005] This application provides a flow control method, electronic device, storage medium, chip system, and program product, which can reduce the transmission rate of service data in the sending core when flow control is detected as necessary. This can mitigate data loss and improve the reliability of data transmission between different cores.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a flow control method applied to a first processor core, the method comprising:

[0008] A first processor core receives service data transmitted by a second processor core at a first speed. The second processor core is different from the first processor core. The first processor core detects whether to perform flow control based on the amount of service data received within a first time period. If flow control is detected, the first processor core sends a flow control message to the second processor core, indicating the transmission speed of the service data. The first processor core receives service data transmitted by the second processor core at a second speed, which is determined by the second processor core based on the flow control message. The second speed is less than the first speed.

[0009] The first processor core and the second processor core can be two processor cores on the same chip in the same electronic device, processor cores on different chips in the same electronic device, or processor cores in different electronic devices. A processor core can be a core in a multi-core processor capable of independently processing tasks. Examples of processor cores include a central processing unit (CPU) core, a Bluetooth (BT) core, a sensor hub core, a graphics processing unit (GPU) core, a Wi-Fi core, or a digital signal processor (DSP) core. The first speed can be the sum of the transmission speeds of all data transmission services in the first processor core, or it can be the transmission speed of each data transmission service in the first processor core. The first processor core and the second processor core are different; they are not the same processor core. However, the type of the first processor core and the type of the second processor core can be the same. For example, both the first processor core and the second processor core can be CPU cores. The type of the first processor core and the type of the second processor core can also be different. For example, the first processor core is a BT core, and the second processor core is a CPU core.

[0010] In this embodiment, the first processor core can detect whether flow control needs to be performed based on the amount of service data received within a certain time period. If flow control is deemed necessary, it indicates that the first processor core is about to be or has already been filled with service data. Therefore, the first processor core sends a flow control message to the second processor core, indicating the transmission speed of the service data. The second processor core can then transmit service data according to the transmission speed indicated by the flow control message. In other words, during flow control, the second processor core can still successfully send data to the first processor core, thus improving the situation where data loss occurs due to communication channel closure during flow control in related technologies. Furthermore, during flow control, the second processor core transmits service data at a reduced transmission speed, making the service data transmitted more slowly, thereby alleviating service data congestion and reducing the waiting time for service data consumption. This improves the reliability of data transmission. Based on the above analysis, it can be determined that the second processor core in this embodiment can improve data loss and / or data latency by reducing the transmission speed of service data. Therefore, neither the first nor the second processor core needs to frequently open or close the communication channel between them, which helps improve the stability of data transmission.

[0011] It should be noted that a processor may include multiple cores, and when these multiple cores can communicate with each other, the flow control method provided in the embodiments of this application can also be used for flow control during the communication between these multiple cores.

[0012] In one possible implementation of the first aspect, the first processor core determines whether to perform flow control based on the amount of service data received within a first time period. This includes: the first processor core calculating a first ratio of the data amount to the first time period to obtain a first transmission rate. The first ratio of the data amount to the first time period can be understood as the first ratio of the data amount to the duration of the corresponding first time period. For example, if the first time period is from 8:00:00 to 8:00:05, the duration of the first time period is the difference between 8:00:05 and 8:00:00, which is 5 seconds. The first processor core then checks whether the first transmission rate is greater than a second transmission rate, where the second transmission rate is the maximum transmission rate between the first and second processor cores. If the first transmission rate is greater than the second transmission rate, flow control is performed; if the first transmission rate is less than the second transmission rate, flow control is not performed.

[0013] In this implementation, the second transmission rate is the maximum transmission rate between the first and second processor cores. In other words, the second transmission rate is designed with optimal throughput as the target. Therefore, the second transmission rate reflects the rate at which services consume service data in the first processor core. When the first transmission rate is less than the second transmission rate, it means that the rate at which service data enters the first processor core is less than the rate at which service data is consumed. In this case, the first processor core will not be filled, and therefore flow control is not required. When the first transmission rate is greater than the second transmission rate, it means that the rate at which service data enters the first processor core is greater than the rate at which service data is consumed. Over time, the first processor core is more likely to be filled, thus requiring flow control.

[0014] In another possible implementation of the first aspect, before the first processor core detects whether to perform flow control based on the amount of service data received within a first time period, the method further includes: the first processor core determining the first time period based on a second ratio of the maximum capacity of the first storage area and the second transmission rate. The first storage area is a storage area within the first processor core used to store service data.

[0015] In this implementation, since the first time period is the ratio of the maximum capacity of the first storage area to the second transmission rate, the duration of the first time period can be understood as the shortest time required for the first storage area to be filled. That is, the first storage area will not be filled until at least the duration corresponding to the first time period has elapsed. Therefore, compared to determining whether flow control is needed based on the amount of business data corresponding to a duration longer than the first time period, the first processor core determines whether flow control is needed more promptly based on the amount of business data corresponding to the first time period. This allows for earlier identification of situations requiring flow control, enabling the first processor core to trigger flow control in a timely manner and reducing data loss.

[0016] In another possible implementation of the first aspect, before the first processor core sends the flow control message to the second processor core, the method further includes: the first processor core calculating the difference between a first transmission rate and a second transmission rate, and generating a flow control message. The flow control message includes a reduction in the transmission rate, where the reduction is greater than or equal to the difference. The second rate is obtained by the second processor core by subtracting the reduction from the first rate. In other words, the first transmission rate calculated by the first processor core can be used not only to determine whether flow control should be initiated, but also to calculate the reduction in the transmission rate, so as to explicitly instruct the second processor core on how to control the transmission rate of the service based on instructing the second processor core to perform flow control.

[0017] In another possible implementation of the first aspect, the flow control message includes a first identifier indicating a target service. The first processor core receives service data transmitted by the second processor core at a second speed, including: the first processor core receiving service data of the target service transmitted by the second processor core at the second speed, the target service being determined by the second processor core based on the first identifier. The transmission speed of services other than the target service in the second processor core can remain unchanged.

[0018] In this implementation, the second processor core can adjust the speed at which the target service sends service data based on the first identifier in the flow control message, so as not to affect the transmission efficiency of services other than the target service in the second processor core while achieving flow control.

[0019] In another possible implementation of the first aspect, the service data includes a second identifier, which indicates the source service of the service data. Before the first processor core sends a flow control message to the second processor core, the method further includes: the first processor core calculating the data volume of each source service based on the second identifier in the service data received within a first time period. The first identifier indicates the first number of source services with the largest data volume.

[0020] In this implementation, the target service is the service with the largest amount of data sent by the second processor core within the first time period, indicating a higher transmission speed for the target service. Therefore, the potential for reducing the transmission speed of the target service is also greater. Thus, when the second processor core adjusts the transmission speed of the target service, it can more easily mitigate data latency and / or data loss in the first processor core, improving data transmission reliability and flow control efficiency with only a single adjustment, without affecting the transmission rate of services with smaller data volumes sent by the second processor core within the first time period. Furthermore, ignoring smaller data volumes also saves computing resources for the first processor core, improving computational efficiency.

[0021] In another possible implementation of the first aspect, multiple second processor cores exist, and the service data carries a third identifier, which indicates the source processor core of the service data. The first processor core sends a flow control message to the second processor cores, including: the first processor core sending the flow control message to the second processor core based on the third identifier. The service data carries the third identifier so that the first processor core can determine which second processor core the flow control message should be sent to.

[0022] In another possible implementation of the first aspect, after the first processor core receives service data transmitted by the second processor core at a second speed, the method further includes: the first processor core sending a flow control release message to the second processor core. The flow control release message instructs the first processor core to release flow control, and the flow control release message may include a third speed, which may be greater than the second speed. The first processor core receives service data transmitted by the second processor core at the third speed. In this way, the second processor core can improve inter-core communication efficiency within the capacity of the first processor core.

[0023] Normally, the third speed can be the first speed.

[0024] In some scenarios, the flow control process may involve multiple rate reductions. The first rate can be the reduced rate, therefore, the third rate can be the first rate, or it can be the rate before the initial rate reduction.

[0025] In another possible implementation of the first aspect, the method further includes: before detecting that flow control needs to be performed, the first processor core stores received service data in a first storage area, the first storage area being a storage area within the first processor core used for storing service data. After detecting that flow control needs to be performed, the first processor core stores received service data in a second storage area, the second storage area being a shared storage area of ​​one or more processor cores in the chip where the first processor core resides. The service data received by the first processor core after detecting that flow control needs to be performed may include service data transmitted at a first speed before the second processor core transmits service data at a second speed, as well as service data transmitted by the second processor core at a second speed. Thus, when the first processor core receives service data after the first storage area is full, the first processor core can store the service data in the second storage area, thereby reducing the loss of service data.

[0026] The business data stored in the first storage area and the second storage area may include the business data received by the first processor core.

[0027] In another possible implementation of the first aspect, after detecting that flow control needs to be performed, the first processor core stores the received service data in the second storage area, including: after detecting that flow control needs to be performed, the first processor core stores the received service data in the corresponding location in the second storage area based on priority.

[0028] The priority of the business data can be either first priority or second priority, with first priority being higher than second priority. After detecting that flow control needs to be performed, the first processor core can store the business data according to its priority and prioritize the consumption of first-priority business data so that first-priority business data is not delayed due to flow control.

[0029] In another possible implementation of the first aspect, after detecting that flow control needs to be performed, the first processor core stores the received service data in the second storage area, including: after detecting that flow control needs to be performed, if the length of the received service data is greater than the remaining capacity of the first storage area, the first processor core stores the received service data in the second storage area. The method further includes: after detecting that flow control needs to be performed, if the length of the received service data is less than the remaining capacity of the first storage area, the first processor core stores the received service data in the first storage area.

[0030] In this implementation, if the length of the service data is less than the remaining capacity of the first storage area, it indicates that the first storage area has sufficient capacity to store the service data. Therefore, the first processor core stores the received service data in the first storage area. If the length of the service data is greater than the remaining capacity of the first storage area, it indicates that the first storage area no longer has sufficient capacity to store the service data. Therefore, the first processor core stores the received service data in the second storage area.

[0031] In another possible implementation of the first aspect, the method further includes: a first processor core consuming business data in a first storage area and business data in a second storage area. After storing the received business data in the second storage area, the method further includes: if the amount of business data stored in the second storage area is less than a preset value, releasing the second storage area to avoid wasting memory resources.

[0032] Secondly, embodiments of this application provide a flow control method applied to a second processor core. The method includes: the second processor core sending service data to a first processor core at a first speed, wherein the second processor core is different from the first processor core. The second processor core receives a flow control message sent by the first processor core, the flow control message indicating the sending speed of the service data. The second processor core determines a second speed at which it sends the service data based on the flow control message. Then, the second processor core sends the service data to the first processor core at the second speed. The second speed is less than the first speed.

[0033] In this embodiment, during flow control, the second processor core can still successfully send data to the first processor core, thus mitigating data loss caused by communication channel closure during flow control in related technologies. Furthermore, during flow control, the second processor core sends service data at a reduced transmission rate, resulting in slower data delivery and alleviating congestion, thereby reducing the time required for service data to be consumed. This improves data transmission reliability. Based on the above analysis, it can be determined that the second processor core in this embodiment can improve data loss and / or data latency by reducing the transmission rate of service data. Therefore, neither the first nor the second processor core needs to frequently open or close the communication channel between them, contributing to improved data transmission stability.

[0034] In one possible implementation of the second aspect, the flow control message includes a first identifier indicating a target service. The second processor core determines a second speed at which it transmits service data based on the flow control message, including: the second processor core determines the transmission speed of the service data for the target service as the second speed based on the flow control message. The second processor core transmits service data to the first processor core at the second speed, including: the second processor core transmits the service data for the target service to the first processor core at the second speed.

[0035] In this implementation, the second processor core can adjust the speed at which the target service sends service data based on the first identifier in the flow control message, so as not to affect the transmission efficiency of services other than the target service in the second processor core while achieving flow control.

[0036] In one possible implementation of the second aspect, the first identifier indicates the first number of source services with the largest amount of data.

[0037] In this implementation, the target service is the service with the largest amount of data sent by the second processor core within the first time period, indicating a higher transmission speed for the target service. Therefore, the potential for reducing the transmission speed of the target service is also greater. Thus, when the second processor core adjusts the transmission speed of the target service, it can more easily mitigate data latency and / or data loss in the first processor core, improve data transmission reliability and flow control efficiency, with only a single adjustment, without affecting the transmission rate of services with smaller data volumes sent by the second processor core within the first time period.

[0038] In another possible implementation of the second aspect, after the second processor core sends service data to the first processor core at a second speed, the method further includes: the second processor core receiving a flow control release message sent by the first processor core. The flow control release message instructs the first processor core to release flow control, and the flow control release message includes a third speed, which is greater than the second speed. The second processor core then sends service data to the first processor core at the third speed. In this way, the second processor core can improve inter-core communication efficiency within the capacity of the first processor core.

[0039] Normally, the third speed can be the first speed.

[0040] In some scenarios, the flow control process may involve multiple rate reductions. The first rate can be the reduced rate, therefore, the third rate can be the first rate, or it can be the rate before the initial rate reduction.

[0041] Thirdly, embodiments of this application provide a flow control method applied to a second processor core. The method includes: services in the second processor core sending service data to a third storage area at a first speed; and the second processor core sending service data from the third storage area to a first processor core. The third area is a storage area in the second processor core used to store service data to be sent to the first processor core; the first processor core is different from the second processor core. The second processor core detects whether flow control needs to be performed based on the amount of service data sent within a second time period. If flow control is detected, the second processor core generates a flow control message indicating the sending speed of the service data. The second processor core determines the sending speed of the service data sent to the third storage area based on the flow control message. Services in the second processor core send service data to the third storage area at a second speed.

[0042] In this embodiment, when the second processor core determines that flow control is required, it indicates that the transmit buffer is about to be filled with service data or has already been filled. Therefore, the second processor core sends a flow control message to the service in the transmit core to reduce the rate at which the service transmits service data. In this way, the amount of service data sent to the transmit buffer per unit time is reduced, thereby alleviating the situation where the transmit buffer is about to be filled with service data or has already been filled.

[0043] In one possible implementation of the third aspect, the second processor core determines whether to perform flow control based on the amount of service data sent within the second time period. This includes: the second processor core calculating a third ratio of the data amount to the second time period to obtain a third transmission rate; and detecting whether the third transmission rate is greater than the second transmission rate, where the second transmission rate is the maximum transmission rate between the first and second processor cores. If the third transmission rate is greater than the second transmission rate, flow control is performed; if the third transmission rate is less than the second transmission rate, flow control is not performed.

[0044] In this implementation, the third transmission rate can be understood as an assessment of the amount of service data sent to the send buffer per unit time in the second time period. Therefore, when the third transmission rate is greater than the second transmission rate, it means that the service's transmission speed from the send buffer to the send buffer is greater than the transmission speed of the service data from the send buffer to the first processor core via the communication channel. This indicates a tendency for the send buffer to fill up with the service data sent by this service. Subsequently, the second processor core can send flow control messages to the services within the second processor core to reduce the service's transmission speed from the send buffer to the send buffer, ensuring that the transmission speed is less than the transmission speed of the service data from the send buffer to the first processor core via the communication channel. This alleviates the tendency for the send buffer to fill up, thereby reducing the waiting time of service data in the send buffer and mitigating data loss caused by the send buffer potentially filling up during flow control.

[0045] In another possible implementation of the third aspect, before the second processor core detects whether to perform flow control based on the amount of service data sent during the second time period, the method further includes: the second processor core determining the second time period based on a fourth ratio of the maximum capacity of the third storage area and the second transmission rate.

[0046] In this implementation, since the second time period is the ratio of the maximum capacity of the third storage area to the second transmission rate, the duration of the second time period can be understood as the shortest time required for the third storage area to be filled. In other words, the third storage area will not be filled until at least the duration corresponding to the second time period has elapsed. Therefore, compared to determining whether flow control is needed based on the amount of business data corresponding to a duration longer than the second time period, the second processor core determines whether flow control is needed more promptly based on the amount of business data corresponding to the second time period. This allows for earlier identification of situations requiring flow control, enabling the second processor core to trigger flow control in a timely manner and reducing data loss.

[0047] In another possible implementation of the third aspect, before the second processor core generates the flow control message, the method further includes: the second processor core calculating the difference between the third transmission rate and the second transmission rate, generating a flow control message, the flow control message including the reduction in transmission speed, the reduction being greater than or equal to the difference. Here, the second speed is obtained by the second processor core subtracting the reduction from the first speed. That is, the third transmission rate calculated by the second processor core can be used not only to determine whether flow control should be initiated, but also to calculate the reduction in transmission speed, so as to explicitly instruct the services in the second processor to control the transmission speed based on the instruction to the second processor to execute flow control.

[0048] In another possible implementation of the third aspect, the flow control message includes a first identifier indicating a target service. The service in the second processor core sends service data to the third storage area at a first speed, including: the target service in the second processor core sending service data to the third storage area at the first speed, the target service being determined by the second processor core based on the first identifier.

[0049] In this implementation, the second processor core can adjust the speed at which the target service sends service data based on the first identifier in the flow control message, so as not to affect the transmission efficiency of services other than the target service in the second processor core while achieving flow control.

[0050] Fourthly, embodiments of this application provide an electronic device, including: a memory and one or more processors. The memory and processors are coupled. The processor may include a first processor core and a second processor core. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method of the first aspect and its possible implementations, the method of the second aspect and its possible implementations, or the method of the third aspect and its possible implementations.

[0051] Fifthly, embodiments of this application provide a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method of the first aspect and its possible implementations, the method of the second aspect and its possible implementations, or the method of the third aspect and its possible implementations.

[0052] Sixthly, embodiments of this application provide a chip system applied to an electronic device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the electronic device to perform the method of the first aspect and its possible implementations, the method of the second aspect and its possible implementations, or the method of the third aspect and its possible implementations.

[0053] In a seventh aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method as described in the first aspect and its possible implementations, the method as described in the second aspect and its possible implementations, or the method as described in the third aspect and its possible implementations.

[0054] Understandably, the beneficial effects achieved by the electronic device of the fourth aspect, the computer-readable storage medium of the fifth aspect, the chip system of the sixth aspect, and the computer program product of the seventh aspect provided above can be referred to the beneficial effects of the first to third aspects, which will not be repeated here. Attached Figure Description

[0055] Figure 1 This is a schematic diagram of an inter-core communication scenario provided in an embodiment of this application;

[0056] Figure 2 One of the flowcharts of the flow control method provided in the embodiments of this application;

[0057] Figure 3 Provided for the embodiments of this application Figure 2 A schematic diagram illustrating the flow control effects of the flow control methods described in the diagram;

[0058] Figure 4 A second schematic flowchart of the flow control method provided in the embodiments of this application;

[0059] Figure 5 Provided for the embodiments of this application Figure 4 A schematic diagram illustrating the flow control effects of the flow control methods described in the diagram;

[0060] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0061] Figure 7 A schematic diagram of an inter-core communication architecture provided in an embodiment of this application;

[0062] Figure 8 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0063] Figure 9 The third schematic flowchart of the flow control method provided in the embodiments of this application;

[0064] Figure 10 A schematic diagram illustrating the process of storing and consuming business data, provided for an embodiment of this application;

[0065] Figure 11 A flowchart illustrating yet another flow control method provided in this application embodiment;

[0066] Figure 12This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0067] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0068] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0069] To achieve efficient parallel computing and multitasking capabilities, electronic devices are typically equipped with multi-core processors. A multi-core processor can include multiple cores capable of independently processing tasks. A multi-core processor can be understood as a chip integrating multiple cores, which can be of the same or different types. These cores can be, for example, a central processing unit (CPU) core, a Bluetooth (BT) core, a sensor hub core, a graphics processing unit (GPU) core, a Wi-Fi core, or a digital signal processor (DSP) core, etc.

[0070] Among them, the CPU core can be used to execute instructions, process data, and coordinate system operation; the BT core can be used to process the Bluetooth protocol stack; the sensor hub core can be used to manage sensor data; the GPU core can be used for image rendering and parallel computing; the Wi-Fi core can be used to process Wi-Fi communication; and the DSP core can be used to process digital signals.

[0071] It is understood that the cores included in the multi-core processors of different types of electronic devices may vary. This application does not specifically limit the type and number of cores included in an electronic device. For example, the multi-core processor cores in a wearable device may include: a CPU core, a sensor hub core, a BT core, and a Wi-Fi core. The multi-core processor cores in a mobile phone may include: a CPU core, a sensor hub core, a BT core, a GPU core, a DSP core, and a Wi-Fi core.

[0072] Different cores can communicate with each other; the process of communication between different cores is called inter-core communication.

[0073] For example, Figure 1 This is a schematic diagram of an inter-core communication scenario provided in an embodiment of this application. Figure 1 As shown, in this scenario, the electronic device may include N cores, where N can be an integer greater than 1. For ease of explanation, an example of N=2 is used. The first core (represented by the CPU core in the diagram) and the second core (represented by the BT core in the diagram) can reside on the same chip or different chips of the electronic device. For example, the CPU core and the BT core in the electronic device can reside on a system-on-a-chip (SOC) of the electronic device. The first core and the second core can communicate with each other through a communication channel. For example, the first core and the second core can transmit business data through the communication channel.

[0074] In some implementations, the first and second cores can also be located in two separate electronic devices.

[0075] For example, the electronic devices in this application embodiment may be wearable devices, mobile phones, tablets, desktops, laptops, handheld computers, laptops, ultra-mobile personal computers (UMPCs), augmented reality (AR) or virtual reality (VR) devices, etc., that have multi-core processors and are capable of cross-core communication. Wearable devices may include smartwatches, smart bracelets, smart glasses, smart helmets, etc., that can be worn on the user's body or integrated into clothing. This application embodiment does not impose any special limitations on the specific form of the electronic devices.

[0076] In the following description, the transmitting core and the receiving core are two cores in the same electronic device, with the transmitting core being a CPU core and the receiving core being a BT core. It should be understood that this example does not constitute a limitation on the embodiments of this application. For example, the transmitting core and the receiving core may also be located in different electronic devices. Furthermore, the transmitting core and / or the receiving core may be other cores.

[0077] It's important to note that the distinction between send and receive cores is based solely on their data transmission and reception capabilities. In different business scenarios, a single core can perform different functions, allowing for switching between send and receive roles. For example, for sports and health data, the BT core can send it to the CPU core for processing; in this case, the BT core acts as the send core, and the CPU core as the receive core. Conversely, for audio data, the CPU core can send it to the BT core; in this case, the BT core acts as the receive core, and the CPU core as the send core.

[0078] In this embodiment, a business function can be understood as a logical unit or module designed within an application to achieve a specific function or solve a specific problem. Each business function typically corresponds to a specific function or service. Business data refers to the data produced and / or processed by the business function, and can reflect business status, rule execution results, and user interaction traces, etc.

[0079] For example, taking a navigation application as an example, a navigation application may include various services such as map display, location services, route planning, navigation, and search. For instance, the data for map display services may include image or vector data, map style configurations (such as night mode, terrain mode, etc.), and the user's current field of view, while the data for location services may include raw data from the Global Positioning System (GPS) (such as latitude, longitude, altitude, speed, etc.) and positioning accuracy.

[0080] It is understood that the applications in different cores can be the same or different; that is, the business logic in different cores can be the same or different. This application does not specifically limit the business logic in different cores.

[0081] It is understood that the number of cores, types of cores, business operations, and business data in the above scenarios are merely illustrative examples, and the embodiments of this application are not limited thereto.

[0082] As mentioned above, the sending core can send service data to the receiving core. However, due to the receiving core's poor data processing capabilities and / or insufficient memory resources, data loss is a significant issue. Specifically, the receiving core's memory resources can include its receive buffer. The receive buffer is a memory area within the receiving core that stores received data.

[0083] For example, the BT core can store service data sent by the CPU core in its receive buffer. When the BT core's data processing capacity is insufficient, its receive buffer may become full. Subsequently, the BT core's receive buffer will no longer be able to receive newly arriving service data. Therefore, newly arriving service data is prone to loss. The BT core's receive buffer can be understood as a storage area within the BT core used to temporarily store received but unprocessed service data.

[0084] For example, when the receive buffer of the BT core is small, the receive buffer is prone to overflow, resulting in data loss.

[0085] Therefore, in order to mitigate data loss during inter-core communication and improve data transmission reliability, electronic devices can perform flow control (also known as management or flow control) on inter-core communication.

[0086] In some implementations, electronic devices employ a dual-core architecture with inter-core communication, where the two cores have a master-slave relationship. The slave core can send flow control information to the master core. The master core can close the communication channel based on the flow control information sent by the slave core. The master core can also be used to open the communication channel.

[0087] The following example illustrates the flow control process of inter-core communication in the aforementioned dual-core architecture, using the CPU core as the master core and the BT core as the slave core, with the master core acting as the sending core and the slave core as the receiving core. Figure 2 As shown, the method may include S201-S208.

[0088] S201, the CPU core sends service data to the BT core at the first rate.

[0089] S202, BT core stores the received service data.

[0090] S203, BT core consumes and stores business data.

[0091] S204, BT verification monitors the cache usage rate of the BT core.

[0092] The BT core's buffer utilization rate can be understood as the utilization rate of the BT core's receive buffer.

[0093] S205. When the cache utilization rate of the BT core is greater than or equal to the preset flow control threshold, the BT core generates a first flow control message, which indicates that the cache utilization rate of the BT core is greater than or equal to the preset flow control threshold.

[0094] S206, the BT core sends the first flow control message to the CPU core.

[0095] In real-world scenarios, the initial flow rate is relatively high to improve the efficiency of the CPU core sending service data to the BT core. However, when the CPU core continuously sends a large amount of service data to the BT core at a high speed, the BT core's buffer utilization rate rises rapidly. When the BT core's buffer utilization rate is greater than or equal to the BT core's preset flow control threshold, the BT core can generate a first flow control message and send it to the CPU core.

[0096] S207, CPU core closes the communication channel between CPU core and BT core.

[0097] Understandably, after the CPU core closes the communication channel, it cannot send business data to the BT core.

[0098] S208. After waiting for the first preset time, the CPU core opens the communication channel.

[0099] Afterwards, the CPU core can continue to send business data to the BT core.

[0100] Below, in conjunction with Figure 3 illustrate Figure 2 The flow control effect of the flow control method in the text.

[0101] like Figure 3 As shown, when the CPU core continuously sends a large amount of service data to the BT core at high speed, the BT core's buffer utilization rapidly rises to the flow control threshold. After the CPU core closes the communication channel, it cannot send service data to the BT core; therefore, the service data flow on the communication channel (hereinafter referred to as channel flow) becomes 0. Since the BT core's receive buffer no longer receives service data and the BT core consumes the service data in the receive buffer after the CPU core closes the communication channel, the BT core's buffer utilization decreases.

[0102] based on Figure 3 It can be determined that during the period when the communication channel is closed, i.e., during flow control, the CPU core cannot send service data to the BT core through the communication channel. Therefore, the service data in the BT core's receive buffer no longer increases. Thus, as the BT core consumes the service data already received in its receive buffer, the amount of service data in the BT core's receive buffer gradually decreases, and the BT core's buffer utilization rate gradually declines. Therefore, after the communication channel is reopened, the BT core can continue to receive service data sent by the CPU core, thereby mitigating data loss caused by the BT core's receive buffer becoming full or overflowing.

[0103] However, using the above Figure 2 The technical solution has at least the following drawbacks:

[0104] First, the CPU core directly controls the opening and closing of the communication channel, and the service is unaware of the opening and closing of the channel. Therefore, even after the communication channel is closed, the service continues to send service data. However, because the communication channel is closed, the CPU core will fail to send service data to the BT core, resulting in the loss of this service data. Therefore, the data transmission reliability of inter-core communication is still relatively poor.

[0105] Second, the CPU core only controls the opening or closing of the communication channel. After the communication channel is reopened, the service continues to send service data to the BT core at a high speed, causing the BT core's buffer usage to rise rapidly to the flow control threshold again. The CPU core will then close the communication channel, which may require frequent opening or closing of the communication channel, affecting the stability of data transmission.

[0106] Third, only the CPU core, acting as the master core, can control the opening and closing of the communication channel, thereby achieving flow control over the BT core's received service data. However, in other scenarios, the CPU core remains the master core but acts as the receiver, while the BT core remains the slave core but acts as the transmitter. In these scenarios, the BT core, as the slave core, cannot control the opening and closing of the communication channel, and therefore cannot achieve flow control over the CPU core's received service data. In other words, when the master core acts as the receiver, it is difficult to achieve the flow control described above. Figure 2 The technical solution implements flow control for the receiving core's received service data. However, if the BT core continues to send service data to the CPU core at high speed, it can easily cause congestion of service data within the CPU core, thus extending the waiting time for service data to be consumed.

[0107] In view of this, embodiments of this application provide a flow control method. In this method, when the receiving core determines that flow control is necessary, the receiving core generates a second flow control message (hereinafter referred to as the flow control message) and sends the flow control message to the sending core. The sending core reduces the transmission rate of service data in the sending core based on the flow control message sent by the receiving core. The flow control message indicates the transmission rate of the service data. Specifically, as shown... Figure 4 As shown, flow control methods may include S401-S407.

[0108] S401. The transmitting core (also known as the second processor core) sends service data to the receiving core (also known as the first processor core) at a first speed.

[0109] The receiving core and the transmitting core can be any two cores from a multi-core processor in the electronic device. For example, the receiving core is a BT core, and the transmitting core is a CPU core.

[0110] S402, The receiving core stores the received service data in the receiving buffer, and the receiving core consumes the service data in the receiving buffer.

[0111] It is understandable that the receiving core can continuously receive business data, and the receiving core can continuously consume business data in the receive buffer.

[0112] S403: The receiving core determines whether flow control is required based on the amount of service data received within the target time period (also known as the first time period) and the maximum capacity of the receiving buffer. The maximum capacity of the receiving buffer is the maximum number of bytes that the receiving buffer can store. If yes, then execute S404 and subsequent steps; otherwise, execute S403 and subsequent steps.

[0113] The target time period refers to the shortest time taken for the receiving core's receive buffer to fill up. The volume of business data can be understood as the total number of bytes. The target time period can be an empirical value or calculated in real-time. For details on calculating the target time period, please refer to the following text. Figure 9 The description in the corresponding embodiment.

[0114] For example, the units for the amount of business data and the maximum capacity of the receiving buffer can be bytes (B) (or bits), kilobytes (KB) (or kilobits), or megabytes (MB) (or megabits), etc.

[0115] If the receiving core determines that flow control is required, it means that the receiving buffer is about to be filled with received service data or has already been filled with service data. In this case, the receiving core can notify the sending core to perform flow control, such as by executing S404 and subsequent steps below.

[0116] If the receiving core determines that flow control is not required, it means that the receiving buffer has enough capacity to store more service data. Therefore, the receiving core executes S403 and subsequent steps.

[0117] This application does not specifically limit the implementation method of the receiving core determining whether flow control is required. This application only lists two exemplary methods.

[0118] For example, the receiving core can determine whether the amount of service data received within the target time period is greater than the maximum capacity of the receiving buffer. If the amount of service data received within the target time period is greater than or equal to the maximum capacity of the receiving buffer, the receiving core determines that flow control is required; if the amount of service data received within the target time period is less than the maximum capacity of the receiving buffer, the receiving core determines that flow control is not required.

[0119] For another example, the receiving core can calculate its buffer utilization rate based on the amount of service data received within the target time period and the maximum capacity of the receiving buffer. Then, if the receiving core's buffer utilization rate is greater than or equal to its preset flow control threshold, the receiving core determines that flow control is required; if the receiving core's buffer utilization rate is less than its preset flow control threshold, the receiving core determines that flow control is not required.

[0120] S404. The receiving core sends a flow control message to the sending core. The flow control message is used to indicate the sending speed of service data.

[0121] In a possible implementation, the flow control message may include the reduction in the transmission rate of service data. The sending core can then reduce the transmission rate of service data based on this reduction. Afterward, the sending core can transmit the service data at the reduced transmission rate (hereinafter referred to as the second rate).

[0122] S405. The sending core adjusts the sending speed of the service data to the second speed according to the flow control message. The second speed is less than the first speed.

[0123] In a possible implementation, the data production rate in the sending core corresponds to the data transmission rate. The sending core can reduce the data transmission rate by decreasing the data production rate. When the data production rate decreases, the transmission rate also decreases accordingly. When the sending core transmits data at the reduced transmission rate, the data is delivered to the receiving core more slowly, thus alleviating congestion in the receiving core and reducing the time spent waiting for data consumption. Furthermore, a reduced data production rate means a smaller amount of data is produced per unit of time. This reduces the storage pressure on the sending core, further alleviating congestion.

[0124] S406. The sending core sends service data to the receiving core at a second speed.

[0125] S407. The receiving core stores the received service data in the receiving buffer, and the receiving core consumes the service data in the receiving buffer.

[0126] Below, in conjunction with Figure 5 illustrate Figure 4 The corresponding implementation examples demonstrate the flow control effects achieved.

[0127] like Figure 5 As shown, during flow control, electronic devices reduce the transmission rate of service data in the transmission core, thereby reducing channel traffic. After flow control is lifted, the transmission rate of service data in the transmission core increases, thereby increasing channel traffic.

[0128] based on Figure 5 It can be determined that during flow control periods, channel flow will decrease compared to non-flow control periods. Figure 3 The channel flow is zero during flow control, and the reduction in channel flow during flow control is smoother. In other words, the sending core can still successfully send data to the receiving core during flow control, thus improving performance. Figure 3 This addresses the issue of data loss due to communication channel closure during flow control. Furthermore, during flow control, the sending core transmits service data at a reduced speed, resulting in slower data delivery and thus alleviating congestion, thereby reducing the time service data waits to be consumed. This improves the reliability of data transmission.

[0129] It should be noted that, in the embodiments of this application, the transmission speed of business data can be understood as the speed at which business data is produced. In other words, adjusting the transmission speed of business data in the embodiments of this application can be understood as adjusting the speed at which business data is produced.

[0130] The above embodiments use the receiving core as an example to illustrate the flow control method in this application. In other embodiments, steps S401-S407 of the above flow control method can also be executed by the sending core. Specifically, when executed by the sending core, the steps are as follows:

[0131] S401-S402 can be replaced by: the sending core storing the service data in the sending core that is sent at the first speed in the sending buffer, and the sending core sending the service data in the sending buffer to the receiving core.

[0132] The send buffer is the memory area in the send core that stores the data to be sent.

[0133] It is understandable that the sending core can continuously store the service data to be sent into the sending buffer, and the sending core can continuously send the service data in the sending buffer to the receiving core.

[0134] S403-S404 can be replaced by: The sending core determines whether flow control is required based on the amount of service data sent from the sending buffer within the target time period and the maximum capacity of the sending buffer. The maximum capacity of the sending buffer is the maximum number of bytes that the sending buffer can store.

[0135] When the sending core determines that flow control is necessary, it indicates that the sending buffer is about to be filled with service data or has already been filled. Therefore, the sending core executes the step of sending flow control messages to services within the sending core to reduce the rate at which services send service data. In this way, the amount of service data sent to the sending buffer per unit time is reduced, thereby alleviating the situation where the sending buffer is about to be filled with service data or has already been filled.

[0136] If the sending core determines that flow control is not required, it means that the sending buffer has sufficient capacity to receive service data. The sending core then performs the steps of storing the service data and sending the stored service data.

[0137] S405 can be replaced by: The service in the sending core adjusts the sending speed of the service data to a second speed according to the flow control message, and the second speed is less than the first speed.

[0138] In a possible implementation, the data production rate and data transmission rate of the sending core are correlated. The sending core can reduce the data transmission rate by decreasing the data production rate. When the data production rate decreases, the data transmission rate also decreases accordingly. When the sending core transmits data at the reduced transmission rate, the data is delivered to the receiving core more slowly, thus alleviating congestion on the receiving core and reducing the time the data waits to be consumed.

[0139] S406 can be replaced by: the services in the sending core send service data to the sending buffer at a second speed.

[0140] S407 can be replaced by: the sending core storing the service data to be sent in the sending core in the sending buffer, and the sending core sending the service data in the sending buffer to the receiving core at the first speed.

[0141] For example, the electronic devices in this application embodiment may be wearable devices, mobile phones, tablets, desktops, laptops, handheld computers, laptops, ultra-mobile personal computers (UMPCs), augmented reality (AR) or virtual reality (VR) devices, etc., that have multi-core processors and are capable of cross-core communication. Wearable devices may include smartwatches, smart bracelets, smart glasses, smart helmets, etc., that can be worn on the user's body or integrated into clothing. This application embodiment does not impose any special limitations on the specific form of the electronic devices.

[0142] The following will take a mobile phone as an example to further describe the technical solution provided in the embodiments of this application. It should be understood that the embodiments of this application do not impose any limitations on the product form of the electronic device.

[0143] Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Figure 6As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0144] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0145] Processor 110 may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0146] In this embodiment, a processing unit may include one or more cores. The cores within a processing unit can be understood as the basic execution units of the processing unit. Different processing units may include different cores. For example, a processing unit such as a CPU may include one or more CPU cores, and a processing unit such as an NPU may include one or more NPU cores (also referred to as neural network cores or tensor cores, etc.). Different cores can be integrated onto the same chip, and this chip integrating multiple cores can be understood as a multi-core processor. For example, the CPU cores in a CPU, the GPU cores in a GPU, and the NPU cores in an NPU can be integrated onto the same chip to form a multi-core processor. Of course, different cores can also reside on different chips.

[0147] In this embodiment, the processor 110 may further include a sensor coprocessor and a communication coprocessor. The sensor coprocessor may include a sensor hub core. The sensor coprocessor can be used to manage sensor data collected by the sensor module 180. The communication coprocessor may include a BT core and a Wi-Fi core. In some embodiments, the communication coprocessor can be used to process signals transmitted by the mobile communication module 150 and / or the wireless communication module 160. In some embodiments, the communication coprocessor can also process signals transmitted by the mobile communication module 150 and / or the wireless communication module 160.

[0148] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0149] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0150] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0151] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0152] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0153] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0154] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other media files can be stored on the external memory card.

[0155] The internal memory 121 can be used to store computer executable program code, which includes instructions. The processor 110 executes various functions (APPs) and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, phone book, etc.). In addition, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. In this embodiment, the internal memory 121 may also include static random-access memory (SRAM) and pseudo-static random-access memory (PSRAM). Both SRAM and PSRAM can be used to store business data. The PSRAM may be integrated on the same chip with one or more cores. Cores integrated on the same chip can share the PSRAM on that chip.

[0156] It should be noted that the aforementioned Figure 6 The description and its contents are merely examples of one application carrier of the solution provided in the embodiments of this application. Figure 6 The composition of this component does not constitute a limitation on the solution described in the embodiments of this application. In other embodiments, the electronic device 100 may also have a greater... Figure 6 The diagram shows the number of components, either more or fewer.

[0157] exist Figure 6 The example shown illustrates the hardware composition of an electronic device 100. In some embodiments, the electronic device 100 may also utilize its various hardware components (such as...) Figure 6 The hardware components shown are used to run an operating system. This operating system can have different software layers, allowing different programs to run.

[0158] After introducing the core of the hardware structure of the electronic device, the communication architecture for inter-core communication provided in the embodiments of this application will be described below.

[0159] In this embodiment, different cores can communicate with each other via a communication channel. The two cores communicating between cores can be located in the same chip of the same electronic device, in different chips of the same electronic device, or in different electronic devices.

[0160] For example, in combination Figure 7 The communication architecture for inter-core communication provided in the embodiments of this application is illustrated by way of example. It is understood that the number of electronic devices, the types of electronic devices, the number of chips, the number of cores, the types of cores, and the location of the cores in this example do not constitute a limitation on the embodiments of this application.

[0161] like Figure 7 As shown, the first electronic device may include a first chip and a second chip. The first chip may include a CPU core, a BT core, and a sensor hub core. For example, the first electronic device may be a smartwatch, and the second electronic device may be a smartphone.

[0162] See also Figure 7 Different cores can communicate using different communication channels. For example, the CPU core and the sensor hub core in the first chip can communicate via communication channel 1 (referred to as channel 1 in the diagram); the CPU core and the BT core in the first chip can communicate via communication channel 2; and the BT core and the sensor hub core in the first chip can communicate via communication channel 3. The first chip and the second chip can also communicate. For instance, communication between the first chip and the second chip can specifically be communication between the cores in the first chip and the cores in the second chip. For example, the BT core in the first chip and the BT core in the second chip can communicate via communication channel 4. The cores in a smartwatch and a mobile phone can also communicate. For example, the BT core in the first chip of a smartwatch and the BT core in a smartphone can communicate via communication channel 5.

[0163] The maximum communication rate (also known as the maximum transmission rate) of the communication channel between two cores can be pre-calculated. This application does not specifically limit the calculation method for the maximum communication rate. For example, the maximum communication rate of the communication channel between two cores can be calculated by a hardware performance monitoring counter (PMC) based on the amount of data collected under full-load conditions of the communication channel. The PMC can be located in the chip where the core initiating the communication resides. Full-load conditions of the communication channel can be understood as the communication channel continuously transmitting data while the PMC is collecting data, and the communication channel is shared or contested by other entities.

[0164] The maximum communication rate of different communication channels can be different. For example, the maximum communication rate of communication channel 1 can be 1 megabit per second (Mbps); the maximum communication rate of communication channel 2 can be 1.2 Mbps; the maximum communication rate of communication channel 3 can be 1.1 Mbps; the maximum communication rate of communication channel 4 can be 0.9 Mbps; and the maximum communication rate of communication channel 5 can be 0.8 Mbps. This application does not limit the calculation method of the maximum communication rate of the communication channels.

[0165] The inter-core communication architecture in this application embodiment can include multiple cores, multiple communication channels, and different communication protocols corresponding to different communication channels. Any two cores among the multiple cores can trigger the other's flow control to start or stop, and any core acting as a sending core can also trigger its own flow control to start or stop. Therefore, compared with the dual-core architecture in related technologies where the main core unidirectionally controls the opening or closing of the communication channel, the inter-core communication architecture in this application embodiment is more suitable for flow control in complex inter-core communication scenarios involving multiple cores, multiple communication channels, and multiple communication protocols.

[0166] Inter-core communication between different cores can be implemented based on the software architecture of electronic devices. See below. Figure 8 The software architecture of electronic devices will be introduced.

[0167] Figure 8 This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application. The software system of the electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the application uses a layered architecture based on Android. TM Taking the system as an example, the software structure of the electronic device is illustrated.

[0168] In this embodiment, the software architecture of the electronic device may include the software architecture corresponding to each core of the electronic device. For example, the software architecture of the electronic device may include the software architecture corresponding to the CPU core, the software architecture corresponding to the BT core, and the software architecture corresponding to the sensor hub core, etc. The following description uses the software architecture corresponding to the CPU core as an example, but this example does not constitute a limitation on the embodiments of this application. The software architecture corresponding to other cores may include more or fewer modules.

[0169] like Figure 8 As shown, the software architecture corresponding to the CPU core in the software architecture of an electronic device is a layered architecture. A layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TMThe system is divided into four layers, from top to bottom: the application layer, the application framework (FWK) layer, the hardware abstraction layer (HAL) layer, and the kernel layer.

[0170] The application layer can include a series of application packages.

[0171] like Figure 8 As shown, the application package can include applications such as video, navigation, Bluetooth, WLAN, calling, music, and fitness and health. Each application can include multiple services.

[0172] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes a set of predefined functions.

[0173] In some embodiments, the application framework layer may include an inter-core communication module, a mailbox, and a mailbox buffer.

[0174] The inter-core communication module can be used to determine whether flow control is required. If flow control is required, it generates a data packet containing flow control messages. The inter-core communication module can also parse received data packets. If the parsed data packet contains flow control messages, it sends the flow control messages to the corresponding service.

[0175] Mailboxes can be used to send received business data to the hardware abstraction layer.

[0176] The mailbox buffer can be used to store business data received by the mailbox but not yet sent.

[0177] The Hardware Abstraction Layer (HAL) is an interface layer located between the application framework layer and the kernel layer, providing a virtual hardware platform for the operating system.

[0178] The hardware abstraction layer may include a memory pool (Mempool) and a serial communication interface (SIO) module.

[0179] The memory pool can include SRAM and pseudo-static random-access memory, PSRAM.

[0180] In this embodiment, the transmit buffer and receive buffer can be in SRAM. The transmit buffer and receive buffer can exist in the form of a buffer queue. For ease of description, the receive buffer will be referred to as the first buffer queue (or the first storage area). PSRAM can be used to store service data that cannot be stored in the first buffer queue during flow control.

[0181] The SIO module can support data transmission using multiple communication protocols. It is understood that the core software architecture included in the above-described electronic device software architecture is illustrative. In real-world scenarios, the number of core software architectures included in the software architecture of an electronic device can be more or less. This application does not limit the number of core software architectures included in the software architecture of the electronic device.

[0182] The kernel layer is the layer between hardware and software, and it can include a kernel cache queue and task scheduling. The kernel cache queue can be used to cache business data sent by the application layer. Task scheduling can be used to activate receiving threads, which can then copy business data from the kernel cache queue to the mailbox in the application framework layer.

[0183] The following is combined with Figure 8 This provides an example illustrating the workflow of electronic device software and hardware.

[0184] The service data sent from the sending core to the receiving core can be stored in the receiving core's memory pool. The receiving core's inter-core communication module can obtain the target data flow (i.e., the amount of service data received within the target duration, as mentioned earlier) from the memory pool in real time. Then, the receiving core's inter-core communication module can determine whether the target data flow exceeds the target capacity (i.e., the maximum capacity of the receive buffer, as mentioned earlier). If the target data flow exceeds the target capacity, the receiving core's inter-core communication module can send a flow control message to the receiving core's SIO module. Next, the receiving core's SIO module sends the flow control information to the sending core's SIO module. The flow control information can be sent in the form of data packets. After receiving the flow control information, the sending core's SIO module can forward the flow control information to the sending core's inter-core communication module. Then, the sending core's inter-core communication module can send the flow control information to the service sending service data. Afterward, the service can reduce the service data sending rate based on the flow control information.

[0185] Below, in conjunction with the above Figure 7 and the following Figure 9 The flow control method provided in the embodiments of this application will be described. The flow control method in the embodiments of this application can be applied to... Figure 6 The hardware structure shown is similar to Figure 8 The illustrated software architecture is integrated into the electronic device.

[0186] For example, taking electronic devices as an example Figure 7 Take, for example, a smartwatch. Figure 9 As shown, the method may include S901-S910.

[0187] S901, The sending core sends service data to the receiving core at the highest speed.

[0188] The first speed can be the transmission speed of the data from each individual service within the service that transmits service data, or it can be the sum of the transmission speeds of the data from multiple services within the service that transmits service data. For example, if services A and B in the sending core are transmitting service data, the first speed can be the transmission speed of the data from service A, the transmission speed of the data from service B, or the sum of the transmission speeds of the data from services A and B.

[0189] S902, the receiving core stores the received service data in the first buffer queue, and the receiving core consumes the service data in the first buffer queue.

[0190] In a possible implementation, the receiving core stores the received business data in the first buffer queue and consumes the business data in the first buffer queue based on the first-in-first-out principle.

[0191] S903, The receiving core obtains the target data traffic, which is the amount of business data received by the receiving core within the target time period.

[0192] The target time period is the period preceding the first moment. The first moment is the time from when the receiving core executes the process of acquiring the target data traffic. Alternatively, it can be understood as the time period starting from the difference between the first moment and the corresponding duration of the target time period (hereinafter referred to as the target duration for ease of description), and ending at the first moment. For example, if the first moment is 8:00:00, and the target duration is the difference between 8:00:00 and 7:59:50, the target time period can be the period from 7:59:50 to 8:00:00. In this case, the target data traffic is the data traffic received during the period from 7:59:50 to 8:00:00. For example, the unit of the target data traffic can be megabits or megabytes.

[0193] In a possible implementation, the receiving core can calculate the target duration based on the target maximum communication rate (also known as the second transmission rate) and the target capacity. The target maximum communication rate is the maximum communication rate of the communication channel between the receiving core and the transmitting core. For example, the target duration can be the ratio of the target capacity to the target maximum communication rate.

[0194] Since the target duration is the ratio of the target capacity to the target maximum communication rate, it can be understood as the shortest time required to fill the first buffer queue. In other words, the first buffer queue will not be full until at least the target duration has elapsed. Therefore, compared to determining whether flow control is needed based on the amount of business data corresponding to a duration longer than the target duration, the receiving core can more promptly determine whether flow control is needed based on the target data traffic corresponding to the target duration. This allows for earlier identification of situations requiring flow control, enabling the receiving core to trigger flow control in a timely manner and reducing data loss.

[0195] S904. The receiving core determines the target channel traffic (also known as the first transmission rate) based on the target data traffic. The target channel traffic is the amount of service data received by the receiving core per unit time within the target time period.

[0196] In a possible implementation, the receiving core can determine the target channel traffic as the ratio of the target data traffic to the target duration.

[0197] In this embodiment, the receiving core calculates the target channel traffic, enabling the subsequent receiving core to determine whether to initiate flow control based on the target channel traffic and the target maximum communication rate.

[0198] S905: The receiving core determines whether the target channel traffic exceeds the target maximum communication rate. If yes, proceed with S906 and subsequent steps; otherwise, proceed with S903 and subsequent steps.

[0199] In this implementation, the receiving core counts the amount of service data within the target time period. The target duration is calculated by the receiving core based on the target maximum communication rate and the target capacity. The target maximum communication rate is designed with optimal throughput in mind; therefore, it reflects the rate at which services in the receiving core consume service data from the first buffer queue. When filling the first buffer queue with this target maximum communication rate, the target duration is required to fill it. Therefore, if the target communication rate, determined by the target data flow and duration within the target time period, is less than the target maximum communication rate, it's equivalent to the rate at which service data enters the first buffer queue being less than the rate at which service data is consumed from the first buffer queue. In this case, the first buffer queue will not be filled, and flow control is not required. Conversely, if the target communication rate, determined by the target data flow and duration, is greater than the target maximum communication rate, it's equivalent to the rate at which service data enters the first buffer queue being greater than the rate at which service data is consumed from the first buffer queue. Over time, the first buffer queue is more likely to fill, thus requiring flow control.

[0200] Therefore, if the target channel traffic is greater than the target maximum communication rate, it means that the amount of service data to be consumed stored in the receiving core is about to exceed the target capacity or has already exceeded it, and flow control needs to be initiated. The receiving core executes S906 and subsequent steps.

[0201] If the target channel traffic is less than the target maximum communication rate, it means that the first buffer queue has enough capacity to store service data, and flow control does not need to be started. The receiving core executes S903 and subsequent steps.

[0202] Understandably, when the target channel traffic equals the target maximum communication rate, the receiving core can execute steps S903 and thereafter, or steps S906 and thereafter.

[0203] S906, The receiving core generates speed reduction information based on the target channel traffic and the target maximum communication rate. The speed reduction information indicates the extent of the reduction in the transmission speed of service data.

[0204] In a possible implementation, the receiving core can calculate the difference between the target channel traffic and the target maximum communication rate to obtain rate reduction information. For example, the rate reduction indicated by the rate reduction information is this difference; alternatively, the rate reduction indicated by the rate reduction information can also be greater than this difference. In other words, the target channel traffic calculated by the receiving core can not only be used to determine whether flow control should be initiated, but also to calculate the rate reduction indicated by the rate reduction information, so as to clearly instruct the sending core how to control the transmission rate of the service based on instructing the sending core to execute flow control.

[0205] The above implementation determines whether flow control needs to be initiated based on the target channel traffic and the target maximum communication rate. Optionally, the receiving core can also directly determine whether flow control needs to be initiated based on whether the target data traffic is greater than the target capacity. For example, if the target data traffic is greater than or equal to the target capacity, the receiving core determines that flow control needs to be initiated; if the target data traffic is less than the target capacity, the receiving core determines that flow control does not need to be initiated.

[0206] S907. The receiving core sends a flow control message to the sending core. The flow control message includes speed reduction information and a first identifier. The first identifier is used to indicate the target service for which the sending speed needs to be adjusted.

[0207] The first identifier may be the business name, business number, etc. of the target business, but this application embodiment does not specifically limit it.

[0208] The target service can be any one or more services among all services that have sent service data in the sending core, or it can be at least one service that has sent the most service data.

[0209] Taking the target business as at least one business with the largest data volume as an example, this application embodiment here exemplifies a specific method for determining the first identifier:

[0210] When acquiring target data traffic, the receiving core can count the amount of business data based on the second identifier and the third identifier respectively, and determine the second identifier of at least one business with the largest amount of business data as the first identifier.

[0211] In some embodiments, the service data may carry a second identifier and a third identifier. The third identifier indicates the core sending the service data, and the second identifier indicates the service sending the service data. This application does not specifically limit the form of the second and third identifiers. For example, the second identifier may be the service name and / or service number, etc. The third identifier may be the core name and / or number, etc. The above is merely an exemplary approach; in actual implementation, it does not limit the method of determining the first identifier. For example, the receiving core may also randomly select a service and determine the second identifier of the selected service as the first identifier.

[0212] The following section provides further details on the speed reduction information and the target services.

[0213] In some embodiments, the rate reduction indicated by the rate reduction information may be the sum of the rate reductions in the transmission speed of at least one target service's data.

[0214] For example, the rate reduction indication is 0.3 Mbps. Services A, B, and C in the sending core send service data to the receiving core. When acquiring the target data traffic, the receiving core calculates that the amount of service data carrying the second identifier A is 5 MB, the amount of service data carrying the second identifier B is 4 MB, and the amount of service data carrying the second identifier C is 0.08 MB. That is, the amounts of service data carrying the second identifier A and the second identifier B are both significantly larger than the amount of service data carrying the second identifier C. Therefore, the receiving core can determine the second identifier A and the second identifier B as the first identifier, i.e., services A and B are the target services. After receiving the flow control message, the sending core can reduce the transmission speed of services A and B, and the sum of the rate reductions for service A and B is 0.3 Mbps. Here, the service data carrying the second identifier A indicates that the service source of this data is service A. Similarly, business data carrying the second identifier B indicates that the business source of the business data is business B, and business data carrying the second identifier C indicates that the business source of the business data is business C.

[0215] In this embodiment, the reduction in the transmission speed of service data for each target service is less than the reduction indicated by the rate-down information. This has two advantages: First, it reduces the transmission speed of service data for the target services, resulting in a relatively lower rate at which the receiving core receives service data. Consequently, the buffer utilization rate in the receiving core increases more slowly or even decreases, allowing the receiving core to continuously and successfully receive service data, reducing data loss, and thus improving the reliability of data transmission in inter-core communication. Second, it minimizes the reduction in the transmission speed of service data for each target service, enabling them to transmit service data at a higher speed within the allowable range of the rate-down information, thereby reducing the impact of flow control on service data transmission.

[0216] In other embodiments, the rate reduction indicated by the rate reduction information may also be the rate reduction of the transmission speed of the service data of each service in at least one target service.

[0217] Referring to the example above, the difference is that the reduction in the data transmission speed of service A and service B is both 0.3 Mbps.

[0218] In this embodiment, the reduction in service data for each target service is the same as the reduction indicated by the rate-down information. This significantly reduces the overall transmission speed of the target service's service data, making it easier for the target service to achieve flow control with only one rate-down operation. This improves flow control sensitivity and conserves computing resources of the receiving core.

[0219] S908: The sending core adjusts the sending speed of the target service's business data to a second speed based on the speed reduction information. The second speed is less than the first speed.

[0220] In a possible implementation, upon receiving a flow control message, the sending core can reduce the transmission rate of the target service's data within the sending core based on the rate-reduction information. The sum of the rate reductions for the transmission rates of the service data of each target service can be greater than or equal to the rate reduction indicated by the rate-reduction information.

[0221] In this implementation, the sending core controls the reduction in the transmission rate of the target service's data, allowing it to minimize the target channel traffic with fewer adjustments. For example, if the sending core only reduces the transmission rate of each service's data once, the target channel traffic recalculated by the receiving core will already be less than the target maximum communication rate. This improves flow control efficiency, thereby reducing data latency and / or data loss during flow control, further enhancing data transmission reliability.

[0222] In the above implementation, the sending core adjusts the transmission speed of the service data for the target service, which is indicated by a first identifier. Alternatively, the sending core may not adjust the transmission speed of the service data for the target service, but instead adjust the transmission speed of the service data for any service within the sending core.

[0223] Therefore, optionally, the above S908 can be replaced by: the sending core adjusting the sending speed of any service data that has sent service data to a second speed, which is less than the first speed, according to the speed reduction information.

[0224] In the above embodiments, the deceleration information indicates the degree of reduction. However, in other embodiments, the deceleration information may also indicate a speed value. For example, the deceleration information may indicate a second speed.

[0225] S909, The transmitting core sends service data to the receiving core at a second speed.

[0226] S910 receives service data stored in the core and consumes service data stored in the core.

[0227] In some embodiments, after S907 described above, and after waiting for a second preset time, the receiving core can repeat S903 and its subsequent steps. This allows for the detection of the effectiveness of flow control after one instance of flow control, and further flow control if the effect is unsatisfactory.

[0228] In these embodiments, since a certain amount of time is consumed between the step of the receiving core sending the flow control message and the step of the sending core sending the service data at the second speed, after the receiving core sends the flow control message, the receiving core can wait for a second preset time before determining whether the target channel traffic is greater than the target maximum communication rate. This reduces the number of judgments made by the receiving core, thereby saving the computing resources of the sending core.

[0229] Furthermore, if the target channel traffic exceeds the target maximum communication rate, it indicates that the receiving core may still be filled up when the sending core transmits service data at the second speed. Therefore, the receiving core sends a flow control message to the sending core again, causing the sending core to further reduce the service data transmission rate from the second speed, thereby reducing service data loss. If the target channel traffic is less than the target maximum communication rate, it indicates that the receiving core will not be filled up when the sending core transmits service data at the second speed. Therefore, the receiving core can send a flow control release message to the sending core, causing the sending core to release the restriction on the service data transmission rate. For example, the sending core can restore the service data transmission rate to the transmission rate before the adjustment.

[0230] Among them, the flow control release message can instruct an increase in the sending speed of business data.

[0231] For example, the flow control release message may include the increase in the transmission speed of service data. The sending core can adjust the second speed to a third speed based on the flow control information. Then, the sending core can send service data to the receiving core at the third speed. The third speed is greater than the second speed, thereby improving inter-core communication efficiency within the receiving core's capacity.

[0232] In the above embodiments, when calculating the amount of service data received by the receiving core within a target time period, the receiving core determines the target channel traffic by summing the total amount of all service data within the target time period. In other words, the target data traffic takes into account the storage resource usage of all service data received by the receiving core within the target time period. Therefore, the target channel traffic calculated by the receiving core based on this target data traffic is more accurate, resulting in more accurate rate-reduction information determined by the receiving core based on this target channel traffic, thereby improving the accuracy of flow control based on this rate-reduction information.

[0233] In other embodiments, when the receiving core calculates the amount of service data received within a target time period, it may determine the target channel traffic by only considering the sum of the amounts of one or more service data items with the largest amounts of data, and then determine the target channel traffic based on this target channel traffic. In other words, when calculating the amount of service data received within a target time period, the receiving core may disregard service data items with smaller amounts of data, thereby saving the receiving core's computing resources and improving computing efficiency.

[0234] The above embodiment is illustrated using a communication scenario between one sending core and one receiving core. In other scenarios, multiple sending cores may be sending service data to the receiving core.

[0235] For ease of description, the following example uses multiple sending cores, including a first sending core and a second sending core, to illustrate the flow control process in this scenario. Figure 9The description in the corresponding embodiment is similar, except that the target data traffic is the sum of the amount of service data sent by the first sending core and the amount of service data sent by the second sending core within the target time period, received by the receiving core. The target duration can be the ratio of the target capacity to the total maximum communication rate. The total maximum communication rate is the sum of the first maximum communication rate and the second maximum communication rate. The first maximum communication rate is the maximum communication rate of the communication channel between the first sending core and the receiving core, and the second maximum communication rate is the maximum communication rate of the communication channel between the second sending core and the receiving core. The receiving core can determine whether the first sending core needs flow control based on the first channel traffic and the first maximum communication rate, and / or, the receiving core can determine whether the second sending core needs flow control based on the second channel traffic and the second maximum communication rate. The first channel traffic can be understood as the amount of service data sent by the first sending core received by the receiving core per unit time within the target time period; the second channel traffic can be understood as the amount of service data sent by the second sending core received by the receiving core per unit time within the target time period.

[0236] For example, if the first channel traffic exceeds the first maximum communication rate, it indicates that the receiving core is likely to be filled with service data; therefore, the receiving core determines that the first transmitting core needs to perform flow control. And / or, if the second channel traffic exceeds the second maximum communication rate, it indicates that the receiving core is likely to be filled with service data; therefore, the receiving core determines that the second transmitting core needs to perform flow control. If the first channel traffic is less than the first maximum communication rate and the second channel traffic is less than the second maximum communication rate, it indicates that the receiving core is not likely to be filled; therefore, the receiving core determines that the second transmitting core does not need to perform flow control.

[0237] The service data carries a third identifier, which is used to indicate the source processor core of the service data. If it is determined that the traffic of the first channel is greater than the first maximum communication rate, the receiving core can send a flow control message to the first sending core based on the third identifier in the service data corresponding to the traffic of the first channel; if it is determined that the traffic of the second channel is greater than the second maximum communication rate, the receiving core can send a flow control message to the second sending core based on the third identifier in the service data corresponding to the traffic of the second channel.

[0238] After the receiving core determines that the target channel traffic exceeds the target maximum communication rate, as described in S905 above, and before the sending core sends data to the receiving core at the second speed, as described in S909 above, the sending core continuously sends service data to the receiving core at a relatively high speed, such as the first speed. Therefore, during this time delay (e.g., the time between the receiving core executing S905 and the sending core executing S909 above), the service data sent by the sending core may have already filled the first buffer queue, making it impossible to receive more service data.

[0239] Based on this, in some embodiments, after the receiving core determines that the target channel traffic exceeds the target maximum communication rate, for example after S905 described above, the receiving core can request a second buffer queue in the PSRAM. Thus, when the receiving core receives service data after the first buffer queue is full, it can store the service data in the second buffer queue, thereby reducing the loss of service data. The service data received by the receiving core may include, for example, the service data transmitted by the sending core at a first speed from S901 to S909, and the service data transmitted by the sending core at a second speed starting from S909. Therefore, service data that cannot be stored in the first buffer queue can be stored in the second buffer queue, further reducing the risk of loss of service data transmitted from the sending core to the receiving core.

[0240] Furthermore, the priority of business data can be either first priority or second priority, with first priority being higher than second priority. After requesting the second cache queue, the receiving core can store business data according to its priority and prioritize consuming first-priority business data so that it is not delayed due to flow control.

[0241] It is understood that the prioritization of business data can be set according to the actual scenario, and this application embodiment does not specifically limit it. For example, first-priority business data may refer to business data that has a direct impact on business operations, decision-making, or user experience, requiring rapid processing, high availability, and strong consistency. Second-priority business data may refer to data that has a smaller impact on the business, can be processed with delayed latency, and requires lower computing resources. Below, in conjunction with... Figure 10 The process of how the receiving core stores and consumes business data is further explained.

[0242] For example, Figure 10 This is a schematic diagram illustrating a process for storing and consuming business data, provided as an embodiment of this application. Figure 10 As shown, after the receiving core determines that the target channel traffic is greater than or equal to the target maximum communication rate, when the receiving core receives service data, the process of storing and consuming the service data may include S1001-S1007.

[0243] S1001, The receiving core receives new service data. The new service data is the service data received by the receiving core after it determines that the target channel traffic is greater than the target maximum communication rate.

[0244] S1002, Receive the core to identify the length and priority of new service data.

[0245] S1003. The receiving core determines whether the length of the new service data is less than the free capacity (also known as the remaining capacity) of the first buffer queue of the receiving core. If yes, the receiving core performs the step of storing the service data into the first buffer queue according to the priority of the service data, as shown in S1004 below; if no, the receiving core performs the step of storing the service data into the second buffer queue according to the priority of the service data, as shown in S1005 below.

[0246] If the length of the new business data is less than the free capacity of the first cache queue, it means that the first cache queue has sufficient capacity to store the new business data. Therefore, S1004 can be executed. If the length of the new business data is greater than or equal to the free capacity of the first cache queue, it means that the first cache queue no longer has sufficient capacity to store the new business data. Therefore, S1005 can be executed.

[0247] S1003 determines the storage location of new service data by checking whether the length of the new service data is less than the free capacity of the first buffer queue of the receiving core. This implementation ensures that the first buffer queue does not overflow when new service data is stored.

[0248] It is understood that the above method for determining the storage location of new business data is only an exemplary method, and in actual implementation, it is not intended to limit the method for determining the storage location of new business data.

[0249] In one example, the receiving core can also determine the storage location of new service data based on the free capacity of the first cache queue. For instance, if the free capacity of the first cache queue is greater than or equal to a first preset threshold, the receiving core can store the new service data in the first cache queue. If the free capacity of the first cache queue is less than the first preset threshold, the receiving core can store the new service data in the second cache queue. In this way, the receiving core can dynamically determine the storage location of new service data based on the free capacity of the first cache queue, so that when there is still a large amount of free capacity in the first cache queue, the receiving core can store service data in the first cache queue as much as possible. Therefore, the second cache queue can be released as early as possible, thereby reducing memory contention and improving resource utilization.

[0250] In another example, the receiving core can also prioritize storing new service data in the second buffer queue. Only after the service data in the first buffer queue has been consumed will the receiving core store the received new service data into the first buffer queue. In other words, new service data will not be stored in the first buffer queue until the service data in the first buffer queue has been consumed, thus mitigating the situation where the first buffer queue is about to fill up or has already filled up as early as possible.

[0251] In another example, the receiving core can also prioritize storing new service data in a second buffer queue. After a third preset time, the receiving core begins storing the received new service data in the first buffer queue. This allows the first buffer queue a longer consumption time, thus alleviating the situation where the first buffer queue is about to fill up or has already filled up as early as possible.

[0252] S1004. The receiving core stores new service data into the first buffer queue according to priority.

[0253] In a possible implementation, if the priority of the new service data is first, the receiving core stores the new service data at the head of the first buffer queue; if the priority of the new service data is second, the receiving core stores the new service data at the tail of the first buffer queue.

[0254] It should be understood that business data at the head of the first cache queue is consumed first.

[0255] S1005. The receiving core stores new service data into the second buffer queue according to priority.

[0256] In a possible implementation, if the priority of the new service data is first, the receiving core stores the new service data at the head of the second buffer queue; if the priority of the new service data is second, the receiving core stores the new service data at the tail of the second buffer queue.

[0257] It should be understood that business data at the head of the second cache queue is consumed first.

[0258] S1006, Receive core consumes service data from the first and second cache queues.

[0259] In a possible implementation, the receiving core consumes the service data in the first and second buffer queues according to the priority and the time of receipt of the service data in the first and second buffer queues.

[0260] For example, if the service data at the head of either the first or second cache queue has a priority of first priority, the receiving core will prioritize consuming that service data. If the service data at the head of both the first and second cache queues has a priority of first priority, the receiving core can determine whether the entry time of the service data at the head of the first cache queue is earlier than the entry time of the service data at the head of the second cache queue. If the entry time of the service data at the head of the first cache queue is earlier than the entry time of the service data at the head of the second cache queue, the receiving core can prioritize processing the service data at the head of the first cache queue; if the entry time of the service data at the head of the first cache queue is later than the entry time of the service data at the head of the second cache queue, the receiving core can prioritize processing the service data at the head of the second cache queue.

[0261] S1007. After all the new service data in the second buffer queue has been consumed, the receiving core releases the second buffer queue.

[0262] Since new service data may also be stored in the first buffer queue for consumption, and during flow control, the sending core reduces the sending rate of service data, the amount of new service data in the second buffer queue gradually decreases. In a possible implementation, if the amount of service data stored in the second buffer queue is less than or equal to a preset value, the receiving core releases the second buffer queue, thereby avoiding waste of memory resources. For example, after all the service data in the second buffer queue has been consumed, the receiving core releases the second buffer queue.

[0263] In this embodiment of the application, for service data received by the receiving core after the receiving core determines that the target channel traffic is greater than or equal to the target maximum communication rate, the receiving core prioritizes the service data with the first priority, so that the service data with the first priority will not be delayed due to flow control, thereby further improving the reliability of data transmission.

[0264] The condition for releasing the second cache queue in S1007 above is only an exemplary condition. In actual implementation, it is not used to limit the conditions for releasing the second cache queue.

[0265] In one example, if the free capacity of the first cache queue is greater than a second preset threshold, the business data in the second cache queue can be sent to the first cache queue, and then the receiving core releases the second cache queue.

[0266] Furthermore, the second preset threshold can be greater than or equal to the capacity of the second cache queue. Therefore, even if the second cache queue is full, the first cache queue can still store all the business data from the second cache queue, thereby further reducing the loss of business data.

[0267] In another example, the second cache queue can also be released after a fourth preset time period following the request of the second cache queue.

[0268] In another example, the second cache queue can also be released after flow control is lifted, so that the second cache queue is available throughout the flow control period, thereby reducing the loss of business data during flow control.

[0269] Figure 9 The corresponding embodiment uses the receiving core as an example to illustrate the flow control method in this application. In other embodiments, S901-S907 of the above flow control method can also be executed by the sending core.

[0270] Specifically, when the flow control method in this application embodiment is executed by the sending core, the sending core can perform steps similar to those in S901-S907 described above. The difference is that the executing entity of the above steps is the sending core; the first buffer queue can be the sending buffer of the sending core; the target data flow is the amount of service data sent by the service in the sending core within the target time period; the target channel flow is the amount of service data sent by the service in the sending core per unit time within the target time period; and the target duration can be the ratio of the maximum capacity of the sending buffer to the target maximum communication rate.

[0271] In this embodiment, the target channel traffic can be understood as an assessment of the amount of service data sent to the sending buffer per unit time within a target time period. Therefore, when the target channel traffic exceeds the target maximum communication rate, it indicates that the service's data transmission speed to the sending buffer is greater than the transmission speed of service data from the sending buffer to the receiving core via the communication channel. Consequently, the sending buffer tends to fill up with the service data transmitted by this service. Subsequently, the sending core can send flow control messages to services within the sending core to reduce the service's data transmission speed to the sending buffer, ensuring that the transmission speed is less than the transmission speed of service data from the sending buffer to the receiving core via the communication channel. This alleviates the tendency for the sending buffer to fill up, thereby reducing the waiting time of service data in the sending buffer and mitigating data loss caused by the sending buffer potentially filling up during flow control. Since the sending core or receiving core does not need to frequently open or close the communication channel, the stability of data transmission is also improved.

[0272] Furthermore, Figure 10The corresponding embodiment uses the receiving core as an example to illustrate the storage process of service data in the embodiments of this application. In some other embodiments, the above steps S1001-S1007 can also be executed by the sending core to improve the situation of data delay and / or data loss caused by flow control in the sending core. The difference is that the first buffer queue can be the sending buffer area of ​​the sending core, and the second buffer queue is requested by the sending core in PSRAM after determining that the target channel traffic is greater than the target maximum communication rate. In this way, when the sending core receives service data after the first buffer queue is full, the sending core can store the service data in the second buffer queue, thereby reducing the loss of service data.

[0273] To more clearly describe the technical solutions provided in the embodiments of this application, please refer to Figure 11 For example, Figure 11 This is a flowchart illustrating another flow control method provided in an embodiment of this application. Figure 11 As shown, the method may include S1101-S1130.

[0274] S1101, The service in the sending core sends the service data to the kernel cache queue in the kernel layer of the sending core at the first speed.

[0275] S1102, The kernel cache queue in the sending core transmits business data to the mailbox in the application framework layer at the fastest speed.

[0276] In a possible implementation, when the kernel cache queue in the sending core receives business data, it can trigger the task scheduling module in the kernel layer of the sending core to activate the receiving thread. Then, the receiving thread can copy the business data from the kernel cache queue to the mailbox in the application framework layer.

[0277] S1103, the mailbox in the sending core transmits service data to the serial communication module in the receiving core via the inter-core communication module of the sending core and the serial communication interface module of the sending core.

[0278] S1104. The serial communication module in the receiving core transmits service data to the inter-core communication module in the application framework layer of the receiving core.

[0279] S1105, The inter-core communication module in the receiving core transmits the service data to the first buffer queue of the receiving core.

[0280] S1106, the first buffer queue of the receiving core stores service data.

[0281] S1107: Receive service data from the first buffer queue of the service consumption function in the core.

[0282] In a possible implementation, services in the receiving core can consume service data from the first cache queue through active polling.

[0283] Following S1104 above, the inter-core communication module in the receiving core can also execute S1108-S1110 to determine whether flow control should be performed.

[0284] S1108, The inter-core communication module in the receiving core obtains the target data traffic, which is the amount of service data received by the receiving core within the target time period.

[0285] In a possible implementation, the inter-core communication module in the receiving core can record information such as the second identifier, third identifier, length, priority, and target timestamp of the received and transmitted service data. At the first moment, the inter-core communication module in the receiving core can obtain the target data traffic based on the second identifier, third identifier, and target timestamp of the service data. The target timestamp of the service data can be the timestamp at which the inter-core communication module in the receiving core receives the service data.

[0286] S1109. The inter-core communication module in the receiving core determines the target channel traffic based on the target data traffic. The target channel traffic is the amount of service data received by the receiving core per unit time within the target time period.

[0287] S1110: The inter-core communication module in the receiving core determines whether the target channel traffic is greater than the target maximum communication rate. If not, the receiving core performs the step of determining whether flow control information has been sent, as described in S1111 below; if so, the receiving core performs the step of generating rate reduction information, as described in S1112 below.

[0288] If the target channel traffic is less than the target maximum communication rate, it means that the first buffer queue has enough capacity to store service data and flow control does not need to be started. The receiving core executes S1111. If the target channel traffic is greater than the target maximum communication rate, it means that the amount of service data to be consumed stored in the receiving core is about to exceed the target capacity or has already exceeded it. Flow control needs to be started and the receiving core executes S1112.

[0289] S1108-S1110 can be found in S903-S905 above, and will not be repeated here.

[0290] S1111: The inter-core communication module in the receiving core determines whether a flow control message has been sent. If yes, proceed to S1126 and subsequent steps; otherwise, proceed to S1108 and subsequent steps.

[0291] This application embodiment does not limit the method by which the receiving core determines whether a flow control message has been sent. For example, the receiving core may include a first flag bit, which corresponds to a first state or a second state. The first state may indicate that the receiving core has sent a flow control message, and the second state may indicate that the receiving core has not sent a flow control message. The receiving core can determine whether it has sent a flow control message based on the state corresponding to the first flag bit. After the inter-core communication module in the receiving core executes the step of sending a flow control message, for example, after S1113, the inter-core communication module in the receiving core may set the first flag bit, making it correspond to the first state; after the step of generating a flow control release message, for example, after S1127, the inter-core communication module in the receiving core may reset the first flag bit, making it correspond to the second state.

[0292] Since S1111 is executed by the receiving core when the target channel traffic is less than the target maximum communication rate, if the receiving core determines that a flow control message has been sent, it means that the first buffer queue of the receiving core is no longer at risk of being filled, and the receiving core can execute S1126 below to release flow control; if the receiving core determines that no flow control message has been sent, it means that the first buffer queue of the receiving core is no longer at risk of being filled, and the receiving core can re-determine whether flow control is needed. Therefore, the receiving core can execute S1108 above.

[0293] It is understandable that the receiving core can continuously receive service data. Therefore, the target data traffic value obtained by the receiving core after S1111 is different from the target data traffic value in S1108.

[0294] S1112. The inter-core communication module in the receiving core generates speed reduction information based on the target channel traffic and the target maximum communication rate. The speed reduction information indicates the extent of the reduction in the transmission speed of service data.

[0295] S1113. The inter-core communication module in the receiving core sends the flow control information to the serial communication interface module in the hardware abstraction layer of the sending core. The flow control information includes speed reduction information and a first identifier. The first identifier is used to indicate the service that needs to adjust the transmission speed.

[0296] S1112-S1113 are similar to or the same as S906-S907 mentioned above, and will not be described again here.

[0297] S1114. The serial communication interface module in the receiving core sends flow control information to the service in the sending core via the serial communication interface module of the sending core and the inter-core communication interface module of the sending core.

[0298] S1115. The target service indicated by the first identifier in the transmission core is adjusted to a second speed according to the speed reduction information. The second speed is less than the first speed.

[0299] S1116. The target service indicated by the first identifier in the sending core sends the service data to the kernel cache queue in the sending core at a second speed.

[0300] The receiving core and the transmitting core perform a process similar to S1102-S1104 above, the difference being that the service data is transmitted at the second speed.

[0301] If the receiving core determines that the target channel traffic is greater than the target maximum communication rate, it indicates that the first buffer queue is at risk of being filled or has already been filled. Therefore, after S1110, the receiving core can also execute S1117 so that the service data received by the receiving core can be stored in the second buffer queue, thereby reducing data loss.

[0302] S1117, The inter-core communication module of the receiving core requests a second buffer queue.

[0303] In a possible implementation, the inter-core communication module of the receiving core can send a cache request instruction to the PSRAM, and the PSRAM can determine the second cache queue based on the cache request instruction.

[0304] S1118. The inter-core communication module in the receiving core determines whether the length of the service data is less than the free capacity of the first buffer queue in the receiving core.

[0305] In a possible implementation, the first buffer queue in the receiving core can send capacity information to the inter-core communication module in the receiving core in real time. The capacity information is used to indicate the free capacity of the first buffer queue in the receiving core.

[0306] If the length of the business data is less than the free capacity of the first cache queue, it means that the first cache queue has sufficient capacity to store the new business data. Therefore, S1119 can be executed; if the length of the business data is greater than or equal to the free capacity of the first cache queue, it means that the first cache queue no longer has sufficient capacity to store the new business data. Therefore, S1120 can be executed.

[0307] S1119. The first buffer queue in the receiving core stores business data according to the priority of the business data.

[0308] S1120, The second buffer queue in the receiving core stores service data according to the priority of the service data.

[0309] S1121, Receive service data from the first and second cache queues in the service consumption core.

[0310] S1119-S1121 can be found in S1004-S1006 above, and will not be repeated here.

[0311] The sending core reduces the transmission rate of the target service's data; therefore, as the service data in the second buffer queue is consumed, the amount of service data in the second buffer queue gradually decreases. The inter-core communication module in the receiving core can release the second buffer queue to avoid wasting memory resources. Therefore, after S1121 described above, the method may further include S1122-S1125.

[0312] S1122: The second buffer queue in the receiving core sends a release message to the inter-core communication module, indicating the free capacity of the second buffer queue.

[0313] For example, the second cache queue can periodically send release information to the receiving core, or it can send release information to the receiving core in real time. Alternatively, the second cache queue can also send release information to the receiving core when the second cache queue is empty. This application embodiment does not specifically limit this.

[0314] S1123. When the release information indicates that the second buffer queue is empty, the inter-core communication module of the receiving core generates a release instruction based on the release information. The release instruction is used to indicate the release of the second buffer queue.

[0315] S1124. The inter-core communication module of the receiving core sends the release instruction to the second buffer queue.

[0316] S1125 and PRSAM release the second buffer queue based on the release instruction.

[0317] After the inter-core communication module of the receiving core sends the flow control information, the sending core executes the flow control. The receiving core can wait for a period of time before determining whether the flow control is complete. This allows for reserved execution time for flow control and also saves computing resources for the receiving core. Therefore, after S1113, the receiving core can also execute S1126.

[0318] S1126. After sending the flow control message, the inter-core communication module of the receiving core waits for a period of time, and then the inter-core communication module of the receiving core executes S1108.

[0319] The waiting time for the inter-core communication module of the receiving core can be set according to the actual scenario, and this application embodiment does not make specific limitations on it.

[0320] S1127, Receive the flow control release message generated by the inter-core communication module in the core.

[0321] S1128, The inter-core communication module in the receiving core sends the flow control release message to the serial communication interface module in the receiving core.

[0322] S1129. The serial communication interface module in the receiving core sends the flow control release message to the service in the sending core via the serial communication interface module in the initiating core and the inter-core communication module in the sending core.

[0323] S1130, Release flow control for services in the sending core.

[0324] This application also provides a chip system. Figure 12 This is a schematic diagram of a chip system provided in an embodiment of this application. The chip system can be a System-on-a-Chip (SoC) chip or a collection of multiple chips. In this embodiment, the transmitting core and receiving core can be located on the same chip or on different chips within the chip system. Figure 12 As shown, the chip system 1200 includes at least one processor 1201 and at least one interface circuit 1202. The processor 1201 and the interface circuit 1202 are interconnected via lines. For example, the interface circuit 1202 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 1202 can be used to send signals to other devices (e.g., the processor 1201). Exemplarily, the interface circuit 1202 can read instructions stored in memory and send those instructions to the processor 1201. When the instructions are executed by the processor 1201, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0325] This application also provides a computer-readable storage medium storing computer program code. When the processor executes the computer program code, the electronic device executes the relevant method steps in the above method embodiments.

[0326] This application also provides a computer program product that, when run on a computer, causes the computer to execute the relevant method steps described in the above method embodiments.

[0327] The electronic devices, computer-readable storage media, or computer program products provided in this application are all used to perform the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0328] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0329] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0330] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0331] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0332] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to it, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0333] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A flow control method, characterized in that, Applied to a first processor core, the method includes: Receive service data sent by a second processor core at a first speed, wherein the second processor core is different from the first processor core; Whether to perform flow control is determined based on the amount of business data received within the first time period; Upon detecting that flow control needs to be performed, a flow control message is sent to the second processor core, the flow control message indicating the transmission rate of the service data; The second processor core receives service data sent at a second speed, which is determined by the second processor core based on the flow control message, and the second speed is less than the first speed.

2. The method according to claim 1, characterized in that, The step of detecting whether to perform flow control based on the amount of business data received within the first time period includes: Calculate the first ratio of the data volume to the first time period to obtain the first transmission rate, and detect whether the first transmission rate is greater than the second transmission rate, wherein the second transmission rate is the maximum transmission rate between the first processor core and the second processor core. If the first transmission rate is greater than the second transmission rate, then flow control must be performed; if the first transmission rate is less than the second transmission rate, then flow control does not need to be performed.

3. The method according to claim 2, characterized in that, Before determining whether to perform flow control based on the amount of service data received within the first time period, the method further includes: The first time period is determined based on a second ratio of the maximum capacity of the first storage region and the second transmission rate. The first storage area is the storage area in the first processor core used to store the business data.

4. The method according to claim 2 or 3, characterized in that, Before sending the flow control message to the second processor core, the method further includes: Calculate the difference between the first transmission rate and the second transmission rate, and generate the flow control message. The flow control message includes the reduction in transmission speed, and the reduction is greater than or equal to the difference. The second speed is obtained by subtracting the reduction from the first speed by the second processor core.

5. The method according to any one of claims 1-4, characterized in that, The flow control message includes a first identifier, which indicates the target service; The receiving of service data transmitted by the second processor core at a second speed includes: The second processor core receives service data of the target service sent at the second speed, wherein the target service is determined by the second processor core based on the first identifier.

6. The method according to claim 5, characterized in that, The business data includes a second identifier, which indicates the source business of the business data. Before sending the flow control message to the second processor core, the method further includes: Based on the second identifier in the business data received within the first time period, the data volume of each source business is counted. Among them, the first identifier indicates the first number of source services with the largest amount of data.

7. The method according to any one of claims 1-6, characterized in that, After receiving the service data transmitted by the second processor core at the second speed, the method further includes: Send a flow control release message to the second processor core, the flow control release message instructing the first processor core to release flow control, the flow control release message including a third speed, the third speed being greater than the second speed; Receive service data sent by the second processor core at the third speed.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Before detecting that flow control needs to be performed, the received service data is stored in a first storage area, which is the storage area in the first processor core used to store the service data; After detecting that flow control needs to be performed, the received service data is stored in a second storage area, which is a shared storage area of ​​one or more processor cores in the chip where the first processor core is located.

9. The method according to claim 8, characterized in that, The step of storing the received service data in the second storage area after detecting that flow control needs to be performed includes: After detecting that flow control needs to be performed, the received business data is stored in the corresponding location in the second storage area based on priority.

10. The method according to claim 8 or 9, characterized in that, The step of storing the received service data in the second storage area after detecting that flow control needs to be performed includes: After detecting that flow control needs to be performed, if the length of the received service data is greater than the remaining capacity of the first storage area, the received service data will be stored in the second storage area. The method further includes: after detecting that flow control needs to be performed, storing the received service data in the first storage area if the length of the received service data is less than the remaining capacity of the first storage area.

11. The method according to any one of claims 8-10, characterized in that, After storing the received business data in the second storage area, the method further includes: Consume business data in the first storage area and business data in the second storage area; The method further includes: If the amount of business data stored in the second storage area is less than a preset value, the second storage area will be released.

12. A flow control method, characterized in that, Applied to a second processor core, the method includes: The service data is sent to the first processor core at a first speed, and the second processor core is different from the first processor core. Receive a flow control message sent by the first processor core, the flow control message indicating the transmission speed of the service data; The second speed at which the second processor core sends service data is determined based on the flow control message; Service data is sent to the first processor core at the second speed.

13. The method according to claim 12, characterized in that, The flow control message includes a first identifier, which indicates the target service; Determining the second speed at which the second processor core sends service data based on the flow control message includes: Based on the flow control message, the sending speed of the service data of the target service is determined as the second speed; Sending service data to the first processor core at the second speed includes: The service data of the target service is sent to the first processor core at the second speed.

14. The method according to claim 13, characterized in that, The first identifier indicates the first number of source services with the largest amount of data.

15. The method according to any one of claims 12-14, characterized in that, After sending service data to the first processor core at the second speed, the method further includes: Receive a flow control release message sent by the first processor core; the flow control release message instructs the first processor core to release flow control, and the flow control release message includes a third speed, the third speed being greater than the second speed; Service data is sent to the first processor core at the third speed.

16. An electronic device, characterized in that, The electronic device includes a processor and a memory; the processor is coupled to the memory; the processor includes a first processor core and a second processor core; the memory is used to store computer program code; the computer program code includes computer instructions, which, when executed by the processor, cause the electronic device to perform the method as described in any one of claims 1-15.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-15.

18. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-15.

19. A computer program product, characterized in that, The computer program product includes instructions that, when the computer program product is run on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-15.

Images