DETAILED ACTION
This Action is a response to the filing received 27 June 2023. Claims 1-20 are presented for examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 20 June 2024 is being considered by the examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 4 and 6 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Mayatskikh et al., U.S. 2020/0065021 A1 (“Mayatskikh”).
Regarding claim 1, Mayatskikh teaches: A method for hot upgrade or live recovery of storage backend software running on an Infrastructure Processing Unit (IPU) or Data Processing Unit (DPU), the storage backend software used to access one or more storage devices operatively coupled to the IPU or DPU (Mayatskikh, e.g., ¶13, “performing a live upgrade of a storage device driver using a shim application …” See also, e.g., ¶14, “a shim module acts as a proxy for the gendisk API. The shim sits between the kernel block subsystem layer and the low-level driver (LLD). Upon load, a LLD registers itself in the shim as an engine for gendisk API. When a disk that is created by the LLD is opened by a system component …” See also, e.g., FIG. 1 and ¶23, “storage hardware 140 may include one or more persistent storage devices … a first hard disk drive 142A and a second hard disk drive 142B …” Examiner’s note: the device shim 120, alone or in combination with respective storage drivers, acts as an infrastructure and/or data processing unit on which storage backend software runs, as the software is used to access one or more storage devices 142 coupled to the IPU/DPU), comprising:
saving configuration space and queue related information associated with Input-Output (IO) operations for at least one storage device operatively coupled to the IPU or DPU (Mayatskikh, e.g., ¶16, “LLD suspends all block device IO queues so that no new IO requests may be sent to the LLD. It also cancels timers and flushes deferred activity. Internal objects that have to persist over upgrade (e.g., that will be used by the new LLD), are passed to the shim as a cookie pointer to a memory area where these objects are located … gendisk-related objects are not destroyed …”);
performing a hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶13, “performing a live upgrade of a storage device driver using a shim application”); and
restoring the configuration space and queue related information and restarting IO operations at a last completed point prior to initiation of the hot upgrade or live recovery (Mayatskikh, e.g., ¶17, “new LLD module is then loaded. It registers in the shim, retrieves cookie(s) saved by the old LLD, restores the operational state from the old objects contained/referenced in a memory behind cookie pointer(s), walks through the list of existing block devices served by the old version, recovers them, and resumes block device queues. Upon resuming the block device queues, IO continues to flow …”).
Regarding claim 4, the rejection of claim 1 is incorporated, and Mayatskikh further teaches: executing a primary process on the IPU or DPU; allocating, via the primary process, shared memory for a hot upgrade or live recovery (Mayatskikh, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … shim application may store these pointers … in the general memory of the computer system”); executing a secondary process on the IPU or DPU; and utilizing, via the secondary process, the shared memory for the hot update or live recovery to facilitate the hot upgrade or live recovery (Mayatskikh, e.g., ¶41, “new storage driver is loaded and registers with the shim application … new storage driver may be loaded (e.g., placed into memory) …” See also, e.g., ¶42, “operational state of the storage driver may be restored on the new storage driver using the one or more objects … application shim may transmit a list of pointers to the new storage driver. The new storage driver may then retrieve the object using the pointers”).
Regarding claim 6, the rejection of claim 4 is incorporated, and Mayatskikh further teaches: creating a backend controller via execution of the secondary process, the backend controller used to access at least one storage device operatively coupled to the IPU or DPU (Mayatskikh, e.g., ¶¶43-44, “shim application may identify existing block devices serviced by the old storage driver … may then recover the identified block devices … making the block devices operational … new driver may resume the block device queues. In addition, any I/O requests received by the OS after suspending the block device queue and before resuming the block device queues … may be transmitted to the new storage device …”).
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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-3 are rejected under 35 U.S.C. § 103 as being unpatentable over Mayatskikh in view of Pandit et al., U.S. 2024/0272924 A1 (“Pandit”).
Regarding claim 2, the rejection of claim 1 is incorporated, and Mayatskikh further teaches: reassociating newly started or restarted backend software with the front-end host driver following the hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶17, “new LLD module is then loaded. It registers in the shim, retrieves cookie(s) saved by the old LLD, restores the operational state from the old objects contained/referenced in a memory behind cookie pointer(s), walks through the list of existing block devices served by the old version, recovers them, and resumes block device queues. Upon resuming the block device queues, IO continues to flow …”).
Mayatskikh does not more particularly teach that the IPU or DPU is coupled to a host providing a front-end host driver. However, Pandit does teach: wherein the IPU or DPU is coupled to a host providing a front-end host driver (Pandit, e.g., ¶26, “Configurations using a bare metal server require connecting a physical device … to server … using DPI … a bare metal server is connected to DPU … which provides a networking device (VirtIO net) and a block device (VirtIO blk) that QEMU hypervisor 212 and bare metal server can use”) for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, e.g., ¶¶26-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the IPU or DPU is coupled to a host providing a front-end host driver because the disclosure of Pandit shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for accelerated backend software updates to provide that the IPU or DPU is coupled to a host providing a front-end host driver for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, Id.).
Regarding claim 3, the rejection of claim 2 is incorporated, and Pandit further teaches that the front-end host driver comprises a host virtio-blk device: wherein the front-end host driver comprises a host virtio-blk device (Pandit, e.g., ¶21, “VirtIO is a standard specification in virtualization … core feature of VirtIO is Virtqueue (VQ) abstraction … device of a virtual machine can use one or more … VQs. A VirtIO blk device is a simple virtual block device … Frontend (FE) VirtIO driver in user space 120 VM places read, write, and other requests onto VQ, so that backend (BE) VirtIO driver (in service VM space) can process them accordingly …”) for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, e.g., ¶¶26-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the front-end host driver comprises a host virtio-blk device because the disclosure of Pandit shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for accelerated backend software updates to provide that the front-end host driver comprises a host virtio-blk device for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, Id.).
Claim 5 is rejected under 35 U.S.C. § 103 as being unpatentable over Mayatskikh in view of Glimcher, Boris, U.S. 2023/0305977 A1 (“Glimcher”).
Regarding claim 5, the rejection of claim 4 is incorporated, but Mayatskikh does not more particularly teach that the primary and secondary processes are Storage Performance Development Kit (SPDK) processes. However, Glimcher does teach: wherein the primary process and the secondary process are Storage Performance Development Kit (SPDK) processes (Glimcher, e.g., ¶46, “target implementation of an emulated device may be created to handle submission and completion queue pairs … Code for target implementation may be running as a storage performance development kit (SPDK) in a polling mode, handling both administrative management operations …”) for the purpose of operating a plurality of emulated NVMe/PCIe block devices running on a host and consumed by a plurality of distributed application instances (Glimcher, e.g., ¶¶44-49 et seq.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the primary and secondary processes are Storage Performance Development Kit (SPDK) processes because the disclosure of Glimcher shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for performing a non-disruptive updated to a network interface controller to provide that the primary and secondary processes are Storage Performance Development Kit (SPDK) processes for the purpose of operating a plurality of emulated NVMe/PCIe block devices running on a host and consumed by a plurality of distributed application instances (Glimcher, Id.).
Claims 7-9, 11, 13-15 and 17-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Mayatskikh in view of Kutch et al., U.S. 2021/0232528 A1 (“Kutch”).
Regarding claim 7, the rejection of claim 1 is incorporated, and Mayatskick further teaches: using at least a portion of the plurality of indexes to track inflight IO operations in connection with the hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶36, “requests/commands in the block device queues (e.g., to retrieve data) may be maintained … accumulated requests can be executed when the new storage driver is loaded.” See also, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … store these pointers …” See also, e.g., ¶¶41-44, “new storage driver is loaded and registers with the shim application … operational state of the storage driver may be restored on the new storage driver using the one or more objects … new driver may resume the block device queues …”).
Mayatskikh does not more particularly teach that the IPU or DPU is coupled to a host running a front-end host driver, implementing a ring queue shared between the front-end host driver and a backend controller created by the storage backend software, and maintaining a plurality of indexes of the ring queue. However, Kutch does teach: wherein the IPU or DPU is coupled to a host running a front-end host driver (Kutch, e.g., ¶9, “virtual data path acceleration (vDPA). vDPA allows a connection between a VM or container and device to be established using virtio to provide a data-plane between a virtio executing within a VM and … control-plane that is managed by a vDPA application …” See also, e.g., ¶32, “NIC 330 can include … an infrastructure processing unit (IPU), data processing unit (DPU) …”), further comprising:
implementing a ring queue shared between the front-end host driver and a backend controller created by the storage backend software (Kutch, e.g., ¶33, “VDEV driver 304 can allocate memory for packet buffers and Rx or Tx descriptors rings, and descriptor rings (queues) can be accessible to FDR 320 and … NIC 330.”);
maintaining a plurality of indexes for the ring queue (Kutch, e.g., ¶66, “a virtio queue can be used to transfer an available (avail) ring index corresponding to a descriptor in a descriptor table and/or used ring entry index corresponding to a descriptor in a descriptor table …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the IPU or DPU is coupled to a host running a front-end host driver, implementing a ring queue shared between the front-end host driver and a backend controller created by the storage backend software, and maintaining a plurality of indexes of the ring queue because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide that the IPU or DPU is coupled to a host running a front-end host driver, implementing a ring queue shared between the front-end host driver and a backend controller created by the storage backend software, and maintaining a plurality of indexes of the ring queue for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Regarding claim 8, the rejection of claim 7 is incorporated, and Kutch further teaches that the indexes include a used index controlled by a storage device and an available index controlled by the front-end host device, the inflight IO operations determined by comparing the available and used indexes: wherein the plurality of indexes includes a used index controlled by a storage device and an available index controlled by the front-end host driver, and the inflight IO operations are determined by comparing the available index with the used index (Kutch, e.g., ¶66, “a virtio queue can be used to transfer an available (avail) ring index corresponding to a descriptor in a descriptor table and/or used ring entry index corresponding to a descriptor in a descriptor table …” See also, e.g., ¶67, “to send an IO request … a VEE can locate a free (available) descriptor entry from the descriptor table … a free entry is a desc with index 0 (desc 0) …” and ¶69, “VEE can use a virtqueue to provide an avail ring index to pass a descriptor to the vhost target and the vhost target can update the virtqueue with a used ring index to the VEE …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the indexes include a used index controlled by a storage device and an available index controlled by the front-end host device, the inflight IO operations determined by comparing the available and used indexes because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide that the indexes include a used index controlled by a storage device and an available index controlled by the front-end host device, the inflight IO operations determined by comparing the available and used indexes for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Regarding claim 9, Mayatskikh teaches: An apparatus comprising: … a processor; memory, coupled to the processor; and instructions including storage backend software configured to be executed on the processor to enable the apparatus (Mayatskikh, e.g., ¶46, “example computer system 401 that may be used in implementing one or more of the methods … system 401 may comprise one or more CPUs 402, a memory subsystem 404 … which may be communicatively coupled … via a memory bus …” See also, e.g., ¶49, “One or more programs/utilities 428, each having at least one set of program modules 430 may be stored in memory … Program modules 430 generally perform the functions …”) to:
save configuration space and queue related information associated with Input-Output (IO) operations for at least one storage device operatively to be coupled to the one or more IO interfaces (Mayatskikh, e.g., ¶16, “LLD suspends all block device IO queues so that no new IO requests may be sent to the LLD. It also cancels timers and flushes deferred activity. Internal objects that have to persist over upgrade (e.g., that will be used by the new LLD), are passed to the shim as a cookie pointer to a memory area where these objects are located … gendisk-related objects are not destroyed …”);
facilitate a hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶13, “performing a live upgrade of a storage device driver using a shim application”); and
restore the configuration space and queue related information and restart IO operations at a last completed point prior to initiation of the hot upgrade or live recovery (Mayatskikh, e.g., ¶17, “new LLD module is then loaded. It registers in the shim, retrieves cookie(s) saved by the old LLD, restores the operational state from the old objects contained/referenced in a memory behind cookie pointer(s), walks through the list of existing block devices served by the old version, recovers them, and resumes block device queues. Upon resuming the block device queues, IO continues to flow …”).
Mayatskikh does not more particularly teach that the apparatus further comprises a host interface with a compute host and one or more IO interfaces configured to connect to a local or remote storage device. However, Kutch does teach: a host interface to interface with a compute host; one or more input-output (IO) interfaces configured to connect to a local or remote storage device (Kutch, e.g., ¶9, “virtual data path acceleration (vDPA). vDPA allows a connection between a VM or container and device to be established using virtio to provide a data-plane between a virtio executing within a VM and … control-plane that is managed by a vDPA application …” See also, e.g., ¶32, “NIC 330 can include … an infrastructure processing unit (IPU), data processing unit (DPU) …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the apparatus further comprises a host interface with a compute host and one or more IO interfaces configured to connect to a local or remote storage device because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide that the apparatus further comprises a host interface with a compute host and one or more IO interfaces configured to connect to a local or remote storage device for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Regarding claim 11, the rejection of claim 9 is incorporated, and Mayatskikh further teaches: wherein the instructions include instructions for: a primary process that allocates a portion of the memory as shared memory for a hot update or live recovery (Mayatskikh, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … shim application may store these pointers … in the general memory of the computer system”); and a secondary process the utilizes the shared memory for the hot update or live recovery to facilitate a portion of the hot upgrade or live recovery (Mayatskikh, e.g., ¶41, “new storage driver is loaded and registers with the shim application … new storage driver may be loaded (e.g., placed into memory) …” See also, e.g., ¶42, “operational state of the storage driver may be restored on the new storage driver using the one or more objects … application shim may transmit a list of pointers to the new storage driver. The new storage driver may then retrieve the object using the pointers”).
Regarding claim 13, the rejection of claim 11 is incorporated, and Mayatskikh further teaches: wherein execution of the instructions creates a backend controller via execution of the secondary process that is used to access at least one local or remote storage device via the one or more IO interfaces (Mayatskikh, e.g., ¶¶43-44, “shim application may identify existing block devices serviced by the old storage driver … may then recover the identified block devices … making the block devices operational … new driver may resume the block device queues. In addition, any I/O requests received by the OS after suspending the block device queue and before resuming the block device queues … may be transmitted to the new storage device …”).
Regarding claim 14, the rejection of claim 15 is incorporated, and Mayatskikh further teaches: wherein the last completed point prior to initiation of the hot upgrade or live recovery is identified by accessing, via the backend controller, one or more of the plurality of indexes (Mayatskikh, e.g., ¶36, “requests/commands in the block device queues (e.g., to retrieve data) may be maintained … accumulated requests can be executed when the new storage driver is loaded.” See also, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … store these pointers …” See also, e.g., ¶¶41-44, “new storage driver is loaded and registers with the shim application … operational state of the storage driver may be restored on the new storage driver using the one or more objects … new driver may resume the block device queues …”).
Mayatskikh does not more particularly teach that the compute host implements a ring queue shared between a front-end host driver and the backend controller utilizing a plurality of indexes. However, Kutch does teach: wherein the compute host implements a ring queue shared between a front-end host driver and the backend controller utilizing a plurality of indexes (Kutch, e.g., ¶33, “VDEV driver 304 can allocate memory for packet buffers and Rx or Tx descriptors rings, and descriptor rings (queues) can be accessible to FDR 320 and … NIC 330.” See also, e.g., ¶66, “a virtio queue can be used to transfer an available (avail) ring index corresponding to a descriptor in a descriptor table and/or used ring entry index corresponding to a descriptor in a descriptor table …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the compute host implements a ring queue shared between a front-end host driver and the backend controller utilizing a plurality of indexes because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide that the compute host implements a ring queue shared between a front-end host driver and the backend controller utilizing a plurality of indexes for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Regarding claim 15, the rejection of claim 9 is incorporated, and Kutch further teaches: wherein the apparatus comprises an Infrastructure Processing Unit (IPU) or Data Processing Unit (DPU) (Kutch, e.g., ¶9, “virtual data path acceleration (vDPA). vDPA allows a connection between a VM or container and device to be established using virtio to provide a data-plane between a virtio executing within a VM and … control-plane that is managed by a vDPA application …” See also, e.g., ¶32, “NIC 330 can include … an infrastructure processing unit (IPU), data processing unit (DPU) …”).
Regarding claim 17, Mayatskikh teaches: A system comprising: … save configuration space and queue related information associated with Input-Output (IO) operations for at least one of the one or more storage device operatively coupled to the IPU or DPU (Mayatskikh, e.g., ¶13, “performing a live upgrade of a storage device driver using a shim application …” See also, e.g., ¶14, “a shim module acts as a proxy for the gendisk API. The shim sits between the kernel block subsystem layer and the low-level driver (LLD). Upon load, a LLD registers itself in the shim as an engine for gendisk API. When a disk that is created by the LLD is opened by a system component …” See also, e.g., FIG. 1 and ¶23, “storage hardware 140 may include one or more persistent storage devices … a first hard disk drive 142A and a second hard disk drive 142B …” Examiner’s note: the device shim 120, alone or in combination with respective storage drivers, acts as an infrastructure and/or data processing unit on which storage backend software runs, as the software is used to access one or more storage devices 142 coupled to the IPU/DPU. See also, e.g., ¶16, “LLD suspends all block device IO queues so that no new IO requests may be sent to the LLD. It also cancels timers and flushes deferred activity. Internal objects that have to persist over upgrade (e.g., that will be used by the new LLD), are passed to the shim as a cookie pointer to a memory area where these objects are located … gendisk-related objects are not destroyed …”);
facilitate a hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶13, “performing a live upgrade of a storage device driver using a shim application”); and
restore the configuration space and queue related information and restart IO operations at a last completed point prior to initiation of the hot upgrade or live recovery (Mayatskikh, e.g., ¶17, “new LLD module is then loaded. It registers in the shim, retrieves cookie(s) saved by the old LLD, restores the operational state from the old objects contained/referenced in a memory behind cookie pointer(s), walks through the list of existing block devices served by the old version, recovers them, and resumes block device queues. Upon resuming the block device queues, IO continues to flow …”).
Mayatskikh does not more particularly teach a compute host including a front-end host storage device driver, an IPU or DPU coupled to the compute host having storage backend software used to access storage devices operatively coupled to the IPU or DPU and configured to enable the compute host to access the storage devices via the front-end storage device driver. However, Kutch does teach: a compute host including a front-end host storage device driver; an Infrastructure Processing Unit (IPU) or Data Processing Unit (DPU) coupled to the compute host, having storage backend software used to access one or more storage devices operatively coupled to the IPU or DPU and configured to, enable the compute host to access at least one of the one or more storage devices via the front-end host storage device driver (Kutch, e.g., ¶9, “virtual data path acceleration (vDPA). vDPA allows a connection between a VM or container and device to be established using virtio to provide a data-plane between a virtio executing within a VM and … control-plane that is managed by a vDPA application …” See also, e.g., ¶32, “NIC 330 can include … an infrastructure processing unit (IPU), data processing unit (DPU) …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide for a compute host including a front-end host storage device driver, an IPU or DPU coupled to the compute host having storage backend software used to access storage devices operatively coupled to the IPU or DPU and configured to enable the compute host to access the storage devices via the front-end storage device driver because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide for a compute host including a front-end host storage device driver, an IPU or DPU coupled to the compute host having storage backend software used to access storage devices operatively coupled to the IPU or DPU and configured to enable the compute host to access the storage devices via the front-end storage device driver for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Regarding claim 18, the rejection of claim 17 is incorporated and Mayatskikh further teaches: wherein the IPU or DPU is further configured to reassociate newly started or restarted backend software with the front-end host storage device driver following the hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶17, “new LLD module is then loaded. It registers in the shim, retrieves cookie(s) saved by the old LLD, restores the operational state from the old objects contained/referenced in a memory behind cookie pointer(s), walks through the list of existing block devices served by the old version, recovers them, and resumes block device queues. Upon resuming the block device queues, IO continues to flow …”).
Regarding claim 19, the rejection of claim 17 is incorporated, and Mayatskikh further teaches: wherein the IPU or DPU is further configured to: execute a primary process; allocate, via the primary process, shared memory for a hot update or live recovery (Mayatskikh, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … shim application may store these pointers … in the general memory of the computer system”); execute a secondary process; and utilize, via the secondary process, the shared memory for the hot update or live recovery to facilitate the hot upgrade or live recovery (Mayatskikh, e.g., ¶41, “new storage driver is loaded and registers with the shim application … new storage driver may be loaded (e.g., placed into memory) …” See also, e.g., ¶42, “operational state of the storage driver may be restored on the new storage driver using the one or more objects … application shim may transmit a list of pointers to the new storage driver. The new storage driver may then retrieve the object using the pointers”).
Regarding claim 20, the rejection of claim 17 is incorporated, and Mayatskikh further teaches: utilize at least a portion of the plurality of indexes to track inflight IO operations in connection with the hot upgrade or live recovery of the storage backend software (Mayatskikh, e.g., ¶36, “requests/commands in the block device queues (e.g., to retrieve data) may be maintained … accumulated requests can be executed when the new storage driver is loaded.” See also, e.g., ¶39, “Pointers for the one or more internal objects that need to persist may be passed to the shim application … store these pointers …” See also, e.g., ¶¶41-44, “new storage driver is loaded and registers with the shim application … operational state of the storage driver may be restored on the new storage driver using the one or more objects … new driver may resume the block device queues …”).
Mayatskikh does not more particularly teach that the system is configured to implement a ring queue shared between the front-end storage device driver and a backend controller created by the storage backend software and maintain a plurality of indexes for the ring queue. However, Kutch does teach: wherein the system is configured to: implement a ring queue shared between the front-end host storage device driver and a backend controller created by the storage backend software (Kutch, e.g., ¶33, “VDEV driver 304 can allocate memory for packet buffers and Rx or Tx descriptors rings, and descriptor rings (queues) can be accessible to FDR 320 and … NIC 330.”); maintain a plurality of indexes for the ring queue (Kutch, e.g., ¶66, “a virtio queue can be used to transfer an available (avail) ring index corresponding to a descriptor in a descriptor table and/or used ring entry index corresponding to a descriptor in a descriptor table …”) for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, e.g., ¶¶32-36, 58-69).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh to provide that the system is configured to implement a ring queue shared between the front-end storage device driver and a backend controller created by the storage backend software and maintain a plurality of indexes for the ring queue because the disclosure of Kutch shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for configuring a storage device interface to provide that the system is configured to implement a ring queue shared between the front-end storage device driver and a backend controller created by the storage backend software and maintain a plurality of indexes for the ring queue for the purpose of implementing techniques for providing massively distributed network and storage device interfaces to perform accelerated storage operations (Kutch, Id.).
Claims 10 and 16 are rejected under 35 U.S.C. § 103 as being unpatentable over Mayatskikh in view of Kutch, and in further view of Pandit.
Regarding claim 10, the rejection of claim 9 is incorporated, but Mayatskikh in view of Kutch does not more particularly teach that the compute host employs a front-end driver. However, Pandit does teach: wherein the compute host employs a front-end host driver (Pandit, e.g., ¶26, “Configurations using a bare metal server require connecting a physical device … to server … using DPI … a bare metal server is connected to DPU … which provides a networking device (VirtIO net) and a block device (VirtIO blk) that QEMU hypervisor 212 and bare metal server can use”) for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, e.g., ¶¶26-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh in view of Kutch to provide that the compute host employs a front-end driver because the disclosure of Pandit shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for accelerated backend software updates to provide that the compute host employs a front-end driver for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, Id.).
Regarding claim 16, the rejection of claim 9 is incorporated, but Mayatskikh in view of Kutch does not more particularly teach that the compute host employs a front-end host virtio-blk device driver and further comprises a VNMe/virtio-blk physical function and virtual function. However, Pandit does teach: wherein the compute host employs a front-end host virtio-blk device driver, and wherein the apparatus further comprises a Nonvolatile Memory Express (NVMe)/virtio-blk physical function and virtual function (PF/VF) (Pandit, e.g., ¶26, “Configurations using a bare metal server require connecting a physical device … to server … using DPI … a bare metal server is connected to DPU … which provides a networking device (VirtIO net) and a block device (VirtIO blk) that QEMU hypervisor 212 and bare metal server can use.” See also, e.g., ¶¶102-104, describing the storage subsystem comprising NVM devices, wherein FIGS. 1 and 2 display embodiments comprising physical and virtual memory) for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, e.g., ¶¶26-28).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh in view of Kutch to provide that the compute host employs a front-end host virtio-blk device driver and further comprises a VNMe/virtio-blk physical function and virtual function because the disclosure of Pandit shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for accelerated backend software updates to provide that the compute host employs a front-end host virtio-blk device driver and further comprises a VNMe/virtio-blk physical function and virtual function for the purpose of providing an accelerated emulation system within which software updates may quickly be made without system disruption (Pandit, Id.).
Claim 12 is rejected under 35 U.S.C. § 103 as being unpatentable over Mayatskikh in view of Kutch, and in further view of Glimcher.
Regarding claim 12, the rejection of claim 11 is incorporated, but Mayatskikh in view of Kutch does not more particularly teach that the primary and secondary processes are SPDK processes. However, Glimcher does teach: wherein the primary process and the secondary process are Storage Performance Development Kit (SPDK) processes (Glimcher, e.g., ¶46, “target implementation of an emulated device may be created to handle submission and completion queue pairs … Code for target implementation may be running as a storage performance development kit (SPDK) in a polling mode, handling both administrative management operations …”) for the purpose of operating a plurality of emulated NVMe/PCIe block devices running on a host and consumed by a plurality of distributed application instances (Glimcher, e.g., ¶¶44-49 et seq.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for live upgrade of a storage device driver as taught by Mayatskikh in view of Kutch to provide that the primary and secondary processes are SPDK processes because the disclosure of Glimcher shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for performing a non-disruptive updated to a network interface controller to provide that the primary and secondary processes are SPDK processes for the purpose of operating a plurality of emulated NVMe/PCIe block devices running on a host and consumed by a plurality of distributed application instances (Glimcher, Id.).
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
Prosecution Insights