DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7-13 and 15-19 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Bernath (U.S. Patent Application Publication 2017/0180272 A1).
Regarding claim 1, Bernath discloses a data processing unit (DPU) comprising:
one or more circuits (FIGS. 1A and 1B; paragraph [0038], one network interface card (NIC) 102) to:
obtain information transmitted (Paragraph [0041], a processor within the NIC 102 executes an algorithm comprising computer-readable instructions to filter each of the incoming packets and place each of the packets into a corresponding buffer. The algorithm analyzes information in the header and/or the payload to determine which buffer the packet should be inserted into. While being received, and filtered, each packet is assigned an index by the NIC 102 that indicates where the packet is being stored in memory ...; paragraph [0046], the NIC 102 receives packets and filters the packets ... the packets are assigned an index by the NIC 102) in a plurality of transmission control protocol (TCP) data packets (FIG. 2; paragraph [0069], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS); and
store data, based at least in part on the information (Paragraph [0041], the NIC 102 receives packets, groups similar packets together, assigns an index to each packet, and stores the similar packets in a particular one of the buffers 109), in a graphics processing unit (GPU) memory (Paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 2, Bernath discloses everything claimed as applied above (see claim 1), and Bernath further disclose wherein the one or more circuits are to reorder the TCP data packets to assemble the information into a data file (FIGS. 1 and 2; paragraphs [0069]-[0070], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS ... the NIC 102 will notify the GPU 104 via memory interrupt, and the packets will be processed by a specialized kernel of the GPU 104 specific for the packet type ... the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA. Each of the buffers may have a capped size or flow capacity and each buffer includes an index file 214 created by the NIC 102 that provides an offset of a start of each packet in GPU memory), and the data is to comprise the data file (Paragraph [0070], the first packet is located at memory offset 56. A second packet may have an index 2 that points to memory offset 70, where the memory begins at 0 and ends at 128. Thus, the second packet is located at memory offset 70. The index file 214 will list each index in the buffer and an offset in GPU memory that each index points to).
Regarding claim 3, Bernath discloses everything claimed as applied above (see claim 1), and Bernath further disclose wherein the one or more circuits are to use a direct memory access (DMA) transfer protocol to store the data in the GPU memory (FIGS. 1A, 1B and 2; paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 4, Bernath discloses everything claimed as applied above (see claim 1), and Bernath further disclose wherein the one or more circuits are to indicate to at least one GPU that the data has been stored in the GPU memory (FIGS. 1A, 1B and 2; paragraph [0052], the NIC 102 may be notified by the GPU 104 that output packets are stored in GPU memory in an output buffer and ready for transmission using DMA).
Regarding claim 5, Bernath discloses everything claimed as applied above (see claim 1), and Bernath further disclose wherein the one or more circuits are to receive an indication from at least one GPU to indicate that the at least one GPU successfully accessed the data stored in the GPU memory (Paragraph [0037], when the GPU has processed the buffer and is ready to transmit data to the network controller, the GPU may notify the NIC that the buffer has been processed by using memory based transaction across the high speed bus. The GPU may deliver the data directly to the NIC using direct memory access bypassing the CPU; FIGS. 1, 2 and 3; paragraph [0077], if there is an output, then in step 316, the GPU 104 will store output packets or data in output buffer(s) and set an index for the data in the output buffer(s). If an output packet is not created, then the GPU 104 may create an index entry that indicates that no output packet was created. The GPU 104 can optionally set an output flag indicating that the output buffer(s) is ready that will be used to notify a kernel. In step 318, a kernel may be spawned by the GPU 104 to notify the NIC 102 that there is data in the output buffer(s) of the GPU 104 that is ready to transmit by sending the NIC 102 the index for the data in the output buffer. The NIC 102 will send the data stored in the output buffer in the GPU 104 using DMA).
Regarding claim 7, Bernath discloses a system (Paragraph [0038], FIGS. 1A and 1B illustrate block diagrams of a system for accelerating network applications using an enhanced network interface and massively parallel distributed processing 100 according to an example embodiment) comprising:
memory (Paragraph [0039], buffers 109); and
at least one parallel processing unit (PPU) (Paragraph [0028], the GPU is one example of successful massively parallel processing) connected to the memory (Paragraph [0045], the GPU 104 receives data in the buffers 109, monitors interrupts associated with the buffers 109, and processes the data in the buffers 109) and comprising one or more circuits (Paragraph [0061], each CPU 106 in the system 100 can have its own “island” and be connected to at least one NIC 102, at least one GPU 104, and at least one optional storage 108 over the bus 113) to:
access data (Paragraph [0077], a kernel may be spawned by the GPU 104 to notify the NIC 102 that there is data in the output buffer(s) of the GPU 104 that is ready to transmit by sending the NIC 102 the index for the data in the output buffer. The NIC 102 will send the data stored in the output buffer in the GPU 104 using DMA) stored in the memory by a data processing unit (DPU) (Paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA) that was obtained by the DPU from a message transmitted(Paragraph [0041], a processor within the NIC 102 executes an algorithm comprising computer-readable instructions to filter each of the incoming packets and place each of the packets into a corresponding buffer. The algorithm analyzes information in the header and/or the payload to determine which buffer the packet should be inserted into. While being received, and filtered, each packet is assigned an index by the NIC 102 that indicates where the packet is being stored in memory ...; paragraph [0046], the NIC 102 receives packets and filters the packets ... the packets are assigned an index by the NIC 102) in accordance with Transmission Control Protocol (TCP) (FIG. 2; paragraph [0069], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS); and
transmit an acknowledgement to the DPU indicating that the data has been accessed (FIGS. 1, 2 and 3; paragraph [0077], if there is an output, then in step 316, the GPU 104 will store output packets or data in output buffer(s) and set an index for the data in the output buffer(s). If an output packet is not created, then the GPU 104 may create an index entry that indicates that no output packet was created. The GPU 104 can optionally set an output flag indicating that the output buffer(s) is ready that will be used to notify a kernel. In step 318, a kernel may be spawned by the GPU 104 to notify the NIC 102 that there is data in the output buffer(s) of the GPU 104 that is ready to transmit by sending the NIC 102 the index for the data in the output buffer. The NIC 102 will send the data stored in the output buffer in the GPU 104 using DMA).
Regarding claim 8, Bernath discloses everything claimed as applied above (see claim 7), and Bernath further disclose wherein the one or more circuits are to:
detect the data has been stored in the memory by the DPU before accessing the data (FIGS. 1A, 1B and 2; paragraph [0052], the NIC 102 may be notified by the GPU 104 that output packets are stored in GPU memory in an output buffer and ready for transmission using DMA).
Regarding claim 9, Bernath discloses a data center comprising:
a plurality of graphics processing units (GPUs) (FIGS. 1A and 1B; paragraph [0043], a GPU 104); and
a data processing unit (DPU) (Paragraph [0041], a processor within the NIC 102) comprising:
a network adapter (Paragraph [0038], one network interface card (NIC) 102) configured to receive a plurality of data packets (Paragraph [0041], the NIC 102 receives packets,);
at least one server to receive the plurality of data packets (FIG. 2; paragraph [0069], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS) and obtain processed data by processing the plurality of data packets (Paragraph [0041], a processor within the NIC 102 executes an algorithm comprising computer-readable instructions to filter each of the incoming packets and place each of the packets into a corresponding buffer. The algorithm analyzes information in the header and/or the payload to determine which buffer the packet should be inserted into. While being received, and filtered, each packet is assigned an index by the NIC 102 that indicates where the packet is being stored in memory ...; paragraph [0046], the NIC 102 receives packets and filters the packets ... the packets are assigned an index by the NIC 102); and
a transfer engine to transfer the processed data (Paragraph [0041], the NIC 102 receives packets, groups similar packets together, assigns an index to each packet, and stores the similar packets in a particular one of the buffers 109) to a memory of at least one of the plurality of GPUs (Paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 10, Bernath discloses everything claimed as applied above (see claim 9), and Bernath further disclose wherein the plurality of data packets comprise a plurality of transmission control protocol (TCP) data packets (FIG. 2; paragraph [0069], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS).
Regarding claim 11, Bernath discloses everything claimed as applied above (see claim 10), and Bernath further disclose wherein the at least one server is to assemble a data file by reordering the TCP data packets (FIGS. 1 and 2; paragraphs [0069]-[0070], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS ... the NIC 102 will notify the GPU 104 via memory interrupt, and the packets will be processed by a specialized kernel of the GPU 104 specific for the packet type ... the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA. Each of the buffers may have a capped size or flow capacity and each buffer includes an index file 214 created by the NIC 102 that provides an offset of a start of each packet in GPU memory), and the processed data is to comprise the data file (Paragraph [0070], the first packet is located at memory offset 56. A second packet may have an index 2 that points to memory offset 70, where the memory begins at 0 and ends at 128. Thus, the second packet is located at memory offset 70. The index file 214 will list each index in the buffer and an offset in GPU memory that each index points to).
Regarding claim 12, Bernath discloses everything claimed as applied above (see claim 9), and Bernath further disclose wherein the transfer engine is to use a direct memory access (DMA) transfer protocol to store the processed data in the memory of the at least one GPU (FIGS. 1A, 1B and 2; paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 13, Bernath discloses everything claimed as applied above (see claim 9), and Bernath further disclose wherein the DPU is to indicate to the at least one GPU that the processed data has been stored in the memory of the at least one GPU (FIGS. 1A, 1B and 2; paragraph [0052], the NIC 102 may be notified by the GPU 104 that output packets are stored in GPU memory in an output buffer and ready for transmission using DMA).
Regarding claim 15, Bernath discloses everything claimed as applied above (see claim 9), and Bernath further disclose further comprising:
at least one computing system comprising the plurality of GPUs (FIGS. 1A and 1B; paragraph [0043], a GPU 104), the DPU (Paragraph [0041], a processor within the NIC 102), and at least one central processing unit (CPU) (Paragraph [0043], CPU 106), wherein the at least one server (Paragraph [0078], the system 100 may be incorporated into a web server 402 that provides parallel protocol processing as shown in FIG. 4A. The web server 402 executes at least one application 403 that can be used to handle a very large number of socket connections. The web server 402 comprises one or more NIC(s) 102, one or more GPU(s) 104, one or more CPU(s) 106) is to obtain the processed data without involving the CPU (Paragraph [0082], when the web server 402 receives an HTTP request for a file over a TCP connection, the web server 402 may generate a Network File System (NFS) request payload. This payload may be passed to the NIC 102, and the NIC 102 may insert active NFS connection information into the HTTP request. When NFS response data is returned from a server, the NIC 102 may place the NFS response data into a buffer in GPU memory that is used for NFS content replies. The GPU 104 may generate an appropriate TCP reply, e.g., SEQ/ACK numbers, and return a packet to the NIC 102 as shown in FIG. 4B. The NIC 102 may also be configured to generate HTTP/TCP reply packets if the NIC 102 is used to store required stream parameters), and the transfer engine is to transfer the processed data to the memory without involving the CPU (Paragraph [0082], when NFS response data is returned from a server, the NIC 102 may place the NFS response data into a buffer in GPU memory that is used for NFS content replies).
Regarding claim 16, Bernath discloses a method comprising:
obtaining, by at least one data processing unit (DPU) (FIGS. 1A and 1B; paragraph [0041], a processor within the NIC 102). information transmitted (Paragraph [0041], a processor within the NIC 102 executes an algorithm comprising computer-readable instructions to filter each of the incoming packets and place each of the packets into a corresponding buffer. The algorithm analyzes information in the header and/or the payload to determine which buffer the packet should be inserted into. While being received, and filtered, each packet is assigned an index by the NIC 102 that indicates where the packet is being stored in memory ...; paragraph [0046], the NIC 102 receives packets and filters the packets ... the packets are assigned an index by the NIC 102) in a plurality of transmission control protocol (TCP) data packets (FIG. 2; paragraph [0069], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS); and
storing, by the at least one DPU, data, based at least in part on the information (Paragraph [0041], the NIC 102 receives packets, groups similar packets together, assigns an index to each packet, and stores the similar packets in a particular one of the buffers 109), in memory associated with a graphics processing unit (GPU) (Paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 17, Bernath discloses everything claimed as applied above (see claim 16), and Bernath further disclose wherein the at least one DPU is to reorder the TCP data packets to assemble the information into a data file (FIGS. 1 and 2; paragraphs [0069]-[0070], the NIC 102 filters the incoming packets into groups of similar packets using the processing model derived from the associated algorithm. For protocols, such as transmission control protocol (TCP), packets may be grouped by the NIC 102 by packet type, e.g., TCP FLAGS ... the NIC 102 will notify the GPU 104 via memory interrupt, and the packets will be processed by a specialized kernel of the GPU 104 specific for the packet type ... the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA. Each of the buffers may have a capped size or flow capacity and each buffer includes an index file 214 created by the NIC 102 that provides an offset of a start of each packet in GPU memory), and the data is to comprise the data file (Paragraph [0070], the first packet is located at memory offset 56. A second packet may have an index 2 that points to memory offset 70, where the memory begins at 0 and ends at 128. Thus, the second packet is located at memory offset 70. The index file 214 will list each index in the buffer and an offset in GPU memory that each index points to).
Regarding claim 18, Bernath discloses everything claimed as applied above (see claim 16), and Bernath further disclose wherein storing the data comprises using a direct memory access (DMA) transfer protocol to store the data in the memory associated with the GPU (FIGS. 1A, 1B and 2; paragraph [0070], the NIC 102 processes and filters incoming packets into a buffer of TCP SYN packets 204, a buffer of TCP ACK packets 206, a buffer of HTTP GET packets 208, a buffer of NFS DATA packets 210, a buffer of RADIUS packets 212, etc. Each of these buffers may be stored in GPU memory by the NIC 102 using DMA).
Regarding claim 19, Bernath discloses everything claimed as applied above (see claim 16), and Bernath further disclose wherein the at least one DPU is to indicate to the GPU that the data has been stored in the memory associated with the GPU (FIGS. 1A, 1B and 2; paragraph [0052], the NIC 102 may be notified by the GPU 104 that output packets are stored in GPU memory in an output buffer and ready for transmission using DMA).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 6, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bernath (U.S. Patent Application Publication 2017/0180272 A1) in view of Rossetti (U.S. Patent Application Publication 2015/0039793 A1).
Regarding claim 6, Bernath discloses everything claimed as applied above (see claim 1).
However, Bernath does not specifically disclose wherein the one or more circuits are to receive an indication from at least one GPU to indicate that the at least one GPU is ready to receive additional data.
In additional, Rossetti discloses (Abstract, a Network Interface Card (NIC) for a cluster node for parallel calculation on multi-core GPU is described. The NIC has a cluster network including a host and a host memory, a graphics processing unit (GPU) with a GPU memory, a bus and the NIC. The NIC has a transmission network connection block and a reception network connection block. The NIC further includes the following blocks: a transmission block, a reception block, and a GPU memory management block for a direct exchange between the GPU memory and the network through the NIC ...) wherein the one or more circuits are to receive an indication from at least one GPU (FIGS. 1 and 2 show GPU) to indicate that the at least one GPU is ready to receive additional data (Paragraphs [0111]-[0114], the P2P GPU RX feature, which is part of this invention, allows for the NIC to autonomously carry on the RX operation of a message targeted to a GPU memory buffer ... the proposed method extends the RDMA technique (prior-art) to GPU memory buffers, and relies on the application running on the host to pre-register GPU RX buffers before their use (prior art) on the NIC_GPU_RX (patenting block) ... a. NIC_GPU_RX triggers the NIC_GPU_DMA, which manipulates the GPU to make it accessible the memory region from the bus. ... b. NIC_GPU_DMA does its work by proper writing some GPU configuration registers. ... c. NIC_GPU_RX generates a DMA transaction on the bus to move the data corresponding to the sub-range Ij from RX_BUFFERS to the GPU memory ... NIC_EQ block, as a completion signal of the whole RX operation, writes an event onto the event queue (EQ) in host memory (prior art). The event is got by the application that processes the just received memory buffers; paragraph [0104], NIC_EQ block, signaling the operation completion, writes some event data structure in a proper (either GPU or host) memory area which acts as an event queue (EQ). In this way the application is signaled that the GPU memory has been read and can be reused. Thus, an event onto the event queue (EQ) in host memory indicates that the reused memory of GPU is ready to receive additional data).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the a system for accelerating network applications using an enhanced network interface and massively parallel distributed processing taught by Bernath incorporate the teachings of Rossetti, and applying the events queues management block taught by Rossetti to provide the events queues between the graphics processing unit (GPU) and the data processing unit (DPU) in order to indicate that the GPU is ready to receive additional data. Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify Bernath according to the relied-upon teachings of Rossetti to obtain the invention as specified in claim.
Regarding claim 14, Bernath discloses everything claimed as applied above (see claim 9).
However, Bernath does not specifically disclose wherein the DPU is to receive an indication from the at least one GPU to indicate that the at least one GPU is ready to receive additional data.
In additional, Rossetti discloses (Abstract, a Network Interface Card (NIC) for a cluster node for parallel calculation on multi-core GPU is described. The NIC has a cluster network including a host and a host memory, a graphics processing unit (GPU) with a GPU memory, a bus and the NIC. The NIC has a transmission network connection block and a reception network connection block. The NIC further includes the following blocks: a transmission block, a reception block, and a GPU memory management block for a direct exchange between the GPU memory and the network through the NIC ...) wherein the DPU is to receive an indication from the at least one GPU (FIGS. 1 and 2 show GPU) to indicate that the at least one GPU is ready to receive additional data (Paragraphs [0111]-[0114], the P2P GPU RX feature, which is part of this invention, allows for the NIC to autonomously carry on the RX operation of a message targeted to a GPU memory buffer ... the proposed method extends the RDMA technique (prior-art) to GPU memory buffers, and relies on the application running on the host to pre-register GPU RX buffers before their use (prior art) on the NIC_GPU_RX (patenting block) ... a. NIC_GPU_RX triggers the NIC_GPU_DMA, which manipulates the GPU to make it accessible the memory region from the bus. ... b. NIC_GPU_DMA does its work by proper writing some GPU configuration registers. ... c. NIC_GPU_RX generates a DMA transaction on the bus to move the data corresponding to the sub-range Ij from RX_BUFFERS to the GPU memory ... NIC_EQ block, as a completion signal of the whole RX operation, writes an event onto the event queue (EQ) in host memory (prior art). The event is got by the application that processes the just received memory buffers; paragraph [0104], NIC_EQ block, signaling the operation completion, writes some event data structure in a proper (either GPU or host) memory area which acts as an event queue (EQ). In this way the application is signaled that the GPU memory has been read and can be reused. Thus, an event onto the event queue (EQ) in host memory indicates that the reused memory of GPU is ready to receive additional data).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the a system for accelerating network applications using an enhanced network interface and massively parallel distributed processing taught by Bernath incorporate the teachings of Rossetti, and applying the events queues management block taught by Rossetti to provide the events queues between the graphics processing unit (GPU) and the data processing unit (DPU) in order to indicate that the GPU is ready to receive additional data. Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify Bernath according to the relied-upon teachings of Rossetti to obtain the invention as specified in claim.
Regarding claim 20, Bernath discloses everything claimed as applied above (see claim 16).
However, Bernath does not specifically disclose wherein the at least one DPU is to receive an indication from the GPU to indicate that the GPU is ready to receive additional data.
In additional, Rossetti discloses (Abstract, a Network Interface Card (NIC) for a cluster node for parallel calculation on multi-core GPU is described. The NIC has a cluster network including a host and a host memory, a graphics processing unit (GPU) with a GPU memory, a bus and the NIC. The NIC has a transmission network connection block and a reception network connection block. The NIC further includes the following blocks: a transmission block, a reception block, and a GPU memory management block for a direct exchange between the GPU memory and the network through the NIC ...) wherein the at least one DPU is to receive an indication from the GPU (FIGS. 1 and 2 show GPU) to indicate that the GPU is ready to receive additional data (Paragraphs [0111]-[0114], the P2P GPU RX feature, which is part of this invention, allows for the NIC to autonomously carry on the RX operation of a message targeted to a GPU memory buffer ... the proposed method extends the RDMA technique (prior-art) to GPU memory buffers, and relies on the application running on the host to pre-register GPU RX buffers before their use (prior art) on the NIC_GPU_RX (patenting block) ... a. NIC_GPU_RX triggers the NIC_GPU_DMA, which manipulates the GPU to make it accessible the memory region from the bus. ... b. NIC_GPU_DMA does its work by proper writing some GPU configuration registers. ... c. NIC_GPU_RX generates a DMA transaction on the bus to move the data corresponding to the sub-range Ij from RX_BUFFERS to the GPU memory ... NIC_EQ block, as a completion signal of the whole RX operation, writes an event onto the event queue (EQ) in host memory (prior art). The event is got by the application that processes the just received memory buffers; paragraph [0104], NIC_EQ block, signaling the operation completion, writes some event data structure in a proper (either GPU or host) memory area which acts as an event queue (EQ). In this way the application is signaled that the GPU memory has been read and can be reused. Thus, an event onto the event queue (EQ) in host memory indicates that the reused memory of GPU is ready to receive additional data).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the a system for accelerating network applications using an enhanced network interface and massively parallel distributed processing taught by Bernath incorporate the teachings of Rossetti, and applying the events queues management block taught by Rossetti to provide the events queues between the graphics processing unit (GPU) and the data processing unit (DPU) in order to indicate that the GPU is ready to receive additional data. Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify Bernath according to the relied-upon teachings of Rossetti to obtain the invention as specified in claim.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Xilin Guo whose telephone number is (571)272-5786. The examiner can normally be reached Monday - Friday 9:00 AM-5:30 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel Hajnik can be reached at 571-272-7642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/XILIN GUO/Primary Examiner, Art Unit 2616
Prosecution Insights