A password heterogeneous computing dynamic scheduling method based on execution path benefit evaluation

Abstract

The present application relates to the technical field of password heterogeneous computing resource scheduling, and specifically discloses a password heterogeneous computing dynamic scheduling method based on execution path benefit evaluation, which comprises the following steps: in response to a password computing task request, extracting task characteristic information and collecting heterogeneous computing environment running state information; if a system precondition determination condition is met, determining a software path as a target path; otherwise, matching a static scheduling rule; if no matching is found, respectively predicting expected processing time of the software path and a hardware path, calculating energy efficiency factors and resource costs, and comprehensively evaluating expected benefits of the two paths; comparing the benefit difference, and when the difference is less than a threshold, determining the target path through a probabilistic selection mechanism, otherwise, taking the path with greater benefit as the target path; and routing the task to the target path for execution. Through the establishment of an execution path-oriented dynamic benefit evaluation model, the present application realizes adaptive optimal scheduling of password computing tasks between a CPU software path and a CCP hardware path.

Description

Technical Field

[0001] This invention relates to the field of cryptographic heterogeneous computing resource scheduling technology, specifically to a dynamic scheduling method for cryptographic heterogeneous computing based on execution path benefit evaluation. Background Technology

[0002] With the continuous increase in network communication bandwidth and the growing demand for data security, cryptographic computation tasks have become a significant computational load in network devices, servers, and security infrastructure. To improve cryptographic computation performance, existing technologies mainly employ a heterogeneous computing model that combines general-purpose processor software computation with dedicated cryptographic hardware acceleration.

[0003] Currently, cryptographic computation acceleration solutions mainly fall into two categories: one is a standalone cryptographic acceleration solution, which provides hardware computing capabilities through a standalone cryptographic device or cryptographic card, and the scheduling module allocates cryptographic tasks to different cryptographic resources for execution based on task type and device load; the other is an on-chip integrated cryptographic coprocessor solution (such as the CCP built into Hygon CPU), which calls hardware acceleration capabilities through a driver or cryptographic framework interface. This solution reduces data interaction overhead compared to standalone cryptographic devices.

[0004] In terms of cryptographic task scheduling, existing technologies mainly include the following types: (1) Scheduling methods based on hardware queue management. For example, Chinese patent application CN121278748A allocates a software cache queue when the cryptographic coprocessor driver is loaded, writes the encryption tasks to the tail of the software cache queue in sequence, and then extracts the tasks from the software cache queue to enter the hardware queue for processing. This type of method mainly solves the packet loss problem caused by insufficient hardware queue capacity, but its essence is a static queue management mechanism. It does not have the ability to dynamically select the execution path according to the data block size and system load status, and cannot identify the problem that hardware acceleration causes performance degradation due to fixed overhead in small data block scenarios.

[0005] (2) Scheduling methods based on computing power weights. For example, Chinese patent application CN117130789A initializes the CPU cores and heterogeneous cryptographic hardware acceleration modules involved in cryptographic operations, calculates the computing power weight of each unit, and determines the target cryptographic operation unit based on the load calculation results. The computing power weights of this type of method are pre-calculated fixed values, which cannot reflect the dynamic changes in the performance of the execution path during runtime. When the system load changes or the hardware queue is congested, the static weights may lead to the selection of the wrong execution path.

[0006] In summary, existing technologies generally suffer from the following shortcomings: First, they lack a dynamic benefit evaluation mechanism for different execution paths (CPU software path and CCP hardware path) for the same cryptographic task, and cannot dynamically determine the current optimal execution path based on the operating environment; second, scheduling methods based on fixed rules or static weights have insufficient adaptability and cannot respond to dynamic changes in system load and business traffic; third, scheduling decisions usually only focus on a single factor and do not comprehensively consider the combined impact of multiple factors such as data scale, algorithm characteristics, hardware busyness, and CPU utilization on execution efficiency, resulting in insufficient scheduling accuracy. Summary of the Invention

[0007] To address the above problems, this invention proposes a dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation. The specific technical solution is as follows: A dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation includes the following steps: S1. Respond to the cryptographic computation task request, extract task feature information, and collect the current heterogeneous computing environment's running status information.

[0008] S2. If the running status information meets any of the following system pre-judgment conditions, then the software path is determined as the target path and the process proceeds to S6; otherwise, proceed to S3. The system pre-judgment conditions include: The CCP hardware queue depth exceeds the preset overload threshold.

[0009] The historical latency of the hardware path exceeds the preset latency threshold.

[0010] CPU core utilization is lower than the preset low level.

[0011] S3. Determine whether the task characteristic information matches the pre-configured static scheduling rule. If yes, determine the path specified by the rule as the target path and proceed to S6; otherwise, proceed to S4.

[0012] S4. Based on task characteristic information and running status information, predict the expected processing time of the software path and hardware path respectively to calculate the processing speed of the two paths, and calculate the energy efficiency factor and resource cost of the two paths, and comprehensively evaluate the expected benefits of the two paths accordingly.

[0013] S5. Compare the expected returns of the two paths and calculate the return difference. If the return difference is less than the preset return difference threshold, the target path is determined through a probabilistic selection mechanism; otherwise, the path with the larger expected return is selected as the target path.

[0014] S6. Route the cryptographic calculation task to the target path for execution.

[0015] Based on the above embodiments, step S1 includes: In response to a received cryptographic computation task request, the task descriptor of the cryptographic computation task is parsed, and task feature information is extracted. The task feature information includes cryptographic algorithm type, algorithm working mode, length of data to be processed, key length, and parallelizability of the task.

[0016] Collect the current operating status information of the heterogeneous computing environment. The operating status information includes CCP hardware queue depth, CCP hardware engine utilization, CCP hardware busy status, hardware path historical latency, CCP dynamic power consumption, CPU core utilization, and CPU dynamic power consumption.

[0017] Based on the above embodiments, the method for pre-configuring static scheduling rules includes: Select one or more task features from the task feature information as flag task features, and assign corresponding execution paths to the flag task features. Based on the mapping relationship between the flag task features and the execution paths, establish static scheduling rules.

[0018] Based on the above embodiments, the method for calculating the processing speed of the software path includes: Extract the baseline value of the unit data processing time for the current cryptographic algorithm type on the software path from the database, and multiply it by the length of the current data to be processed to obtain the baseline processing time for the software path.

[0019] Compare the length of the data to be processed with the current CPU cache space, calculate the ratio of the overflow amount of the data to be processed exceeding the CPU cache space to the total CPU cache capacity, and use this as the data overflow ratio. Based on the preset mapping relationship between the data overflow ratio and the data size influence factor, determine the data size influence factor of the software path.

[0020] Calculate the ratio between the current CPU core utilization rate and the preset CPU core utilization rate threshold as the relative proportion of CPU core utilization rate. Based on the mapping relationship between the preset relative proportion of CPU core utilization rate and the CPU load impact factor, determine the CPU load impact factor of the software path.

[0021] The expected processing time of the software path is obtained by multiplying the baseline processing time, the data size impact factor, and the CPU load impact factor.

[0022] The ratio of the length of the data to be processed to the expected processing time is calculated as the processing speed of the software path.

[0023] Based on the above embodiments, the method for calculating the processing speed of the hardware path includes: Calculate the baseline processing time of the hardware path based on the baseline value of the unit data processing time for the current cryptographic algorithm type and the length of the data to be processed.

[0024] The current CCP hardware queue depth and the historical latency of the hardware path are compared with their corresponding preset thresholds to obtain the queue depth ratio and the historical latency ratio. Based on the preset mapping relationship between the queue depth ratio and the queue depth influence factor, and the mapping relationship between the historical latency ratio and the historical latency penalty factor, the queue depth influence factor and the historical latency penalty factor of the hardware path are determined.

[0025] Based on the current busy status of the CCP hardware, and combined with the preset busy status influence factors corresponding to different CCP hardware busy statuses, the busy status influence factor of the hardware path is matched to obtain the busy status influence factor.

[0026] Multiply the baseline processing time of the hardware path, the queue depth impact factor, the historical latency penalty factor, and the busy state impact factor, and add the resulting product to the fixed commit cost of the hardware path to obtain the expected processing time of the hardware path.

[0027] The ratio of the length of the data to be processed to the expected processing time of the hardware path is calculated as the processing speed of the hardware path.

[0028] Based on the above embodiments, the method for calculating the software path energy efficiency factor and the hardware path energy efficiency factor includes: Calculate the product of the current CPU dynamic power consumption and the expected processing time of the software path, then calculate the ratio of the length of the data to be processed to the product, and use the resulting ratio as the energy efficiency factor of the software path.

[0029] Similarly, calculate the product of the current CCP dynamic power consumption and the expected processing time of the hardware path, then calculate the ratio of the length of the data to be processed to the product, and use the resulting ratio as the energy efficiency factor of the hardware path.

[0030] Based on the above embodiments, the method for calculating the resource cost of a software path includes: Obtain the overall average CPU utilization of the system and calculate the ratio of the overall average CPU utilization of the system to the preset safe CPU utilization threshold.

[0031] If the ratio is less than or equal to 1, then the CPU resource scarcity penalty coefficient is set to 1.

[0032] If the ratio is greater than 1, the ratio is multiplied by a preset scarcity sensitivity coefficient, and the resulting product is used as the CPU resource scarcity penalty coefficient; wherein, the scarcity sensitivity coefficient is a constant greater than 1.

[0033] Obtain the current CPU core utilization rate, calculate the product of the current CPU core utilization rate and the CPU resource scarcity penalty coefficient, and use the resulting product as the resource cost of the software path.

[0034] Based on the above embodiments, the method for calculating the resource cost of the hardware path includes: The ratio of the task arrival rate to the maximum service rate of the hardware is used as the hardware system utilization intensity.

[0035] If the hardware system utilization intensity is less than 1, then calculate the difference between 1 and the hardware system utilization intensity, and use the reciprocal of the difference as the hardware resource scarcity penalty coefficient.

[0036] If the utilization intensity of the hardware system is greater than or equal to 1, then the hardware resource scarcity penalty coefficient is set to a preset upper limit protection value.

[0037] Calculate the ratio of the current CCP hardware queue depth to the maximum capacity of the hardware queue, and multiply this ratio by the hardware resource scarcity penalty coefficient to obtain the product value.

[0038] The product value is compared with a preset upper limit for resource costs, and the smaller of the two values ​​is taken as the resource cost of the hardware path.

[0039] Based on the above embodiments, a method for comprehensively evaluating the expected returns of the two paths includes: The processing speed, energy efficiency factor, and resource cost of the software path and hardware path are normalized respectively to obtain the normalized processing speed, normalized energy efficiency factor, and normalized resource cost for each path.

[0040] Based on the preset fusion weights corresponding to processing speed, energy efficiency factor, and resource cost, the normalized processing speed of each path is multiplied by its corresponding processing speed weight, the normalized energy efficiency factor is multiplied by its corresponding energy efficiency factor weight, and the normalized resource cost is multiplied by its corresponding resource cost weight. The sum of these three results is taken as the expected return of that path.

[0041] Based on the above embodiments, step S5 includes: Calculate the absolute value of the difference between the expected revenue of the software path and the expected revenue of the hardware path, and calculate the average of the expected revenues of the two paths.

[0042] If the average value is less than a preset minimum positive threshold, the profit difference is set to zero; otherwise, the absolute value of the difference is divided by the average value, and the resulting ratio is taken as the profit difference.

[0043] The difference in returns is compared with a preset threshold for the difference in returns.

[0044] If the profit difference is less than the profit difference threshold, the target path is determined through a probabilistic selection mechanism.

[0045] If the difference in returns is greater than or equal to the threshold for difference in returns, then the path corresponding to the one with the greater expected return is determined as the target path.

[0046] Compared with existing technologies, the dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation described in this invention has the following advantages: 1. This invention improves system response speed by setting pre-judgment conditions at the front end of the scheduling decision process, switching to the software path in a timely manner when the hardware path is overloaded or its performance deteriorates, ensuring service quality, prioritizing the use of the software path when CPU resources are sufficient to reduce hardware access and evaluation overhead, and shortening the decision path length under extreme conditions through a fast filtering mechanism.

[0047] 2. This invention sets up a static scheduling rule matching layer before dynamic benefit evaluation, enabling tasks with deterministic path preferences to be scheduled directly without performing complex evaluations, thus reducing decision-making overhead. At the same time, it supports operations and maintenance personnel to customize and adjust rules according to actual needs, enhancing the interventionability and interpretability of scheduling strategies, and enabling the dynamic evaluation engine to centrally process complex tasks, thereby improving overall scheduling efficiency.

[0048] 3. Compared with the static capability assessment of different hardware devices in the prior art, the present invention establishes a unified dynamic benefit evaluation model for multiple executable paths (CPU software path and CCP hardware path) of the same cryptographic task. It comprehensively considers three dimensions: processing speed, energy efficiency factor and resource cost, and realizes accurate quantification of the actual benefit of the execution path, thus overcoming the deficiency of the lack of dynamic evaluation mechanism for execution paths in the prior art.

[0049] 4. This invention makes dynamic decisions based on real-time calculated path revenue values, without relying on pre-set fixed thresholds or static computing power weights. It can adaptively respond to changes in system load, business traffic, and hardware status, thus solving the problem of incorrect path selection caused by the failure of fixed strategies in existing technologies.

[0050] 5. This invention incorporates multiple factors such as the data scale of cryptographic tasks, algorithm characteristics, hardware queue depth, hardware busy status, CPU utilization, and historical execution latency into a unified evaluation framework. It achieves joint perception and comprehensive evaluation of multiple factors through a nonlinear weighted model, overcoming the limitations of existing technologies that only focus on a single factor and lack comprehensive state perception capabilities.

[0051] 6. This invention employs probabilistic smoothing diversion when path benefits are similar, avoiding frequent path switching and system oscillations in critical states. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0054] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a dynamic scheduling method for cryptographic heterogeneous computing based on execution path benefit evaluation proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0056] The following description, in conjunction with the accompanying drawings, details a specific scheme for a dynamic scheduling method for cryptographic heterogeneous computing based on execution path benefit evaluation provided by this invention.

[0057] Please see Figure 1 As shown, the present invention provides a dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation, which includes the following steps S1 to S6.

[0058] Step S1: Respond to the cryptographic computation task request, extract task feature information, and collect the current heterogeneous computing environment's running status information.

[0059] In a preferred embodiment of the present invention, step S1 includes: In response to a received cryptographic computation task request, the task descriptor of the cryptographic computation task is parsed, and task feature information is extracted. The task feature information includes cryptographic algorithm type, algorithm working mode, length of data to be processed, key length, and parallelizability of the task.

[0060] Collect the current operating status information of the heterogeneous computing environment. The operating status information includes CCP hardware queue depth, CCP hardware engine utilization, CCP hardware busy status, hardware path historical latency, CCP dynamic power consumption, CPU core utilization, and CPU dynamic power consumption.

[0061] It should be noted that the cryptographic algorithm types include, but are not limited to, SM2, SM3, SM4, AES, SHA, etc.; the algorithm operating modes include, but are not limited to, ECB, CBC, CTR, GCM, Sign, etc. The task parallelism includes two cases: parallelizable and non-parallelizable. The determination criterion is: if the task has a data dependency chain, it is determined to be non-parallelizable; otherwise, it is determined to be parallelizable.

[0062] It should be noted that after receiving the password calculation task request, multiple sets of data are collected within the current time window, including CCP hardware queue depth, CCP hardware engine utilization, CPU core utilization, and historical task execution latency of hardware paths. The arithmetic mean of each data set is calculated, and the resulting mean is used as the value of each running status information corresponding to the current heterogeneous computing environment.

[0063] It should be noted that the CCP hardware engine utilization rate refers to the ratio of the actual time the CCP hardware engine spends performing cryptographic operations to the total available time per unit time. This value can be obtained through the hardware performance monitoring unit (PMU).

[0064] It should be noted that the CCP hardware busy state is obtained as follows: based on the CCP hardware engine utilization rate of the current heterogeneous computing environment, and combined with the preset CCP hardware engine utilization rate value ranges corresponding to multiple CCP hardware busy states, a matching judgment is performed to obtain the CCP hardware busy state to which the current heterogeneous computing environment belongs. As a specific example of this embodiment, the CCP hardware busy state includes idle state, medium load state, high load state, and overload state. The CCP hardware engine utilization rate ranges corresponding to each state are as follows: idle state corresponds to 0% to 30% (inclusive of endpoint values, the same below), medium load state corresponds to 30% to 70%, high load state corresponds to 70% to 90%, and overload state corresponds to 90% to 100%.

[0065] It should be noted that the CPU dynamic power consumption refers to the dynamic power consumed by the CPU during the execution of software path cryptographic operations due to logic gate flipping and transistor switching activities. It is obtained by reading the average power consumption of the CPU chip within a preset time window through the CPU's integrated Running Average Power Limit (RAPL) interface or power model calculation unit, and subtracting the static leakage power consumption component from this value. As a specific example, the CPU dynamic power consumption can also be obtained by reading the real-time current and voltage values ​​on the CPU core power rail (VR), calculating their product, and then performing low-pass filtering to ensure the smoothness and timeliness of the power consumption data.

[0066] It should be noted that the CCP dynamic power consumption refers to the dynamic power consumed by the CCP hardware engine during hardware path cryptography operations due to internal logic circuit switching and high-speed clock network switching. It is obtained by reading the instantaneous power consumption value of the CCP hardware engine within a preset sampling window using the power monitoring register integrated within the CCP hardware engine or an on-chip power sensor, and subtracting the static power consumption component to obtain the CCP dynamic power consumption. As a specific example, the CCP dynamic power consumption can also be obtained by reading the real-time current and voltage detection values ​​on the CCP hardware engine's power rail, calculating their product, and then performing digital-to-analog conversion and digital filtering to obtain smooth power consumption data. In another example, if the CCP hardware engine does not provide a direct power consumption reading interface, the current dynamic power consumption can be obtained through linear estimation based on the ratio between the current CCP hardware engine utilization rate and the known full-load dynamic power consumption rating.

[0067] It should be understood that the above-mentioned methods for obtaining the dynamic power consumption of CPU and CCP are mature technologies in this field. This embodiment does not limit the specific implementation method. Any method that can provide the current dynamic power consumption values ​​of CPU and CCP can be used in conjunction with this embodiment.

[0068] Step S2: If the running status information meets any of the following system pre-judgment conditions, the software path is determined as the target path and the process proceeds to S6; otherwise, proceed to S3. The system pre-judgment conditions include: CCP hardware queue depth exceeds a preset overload threshold, hardware path historical latency exceeds a preset latency threshold, and CPU core utilization is lower than a preset low level.

[0069] It should be noted that the CCP hardware queue depth overload threshold is used to determine whether the current hardware path is in a state of task backlog overload. In this embodiment, this threshold is set based on the physical queue depth capacity of the CCP hardware engine and the average processing latency of typical cryptographic computation tasks. Typically, 80% of the maximum hardware queue capacity is taken as the default overload threshold. For example, if the maximum depth of the CCP hardware queue is 128 task slots, the overload threshold is set to 102 pending tasks. In actual operation, this threshold can be adaptively adjusted according to the historical task arrival rate and dynamic changes in hardware processing capacity. When the task arrival rate per unit time is consistently higher than the hardware processing rate, the threshold can be appropriately lowered to improve the sensitivity of system security intervention; conversely, it can be appropriately raised to reduce unnecessary software path switching, thereby achieving a balance between system security and execution efficiency.

[0070] It should be noted that the historical latency threshold for the hardware path is used to assess whether the response performance of the hardware path has deteriorated within a past time window. In this embodiment, the threshold is set based on the highest tolerable latency requirement of the cryptographic computing tasks served by the heterogeneous computing system. The default value can be determined according to the Quality of Service (QoS) constraints in typical application scenarios, for example, set to 50 milliseconds. In terms of specific adjustment logic, the threshold is dynamically corrected using latency statistics within a sliding window. When a continuous upward trend in hardware path latency is detected, the system can appropriately lower the threshold to switch the task to the software path in advance to avoid task timeout. When the hardware path latency tends to stabilize and the duration below the threshold exceeds a preset time window, it can be gradually restored to the default value to fully utilize the hardware acceleration capability.

[0071] It should be noted that the CPU core utilization low watermark is used to characterize the sufficiency of available computing resources for the software path. In this embodiment, the low watermark threshold is set based on the minimum proportion of CPU resources reserved by the system for software cryptographic operations. The default value can be set to 30%, meaning that when the CPU core utilization is below 30%, it indicates that the system currently has sufficient computing resources for the software path to perform cryptographic operations. The adjustment logic of this threshold depends on the real-time load comparison between the software path and the hardware path: if, within a continuous time window, the average task execution time of the software path is significantly lower than that of the hardware path, it indicates that the processing capacity of the software path is relatively sufficient, and the low watermark threshold can be appropriately increased to allocate more tasks to the software path; conversely, if the processing performance of the hardware path is significantly better than that of the software path and the CPU resource demand is tight, the low watermark threshold can be appropriately decreased to reduce excessive reliance on the software path, thereby optimizing the overall system's resource utilization and task processing efficiency.

[0072] In this embodiment, the pre-judgment conditions set during the dynamic scheduling of heterogeneous cryptographic computation are designed to address extreme conditions such as hardware path overload, performance degradation, and software path idleness, ensuring scheduling security and response efficiency under abnormal operating conditions. In step S2, when the CCP hardware queue depth exceeds the overload threshold or the historical latency of the hardware path exceeds the latency threshold, it indicates that the hardware path is in a state of task backlog or performance degradation. If tasks are continued to be allocated to the hardware path, it will lead to a significant increase in task response latency. When the CPU core utilization rate is lower than the preset low watermark, it indicates that the CPU software path currently has sufficient computing resources and favorable conditions for efficiently executing cryptographic computation tasks. Based on the judgment of the above three situations, step S2 sets a security constraint filtering mechanism at the front end of the scheduling decision process, so that scheduling decisions can be made directly without subsequent static rule matching and dynamic benefit evaluation in clearly advantageous or disadvantageous scenarios. The beneficial effects of this step are reflected in the following three aspects. First, when the hardware path is overloaded or its performance is degraded, the task is switched to the software path in a timely manner, effectively ensuring the service quality of cryptographic computation tasks and the overall stability of the system. Secondly, when CPU resources are plentiful, software paths are prioritized, reducing unnecessary hardware access and evaluation process overhead, thus lowering system energy consumption. Thirdly, by setting up a fast filtering mechanism at the front end of the decision-making process, the decision path length under extreme conditions is significantly shortened, improving the system's response speed in abnormal states.

[0073] Step S3: Determine whether the task characteristic information matches the pre-configured static scheduling rule. If yes, determine the path specified by the rule as the target path and proceed to S6; otherwise, proceed to S4.

[0074] In a preferred embodiment of the present invention, the method for pre-configuring static scheduling rules includes: Select one or more task features from the task feature information as flag task features, and assign corresponding execution paths to the flag task features. Based on the mapping relationship between the flag task features and the execution paths, establish static scheduling rules.

[0075] It should be noted that there can be multiple pre-configured static scheduling rules, which together constitute a static scheduling rule table. Each static scheduling rule is established by selecting one or more task features from the task feature information as flag task features and specifying a corresponding execution path for each flag task feature. When determining whether the current task feature information matches a pre-configured static scheduling rule, if the task feature information matches any rule in the static scheduling rule table, it is determined to be a match, and the execution path specified by that matching rule is determined as the target path; if the task feature information does not match any rule in the static scheduling rule table, it is determined to be a non-match.

[0076] In one specific embodiment, the static scheduling rules include, but are not limited to: hardware path forced routing rules for asymmetric cryptographic algorithms (such as SM2 and ECDH), path preference rules for specific data length ranges, and other deterministic routing strategies pre-configured by the system. As one example, a static scheduling rule table is constructed using algorithm type as an index. This table consists of several mapping pairs between algorithm types and specified paths, used to record special algorithm types that can be directly routed without dynamic benefit evaluation and their corresponding specified execution paths. The specific matching process is as follows: upon receiving a cryptographic computation task request, task feature information is extracted, and the algorithm type identifier of the current cryptographic computation task is obtained from the task feature information; the algorithm type identifier is matched with each mapping pair in the pre-configured static scheduling rule table. If the algorithm type identifier of the current task matches a mapping pair in the rule table, the specified execution path (software path or hardware path) corresponding to that algorithm type is directly determined as the target path, and the subsequent dynamic benefit evaluation and decision-making process is terminated; if the algorithm type identifier of the current task does not match any mapping pair in the rule table, the subsequent dynamic benefit evaluation process continues.

[0077] In this embodiment, after quickly determining the system's pre-judgment conditions, the scheduling decision process enters the static scheduling rule matching stage. In step S3, certain types or characteristics of cryptographic computation tasks have clear and stable optimal execution path preferences. For example, asymmetric cryptographic algorithms typically rely on specially designed acceleration units in CCP hardware, whose hardware processing speed is far superior to software implementations. These tasks have a deterministic advantage in being assigned to hardware paths. Based on the above principle, step S3 solidifies the deterministic scheduling decisions, verified through prior analysis or history, into the system in the form of static rules, forming a rule matching layer preceding the dynamic benefit evaluation process. The beneficial effects of this step mainly include the following: First, for tasks with deterministic path preferences, scheduling can be completed without performing complex expected time prediction, energy efficiency assessment, and benefit-weighted calculations, significantly reducing decision-making overhead in high-frequency task scenarios. Second, static scheduling rules can be customized and adjusted by operations and maintenance personnel according to actual business needs and hardware changes, providing a flexible channel for manual intervention and enhancing the interpretability of the scheduling strategy. Third, by setting a rule filtering layer before benefit evaluation, the dynamic evaluation engine can centrally process complex tasks with unclear path preferences, thereby improving the overall scheduling system's operating efficiency.

[0078] Step S4: Based on task characteristic information and running status information, predict the expected processing time of the software path and hardware path respectively to calculate the processing speed of the two paths, and calculate the energy efficiency factor and resource cost of the two paths, and comprehensively evaluate the expected benefits of the two paths accordingly.

[0079] In a preferred embodiment of the present invention, the method for calculating the processing speed of a software path includes: Extract the baseline value of the unit data processing time for the current cryptographic algorithm type on the software path from the database, and multiply it by the length of the current data to be processed to obtain the baseline processing time for the software path.

[0080] Compare the length of the data to be processed with the current CPU cache space, calculate the ratio of the overflow amount of the data to be processed exceeding the CPU cache space to the total CPU cache capacity, and use this as the data overflow ratio. Based on the preset mapping relationship between the data overflow ratio and the data size influence factor, determine the data size influence factor of the software path.

[0081] Calculate the ratio between the current CPU core utilization rate and the preset CPU core utilization rate threshold as the relative proportion of CPU core utilization rate. Based on the mapping relationship between the preset relative proportion of CPU core utilization rate and the CPU load impact factor, determine the CPU load impact factor of the software path.

[0082] The expected processing time of the software path is obtained by multiplying the baseline processing time, the data size impact factor, and the CPU load impact factor.

[0083] The ratio of the length of the data to be processed to the expected processing time is calculated as the processing speed of the software path.

[0084] In a preferred embodiment of the present invention, the method for calculating the processing speed of the hardware path includes: Calculate the baseline processing time of the hardware path based on the baseline value of the unit data processing time for the current cryptographic algorithm type and the length of the data to be processed.

[0085] The current CCP hardware queue depth and the historical latency of the hardware path are compared with their corresponding preset thresholds to obtain the queue depth ratio and the historical latency ratio. Based on the preset mapping relationship between the queue depth ratio and the queue depth influence factor, and the mapping relationship between the historical latency ratio and the historical latency penalty factor, the queue depth influence factor and the historical latency penalty factor of the hardware path are determined.

[0086] Based on the current busy status of the CCP hardware, and combined with the preset busy status influence factors corresponding to different CCP hardware busy statuses, the busy status influence factor of the hardware path is matched to obtain the busy status influence factor.

[0087] Multiply the baseline processing time of the hardware path, the queue depth impact factor, the historical latency penalty factor, and the busy state impact factor, and add the resulting product to the fixed commit cost of the hardware path to obtain the expected processing time of the hardware path.

[0088] The ratio of the length of the data to be processed to the expected processing time of the hardware path is calculated as the processing speed of the hardware path.

[0089] In a preferred embodiment of the present invention, the method for calculating the software path energy efficiency factor and the hardware path energy efficiency factor includes: Calculate the product of the current CPU dynamic power consumption and the expected processing time of the software path, then calculate the ratio of the length of the data to be processed to the product, and use the resulting ratio as the energy efficiency factor of the software path.

[0090] Similarly, calculate the product of the current CCP dynamic power consumption and the expected processing time of the hardware path, then calculate the ratio of the length of the data to be processed to the product, and use the resulting ratio as the energy efficiency factor of the hardware path.

[0091] In a preferred embodiment of the present invention, the method for calculating the resource cost of a software path includes: Obtain the overall average CPU utilization rate of the system, and calculate the ratio of the overall average CPU utilization rate of the system to the preset CPU safe utilization threshold.

[0092] If the ratio is less than or equal to 1, it indicates that the overall CPU resources of the system are not scarce, and no additional scarcity penalty is required. The CPU resource scarcity penalty coefficient is set to 1.

[0093] If the ratio is greater than 1, it indicates that the overall CPU resources of the system have entered a scarce state. This ratio is multiplied by a preset scarcity sensitivity coefficient, and the product is used as the CPU resource scarcity penalty coefficient. The scarcity sensitivity coefficient is a constant greater than 1, with a default value of 1.5. It is used to adjust the amplification of resource cost penalties after the system enters a scarce state. This value can be preset or dynamically adjusted according to the system's sensitivity requirements to resource scarcity.

[0094] Obtain the current CPU core utilization rate, calculate the product of the current CPU core utilization rate and the CPU resource scarcity penalty coefficient, and use the resulting product as the resource cost of the software path.

[0095] It should be noted that the current CPU core utilization rate is a percentage value (ranging from 0 to 1). Multiplying it directly by the CPU resource scarcity penalty coefficient yields a dimensionless penalty value for resource cost. The magnitude of this penalty value matches the normalized processing speed and energy efficiency factor, ensuring that the resource cost weight can play the expected penalty adjustment role in the subsequent linear weighted fusion.

[0096] In a preferred embodiment of the present invention, the method for calculating the resource cost of a hardware path includes: The ratio of the task arrival rate to the maximum service rate of the hardware is used as the hardware system utilization intensity.

[0097] If the hardware system utilization intensity is less than 1, it indicates that the hardware path has not yet reached saturation. The difference between 1 and the hardware system utilization intensity is calculated, and its reciprocal is used as the hardware resource scarcity penalty coefficient. In this case, the higher the hardware system utilization intensity, the larger the hardware resource scarcity penalty coefficient, and the higher the resource cost of the hardware path. Therefore, a corresponding penalty is imposed on the hardware path in the benefit assessment, guiding scheduling decisions to divert traffic to software paths when hardware resources are approaching saturation.

[0098] If the hardware system utilization intensity is greater than or equal to 1, it indicates that the hardware path is saturated or oversaturated. In this case, the denominator of the above reciprocal formula is zero or negative, and it cannot be calculated directly. Therefore, the hardware resource scarcity penalty coefficient is set to a preset upper limit protection value. The upper limit protection value is a positive number not less than 2, and its default value is 10. This value is based on the following: when the hardware system utilization intensity reaches 1, the hardware path has no additional service capacity to accommodate new tasks, and a sufficiently large penalty should be applied to divert the vast majority of tasks to the software path. The upper limit protection value can be preset or dynamically adjusted according to the system's tolerance for hardware overload.

[0099] The ratio of the current CCP hardware queue depth to the maximum hardware queue capacity is calculated. This ratio is then multiplied by the hardware resource scarcity penalty coefficient to obtain the product. This product is compared with a preset upper limit for resource costs, and the smaller of the two is taken as the resource cost of the hardware path. The upper limit for resource costs is a positive number not exceeding 10, with a default value of 10. This is used to prevent excessive amplification of resource costs when both queue depth and scarcity penalty coefficient are high, which could lead to instability in the revenue assessment. This upper limit clamping mechanism ensures that resource costs remain stable under extreme operating conditions, preventing abnormal fluctuations in a single dimension from dominating the overall revenue assessment result.

[0100] It should be noted that the above hardware resource scarcity penalty coefficient is calculated in a segmented manner. This ensures a monotonically positive correlation between resource cost and utilization intensity when the hardware system is not saturated. It also avoids division by zero error and negative value risk by taking the upper limit protection value under saturation conditions. This ensures that the hardware path resource cost is non-negative across the entire operating range, which is consistent with the original design intention of using resource cost as a penalty item.

[0101] In a preferred embodiment of the present invention, the method for comprehensively evaluating the expected benefits of the two paths includes: The processing speed, energy efficiency factor, and resource cost of the software path and hardware path are normalized respectively to obtain the normalized processing speed, normalized energy efficiency factor, and normalized resource cost for each path.

[0102] Based on the preset fusion weights corresponding to processing speed, energy efficiency factor, and resource cost, the normalized processing speed of each path is multiplied by its corresponding processing speed weight, the normalized energy efficiency factor is multiplied by its corresponding energy efficiency factor weight, and the normalized resource cost is multiplied by its corresponding resource cost weight. The sum of these three results is taken as the expected return of that path.

[0103] It should be noted that the database stores benchmark values ​​for unit data processing time for different cryptographic algorithm types on both the software and hardware paths. These benchmark values ​​are obtained as follows: During system deployment or operation and maintenance, for each supported cryptographic algorithm type, a representative standard test dataset is selected, and multiple cryptographic computation tasks are independently executed on both the software and hardware paths. The processing time per unit of data (e.g., per kilobyte or per megabyte) in each task is recorded. The results from these multiple records on both paths are then statistically processed (e.g., by taking the arithmetic mean or median) to eliminate measurement bias caused by random system fluctuations. The statistically processed values ​​are then stored in the database as benchmark values ​​for unit data processing time for that algorithm type on both the software and hardware paths. During actual operation, the system can also perform periodic or triggered online corrections to the benchmark values ​​for each algorithm type on both paths based on accumulated feedback from historical task execution data. This allows the benchmark values ​​to adaptively update with the slow changes in system software environment, hardware microcode updates, and CPU / CCP performance.

[0104] It should be noted that the mapping relationship between the data overflow ratio and the data size influence factor is established as follows: Based on the cache hierarchy of the current CPU platform (including L2 and L3 cache capacity) and main memory access bandwidth parameters, actual memory access latency curves under different data overflow ratios are obtained through micro-benchmark testing. Based on this, the data overflow ratio is divided into several continuous intervals, and a corresponding data size influence factor is configured for each interval to characterize the amplification effect of the additional time overhead introduced by data access crossing cache boundaries on the benchmark processing time. As a specific example, the value range of the data size influence factor is set to 1.00 to 1.30. The specific mapping relationships are as follows: when the data overflow ratio is 0, the data size impact factor is 1.00; when the data overflow ratio is greater than 0 but not exceeding 30%, the data size impact factor is determined by linear interpolation from 1.00 to 1.15; when the data overflow ratio is greater than 30% but not exceeding 70%, the data size impact factor is determined by linear interpolation from 1.15 to 1.25; and when the data overflow ratio is greater than 70%, the data size impact factor is 1.30. It should be understood that the endpoints of the above intervals and the values ​​of the data size impact factor are only examples. In actual engineering deployments, calibration should be performed based on the cache hierarchy (such as L2 / L3 cache size) and memory access latency characteristics of the target CPU platform. Mapping parameters suitable for specific hardware platforms can be obtained through conventional benchmark testing.

[0105] It should be noted that the CPU core utilization threshold is used to quantify the impact of the current CPU load on software processing performance in the calculation of the expected processing time of the software path. Its setting is based on the fact that cryptographic operations on the software path mainly rely on CPU computing resources. When the CPU core utilization increases, the time slice available to the software task decreases, resulting in a corresponding extension of the actual processing time compared to the baseline value. In this embodiment, the CPU core utilization threshold is set to 0.6 to 0.7 (i.e., 60% to 70%). This range is determined based on the following: when the CPU core utilization is below 0.6, the system typically has ample idle computing resources, the software path can run close to full performance, and the impact of CPU load on processing time is negligible; when the CPU core utilization exceeds 0.7, the operating system scheduling latency increases significantly, and the overhead of task queuing and context switching rises sharply, resulting in a significant deterioration in software path performance. The adjustment logic for the CPU core utilization threshold is as follows: dynamic correction is made based on the historical task execution feedback in the most recent time period of the software path. Specifically, when the deviation between the actual average processing time of the software path and the processing time predicted based on the current threshold continues to exceed the preset error tolerance range in multiple consecutive time windows, the system gradually increases or decreases the threshold by a preset step size so that the prediction model is more in line with the actual scheduling characteristics and load response curve of the current CPU platform.

[0106] It should be noted that the mapping relationship between the relative proportion of CPU core utilization and the CPU load impact factor is established as follows: Before system deployment, for the target CPU platform, benchmark tests are conducted to obtain the actual processing time of the software path performing cryptographic operations under different CPU core utilization levels. Using the processing time under no-load conditions (CPU core utilization of 0) as a benchmark, the growth factor of processing time under each load level is calculated. This allows for the fitting and establishment of a correspondence between the relative proportion of CPU core utilization and the CPU load impact factor. This factor is used to quantify the amplification effect of scheduling latency and time slice reduction introduced by CPU load contention on software processing time. As a specific example, in the mapping relationship, the relative proportion of CPU core utilization is the ratio between the current CPU core utilization and a preset CPU core utilization threshold (ranging from 0.6 to 0.7). When the relative ratio is less than or equal to 1, it indicates that the current CPU load has not exceeded the threshold, and the load has little impact on the software path performance. The CPU load impact factor is set to 1.0. When the relative ratio is greater than 1 but not more than 1.2, it means that the current CPU core utilization exceeds the threshold but has not yet reached a severe overload state. The CPU load impact factor increases linearly from 1.0 to 1.10. When the relative ratio is greater than 1.2 but not more than 1.5, the CPU load impact factor increases linearly from 1.10 to 1.20. When the relative ratio is greater than 1.5, it indicates that the CPU is under severe overload, the software path performance is severely degraded, and the CPU load impact factor is set to 1.30.

[0107] It should be understood that the endpoints of each interval and the corresponding factor values ​​mentioned above are only illustrative examples. In actual engineering deployments, calibration should be performed according to the scheduling strategy of the target CPU platform (such as the time slice allocation mechanism of the CFS scheduler) and the real-time preemption characteristics. The mapping parameters applicable to the specific hardware and operating system environment can be obtained through standard performance testing tools.

[0108] It should be noted that the CCP hardware queue depth threshold is used to quantify the impact of the current congestion level of the hardware task queue on the processing latency of subsequent tasks in the calculation of the expected processing time of the hardware path. The threshold is set based on the fact that the CCP hardware engine typically adopts a first-in, first-out (FIFO) task queue structure. When the queue depth exceeds a certain level, newly submitted tasks must wait for all existing tasks in the queue to complete before they can be executed. This queuing time is approximately proportional to the queue depth. In this embodiment, the CCP hardware queue depth threshold is set to 60% of the maximum depth of the hardware queue. For example, if the maximum depth of the CCP hardware queue is 128 task slots, then the threshold is set to 77 pending tasks. The adjustment logic for this threshold is as follows: it is dynamically corrected based on the historical average processing time and task arrival rate of the hardware path. Specifically, when the average queuing time of hardware tasks exceeds the preset tolerance range within multiple consecutive time windows, the system lowers the threshold by a preset step size to improve the sensitivity of the queue depth influence factor, so that more tasks can be diverted to the software path when the queue depth is still at a low level. Conversely, when the hardware path is idle or under low load for a long time, the system gradually raises the threshold to make full use of hardware acceleration resources and reduce unnecessary path switching overhead.

[0109] It should be noted that the hardware path historical latency threshold is used to evaluate whether the recent performance of the hardware path has shown a deteriorating trend in the calculation of the expected processing time of the hardware path. The threshold is set based on the fact that the historical task execution latency of the hardware path reflects the actual processing capability of the CCP hardware engine in the current operating environment. When the historical latency consistently exceeds the preset threshold, it indicates that the hardware path may experience performance degradation due to reasons such as microcode updates, temperature-induced frequency throttling, power management strategy adjustments, or hardware aging. A penalty factor needs to be applied in the benefit evaluation to reduce the priority of the hardware path. In this embodiment, the hardware path historical latency threshold is set to twice the baseline value of the hardware path's unit data processing time under standard test conditions. For example, if the baseline processing time for the current algorithm type on the hardware path is 5 milliseconds per megabyte, then the latency threshold is set to 10 milliseconds per megabyte. The adjustment logic for this threshold is as follows: based on the actual execution latency statistics of the hardware path within the most recent time window, the latency trend value is calculated using the exponentially weighted moving average method. If the trend value exceeds the current threshold for several consecutive windows and shows an upward trend, the threshold is gradually lowered to respond more quickly to the performance degradation of the hardware path. If the trend value falls below the threshold and lasts for more than a preset stable window, it is gradually restored to the default value to avoid excessive penalties due to occasional latency fluctuations.

[0110] It should be noted that the mapping relationship between the queue depth ratio and the queue depth influence factor is established as follows: Before system deployment, background task flows of different depths are injected into the CCP hardware queue. The actual processing time of target tasks from submission to completion at each queue depth level is measured. Taking the processing time at a queue depth of 0 (i.e., an empty queue) as a benchmark, the growth factor of processing time under each queue depth ratio is calculated. This allows for the fitting and establishment of a correspondence between the queue depth ratio and the queue depth influence factor. This factor is used to quantify the amplification effect of queuing delays introduced by newly submitted tasks waiting for existing tasks in the queue to be dequeued and completed on the expected processing time. As a specific example, the queue depth ratio is the ratio of the current CCP hardware queue depth to a preset CCP hardware queue depth threshold (60% of the maximum hardware queue depth). When the queue depth ratio is less than or equal to 1, it indicates that the current queue depth is below the threshold, the queuing time is short, and the impact on hardware processing performance is limited; the queue depth impact factor is set to 1.0. When the queue depth ratio is greater than 1 but not exceeding 1.5, the queue depth impact factor increases linearly from 1.0 to 1.05. When the queue depth ratio is greater than 1.5 but not exceeding 2.0, the queue depth impact factor increases linearly from 1.05 to 1.10. When the queue depth ratio is greater than 2.0, it indicates that the hardware queue is deeply congested, but considering that the dequeue rate of the CCP hardware engine is relatively stable and the increase in queuing latency tends to be gradual, the queue depth impact factor is set to 1.20. It should be understood that the above interval endpoints and corresponding factor values ​​are only illustrative examples. In actual engineering deployments, calibration should be performed according to the task dequeue rate and average task processing time of the specific CCP hardware engine. Mapping parameters suitable for specific hardware platforms can be obtained through standard performance testing tools.

[0111] It should be noted that the mapping relationship between the historical latency ratio and the historical latency penalty factor is established as follows: Before system deployment, different levels of background interference tasks are injected into the CCP hardware path to simulate various latency degradation scenarios. The actual processing time of the target task under each scenario is measured. Using the processing time under normal conditions (historical latency equals the baseline processing time) as a benchmark, the growth factor of processing time under each historical latency ratio is calculated. This allows for the fitting and establishment of a correspondence between the historical latency ratio and the historical latency penalty factor. This factor is used to quantify the penalized amplification effect of recent performance degradation of the hardware path on the expected processing time of the current task. As a specific example, the historical latency ratio is the ratio of the current hardware path's historical latency to a preset hardware path historical latency threshold (twice the baseline value of the hardware path's unit data processing time under standard test conditions). When the historical latency ratio is less than or equal to 1, it indicates that the recent performance of the hardware path is within the normal range, and no additional penalty is required; the historical latency penalty factor is set to 1.0. When the historical latency ratio is greater than 1 but does not exceed 1.3, the historical latency penalty factor increases linearly from 1.0 to 1.08. When the historical latency ratio is greater than 1.3 but does not exceed 1.6, the historical latency penalty factor increases linearly from 1.08 to 1.15. When the historical latency ratio is greater than 1.6, it indicates that the hardware path has significant performance degradation; the historical latency penalty factor is set to 1.2. It should be understood that the endpoints of the above intervals and the corresponding factor values ​​are only illustrative examples. In actual engineering deployments, calibration should be performed based on the performance degradation characteristics of the specific CCP hardware engine and the statistical distribution of task processing time. Mapping parameters suitable for a specific hardware platform can be obtained through standard performance testing tools.

[0112] It should be noted that the busy state impact factors corresponding to the different CCP hardware busy states are established as follows: Before system deployment, different background load scenarios are constructed, causing the CCP hardware engine to run within the preset utilization range corresponding to each busy state. Standard test tasks are executed in each state, and the actual processing time of the task in the idle state is used as a benchmark to calculate the growth factor of processing time in each busy state. This determines the value of the impact factor corresponding to each busy state. This factor is used to quantify the amplification effect of resource contention and instruction scheduling delay on the expected processing time of the CCP hardware engine under the current busy level. As a specific example, the CCP hardware busy states include idle state, medium load state, high load state, and overload state, corresponding to the following CCP hardware engine utilization ranges: idle state corresponds to 0% to 30%, medium load state to 30% to 70%, high load state to 70% to 90%, and overload state to 90% to 100%. The impact factors for each busy state are as follows: In the idle state, hardware resources are ample, and processing performance can be fully utilized, with an impact factor of 1.0; in the medium load state, the hardware engine experiences slight resource contention, but the impact on task processing throughput is minimal, with an impact factor of 1.03; in the high load state, hardware engine resource contention intensifies, and instruction scheduling latency increases significantly, with an impact factor of 1.07; in the overload state, the hardware engine operates near full capacity, and processing performance is severely degraded, with an impact factor of 1.12. It should be understood that the utilization range divisions and impact factor values ​​corresponding to the above busy states are only illustrative examples. In actual engineering deployments, calibration should be performed based on the specific CCP hardware engine's microarchitecture characteristics and resource scheduling strategies. Standard performance testing tools can be used to obtain state division thresholds and factor values ​​applicable to specific hardware platforms.

[0113] It should be noted that the fixed submission overhead of the hardware path refers to the fixed time overhead, independent of the length of the data to be processed, necessary before the cryptographic computation task is submitted from the software layer to the CCP hardware engine and executed by the hardware. This overhead includes at least the time consumed by the construction and configuration of the task descriptor, the enqueue operation of the hardware queue, interrupt response, and context switching. The fixed submission overhead is obtained as follows: During the system deployment phase, for each supported cryptographic algorithm type, a fixed length of test data (e.g., zero bytes or the smallest data block, such as 1 byte) is selected. Under the condition that the hardware queue is empty and there are no other interfering factors, the hardware path submission operation is repeatedly executed multiple times. The time difference between the task submission time and the hardware execution start time is recorded for each operation. Statistical processing (e.g., taking the arithmetic mean or median value) is performed on the multiple recorded results to eliminate biases caused by operating system scheduling and measurement noise. The statistically processed value is stored in the database as the fixed submission overhead of the hardware path. In practice, since the fixed commit overhead mainly depends on the inherent latency of the software driver layer and hardware interface, its value is relatively stable and generally does not need to be updated frequently. However, after the driver version is upgraded or the hardware microcode is updated, the system can re-execute the above test operation to correct the stored fixed commit overhead value to ensure the accuracy of the hardware path expected processing time calculation.

[0114] It should be noted that the overall system CPU average utilization rate is used to characterize the overall resource saturation of all CPU cores in the current heterogeneous computing environment. It is obtained as follows: Through the system-level performance monitoring interface provided by the operating system (such as the / proc / stat file in Linux or performance counters in Windows), the active and idle times of each CPU core are read at a fixed sampling period within a preset time window. The utilization rate of each core is calculated, and the arithmetic mean of all cores is taken as the overall system CPU average utilization rate. Specifically, the sum of the non-idle time (including user-mode time, kernel-mode time, and I / O wait time) of each core within the preset sampling window is divided by the total time to obtain the utilization rate of a single core. Then, the utilization rates of all cores are summed and divided by the total number of CPU cores; the resulting average is the overall system CPU average utilization rate. This collection process is triggered every time a password calculation task request arrives to ensure that the obtained average utilization rate reflects the latest system resource contention status.

[0115] It should be noted that the CPU safe utilization threshold is used to define whether the overall computing resources of the system are in a scarce state, and is the benchmark parameter for calculating the CPU resource scarcity penalty coefficient. Its setting is based on the following: when the overall average CPU utilization rate of the system continuously exceeds a certain level, the operating system scheduling latency increases significantly, and the response time and throughput of critical tasks will experience unacceptable degradation. This level is determined as the CPU safe utilization threshold. In this embodiment, the CPU safe utilization threshold is set to 70% to 80%. The determination of this range is based on the following: when the overall average CPU utilization rate of the system is below 70%, the system still has sufficient computing margin, the resource cost of the software path is low, and no significant scarcity penalty needs to be imposed; when the average utilization rate is between 70% and 80%, the system is approaching a resource bottleneck, and a certain cost penalty should be imposed on the allocation of tasks to the software path to suppress overuse; when the average utilization rate exceeds 80%, it indicates that the system has entered a resource scarcity state, and continuing to allocate tasks to the software path will cause significant fluctuations in system performance. The resource cost of the software path should be significantly increased through the scarcity penalty coefficient, thereby guiding scheduling decisions to tilt towards the hardware path. In actual engineering deployments, this threshold should be set according to the service quality requirements of the specific application scenario (such as the maximum tolerable latency of the task, the lower limit of system throughput, etc.). A configuration value suitable for a specific deployment environment can be obtained through stress testing. It should be understood that the aforementioned CPU safe occupancy threshold and the aforementioned CPU core utilization threshold used to calculate the relative proportion of CPU core utilization are two independently configurable parameters. They differ in physical meaning and function. The former is used to determine whether the overall system resources are in a scarce state to calculate resource costs, while the latter is used to quantify the amplification effect of CPU load on processing time to predict processing speed. In specific implementations, they can be set independently to the same or different values; this implementation does not impose such restrictions.

[0116] It should be noted that the maximum hardware queue capacity refers to the maximum number of task slots that the queue structure inside the CCP hardware engine can accommodate for caching pending cryptographic computation task requests. This is an inherent parameter determined during the CCP hardware architecture design phase. In this embodiment, the maximum hardware queue capacity is obtained as follows: during system initialization, the maximum queue depth value supported by the current CCP hardware engine is obtained by reading the CCP hardware device configuration register or the queue depth attribute interface provided by the hardware abstraction layer; or the corresponding queue capacity parameter is obtained by querying the hardware resource description table (such as the ACPI table or device tree) passed from the firmware to the operating system kernel during system startup. The maximum hardware queue capacity value obtained in the above manner remains constant during system operation. It is typically read once during driver initialization and cached in memory for direct use in subsequent calculation steps, without needing to repeatedly read the hardware registers.

[0117] It should be noted that the task arrival rate refers to the number of cryptographic computation tasks arriving at the CCP hardware queue per unit time, which characterizes the real-time task load intensity faced by the current hardware path. In this embodiment, the task arrival rate is obtained as follows: within a preset time window, the total number of tasks newly submitted to the hardware path is counted using the task submission count of the driver layer or the enqueue event count of the CCP hardware queue. The total number of tasks is then divided by the time window length to obtain the average task arrival rate per unit time. The length of the time window can be dynamically adjusted according to the drastic changes in task arrival traffic. For example, a shorter time window is used when task arrival traffic fluctuates greatly to improve response sensitivity, while a longer time window is used when traffic is stable to smooth out occasional fluctuations. The above statistical process is updated once at the end of each time window, and the updated task arrival rate value is stored in system memory for subsequent reading when calculating hardware system utilization intensity.

[0118] It should be noted that the maximum hardware service rate refers to the maximum number of cryptographic computation tasks that the CCP hardware engine can complete per unit time under ideal conditions (i.e., when the hardware queue is empty and there is no contention). It is an inherent performance parameter characterizing the peak processing capability of the CCP hardware engine. In this embodiment, the maximum hardware service rate is obtained as follows: during the system deployment or hardware initialization phase, a standardized hardware performance evaluation procedure is executed. Under the condition that the hardware queue is empty and no other interfering tasks are running, cryptographic computation tasks are continuously submitted to the CCP hardware engine. The number of tasks that the hardware can complete per unit time is measured, and the arithmetic mean of multiple measurements is stored in the database as the maximum hardware service rate. In specific implementation, since the maximum hardware service rate mainly depends on the microarchitecture design and operating frequency of the CCP hardware engine, this value remains relatively stable when the hardware parameters do not change, and generally does not need to be updated frequently. However, after hardware frequency adjustment (such as dynamic voltage frequency adjustment, DVFS) or microcode update, the system should re-execute the above evaluation procedure to obtain the updated service rate value to ensure the accuracy of hardware system utilization intensity calculation.

[0119] It should be noted that the dynamic fusion weights corresponding to processing speed, energy efficiency factor, and resource cost are used to adjust the relative contribution of the three factors to the final benefit score in the expected benefit calculation. Their setting is based on the real-time operating status of the current heterogeneous computing environment and the focus of the system optimization objectives. Specifically, the dynamic fusion weights include processing speed weight, energy efficiency factor weight, and resource cost weight, the sum of which is 1. In this embodiment, the default values ​​for the fusion weights are as follows: processing speed weight is 0.5, energy efficiency factor weight is 0.2, and resource cost weight is 0.3. The determination of these default values ​​is based on the following: the primary optimization objective of the cryptographic heterogeneous computing system is task execution efficiency, hence the processing speed weight is the largest; resource cost is secondary, to consider the long-term resource sustainability of the system; the energy efficiency factor weight is relatively small to adapt to the actual situation in most application scenarios where power consumption sensitivity is lower than performance sensitivity. The adjustment logic for the fusion weights is as follows: the system adaptively adjusts based on the current operating mode and preset scheduling strategy preferences. Specifically, when the system detects that it is currently in a performance-priority mode (such as processing high-priority real-time cryptographic tasks), the processing speed weight is increased while the energy efficiency factor weight and resource cost weight are decreased accordingly. When the system detects that it is currently in an energy-saving-priority mode (such as battery-powered or low-load operating scenarios), the energy efficiency factor weight is increased while the processing speed weight and resource cost weight are decreased accordingly. When the system detects that the current CPU or CCP resource utilization rate is continuously approaching its respective safety threshold, the resource cost weight is increased while the processing speed weight and energy efficiency factor weight are decreased accordingly, in order to guide scheduling decisions to select paths with lower resource consumption and avoid the system entering an overload state. It should be understood that the above weight values ​​and adjustment logic are only illustrative examples. In actual engineering deployments, the weights should be configured according to the service quality requirements and system management strategies of the specific application scenario. The weight parameters suitable for a specific deployment environment can be determined through experience or statistical analysis based on historical task execution data.

[0120] Step S5: Compare the expected returns of the two paths and calculate the return difference. If the return difference is less than the preset return difference threshold, the target path is determined through a probabilistic selection mechanism; otherwise, the path with the larger expected return is selected as the target path.

[0121] In a preferred embodiment of the present invention, step S5 includes: S51. Calculate the absolute value of the difference between the expected revenue of the software path and the expected revenue of the hardware path, and calculate the average value of the expected revenue of the two paths.

[0122] If the average value is less than a preset minimum positive threshold, the profit difference is set to zero; otherwise, the absolute value of the difference is divided by the average value, and the resulting ratio is taken as the profit difference.

[0123] S52. Compare the profit difference with a preset profit difference threshold.

[0124] S53. If the profit difference is less than the profit difference threshold, the target path is determined through a probabilistic selection mechanism.

[0125] S54. If the difference in returns is greater than or equal to the threshold for difference in returns, then the path corresponding to the one with the larger expected return is determined as the target path.

[0126] It should be noted that the minimum positive number threshold is a positive number no greater than 10 to the power of -6, and its default value is 10 to the power of -6.

[0127] It should be noted that the aforementioned payoff difference threshold is used to determine whether the expected payoffs of two paths are close, in order to decide whether to trigger a probabilistic selection mechanism. The rationale for this threshold is that when the payoff difference between two paths is small relative to their average payoff level, the decision advantage of forcibly choosing the path with the larger payoff is extremely limited. Furthermore, the overhead introduced by frequent path switching due to system state fluctuations may outweigh this advantage. Therefore, a threshold needs to be set to define the range within which payoffs are close. In this embodiment, the revenue difference threshold is set to 5% to 10% (i.e., 0.05 to 0.10). The determination of this range is based on the following: the ratio of the absolute value of the revenue difference between the two paths to the average revenue of the two paths is taken as the relative revenue difference. When the ratio is less than 5%, the actual performance difference between the two paths can be considered to be insignificant in engineering terms, and the task should be smoothly distributed entirely through a probabilistic mechanism. When the ratio is between 5% and 10%, although the one with greater revenue has a certain advantage, the advantage is not sufficient to constitute a strong reason for selection. The task should still be allocated according to the revenue ratio through a probabilistic mechanism to maintain scheduling smoothness. When the ratio exceeds 10%, the advantage of the one with greater revenue has statistical significance and practical engineering meaning. A strong selection strategy should be adopted to ensure optimal task execution efficiency.

[0128] Furthermore, the adjustment logic for the revenue difference threshold is as follows: dynamic correction is performed based on statistical feedback from the system's current load status and path switching frequency. Specifically, when the system detects that the alternation frequency of path selection results within a continuous time window exceeds the preset oscillation tolerance limit, it indicates that the current threshold setting is too small, resulting in an overly narrow critical region. The system gradually increases the threshold with a preset step size to expand the applicability of the probabilistic selection mechanism, smooth task distribution, and suppress oscillations. Conversely, when the system is operating in a steady state and the path switching frequency is low, the threshold can be gradually decreased to reduce the randomness introduced by probabilistic selection, making scheduling decisions more certain and stable. It should be understood that the above threshold value range and adjustment logic are only illustrative examples. In actual engineering deployments, the balance between scheduling stability and performance optimization needs should be configured according to the specific application scenario. The revenue difference threshold parameter suitable for a specific deployment environment can be determined through statistical analysis of historical task execution data.

[0129] It should be noted that the process of determining the target path through the probabilistic selection mechanism is as follows: When the difference in benefits between the software path and the hardware path is less than a preset benefit difference threshold, it indicates that the two paths perform similarly under the current task characteristics and operating environment. If a hard selection mechanism is used in this situation, i.e., always choosing the path with the greater benefit, then when small fluctuations in the system state cause frequent alternations in the benefit relationship, it will trigger critical oscillations in path selection, resulting in unstable scheduling decisions and unnecessary system overhead. To overcome the above problems, this implementation adopts a probabilistic selection mechanism to achieve smooth task distribution between the two paths.

[0130] The specific implementation method of the probabilistic selection mechanism is as follows: First, determine whether the expected revenue of the software path and the expected revenue of the hardware path are greater than zero.

[0131] If the expected returns of both paths are greater than zero, the sum of the expected returns of the hardware path and the software path is calculated. The expected return of the hardware path is then divided by this sum, and the resulting ratio is taken as the probability that the hardware path is selected. As can be seen from the above calculation method, this probability value ranges from 0 to 1. The higher the proportion of the expected return of the hardware path to the sum of the returns of the two paths, the greater its probability of being selected. When the returns of the two paths are equal, the probability of the hardware path being selected is one-half, meaning that both paths have an equal chance of being selected.

[0132] If the expected returns of both paths are less than or equal to zero, then the expected returns themselves no longer have any physical meaning as a basis for probability calculation—in this case, neither path can bring positive returns, and choosing either path will not produce any performance gain. In this situation, the scheduling objective should shift from maximizing returns to minimizing costs, that is, comparing the resource costs of software paths with those of hardware paths, selecting the path with the lower resource cost as the target path, and skipping the subsequent random number selection step to avoid unnecessary resource consumption.

[0133] If only one path has an expected return greater than zero, then that path has a clear advantage in terms of return. The path with an expected return greater than zero should be directly identified as the target path, without the need for random selection, so as to ensure that the task always obtains positive returns.

[0134] When the expected returns of both paths are greater than zero and a probabilistic selection mechanism is triggered, a pseudo-random number between 0 and 1 is generated by the system's random number generator. This random number is then compared with the selection probability of the hardware path. If the random number is less than the selection probability of the hardware path, the hardware path is selected as the target execution path; if the random number is greater than or equal to the selection probability of the hardware path, the software path is selected as the target execution path.

[0135] Through the aforementioned probabilistic selection mechanism, when the rewards of two paths are similar and both positive, the probability of each path being selected is proportional to its reward. Tasks are allocated to each path according to probability, rather than being rigidly fixed to a particular path. This effectively avoids frequent switching between paths due to minor fluctuations in the system state, improving the long-term stability and smoothness of the scheduling strategy. At the same time, paths with relatively higher expected rewards still receive a greater probability of selection, ensuring that the scheduling decision tends to be statistically optimal overall.

[0136] Step S6: Route the password calculation task to the target path for calculation.

[0137] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0138] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. The focus of each embodiment is on its differences from other embodiments. In particular, the apparatus embodiments are described simply because they are fundamentally based on the method embodiments; relevant details can be found in the descriptions of the method embodiments.

[0139] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0140] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0141] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] Secondly, the accompanying drawings of the embodiments disclosed in this invention only involve structures related to the embodiments disclosed in this invention. Other structures can refer to general designs. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other.

[0145] Finally, the above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation, characterized in that, Includes the following steps: S1. Respond to the cryptographic computation task request, extract task feature information, and collect the current heterogeneous computing environment's running status information; S2. If the running status information meets any of the following system pre-judgment conditions, then the software path is determined as the target path and the process proceeds to S6; otherwise, proceed to S3. The system pre-judgment conditions include: The CCP hardware queue depth exceeds the preset overload threshold; The historical latency of the hardware path exceeds a preset latency threshold; CPU core utilization is lower than the preset low level; S3. Determine whether the task characteristic information matches the pre-configured static scheduling rule. If yes, determine the path specified by the rule as the target path and proceed to S6; otherwise, proceed to S4. S4. Based on task characteristic information and running status information, predict the expected processing time of the software path and hardware path respectively to calculate the processing speed of the two paths, and calculate the energy efficiency factor and resource cost of the two paths, and comprehensively evaluate the expected benefits of the two paths accordingly. S5. Compare the expected returns of the two paths and calculate the return difference. If the return difference is less than the preset return difference threshold, the target path is determined through a probabilistic selection mechanism; otherwise, the path with the larger expected return is selected as the target path. S6. Route the cryptographic calculation task to the target path for execution.

2. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 1, characterized in that, Step S1 includes: In response to a received cryptographic computation task request, the task descriptor of the cryptographic computation task is parsed, and task feature information is extracted. The task feature information includes cryptographic algorithm type, algorithm working mode, length of data to be processed, key length, and parallelizability of the task. Collect the current operating status information of the heterogeneous computing environment. The operating status information includes CCP hardware queue depth, CCP hardware engine utilization, CCP hardware busy status, hardware path historical latency, CCP dynamic power consumption, CPU core utilization, and CPU dynamic power consumption.

3. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 1, characterized in that, Methods for pre-configuring static scheduling rules include: Select one or more task features from the task feature information as flag task features, and assign corresponding execution paths to the flag task features. Based on the mapping relationship between the flag task features and the execution paths, establish static scheduling rules.

4. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 2, characterized in that, Methods for calculating the processing speed of software paths include: Extract the baseline value of the unit data processing time for the current cryptographic algorithm type on the software path from the database, and multiply it by the length of the current data to be processed to obtain the baseline processing time for the software path. Compare the length of the data to be processed with the current CPU cache space, calculate the ratio of the overflow amount of the data to be processed exceeding the CPU cache space to the total CPU cache capacity, and use it as the data overflow ratio. Based on the preset mapping relationship between the data overflow ratio and the data size influence factor, determine the data size influence factor of the software path. Calculate the ratio between the current CPU core utilization rate and the preset CPU core utilization rate threshold as the relative proportion of CPU core utilization rate. Based on the mapping relationship between the preset relative proportion of CPU core utilization rate and the CPU load impact factor, determine the CPU load impact factor of the software path. Multiply the baseline processing time of the software path, the data size impact factor, and the CPU load impact factor to obtain the expected processing time of the software path. The ratio of the length of the data to be processed to the expected processing time is calculated as the processing speed of the software path.

5. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 2, characterized in that, Methods for calculating the processing speed of hardware paths include: Calculate the baseline processing time of the hardware path based on the baseline value of the unit data processing time of the current cryptographic algorithm type and the length of the data to be processed. The current CCP hardware queue depth and the historical latency of the hardware path are compared with their corresponding preset thresholds to obtain the queue depth ratio and the historical latency ratio. Based on the preset mapping relationship between the queue depth ratio and the queue depth influence factor and the mapping relationship between the historical latency ratio and the historical latency penalty factor, the queue depth influence factor and the historical latency penalty factor of the hardware path are determined. Based on the current busy status of the CCP hardware, and combined with the preset busy status influence factors corresponding to different CCP hardware busy statuses, the busy status influence factor of the hardware path is matched and obtained. Multiply the baseline processing time of the hardware path, the queue depth impact factor, the historical latency penalty factor, and the busy state impact factor, and add the product to the fixed commit cost of the hardware path to obtain the expected processing time of the hardware path. The ratio of the length of the data to be processed to the expected processing time of the hardware path is calculated as the processing speed of the hardware path.

6. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 2, characterized in that, Methods for calculating the energy efficiency factor of the software path and the energy efficiency factor of the hardware path include: Calculate the product of the current CPU dynamic power consumption and the expected processing time of the software path, then calculate the ratio of the length of the data to be processed to the product, and use the obtained ratio as the energy efficiency factor of the software path. Similarly, calculate the product of the current CCP dynamic power consumption and the expected processing time of the hardware path, then calculate the ratio of the length of the data to be processed to the product, and use the resulting ratio as the energy efficiency factor of the hardware path.

7. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 2, characterized in that, Methods for calculating the resource cost of a software path include: Obtain the overall average CPU utilization of the system and calculate the ratio of the overall average CPU utilization of the system to the preset safe CPU utilization threshold; If the ratio is less than or equal to 1, the CPU resource scarcity penalty coefficient is set to 1. If the ratio is greater than 1, the ratio is multiplied by a preset scarcity sensitivity coefficient, and the resulting product is used as the CPU resource scarcity penalty coefficient; wherein, the scarcity sensitivity coefficient is a constant greater than 1. Obtain the current CPU core utilization rate, calculate the product of the current CPU core utilization rate and the CPU resource scarcity penalty coefficient, and use the resulting product as the resource cost of the software path.

8. The dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 2, characterized in that, Methods for calculating the resource cost of a hardware path include: The ratio of the task arrival rate to the maximum service rate of the hardware is used as the hardware system utilization intensity. If the utilization intensity of the hardware system is less than 1, then calculate the difference between 1 and the utilization intensity of the hardware system, and use the reciprocal of the difference as the hardware resource scarcity penalty coefficient. If the utilization intensity of the hardware system is greater than or equal to 1, then the hardware resource scarcity penalty coefficient is set to a preset upper limit protection value. Calculate the ratio of the current CCP hardware queue depth to the maximum capacity of the hardware queue, and multiply this ratio by the hardware resource scarcity penalty coefficient to obtain the product value; The product value is compared with a preset upper limit for resource costs, and the smaller of the two values ​​is taken as the resource cost of the hardware path.

9. A dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 1, characterized in that, Methods for comprehensively evaluating the expected returns of the two paths include: The processing speed, energy efficiency factor, and resource cost of the software path and hardware path are normalized respectively to obtain the normalized processing speed, normalized energy efficiency factor, and normalized resource cost for each path. Based on the preset fusion weights corresponding to processing speed, energy efficiency factor, and resource cost, the normalized processing speed of each path is multiplied by its corresponding processing speed weight, the normalized energy efficiency factor is multiplied by its corresponding energy efficiency factor weight, and the normalized resource cost is multiplied by its corresponding resource cost weight. The sum of these three results is taken as the expected return of that path.

10. A dynamic scheduling method for heterogeneous cryptographic computing based on execution path benefit evaluation according to claim 1, characterized in that, Step S5 includes: Calculate the absolute value of the difference between the expected revenue of the software path and the expected revenue of the hardware path, and calculate the average of the expected revenues of the two paths; If the average value is less than a preset minimum positive threshold, the profit difference is set to zero; otherwise, the absolute value of the difference is divided by the average value, and the resulting ratio is taken as the profit difference. The difference in returns is compared with a preset threshold for the difference in returns; If the profit difference is less than the profit difference threshold, the target path is determined through a probabilistic selection mechanism. If the difference in returns is greater than or equal to the threshold for difference in returns, then the path corresponding to the one with the greater expected return is determined as the target path.

Images