Dynamic command capacity allocation across multiple sessions and transports

A method for dynamically allocating a plurality of command processing resources is disclosed. The method generally includes the steps of (A) allocating the command processing resources from a first protocol layer to a first pool of a second protocol layer below the first protocol layer, (B) allocating at least some of the command processing resources from the first pool to a plurality of second pools and (C) sending a particular one of the command processing resources from one of the second pools to the first protocol layer for processing an operation.

FIELD OF THE INVENTION

The present invention relates to a storage area networking generally and, more particularly, to a dynamic command capacity allocation across multiple high level protocols.

BACKGROUND OF THE INVENTION

The small computer system interface (SCSI) storage protocol is being layered on a number of network-based transport protocols. The network-based transport protocols include Fibre Channel, Internet SCSI (iSCSI), and Infiniband. A monolithic driver, with the SCSI layer and the transport layer in the same driver, is currently used on storage devices providing a single transport protocol. A layered driver, with separate SCSI and transport layers, is currently used for storage devices providing multiple transport protocols. A layered driver can also be used for storage devices providing a single transport protocol.

In direct connect storage devices, all command processing resources of the SCSI layer are used for the single system connecting to the storage device. In storage devices connected to storage area networks, the storage device can be shared by multiple systems. Regardless of driver type, the command processing resources of the SCSI layer are being shared across multiple transport layer connections. Current mechanisms allocate fixed resources to each transport layer session. The static allocation mechanism can be extended to support multiple transport layers.

The use of a static allocation mechanism for command processing resources restricts the flexibility of a solution. Each session (i.e., where the session is a transport level construct) has an arbitrary maximum performance based on the statically allocated number of command processing resources. Each transport layer also has an aggregate maximum performance based on the statically allocated number of command processing resources and the number of sessions supported by the allocation. For example, consider a protocol layer that can support 16 independent communications services (i.e., 16 independent I_T Nexi for SCSI). In a static allocation, each transport protocol is given a maximum 8 of the transport level session constructs (i.e., for iSCSI a maximum of 8 sessions and for Fibre Channel a maximum of 8 connections). Thus, an arbitrary division exists between transports. Within the transport the allocation of resources between sessions may also be static. The present invention addresses the dynamic allocation of resources both across transports and within each transport.

SUMMARY OF THE INVENTION

The present invention concerns a method for dynamically allocating a plurality of command processing resources. The method generally comprises the steps of (A) allocating the command processing resources from a first protocol layer to a first pool of a second protocol layer below the first protocol layer, (B) allocating at least some of the command processing resources from the first pool to a plurality of second pools and (C) sending a particular one of the command processing resources from one of the second pools to the first protocol layer for processing an operation.

The objects, features and advantages of the present invention include providing a method and circuit that may (i) adjust an allocation of command processing resources between transport protocols and sessions within each transport protocol, (ii) move command processing resources over time to a transport layer with the most open sessions, (iii) allow each session to have a larger number of command processing resources when a system has few open sessions, (iv) allow reduced session capacity when a large number of sessions are open and/or (v) dynamically adjust a capacity of the sessions and the transport protocols as sessions are opened and closed.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring toFIG. 8, a block diagram of an example implementation of a storage area network system200is shown. The present invention generally pertains to the field of storage devices202(one shown) having a circuit204attached to multiple host systems206ato206cvia a communications network208, and in particular, storage area networks. The small computer system interface (SCSI) storage protocol may be layered on a number of network-based transport protocols. The network-based transport protocols generally include Fibre Channel, Internet SCSI (iSCSI), and Infiniband. A mechanism may be defined allowing command processing resources (CPRs) of a SCSI layer to be dynamically reallocated as sessions are opened and closed. The present invention generally guarantees a minimal session operation in fully loaded systems while allowing extra command processing capacity for sessions in lightly loaded systems. In a layered driver stack, the present invention generally supports sharing SCSI command processing resources between multiple transport protocols, such as Fibre Channel, Infiniband and Internet SCSI (iSCSI). All session capacity semantics involved with transport credit mechanisms may be preserved, such as the iSCSI sequence number computation.

An iSCSI entity may contain one or more iSCSI targets. Each iSCSI target may support simultaneous access by multiple iSCSI initiators. Each initiator may open an iSCSI session on any iSCSI target on the iSCSI entity for which access has been granted. Fibre Channel and Infiniband may also create multiple connections and multiple sessions to access storage resources. Each session generally represents a single SCSI I_T Nexus. As such, sessions opened substantially simultaneously for a storage device may share the command processing resources for the SCSI layer of the storage device.

In a network storage device with a layered driver architecture, each operation (e.g., SCSI tasks and SCSI task management requests (TMR)) may be transmitted to the SCSI layer using a command processing resource. The command processing resource for a SCSI operation (ScsiOp) generally contains all context of the SCSI operation. While the SCSI operation is in progress, the transport layer may use an input/output request block (IORB) to track execution of the SCSI operation. The SCSI layer generally has a limited number of SCSI operations. Since an amount of state in the I/O request block may be significantly smaller than a state in the SCSI operation, a system may have a significantly larger number of I/O request blocks than a number of SCSI operations.

A maximum number of sessions supported by each transport layer is generally determined by how the SCSI operations are allocated to sessions. In a simple conventional solution, each session is given a fixed number of SCSI operations. The SCSI operations are commonly reused for each command processed. A total number of sessions supported is thus limited to a total number of SCSI operations divided by a number of SCSI operations per session. In conventional systems where multiple transport protocols are supported, the SCSI operations are statically allocated to each transport protocol. Therefore, the performance characteristics of sessions do not change as sessions open and close. All sessions have a fixed maximum performance dictated by the statically assigned SCSI operations. The conventional systems are also incapable of responding to changes in access patterns between different transports. All the static allocation decisions are made a-priori and cannot respond dynamically to usage changes within or across transport layers.

A mechanism to allow a storage device to dynamically adjust operation performance may have one or more of the following characteristics. Each transport layer used by the storage device may reserve a subset of a total number of available SCSI operations. Each particular SCSI operation allocated to a particular transport layer may be released after use. By releasing, the particular SCSI operation may be reallocated to a different transport layer, if not reserved, or back to the originating transport layer. Each session is generally guaranteed an allocation of a minimum number of SCSI operations. Sessions may hold allocated SCSI operations until the SCSI operations have been used. Each session may be allowed to acquire additional SCSI operations after a SCSI operation has completed. The total number of allocations may be up to a session maximum value. The SCSI operation maximum value for sessions may vary dynamically to fairly distribute SCSI operations across sessions in each transport layer. The SCSI operation maximum value generally may not exceed a transport layer specific absolute maximum value. The above characteristics may be applied directly to the iSCSI transport layer. The above characteristics may be used with minimal modification for the Fibre Channel and Infiniband transport protocols.

The present invention generally defines an architecture and/or method that meet the above characteristics. One or more of the following attributes may be implemented in accordance with the present invention. A transport reservation mechanism may be provided in a SCSI operation context structure. An optional transport pool may hold SCSI operation contexts pre-allocated to a transport but not currently assigned to a session. A pool shared by all sessions in a transport holding I/O request block contexts may be used for immediate delivery commands of the transport layer. A pool for each session holding I/O request block contexts may be used for normal delivery commands of the transport layer. An exemplary embodiment of the present invention may include all of the above attributes.

The SCSI operation transport reservation mechanism generally allows each transport layer to reserve a set of SCSI operations. The SCSI operation transport reservation mechanism may inform the SCSI layer that a specific SCSI operation should be returned to a specific transport layer. The SCSI operation transport reservation mechanism may prevent the SCSI layer from allocating a reserved SCSI operation to another transport layer.

During initialization, each transport layer may determine an initial number of SCSI operations to reserve and report the initial number to the SCSI layer. The total number of reserved SCSI operations generally includes (i) a number designated for an immediate I/O request block pool of the transport layer and (ii) a number used to provide each session with a minimum command processing capability. In turn, the SCSI layer generally determines a number of SCSI operations may be unreserved and provides the unreserved number to each transport layer. The unreserved quantity may be the number of SCSI operations available to balance command processing capacity allocations across the various transport layers and sessions dynamically.

Referring toFIG. 1, a block diagram of an example system100for a SCSI operation life cycle is shown in accordance with a preferred embodiment of the present invention. The system100generally comprises a SCSI layer102and one or more transport layers104. A signal (e.g., A) may convey one or more SCSI operations allocated from the SCSI layer102to a transport layer104. A signal (e.g., B) may convey one or more SCSI operations from the transport layer104to the SCSI layer102for processing of an operation. A signal (e.g., C) may convey information to and/or from an initiator of the operation.

Each transport layer104generally comprises a first pool (or module)110, a second pool (or module)112, a third pool (or module)114and a transfer block (or module)116. The first pool110may be referred to as a SCSI operation (ScsiOp) pool. The second pool112may be referred to as a session input/output request block (IORB) pool. The third pool114may be referred to as an immediate IORB pool. The transfer block116may be operational to (i) receive allocated I/O request blocks with linked SCSI operations, (ii) transport the SCSI operations to the SCSI layer102, (iii) release the I/O request blocks without the SCSI operations and (iv) open/close sessions with the initiator.

The SCSI layer102may be implemented per the SCSI specification. Application layers, presentation layers and session layers of the Open Systems Interconnection seven-layer model as well as similar upper level layers and sub-layers of other protocols may be implemented as the layer102to meet the criteria of a particular application. The transport layer104may be implemented per the Fibre Channel specification, the Internet SCSI specification and/or the Infiniband specification. The transport layer104may include a session sub-layer. Transport layers of other transport protocols may be implemented to meet the criteria of a particular application. The ScsiOp pool110may be implemented as a list of pre-allocated SCSI operations to reduce overhead of allocation SCSI protocol context from the SCSI layer102to the transport layer104. The session IORB pool112and the immediate IORB pool114may each be implemented as a list of pre-allocated transport protocol context to minimize allocation and to support transport credit and flow of control mechanisms.

The SCSI operation pool110generally requests a set of SCSI operations from the SCSI layer102at initialization and whenever the SCSI operation pool110is empty or at a predetermined low water mark. The SCSI operation pool110may allocate SCSI operations to the immediate IORB pool114and one or more session IORB pools112(only one shown for clarity) of the transport layer104, one at a time, as requested by the IORB pools112and114. When a session is closed, the respective session IORB pool112may release the associated SCSI operations back to the originating SCSI operation pool110rather than the SCSI layer102. Releasing to another pool within the transport layer104generally preserves a small reservoir of SCSI operations for command processing in the transport layer104.

Some SCSI operations may be released in the SCSI layer102as the commands are processed. The flow of SCSI operations as commands are completed may be used to unlink the release of SCSI layer resources from the completion of each command processing by the transport layer104. The flow may also allow SCSI operations to move between transport layers as demand varies dynamically between the transport layers.

Referring toFIGS. 2 and 3, block diagrams of example organizations of a transport layer session IORB pool112and an immediate IORB pool114are shown. The transport layer session IORB pool (or “session IORB pool” for short)112and the immediate IORB pool114may have a similar structure. Each of the session IORB pool112and the immediate IORB pool114may generically be referred to as an IORB pool120, IORB pools120and IORB pools112/114, unless otherwise noted. Each IORB pool120generally comprises multiple elements (or values) described in more detail below.

One or more elements (e.g., HeldIORBList) may form a held list122. The held list122generally comprises I/O request blocks for which SCSI operations are not available. The held IORBs may be linked to SCSI operations when a dynamic capacity of the IORB pool120is increased.

One or more elements (e.g., ReadyIORBList) may form a ready list124. The ready list124generally comprises I/O request blocks for SCSI operations that have been allocated. The ready I/O request blocks may be available for incoming SCSI command requests, task management requests, SCSI layer management requests and other similar requests.

An element (e.g., AbsMaxDepth) may define a maximum number of I/O request blocks in the IORB pool120. The element AbsMaxDepth may have a different value for (i) each transport protocol, (ii) each of the immediate IORB pools114and (iii) each of the session IORB pools112within the same transport layer104.

An element (e.g., AbsMinDepth) may define a number of I/O request blocks in the IORB pool120for which SCSI operations are reserved. The element AbsMinDepth may have a different value for (i) each transport protocol, (ii) each of the immediate IORB pools114and (iii) each of the session IORB pools112within the same transport.

An element (e.g., CurMaxDepth) may define a number of I/O request blocks for which SCSI operations are available when SCSI operations are generally equitably distributed across all IORB pools120. The element CurMaxDepth value may reference a number common to all session IORB pools112in a transport layer104.

An element (e.g., HeldCount) may define a number of I/O request blocks in the held list122. The element HeldCount may store a held number. The element HeldCount value generally determines how many SCSI operations may be reallocated to the originating IORB pool120during a refill operation. The element HeldCount number may indicate how may I/O request blocks do not have an associated SCSI operation.

An element (e.g., ReadyCount) may define a number of I/O request blocks in the ready list124. For session IORB pools112, the element ReadyCount generally defines a current command processing capacity of the session. For the immediate IORB pool114, the value ReadyCount generally defines a number of immediate delivery SCSI commands and task management requests that may be processed.

Bars126(one in each ofFIGS. 2 and 3) graphically represent all I/O request blocks available to the IORB pool120. I/O request blocks (e.g., IORB127) that have SCSI operations residing in the ready list124may be indicated at a bottom part of the bar126. I/O request blocks in use by a session for command processing are generally indicated by a middle part128of the bar126. I/O request blocks that do not have SCSI operations residing in the held list122may be indicated in an upper part of the bar126. Note that the held list122for the immediate IORB pool114may always be empty since an absolute minimum depth value (AbsMinDepth) of the immediate IORB pool114and a current maximum depth value (CurMaxDepth) may be always equal to an absolute maximum depth value (AbsMaxDepth).

The value ReadyCount is generally a length of the ready list124. The value ReadyCount may represent the unused command capacity of a session. The value ReadyCount and the value CurMaxDepth may be compared when an I/O request block is released to determine if the released I/O request block should be reallocated a SCSI operation. The value HeldCount is generally a length of the held list122. The value HeldCount may represent available I/O request blocks without SCSI operations. A difference between the value AbsMaxDepth and the value CurMaxDepth may be compared with the value HeldCount to determine if the IORB pool120should accumulate SCSI operations when an I/O request block is returned to the IORB pool120after the completion of a SCSI operation.

Each IORB pool120may be created with an AbsMaxDepth number of I/O request blocks. For session IORB pools112, the value AbsMaxDepth generally defines an absolute maximum command capacity of the sessions for a transport layer. For an immediate IORB pool114, the value AbsMaxDepth generally defines an absolute maximum number of immediate delivery SCSI tasks, SCSI task management requests and SCSI layer management operations that may be processed by the transport layer104.

Each IORB pool120may have an AbsMinDepth number of SCSI operations reserved for future use. For the session IORB pools112, the value AbsMinDepth may be set to a minimum number of SCSI operations used to operate the transport protocol session. For an immediate IORB pool114, the value AbsMinDepth may be set to a minimum number of SCSI operations used for the immediate command operation of the transport layer104.

Each session IORB pool112may have at most a CurMaxDepth number of I/O request blocks with SCSI operations allocated to fairly spread the SCSI operations of the SCSI layer102across all active sessions. The value CurMaxDepth is generally held in a quantity (e.g., SessionMaximumPoolDepth) for the transport layer104. The value CurMaxDepth for a session IORB pool112may be recomputed each time a session is created or destroyed. A field holding the value CurMaxDepth of each session IORB pool112generally references the quantity SessionMaximumPoolDepth for the transport layer104. The immediate IORB pool114may have a value CurMaxDepth set similar to the value AbsMaxDepth and the value AbsMinDepth for the immediate IORB pool114. The value CurMaxDepth for an immediate IORB pool114generally does not change as sessions are created and destroyed. Thus, the value CurMaxDepth for the immediate IORB pool114may reference the value AbsMaxDepth element for the immediate IORB pool114.

The dynamic capacity allocation mechanism generally uses the following transport layer104wide quantities. Each transport layer104may have a unique set of element values. An element (e.g., MaximumNumberSessions) may define a value for a maximum number of simultaneous sessions supported by the transport layer104. An element (e.g., NumberScsiOps) may define a value for a total number of SCSI layer102SCSI operations available in the storage device. An element (e.g., NumberReservedImmediateSsciOps) may define a value for a number of SCSI operations reserved by the transport layer104for (i) SCSI tasks and SCSI task management requests marked for immediate delivery and (ii) SCSI layer management operations originating in the transport layer104. An element (e.g., NumberReservedSessionScsiOps) may define a value for a number of SCSI operations reserved by a particular transport layer104for minimal operation of sessions within the particular transport layer104. An element (e.g., NumberAvailableScsiOps) may define a value for a number of SCSI operations not reserved by any transport layer104. The unreserved SCSI operations are generally available for dynamically balancing session command processing capacity across the sessions of the transport layers104.

An element (e.g., AbsoluteMaximumPoolDepth) may define a value for a maximum depth of the session IORB pools112. The value AbsoluteMaximumPoolDepth generally defines the maximum command queue depth of the sessions in a transport layer104. An element (e.g., AbsoluteMinimumPoolDepth) may define a value for a minimum depth of session IORB pools112. The value AbsoluteMinimumPoolDepth generally defines the number of SCSI operations reserved for minimum acceptable operation of the sessions in a transport layer104. An element (e.g., SessionMaximumPoolDepth) may define a value for a dynamically adjusted session IORB pool112maximum pool depth. The value SessionMaximumPoolDepth may always reside between the value AbsoluteMaximumPoolDepth and the value AbsoluteMinimumPoolDepth inclusively. An element (e.g., SessionIORBPoolCount) may define a value for a number of active session IORB pools112. The value SessionIORBPoolCount may be updated as session IORB pools112are created and destroyed for the sessions of the transport layer104. The above quantities are generally initialized when the transport layer104is initialized and used to initialize the immediate IORB pool114and the session IORB pool112elements as session IORB pools112are created and destroyed for the sessions of the transport layer104.

The SessionMaximumPoolDepth transport wide quantity is generally recomputed as transport sessions are opened and closed as follows:

When SessionIORBPoolCount is greater than zero, then
SessionMaximumPoolDepth=(NumberAvailableScsiOps/SessionIORBPoolCount)+AbsoluteMinimumPoolDepth
and when SessionIORBPoolCount is zero, then
SessionMaximumPoolDepth=AbsoluteMaximumPoolDepth

Referring toFIG. 4, a block diagram illustrating an example opening of a session is shown. In particular, a relationship between the element SessionMaximumPoolDepth and the other elements in session IORB pools112a-112care shown. The session IORB pools112aand112bmay be already open in the example when the new session pool112copens.

When a session3and an associated session IORB pool112care opened, the value SessionMaximumPoolDepth generally decreases (as indicated by arrow130) if more I/O request blocks are present in all of the sessions (e.g., session1, session2and session3) than SCSI operations available in the system100. All sessions (e.g., session1and session2) that were open before the new session3opens may have more than a fair allocation of SCSI operations. As such, the common fair allocation may be lowered across all session IORB pools112a-112cto accommodate the new session3. In the example illustrated, a length132of the held lists122aand122bfor session1and session2may expand as the value SessionMaximumPoolDepth drops from a value134to a value136. If the ready lists124aand/or124bend above the new SessionMaximumPoolDepth value136(e.g., session1), the associated session IORB pool112(e.g.,112a) may be considered to have an over allocation of SCSI operations. A session IORB pool112(e.g.,112a) with too many SCSI operations generally does not reclaim SCSI operations for I/O request blocks as SCSI operations are completed. Instead, completed SCSI operations may be left in the SCSI layer102for reallocation to other IORB pools120. If the ready lists124aand/or124bend below the new SessionMaximumPoolDepth value136(e.g., session2and session3), the associated session IORB pool112(e.g.,112band112c) may be considered to have less that a fair share of SCSI operations. Allocation of additional SCSI operations up to the SessionMaximumPoolDepth value136may be accomplished as part of a refill operation.

Referring toFIG. 5, a block diagram illustrating an example closing of a session is shown. Both session IORB pools112dand112emay be already open in the example when the session IORB pool112ecloses.

When a particular session (e.g., session5) is closed, the value SessionMaximumPoolDepth in the remaining open session IORB pools112(e.g.,112d) generally-increases (as indicated by arrow140) as the SCSI operations allocated to the closed session are redistributed throughout the system100. All sessions remaining open (e.g., session4) after the particular session closes may have less than a newly calculated fair allocation of SCSI operations. For example, the value SessionMaximumPoolDepth may move from a value142below a held list122dto a value144within the held list122d. As I/O request blocks are returned to the session IORB pool112dwith an under allocation of SCSI operations, new SCSI operations are acquired by the session IORB pool112d. The session IORB pool112dgenerally uses a modified greedy process to reallocate and gain additional SCSI operations. When an I/O request block is released and the session IORB pool112dis below the fair share value144of SCSI operations, the session IORB pool112dmay allocate SCSI operations to I/O request blocks in the held list122duntil (i) the fair share value144is obtained, (ii) a refill limit is reached or (iii) no more SCSI operations are available to acquire.

Referring again toFIG. 1, the transport layer104may pre-allocate a set (e.g., AbsMinDepth or some other value) of SCSI operations to reduce an overhead of reallocating SCSI operations. The pre-allocated SCSI operations are generally held in the SCSI operation pool110. As each immediate IORB pool114and session IORB pools112are created, each immediate IORB pool114and session IORB pool112may allocate SCSI operations, one at a time, from the SCSI operation pool110. Allocation may continue until the IORB pools112/114reaches either a respective current maximum I/O request block depth or until there are no more SCSI operations available. Note that the transport layer104generally has reserved a minimum number of SCSI operations so each IORB pool112/114may allocate at least a predetermined minimum number (e.g., AbsMinDepth) of SCSI operations.

As a number of requested operations are received from a SCSI initiator148via the signal C over the transport layer104or if the transport layer104generates a SCSI layer management operation, a similar number of I/O request blocks with associated SCSI operations may be allocated from an IORB pool112/114to track the requested operations. Each I/O request block may be taken from either (i) the shared immediate IORB pool114for immediate delivery operations or (ii) a session specific IORB pool112. A reservation characteristic of each SCSI operation pulled from an IORB pool112/114may be set if a depth (ReadyCount) for the originating IORB pool112/114is below the minimum depth for maintaining session operation. From the transfer block116, the SCSI operation may be sent to the SCSI layer102. Upon completion of the requested operation, the associated SCSI operation may be released to the SCSI layer102and the I/O request block may be returned to the originating IORB pool112/114from which allocated. A reserved SCSI operation may be returned to the originating transport layer104. The IORB pools112/114generally allocate new SCSI operations from the SCSI operation pool110only when fewer than the fair share of SCSI operations remain. In the life cycle, the dynamic capacity allocation may be implemented entirely in the allocation and release processes of the IORB pools112/114with cooperation from the SCSI layer102for reallocating reserved SCSI operations back to transport layer104requesting the reservation.

Referring toFIG. 6, a flow diagram of an example implementation of an allocation method150is shown. The allocation method (or process)150generally comprises a block (or step)152, a block (or step)154, a block (or step)156, a block (or step)158, a block (or step)160, a block (or step)162, a block (or step)164and a block (or step)166. The allocation method150generally begins with a receipt of a request from a caller (e.g., initiator148) for an IORB allocation (e.g., block152) via signal C. The ready list124of an IORB pool120may be checked (e.g., decision block154) to determine if empty. If the ready list124is empty (e.g., the YES branch of decision block154), the IORB pool120generally returns a NULL indication (e.g., block156) via signal C to indicate that no resources (e.g., no command processing capacity) may be available to satisfy the request. Any unique value distinguishable from a valid resource may be used as the return value. Otherwise (e.g., the NO branch of decision block154), a first I/O request block may be removed from the ready list124and the value ReadyCount is decremented (e.g., block158).

All common I/O request block initializations may be done automatically (e.g., block160) so that the caller is free from handling the initializations. If the ReadyCount is less than the absolute minimum depth (AbsMinDepth) for the IORB pool120(e.g., the YES branch of decision block162), the SCSI operation associated with the I/O request block may be marked as reserved for reallocation to the transport layer104of the originating IORB pool120(e.g., block164). Since the absolute minimum depth of the IORB pool120for immediate delivery commands may be similar to the number of IORBs in the IORB pool120, the transport reservation may always be set for I/O request blocks allocated from the immediate IORB pool114. After reservation of the SCSI operation or if the value ReadyCount is greater than or equal to the value AbsMinDepth (e.g., the NO branch of decision block162), the initialized IORB with an associated SCSI operation may be returned to the caller (e.g., block166).

Referring toFIG. 7, a flow diagram of an example implementation of a release method170is shown. The release method170generally comprises a block (or step)172, a block (or step)174, a block (or step)176, a block (or step)178, a block (or step)180, a block (or step)182, a block (or step)184, a block (or step)186, a block (or step)188, a block (or step)190, a block (or step)192, a block (or step)194, a block (or step)196, a block (or step)198, a block (or step)200and a block (or step)202.

An I/O request block is always released to same IORB pool120from which the I/O request block was allocated. On release (e.g., block172), the value ReadyCount of the originating IORB pool120may be compared with the value CurMaxDepth (e.g., decision block174). If the value ReadyCount is not less than the value CurMaxDepth (e.g., the NO branch of decision block174), the IORB pool120may have an over allocation of SCSI operations. Therefore, the I/O request block may be placed in the held list122and the value HeldCount may be incremented (e.g., block176). The release method170may then be considered completed (e.g., block178). Otherwise (e.g., the YES branch of decision block174), an attempt to allocate a replacement SCSI operation from the SCSI operation pool110or SCSI layer102may be performed (e.g., block180). If no SCSI operation is available (e.g., the NO branch of decision block182), the I/O request block may be placed in the held list122and the value HeldCount incremented (e.g., block176). The release may then be completed (e.g., block178). If a SCSI operation is available (e.g., the YES branch of decision block182), the transport reservation mark of the SCSI operation may be cleared (if set) and the SCSI operation linked to the I/O request block (e.g., block184). The I/O request block may then be placed in the ready list124and the value ReadyCount may be incremented (e.g., block186). For an immediate IORB pool114, the I/O request block may always receive a new SCSI operation and the I/O request block may be placed in the ready list124.

After the released I/O request block is added to the ready list124, the IORB pool120generally implements a “greedy” refill process to obtain as many SCSI operations as possible. The greedy refill process may calculate the value HeldCountMax by subtracting the value CurMaxDepth from the value AbsMaxDepth (e.g., block188). The value HeldCountMax may be adjusted to reflect the maximum refill if the IORB pool120is implementing a modified greedy refill process (e.g., block190). For an immediate IORB pool114, the value HeldCountMax may always be zero and the held list122may always be empty. Next, a sequence of I/O request blocks may be moved from the held list122to the ready list124(e.g., blocks192-202) until the held list122is either (i) reduced to a maximum length (e.g., the NO branch of decision block192) or (i) no more SCSI operations are available (e.g., the NO branch of decision block196). If the value HeldCount is not greater than the value HeldCountMax (e.g., the No branch of decision block192), the release method170may be completed (e.g., block178). Otherwise (e.g., the YES branch of decision block192), an attempt may be made to allocate an additional SCSI operation from the SCSI operation pool110or SCSI layer102(e.g., block194). If no SCSI operation is available (e.g., the NO branch of decision block196), the release method170may be completed (e.g., block178). Otherwise (e.g., the YES branch of decision block196), an I/O request block may be removed from the held list122and the value HeldCount may be decremented (e.g., block198). The SCSI operation transport reservation may also be cleared (if set) and the SCSI operation linked to the I/O request block (e.g., block200). Afterwards, the I/O request block may be placed in the ready list124of the IORB pool120and the value ReadyCount may be incremented (e.g., block202). The release method170generally repeats comparing the decremented value HeldCount to the previously computed value HeldCountMax (e.g., back to decision block192).

In a driver stack with multiple transport layers, each transport layer104may use different I/O request block contexts. The IORB pools120for each transport layer104generally contain the unique I/O request block for the transport layer104. The IORB pools120may use a union of all I/O request block contexts, a subclass mechanism, or have unique I/O request blocks depending on the implementation language. Combinations of the above aspects may vary from implementation to implementation within the scope of the present invention.

The present invention may have the following advantages when compared with a traditional static command processing capacity allocation scheme. A command processing capacity of a storage device may be adjusted dynamically across multiple transports. The command processing capacity may be adjusted dynamically across sessions within a single transport. The storage device may provide additional command processing capacity to each session when the system is lightly loaded. The storage device generally provides a guaranteed minimum command processing capacity to a larger number of sessions. Implementation of the present invention generally adds just a small overhead for allocating and releasing I/O request block contexts when compared with a static allocation scheme.

The function performed by the flow diagrams ofFIGS. 1,6and7may be implemented using a conventional general purpose digital computer programmed according to the teachings of the present specification, as will be apparent to those skilled in the relevant art(s). Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s).

The present invention thus may also include a computer product which may be a storage medium including instructions which can be used to program a computer to perform a process in accordance with the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disk, optical disk, CD-ROM, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, Flash memory, magnetic or optical cards, or any type of media suitable for storing electronic instructions. As used herein, the term “simultaneously” is meant to describe events that share some common time period but the term is not meant to be limited to events that begin at the same point in time, end at the same point in time, or have the same duration.