Method and apparatus for controlling the execution of tasks in a computing system

Abstract

To disclose a method, a device, a system and a product for controlling execution of a task in a computing system.SOLUTION: In a method, a device, a system and a product, the device includes at least one storage device and at least one processor. The at least one processor executes at least an instruction to acquire a request for executing a reverse direction operation to a data flow previously converted during a forward direction operation, determine a first processor core that has executed the forward direction operation and transmit the data flow including an identifier of the first processor core to a second processor core in order to execute the reverse direction operation.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This disclosure generally relates to computing systems, and more particularly to controlling the execution of tasks in a computing system.

Background Art

[0002] In recent years, computing systems have been designed to include more than one processor. Such computing systems are referred to as multi-core computing systems. Multi-core computing systems can execute multiple tasks in parallel, enhance the efficiency of the computing system, optimize the computing system, and provide different opportunities for troubleshooting.

Brief Description of the Drawings

[0003] [Figure 1] FIG. is a diagram of an exemplary implementation of a multi-core computing system for controlling the execution of forward and reverse functional tasks. [Figure 2] FIG. 1 is a block diagram showing an exemplary core of the multi-core computing system. [Figure 3] FIG. 1 is a block diagram showing an exemplary resource manager of the multi-core computing system. <0​​​​​​​​​​​​​This is a block diagram of an example processing platform configured to execute the instructions shown in Figures 5 and 6 in order to implement a multicore computing system. [Figure 9] This is a block diagram of an exemplary software distribution platform for distributing software (e.g., software corresponding to the exemplary computer-readable instructions in Figures 6 and 7) to client devices such as consumers (e.g., for licensing, sale, and / or use), retailers (e.g., for sale, resale, licensing, and / or sublicensing), and / or original equipment manufacturers (OEMs) (e.g., for inclusion in products distributed to retailers or direct-purchasing customers). The drawings are not to scale. Generally, the same reference numerals are used to refer to the same or similar parts throughout the drawings and the accompanying descriptions.

[0004] Unless otherwise specified, descriptors such as “First,” “Second,” “Third,” etc., are used herein without ever attributing or indicating any meaning of priority, physical order, placement in a list, and / or sequence, and are used solely as labels and / or arbitrary names to distinguish elements for the sake of understanding the examples of disclosure. In some examples, the descriptor “First” may be used to indicate a certain element in the detailed description, but the same element may be indicated in the claims by different descriptors such as “Second” or “Third.” In such examples, it should be understood that such descriptors are used solely to distinguish and identify elements that may otherwise share the same name. [Modes for carrying out the invention]

[0005] In data processing and data transfer, data is currently protected from software within the device platform by cyclic redundancy check (CRC). CRC is an error detection code that detects unauthorized modifications to raw data. The process of performing a CRC involves the transmitter (e.g., a device, software, application, etc.) generating check values ​​and adding them to the raw data before sending it to the receiver (e.g., the device platform requesting the data). The receiver generates check values ​​upon receiving the data and compares the two check values ​​to determine if they match. If the check values ​​do not match, the data may be considered corrupted. The receiver may take several corrective actions to obtain the correct data from the transmitter. If the check values ​​match, the receiver processes and / or stores the data. Thus, the data is protected during transfer from the transmitting device and / or transmitting software to the receiving device.

[0006] However, data may not be protected within the device platform. For example, when a check value is validated (e.g., when the check value matches), the data is sent to a processing element for processing (e.g., encryption, decryption, compression, decompression, etc.), and in some cases, these processing elements may be faulty. Thus, the data may be corrupted due to the faulty processing element. Conventional methods for protecting data within a device platform include dual-redundant and triple-redundant systems.

[0007] Dual modular redundancy (DMR) is a process that duplicates and / or abstracts processing engines to compare their outputs, submitting data for the same task to both engines. For example, in a dual modular redundancy system, two engines receive the same data, perform the same job and / or task (e.g., encryption, decryption, Fast Fourier transform (FFT), etc.), and compare the output data. The outputs of both engines must match for the job to be considered successful.

[0008] A Triple Redundancy System (TMR) is a process similar to a DMR, except that tasks and / or jobs are submitted to three identical processing engines instead of two. In a TMR, the outputs of the three processing engines are submitted to a majority voting system that identifies the correct output (e.g., identifying uncorrupted data) based on a 2-to-1 vote. For example, if two outputs match and one does not, the values ​​of the two matching outputs are considered correct. If two or more outputs do not match, no correct value exists, and the job is considered a failure.

[0009] These conventional methods require two to three times the resources for the device platform to enable TMR and / or DMR. In some examples, these resources include the central processing unit (CPU), random-access memory (RAM), cache space, network throughput, power, I / O operations, direct memory access (DMA) channels, and external memory. These extra resources increase the bill of materials (BOM) cost for the device platform and further increase the processing time required to handle data transfers.

[0010] The examples disclosed herein verify data within a device platform using a single-pass flow (e.g., data is processed once). The examples disclosed herein particularly focus on packet processing (e.g., analysis and storage of network packets) and its end-to-end stages. For example, in packet processing, a device acquires data packets from a network and goes through the stages of encryption, storage, decryption, and transmission. In such examples, the examples disclosed herein detect silent data corruption errors occurring in data processing (e.g., encryption and / or decryption stages) based on tracking which elements are performing tasks on the data. However, the examples disclosed herein are not limited to packet processing. For example, the examples disclosed herein can be implemented by radio signal processing systems, data compression systems, and the like.

[0011] Examples disclosed herein include a response controller that identifies the source of processed data (e.g., core, engine, element, entity, etc.) and tags the processed data with an identifier corresponding to the source. This enables a workload controller, such as a load balancer, to ensure that different processing entities are used for reverse processing operations on the data. Examples disclosed herein mitigate double errors that may occur due to a faulty processor performing both forward and reverse operations. Double errors can occur when the same faulty entity is used to generate and validate data, resulting in incorrect validation checks.

[0012] Figure 1 shows an exemplary implementation of an exemplary multicore computing system 100 coupled to an exemplary network 102 to control the execution of forward and reverse functional tasks. The exemplary multicore computing system 100 includes an exemplary processor 101, exemplary main memory 104, exemplary network interface card 106, and exemplary application (e.g., firmware and / or software application) 108. The exemplary processor 101 includes an exemplary first core 110, an exemplary second core 112, an exemplary third core 114, an exemplary fourth core 116, an exemplary load balancer 118, and an exemplary resource manager 122.

[0013] In Figure 1, the exemplary multicore computing system 100 can implement distributed units (DUs), centralized units (CUs), and / or core devices. In the examples disclosed herein, the DUs and / or CUs are edge servers, such as multicore edge servers (e.g., 5G edge servers), that can distribute data flows (e.g., communication flows, packet flows, flows of one or more data packets, etc.) to different destinations (e.g., a 5G device environment, a core network, etc.) through the network 102. In the examples disclosed herein, the core device is a multicore server (e.g., a physical server, a virtual server, etc., and / or a combination thereof). Furthermore and / or alternatively, the core device may be any type of computing device. In some examples, the multicore computing system 100 can implement computing devices in a wireless environment, i.e., a wireless environment to facilitate the execution of computing tasks using a wireless network (e.g., network 102).

[0014] In Figure 1, the exemplary multicore computing system 100 includes an exemplary processor 101 for performing one or more computing tasks. For example, processor 101 includes cores 110, 112, 114, and 116 that perform tasks based on data acquired from network 102 via data flow 120. In some examples, cores 110, 112, 114, and 116 perform forward and reverse tasks on the data acquired from network 102. For example, a forward task includes any other task / job, including encryption, compression, FFT, and / or a corresponding reverse task / job. A reverse task includes any other task / job, including decryption, decompression, reverse FFT, and / or reversing the previous task / job. In some examples disclosed herein, cores 110, 112, 114, and 116 encrypt the data. For example, cores 110, 112, 114, and 116 implement an encryption algorithm to securely store the data in main memory 104. In other examples, cores 110, 112, 114, and 116 decrypt data. For example, cores 110, 112, 114, and 116 implement decryption algorithms and / or decryption methods such as counter mode (CTR) decryption. In some examples, some of cores 110, 112, 114, and 116 encrypt data and decrypt data. For example, any of cores 110, 112, 114, and 116 can be used to encrypt and / or decrypt data.

[0015] In Figure 1, cores 110, 112, 114, and 116 may be located within a cluster. For example, the first core 110 and the second core 112 are included in the first cluster, and the third core 114 and the fourth core 116 are included in the second cluster. In the examples disclosed herein, a cluster is a set of loosely connected or tightly connected processor cores that cooperate so as to be considered a single processing system. In a multicore computing system (e.g., the multicore computing system 100 in Figure 1), multiple cores are used to speed up data processing. For example, a large data flow that requires a significant amount of processing to complete a job quickly can be divided among multiple cores 110, 112, 114, and 116. In the examples disclosed herein, a multicore computing system 100 includes multiple cores 110, 112, 114, and 116, which not only accelerate processing time but also ensure that different cores perform reverse tasks (e.g., decryption, decompression, etc.) from cores that perform forward tasks (e.g., encryption, compression, etc.). Thus, cores 110, 112, 114, and 116 include controllers that generate descriptors such as response descriptors and request descriptors that inform entities (e.g., other cores, NIC 106, application 108, load balancer 118, etc.) how the data has been processed. The exemplary cores 110, 112, 114, and 116 are described in further detail below with reference to Figure 2.

[0016] In Figure 1, the exemplary multicore computing system 100 includes exemplary main memory 104 for storing data corresponding to data flow 120. In some examples, cores 110, 112, 114, and 116 store data in main memory 104. In some examples, the NIC 106 stores data in main memory 104. In some examples, application 108 stores data in main memory 104. In some examples, main memory 104 is communicatively coupled to processor 101. In other examples, main memory 104 is directly coupled to processor 101 via wiring connections. Thus, the exemplary processor 101 can access the data stored in exemplary main memory 104.

[0017] In Figure 1, an exemplary multicore computing system 100 includes an exemplary NIC 106 for receiving data packets from dataflow 120. In some examples, NIC 106 can randomly spray packets via receive-side scaling (RSS), thereby reducing the bandwidth associated with cores 110, 112, 114, 116, and / or more generally, processor 101 including cores 110, 112, 114, 116. In other examples, NIC 106 can distribute data packets from dataflow 120 to a single core among 110, 112, 114, and 116 based on information associated with the data packets. For example, NIC 106 may detect and / or read information within the data packet descriptor to determine which core 110, 112, 114, or 116 will process the data packet.

[0018] In some examples, application 108 directs data flow 120 from input 122 to processor 101 via the first of the NICs 106. In some examples, cores 110, 112, 114, 116, and / or more generally, processor 101 can send processed data packets to output 124 via the second of the NICs 106 and / or application 108. Although two instances of NIC 106 are shown in Figure 1, alternatively, the two instances may be combined into a single instance, and / or different numbers of NICs 106 may be used.

[0019] In Figure 1, an exemplary multicore computing system 100 includes an exemplary application 108 that directs, manages, etc., an exemplary data flow 120. In some examples, application 108 performs processing tasks on data packets within the data flow 120, such as encryption and compression tasks. In some examples, application 108 communicates with an application programming interface (API) via a network 102. In some examples, application 108 determines which of cores 110, 112, 114, and 116 will perform tasks related to the data flow 120. For example, a particular task related to application 108 may be executed faster and / or more efficiently on a designated accelerator (e.g., FPGA, GPU, cryptographic accelerator), and application 108 assigns the particular task to this designated accelerator. In some examples, application 108 labels data flow 120 with a core identifier (ID, identifier) ​​to indicate which core (e.g., one of cores 110, 112, 114, 116) data flow 120 should be directed to (e.g., concatenate, append, etc.).

[0020] In FIG. 1, an exemplary processor 101 includes an exemplary load balancer 118 within a multi-core computing system 100 to improve load balancing and workload distribution. In some examples, the load balancer 118 distributes the data flow 120 to a specific cluster among the clusters of cores 110, 112, 114, 116 based on cluster availability (e.g., available resources associated with the cluster). The exemplary load balancer 118 distributes the data flow 120 to one or more cores 110, 112, 114, 116 based on a scheduling type (e.g., atomic scheduling, sequential scheduling, etc.), receives the data flow 120 processed from the one or more cores 110, 112, 114, 116, and can re-order and / or aggregate the processed data flow 120 in preparation for distribution and / or transmission to different hardware, different logical entities, etc.

[0021] In FIG. 1, the processor 101 includes exemplary resource managers 122a and 122b, collectively resource manager 122, to direct the data flow 120 to one of the cores within the cluster. In FIG. 1, the exemplary first resource manager 122a manages a first cluster that includes and / or contains the first core 110 and the second core 112. In FIG. 1, the exemplary second resource manager 122b manages a second cluster that includes and / or contains the third core 114 and the fourth core 116. The exemplary resource manager 122 determines which core within the cluster will process the data flow 120 in response to receiving the data flow 120 from the exemplary load balancer 118. For example, the resource manager 122 distributes the data flow 120 to a specific core based on a core identifier (ID) associated with the data flow 120. For example, the resource manager 122 may read and / or analyze descriptors concatenated and / or appended to the data packets of the data flow 120. The exemplary resource manager 122 is described in further detail below with respect to FIG. 3.

[0022] In some examples, the resource manager 122 implements exemplary means for allocation and / or management. The means for allocation and / or management are implemented by executable instructions such as those implemented at least by blocks 702, 704, 706, 708, and 710 of FIG. 7. The executable instructions of blocks 702, 704, 706, 708, and 710 of FIG. 7 may be executed on at least one processor such as exemplary processor 812 of FIG. 8. In other examples, the means for allocation and / or management are implemented by hardware logic, hardware-implemented state machines, logic circuits, and / or any other combination of hardware, software, and / or firmware.

[0023] Referring to FIG. 2, a block diagram of an exemplary core 200 is shown. The exemplary core 200 can implement any of cores 110, 112, 114, 116 within the cluster of FIG. 1. The exemplary core 200 includes an exemplary operation controller 202, an exemplary response controller 204, and an exemplary memory 206.

[0024] In Figure 2, the exemplary core 200 includes an exemplary operation controller 202 for performing operations on a data flow (e.g., data flow 120 in Figure 1). The exemplary operation controller 202 implements forward and reverse computing functions such as compression and decompression, encryption and decryption, FFT and inverse FFT, etc. For example, the operation controller 202 transforms the data flow based on specific computing functions. In the examples disclosed herein, the operation controller 202 implements CRC technology. For example, the operation controller verifies integrity checks on data packets in data flow 120. Thus, data packets coming from a network (e.g., network 102 in Figure 1) or an application (e.g., application 108 in Figure 1) are analyzed and verified to protect the core 200 from any type of corruption. Furthermore, packets coming from the core 200 to an application (e.g., application 108 in Figure 1) or a network (e.g., network 102 in Figure 1) are analyzed and verified to protect data and applications and / or the network. The exemplary operation controller 202 communicates with an exemplary response controller 204, an exemplary memory 206, an exemplary resource manager (e.g., the first resource manager 122a and / or the second resource manager 122b in Figure 1), a load balancer (e.g., the load balancer 118 in Figure 1), one or more NICs (e.g., the NIC 106 in Figure 1), and one or more applications (e.g., the application 108 in Figure 1).

[0025] In some examples, the operation controller 202 implements exemplary means for controlling operation and / or core operation. These means are implemented by executable instructions, such as those implemented by blocks 602, 604, 606, 608, 610, 614, and 620 in Figure 6. The executable instructions 602, 604, 606, 608, 610, 614, 620, and 622 in Figure 6 may be executed by at least one processor, such as the exemplary processor 812 in Figure 8. In other examples, the means for controlling operation and / or core operation are implemented by hardware logic, hardware implementation state machines, logic circuits, and / or other combinations of hardware, software, and / or firmware.

[0026] In Figure 2, the exemplary core 200 includes an exemplary response controller 204 for controlling the generation of response descriptors. As used herein, a descriptor is information that describes how data (e.g., data packets, data flows, etc.) is processed on the requesting side (e.g., by application 108 in Figure 1) or how it is processed by a responding device (e.g., core 200). In some examples, the requesting side provides the responding side with a request descriptor. For example, a request descriptor corresponding to an application that wishes to encrypt a data flow (e.g., data flow 120 in Figure 1) to the responding side would include information such as plaintext, encryption key, algorithm, configuration, core ID used for encryption, buffer addresses (e.g., input, output), etc. In some examples, the responding side includes any software, firmware, and / or hardware that performs the request. For example, a response descriptor corresponding to a core that performs encryption and / or decryption (e.g., core 200) would include information such as ciphertext / plaintext, integrity check status flags (e.g., success, failure, exception, etc.), core ID, etc.

[0027] An exemplary response controller 204 obtains information from the operation controller 202 and / or memory 206 that corresponds to how the data will be processed. In some examples, the response controller 204 generates a data sequence containing all the processing information. In other examples, the response controller 204 generates an array of bits, each bit corresponding to the type of data (e.g., encryption key, status flag, core ID, configuration, algorithm, etc.). In some examples, the response controller 204 concatenates, appends, combines, etc., the array of bits with plaintext (e.g., raw input data and / or decrypted data), (e.g., encrypted data of an encryption algorithm and / or unreadable output), and / or any other type of processed data.

[0028] In some examples, the response controller 204 sends the descriptor to a NIC (e.g., one of the NICs 106 in Figure 1), an application (e.g., application 108 in Figure 1), a network (e.g., network 102 in Figure 1), and / or memory (e.g., memory 206, main memory 104 in Figure 1, etc.). In some examples, application 108 in Figure 1 guides the flow of the descriptor based on the data flow 120. In other examples, the load balancer 118 in Figure 1 guides the flow of the descriptor.

[0029] In some examples, the response controller 204 implements exemplary means for controlling the generation of response descriptors. These means are implemented by executable instructions, such as those implemented by blocks 612, 616, and 618 in Figure 6. The executable instructions in 612, 616, and 618 of Figure 6 may be executed by at least one processor, such as the exemplary processor 812 in Figure 8. In other examples, the means for controlling the generation of response descriptors are implemented by hardware logic, a hardware implementation state machine, logic circuits, and / or any other combination of hardware, software, and / or firmware.

[0030] In Figure 2, the core 200 includes an exemplary memory 206 for storing data that is input to and output to the operation controller 202 and the response controller 204. For example, memory 206 stores compressed and / or encrypted data submitted by an application (e.g., application 108 in Figure 1). In the examples disclosed herein, memory 206 is implemented by a cache. In other examples, memory 206 is implemented by magnetic core memory, system memory, the main memory of the computing system (e.g., main memory 104 in the multicore computing system 100 in Figure 1) and / or any other type of memory. The exemplary memory 206 may be accessed by any core in the multicore processor 101 in Figure 1, the exemplary resource manager 122 in Figure 1, the exemplary load balancer 118 in Figure 1, the exemplary application 108 in Figure 1, the exemplary NIC 106 in Figure 1 and / or the exemplary main memory 104 in Figure 1.

[0031] Referring to Figure 3, a block diagram of an exemplary resource manager 300 is shown. The exemplary resource manager 300 can implement either resource manager 122a or 122b in Figure 1. The exemplary resource manager 300 includes an exemplary interface controller 302 and an exemplary core decision controller 304.

[0032] In Figure 3, the exemplary resource manager 300 includes an exemplary interface controller 302 for receiving requests to perform actions on a data flow (e.g., data flow 120 in Figure 1). In some examples, the interface controller 302 is a communication controller that receives and sends data and / or instructions to different processing elements (e.g., processor cores, load balancers, etc.). In some examples, the interface controller 302 sends a request to the core determination controller 304 for analyzing the data flow. In some examples, the interface controller 302, and / or more generally the resource manager 300, allows the corresponding core (e.g., a core managed by the resource manager 300) to update the output data (e.g., transformed data) by the core ID in the response descriptor. For example, the interface controller 302 may query the corresponding core for the response descriptor containing the transformed data and the core ID.

[0033] In some examples, the interface controller 302 implements exemplary means for receiving and transmitting data requests. These means are implemented by executable instructions, such as those implemented by blocks 702, 708, and 710 in Figure 7. The executable instructions in 702, 708, and 710 in Figure 7 may be executed by at least one processor, such as the exemplary processor 812 in Figure 8. In other examples, the means for receiving and transmitting data requests are implemented by hardware logic, a hardware implementation state machine, logic circuits, and / or any other combination of hardware, software, and / or firmware.

[0034] In Figure 3, the resource manager 300 includes an exemplary core determination controller 304 for determining the type of operation required in the data flow and defining which processing core identifier will perform the operation. The exemplary core determination controller 304 determines whether the data in the data flow has been processed in the forward direction. For example, the core determination controller 304 identifies whether the request descriptor contains ciphertext for decryption, compressed data for decompression, etc.

[0035] In some examples, if the data in the data flow has been processed forward, the core decision controller 304 sends the data flow to a different core than the forward processing core. For example, the core decision controller 304 analyzes the response descriptor corresponding to the request received by the interface controller 302 and identifies the core to be used to perform the forward operation. In some examples, the core decision controller 304 can identify the core to be used to perform the forward operation based on the core ID in the response descriptor. An exemplary core decision controller 304 performs the operation of the request by selecting a core ID different from the core ID in the response descriptor corresponding to the request. The core decision controller 304 is not limited to analyzing requests for data that has been processed forward. The core decision controller 304 continues to analyze requests for the type of data and the type of operation that should be performed to determine which core in the cluster should send the data flow to. In some examples, the core decision controller 304 notifies the interface controller 302 of the selected core.

[0036] In some examples, the core determination controller 304 implements exemplary means for determining a core for processing. The means for determining a core for processing is implemented by executable instructions, such as those implemented by blocks 704 and 706 in Figure 7. The executable instructions 704 and 706 in Figure 7 may be executed by at least one processor, such as the exemplary processor 812 in Figure 8. In other examples, the means for determining a core for processing is implemented by hardware logic, a hardware implementation state machine, logic circuits, and / or any other combination of hardware, software, and / or firmware.

[0037] Returning to Figure 1, we will describe an exemplary operation of the implementation of the multicore computing system 100 in Figure 2 for encrypting and decrypting dataflow 120. In the exemplary operation, application 108 sends a request to processor 101 via a first of the NICs 106 to securely store the data of dataflow 120 (e.g., encrypt the dataflow). The exemplary application 108 includes processing information (e.g., a request descriptor) in the request. For example, application 108 identifies a desired core (e.g., a first of the cores 110) for processing, keys, configuration, etc.

[0038] In exemplary operation, the load balancer 118 receives the request and determines where to direct the data flow 120. For example, the load balancer 118 may query the resource manager 122 about the resource availability of the cluster. In some examples, if the cluster containing the desired processing core (e.g., the first of the cores 110) is unavailable, the load balancer 118 queues the data (e.g., adds and / or places elements such as queue elements into the queue) from the unavailable cluster (e.g., the first cluster containing the first of the cores 110) to a different cluster (e.g., the third or fourth of the cores 114, 116). For example, the load balancer 118 directs the data flow 120 to a cluster available for encryption (e.g., containing an appropriate amount of computing resources). In some examples, a cluster may be unavailable, for example, when one or more of its cores are processing different data flows, when the cluster does not have enough resources to handle the size of the data flow 120, or when the cluster does not have the computing power to perform the request for the data flow 120.

[0039] In exemplary operation, the desired first resource manager 122a retrieves the dataflow 120 (for example, when the first cluster is available) and determines which cores (110, 112) in the cluster can process the dataflow 120. In some examples, the first resource manager 122a determines which cores (110, 112) are available based on the request descriptor corresponding to the dataflow 120. In other examples, the first resource manager 122a determines which cores (110, 112) are available based on core availability. The exemplary first resource manager 122a sends the dataflow 120 to the desired processing core and / or an available processing core (for example, the first core 110). The desired processing core (for example, core 110) retrieves the dataflow 120 and processing information from the first resource manager 122a. In some examples, the first core 110 utilizes the request descriptor corresponding to the dataflow (for example, the key and configuration) to perform an encryption task.

[0040] In exemplary operation, core 110 performs integrity checking of data flow 120. For example, core 110 generates a CRC value and / or integrity check value and compares it to the CRC value contained in data flow 120. The terms “CRC value” and “integrity check value” are equivalent and can be used interchangeably herein. Depending on whether the comparison between the two CRC values ​​matches, core 110 encrypts the data in data flow 120. For example, if the data is successfully verified, core 110 implements the Advanced Encryption Standard (AES) in counter mode to encrypt and / or encode the data. In AES counter mode, core 110 generates ciphertext by XORing the plaintext data with a counter value (e.g., an AES counter). Core 110 generates a CRC value depending on the encryption of data flow 120.

[0041] In exemplary operation, core 110 generates a response descriptor based on the ciphertext, core ID, CRC value, and CRC state. For example, core 110 generates a response descriptor by concatenating the encoded data with the core ID, CRC value, and "success" state. In some examples, core 110 stores the response descriptor in memory, such as main memory 104. In other examples, core 110 submits the response descriptor to application 108 via a second of the NICs 106.

[0042] In an exemplary operation, application 108 submits a request to processor 101 via the first of the NICs 106 to retrieve data from storage. For example, application 108 implements a request to decrypt dataflow 120. In some examples, application 108 retrieves a response descriptor corresponding to the request. For example, application 108 implements a memory query to obtain ciphertext and processing information corresponding to the encrypted dataflow 120. In some examples, application 108 accesses the encrypted dataflow 120 from main memory 104 via one of the NICs 106.

[0043] In an exemplary operation, the load balancer 118 retrieves a request and response descriptor from one of the NICs 106. Based on cluster availability, information in the request and response descriptors, the size of the data flow 120, etc., the exemplary load balancer 118 decides which cluster to queue the data flow 120 to. In an exemplary operation, the load balancer 118 decides to queue the data flow 120 in the first cluster (including the first core 110 and the second core 112).

[0044] An exemplary first resource manager 122a retrieves the data flow 120. The exemplary first resource manager 122a analyzes the response descriptor corresponding to the data flow 120 and determines the appropriate core to queue the data flow 120. In some examples, the resource manager 122 is trained to queue the data flow 120 to a core that has not been previously used. For example, the first resource manager 122a queues the data flow 120 to the second of the cores 112 because the first of the cores 110 performed a forward task (e.g., encryption) on the data flow 120. The exemplary resource manager 122 queues different processing cores for forward and reverse tasks to detect and / or identify a faulty core. For example, performing reverse tasks on different cores eliminates the possibility of a false positive scenario. A false positive scenario can occur during AES in counter mode. For example, if the first core 110 generates an incorrect counter value, the decryption phase of data flow 120 will be decrypted with the same incorrect counter value used during encryption, and therefore processor 101 will not detect that core 110 is generating an incorrect counter value. However, if a different core obtains data flow 120 encrypted with an incorrect counter value, the different core will attempt to decrypt data flow 120 with the correct counter value, and since the plaintext is not the original plaintext of data flow 120 before encryption, the final CRC check will fail. The only time data for application 108 is unprotected is inside a processing core (e.g., one of cores 110, 112, 114, or 116) when the data is being transformed (e.g., processed). If an error occurs in one of cores 110, 112, 114, or 116 (e.g., due to process degradation (permanent), a SER event (temporal), etc.), the error will be automatically included in the output CRC calculation and will not be detected within the CRC flow.

[0045] In an exemplary operation, the exemplary first resource manager 122a queues an encrypted data flow 120 for the second of the cores 112 based on a response descriptor (e.g., a core ID corresponding to the first of the cores 110 and tagged in the response descriptor) and core availability.

[0046] The second core 112 retrieves the request and data flow 120 and verifies its integrity. For example, the second core 112 generates a CRC value and compares it to the CRC value contained in the data flow 120. Depending on the comparison, the second core 112 updates a status flag to indicate whether the verification was successful or not. In some examples, if the verification is successful, the second core 112 continues to decrypt the data. In other examples, if the verification fails, the second core 112 generates a response descriptor containing the ciphertext of the data flow 120, the failure status, and the identifier of the second core 112. Thus, the exemplary load balancer 118, resource manager 122, and / or exemplary application 108 can determine that further troubleshooting is required based on the response descriptor.

[0047] In exemplary operation, the second core 112 decrypts the dataflow 120 depending on the success of the verification. In some examples, if the second core 112 is faulty, an incorrect counter value may be used to decrypt the dataflow 120. Thus, during the final CRC verification, the second core 112 allows different processing entities to observe a CRC failure against the plaintext and detect the error. In other examples, if the first core 110 performs incorrect encryption and the second core 112 performs the intended decryption, the second core 112 allows different processing entities to observe a CRC failure against the plaintext and detect the error.

[0048] In exemplary operation, if any of the cores performing a reverse task (e.g., a decryption task) observes a failure, the exemplary load balancer 118, exemplary resource manager 122, and / or exemplary application 108 may move the data to recover it (e.g., troubleshoot how to correctly decrypt the data) and isolate the faulty core from computing resources so as not to contaminate other data flows. In some examples, the resource manager 122 may send the faulty data back to the core that performed the forward task in order to recover it. In some examples, the application 108 and / or load balancer 118 may notify the operator, system manager, etc., of the faulty core and / or disable the core from the multicore computing system 100. In some examples, if the faulty core is offloaded and / or disabled, the core can pass system diagnostic tests.

[0049] The advantages of implementing response controllers (e.g., response controller 204 in Figure 2) within processing cores 110, 112, 114, and 116, and training the resource manager 122 to select different cores for forward and reverse tasks, include achieving end-to-end data integrity within the multicore computing system 100. An example disclosed herein enables real-time detection of defective processing entities within the multicore computing system 100 that should be identified and isolated within the system.

[0050] Figure 4 is a data flow diagram 400 for an encryption request. The exemplary data flow diagram 400 includes an exemplary cryptographic engine 401. The exemplary cryptographic engine 401 is a module (e.g., a processor) designed to perform encryption and / or decryption operations. In Figure 4, the exemplary cryptographic engine 401 is an unprotected processing core. For example, the cryptographic engine 401 does not include or implement a response controller with core ID tagging and therefore cannot detect silent defects in the data during processing.

[0051] In Figure 4, the application (e.g., software and / or firmware) submits the plaintext and key to be encrypted to the exemplary cryptographic engine 401. The submission involves several steps, including a first step 402, a second step 404, a third step 406, and a fourth step 408. Steps 402, 404, 406, and 408 each correspond to the verification of the data (e.g., plaintext, key, ciphertext, etc.) in the submission.

[0052] In the exemplary data flow diagram 400, the application generates CRC values ​​for the plaintext and key in the first step 402. For example, the application can generate CRC values ​​based on the data in the plaintext. The application sends the data (e.g., plaintext, key, and CRC values) over the network to the exemplary cryptographic engine 401. The transmission of the data is protected by CRC verification upon input to the engine 401. For example, in the second step 404, the cryptographic engine 401 performs an integrity check to verify the data. In some examples, the cryptographic engine 401 generates a CRC value and compares it to the CRC value generated by the application. If the comparison shows a match, the exemplary cryptographic engine 401 can access the plaintext and key.

[0053] In the exemplary data flow diagram 400, the application encrypts the plaintext using a key in the third step 406 and generates a CRC value. For example, the cryptographic engine 401 generates a CRC value based on the output ciphertext. The exemplary cryptographic engine 401 responds to the application's submission by sending the ciphertext and CRC value back to the application over the network. The response path is protected by the CRC generated at the output of the cryptographic engine 401.

[0054] For example, in step 408, the application performs an integrity check to validate the data before it can access it. In step 408, the application can validate the integrity of the data, but it may not notice any errors that may have occurred during the encryption of the data. If any errors occur, the application will not know how to troubleshoot them because the exemplary cryptographic engine 401 has not tagged the data with a core ID.

[0055] Figure 5 is a data flow diagram 500 for encryption and decryption requests. Figure 5 includes an exemplary application 501, an exemplary first core 503, an exemplary second core 505, and an exemplary storage disk 507. In Figure 1, the exemplary first core 503 and the exemplary second core 505 are cryptographic engines. The exemplary first core 503 and the exemplary second core 505 implement an exemplary response controller (e.g., response controller 204 in Figure 2) to generate a response descriptor having a core identifier. In Figure 5, the exemplary first core 503 is associated with ID0, and the exemplary second core 505 is associated with ID1. In Figure 5, the exemplary application 501 is software and / or firmware designed to store personal information (e.g., user information such as social security numbers, credit card information, etc.).

[0056] In Figure 5, the exemplary application 501 submits the plaintext and key to be encrypted to the exemplary first core 503. The first submission goes through several steps, including the first step 502, the second step 504, the third step 506, and the fourth step 508. In Figure 5, the exemplary application 501 submits the ciphertext to be decrypted to the exemplary second core 505. The second submission goes through several steps, including the fifth step 510, the sixth step 512, and the seventh step 514.

[0057] In the exemplary operation of data flow diagram 500, application 501 generates a first CRC value based on the plaintext and key in step 502. The first CRC value, along with the plaintext and key, is sent to an exemplary first core 503. In the second step 504, in some examples, the exemplary first core 503 performs an integrity check to validate the data before accessing the plaintext and key.

[0058] In response to the verification of data submitted by the exemplary application 501, the exemplary first core 503 encrypts the plaintext with a key. For example, the first core 503 generates ciphertext. In Figure 5, the first core 503 is a defective core and therefore an error occurs during ciphertext generation. In some examples, the error is caused by XORing the plaintext with the wrong key in order to generate ciphertext. However, some type of error may also occur during the processing of data submitted by application 501.

[0059] In an exemplary third step 506, the first core 503 generates a CRC value based on the ciphertext. In some examples, the CRC value protects the defective ciphertext. In an exemplary fourth step 508, the first core 503 generates a response descriptor, which includes the core ID0, the CRC value, and the ciphertext, among other information and data.

[0060] In the exemplary operation of data flow diagram 500, exemplary application 501 retrieves and stores a response descriptor in response to output from the first core 503. For example, application 501 may facilitate and / or instruct the response descriptor to be stored in system memory until the user requests data within the response descriptor.

[0061] Thus, the exemplary application 501 submits a second request in response to a user requesting stored data. For example, the user requests personal information securely stored in system memory. In some examples, application 501 submits the second request to a load balancer (hardware not shown). In such examples, the load balancer decides where to direct the data for decryption. For example, the load balancer analyzes the response descriptor corresponding to the data and determines which core has previously processed the data. Thus, the load balancer selects a second core 505 to decrypt the data based on core ID 0 tagged in the response descriptor.

[0062] In the exemplary data flow diagram 500, the exemplary second core 505 retrieves the data in the fifth step 510 and performs an integrity check. Depending on the success of the data validation, the exemplary second core 505 accesses and decrypts the data. The exemplary second core 505 may output defective plaintext (e.g., plaintext that does not match the original plaintext submitted by application 501). For example, the second core 505 attempts to decrypt the data with the correct key, but the data was encrypted with the wrong key in the first core 503. Therefore, the plaintext output of the second core 505 may not match the plaintext output of application 501 in the first step of data flow diagram 500.

[0063] In the exemplary data flow diagram 500, the exemplary second core 505 generates a CRC value and a response descriptor for the decoded data in the sixth step 512. In response to the generation of the CRC value and response descriptor for the decoded data, the exemplary second core 505 transmits (e.g., stores) the data to the exemplary storage disk 507.

[0064] The exemplary storage disk 507 performs an integrity check in the seventh step 514. The exemplary storage disk 507 performs an integrity check based on a comparison between the first CRC value generated in the first step 502 and the last CRC value generated in the sixth step. In some examples, if the comparison does not show a match, the storage disk 507 may notify the computing system implementing application 501 to application 501 and / or any other processing hardware. Thus, the exemplary application 501 can troubleshoot using the core IDs stored in the response descriptors from cores 503, 505.

[0065] Figures 1-3 show exemplary ways of implementing the multicore computing system 100 of Figure 1, but one or more of the elements, processes and / or devices shown in Figures 1-3 may be combined, split, rearranged, omitted, removed and / or implemented in any other way. Furthermore, the exemplary processor 101, exemplary NIC 106, exemplary application 108, exemplary load balancer 118, exemplary resource manager 122, exemplary first core 110, exemplary second core 112, exemplary third core 114, exemplary core 116, exemplary operation controller 202, exemplary response controller 204, exemplary resource manager 300, exemplary core decision controller 302, and / or more generally the exemplary multicore computing system 100 of Figure 1 may be implemented by hardware, software, firmware, and / or any combination of hardware, software and / or firmware.Therefore, for example, an exemplary processor 101, an exemplary NIC 106, an exemplary application 108, an exemplary load balancer 118, an exemplary resource manager 122, an exemplary first core 110, an exemplary second core 112, an exemplary third core 114, an exemplary fourth core 116, an exemplary core 200, an exemplary operation controller 202, an exemplary response controller 204, an exemplary resource manager 300, an exemplary interface controller 302, an exemplary core decision controller 304, and / or more generally, the exemplary multicore computing system 100 in Figure 1 may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field programmable logic devices (FPLDs).When reading any of the claims of the apparatus or system of this Patent in order to cover a purely software and / or firmware implementation, the exemplary processor 101, exemplary NIC 106, exemplary application 108, exemplary load balancer 118, exemplary resource manager 122, exemplary first core 110, exemplary second core 112, exemplary third core 114, exemplary fourth core 116, exemplary core 200, exemplary operation controller 202, exemplary response controller 204, exemplary resource manager 300, exemplary interface controller 302 and / or exemplary core determination controller 304 are expressly defined herein to include memory containing software and / or firmware, non-transient computer-readable storage devices or storage disks such as digital versatile disks (DVDs), compact disks (CDs), Blu-ray discs, etc. Furthermore, the exemplary multicore computing system 100 in Figure 1 may include, in addition to or instead of, those shown in Figures 1-3, one or more elements, processes, and / or devices, and / or more than one or all of the illustrated elements, processes, and devices. As used herein, the term “communicating,” including its variations, encompasses direct communication and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or constant communication, but rather further includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and / or one-off events.

[0066] Figures 6 and 7 show flowcharts representing exemplary hardware logic, machine-readable instructions, hardware implementation state machines, and / or any combination thereof for implementing the multicore computing system 100 of Figure 1. The machine-readable instructions may also be one or more executable programs or parts of executable programs for execution by a computer processor and / or processor circuit, such as the processor 812 shown in the exemplary processor platform 800 described below with respect to Figure 8. The program may be embodied as software stored on a non-temporary computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 812; however, the entire program and / or parts thereof may, alternatively, be executed by a device other than the processor 812 and / or embodied in firmware or dedicated hardware. Furthermore, while the exemplary program is described with reference to the flowcharts shown in Figures 6 and 7, many other methods for implementing the exemplary multicore computing system 100 may be used as alternatives. For example, the execution order of blocks may be changed, and / or some of the described blocks may be modified, removed, or combined. Furthermore, or alternatively, part or all of the block may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) configured to perform the corresponding operations without running software or firmware. The processor circuits may be distributed across different network locations and / or locally distributed across one or more devices (e.g., a multi-core processor in a single machine, multiple processors distributed across a server rack, etc.).

[0067] The machine-readable instructions described herein may be stored in one or more of the following formats: compressed format, encrypted format, fragmented format, compiled format, executable format, packaged format, etc. The machine-readable instructions described herein may be stored as data or data structures (e.g., instruction parts, code, code representations, etc.) that can be used to create, manufacture and / or generate machine-executable instructions. For example, machine-readable instructions may be fragmented and stored in one or more storage devices and / or computing devices (e.g., servers) located at the same or different locations on a network or set of networks (e.g., a cloud, edge devices, etc.). Machine-readable instructions may require one or more of the following to be directly readable, interpretable and / or executable by computing devices and / or other machines: installation, modification, adaptation, update, combination, supplementation, configuration, decryption, decompression, unpacking, distribution, reallocation, compilation, etc. For example, machine-readable instructions may be stored in multiple parts, each individually compressed, encrypted, and stored on separate computing devices, such that when decrypted, uncompressed, and combined, they form a set of executable instructions that implement one or more functions, which together may form a program as described herein.

[0068] In other examples, machine-readable instructions may be stored in a state that they can be read by processor circuits, but additional libraries (e.g., dynamic link libraries (DLLs)), software development kits (SDKs), application programming interfaces (APIs), etc., may be required to execute the instructions on a particular computing device or other device. In other examples, machine-readable instructions (e.g., stored settings, data inputs, recorded network addresses, etc.) may need to be configured before the machine-readable instructions and / or corresponding programs are executed in whole or in part. Accordingly, machine-readable media used herein may contain machine-readable instructions and / or programs regardless of the specific format or state of the machine-readable instructions and / or programs when stored or when stationary or in motion.

[0069] The machine-readable instructions described herein may be expressed in any past, present, or future instruction language, scripting language, programming language, etc. For example, machine-readable instructions may be expressed using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.

[0070] As described above, the exemplary processes in Figures 6 and 7 may be implemented using executable instructions (e.g., computer and / or machine-readable instructions) stored in non-temporary computer and / or machine-readable media such as hard disk drives, flash memory, read-only memory, compact disks, digital multipurpose disks, caches, random access memory, and / or other storage devices or storage disks where information is stored for any duration (e.g., long-term, permanent, short-term, for temporary buffering, and / or for caching information). As used herein, the term “non-temporary computer-readable media” includes any type of computer-readable storage device and / or storage disk and is explicitly defined to exclude the transmission medium by eliminating the propagation signal.

[0071] The terms “including” and “comprising” (and all their forms and tenses) are used herein as open-ended terms. Therefore, whenever a claim uses any form of “include” or “comprise” (e.g., including “comprises,” “includes,” “comprising,” “including,” “having,” etc.) as a preamble or within the description of any type of claim, it is understood that there may be further elements, terms, etc., without exceeding the scope of the corresponding claim or description. For example, when the term “at least” is used as a transition term in the preamble of a claim, it is considered open-ended, just as the terms “comprising” and “including” are open-ended. The term "and / or" when used in the form, for example, A, B and / or C, indicates any combination or subset of A, B, and C, such as (1) A only, (2) B only, (3) C only, (4) A and B, (5) A and C, (6) B and C, and (7) A, B and C. When used herein in the context of describing structures, components, items, objects and / or things, the term "at least one of A and B" is intended to indicate an implementation that includes (1) at least one A, (2) at least one B, and (3) either at least one A or at least one B. Similarly, when used herein in the context of describing structures, components, items, objects and / or things, the term "at least one of A or B" is intended to indicate an implementation that includes (1) at least one A, (2) at least one B, and (3) either at least one A or at least one B. Where used herein in a context describing the implementation or execution of a process, instruction, action, activity and / or step, the term “at least one of A and B” is intended to indicate an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B.Similarly, when used herein in a context describing the implementation or execution of a process, instruction, action, activity and / or step, the term “at least one of A or B” is intended to indicate an implementation comprising (1) at least one A, (2) at least one B, and (3) either at least one A and at least one B.

[0072] Singular references used herein (e.g., "a," "an," "first," "second," etc.) do not exclude plurals. Entities having the term "a" or "an," when used herein, refer to one or more of those entities. "a" (or "an"), "one or more," and "at least one" are interchangeable herein. Furthermore, actions of multiple means, elements, or methods, although individually listed, may be implemented, for example, by a single unit or processor. Additionally, individual features may be included in different examples or claims, but these may be combined in some cases, and inclusion in different examples or claims does not mean that the combination of features is unfeasible and / or unfavorable.

[0073] Figure 6 is a flowchart of machine-readable instructions 600 that may be executed to implement the exemplary core 200 in Figure 2 to process data. A reference is made to the exemplary core 200 in Figure 2, but any one of cores 110, 112, 114 and / or 116 can be implemented by the machine-readable instructions 600.

[0074] The machine-readable instruction 600 includes a block 602 in which an exemplary core 200 receives a request to process a data flow. For example, an application submits data (e.g., plaintext and keys, ciphertext, etc.) to the core 200 via a NIC (e.g., the first of the NICs 106 in Figure 1). In some examples, the core 200 receives a data flow from a load balancer (e.g., load balancer 118 in Figure 1).

[0075] An exemplary core 200 verifies the integrity of the data flow (block 604). For example, the behavior controller 202 performs an integrity check based on generating a CRC value and comparing it to the CRC value contained in the data flow.

[0076] The exemplary core 200 determines whether the verification was successful or not (block 606). For example, the operation controller 202 determines whether the comparison of two CRC values ​​shows a match or not.

[0077] If the exemplary core 200 determines that the comparison indicates a match (for example, if block 606 returns the value YES), the exemplary core 200 updates a status flag to indicate the success of the validation (block 608). For example, core 200 includes a status flag that is updated when data is acquired and cleared when data is sent. The status flag is used to indicate whether the data has passed the cyclic redundancy check.

[0078] The exemplary core 200 performs processing on the data in the data flow (block 610). For example, the operation controller 202 may perform AES in counter mode to encrypt plaintext data based on a counter value. In some examples, the operation controller 202 performs AES in counter mode to decrypt ciphertext data based on a counter value. The exemplary core 200 performs either forward and / or reverse tasks on the data. In some examples, the operation controller 202 outputs the processed data to the response controller 204.

[0079] The exemplary core 200 determines the processing core identifier (block 612). For example, the response controller 204 determines the index of core 200 and stores that index as the core ID in memory 206.

[0080] The exemplary core 200 generates an integrity check value (block 614). For example, the operation controller 202 generates a CRC value based on the output data (e.g., ciphertext, plaintext, etc.).

[0081] An exemplary core 200 concatenates data with status flags, a core identifier, and an integrity check value to generate a response descriptor (block 616). For example, a response controller 204 combines information corresponding to a processing job (e.g., encryption job, decryption job, etc.) into a response descriptor useful for subsequent processing of the data flow.

[0082] In an exemplary core 200, the response descriptor is stored (block 618). For example, memory 206 stores the response descriptor locally. In some examples, memory 206 stores the response descriptor in main system memory. In some examples, core 200 sends the response descriptor back to the application. Thus, the application may store the response descriptor.

[0083] Returning to block 606, if the exemplary core 200 determines that the comparison does not show a match (for example, block 606 returns the value NO), the exemplary core 200 updates the status flag to indicate validation failure (block 620). For example, the operation controller 202 and / or response controller 204 increment the status flag to a value indicating that the data did not pass the cyclic redundancy check. In some examples, when the integrity check fails, the core 200 cannot access the data in the dataflow, and therefore the data is not processed. For example, the core 200 validates the data before it becomes accessible to the job's data.

[0084] The exemplary core 200 waits for other requests (block 622). For example, core 200 repeats machine-readable instruction 600 in response to other requests for processing data.

[0085] Figure 7 is a flowchart of machine-readable instructions 700 that may be executed to implement the exemplary resource manager 300 of Figure 3. While a reference is made to the resource manager 300 of Figure 3, either resource manager 122a or 122b of Figure 1 may be implemented by the machine-readable instructions 700.

[0086] The machine-readable instruction 700 receives a request for an exemplary resource manager 300 to perform a reverse operation on the data flow. For example, the interface controller 302 receives a request submitted by a load balancer (e.g., load balancer 118) to retrieve data from storage where such data is encoded. The load balancer may then direct the request to the exemplary resource manager 300 to determine the optimal processing entity for decoding the data flow.

[0087] An exemplary resource manager 300 analyzes the response descriptor corresponding to the request (block 704). For example, the core decision controller 304 reads the processing information corresponding to the encryption of the data flow. In some examples, the response descriptor is mapped to a memory location. In other examples, the response descriptor is the data packet of the data flow. For example, the response descriptor for encrypted data is the ciphertext plus all the processing information associated with the ciphertext. In examples where the response descriptor does not correspond to encrypted data, the response descriptor is the data (e.g., compressed data, decompressed data, discrete Fourier transform data, inverse discrete Fourier transform data, etc.) plus the processing information associated with the data.

[0088] An exemplary resource manager 300 determines, based on analysis, the processing core identifier used to perform forward operations on the data flow (block 706). For example, the core determination controller 304 searches for a numerical value corresponding to the core index, core ID, and / or the processing entity that has encrypted, compressed, etc., the data flow in the response descriptor.

[0089] The exemplary resource manager 300 sends the data flow for reverse processing to a different processing core than the core used to perform forward operations on the data flow (block 708). For example, the interface controller 302 is notified by the core determination controller 304 which processing core is selected to provide and / or queue the data flow 120. The resource manager 300 operates to use two different cores for forward and reverse tasks in order to detect erroneous and faulty processing cores. Therefore, if core ID 0 is performing a forward task, the resource manager 300 does not send the data flow for a reverse task to core ID 0.

[0090] The exemplary resource manager 300 waits for other requests (block 710). For example, the machine-readable instruction 700 is repeated when the resource manager 300 receives other requests from the load balancer.

[0091] Figure 8 is a block diagram of an exemplary processor platform 800 configured to execute the instructions in Figures 6 and 7 in order to implement the multicore computing system 100 of Figure 1. The processor platform 800 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a mobile phone, a smartphone, a tablet such as iPad®), a personal digital assistant (PDA), an internet device, a DVD player, a digital video recorder, a Blu-ray player, a game console, a personal video recorder, a set-top box, or any other type of computing device.

[0092] The illustrated example processor platform 800 includes a processor 812. The illustrated example processor 812 is hardware. For example, the processor 812 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may also be a semiconductor-based (e.g., silicon-based) device. In this example, the multicore computing system 100 implements an exemplary processor 101 including a first core 110, a second core 112, a third core 114, a fourth core 116, a load balancer 118, a resource manager 122, a NIC 106, and an application 108, a core 200, an operation controller 202, a response controller 204, a resource manager 300, an interface controller 302, and a core determination controller 304.

[0093] The illustrated example processor 812 includes local memory 813 (e.g., a cache). In some examples, local memory 813 can be implemented by the exemplary memory 206 in Figure 2. The illustrated example processor 812 communicates with main memory 104, which includes volatile memory 814 and non-volatile memory 816, via bus 818. Volatile memory 814 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. Non-volatile memory 816 may be implemented by flash memory and / or any other desired type of memory device. Access to main memory 104, 814, and 816 is controlled by a memory controller.

[0094] The illustrated example processor platform 800 also includes an interface circuit 820. In some examples, the interface circuit 820 implements an exemplary NIC 106. The interface circuit 820 may be implemented by any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), a Bluetooth® interface, a Near Field Communication (NFC) interface, and / or a PCI Express interface.

[0095] In the illustrated example, one or more input devices 822 are connected to the interface circuit 820. The input devices 822 allow the user to input data and / or commands to the processor 812. The input devices can be implemented, for example, by audio sensors, microphones, cameras, keyboards, buttons, mice, touchscreens, trackpads, trackballs, IsoPoint and / or voice recognition systems.

[0096] One or more output devices 824 are also connected to the interface circuit 820 in the illustrated example. The output devices 824 can be implemented by, for example, display devices (e.g., light-emitting diodes (LEDs, liquid crystal diodes), organic light-emitting diodes (OLEDs), liquid crystal displays (LCDs), cathode ray tube displays (CRTs), IPS (in-place switching) displays, touchscreens, etc.), haptic output devices, and / or speakers. Thus, the interface circuit 820 in the illustrated example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0097] The interface circuit 820 in the illustrated example also includes communication devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate data exchange with external machines (e.g., any type of computing device) via the network 826. Communication can be carried out, for example, via Ethernet connections, digital subscriber line (DSL) connections, telephone line connections, coaxial cable systems, satellite systems, line-of-sight wireless systems, cellular telephone systems, etc.

[0098] The illustrated example processor platform 800 also includes one or more mass storage devices 828 for storing software and / or data. Examples of such mass storage devices 828 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, redundant array of independent disks (RAID), and digital versatile disk (DVD) drives.

[0099] The machine-executable instructions 600, 700, and together 832 in Figures 6 and 7 may be stored in a mass storage device 828, volatile memory 814, non-volatile memory 816, and / or a removable, non-temporary, computer-readable storage medium such as a CD or DVD.

[0100] Figure 9 shows a block diagram illustrating an exemplary software distribution platform 905 for distributing software such as the exemplary computer-readable instruction 832 in Figure 8 to a third party. The exemplary software distribution platform 905 may be implemented by any computer server, data facility, cloud service, etc., that can store the software and transmit it to other computing devices. The third party may be a customer of the entity that owns and / or operates the software distribution platform. For example, the entity that owns and / or operates the software distribution platform may be the developer, seller and / or licensor of the software such as the exemplary computer-readable instruction 832 in Figure 8. The third party may be a customer, user, retailer, OEM, etc., that purchases and / or licenses the software for use and / or resale and / or relicensing. In the illustrated example, the software distribution platform 905 includes one or more servers and one or more storage devices. The storage devices store the computer-readable instruction 832, which may correspond to the exemplary computer-readable instructions 600 and 700 in Figures 6 and 7, as described above. One or more servers of the exemplary software distribution platform 905 communicate with network 910, which may correspond to one or more of the Internet and / or exemplary networks 102 described above. In some examples, one or more servers respond to requests to send software to the requesting party as part of a commercial transaction. Payment for the distribution, sale, and / or licensing of the software may be handled by one or more servers of the software distribution platform and / or via third-party payments. The servers enable the purchaser and / or licensor to download computer-readable instructions 832 from the software distribution platform 905.For example, software that may correspond to the exemplary computer-readable instructions 600 and 700 in Figures 6 and 7 may be downloaded to an exemplary processor platform 800, which executes the computer-readable instructions 832 to implement a multicore computing system 100. In some examples, one or more servers of the software distribution platform 905 periodically provide, transmit and / or enforce updates to the software (e.g., the exemplary computer-readable instructions 832 in Figure 8) to ensure that improvements, patches, updates, etc., are delivered to and applied to the software on end-user devices.

[0101] From the above, it is recognized that exemplary methods, apparatus, and products are disclosed for controlling the processing location of forward and reverse task execution in order to identify defective processing locations. The examples disclosed herein ensure that a data flow is executed in reverse on a different processor core than when it is executed in forward, based on the tagging of processor core identifiers in the data flow. The disclosed methods, apparatus, and products improve the efficiency of using computing devices by enabling a troubleshooting mechanism that can immediately identify where a problem occurred based on processor core identifiers in the data flow. Thus, the disclosed methods, apparatus, and products cover one or more improvements in the functionality of a computer.

[0102] Exemplary methods, apparatus, systems, and products for controlling the execution of tasks in computing systems are disclosed herein. Further examples and combinations thereof include:

[0103] Example 1 includes a device comprising at least one storage device and at least one processor, wherein at least one processor receives a request to perform a reverse operation on a data flow that was previously converted during a forward operation, determines a first processor core that performed the forward operation, and executes an instruction to send the data flow to a second processor core to perform a reverse operation, provided that the data flow includes an identifier of the first processor core.

[0104] In Example 2, the object in Example 1 may optionally include a first request, a second request in which a first processor core receives a forward operation on the dataflow, verifies the integrity of the dataflow using periodic redundancy checks, and includes circuitry to update a state flag indicating the dataflow's validity based on the periodic redundancy checks.

[0105] In Example 3, the objects in Examples 1 and 2 may optionally include a circuit in which the first processor core performs a forward operation on the data flow, outputs the transformed data flow based on the forward operation, and generates an integrity check value corresponding to the transformed data flow, which will subsequently be used for periodic redundancy checks in the second processor core.

[0106] In Example 4, the objects in Examples 1-3 may optionally include a first processor core that outputs a transformed data flow based on a forward operation, determines an identifier for the first processor core corresponding to the index of the first processor core in at least one processor, and generates a response descriptor based on the concatenation of the transformed data flow with the identifier for the first processor core.

[0107] In Example 5, the objects in Examples 1-4 may optionally include the circuit adding a state flag to the response descriptor based on data flow verification and adding an integrity check value to the response descriptor for subsequent periodic redundancy checks in the second processor core.

[0108] In Example 6, the objects in Examples 1-5 may optionally include the circuit storing response descriptors in at least one storage device for subsequent access by at least one processor.

[0109] In Example 7, the objects of Examples 1-6 may optionally include a second processor core that outputs a transformed data flow based on a reverse operation, determines an identifier for the second processor core corresponding to the index of the second processor core in at least one processor, generates a response descriptor based on the concatenation of the transformed data flow with the identifier for the second processor core, and includes circuitry for storing the response descriptor in at least one storage device for subsequent access by at least one processor.

[0110] Example 8 includes a non-temporary, machine-readable storage medium that, when executed, causes one or more processors to obtain a request to perform a reverse operation on a data flow previously converted during a forward operation, to determine a first processor core that performed the forward operation, and to send the data flow to a second processor core to perform a reverse operation, the data flow containing an identifier of the first processor core.

[0111] In Example 9, the object in Example 8 may optionally include the following: the request is the first request, and the instruction, when executed, causes one or more processors to obtain a second request to perform a forward operation on the data flow, to verify the integrity of the data flow using periodic redundancy checks, and to update a status flag indicating the verification of the data flow based on the periodic redundancy checks.

[0112] In Example 10, the objects in Examples 8-9 may optionally include, when an instruction is executed, causing one or more processors to perform a forward operation on a data flow, to output a transformed data flow based on the forward operation, and to generate an integrity check value corresponding to the transformed data flow, which will subsequently be used for periodic redundancy checks in a second processor core.

[0113] In Example 11, the objects in Examples 8-10 may optionally include, when an instruction is executed, causing one or more processors to output a transformed data flow based on a forward operation, determine the identifier of a first processor core corresponding to the index of a first processor core in one or more processors, and generate a response descriptor based on the concatenation of the transformed data flow with the identifier of the first processor core.

[0114] In Example 12, the objects in Examples 8-11 may optionally include, when an instruction is executed, causing one or more processors to add a status flag to the response descriptor based on data flow verification, and to add a integrity check value to the response descriptor that will be used thereafter for periodic redundancy checks in a second processor core.

[0115] In Example 13, the objects in Examples 8-12 may optionally include, when an instruction is executed, causing one or more processors to store a response descriptor in at least one storage device for subsequent access by one or more processors.

[0116] In Example 14, the objects in Examples 8-13 may optionally include, when an instruction is executed, causing one or more processors to output a transformed data flow based on a reverse operation, to determine an identifier for a second processor core corresponding to an index of a second processor core in one or more processors, to generate a response descriptor based on the concatenation of the transformed data flow with the identifier for the second processor core, and to store the response descriptor in at least one storage device for subsequent access by one or more processors.

[0117] Example 15 includes an apparatus that includes means for obtaining a request to perform a reverse operation on a data flow previously transformed during a forward operation, means for determining a first processor core that performed the forward operation, wherein the data flow includes an identifier of the first processor core, and means for transmitting the data flow to a second processor core to perform a reverse operation.

[0118] In Example 16, the object of Example 15 may optionally include means for controlling the first processor core to receive a second request for a forward operation on the dataflow, to verify the integrity of the dataflow using periodic redundancy checks, and to update a state flag to indicate the verification of the dataflow based on the periodic redundancy checks.

[0119] In Example 17, the objects in Examples 15-16 may optionally include means for controlling the first processor core to perform a forward operation on the data flow, output a transformed data flow based on the forward operation, and generate integrity check values ​​corresponding to the transformed data flow, which will subsequently be used for periodic redundancy checks in the second processor core.

[0120] In Example 18, the objects in Examples 15-17 may optionally include a first processor core that includes means for outputting a transformed data flow based on a forward operation, and means for determining an identifier of the first processor core corresponding to an index of the first processor core in at least one processor, and for generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the first processor core.

[0121] In Example 19, the objects in Examples 15-18 may optionally include a means for generation that adds a state flag to the response descriptor based on data flow verification and adds a integrity check value to the response descriptor that will be used thereafter for periodic redundancy checks in a second processor core.

[0122] In Example 20, the objects in Examples 15-19 may optionally include means for storing response descriptors in at least one storage device for subsequent access by at least one processor.

[0123] In Example 21, the objects of Examples 15-20 may optionally include a second processor core that includes means for outputting a transformed data flow based on a reverse operation; means for determining an identifier of the second processor core corresponding to an index of the second processor core in at least one processor and generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the second processor core; and means for storing the response descriptor in at least one storage device for subsequent access by at least one processor.

[0124] Example 22 includes an interface controller for receiving requests to perform a reverse operation on a data flow previously converted during a forward operation, and a core determination controller for determining a first processor core that performed the forward operation, the data flow containing an identifier of the first processor core, and the core determination controller for determining to send the data flow to a second processor core to perform a reverse operation.

[0125] In Example 23, the object in Example 22 may optionally include an operation controller for which the request is a first request, a first processor core receives a second request to perform a forward operation on the dataflow, verifies the integrity of the dataflow using periodic redundancy checks, and updates a state flag to indicate the dataflow's validity based on the periodic redundancy checks.

[0126] In Example 24, the objects in Examples 22-23 may optionally include an operation controller for performing forward operations on the data flow, outputting the transformed data flow based on the forward operations, and generating integrity check values ​​corresponding to the transformed data flow, which will subsequently be used for periodic redundancy checks in a second processor core.

[0127] In Example 25, the objects in Examples 22-24 may optionally include an operation controller for outputting a transformed data flow based on a forward operation, and a response controller for determining an identifier for a first processor core corresponding to an index of a first processor core in at least one processor, and generating a response descriptor based on the concatenation of the transformed data flow with the identifier for the first processor core.

[0128] In Example 26, the objects in Examples 22-25 may optionally include the response controller adding a status flag to the response descriptor based on data flow verification and adding an integrity check value to the response descriptor for subsequent periodic redundancy checks in the second processor core.

[0129] In Example 27, the objects in Examples 22-26 may optionally include memory for storing response descriptors in at least one storage device for subsequent access by at least one processor.

[0130] In Example 28, the objects in Examples 22-27 may optionally include an operation controller for outputting the transformed data flow based on the reverse operation; a response controller for determining the identifier of a second processor core corresponding to the index of a second processor core in at least one processor and generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the second processor core; and memory for storing the response descriptor in at least one storage device for subsequent access by at least one processor.

[0131] Example 29 includes a method comprising the steps of: obtaining a request to perform a reverse operation on a data flow that was previously transformed during a forward operation; determining a first processor core that performed the forward operation, wherein the data flow includes an identifier of the first processor core; and sending the data flow to a second processor core to perform a reverse operation.

[0132] In Example 30, the object of Example 29 may optionally further include the steps of: the request being a first request; the method being a step of obtaining a second request to perform a forward operation on a data flow; verifying the integrity of the data flow using periodic redundancy checks; and updating a status flag to indicate the verification of the data flow based on the periodic redundancy checks.

[0133] In Example 31, the objects in Examples 29-30 may optionally include the steps of performing a forward operation on the data flow, outputting the transformed data flow based on the forward operation, and generating integrity check values ​​corresponding to the transformed data flow, which will be used thereafter for periodic redundancy checks in a second processor core.

[0134] In Example 32, the objects in Examples 29-31 may optionally include the steps of: outputting a transformed data flow based on a forward operation; determining the identifier of a first processor core corresponding to the index of a first processor core in at least one processor; and generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the first processor core.

[0135] In Example 33, the objects in Examples 29-32 may optionally include the steps of adding a status flag to the response descriptor based on data flow verification and adding an integrity check value to the response descriptor to be used thereafter for periodic redundancy checks in the second processor core.

[0136] In Example 34, the objects in Examples 29-33 may optionally include the step of storing a response descriptor in a storage device for subsequent access by at least one processor.

[0137] In Example 35, the objects in Examples 29-34 may optionally include the steps of: outputting a transformed data flow based on a reverse operation; determining the identifier of a second processor core corresponding to an index of a second processor core in at least one processor; generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the second processor core; and storing the response descriptor in a storage device for subsequent access by at least one processor.

[0138] Example 36 is an edge computing gateway that includes processing circuitry for performing any of Examples 29-35.

[0139] Example 37 is a base station that includes a network interface card and processing circuitry for performing any of the actions in Examples 29-35.

[0140] Example 38 is a computer-readable medium containing instructions for performing any of Examples 29-35.

[0141] While certain exemplary methods, apparatuses, and products are disclosed herein, the scope of this patent is not limited thereto. In contrast, this patent covers all methods, apparatuses, and products that fall within the claims of this patent.

[0142] The following claims are incorporated by reference into this detailed description, and each claim stands alone as a distinct embodiment of the present disclosure.

Claims

1. A device comprising at least one storage device and at least one processor, The aforementioned at least one processor comprises at least, We receive a request to perform a reverse operation on a data flow that was previously transformed during a forward operation. Determine the first processor core that performed the forward operation, and the data flow includes the identifier of the first processor core. The data flow is sent to a second processor core in order to perform the aforementioned reverse operation. A device that executes instructions for a specific purpose.

2. The above request is a first request, and the first processor core is A second request is obtained to perform the forward operation on the aforementioned data flow, The integrity of the data flow is verified using periodic redundancy checks. Based on the periodic redundancy check, update the status flag to indicate the verification of the data flow. The apparatus according to claim 1, including a circuit for that purpose.

3. The first processor core is Perform the forward operation on the aforementioned data flow, Based on the aforementioned forward operation, the transformed data flow is output. Generate an integrity check value that corresponds to the converted data flow and will be used thereafter for periodic redundancy checks in the second processor core. The apparatus according to claim 1, including a circuit for that purpose.

4. The first processor core is Based on the aforementioned forward operation, the transformed data flow is output. Determine the identifier of the first processor core corresponding to the index of the first processor core in the at least one processor, A response descriptor is generated based on the concatenation of the transformed data flow with the identifier of the first processor core. The apparatus according to claim 1, including a circuit for that purpose.

5. The apparatus according to claim 4, wherein the circuit adds a state flag to the response descriptor based on the verification of the data flow, and adds a integrity check value to the response descriptor to be used thereafter for periodic redundancy checks in the second processor core.

6. The apparatus according to claim 4 or 5, wherein the circuit stores the response descriptor in the at least one storage device for subsequent access by the at least one processor.

7. The second processor core is, Based on the aforementioned reverse operation, the transformed data flow is output. Determine the identifier of the second processor core corresponding to the index of the second processor core in the at least one processor, A response descriptor is generated based on the concatenation of the transformed data flow with the identifier of the second processor core, The response descriptor is stored in the at least one storage device for subsequent access by the at least one processor. The apparatus according to claim 1, including a circuit for that purpose.

8. When executed by at least one processor, at least, To obtain a request to perform a reverse operation on a data flow that was previously transformed during a forward operation, The first processor core that performed the forward operation is determined, and the data flow includes the identifier of the first processor core. To perform the aforementioned reverse operation, the data flow is sent to the second processor core. A computer-readable storage device or storage disk containing instructions.

9. The aforementioned request is a first request, and when the instruction is executed, it results in at least one processor receiving the following instructions: A second request is obtained to perform the forward operation on the aforementioned data flow. Periodic redundancy checks are used to verify the integrity of the data flow. The computer-readable storage device or storage disk according to claim 8, which updates a status flag to indicate verification of the data flow based on the periodic redundancy check.

10. When the instruction is executed, it causes at least one processor to: Perform the forward operation on the aforementioned data flow, Based on the aforementioned forward operation, the transformed data flow is output. The computer-readable storage device or storage disk according to claim 8, which generates integrity check values ​​to be used thereafter for periodic redundancy checks in the second processor core, corresponding to the converted data flow.

11. When the instruction is executed, it causes at least one processor to: Based on the aforementioned forward operation, the transformed data flow is output. Determine the identifier of the first processor core corresponding to the index of the first processor core in one or more processors. The computer-readable storage device or storage disk according to claim 8, which generates a response descriptor based on the concatenation of the converted data flow with the identifier of the first processor core.

12. When the instruction is executed, it causes at least one processor to: Based on the verification of the data flow, a status flag is added to the response descriptor. The computer-readable storage device or storage disk according to claim 11, wherein a integrity check value to be subsequently used for periodic redundancy checks in the second processor core is added to the response descriptor.

13. When the instruction is executed, it causes at least one processor to: The computer-readable storage device or storage disk according to claim 11 or 12, wherein the response descriptor is stored in at least one storage device for subsequent access by the one or more processors.

14. When the instruction is executed, it causes at least one processor to: Based on the aforementioned reverse operation, the transformed data flow is output. Determine the identifier of the second processor core corresponding to the index of the second processor core in one or more processors, A response descriptor is generated based on the concatenation of the transformed data flow with the identifier of the second processor core. The computer-readable storage device or storage disk according to claim 8, wherein the response descriptor is stored in at least one storage device for subsequent access by the one or more processors.

15. Means for obtaining a request to perform a reverse operation on a data flow that was previously transformed during a forward operation, Means for determining the first processor core that performed the forward operation, wherein the data flow includes an identifier for the first processor core, Means for transmitting the data flow to a second processor core in order to perform the aforementioned reverse operation, A device that includes this.

16. The above request is a first request, and the first processor core is A second request is obtained to perform the forward operation on the aforementioned data flow, The integrity of the data flow is verified using periodic redundancy checks. Based on the periodic redundancy check, update the status flag to indicate the verification of the data flow. The apparatus according to claim 15, comprising means for controlling in that manner.

17. The first processor core is Perform the forward operation on the aforementioned data flow, Based on the aforementioned forward operation, the transformed data flow is output. Generate an integrity check value that corresponds to the converted data flow and will be used thereafter for periodic redundancy checks in the second processor core. The apparatus according to claim 15, comprising means for controlling in that manner.

18. The first processor core is Means for outputting the transformed data flow based on the aforementioned forward operation, Means for determining the identifier of the first processor core corresponding to the index of the first processor core in at least one processor, and for generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the first processor core. The apparatus according to claim 15, including the apparatus described in claim 15.

19. The means for generating the above is, Based on the verification of the data flow, a status flag is added to the response descriptor. The apparatus according to claim 18, wherein a integrity check value to be subsequently used for periodic redundancy checks in the second processor core is added to the response descriptor.

20. The apparatus according to claim 18 or 19, further comprising means for storing the response descriptor in at least one storage device for subsequent access by the at least one processor.

21. The second processor core is, Means for outputting the transformed data flow based on the aforementioned reverse operation, Means for determining an identifier of the second processor core corresponding to an index of the second processor core in at least one processor, and for generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the second processor core, Means for storing the response descriptor in at least one storage device for subsequent access by at least one processor The apparatus according to claim 15, including the apparatus described in claim 15.

22. An interface controller for receiving requests to perform reverse operations on data flows that were previously transformed during forward operations, A core determination controller for determining the first processor core that performed the forward operation, wherein the data flow includes an identifier for the first processor core, and a core determination controller for determining to send the data flow to a second processor core to perform the reverse operation. A device that includes this.

23. The first processor core is An operation controller for outputting the converted data flow based on the aforementioned forward operation, A response controller for determining the identifier of the first processor core corresponding to the index of the first processor core in at least one processor, and for generating a response descriptor based on the concatenation of the transformed data flow with the identifier of the first processor core. The apparatus according to claim 22, including the following:

24. The response controller is Based on the verification of the data flow, a status flag is added to the response descriptor. The apparatus according to claim 23, wherein a integrity check value to be subsequently used for periodic redundancy checks in the second processor core is added to the response descriptor.

25. The apparatus according to claim 23 or 24, further comprising memory for storing the response descriptor in at least one storage device for subsequent access by the at least one processor.

Images