Request processing method and apparatus, electronic device, and storage medium

Abstract

The application provides a request processing method and device, electronic equipment and storage medium, and belongs to the technical field of computers. The method comprises the following steps: receiving a first prefetch request from a source end; writing the first prefetch request into a prediction queue, the prediction queue being used for storing prefetch requests from multiple source ends, and the prediction queue also being used for sending the prefetch requests to a destination end based on the sequence identifiers of each prefetch request; configuring the sequence identifier of the first prefetch request as a first numerical value, the first numerical value being equal to the number of stored prefetch requests in the prediction queue when the first prefetch request is written; and if a second prefetch request in the prediction queue is discarded, updating the sequence identifier of a third prefetch request, the third prefetch request being a prefetch request written into the prediction queue after the second prefetch request. By configuring and updating the sequence identifiers of the prefetch requests in the prediction queue, the ordered storage and sending of the multiple-source-end prefetch requests are realized, and the continuity and execution efficiency of the prefetch request processing are ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a request processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Currently, chip systems have increasingly higher performance requirements. To reduce the latency of request execution, the source end typically predicts possible data access behaviors, generates prefetch requests, and sends them to the destination end. This allows the destination end to prepare data in advance, so that when the actual request arrives, the data is already ready, thereby eliminating or reducing waiting latency and improving performance.

[0003] Typically, a queue records prefetch requests originating from the source. The logical order is maintained by migrating requests across different physical layers. Prefetch requests are read from the queue sequentially and sent to the destination. However, in scenarios with multiple sources, the commonly used queue structure struggles to quickly migrate prefetch requests, easily leading to request confusion, backlog, or accidental deletion. This makes it difficult to meet the complex processing requirements of prefetch requests and impacts the efficiency of prefetching operations. Summary of the Invention

[0004] This application provides a request processing method, apparatus, electronic device, and storage medium, which can meet the complex processing requirements of prefetch requests and ensure the continuity and execution efficiency of prefetch request processing. The technical solution is as follows: On the one hand, a request processing method is provided, the method comprising: Receive a first prefetch request from the source end, the first prefetch request being predicted by the source end, the first prefetch request being used to notify the destination end in advance to complete data loading; The first prefetch request is written into the prediction queue, which is used to store prefetch requests from multiple sources and to send prefetch requests to the destination based on the sequence identifier of each prefetch request. Configure the sequence identifier of the first prefetch request to a first value, which is equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written. If the second prefetch request in the prediction queue is discarded, the order identifier of the third prefetch request is updated. The third prefetch request is the prefetch request written into the prediction queue after the second prefetch request.

[0005] In some embodiments, the prediction queue includes multiple storage layers, each storage layer being used to store a single prefetch request; The first value is the number of storage layers occupied when the first prefetch request is written to the prediction queue, and the occupied storage layer is the storage layer in the prediction queue that currently stores the prefetch request.

[0006] In some embodiments, the method further includes: Simultaneously receive a fourth prefetch request and a fifth prefetch request, wherein the fourth prefetch request comes from the first source and the fifth prefetch request comes from the second source; Based on the preset priorities of the first source and the second source, the sequence identifier of the fourth prefetch request is configured as a second value, and the sequence identifier of the fifth prefetch request is configured as a third value. Wherein, if the preset priority of the first source end is higher than the preset priority of the second source end, then the second value is less than the third value.

[0007] In some embodiments, the method further includes: If the received data access request matches the second prefetch request, the second prefetch request is discarded. The data access request is used to notify the destination to perform data processing operations.

[0008] In some embodiments, discarding the second prefetch request includes: If the second prefetch request has been sent to the corresponding destination and remains in the prediction queue after being sent to the corresponding destination, then the second prefetch request is discarded. If the second prefetch request is not sent to the corresponding destination, the second prefetch request is discarded, and the destination is notified to prepare the data corresponding to the data access request in advance.

[0009] In some embodiments, the number of the second prefetch request and the third prefetch request is at least one; The update of the order identifier of the third prefetch request includes: For each third prefetch request, a first target value is subtracted from the sequence identifier of the third prefetch request, where the first target value is the number of second prefetch requests written before the third prefetch request.

[0010] In some embodiments, the number of the second prefetch requests is at least one; The method further includes: If the value of the read pointer is not equal to the sequence identifier of each second prefetch request, the value of the read pointer is subtracted from the second target value. The read pointer is used to read prefetch requests from the queue. The second target value is the number of target prefetch requests in at least one second prefetch request. The sequence identifier of the target prefetch request is less than the value of the read pointer.

[0011] In some embodiments, the method further includes: Once the number of prefetch requests currently stored in the prediction queue reaches a preset threshold, if the second prefetch request is written before other prefetch requests in the prediction queue, the second prefetch request is discarded.

[0012] In some embodiments, the number of the second prefetch request and the third prefetch request is at least one; The update of the order identifier of the third prefetch request includes: Subtract the number of second prefetch requests from the sequence identifier of each third prefetch request.

[0013] In some embodiments, the number of the second prefetch requests is at least one; The method further includes: If the value of the read pointer is greater than the sequence identifier of each second prefetch request, the value of the read pointer is reduced by the number of the second prefetch requests. The read pointer is used to read prefetch requests from the queue. If the value of the read pointer is equal to the sequence identifier of any second prefetch request, the read pointer is cleared to zero.

[0014] In some embodiments, the method further includes: The prefetch request whose sequence identifier is equal to the value of the read pointer is sent to the corresponding destination, and the value of the read pointer is adjusted to send the remaining prefetch requests in the prediction queue. The read pointer is used to read the prefetch request from the queue.

[0015] On the other hand, a request processing apparatus is provided, the apparatus comprising: The receiving module is configured to receive a first prefetch request from the source end, the first prefetch request being predicted by the source end, and the first prefetch request being used to notify the destination end in advance to complete data loading; The writing module is used to write the first prefetch request into the prediction queue, the prediction queue is used to store prefetch requests from multiple source ends, and the prediction queue is also used to send the prefetch request to the destination end based on the sequence identifier of each prefetch request. The configuration module is configured to set the sequence identifier of the first prefetch request to a first value, the first value being equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written. An update module is used to update the sequence identifier of a third prefetch request if the second prefetch request in the prediction queue is discarded. The third prefetch request is a prefetch request written into the prediction queue after the second prefetch request.

[0016] In some embodiments, the prediction queue includes multiple storage layers, each storage layer being used to store a single prefetch request; The first value is the number of storage layers occupied when the first prefetch request is written to the prediction queue, and the occupied storage layer is the storage layer in the prediction queue that currently stores the prefetch request.

[0017] In some embodiments, the receiving module is further configured to simultaneously receive a fourth prefetch request and a fifth prefetch request, wherein the fourth prefetch request originates from a first source and the fifth prefetch request originates from a second source. The configuration module is further configured to configure the sequence identifier of the fourth prefetch request as a second value and the sequence identifier of the fifth prefetch request as a third value based on the preset priorities of the first source end and the second source end; wherein, if the preset priority of the first source end is higher than the preset priority of the second source end, the second value is less than the third value.

[0018] In some embodiments, the apparatus further includes: The discard module is used to discard the second prefetch request if the received data access request matches the second prefetch request, the data access request being used to notify the destination to perform data processing operations.

[0019] In some embodiments, the discarding module is further configured to discard the second prefetch request if the second prefetch request has been sent to the corresponding destination and the second prefetch request is retained in the prediction queue after being sent to the corresponding destination; and if the second prefetch request has not been sent to the corresponding destination, discard the second prefetch request and notify the destination to prepare the data corresponding to the data access request in advance.

[0020] In some embodiments, the number of the second prefetch request and the third prefetch request is at least one; The update module is configured to subtract a first target value from the sequence identifier of each third prefetch request, whereby the first target value is the number of second prefetch requests written before the third prefetch request.

[0021] In some embodiments, the number of the second prefetch requests is at least one; The update module is further configured to subtract a second target value from the value of the read pointer if the value of the read pointer is not equal to the sequence identifier of each second prefetch request. The read pointer is used to read prefetch requests from the queue, and the second target value is the number of target prefetch requests in at least one second prefetch request. The sequence identifier of the target prefetch request is less than the value of the read pointer.

[0022] In some embodiments, the discarding module is further configured to discard the second prefetch request if the second prefetch request is written earlier than other prefetch requests in the prediction queue after the number of prefetch requests currently stored in the prediction queue reaches a preset threshold.

[0023] In some embodiments, the number of the second prefetch request and the third prefetch request is at least one; The update module is further configured to subtract the number of the second prefetch requests from the sequence identifier of each third prefetch request.

[0024] In some embodiments, the number of the second prefetch requests is at least one; The update module is further configured to, if the value of the read pointer is greater than the sequence identifier of each second prefetch request, subtract the number of the second prefetch requests from the value of the read pointer, the read pointer being used to read prefetch requests from the queue; and if the value of the read pointer is equal to the sequence identifier of any second prefetch request, clear the read pointer to zero.

[0025] In some embodiments, the apparatus further includes: The sending module is used to send prefetch requests whose sequence identifier is equal to the value of the read pointer to the corresponding destination, and adjust the value of the read pointer to send the remaining prefetch requests in the prediction queue. The read pointer is used to read the prefetch requests from the queue.

[0026] On the other hand, a chip is provided that includes programmable logic circuitry configured to enable the chip to implement the request processing method in the embodiments of this application.

[0027] On the other hand, an electronic device is provided, the electronic device including a chip, wherein programmable logic circuitry in the chip is configured to enable the electronic device to implement the request processing method in the embodiments of this application.

[0028] On the other hand, an electronic device is provided, comprising a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the request processing method in the embodiments of this application.

[0029] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the request processing method in the embodiments of this application.

[0030] On the other hand, a computer program product is provided, including a computer program that is executed by a processor to implement the request processing method in the embodiments of this application.

[0031] This application provides a request processing method that, by allocating and updating a sequence identifier in real time for each prefetch request written to the prediction queue, achieves ordered storage and sending of prefetch requests in multi-source scenarios. In particular, when a request is dropped, the sequence identifier of each subsequent prefetch request is dynamically updated, avoiding the disorder of the queue request logic order caused by request drop-off. This solves the problem of disordered request management caused by untimely migration operations in multi-source scenarios, meets the complex queue processing requirements of prefetching work, ensures the continuity of prefetch request processing, and guarantees the execution efficiency of prefetching work. Attached Figure Description

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

[0033] Figure 1 This is a schematic diagram of an implementation environment provided according to an embodiment of this application; Figure 2 This is a schematic diagram of a request processing flow provided according to an embodiment of this application; Figure 3 This is a flowchart of a request processing method provided according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating the updating of the sequence identifier when a prefetch request is discarded after a match, according to an embodiment of this application. Figure 5 This is a schematic diagram illustrating the updating of the sequence identifier in another case where a prefetch request is discarded after matching, according to an embodiment of this application. Figure 6 This is a schematic diagram illustrating the updating of the read pointer in the case of discarding a prefetch request after a match, according to an embodiment of this application. Figure 7 This is a schematic diagram illustrating the updating of the sequence identifier when a prefetch request is discarded after the queue is full, according to an embodiment of this application. Figure 8 This is a schematic diagram illustrating the updating of the read pointer when a prefetch request is discarded after the queue is full, according to an embodiment of this application. Figure 9 This is a block diagram of a request processing apparatus according to an embodiment of this application; Figure 10 This is a schematic diagram of a chip structure provided according to an embodiment of this application; Figure 11This is a schematic diagram of the structure of an electronic device according to an embodiment of this application; Figure 12 This is a schematic diagram of the structure of another electronic device provided according to an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0035] In this application, the terms "first", "second", etc. are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is there any limitation on the quantity or execution order.

[0036] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0037] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application are authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, prefetch requests and data access requests involved in this application were obtained with full authorization.

[0038] Figure 1 This is a schematic diagram of an implementation environment provided according to an embodiment of this application. See also... Figure 1 The implementation environment includes a source 101, a destination 102, and a chip 103. The source 101, the destination 102, and the chip 103 can be directly or indirectly connected via wired (such as on-chip bus, dedicated interconnect interface, etc.) or wireless communication methods, and this application does not impose any restrictions.

[0039] The number of source terminals 101 and destination terminals 102 is at least one, enabling scenarios where multiple source terminals concurrently submit prefetch requests. Both source terminals 101 and destination terminals 102 can be implemented as processor cores, hardware functional modules, storage controllers, dedicated acceleration units, etc., and this application does not impose any limitations. Source terminals 101, destination terminals 102, and chip 103 can be integrated into the same electronic device or located in different electronic devices, and this application does not impose any limitations. Electronic devices include terminals and servers, etc. Furthermore, chip 103 can be implemented as a processing module executing this application; this processing module can be integrated into the chip or deployed independently, and this application does not impose any limitations.

[0040] In this process, source terminal 101 predicts potential data access behaviors, generates and sends prefetch requests to chip 103 to notify destination terminal 102 in advance to complete data loading preparation. Chip 103 is the main body executing the request processing method of this application. Chip 103 is configured with a prediction queue, which stores prefetch requests from one or more source terminals 101 and sends prefetch requests to destination terminal 102 according to preset rules. Destination terminal 102 responds to prefetch requests and actual data access requests (or execution requests) to perform corresponding data processing operations.

[0041] In addition, when there are multiple source terminals 101 and multiple destination terminals 102 in the implementation environment, the prefetch request generated by the source terminal 101 can carry a destination terminal identifier, which is used to uniquely identify the corresponding destination terminal 102. After the chip 103 reads the prefetch request from the prediction queue, it can accurately send the prefetch request to the corresponding destination terminal 102 based on the destination terminal identifier, avoiding misalignment of prefetch request sending, thereby ensuring accurate distribution of prefetch requests in multi-source and multi-destination scenarios.

[0042] It should be noted that the above implementation environment is only an example, and the method provided in this application embodiment can also be implemented in other environments, which is not limited in this application embodiment.

[0043] Figure 2 This is a flowchart of a request processing method provided according to an embodiment of this application, illustrated using a chip as an example. See [link to flowchart]. Figure 2 The method includes the following steps: 201. Receive a first prefetch request from the source end. The first prefetch request is predicted by the source end and is used to notify the destination end in advance that data loading is complete.

[0044] In this embodiment, the source end refers to the device or module that generates and sends the prefetch request; it is the initiator of the data request and can predict possible data access behaviors and output the prefetch request. The destination end refers to the device or module that receives the prefetch request and executes data loading; it is the executor of the prefetch request and can complete data preparation in advance to respond to subsequent real requests. The first prefetch request is a prefetch request to be processed predicted and generated by the source end; it is a predictive data loading notification instruction. Data loading refers to the operation by which the destination end reads the target data from the storage medium into a specified cache or processing area according to the prefetch request, in preparation for subsequent real data processing.

[0045] 202. Write the first prefetch request into the prediction queue. The prediction queue is used to store prefetch requests from multiple sources. The prediction queue is also used to send prefetch requests to the destination based on the sequence identifier of each prefetch request.

[0046] In this embodiment, the prediction queue refers to a storage structure for storing prefetch requests from multiple sources, used to store, schedule, and send prefetch requests based on a sequence identifier. The sequence identifier is a numerical identifier configured for each prefetch request, used to characterize the logical order of the prefetch requests in the prediction queue.

[0047] In some embodiments, the prediction queue includes multiple storage layers (also called queue layers), each used to store a single prefetch request. Exemplarily, fixed layer numbers are assigned to each storage layer in the prediction queue to distinguish different storage locations. Storage layers that do not store prefetch requests are considered free layers and can be used to store prefetch requests. When multiple free layers exist in the prediction queue, a first prefetch request can be written to one of these free layers; the embodiments of this application do not limit the method of determining the free layer.

[0048] For example, the usage status of the storage layer is characterized by whether or not a sequence identifier is stored. Writing a sequence identifier to the storage layer indicates it is in use, while not writing a sequence identifier indicates it is in use. It should be noted that this is merely an example; a dedicated identifier bit can also be used to characterize the usage status of the storage layer, which will not be elaborated upon here.

[0049] 203. Configure the sequence identifier of the first prefetch request to a first value, which is equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written.

[0050] In this embodiment, the first value refers to the specific value of the sequence identifier configured for the first prefetch request, and the magnitude of the first value is related to the storage state of the queue when the first prefetch request is written. In other words, the first value is the number of storage layers occupied when the first prefetch request is written to the prediction queue. The occupied storage layers are the storage layers in the prediction queue that currently store prefetch requests, that is, the total number of storage layers currently in use.

[0051] For example, if a prefetch request is received when the prediction queue is empty, the sequence identifier of the prefetch request is set to 0 when it is written to the prediction queue. In this case, if another prefetch request is received, the sequence identifier of the other prefetch request is set to 1 when it is written to the queue, and so on. That is, when the first prefetch request is written to an empty queue, the sequence identifier is configured to 0; subsequent prefetch requests are assigned their corresponding sequence identifiers by accumulating the total number of layers used.

[0052] In this way, the physical storage layer of the prediction queue is bound to the sequence identifier, giving the sequence identifier a unique mapping attribute to the physical storage layer. This allows the configuration and updating of the sequence identifier to correspond to the physical storage state of the queue, simplifying the configuration and updating process of the sequence identifier and improving the efficiency and accuracy of identifier management.

[0053] This example uses a default initial value of 0, but this is not a limitation. The first value can also be determined by combining the preset default initial value and the storage state when the prefetch request is written to the queue. For example, if the default initial value is set to 10, the first value is the default initial value (i.e., 10) plus the number of prefetch requests stored in the prediction queue when the prefetch request is written.

[0054] 204. If the second prefetch request in the prediction queue is discarded, update the order identifier of the third prefetch request. The third prefetch request is the prefetch request written into the prediction queue after the second prefetch request.

[0055] In this embodiment, the second prefetch request refers to a prefetch request in the prediction queue that is determined to be discarded. Discarding here means removing the second prefetch request from the prediction queue. The third prefetch request refers to a prefetch request in the prediction queue whose original sequence identifier was greater than that of the second prefetch request, and whose sequence identifier needs to be adjusted due to the discarding of the second prefetch request. There are at least one second prefetch request and at least one third prefetch request. The update here refers to the operation of adjusting the original sequence identifier value of each third prefetch request based on the discarding operation of at least one second prefetch request, so as to ensure the continuity of the logical order of requests in the prediction queue.

[0056] This application provides a request processing method that, by allocating and updating a sequence identifier in real time for each prefetch request written to the prediction queue, achieves ordered storage and transmission of prefetch requests in multi-source scenarios. In particular, when a request is discarded, the sequence identifier of each subsequent prefetch request is dynamically updated, avoiding the disorder of the queue request logic order caused by request discarding. This solves the problem of disordered request management caused by untimely migration operations in multi-source scenarios, meets the complex queue processing requirements of prefetching work, ensures the continuity of prefetch request processing, and guarantees the execution efficiency of prefetching work.

[0057] Based on the above brief introduction, more detailed methods and steps are provided; please refer to [link / reference]. Figure 3 As shown, Figure 3 This is a flowchart of another request processing method provided according to an embodiment of this application. Taking the application of this method to a chip as an example, the method includes the following steps: 301. Receive a first prefetch request from the source end. The first prefetch request is predicted by the source end and is used to notify the destination end in advance that data loading is complete.

[0058] In the embodiments of this application, this step is the same as step 201, and will not be described again here.

[0059] 302. Write the first prefetch request into the prediction queue. The prediction queue is used to store prefetch requests from multiple sources. The prediction queue is also used to send prefetch requests to the destination based on the sequence identifier of each prefetch request.

[0060] In this embodiment of the application, this step is the same as step 202 above, and will not be described again here.

[0061] 303. Configure the sequence identifier of the first prefetch request to a first value, which is equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written.

[0062] In this embodiment of the application, this step is the same as step 203 above, and will not be described again here.

[0063] In some embodiments, when prefetch requests are written simultaneously from multiple sources, different cumulative sequence identifiers are assigned to each prefetch request according to a preset rule to distinguish between the prefetch requests. For example, the prediction rule refers to assigning sequence identifiers according to a preset priority of each source, with higher preset priorities determining the sequence identifier value first, and the sequence identifiers following sequentially.

[0064] Accordingly, a fourth prefetch request and a fifth prefetch request are received simultaneously. The fourth prefetch request originates from the first source, and the fifth prefetch request originates from the second source. When these two prefetch requests are written to the prediction queue, based on the preset priorities of the first and second source sources, the sequence identifier of the fourth prefetch request is configured with a second value, and the sequence identifier of the fifth prefetch request is configured with a third value. If the preset priority of the first source is higher than that of the second source, then the second value is less than the third value. For example, the second value is 1, and the second value is 2 when writing.

[0065] In this way, different order identifiers are configured for multiple source requests received simultaneously based on the preset priority of the source end. This allows the prefetch requests of high-priority source ends to have a higher sending order in the queue and be sent to the destination end first. This can meet the differentiated service needs of different source ends in the chip system and is highly flexible.

[0066] In addition, the allocation rules for sequence identifiers include, but are not limited to, allocation methods based on source priority. Other reasonable allocation strategies may also be adopted, as long as multiple prefetch requests written at the same time can be distinguished by different sequence identifiers, without limiting the specific allocation method.

[0067] Prefetch requests already stored in the prediction queue will be discarded under certain conditions. The following describes two scenarios for discarding prefetch requests: discarding after matching and discarding after the queue is full. See steps 304 and 306 below. After a prefetch request in the prediction queue is discarded, the order identifiers of some remaining prefetch requests will be updated. See steps 305 and 307 below.

[0068] 304. If the received data access request matches the second prefetch request in the prediction queue, discard the second prefetch request. The data access request is used to notify the destination to perform data processing operations.

[0069] In this embodiment of the application, this is a case of discarding the prefetch request after matching. Matching means that the data required for the data access request can be obtained in advance through the prefetch request, such as the destination, access address and other information in the prefetch request and the data access request being consistent.

[0070] In this way, prefetch requests in the prediction queue can be cleared in a timely manner, avoiding invalid retention and repeated execution of prefetch requests, reducing the storage resource occupation of the prediction queue, preventing invalid prefetch requests from causing a backlog for the sending of subsequent valid requests, and improving the storage and processing efficiency of the queue.

[0071] In some embodiments, a prefetch request is read from the queue based on the value of the read pointer, i.e., the prefetch request is sent to the destination. The prefetch request is not cleared after being sent to the destination but remains cached in the prediction queue, waiting to be matched with actual data access requests. Thus, a prefetch request discarded after matching may be a prefetch request that has already been sent to the destination or a prefetch request that has not been sent to the destination. Different processing strategies are applied to these two cases.

[0072] Accordingly, prefetch requests whose sequence identifiers match the values ​​of the read pointers are sent to the corresponding destinations, and the values ​​of the read pointers are adjusted to send the remaining prefetch requests in the prediction queue. These read pointers are used to read prefetch requests from the queue. In this way, using the matching of sequence identifiers and read pointer values ​​as the trigger condition for request sending, the automatic sequential sending of prefetch requests and the dynamic synchronization update of the read pointers are achieved, ensuring that prefetch requests are sent to the destinations continuously and without interruption in logical order.

[0073] Accordingly, taking the second prefetch request as an example. If the second prefetch request has been sent to the corresponding destination and remains in the prediction queue after being sent to the corresponding destination, then the second prefetch request is discarded. If the second prefetch request has not been sent to the corresponding destination, then the second prefetch request is discarded, and a preparation request is sent to the destination. This preparation request is used to notify the destination to prepare the data corresponding to the data access request in advance; or, the second prefetch request can still wait to be read in the prediction queue before being discarded; or, the second prefetch request can be transferred to a higher priority queue to wait to be read so that it can be sent to the destination as soon as possible, which will not be elaborated here. In this way, it is ensured that requests that have been prefetched are effectively cleaned up after the actual request arrives, and it is also ensured that unsent prefetch requests can be promptly notified to the destination to prepare the corresponding data when discarded, avoiding the delay of the actual request caused by untimely data prefetching and improving the overall processing efficiency.

[0074] Furthermore, when the actual data access request (i.e., the real request) arrives, if a matching prefetch request has already been sent to the destination, it indicates an accurate prediction, and the prefetch request cached in the prediction queue is discarded. If no matching prefetch request exists in the prediction queue, it indicates a prediction omission, and a preparation request corresponding to the data access request is generated and sent to the destination. This preparation request instructs the preparation of data related to the data access request in advance. Typically, the preparation request is sent to the destination via the prediction path, which is faster than the execution path used to transmit the data access request. Therefore, the preparation request can also arrive before the data access request, achieving the goal of early preparation and reducing latency.

[0075] 305. If the number of second prefetch requests and the number of third prefetch requests are both at least one, for each third prefetch request, subtract a first target value from the sequence identifier of the third prefetch request. The first target value is the number of second prefetch requests written before the third prefetch request.

[0076] In this embodiment, the first target value is the total number of prefetch requests that have been discarded before the current third prefetch request. By selectively deducting the number of requests discarded before a single subsequent request, the sequence identifier of each subsequent request matches the actual logical order of the requests in the queue, thus ensuring that prefetch requests are sent to the destination in the correct order.

[0077] In other words, when a prefetch request is discarded after matching, the corresponding order identifier adjustment method is as follows: When a received data access request matches N prefetch requests in the prediction queue, a set S is formed, which includes the order identifiers of these N prefetch requests; after discarding these N prefetch requests, for any remaining prefetch request, determine the number K of elements in set S that are less than the original order identifier of the prefetch request. K is the first target value, and the new order identifier of the prefetch request is the original order identifier minus K. N is an integer not less than 1, and K is an integer not less than 0.

[0078] For example, see Figure 4 As shown, Figure 4 This diagram illustrates the updating of the sequence identifier when a prefetch request is discarded after matching, according to an embodiment of this application. The queue on the left side of the diagram contains five prefetch requests with sequence identifiers 0-4. When a data access request arrives and successfully matches the prefetch request with sequence identifier 1, the new sequence identifier is updated as shown in the queue on the right. Specifically, prefetch requests with original sequence identifiers before 0 were not discarded, so their corresponding first target value is 0, and their corresponding new sequence identifiers remain 0. For each prefetch request with original sequence identifiers 2, 3, and 4, a prefetch request (i.e., the prefetch request with sequence identifier 1) was discarded, so their corresponding first target value is 1, and their updated new sequence identifiers are 1, 2, and 3, respectively. At this point, if a new prefetch request is written, its sequence identifier is configured as 4.

[0079] For example, see Figure 5 As shown, Figure 5 This diagram illustrates an alternative method for updating the sequence identifier when a prefetch request is discarded after matching, according to an embodiment of this application. The queue on the left contains five prefetch requests with sequence identifiers 0-4. When multiple data access requests arrive and successfully match the prefetch requests with sequence identifiers 1 and 3, the new sequence identifier is updated as shown in the queue on the right. Specifically, if the prefetch requests before the original sequence identifier 0 were not discarded, the corresponding first target value is 0, and the corresponding new sequence identifier remains 0. If a prefetch request with the original sequence identifier 2 was preceded by a discarded prefetch request (i.e., the prefetch request with sequence identifier 1), the corresponding first target value is 1, and the updated new sequence identifier is 1. If a prefetch request with the original sequence identifier 4 was preceded by two discarded prefetch requests (i.e., two prefetch requests with sequence identifiers 1 and 3), the corresponding first target value is 2, and the updated new sequence identifier is 2. At this point, if a new prefetch request is written, its sequence identifier is configured as 3.

[0080] In some embodiments, the value of the read pointer is adjusted according to the relationship between the current value of the read pointer and the order identifier of the discarded prefetch request. In fact, this adjustment is the same as the adjustment logic of the prefetch request in the corresponding storage layer, so that the adjusted read pointer can still accurately point to the new order identifier corresponding to the original storage layer, ensuring the continuity and accuracy of the reading order.

[0081] Accordingly, if the value of the read pointer is not equal to the sequence identifier of each second prefetch request, the value of the read pointer is subtracted from the second target value. The second target value is the number of target prefetch requests in at least one second prefetch request. The sequence identifier of the target prefetch request is less than the value of the read pointer, that is, the target prefetch request refers to the prefetch request that has been discarded before the prefetch request indicated by the read pointer. If the value of the read pointer is equal to the sequence identifier of any second prefetch request, the value of the read pointer is incremented by 1 to skip the currently pointed-to discarded prefetch request, and then the second target value is subtracted. If the memory layer pointed to by the read pointer contains a prefetch request at this time, the reading continues. If the memory layer pointed to by the read pointer does not contain a prefetch request at this time, the value is incremented by 1 until a prefetch request exists in the pointed-to memory layer.

[0082] In this way, the scenario of matching and triggering discard is adapted to ensure that the value of the read pointer is always synchronized with the actual prefetch request order identifier in the queue. This avoids the read pointer pointing to the wrong prefetch request due to request discard, prevents requests from being missed or sent incorrectly, and ensures the accuracy of the order in which prefetch requests are read from the queue.

[0083] For example, see Figure 6 As shown, Figure 6 This is a schematic diagram illustrating the updating of the read pointer when a prefetch request is discarded after a match, according to an embodiment of this application. Figure 5 If the scenario is the same, and the original value of the read pointer is 2, then determine the number of prefetch requests with a sequence number less than 2 among the discarded prefetch requests. If this number is 1, then adjust the value of the read pointer to 2-1=1, pointing to the layer where the new sequence number of the prefetch request is located.

[0084] 306. If the number of prefetch requests currently stored in the prediction queue reaches a preset threshold, and the second prefetch request in the prediction queue is written before other prefetch requests in the prediction queue, the second prefetch request is discarded.

[0085] In this embodiment, this falls under the category of discarding prefetch requests after the queue is full. The discarded second prefetch request is the one with the smallest sequential identifier (earliest written) in the prediction queue. These prefetch requests haven't been matched for a long time and may indicate prediction failure, therefore they are discarded first. The preset threshold refers to the upper limit of the number of prefetch requests allowed to be stored in the prediction queue or the critical value that triggers cleanup. The preset threshold can be equal to the number of storage layers in the prediction queue, or it can be a preset value less than that number; no restriction is placed here. For example, after reaching the preset threshold, the second prefetch request is immediately discarded; or, after reaching the preset threshold, if a new prefetch request is received, when the new prefetch request is ready to be written to the prediction queue, the second prefetch request is discarded to store the new prefetch request; no restriction is placed on this.

[0086] In this way, a capacity threshold control and old request cleanup mechanism for the prediction queue is established. When the queue storage reaches the preset threshold, the earliest written prefetch request is discarded, realizing the dynamic release of queue storage resources and avoiding storage overflow caused by continuous request backlog in the prediction queue. At the same time, old requests with low timeliness are cleaned up first, ensuring that new prefetch requests can be written to the queue in a timely manner, thereby improving the resource utilization of the queue and the timeliness of request processing.

[0087] 307. If there are at least one second prefetch request and at least one third prefetch request, subtract the number of second prefetch requests from the sequence identifier of each third prefetch request.

[0088] In this embodiment, since the second prefetch requests discarded in this case are some of the earliest second prefetch requests written in the prediction queue, the number of these discarded prefetch requests is subtracted from each subsequent third prefetch request. If a second prefetch request is discarded after a new prefetch request has already been received, the number of second prefetch requests is not less than the number of new prefetch requests received. In this way, for multi-request discarding scenarios triggered by queue thresholds, the order identifiers of subsequent requests are uniformly decremented according to the total number of discarded requests. This improves the efficiency of identifier updates while ensuring the accuracy of order identifier updates and avoids queue processing delays caused by complex calculations.

[0089] In other words, when a prefetch request is discarded after the queue is full, the corresponding order identifier adjustment method is as follows: discard the earliest prefetch request written in the M prediction queues, and subtract M from the original order identifier of the remaining prefetch requests to obtain the new order identifier. M is an integer not less than 1.

[0090] For example, see Figure 7 As shown, Figure 7This diagram illustrates how to update the sequence identifier when a queue is full and prefetch requests are discarded, according to an embodiment of this application. The example assumes a preset threshold equal to the number of storage layers in the prediction queue and the number of discarded prefetch requests equal to the number of newly received prefetch requests. The left-hand queue contains eight prefetch requests with sequence identifiers 0-7. The number of prefetch requests currently stored in the prediction queue has reached the preset threshold. If two new prefetch requests are received at this time, the new sequence identifiers are updated as shown in the right-hand queue. The two prefetch requests with original sequence identifiers 0 and 1 in the prediction queue are discarded. Each prefetch request with original sequence identifiers 2-7 has two prefetch requests discarded before it, resulting in new sequence identifiers of 0-6. The two newly received prefetch requests are written to the two storage layers of the discarded prefetch requests, and their sequence identifiers are configured as 6 and 7, respectively.

[0091] In some embodiments, the value of the read pointer is adjusted according to the relationship between the current value of the read pointer and the order identifier of the discarded prefetch request. In fact, this adjustment is the same as the adjustment logic of the prefetch request in the corresponding storage layer, so that the adjusted read pointer can still accurately point to the new order identifier corresponding to the original storage layer, ensuring the continuity and accuracy of the reading order.

[0092] Accordingly, if the value of the read pointer is greater than the sequence identifier of each second prefetch request, the value of the read pointer is reduced by the number of second prefetch requests to adjust the value of the read pointer to the smallest sequence identifier that was not read after the drop occurred. If the value of the read pointer is equal to the sequence identifier of any second prefetch request, the read pointer is cleared to zero.

[0093] In this way, the read pointer can be quickly adjusted in batches to adapt to the batch discarding scenario triggered by the queue threshold. This ensures that the read pointer can accurately point to the valid prefetch request after batch cleanup, and it can be directly cleared to zero when the pointer matches the discarded request identifier. This simplifies the pointer adjustment operation in extreme scenarios and ensures the continuity of queue request reading.

[0094] For example, see Figure 8 As shown, Figure 8 This is a schematic diagram illustrating the updating of the read pointer when a prefetch request is discarded after a queue is full, according to an embodiment of this application. Figure 7 If the scenario is the same, and the original value of the read pointer is 2, then the value of the read pointer is reduced by the total number of discarded prefetch requests, and adjusted to the new minimum order identifier that has not been read. In other words, the value of the read pointer is adjusted to 2-2=0, pointing to the layer where the prefetch request with the new order identifier of 0 is located.

[0095] Steps 304 and 305 describe how to update the sequence identifier of the third prefetch request when the second prefetch request is discarded after a match; steps 306 and 307 describe how to update the sequence identifier of the third prefetch request when the second prefetch request is discarded after the queue is full. In summary, when situations such as discarding requests after the queue is full or discarding requests after a match occur, the sequence identifiers of the remaining prefetch requests in the prediction queue are adjusted to ensure that the adjusted sequence identifiers are continuous and unique, thus accurately reflecting the real-time order of each prefetch request in the prediction queue. Furthermore, if the total number of used layers in the prediction queue (i.e., the number of occupied storage layers) changes at this time, the sequence identifier of newly written prefetch requests must be configured according to the adjusted value of the total.

[0096] In some embodiments, when both the queue is full and prefetch requests are discarded after writing and prefetch requests are discarded after matching occur simultaneously, the process can be carried out according to steps 304 and 305, and the newly received prefetch requests are stored in the idle layer released by the matching and discarding. Alternatively, two rounds of discarding can be performed according to steps 304 and 306 first, and then the corresponding sequence identifier is updated in accordance with the principles of steps 305 and 307, so that the new sequence identifier is still continuous and unique, truly reflecting the order of prefetch requests in the prediction queue. This embodiment of the application will not elaborate on this. The reading pointer is processed in the same way as the sequence identifier.

[0097] The above embodiments are described using the prefetch working mode as an example, but they are not intended to be limiting. Requests with similar working principles to prefetch requests are also applicable to this method. Similarly, the above sequence identifier and read pointer can also be other forms of expressions with the same working principle, which will not be elaborated here.

[0098] Traditional queue logic cannot meet the requirements of complex prefetch scenarios. For example, when a prefetch request is dropped in the prediction queue, it may be a prefetch request from any storage layer in the middle of the prediction queue. If the prefetch requests in the prediction queue are not migrated and new prefetch requests are written to empty layers, the order of the newly written prefetch requests will be out of order with respect to the layer numbers. In this case, sending prefetch requests according to the order indicated by the layer numbers will obviously cause problems.

[0099] This application provides a request processing method that, by allocating and updating a sequence identifier in real time for each prefetch request written to the prediction queue, handles queue changes in complex scenarios such as discarding requests after the queue is full and discarding requests based on matching. This achieves ordered storage and transmission of prefetch requests in multi-source scenarios, particularly avoiding the disordered logical order of queue requests caused by request discarding. It also solves the problem of disordered request management caused by untimely migration operations in multi-source scenarios, meeting the complex queue processing requirements of prefetching work, ensuring the continuity of prefetch request processing, and guaranteeing the execution efficiency of prefetching work. Furthermore, this method is simple in principle, has low area overhead, and can be widely applied to processing situations with similar scenarios, demonstrating high applicability.

[0100] Figure 9 This is a block diagram of a request processing apparatus according to an embodiment of this application. The apparatus is used to perform the steps of the request processing method described above, see below. Figure 9 The request processing device includes: a receiving module 901, a writing module 902, a configuration module 903, and an update module 904.

[0101] The receiving module 901 is used to receive a first prefetch request from the source end. The first prefetch request is predicted by the source end and is used to notify the destination end in advance to complete data loading. The writing module 902 is used to write the first prefetch request to the prediction queue, which is used to store prefetch requests from multiple sources. The prediction queue is also used to send the prefetch request to the destination based on the sequence identifier of each prefetch request. Configuration module 903 is used to configure the sequence identifier of the first prefetch request as a first value, the first value being equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written. The update module 904 is used to update the order identifier of the third prefetch request if the second prefetch request in the prediction queue is discarded. The third prefetch request is the prefetch request written into the prediction queue after the second prefetch request.

[0102] In some embodiments, the prediction queue includes multiple storage layers, each storage layer being used to store a single prefetch request; The first value is the number of storage layers occupied when the first prefetch request is written to the prediction queue. The occupied storage layers are the storage layers in the prediction queue that currently store prefetch requests.

[0103] In some embodiments, the receiving module 901 is further configured to simultaneously receive a fourth prefetch request and a fifth prefetch request, wherein the fourth prefetch request originates from a first source and the fifth prefetch request originates from a second source. The configuration module 903 is further configured to configure the sequence identifier of the fourth prefetch request as a second value and the sequence identifier of the fifth prefetch request as a third value based on the preset priorities of the first source end and the second source end; wherein, if the preset priority of the first source end is higher than the preset priority of the second source end, the second value is less than the third value.

[0104] In some embodiments, the apparatus further includes: The discard module is used to discard the second prefetch request if the received data access request matches the second prefetch request. The data access request is used to notify the destination to perform data processing operations.

[0105] In some embodiments, the discarding module is further configured to discard the second prefetch request if the second prefetch request has been sent to the corresponding destination and is retained in the prediction queue after being sent to the corresponding destination; and discard the second prefetch request and notify the destination to prepare the data corresponding to the data access request in advance if the second prefetch request has not been sent to the corresponding destination.

[0106] In some embodiments, the number of second prefetch requests and third prefetch requests is at least one; Update module 904 is used to subtract a first target value from the sequence identifier of each third prefetch request, where the first target value is the number of second prefetch requests written before the third prefetch request.

[0107] In some embodiments, the number of second prefetch requests is at least one; The update module 904 is further configured to subtract a second target value from the value of the read pointer if the value of the read pointer is not equal to the sequence identifier of each second prefetch request. The read pointer is used to read prefetch requests from the queue. The second target value is the number of target prefetch requests in at least one second prefetch request. The sequence identifier of the target prefetch request is less than the value of the read pointer.

[0108] In some embodiments, the discard module is further configured to discard the second prefetch request if the second prefetch request is written earlier than other prefetch requests in the prediction queue after the number of prefetch requests currently stored in the prediction queue reaches a preset threshold.

[0109] In some embodiments, the number of second prefetch requests and third prefetch requests is at least one; The update module 904 is also used to subtract the number of second prefetch requests from the sequence identifier of each third prefetch request.

[0110] In some embodiments, the number of second prefetch requests is at least one; The update module 904 is also used to subtract the number of second prefetch requests from the value of the read pointer if the value of the read pointer is greater than the sequence identifier of each second prefetch request, and the read pointer is used to read prefetch requests from the queue; if the value of the read pointer is equal to the sequence identifier of any second prefetch request, the read pointer is cleared to zero.

[0111] In some embodiments, the apparatus further includes: The sending module is used to send prefetch requests whose sequence identifier is equal to the value of the read pointer to the corresponding destination, and adjust the value of the read pointer to send the remaining prefetch requests in the prediction queue. The read pointer is used to read prefetch requests from the queue.

[0112] This application provides a request processing apparatus that, by allocating and updating a sequence identifier in real time for each prefetch request written to the prediction queue, achieves ordered storage and transmission of prefetch requests in multi-source scenarios. In particular, when a request is discarded, the sequence identifier of each subsequent prefetch request is dynamically updated, avoiding the disorder of the queue request logic order caused by request discarding. This solves the problem of disordered request management caused by untimely migration operations in multi-source scenarios, meets the complex queue processing requirements of prefetching work, ensures the continuity of prefetch request processing, and guarantees the execution efficiency of prefetching work.

[0113] It should be noted that the request processing device provided in the above embodiments is only illustrated by the division of the above functional modules when running the application. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the chip can be divided into different functional modules to complete all or part of the functions described above. In addition, the request processing device and the request processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0114] This application also provides a chip, see [link to relevant documentation] Figure 10 As shown, Figure 10 This is a schematic diagram of a chip structure according to an embodiment of this application. The chip includes programmable logic circuitry configured to enable the chip to implement the request processing method in the embodiments of this application. The programmable logic circuitry on chip 1000 includes at least a prediction queue 1001 and a read pointer 1002.

[0115] In some embodiments, the chip 1000 also includes an external interface 1003. The external interface 1003 represents any number and type of I / O interfaces. Exemplarily, various types of external modules 1004 are coupled to the external interface 1003. The external modules 1004 coupled to the external interface 1003 include, but are not limited to, the source end, destination end, etc., as described above.

[0116] The chips provided in the above embodiments are merely illustrative and do not constitute a limitation. In practical applications, components can be added or removed as needed, and the editable logic circuits on the chip can be flexibly edited to complete all or part of the functions described above. Furthermore, the chips provided in the above embodiments and the request processing method embodiments belong to the same concept; their specific implementation process can be found in the method embodiments, and will not be repeated here.

[0117] This application also provides an electronic device. Figure 11 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. See also... Figure 11 The electronic device 1100 includes a chip 1000. Through the programmable logic circuit in the chip 1000, the electronic device 1100 can implement the request processing method in the embodiments of this application.

[0118] This application also provides another electronic device. Figure 12 This is a schematic diagram of the structure of another electronic device according to an embodiment of this application. See also... Figure 12 The electronic device 1200 may vary considerably due to different configurations or performance, and may include one or more processors 1201 and one or more memory 1202.

[0119] Processor 1201 may include one or more processing cores, such as a 4-core processor or a 12-core processor. Processor 1201 may be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). Processor 1201 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state.

[0120] The memory 1202 may include one or more computer-readable storage media, which may be non-transitory. The memory 1202 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices.

[0121] For the electronic device 1200, the memory 1202 stores at least one computer program, which is loaded and executed by the processor 1201 to implement the request processing methods provided in the above-described method embodiments. Of course, the electronic device 1200 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The electronic device 1200 may also include other components for implementing device functions, which will not be elaborated here.

[0122] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the request processing method in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0123] This application also provides a computer program product, including a computer program that is executed by a processor to implement the request processing method in this application embodiment.

[0124] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0125] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A request processing method, characterized in that, The method includes: Receive a first prefetch request from the source end, the first prefetch request being predicted by the source end, the first prefetch request being used to notify the destination end in advance that data loading is complete; The first prefetch request is written into the prediction queue, which is used to store prefetch requests from multiple sources and to send prefetch requests to the destination based on the sequence identifier of each prefetch request. Configure the sequence identifier of the first prefetch request to a first value, which is equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written. If the second prefetch request in the prediction queue is discarded, the order identifier of the third prefetch request is updated. The third prefetch request is the prefetch request written into the prediction queue after the second prefetch request.

2. The request processing method according to claim 1, characterized in that, The prediction queue includes multiple storage layers, each of which stores a single prefetch request. The first value is the number of storage layers occupied when the first prefetch request is written to the prediction queue, and the occupied storage layer is the storage layer in the prediction queue that currently stores the prefetch request.

3. The request processing method according to claim 1, characterized in that, The method further includes: Simultaneously receive a fourth prefetch request and a fifth prefetch request, wherein the fourth prefetch request comes from the first source and the fifth prefetch request comes from the second source; Based on the preset priorities of the first source and the second source, the sequence identifier of the fourth prefetch request is configured as a second value, and the sequence identifier of the fifth prefetch request is configured as a third value. Wherein, if the preset priority of the first source end is higher than the preset priority of the second source end, then the second value is less than the third value.

4. The request processing method according to claim 1, characterized in that, The method further includes: If the received data access request matches the second prefetch request, the second prefetch request is discarded. The data access request is used to notify the destination to perform data processing operations.

5. The request processing method according to claim 4, characterized in that, The discarding of the second prefetch request includes: If the second prefetch request has been sent to the corresponding destination and remains in the prediction queue after being sent to the corresponding destination, then the second prefetch request is discarded. If the second prefetch request is not sent to the corresponding destination, the second prefetch request is discarded, and the destination is notified to prepare the data corresponding to the data access request in advance.

6. The request processing method according to claim 4, characterized in that, The number of the second prefetch request and the third prefetch request is at least one; The update of the order identifier of the third prefetch request includes: For each third prefetch request, a first target value is subtracted from the sequence identifier of the third prefetch request, where the first target value is the number of second prefetch requests written before the third prefetch request.

7. The request processing method according to claim 4, characterized in that, The number of the second prefetch requests is at least one; The method further includes: If the value of the read pointer is not equal to the sequence identifier of each second prefetch request, the value of the read pointer is subtracted from the second target value. The read pointer is used to read prefetch requests from the queue. The second target value is the number of target prefetch requests in at least one second prefetch request. The sequence identifier of the target prefetch request is less than the value of the read pointer.

8. The request processing method according to claim 1, characterized in that, The method further includes: Once the number of prefetch requests currently stored in the prediction queue reaches a preset threshold, if the second prefetch request is written earlier than other prefetch requests in the prediction queue, the second prefetch request is discarded.

9. The request processing method according to claim 8, characterized in that, The number of the second prefetch request and the third prefetch request is at least one; The update of the order identifier of the third prefetch request includes: Subtract the number of second prefetch requests from the sequence identifier of each third prefetch request.

10. The request processing method according to claim 8, characterized in that, The number of the second prefetch requests is at least one; The method further includes: If the value of the read pointer is greater than the sequence identifier of each second prefetch request, the value of the read pointer is reduced by the number of the second prefetch requests. The read pointer is used to read prefetch requests from the queue. If the value of the read pointer is equal to the sequence identifier of any second prefetch request, the read pointer is cleared to zero.

11. The request processing method according to claim 1, characterized in that, The method further includes: The prefetch request whose sequence identifier is equal to the value of the read pointer is sent to the corresponding destination, and the value of the read pointer is adjusted to send the remaining prefetch requests in the prediction queue. The read pointer is used to read the prefetch request from the queue.

12. A request processing apparatus, characterized in that, The device includes: The receiving module is configured to receive a first prefetch request from the source end, the first prefetch request being predicted by the source end, and the first prefetch request being used to notify the destination end in advance to complete data loading; The writing module is used to write the first prefetch request into the prediction queue, the prediction queue is used to store prefetch requests from multiple source ends, and the prediction queue is also used to send the prefetch request to the destination end based on the sequence identifier of each prefetch request. The configuration module is configured to set the sequence identifier of the first prefetch request to a first value, the first value being equal to the number of prefetch requests stored in the prediction queue when the first prefetch request is written. An update module is used to update the order identifier of a third prefetch request if the second prefetch request in the prediction queue is discarded. The third prefetch request is a prefetch request written into the prediction queue after the second prefetch request.

13. A chip, characterized in that, The chip includes programmable logic circuitry configured to enable the chip to implement the request processing method as described in any one of claims 1 to 11.

14. An electronic device, characterized in that, The electronic device includes a chip; The programmable logic circuitry in the chip is configured to enable the electronic device to implement the request processing method as described in any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program for performing the request processing method as described in any one of claims 1 to 11.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the request processing method as described in any one of claims 1 to 11.

Images