Unified instruction processor for direct memory access scatter / gather engine

Abstract

The invention relates to a unified instruction processor for a direct memory access scatter / gather engine. In one embodiment, a system receives input through a network interface card (NIC) including instructions to read or write a payload of a message, a tracker state indicating a round of processing, and a data type descriptor defining an organization of the message payload. The system identifies a current context and a processing state of the instruction. If the data type descriptor indicates a first type, the system: obtains a current context associated with the first type from the host memory or cache of the NIC; and create a direct memory access (DMA) instruction corresponding to the received instruction by performing an operation in the nested loop. If the data type descriptor indicates a second type, the system: obtains a current context associated with the second type by extracting vector entries from a buffer of the NIC; and create a DMA instruction corresponding to the received instruction based on the address and the length in the vector entry.

Description

Background Technology

[0001] A network interface card (NIC) may include a Direct Memory Access (DMA) engine for handling "collection" operations (e.g., reading message payload fragments from host memory and packaging these fragments for network transmission) and a DMA engine for handling "distribution" operations (e.g., segmenting the message payload into fragments and writing these fragments to various locations in host memory). The NIC can use these DMA engines to accelerate the transfer of message payloads to and from host memory. In some cases, the message payload to be transmitted over the network or received from the network may be discontinuous in host memory. Users can use "data type descriptors" to describe the complex data layout used for sending and receiving data. However, a separate processor within the DMA engine may be needed to handle individual data types, which may result in additional hardware and require additional power to allow for maximum bandwidth DMA operations. Attached Figure Description

[0002] Figure 1 A schematic diagram of the architecture of a unified instruction processor that facilitates a direct memory access (DMA) scatter / collection engine, according to one aspect of this application, is shown.

[0003] Figure 2 A schematic diagram of a data type processor (DTP) according to one aspect of this application is shown.

[0004] Figure 3A A table is depicted illustrating an example derived data type (derived-DT) descriptor according to one aspect of this application.

[0005] Figure 3B An example derived data type according to one aspect of this application is described.

[0006] Figure 3C A table is depicted illustrating an example input / output vector data type (IOVEC-DT) descriptor according to one aspect of this application.

[0007] Figure 4A A flowchart illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application is shown.

[0008] Figure 4B A flowchart illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application is shown, including determining the state and context of the derived-DT.

[0009] Figure 4CA flowchart illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application is shown, including determining the state and context of the IOWEC-DT.

[0010] Figure 5 Pseudocode is shown illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application, including determining the processing state of derived data types and the current context.

[0011] Figure 6 A schematic diagram of the calculations performed in the processing of derivative-DT according to one aspect of this application is shown.

[0012] Figure 7 A multiply-accumulate (MAC) unit shared between processing operations on derivative-DT and IOWEC-DT is shown according to one aspect of this application.

[0013] Figure 8A and Figure 8B Pseudocode is shown illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application, including determining the processing state and current context of the IOWEC-DT.

[0014] Figure 9 A schematic diagram of the processing state transitions of Derivative-DT and IOWEC-DT according to one aspect of this application is shown.

[0015] Figure 10 A schematic diagram of byte masking processing according to one aspect of this application is shown.

[0016] Figure 11 A computer-readable medium is shown that facilitates a unified instruction processor for a DMA scatter / collection engine according to one aspect of this application.

[0017] In the accompanying drawings, similar reference numerals denote the same elements. Detailed Implementation

[0018] The following description is provided to enable any person skilled in the art to implement and use these aspects and examples, and is given in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described herein are not limited to those shown, but should be given the broadest scope consistent with the principles and features disclosed herein.

[0019] The aforementioned aspect provides a unified instruction processor in the Direct Memory Access (DMA) scatter / gather engine of the network interface card (NIC). The DMA scatter / gather engine can be used to accelerate the transfer of "message" payloads from and to host memory. A "message" can be a piece of information transmitted over the network as one or more data packets (e.g., an Ethernet frame carrying Control Protocol / Internet Protocol (TCP / IP) packets, a proprietary transport packet, etc.).

[0020] In some cases, message payloads to be transmitted over or received from the network may be discontinuous in host memory, but can be organized using data type descriptors. Users can use data type descriptors to describe complex data layouts for sending and receiving data. However, this may require a separate processor in the DMA engine of the NIC to handle individual data types, potentially resulting in additional hardware and power requirements to allow for maximum bandwidth DMA operations.

[0021] The aforementioned limitations are addressed by providing a unified instruction processor (referred to as a "data type processor" or "DTP") within the DMA scatter / collection engine. Each instance of the scatter / collection DMA engine may include a data type processor. The DTP may include information provided by the DMA scatter / collection engine (e.g., as a response to...) Figure 1 DTP126 and Figure 2 The inputs to the DTP 200) and a set of basic DMA instructions used to generate a series of instructions describing reading from or writing to host memory (e.g., from...). Figure 1 DTP 126 and from Figure 2 Various execution resources of the DTP 200 output.

[0022] In a collection scenario, the collection DMA engine can fetch all ("small") fragments of the payload and pack them together for transmission over the network (as one or more data packets). This improves performance because it may no longer be necessary for software to copy and pack all data into contiguous areas of host memory for use by the NIC. In a distributed scenario, the distributed DMA engine can receive the message payload (packed into one or more network packets), break the message payload into segments, and write these segments to various locations in host memory. This also improves performance because it may no longer be necessary for software to unpack and copy all data written to contiguous areas of host memory upon receipt from the network.

[0023] DTP supports processing two specific data types. The first data type is a "derived data type" ("derived-DT"), which can represent a multidimensional array structure (e.g., defined by one or more nested loops) that includes the number of elements in each dimension, the size of the elements to be transmitted, and the step size in each dimension. The following section combines... Figure 3A Example derived-DT descriptors are provided. The second data type is the "Input / Output Vector Data Type" ("IOVEC-DT"), which can be represented by an array of address / length pairs, where each address / length pair describes a portion of the message payload. The DTP can receive information as input (including instructions and data type descriptors) from various other components in the NIC, process instructions based on the context and state of the data type, and output multiple DMA instructions. The following section combines... Figure 3C A sample IOWEC-DT descriptor is provided. See below for more information. Figure 2 and Figure 10 The DTP can also perform byte-masking on data elements with non-contiguous byte groups.

[0024] Therefore, the aforementioned aspect provides a unified processor in the DMA scatter / collection engine that can support the processing of two different data types: derived-DT (as discussed below). Figure 2 , Figure 4B , Figure 6 and Figure 7 (as described above); and IOWEC-DT (as described below). Figure 2 , Figure 4C (As shown in Figure 8). The following sections will combine... Figure 1 and Figure 2 The architecture and DTP diagram of the DMA scatter / collection engine are provided. By using data type descriptors to describe the complex data layout used for sending and receiving data, and by providing a unified processor capable of handling at least two data types (i.e., Derivative-DT and IOWEC-DT), these aspects eliminate the need for separate processors to handle individual data types, which could lead to increased hardware requirements and power consumption.

[0025] Example High-Level Architecture

[0026] Figure 1A schematic diagram 100 of a unified instruction processor architecture that facilitates a direct memory access (DMA) scatter / collection engine according to one aspect of this application is shown. Figure 100 includes a DMA scatter / collection engine (also referred to as the "engine") 110 that interacts with various components external to the engine. The engine 110 may be part of a circuit system or logic in a NIC capable of performing the operations described herein. Engine 110 may include: a tracker 112 and a tracker arbitrator (“Arb”) 114, the tracker arbitrator 114 being responsible for scheduling the processing of instructions coming into the scatter / collect engine; an instruction random access memory (RAM) 116 storing information associated with incoming instructions; an IVOEC / context fast forward (“context-FF”) buffer 118 (also referred to as an “ICB” or “buffer”) storing data fetched from host memory; a descriptor table 122 with entries, each entry defining a scatter / collect operation; a cold / hot context cache 124 caching contexts based on associated access or storage times; a DMA scatter / collect engine pipeline 120 (also referred to as an “engine pipeline” or “data pipeline”) that collects information from various units or components in the engine; and a data type processor (DTP) 126 that receives input (e.g., from engine pipeline 120) and performs the methods described herein. Descriptor table 122 can be a local software-programmable table for a specific DMA scatter / collection engine, or it can be shared among multiple engines. Before initiating a scatter / collection operation, the software must program the data type descriptors (e.g., Derivative-DT or IOWEC-DT) in descriptor table 122, which define the organization of the message payload in host memory.

[0027] Descriptor table 122 may include non-byte mask descriptor storage and byte mask descriptor storage. The byte mask portion of the descriptor may refer to a value with multiple bits, which can be used as a byte mask for up to a predetermined number of bytes of data. For example, during compression, each bit in an X-bit byte mask may correspond to a byte in a data block or an X-byte data chunk. The non-byte mask portion of the descriptor may include other information, such as loop count and step size (for Derivative-DT), a pointer to an IoVEC in host memory (for IoVEC-DT), etc., which are created by the user and stored in descriptor table 122 for subsequent use or retrieval by the DMA scatter / collection engine. The following section combines... Figure 10 The byte masking process is described in detail.

[0028] During operation, engine 110 may receive instructions 150, such as single-input multiple-output (SIMO) instructions. SIMO instructions may include information defining higher-level scatter / collection operations, such as: base host memory address; overall payload length; and references to entries in descriptor table 122. For each SIMO instruction input to engine 110, engine 110 may ultimately produce multiple instruction outputs, each describing a single DMA read or write. Engine 110 may also generate DMA read instructions for retrieving data from host memory in its own name, such as retrieving IOWEC entry groups or derived-DT context-FF information, as described below. Figure 2 The primitives 210 and 230 are described.

[0029] Engine 110 can store information associated with SIMO instructions in instruction RAM 116 (via communication 154). Upon receiving instruction 150, tracker 112 can create and store a tracker entry. Tracker 112 can track the received instructions, and each entry in the tracker (e.g., out of 256 entries) can manage the overall scatter / collection operation corresponding to the SIMO instruction. Tracker Arb 114 can schedule instruction processing by managing tracker entries and credit-based flow control (e.g., based on communication 188) associated with the engine's output queue (not shown), which allows the engine to manage multiple concurrent collect / scatter operations in a time-sliced ​​manner.

[0030] When an instruction is to be processed based on a schedule via communication 158 (i.e., when a particular tracker entry wins arbitration), engine pipeline 120 can obtain the instruction from instruction RAM 116 (via communication 156) and the contents of the tracker entry (via communication 158). Based on the descriptor information provided in the instruction, engine pipeline 120 can obtain the descriptor from descriptor table 122. If available, engine pipeline 120 can also obtain data (e.g., IVOEC entries or context-FF data) from ICB 118 (via communication 162). If available, engine pipeline 120 can also obtain the current context from hot / cold context cache 124 (via communication 164).

[0031] Once a tracker entry has been selected (i.e., arbitration has been won) and engine pipeline 120 has received up to five inputs from other components in engine 110, a round of processing can begin. Engine pipeline 120 can send these five inputs to DTP 126 (via communications 166, 168, 170, 172, and 174). DTP 126 can receive these five inputs and can accept information from applicable input queues or multiple input queues, for example, if DTP 126 is idle or when DTP 126 has completed any ongoing execution. The five inputs to DTP 126 can include: IOWEC entry group / context -FF, if available (via communication 166); SIMO instructions (via communication 168); tracker status (via communication 170); descriptor (via communication 172); and current context, if available (via communication 174). Depending on, for example, the availability of output queue credits and the possibility of performing additional work, DTP 126 can process the information received from the five inputs over one or more cycles. After processing the input, DTP 126 can generate and send the following as outputs: tracker status updates sent to tracker 112 (via communication 176); new (hot) context sent to hot / cold context buffer 124 (via communication 178); and DMA read / write commands to be processed and transferred by external components of engine 110 (via communication 180). The following is combined with... Figure 2 A detailed description of DTP 126 is provided.

[0032] After processing in each unit, DMA read / write commands can be sent to PCIe interface 142 or network interface 140 via communication 180. DMA command queue 130 and DMA command arbitrator (“Arb”) 132 are responsible for scheduling the transmission of DMA commands. Address translation unit 134 is responsible for converting logical addresses to physical addresses and can transmit the corresponding information to PCIe interface 142 (via communication 190). DMA read / write tracking unit 136 can track the DMA commands being processed and send relevant messages to: ICB 118 (via communication 182); PCIe interface 142 (via communication 192); and packet buffer 138 (via communication 184). Data stored in packet buffer 138 can be transmitted to network interface 140 (via communication 186).

[0033] Figure 2A schematic diagram of a Data Type Processor (DTP) 200 according to one aspect of this application is shown. The DTP 200 may be part of a circuit system or logic within the engine of a NIC that processes resources or performs the operations described herein. The DTP 200 may include an input distribution unit 202 that can receive and distribute five inputs from various components of the DMA scatter / collection engine, including: IOWEC entry group / context-FF 250; SIMO instruction 252; tracker state 254; descriptor 256; and current context 258. Based on descriptor 256, the input distribution unit 202 can determine whether to proceed as depicted in the left-hand communication distribution 260 (if the data type indicates Derivative-DT) or as depicted in the right-hand communication distribution 280 (if the data type indicates IOWEC-DT). As described below, the resources in the DTP 200 for Derivative-DT processing (i.e., the left-hand side) and IOWEC-DT processing (i.e., the right-hand side) may utilize a shared Multiply-Accumulate (MAC) unit 244 and a shared bytemask processing unit 246.

[0034] If the descriptor indicates a derived-DT, the DTP 200 can use the input received via communication 260 to determine the processing state and the current context. The derived-DT processing state unit 204 and the current derived-DT processing context unit 206 can perform operations to identify the processing state and the current context, as described below. Figure 4B , Figure 5 , Figure 6 and Figure 7 As stated above.

[0035] The Derivative-DT Processing State Unit 204 and the Current Derivative-DT Processing Context Unit 206 can determine that if the processing is not in the first cycle of the current round of processing, this indicates that a context has been created in a previous cycle and the corresponding context-FF entry exists in the ICB. This could mean that a previous round of processing has occurred to place the information in the ICB entry. The current context can include a "basic context" (i.e., context-FF 250 from the ICB) and an "extended context" (i.e., the current context 258 from the context cache). The basic context can include the loop counter value and the number of bytes passed, while the extended context can include the address offset and the amount of adjustment to the step value. In this scenario, since both context-FF 250 and the current context 258 have been included as input to DTP 200 (or re-looped from the previous processing cycle via communication 298 as re-looping context 296), units 204 and 206 can determine the processing state and the current context and provide them to the Derivative-DT Loop Execution Unit 208 (via communication 261 and 262).

[0036] The derived-DT loop execution unit 208 can perform loop execution, and the DMA instruction generation unit 212 can generate corresponding DMA instructions based on the results of the loop execution (such as those transmitted via communication 266). In some aspects, the descriptor 256 can indicate the byte mask to be executed (e.g., in...). Figure 3A (Example: element 326 of the derived-DT descriptor for "do_byte_masking"). The byte mask can be included as input with descriptor 256. The derived-DT loop execution unit 208 can perform loop execution by communicating with the byte mask processing unit 246 to obtain the valid bytes of data (via communication 268). The following is in conjunction with... Figure 10 A byte mask is described. The byte mask processing unit 246 can send (via communication 269) information associated with the valid bytes of data to the DMA instruction forming unit 212, which can use this information to form DMA instructions. After executing this loop (or as many rounds as possible), the context update unit 214 can update the context, for example, by updating the loop counter value and the number of bytes transferred based on information transmitted via communication 265.

[0037] Context update unit 214 can also send the updated context to multiplexer (“mux”) 242 (via communication 271). mux 242 can select the updated context and either send it back as a recycle context 296 to the current derived-DT processing context unit 206 for later use (via communication 298), or transmit it as a context output 297 to the hot context buffer (e.g., ...). Figure 1 (Cache 124 in the middle). The processing state update unit 216 can update the processing state, which can affect various operations performed by the DTP 200. The following text combines... Figure 9 States 920, 922, 924, 926, and 928 in the diagram describe the state diagram of the processing states for the derivative-DT processing. The processing state update unit 216 can store the state in register 220, and the stored state can be sent to the derivative-DT processing state unit 204 (via communication 221) for later use. Furthermore, the tracker state update unit 218 can update the tracker state and transmit the updated tracker state to mux 222 (via communication 272). mux 222 can select the updated tracker state and transmit the engine tracker update output 294 to the tracker (e.g., ...). Figure 1 Tracker 112 in the middle).

[0038] The Derivative-DT Processing State Unit 204 and the Current Derivative-DT Processing Context Unit 206 can determine if the packet being processed is the first packet of a message (e.g., based on tracker state 254) and if the processing is in the first cycle of the current round of processing, the DTP 200 can infer the current context. That is, the Derivative-DT Loop Execution Unit 208 can determine (based on communications 261 and 262) by initializing the base context with all zeros and by calculating the extended context. The Derivative-DT Loop Execution Unit 208 can communicate with the MAC Unit 244 to obtain the extended context (via communication 267). The MAC Unit 244 can calculate the address offset (“addr_offset”), the stride adjustment in the y-dimension (“stridey_adj”), and the stride adjustment in the z-dimension (“stridez_adj”). The address offset can indicate the offset from the base address from which the DTP 200 is currently reading or writing the next data element. In this example, the address offset is zero because the loop counter is zero, so the MAC unit does not calculate the address offset. The step size adjustment can be used to track progress via the rows and columns of a matrix that represents a multidimensional array structure of the derived-DT.

[0039] After inferring the current context, the Derivative-DT Loop Execution Unit 208 can perform loop execution, and the same operation as described above can occur on other units of DTP 200 via the same communication (i.e., the operations described above with respect to units 244, 246, 212, 214, 216 and 218).

[0040] Derivative-DT processing state unit 204 and current derivative-DT processing context unit 206 can determine in the data pipeline (e.g., Figure 1 During the traversal of engine pipeline 120, the cached context is checked. If no cached context is found, the operation described below continues. If a cached context is found and the context type indicates IOWEC-DT, the Derivative-DT loop execution unit 208 can identify the current context by obtaining the basic context from the context-FF entry in the ICB (i.e., as input to context-FF 250) and by calculating the extended context (e.g., by communicating with MAC unit 244 as described above). In this scenario, the address offset returned from MAC unit 244 may not be zero, as this scenario only occurs when the packet is not the first packet and processing is not in the first cycle of the current round. If a cached context is found and the context type indicates Derivative-DT, the Derivative-DT loop execution unit 208 can obtain the current (basic and extended) context from the cache (i.e., as input to the current context 258).

[0041] After recognizing the current context, the Derivative-DT Loop Execution Unit 208 can perform loop execution, and the same operation as described above can occur via the same communication to other units of DTP 200 (i.e., the operations described above with respect to units 244, 246, 212, 214, 216 and 218).

[0042] The Derivative-DT Processing Status Unit 204 and the Current Derivative-DT Processing Context Unit 206 can determine that the message being processed corresponds to a GET response packet. The "inbound" or DMA scatter engine can receive the GET response associated with a previously transmitted GET request. When a GET request is processed, the software has already programmed a descriptor table using descriptors to be used for subsequent scatter operations to be performed by the DMA scatter engine on the GET response. When the corresponding GET request packet is issued, the "Get-response-context-generating engine" (not referred to herein) can use the descriptors to generate and store a starting context (context-FF) for each GET response packet. Therefore (here referring to the "inbound" or DMA scatter engine processing the GET response), context-FF 250 can be input to DTP 200, and the bit ("DT_offset.type") indicates that context-FF 250 was not previously placed in the ICB based on a fetch from host memory, but rather arrived at DTP 200 associated with the GET response packet. Therefore, units 204 and 206 can copy this base context from "DT_offset.value" instead of retrieving data from the ICB entry. The derived-DT loop execution unit 208 can identify the current context based on the base context and by computing the extended context (e.g., through communication with MAC unit 244 as described herein).

[0043] After recognizing the current context, the Derivative-DT Loop Execution Unit 208 can perform loop execution, and the same operation as described above can occur via the same communication to other units of DTP 200 (i.e., the operations described above with respect to units 244, 246, 212, 214, 216 and 218).

[0044] The Derivative-DT Processing State Unit 204 and the Current Derivative-DT Processing Context Unit 206 can determine that: (a) processing is in the first cycle; (b) the data packet is not the first data packet and the first round of processing; (c) no cached context was found during data pipeline traversal; or (d) the message does not correspond to the GET response data packet (corresponding to respectively). Figure 4B(Referring to determinations 412, 416, 420, and 428). In this scenario, the derived-DT loop execution unit 208 may not have enough information to begin loop execution. The derived-DT loop execution unit 208 can create an IVOEC-formatted context, allocate an entry in the ICB (listed as an IVOEC-formatted context), and notify the context-FF extraction unit 210 (via communication 263) to extract the appropriate context from the host memory. The context can be pre-calculated for each packet and stored in an array in the host memory. The context-FF extraction unit 210 can send information related to the requested information to the DMA instruction forming unit 212 (via communication 264). The DMA instruction forming unit 212 can generate and send a DMA instruction to read context information from the host memory, for example, via communication 270 to the multiplexer 248, which can be sent as a DMA read / write instruction 295. After the requested context has been returned from host memory, the DMA scatter / collect engine can complete the current round of processing by writing the context in IOWEC format (listing the allocated ICB entries) to the cache for retrieval in subsequent rounds.

[0045] If the descriptor indicates IOWEC-DT, DTP 200 can use the input received via communication 260 to determine the processing state and current context. IOWEC-DT processing state unit 224 and current IOWEC-DT processing context unit 226 can perform operations to determine the processing state and current context, as described below. Figure 4C , Figure 7 , Figure 8A and Figure 8B As stated above.

[0046] The current IVEC-DT processing context unit 226 can determine if the processing is not in the first cycle of the current round of processing, which indicates that a context has already been created in a previous cycle. In this scenario, since the current context has been recirculated from the previous processing cycle (via communication 299 as recirculation context 296), unit 226 can determine the current context and provide it to the IVEC-DT execution unit 228 (via communication 282). If an ICB entry is listed in the recirculation context and recorded as valid (filled with IVEC entry groups read from host memory in the previous round of processing), then the ICB entry has been read by the engine pipeline and presented to the DTP at the start of this round of processing.

[0047] The current IOWEC-DT processing context unit 226 can determine if the packet being processed is the first packet of a message (e.g., based on tracker state 254) and if the processing is in the first cycle of the current round of processing, then the IOWEC-DT execution unit 228 can initialize the IOWEC-DT context with all zeros and set the current context to the IOWEC type (based on communication 282).

[0048] The current IOWEC-DT processing context unit 226 can determine whether a cached context (e.g., via) was found during data pipeline traversal. Figure 1 (Engine pipeline 120 in the cache). If a cached context is found, unit 226 can obtain the current IOWEC-DT context from the cache (i.e., as input to the current context 258). If an ICB entry is listed in the cached context and is recorded as valid (filled with the group of IOWEC entries read from host memory in the previous round of processing), then the ICB entry has been read by the engine pipeline and presented to the DTP along with the cached context.

[0049] If no cached context is found during data pipeline traversal, IOWEC-DT execution unit 228 can initialize the IOWEC-DT context with all zeros and set the current context to type IOWEC (based on communication 282).

[0050] The IVOEC-DT processing status unit 224 can determine the IVOEC-DT processing status based on whether a context was found during data pipeline traversal or whether the processing is in the first cycle of the current round of processing. Unit 224 can further identify the IVOEC processing status based on, for example: whether the current context is included as input to the processing resource; whether payload delivery has been completed; whether the current round of processing includes a null round of processing; whether a new "head-of-context-list" entry has been read from the buffer (i.e., an entry in the buffer referenced by the first list buffer entry in the context); whether an IVOEC entry has been fetched from host memory; whether the "head-of-context-list" entry in the buffer is valid; whether the message payload includes a GET response packet associated with a previous GET request handled by the processing resource; whether the value indicates that no more IVOEC entries will be fetched; whether one or more buffer entries are available for allocation; whether the message payload associated with the instruction is suitable for payload delivery or IVOEC entry fetching; or whether the processing of the instruction is in the first cycle of the current round of processing. The following is in conjunction with... Figure 8BSections 820, 822, and 824 of pseudocode 810 describe the identification and setting of the IOWEC-DT processing state. The above conditions are provided for illustrative purposes and are not limiting. The IOWEC-DT processing state unit 224 may also use other conditions to identify the processing state.

[0051] Based on one or more of these conditions used to identify the processing status of IVOEC-DT, IVOEC-DT execution unit 228 can obtain the processing status from unit 224 (via communication 281) and, together with the context identified by unit 226 (via communication 282), determine that the IVOEC context is available, the ICB entry reading has been completed, and the IVOEC entry is available for processing.

[0052] The IVEC-DT execution unit 228 can process IVEC entries or issue reads to retrieve additional IVEC entries, which may include communication with the MAC unit 244 and the byte mask processing unit 246. For example, the IVEC-DT execution unit 228 can communicate with the MAC unit 244 (via communication 287) to obtain the value "dtseqnum_epnk", as described below. Figure 7 Furthermore, descriptor 256 can indicate to perform a bytemask (e.g., in...). Figure 3C (In example IVEC-DT descriptor, element 380 for "do_byte_masking"). The byte mask can be included as input with descriptor 256. IVEC-DT execution unit 228 can process IVEC entries by communicating with byte mask processing unit 246 to obtain the valid bytes of data (via communication 288). The following is combined with Figure 10 The byte mask is described. The DMA instruction forming unit 232 can generate a corresponding DMA instruction based on the processed IOWEC entry (such as one transmitted via communication 286). In some aspects, the byte mask processing unit 246 can send information associated with the valid bytes of data to the DMA instruction forming unit 212 (via communication 289), which can then use this information to form the DMA instruction. After processing the IOWEC entry, the context update unit 234 can update the context, for example, by updating the pointer to the IOWEC entry and the number of bytes (based on information transmitted via communication 285).

[0053] Context update unit 234 can also send the updated context to mux 242 (via communication 291). mux 242 can select the updated context and either send it back as a recycle context 296 to the current IOWEC-DT processing context unit 226 for later use (via communication 299), or transmit it as a context output 297 to the hot context buffer (e.g., Figure 1 (Cache 124 in the middle). The processing state update unit 236 can update the processing state, which can affect the DTP 200 to perform various operations. The following text combines... Figure 9 States 930, 932, 934, 936, and 938 describe the state diagram of the processing state of the IOWEC-DT process. The processing state update unit 236 can store the state in register 240, and the stored state can be sent (via communication 241) to the IOWEC-DT processing state unit 224 for later use. Furthermore, the tracker state update unit 238 can update the tracker state and transmit the updated tracker state to mux 222 (via communication 292). mux 222 can select the updated tracker state and transmit the engine tracker update output 294 to the tracker (e.g., ...). Figure 1 Tracker 112 in the middle).

[0054] Based on the obtained context and processing state (via communications 281 and 282), the IVOEC-DT execution unit 228 can determine that an IVOEC entry needs to be retrieved from host memory. The IVOEC-DT execution unit 228 can create an IVOEC-formatted context, allocate an entry in the ICB, and notify the IVOEC entry group retrieval unit 230 (via communication 283) to retrieve the appropriate IVOEC entry from host memory. The IVOEC entry group retrieval unit 230 can send information associated with the requested information to the DMA instruction formation unit 232 (via communication 284). The DMA instruction formation unit 232 can generate and send DMA instructions to read the IVOEC entry group from host memory, for example, via communication 290 to the mux 248; the DMA instructions can be sent as DMA read / write instructions 295. The IVOEC-DT execution unit 228 can perform one or more cycles of IVOEC entry group retrieval, allocating another entry in the ICB in each cycle and adding it to the ICB entry list in the context. After one or more of the extracted IOWEC entry groups have been returned from host memory, the DMA scatter / collect engine can complete this round of processing by writing the IOWEC formatted context (listing the allocated ICB entries) to the cache for extraction in subsequent cycles.

[0055] Figure 3ATable 300 depicts an example derived-DT descriptor according to one aspect of this application. Table 300 includes entries 310-338, which indicate the element names (302) of the derived-DT descriptor and a corresponding description (304) for each element. For example, entry 330 indicates that if the value of the element “dsc_type” is set to “1”, this can represent a descriptor in derived-DT format. As another example, entry 326 for the element “do_byte_masking” indicates whether bytemasking is to be performed. If the value of this element is set to “1” (or another value indicating that bytemasking is to be performed), then the descriptor table (e.g., Figure 1 Table 122 in the table can store 256-bit byte masks and descriptors in parallel. Table 300 is reproduced below:

[0056]

[0057] Figure 3B An example derivative-DT 340 according to one aspect of this application is depicted. Paragraph 342 can provide a definition for derivative-DT 340 including: a data structure named "element" having four indicated values; and a data structure named "AoE" as an array of "elements" comprising multiple elements in three dimensions (e.g., x = 200, y = 100, and x = 80), indicating support for step sizes in the three dimensions. For each element in the array, the element size can be at most, for example, 256 bytes, which can be consistent with the size of common data structures in current applications. Other smaller or larger element sizes can also be used. Each of the indications in paragraphs 344, 346, and 348 indicates that only specific sub-elements of an element can be selected for a particular "face" (e.g., in two of the three dimensions). Byte masks for each element can be supported to select individual bytes for transmission. In derivative-DT 340, the byte mask can select the "b" and "d" sub-elements of an element. Example derivative - DT 340 is reproduced below:

[0058]

[0059] Figure 3CTable 360 ​​depicts an example IOWEC-DT descriptor according to one aspect of this application. Table 360 ​​includes entries 370-390, which indicate the element names (362) of the IOWEC-DT descriptor and the corresponding description (364) for each element. For example, entry 384 indicates whether the value of the element “dsc_type” is set to “0”, which could indicate a descriptor in IOWEC-DT format. Furthermore, entry 380 for the element “do_byte_masking” indicates whether bytemasking is to be performed. If the value of this element is set to “1” (or another value indicating that bytemasking is to be performed), then the descriptor table (e.g., ...) is... Figure 1 The descriptor table (122) in the table can store 256-bit byte masks and descriptors in parallel.

[0060] IOVEC-DT can include two general categories: "storage" IOVEC, where each IOVEC entry except the first or last entry has a standard and relatively large length, such as 4 kilobytes (KB); and "general" IOVEC, where the length is typically smaller and random. In the specific case of a general IOVEC, entries can all have the same length value, where each entry can correspond to a data structure of a general-sized element, and each element itself can be a structure that can be described by a byte mask. Table 360 ​​is reproduced below:

[0061]

[0062] Figure 4A A flowchart 400 illustrates a method for a unified instruction processor that facilitates a DMA scatter / collection engine according to one aspect of this application. The system receives input via processing resources in a network interface card (NIC), including instructions for reading or writing message payloads, tracker states indicating a round of processing of the instructions, and data type descriptors defining the organization of the message payload (operation 402). For example, as... Figure 2 As depicted, the DTP 200 can receive SIMO 252, tracker status 254, and descriptor 256.

[0063] The system identifies the processing status and current context of the instruction (Operation 404), as described above. Figure 2 As described in units 204, 206, 224, and 226. In response to the data type descriptor indicating derived-DT (“first type”) (as... Figure 3A (In item 330), the operation is in Figure 4B Continue at marker A. In response to the data type descriptor indicating IOWEC-DT (“Second Type”) (e.g.) Figure 3C(In item 384), the operation is in Figure 4C Continue at marker B. Figure 4B and Figure 4C After identifying the current context and processing state in each operation at markers A and B, the system executes the operation based on the data type and the identified processing state, as described above regarding the units and operations of derived-DT (e.g., Figure 2 (on the left) and IOWEC-DT's units and operations (e.g., Figure 2 The right side of the image is described below. Figure 9 The example derived-DT and IOWEC-DT processing states are described, and in Figure 5 , Figure 8A and Figure 8B Further comments were added in the pseudocode.

[0064] Figure 4B A flowchart 410 illustrates a method of a unified instruction processor facilitating a DMA scatter / collection engine according to one aspect of this application, including determining the state and context of the derived-DT. If the processing of an instruction is not in the first cycle of the current round of processing (determination 412), the system obtains the current context from the context updated at the end of the previous processing cycle (i.e., as a re-looped derived-DT context from the previous processing cycle) (operation 414), as described above regarding... Figure 2 The operation of the derived-DT processing state unit 204 and the current derived-DT processing context unit 206, and the following regarding... Figure 5 The pseudocode 500 is described in section 510. The system sets the processing state to "Loop Execution" (operation 436), as described above regarding... Figure 2 The derived-DT loop execution unit 208 in the middle and the following about Figure 5 In the pseudocode 500, segment 510 and Figure 9 The state “DSTT_LOOP_EXEC” 926 is described in the table.

[0065] If the processing of the instruction occurs in the first cycle of the current round (decision 412) and if the processing of the instruction occurs in the first cycle of the current round and is associated with the first data packet of the message (decision 416), then the system infers the current context by initializing the basic context (e.g., with zeros) and calculating the extended context (operation 418), as described above regarding... Figure 2 The operations of the derived-DT processing state unit 204 and the current derived-DT processing context unit 206, as well as the communication 267 with the MAC unit 244, are described above. The system sets the processing state to a "loop execution" state (operation 436), as described above regarding... Figure 2The derived-DT loop execution unit 208 and the following about Figure 5 In the pseudocode 500, segment 512 and Figure 9 The state “DSTT_LOOP_EXEC” 926 is described in the table.

[0066] If the processing of the instruction is not in the first cycle of the current round of processing and is not associated with the first packet of the message (decision 416), and if a cached context is found during data pipeline traversal (e.g., if the input includes the current context) (decision 420), and if the context type indicates a second type (i.e., indicating IOWEC-DT) (decision 422), then the system determines the current context by obtaining the basic context from the buffer and calculating the extended context (operation 424), as described above regarding... Figure 2 The operation of the derived-DT processing state unit 204 and the current derived-DT processing context unit 206, and the communication with the MAC unit 244 267, as well as the following regarding Figure 5 As described in section 514 of pseudocode 500, the system sets the processing state to "loop execution" (operation 436), as mentioned above. Figure 2 The derived-DT loop execution unit 208 and the following about Figure 5 In the pseudocode 500, segment 514 and Figure 9 The state “DSTT_LOOP_EXEC” 926 is described in the table.

[0067] If a cached context is found during data pipeline traversal (decision 420) and if the context type indicates the first type (i.e., indicates Derivative-DT and not IOWEC-DT) (decision 422), the system obtains the current context from the cache (operation 426), as described above regarding the operations of Derivative-DT processing state unit 204 and current Derivative-DT processing context unit 206, and as described below regarding... Figure 5 As described in section 514 of pseudocode 500, the system sets the processing state to "loop execution" (operation 436), as mentioned above. Figure 2 The derived-DT loop execution unit 208 and the following about Figure 5 In the pseudocode 500, segment 514 and Figure 9 The state “DSTT_LOOP_EXEC” 926 is described in the table.

[0068] If the input does not include the current context (decision 420), and if the message corresponds to a GET response packet associated with a GET request (decision 428), the system obtains the current context by retrieving the previously stored context associated with the GET request and calculating the extended context (operation 430), as described above regarding... Figure 2The operations of the derived-DT processing state unit 204 and the current derived-DT processing context unit 206 are described above. The system sets the processing state to the "loop execution" state (operation 436), as described above regarding... Figure 2 The derived-DT loop execution unit 208 and the following about Figure 5 In the pseudocode 500, segment 516 and Figure 9 The state “DSTT_LOOP_EXEC” 926 is described in the table.

[0069] If the message does not correspond to a GET response packet associated with a GET request (Decision 428), and if there is no corresponding entry for the current context in the buffer (not shown), the system obtains the current context by creating a temporary IVEC-formatted context, allocating an entry in the buffer (listed as IVEC-formatted contexts), issuing a DMA read to fetch the initial or base (derived-DT) context from host memory, and writing the temporary IVEC-formatted context to the buffer (Operation 432), as described above regarding... Figure 2 The operations of the Derivative-DT Processing State Unit 204, the Current Derivative-DT Processing Context Unit 206, the Derivative-DT Loop Execution Unit 208, and the Context-FF Extraction Unit 210 are described above. The system sets the processing state to the "Skip" state (operation 434), as described above regarding... Figure 2 And the following text about Figure 5 In the pseudocode 500, segment 518 and Figure 9 The state “DSTT_SKIP” 928 in the table describes this. Subsequent rounds of processing can proceed after the initial derived-DT context has been returned from host memory and temporarily stored in a buffer entry.

[0070] After operations 434 and 436, the operation returns and... Figure 4A Operation 408 continues. The system creates a DMA instruction (operation 408) corresponding to the received instruction by executing based on the data type, the identified context, and the state. In this derived-DT scenario, the system performs operations within nested loops representing a multidimensional array structure of derived-DT.

[0071] Figure 4C A flowchart 450 illustrates a method for a unified instruction processor that facilitates a DMA scatter / collection engine according to one aspect of this application, including determining the state and context of the IOWEC-DT. If the processing of an instruction is not in the first cycle of the current round of processing (determination 452), the system obtains the current context from the context updated at the end of the previous processing cycle (operation 454), as described above regarding... Figure 2The operation of the current IOWEC-DT processing context unit 226 is described below. The system sets the processing state (operation 466) based on whether a context was found during data pipeline traversal or whether the processing is in the first cycle of the current round of processing, including based on various conditions such as: whether the current context is included as input to the processing resource; whether payload delivery has been completed; whether the current round of processing includes empty round processing; whether a new head-of-context-list entry has been read from the buffer; whether an IOWEC entry has been fetched from host memory; whether the entry in the buffer referenced by the first listed buffer entry in the context is valid; whether the message payload includes a GET response packet associated with a previous GET request handled by the processing resource; whether the value indicates that no more IOWEC entries will be fetched; whether one or more buffer entries are available for allocation; whether the message payload associated with the instruction is suitable for payload delivery or IOWEC entry fetching; or whether the processing of the instruction is in the first cycle of the current round of processing. The following is combined with Figure 8B Sections 820, 822, and 824 of pseudocode 810 describe the identification and setting of the IOWEC processing state, and are further elaborated below. Figure 9 States 930, 932, 934, 936, and 938 in the table describe examples of IOWEC processing states.

[0072] If the instruction processing occurs in the first cycle of the current round (decision 452), and if the instruction processing occurs in the first cycle of the current round and is associated with the first data packet of the message (decision 456), then the system initializes the current IVEC-DT context with all zeros and sets the current context to IVEC type (operation 458), as described above regarding... Figure 2 The operation of the current IOWEC-DT processing context unit 226 is described below. The system sets the processing state based on whether the context is found during data pipeline traversal or whether the processing is in the first cycle of the current round of processing (operation 466) and various conditions, as described below regarding... Figure 8B The pseudocode 810 is described in segments 820, 822, and 824.

[0073] If a cached context is found during data pipeline traversal (e.g., if the input includes the current context) (decision 460), the system can obtain the current IOWEC-DT context from the cache (operation 462), for example, via... Figure 1 Engine pipe 120 and as Figure 2The current context is input 258. The system sets the processing state based on whether the context was found during data pipeline traversal, whether the processing is in the first cycle of the current round (operation 466), and various conditions, as described below. Figure 8B The pseudocode 810 is described in segments 820, 822, and 824.

[0074] If the cached context is not found during data pipeline traversal (Decision 460), the system initializes the current IOWEC-DT context with all zeros and sets the current context to IOWEC type (Operation 464), as mentioned above. Figure 2 The operation of the current IOWEC-DT processing context unit 226 is described below. The system sets the processing state based on whether the context is found during data pipeline traversal or whether the processing is in the first cycle of the current round of processing (operation 466) and various conditions, as described below regarding... Figure 8B The pseudocode 810 is described in segments 820, 822, and 824.

[0075] After operation 466, the operation returns and... Figure 4A Operation 408 continues. The system creates a DMA instruction corresponding to the received instruction by performing an operation based on the data type, the identified context, and the state (operation 408). In this IOWEC-DT scenario, the system has retrieved the IOWEC entry (whether from host memory or from the ICB) and created a DMA instruction corresponding to the received instruction based on the address and length in the IOWEC entry.

[0076] Figure 5 Pseudocode (PC) 500 illustrates a method of a unified instruction processor facilitating a DMA scatter / collection engine according to one aspect of this application, including determining the processing state and current context of derived data types. PC 500 includes a commented section 502 that describes and defines the variables used in sections 510, 512, 514, 516, and 518 of PC 500. Each of sections 510-518 may correspond to the variables described above regarding... Figure 4B The described operation represents an "if", "elseif", or "else" block. For example, segment 510 could correspond to... Figure 4B The decision 412 and operations 414 and 436; segment 512 can correspond to Figure 4B The decision 416 and operations 418 and 436; segment 514 can correspond to Figure 4B The decisions 420 and 422, and operations 424, 426, and 436; segment 516 can correspond to Figure 4B The decision 428 and operations 430 and 436 are included; segment 518 can correspond to... Figure 4BOperations 432 and 434 in the text.

[0077] Figure 6 A schematic diagram 600 is shown illustrating calculations performed during the processing of derived-DT according to one aspect of this application. Figure 600 depicts data elements as squares (e.g., 602, 606, 632, and 636). During the execution of nested loops, the system can: traverse a first dimension, for example, traverse a first dimension having elements 602.A, 602.B, 602.C, and 602.D based on step sizes (“stridex”) 604.1, 604.2, 604.3, and 604.4 respectively in the x dimension; traverse a second dimension based on step sizes (“stridey”) 610.1, 610.2, ..., 640.1, and 640.2 in the y dimension, each stridey including multiple elements of the first dimension, for example, 602.AD, 606.AD, 632.AD, and 636.AD; and traverse a third dimension based on step sizes (“stridez”) 620.1, 620.2, ... in the z dimension, each stridez including multiple elements of the second dimension defined by stridey, for example, 610.1, 610.2, ..., 640.1, 640.2, etc.

[0078] Items 650, 652, and 654 illustrate the process during derivative-DT processing (e.g., by...). Figure 1 The derived-DT processing state unit 204 in the middle is executed, and as Figure 5 The calculations to be performed are described in sections 512, 514, and 516 of pseudocode 500. Item 650 indicates that the address offset (“addr_offset”) indicating where data is read can be calculated as follows: (currentz * stridez) + (currenty * stridey) + (current * stridex). Item 650 indicates that “stridey_adj” can be calculated as (stridex * (elementsx - 1)), and this value should be subtracted from the current address offset before adding stridey. Furthermore, item 650 indicates that “stridez_adj” can be calculated as (stridey * (elementsy - 1)), and this value should be subtracted from the current address offset before adding stridez. These calculations can be performed by... Figure 2 The shared MAC unit 244 executes the process and returns the status to the derived-DT processing unit 204 via communication 267, as described below. Figure 7 As described.

[0079] Figure 7A multiply-accumulate (MAC) unit 700 shared between the processing operations of derivative-DT and IOWEC-DT is shown according to one aspect of this application. The MAC unit 700 may correspond to... Figure 2 The MAC unit 244 is included. The MAC unit 700 may include: a MAC controller 760; multiplexers (“mux”) 762, 764, 766, 768, 770 and 772; multipliers 774, 776 and 778 (e.g., capable of performing 32x16-bit integer multiplication); adder units 780 and 782; and multiplexer / output register pairs 784 / 786, 788 / 790 and 792 / 794.

[0080] The MAC controller 760 can take various start control signals (e.g., “mac_start[0]710”, “mac_start[1]712”, and “mac_start[2]714”) as inputs and can return “mac_done716” (indicating completion status) as output. The MAC controller 760 can control the inputs to multipliers 774, 776, and 778, as well as inputs to, for example, mux 784.

[0081] It is possible to provide inputs "dt_seqnum" 722 and "entries_per_nk" 730 only for IOWEC processing, that is, in the case of... Figure 2 The IVEC-DT execution unit 228 executes and processes the data via communication 287. For a "general" IVEC (which has a fixed number of entries per fixed amount of message payload), these values ​​can be multiplied (a subset of the MAC function) to calculate the entries in the IVEC corresponding to the data packet being processed.

[0082] During the processing of derived-DT: mux 762 can receive “mstridex” 720 (the stridex value from the descriptor) and “zero” 724 as input; mux 764 can receive “mcurrentx” 726 (the x-dimensional loop counter value from the context), “melementsx-1” 728 (where melementsx is the elementsx value from the descriptor) and “zero” 732 as input; mux 766 can receive “mstridey” 734 (the stridey value from the descriptor) and “zero” 736 as input; mux 768 can receive “mcurrentx” 738 (the x-dimensional loop counter value from the context), “melementsy-1” 740 (where melementsy is the elementsy value from the descriptor) and “zero” 742 as input; mux 770 can receive "mstridez" 744 (the stridez value from the descriptor) and "zero" 746 as inputs; and mux 772 can receive "mcurrentz" 748 (the z-dimension loop counter value from the context) and "zero" 750 as inputs. Each multiplexer can select the relevant inputs and send them to multipliers 774, 776, and 778, and then those results can be sent to adders 780 and 782. The results of those additions can be sent to multiplexers 788 and 792, which will choose whether to store the result or the updated value in the corresponding registers 790 and 794, respectively.

[0083] For example, by Figure 6 The result of the calculation indicated by item 652 can be the output of multiplier 774, selected by mux 784, stored in register 786, and output as "stridey_adj" 752. Similarly, by Figure 6 The calculation result indicated by item 654 can be the output of adder 780, selected by mux 788, stored in register 790, and output as "stridez_adj" 756. Furthermore, by... Figure 6 The calculation result indicated by item 650 can be the output of adder 782, selected by mux792, stored in register 794, and output as “addr_offset” 758.

[0084] Figure 8A and Figure 8B Pseudocode (PC) is shown illustrating a method of a unified instruction processor for facilitating a DMA scatter / collection engine according to one aspect of this application, including determining the processing state and current context of IOWEC-D. Figure 8AThe PC 800 is shown, including annotations describing and defining it. Figure 8B The variables used in sections 812, 814, 816, 818, 820, 822, and 824 of PC 810. PC 800 is reproduced below (without the double forward slashes " / / " used to indicate that PC 800 represents a comment):

[0085] 1) The input of the MAC unit is mac_start[2].

[0086] 2) The output of the MAC unit is mac_done and mac_dtseqn_epnk (=IOVEC entry number).

[0087] 3) "tracker_ent_first_round" indicates that this is the first round of processing for the engine tracker entry.

[0088] 4) “start_of_message” indicates that the first data packet of the overall message is being processed.

[0089] 5) “inp_context.pkt_dn” indicates that the packet payload has been successfully delivered.

[0090] 6) "inp_context.noproc" indicates that this is a round of null processing for context passing.

[0091] 7) “do_icb_wait” means that the IVOEC entry cannot be processed and the processor needs to wait for the ICB entry to be submitted so that it can be accepted (and then the round of processing ends).

[0092] 8) “icb_list_sh_last_cyc” indicates that the list of ICB entries in the context was shifted to the right in the previous cycle, so the new head-of-list ICB entry has not yet been read.

[0093] 9) “did_ie_proc_ie_fetch” indicates that the IE_Proc IE_Fetch state transition has been completed in this round of processing.

[0094] 10) “ctxt_icb_valid[0]” indicates that the first ICB entry in the table is valid (it already contains the IOWEC entry group retrieved from the host memory).

[0095] 11) “inp_instr.trk_estt.stail” indicates that subsequent instructions to which the final context can be passed have not yet arrived.

[0096] 12) “inst_PRQ” indicates that the processor is in a “Put-Request” (DMA collection) engine instance.

[0097] 13) “inp_instr.eom” indicates that there are no subsequent instructions to pass the final context to it, and “ie_fetch_none” indicates that no more IOWEC entry groups are fetched.

[0098] 14) “icb_ent_avail” indicates that one or more ICB entries are available for allocation.

[0099] 15) "not_eligible_for_pyld_xfer" indicates that payload transfer cannot yet be performed on tracker entries that are being processed. Currently, it is only suitable for pre-fetching IOWEC entries.

[0100] 16) “icb_refcnt_acc” indicates that ICB can accept reference count update commands.

[0101] 17) “desc_idt.ent_per_nk” is the number of IOWEC entries mapped to an n kilobyte message payload (n is encoded separately in the descriptor). If ent_per_nk > 1, the MAC unit must be used to calculate the number of IOWEC entries.

[0102] Figure 8B PC 810 is shown with segments 812, 814, 816, 818, 820, 822, and 824, where each of segments 812-824 corresponds to the above description of... Figure 4C The described operations represent "if" or "else if" or "else" blocks. For example, segment 812 could correspond to... Figure 4C The decision 452 and operations 454 and 466; segment 814 can correspond to Figure 4C The decision 456 and operations 458 and 466; segment 816 can correspond to Figure 4C The decision 460 and operations 462 and 466; segment 818 can correspond to Figure 4C Operations 464 and 466; and segments 820, 822, and 824 can correspond to Figure 4C Operation 466 and Figure 4A Operation 408 in the PC 810 is reproduced below:

[0103]

[0104] Figure 9A schematic diagram 900 illustrates the processing state transitions of Derivative-DT and IOWEC-DT according to one aspect of this application. The “Idle” state 910 is depicted in dashed lines, indicating a “zero-time” state. An idle state may occur when a round of processing completes in a non-idle state and a new round of processing (of some other engine tracker entry) begins in a non-idle state in the next cycle. An idle state can be considered a “zero-time state”, i.e., a symbolic traversal of the idle state. For example, a symbolic zero-time traversal of the idle state may occur when the system transitions from the DSTT_CFF_Fetch state 920 to the ISTT_MAC_Wait state 930 or from the DSTT_CFF_Fetch state 920 to the DSTT_ICB_Wait state 922.

[0105] The Idle 910 state indicates that no processing is being performed in the current cycle and the system is waiting for input. The DSTT_CFF_Fetch state 920 indicates that context-FF information needs to be fetched from host memory. The system may allocate an ICB entry, issue a DMA read instruction, write the IoVEC context to the cache (listing the allocated ICB entries), and update the tracker entry to the DMA-waiting state. The DSTT_ICB_Wait state 922 indicates that the context is available (from the cache). The context type may be IoVEC (indicating that the context-FF has previously been fetched from host memory and exists in the "head" ICB entry listed in the context), and an ICB entry read may be in progress. The DSTT_MAC_Wait state 924 indicates that the basic context is ready and the MAC unit is performing computations on the extended context (e.g., as described above regarding...). Figure 6 The described stride*_adj and addr_offset).

[0106] The DSTT_Loop_Exec state 926 indicates that the complete context is ready. The system can execute a derived-DT nested loop. The system can issue DMA read / write commands for payload delivery and update addr_offset and byte_cnt. When state 926 is reached, the DTP can typically remain in this state until its output queue credits are exhausted or packet payload delivery is complete. State 926 can correspond to... Figure 4B Operation 436 and Figure 4A Operation 408. State 926 can also correspond to... Figure 5The function indicated in segments 510, 512, 514, and 516 of pseudocode 500 is "<Loop Exec> ".

[0107] The “DSTT_Skip” status 928 indicates that no derivative-DT processing can be performed in this cycle. This can occur for various reasons, such as the need to allocate ICB entries, but all ICB entries may currently be in use. The system exits this round of derivative-DT processing. If applicable, the system can start a new round of processing in the next cycle (for different engine tracker entries).

[0108] The "ISTT_MAC_Wait" status 930 indicates that an IVEC entry needs to be retrieved from host memory and the system (e.g., Figure 2 The MAC unit 244 is performing a calculation on the first entry in the IVOEC entries to be fetched. The “ISTT_IE_Fetch” state 932 indicates that an IVOEC entry needs to be fetched from host memory. The system may allocate an ICB entry, issue a DMA read command, and update the IVOEC context (e.g., add the allocated ICB entry to the list). State 932 can correspond to, for example,... Figure 8B The function indicated in segments 820, 822, and 824 of pseudocode 810 is "<IE_Fetch> The "ISTT_ICB_Wait" status 934 indicates that the IVOEC context is available, the IVOEC entry exists in the "first" ICB entry listed in the context, and ICB entry reading is in progress.

[0109] The "ISTT_IE_Proc" state 936 indicates that the IVEC context is available, the ICB entry reading is complete, and the IVEC entry is available for processing. The system can process the IVEC entry, issue DMA read / write commands, and update the context (e.g., IVEC_ent_ptr and byte_cnt). When state 936 is reached, the DTP typically remains in this state until its output queue credits are exhausted, all IVEC entries in the current ICB entry are consumed, or the packet payload delivery is complete. If all IVEC entries in the current ICB entry have been consumed, the DTP can transition to the STTT_IE_Fetch state 932 if additional IVEC entries need to be fetched. State 936 can correspond to... Figure 4C Operation 466 and Figure 4A Operation 408. State 936 can also correspond to... Figure 8B The function indicated in segment 820 of pseudocode 810 in the document is "<IE_Proc> ".

[0110] The “ISTT_Skip” status 938 indicates that no IVOEC-DT processing can be performed in this cycle. This can occur for various reasons, such as the need to allocate ICB entries, but all ICB entries may currently be in use. The system exits this round of IVOEC-DT processing. If applicable, the system can start a new round of processing in the next cycle (for different engine tracker entries).

[0111] Figure 10 An overview 1000 of byte mask processing according to one aspect of this application is shown. Overview 1000 includes: segment 1010, which depicts a derived-DT (“D-DT”); segment 1020, which depicts an IOWEC-DT; and items 1030, 1032, 1034, and 1036, which describe byte masks. Segment 1010 indicates the derived-DT, which describes a plurality of fixed-size elements arranged in a regular pattern in host memory, such as those described by multiple (e.g., 1, 2, 3) nested loops, where each loop has a specific step size value, such as stridex (1012), stridey (1014), or stridez (1016) by loop, as described above regarding... Figure 6 As described, segment 1010 may include data element 1018 (indicated by a square) having a maximum data element size (e.g., 256 bytes).

[0112] Segment 1020 indicates IOWEC-DT, which describes multiple fixed-size data elements arranged at random locations in host memory, as defined by IOWEC, such as @IOVEC[0].addr(1022), @IOVEC[1].addr(1024), and @IOVEC[2]addr(1026). Segment 1020 may include data element 1028 (represented by a square) with a maximum data element size (e.g., 256 bytes).

[0113] Item 1030 indicates that the maximum data element size can be 256 bytes. Item 1032 indicates that the configured data element size can be equal to the value of "Descriptor.block_size". "Descriptor.bs_last" can indicate the last x-dimensional element of the derived-DT, which can be part of a standard data element. Item 1034 indicates that "Descriptor.byte_mask" indicates the valid bytes in the data element, while "Descriptor.vld_bytes" represents the number of valid bytes. "Descriptor.vb_last" can indicate the last x-dimensional data element of the derived-DT—since the last x-dimensional data element can be part of a standard data element, it can contain a smaller number of valid bytes.

[0114] Item 1036 may indicate a single data element comprising portions 1040-1050. Shaded portions (e.g., 1041, 1043, 1045, 1047, and 1049) may indicate the valid bytes of data based on the byte mask represented by item 1034. Each arrow from item 1034 to the shaded portion may correspond to the length and offset of the data in host memory. For example, the valid bytes of a single data element 1036 may correspond to: bm_offset0 (1060) and bm_len0 (1061), corresponding to shaded portion 1049; bm_offset1 (1062) and bm_len1 (1063), corresponding to shaded portion 1047; bm_offset2 (1064) and bm_len2 (1065), corresponding to shaded portion 1045, and so on, where each shaded portion is represented by the values ​​of bm_offsetX and bm_lenX.

[0115] In a collect operation, a "full" data element, defined by "Descriptor.block_size", can be read from host memory, and valid bytes can be packed together into a data packet. In a scatter operation, a data element can be passed by taking multiple bytes (defined by "Descriptor.vld_bytes" from the received data packet) and scattering them across an address range in host memory (the address range of "Descriptor.block_size") (as defined by "Descriptor.byte_mask").

[0116] The value "elem_addr" indicates the address of the first byte of a data element in host memory. For derivational DTs, elem_addr can be defined by the address of the instruction input to the engine plus the offset reached by various steps produced through nested loop execution. For general IoVEC-DTs, elem_addr can be defined by the address from the IoVEC entry—possibly plus the address from the instruction (if the value of "Descriptor.relative" is equal to "1"). The first byte of the data element may or may not be valid, depending on the byte mask, but the byte mask does not affect elem_addr.

[0117] As needed, process in either "DSTT_Loop_Exec" or "ISTT_IE_Proc" state (respectively...). Figure 9 States 926 and 936 in the above, and respectively for the purposes of the above. Figure 2 In the derived-DT loop execution unit 208 and IVEC-DT execution unit 228, the DMA scatter engine can process bytemask data elements over multiple cycles. During DSTT_Loop_Exec state 926, the loop counter (e.g., "currentx") may not increment until all data elements have been processed. During ISTT_IE_Proc state 936, the DTP may remain on the same IVEC entry until all data elements have been processed. During bytemask processing (e.g., via... Figure 2 In the byte mask processing unit 246, the system can provide a series of offsets (bm_offsetN) and lengths (bm_lenN), with one offset / length pair per cycle. The system can create DMA instructions using offset / length pairs (e.g., via...). Figure 2 The DMA instruction forming unit (212 or 232) in the code generates a series of DMA write instructions. For example, based on... Figure 10 Item 1036: The "Write0" DMA instruction can indicate that bm_len0 bytes should be taken from the data packet and written to elem_addr+bm_offset0; the "Write1" DMA instruction can indicate that bm_len1 bytes should be taken from the data packet and written to elem_addr+bm_offset1; etc.

[0118] Figure 11A computer-readable medium 1100 is illustrated for a unified instruction processor (CRM) that facilitates a DMA scatter / collection engine according to one aspect of this application. The CRM 1100 may be a non-transitory computer-readable medium or device that stores instructions that, when executed by a computer or processor, cause the computer or processor to perform methods, including the methods and operations described herein. The CRM 1100 may store instructions 1110 for receiving input, including instructions for reading or writing a message payload, a tracker state indicating a round of processing of the instructions, and a data type descriptor defining the organization of the message payload, as described above. Figure 1 Inputs 168, 170, and 172 to DTP 126 and Figure 2 The inputs 252, 254, and 256 of DTP 200 are described.

[0119] CRM 1100 can store instruction 1120, which is used to identify the processing status and current context of the instruction, as mentioned above. Figure 2 The derived-DT processing state unit 204, the current derived-DT processing context unit 206, the IOWEC-DT processing state unit 224, and the current IOWEC-DT processing context unit 226 are as follows: Figure 4A , Figure 4B and Figure 4C The operations described above. Figure 5 The pseudocode 500 describes the processing state and current context for identifying the derived-DT. (This is in conjunction with the above.) Figure 8A and Figure 8B Pseudocodes 800 and 810 describe the identification of the processing state and current context of IOWEC-DT.

[0120] CRM 1100 can store instruction 1130 for retrieving the current context associated with the first type from host memory or cache in response to a data type descriptor indicating a first type (e.g., derived-DT), as described above. Figure 4B Operations 414, 416, 424, 426 and 430 are described in the text.

[0121] CRM 1100 can store instruction 1140, which sets the processing state to the first execution state in response to the data type descriptor indicating the first type, as mentioned above. Figure 4B Operation 436 in Figure 5 The pseudocode 500 contains segments 510, 512, 514, and 516 (i.e., "<Loop_Exec> ")as well as Figure 9 As described in DSTT_Loop_Exec state 926.

[0122] The CRM 1100 can store instruction 1150, which, in response to a data type descriptor indicating a first type, creates a Direct Memory Access (DMA) instruction corresponding to the received instruction by executing operations within a nested loop representing a multidimensional array structure of the first type, as described above. Figure 2 The derived-DT loop execution unit 208 and DMA instruction forming unit 212 in the middle and Figure 4A As described in operation 408.

[0123] CRM 1100 may store instruction 1160 for obtaining the current context associated with the second type by retrieving vector entries from the buffer in response to a data type descriptor indicating a second type (e.g., IOWEC-DT), as described above with respect to segments 820, 822 and 824 of pseudocode 810 in Figure 8.

[0124] CRM 1100 can store instruction 1170, which, in response to a data type descriptor indicating a second type, sets the processing state to a second execution state, as described above. Figure 4C Operation 466 in Figure 8, segments 820, 822, and 824 in pseudocode 810 in Figure 8, and... Figure 9 The states described in 930-938.

[0125] The CRM 1100 can store instruction 1180, which, in response to a data type descriptor indicating a second type, creates a DMA instruction corresponding to the received instruction based on the address and length in the vector entry of the second type, as mentioned above. Figure 2 The IOWEC-DT execution unit 228 and DMA instruction forming unit 232 in the middle and Figure 4A As described in operation 408.

[0126] CRM 1100 can include more Figure 11 The instructions shown are more than just those instructions. For example, the CRM 1100 can also store instructions for performing the above operations, which relate to: Figure 1 The architecture in; Figure 2 Communication and operation within; Figure 4A , Figure 4B and Figure 4C The operations described in the flowchart; and Figure 5 , Figure 8A and Figure 8B The pseudocode in the text.

[0127] Generally, the disclosed aspects provide a method for a unified instruction processor, a NIC, and a non-transient computer-readable storage medium for facilitating a DMA scatter / collection engine. In one aspect, the system receives input via processing resources in a network interface card (NIC), the input including instructions for reading or writing a message payload, a tracker state indicating a round of processing of the instructions, and a data type descriptor defining the organization of the message payload. The system identifies the processing state and current context of the instructions. In response to the data type descriptor indicating a first type, the system performs the following operations: obtains the current context associated with the first type from host memory or the NIC's cache; sets the processing state to a first execution state; and creates a direct memory access (DMA) instruction corresponding to the received instruction by performing operations in a nested loop representing a multidimensional array structure of the first type. In response to the data type descriptor indicating a second type, the system performs the following operations: obtains the current context associated with the second type by extracting a vector entry from the NIC's buffer; sets the processing state to a second execution state; and creates a DMA instruction corresponding to the received instruction based on the address and length in the vector entry of the second type.

[0128] In variations of this approach, the first type of data type descriptor includes a representation of a multidimensional array structure, which includes multiple elements in each dimension, the size of the elements to be passed, and the step size in each dimension. The second type of data type descriptor includes a reference to an input / output vector (IOVEC) with entries indicating the address and length of data to be read from or written to host memory.

[0129] In other variations of this aspect, in response to a data type descriptor indicating a first type, the system performs at least one of the following operations: in response to determining that processing of an instruction is not in the first cycle of the current round of processing, obtaining the current context from the updated context of the previous processing cycle; in response to determining that processing of an instruction is in the first cycle of the current round of processing and associated with a first data packet of a message, inferring the current context by initializing the base context with zeros and calculating the extended context; in response to the input including the current context and in response to the context type indicating a second type, determining the current context by obtaining the base context from a buffer and calculating the extended context; in response to the context type indicating a first type, obtaining the current context from a cache; in response to the message corresponding to a GET response data packet associated with a previous GET request, obtaining the current context by retrieving the previously stored context associated with the GET request and calculating the extended context; or in response to detecting that no corresponding entry for the current context is found in the buffer, obtaining the current context by allocating an entry in the buffer and issuing a DMA read to retrieve the context from host memory.

[0130] In another variant, the system computes the extended context by calculating the address offset to be used when performing operations in a nested loop using the multiply-accumulate (MAC) unit, where the nested loop represents a multidimensional array structure of type 1.

[0131] In another variant, the system calculates the address offset by: calculating step size adjustments in at least two dimensions of the multidimensional array structure by the MAC unit before performing operations in the nested loop; and identifying the current position of the processing in the nested loop based on the calculated adjustments, thereby eliminating the need to calculate the address offset for each operation in the nested loop.

[0132] In another variant, in response to a data type descriptor indicating a second type, the system performs at least one of the following operations: in response to determining that processing of an instruction is not in the first cycle of the current round of processing, obtaining the current context from the updated context of a previous processing cycle; in response to determining that processing of an instruction is in the first cycle of the current round of processing and is associated with a first data packet of a message, obtaining the current context by initializing the current context with zeros and setting the context type to indicate the second type; in response to determining that the current context is received as input by the processor, obtaining the current context from a cache; or obtaining the current context by initializing the current context with zeros and setting the context type to indicate the second type.

[0133] In another variant, in response to a data type descriptor indicating a second type, the system identifies the processing state of an instruction based on at least one of the following: whether the current context is included as input to the processing resource; whether payload delivery has been completed; whether the current round of processing includes an empty round; whether a new context list first entry has been read from the buffer; whether an IVOEC entry has been fetched from host memory; whether the context list first entry in the buffer is valid; whether the message payload includes a GET response packet associated with a previous GET request handled by the processing resource; whether the value indicates that no more IVOEC entries will be fetched; whether one or more buffer entries are available for allocation; whether the message payload associated with the instruction is suitable for payload delivery or IVOEC entry fetching; or whether the processing of the instruction is in the first cycle of the current round of processing.

[0134] In another variant, the system identifies IVOEC entries via a multiply-accumulate (MAC) unit that addresses the first byte of the message payload based on at least one of the following: a data type offset included in the instruction and indicating a byte offset within the message payload corresponding to the first byte of the message payload; a predetermined number of bytes corresponding to a byte group; a sequence number associated with the data type offset; or the value of a plurality of IVOEC entries indicating the addressing of the corresponding byte group of the message payload.

[0135] In another variant, in response to determining whether a data type descriptor indicates a first or second type, the system determines a byte mask for creating a DMA instruction, wherein the byte mask includes bits indicating whether the corresponding byte of a data element is valid. Creating a DMA instruction corresponding to an instruction by performing operations in a nested loop includes: obtaining a first series of offsets and lengths by applying a byte mask to the operations in the nested loop; and creating the DMA instruction based on the obtained first series of offsets and lengths. Creating a DMA instruction corresponding to an instruction based on addresses and lengths in vector entries includes: obtaining a second series of offsets and lengths by applying a byte mask to the vector entries; and creating the DMA instruction based on the obtained second series of offsets and lengths.

[0136] In another variant, the system transfers at least one of the created DMA instructions. In response to transferring the at least one created DMA instruction, the system performs at least one of the following: in response to determining that the current round of processing of the instruction has not yet been completed or that the processing of the instruction has not yet been completed, re-loops the current context; or in response to determining that the current round of processing of the instruction has been completed or that the processing of the instruction has been completed, writes the current context to a cache.

[0137] Another aspect provides a network interface card (NIC) with a circuit system for performing the operations described herein, as mentioned above regarding, for example... Figure 1 Engine 110 in the middle Figure 2 DTP 200 in Figure 4A , Figure 4B and Figure 4C Operations and Figure 5 , Figure 8A and Figure 8B The pseudocode described in the document.

[0138] Furthermore, another aspect provides a non-transitory computer-readable storage medium that stores instructions, which, when executed by a computer, cause the computer to perform the methods and operations described herein, as described above for example... Figure 1 Engine 110 in the middle Figure 2 DTP 200 in Figure 4A , Figure 4B and Figure 4C Operations and Figure 5 , Figure 8A and Figure 8B The pseudocode described in the document.

[0139] The descriptions of the above aspects are presented for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Furthermore, the above disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A computer-implemented method, the method comprising: Input is received through processing resources in a network interface card (NIC), including instructions for reading or writing the payload of a message, a tracker state indicating a round of processing of the instructions, and a data type descriptor defining the organization of the message payload; Identify the processing status and current context of the instruction; In response to the data type descriptor indicating a first type: Obtain the current context associated with the first type from the host memory or the NIC's cache; Set the processing state to the first execution state; as well as A direct memory access (DMA) instruction corresponding to a received instruction is created by performing operations in a nested loop, the nested loop representing a multidimensional array structure of the first type; as well as In response to the data type descriptor indicating a second type: The current context associated with the second type is obtained by extracting vector entries from the buffer of the NIC; Set the processing state to the second execution state; and Based on the address and length in the vector entry of the second type, a DMA instruction corresponding to the received instruction is created.

2. The method as described in claim 1, in, The first type of data type descriptor includes a representation of the multidimensional array structure, which includes multiple elements in each dimension, the size of the element to be transmitted, and the step size in each dimension; and The second type of data type descriptor includes a reference to an input / output vector (IOVEC) having entries indicating the address and length of data to be read from or written to the host memory.

3. The method of claim 2, wherein in response to the data type descriptor indicating the first type, the method further comprises at least one of the following: In response to determining that processing of the instruction is not in the first cycle of the current processing round, the current context is obtained from the updated context of the previous processing cycle; In response to determining that the processing of the instruction is in the first cycle of the current round of processing and is associated with the first data packet of the message, the current context is inferred by initializing the base context with zeros and calculating the extended context; In response to the input including the current context and in response to the context type indicating the second type, the current context is determined by obtaining the basic context from the buffer and calculating the extended context; In response to the context type indicating the first type, the current context is obtained from the cache; In response to the message corresponding to a GET response packet associated with a previous GET request, the current context is obtained by retrieving the previously stored context associated with the GET request and calculating the extended context; or In response to the detection that there is no corresponding entry for the current context in the buffer, the current context is obtained by allocating an entry in the buffer and issuing a DMA read to retrieve the context from the host memory.

4. The method of claim 3, wherein calculating the extended context comprises: The address offset to be used when performing the operation in the nested loop representing the multidimensional array structure of the first type is calculated by the multiply-accumulate (MAC) unit.

5. The method of claim 4, wherein calculating the address offset comprises: Before performing the operation in the nested loop, the MAC unit calculates the step size adjustment in at least two dimensions of the multidimensional array structure. as well as Based on the calculated adjustment, the current position processed in the nested loop is identified, thereby eliminating the need to calculate address offsets for each operation in the nested loop.

6. The method of claim 2, wherein in response to the data type descriptor indicating the second type, the method further comprises at least one of the following operations: In response to determining that processing of the instruction is not in the first cycle of the current processing round, the current context is obtained from the updated context of the previous processing cycle; In response to determining that the processing of the instruction is in the first cycle of the current round of processing and associated with the first data packet of the message, the current context is obtained by initializing the current context with zeros and setting the context type to indicate the second type; In response to determining that the current context is received as input by the processor, the current context is obtained from the cache; or The current context is obtained by initializing the current context with zero and setting the context type to the second type.

7. The method of claim 2, wherein in response to the data type descriptor indicating the second type, the method further comprises: The processing state of the instruction is identified based on at least one of the following: Whether the current context is included as input to the processing resource; Has the payload transfer been completed? Does the current wheel processing include empty wheel processing? Has the first entry of the new context list in the buffer been read? Has the IOWEC entry been retrieved from host memory? Is the first entry of the context list in the buffer valid? Does the message payload include a GET response data packet associated with a previous GET request handled by the processing resource? The value indicates whether to no longer fetch any IVOEC entries; Are there one or more buffer entries available for allocation? Whether the message payload associated with the instruction is suitable for payload delivery or IOWEC entry extraction; or Whether the processing of the instruction is in the first cycle of the current round of processing.

8. The method of claim 2, further comprising: The multiply-accumulate (MAC) unit identifies the IOWEC entry addressing the first byte of the message payload based on at least one of the following: Data type offset, which is included in the instruction and indicates a byte offset within the message payload corresponding to the first byte of the message payload; A predetermined number of bytes corresponding to a set of bytes; The serial number associated with the offset of the data type; or The values ​​of multiple IOWEC entries that indicate the addressing of the corresponding byte group of the payload.

9. The method of claim 2, further comprising: In response to determining that the data type descriptor indicates the first type or the second type, the data type descriptor indicates a byte mask to be used to create the DMA instruction, wherein the byte mask includes bits indicating whether the corresponding byte of the data element is valid; The DMA instruction corresponding to the instruction is created by performing operations within the nested loop, including: By applying the byte mask to the operation within the nested loop, the offsets and lengths of the first series are obtained; and The DMA instructions are created based on the obtained first series of offsets and lengths; and The creation of the DMA instruction corresponding to the instruction based on the address and length in the vector entry includes: The offset and length of the second series are obtained by applying the byte mask to the vector entries; and The DMA instructions are created based on the obtained second series of offsets and lengths.

10. The method of claim 1, further comprising: Transfer at least one DMA instruction from the created DMA instructions; In response to the transfer of the at least one created DMA instruction, perform at least one of the following operations: In response to determining that the current round of processing for the instruction has not yet been completed or that the processing of the instruction has not yet been completed, the current context is re-looped; or In response to determining that the current round of processing for the instruction has been completed or that the processing of the instruction has been completed, the current context is written to the cache.

11. A network interface card (NIC) including circuitry, said circuitry being used for: The input is received through the processing resources of the NIC, and the input includes instructions for reading or writing the payload of a message, a tracker state indicating a round of processing of the instructions, and a data type descriptor defining the organization of the message payload; Identify the processing status and current context of the instruction; In response to the data type descriptor indicating a first type: Obtain the current context associated with the first type from the host memory or the NIC's cache; Set the processing state to the first execution state; as well as A direct memory access (DMA) instruction corresponding to a received instruction is created by performing operations in a nested loop, the nested loop representing a multidimensional array structure of the first type; as well as In response to the data type descriptor indicating a second type: The current context associated with the second type is obtained by extracting vector entries from the buffer of the NIC; Set the processing state to the second execution state; and Based on the address and length in the vector entry of the second type, a DMA instruction corresponding to the received instruction is created.

12. The NIC as claimed in claim 11, in, The first type of data type descriptor includes a representation of the multidimensional array structure, which includes multiple elements in each dimension, the size of the element to be transmitted, and the step size in each dimension; and The second type of data type descriptor includes a reference to an input / output vector (IOVEC) having entries indicating the address and length of data to be read from or written to the host memory.

13. The NIC as claimed in claim 12, wherein, In response to the data type descriptor indicating the first type, the circuit is further configured to: In response to determining that processing of the instruction is not in the first cycle of the current processing round, the current context is obtained from the updated context of the previous processing cycle; In response to determining that the processing of the instruction is in the first cycle of the current round of processing and is associated with the first data packet of the message, the current context is inferred by initializing the base context with zeros and calculating the extended context; In response to the input including the current context and in response to the context type indicating the second type, the current context is determined by obtaining the basic context from the buffer and calculating the extended context; In response to the context type indicating the first type, the current context is obtained from the cache; In response to the message corresponding to a GET response packet associated with the previous GET request, the current context is obtained by retrieving the previously stored context associated with the GET request and calculating the extended context; as well as In response to the detection that there is no corresponding entry for the current context in the buffer, the current context is obtained by allocating an entry in the buffer and issuing a DMA read to retrieve the context from the host memory.

14. The NIC of claim 13, wherein the circuitry for calculating the extended context is further configured to: The address offset to be used when performing the operation in the nested loop representing the multidimensional array structure of the first type is calculated by the multi-accumulator (MAC) unit of the NIC; in, The circuit used to calculate the address offset is further used for: Before performing the operation in the nested loop, the MAC unit calculates the step size adjustment in at least two dimensions of the multidimensional array structure. as well as Based on the calculated adjustment, the current position processed in the nested loop is identified, thereby eliminating the need to calculate address offsets for each operation in the nested loop.

15. The NIC as claimed in claim 12, wherein, In response to the data type descriptor indicating the second type, the circuit is further configured to: In response to determining that processing of the instruction is not in the first cycle of the current round of processing, the current context is obtained from the cache; In response to determining that the processing of the instruction is in the first cycle of the current round of processing and associated with the first data packet of the message, the current context is obtained by initializing the current context with zeros and setting the context type to indicate the second type; In response to determining that the current context is received as input by the processor, the current context is obtained from the cache; as well as The current context is obtained by initializing the current context with zeros and setting the context type to the second type.

16. The NIC as claimed in claim 12, wherein, In response to the data type descriptor indicating the second type, the circuit is further configured to: The processing state of the instruction is identified based on at least one of the following: Whether the current context is included as input to the processing resource; Has the payload transfer been completed? Does the current wheel processing include empty wheel processing? Has the first entry of the new context list in the buffer been read? Has the IOWEC entry been retrieved from host memory? Is the first entry of the context list in the buffer valid? Does the message payload include a GET response data packet associated with a previous GET request handled by the processing resource? The value indicates whether to no longer fetch any IVOEC entries; Are there one or more buffer entries available for allocation? Whether the message payload associated with the instruction is suitable for payload delivery or IOWEC entry extraction; or Whether the processing of the instruction is in the first cycle of the current round of processing.

17. The NIC of claim 12, wherein the circuitry is further configured to: The multiply-accumulate (MAC) unit identifies the IOWEC entry addressing the first byte of the message payload based on at least one of the following: Data type offset, which is included in the instruction and indicates a byte offset within the message payload corresponding to the first byte of the message payload; A predetermined number of bytes corresponding to a set of bytes; The serial number associated with the offset of the data type; or The values ​​of multiple IOWEC entries that indicate the addressing of the corresponding byte group of the payload.

18. The NIC of claim 12, wherein the circuitry is further configured to: In response to determining that the data type descriptor indicates the first type or the second type, the data type descriptor indicates a byte mask to be used to create the DMA instruction, wherein the byte mask includes bits indicating whether the corresponding byte of the data element is valid; in, The circuitry used to create the DMA instruction corresponding to the instruction by performing operations in the nested loop is further configured to: The offsets and lengths of the first series are obtained by applying the byte mask to the operation within the nested loop; as well as The DMA instructions are created based on the obtained first series of offsets and lengths; and The circuitry used to create the DMA instruction corresponding to the instruction based on the address and length in the vector entry is further configured to: The offset and length of the second series are obtained by applying the byte mask to the vector entries; and The DMA instructions are created based on the obtained second series of offsets and lengths.

19. The NIC of claim 11, wherein the circuitry further comprises: Transfer at least one DMA instruction from the created DMA instructions; In response to transmitting the at least one created DMA command, the circuitry is further configured to: In response to determining that the current round of processing for the instruction has not yet been completed or that the processing of the instruction has not yet been completed, the current context is re-looped; as well as In response to determining that the current round of processing for the instruction has been completed or that the processing of the instruction has been completed, the current context is written to the cache.

20. A non-transient computer-readable medium storing instructions, the instructions being used to: Receive input, which includes instructions for reading or writing the payload of a message, a tracker state indicating a round of processing of the instructions, and a data type descriptor defining the organization of the message payload; Identify the processing status and current context of the instruction; In response to the data type descriptor indicating a first type: Obtain the current context associated with the first type from host memory or cache; Set the processing state to the first execution state; as well as A direct memory access (DMA) instruction corresponding to a received instruction is created by performing operations in a nested loop, the nested loop representing a multidimensional array structure of the first type; as well as In response to the data type descriptor indicating a second type: The current context associated with the second type is obtained by extracting vector entries from the buffer; Set the processing state to the second execution state; and Based on the address and length in the vector entry of the second type, a DMA instruction corresponding to the received instruction is created.

Images