Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output addressing
Reexamination Certificate
2000-05-11
2003-07-08
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output addressing
C710S005000, C710S033000, C710S048000
Reexamination Certificate
active
06591310
ABSTRACT:
BACKGROUND OF THE INVENTION
In general, the present invention relates to communicating message information, or data, over message passing interface(s) between program modules, such as a target peripheral device module and an operating system (OS) module within an I/O system, whether the modules are executed on the same or different digital computer processors and whether utilizing different operating systems. Of particular interest is the message reply portion of the communication between I/O system modules to, eventually, send status information back to the caller (e.g., an operating system) that issued the original command, regardless of the specific communications protocol and interface technology employed. More particularly, the invention relates to a unique method of responding over an I/O message passing medium to a corresponding request message, by way of an associated novel reply descriptor transmitted in response thereto.
Within an I/O system, typical computer hardware includes a host system entity connected to communicate with one or more I/O devices. The trend in development of I/O system architecture is to utilize a split driver model, see
FIG. 1
, as explained more-fully in a Version 2.0 of the “Intelligent I/O Architecture Specification” dated Feb. 11, 1999 (herein referred to as simply “I
2
O Specification”), the written work product of the collaborative effort of several commercial entities including the applicant hereof. Within the split driver model two basic software modules are defined, each of which can execute on different physical processors and within different operating environments: (1) an OS-specific module (OSM) which provides an interface to the operating system (OS); and (2) a hardware device module (HDM) which provides an interface to each I/O adapter and corresponding device. These two basic modules intercommunicate via a logical “messaging layer” comprised of a network of MessengerInstances (depicted in FIGS. 2-3 of the I
2
O Specification) as illustrated herein in
FIG. 1
over which request messages to I/O devices and completion reply messages are transmitted to effect commands from the operating system rather than having the host/OSM directly read and write from and to each I/O device register. The split driver model allows for expansion of the I/O system through software development, independent of both device hardware and the operating system.
I. Conventional Way to Respond to Requests per I
2
O Specification
Additional layers of stackable drivers beyond the basic OSM and HDM can be logically defined as has been done in the I
2
O Specification to provide additional functionality between the two basic program modules. The stacking of drivers increases the request and reply message load of the system, in turn decreasing its speed/performance. For example when operating within I
2
O, on the order of 28,000 I/O messages are transmitted per second. The I
2
O Specification explains in Section 3.4.1 (“Message Structure and Definitions”), messages are data structures that contain a fixed-size header containing device address and payload description and, immediately following, a variable-size payload containing all additional information associated with the message. If the payload refers to memory, a scatter-gather list (SGL) is included in a format understandable by the originator, the target, the transport, and any intermediate software layers. The header and payload parts reside within a physically-contiguous buffer called the message frame buffer (such as is shown in FIGS. 3-19 of the I
2
O Specification).
I
2
O messages fall into two basic categories: (1) request messages initiate activity at the destination (a request may contain multiple transactions of the same type); and (2) reply messages return status information concerning one or more requests. According to I
2
O convention, a reply message is generated and sent for every request (see I
2
O Specification sections 6.1.2 and 6.4.4), regardless of whether the request was completed without error (see section 6.4.4.2.1 of I
2
O).
I
2
O convention classifies all messages, each class has a format for request messages and a protocol for generating and transmitting reply messages for that class. For example, ‘utility messages’ are common to all message classes, and messages specific to a particular message class are ‘base class messages’. According to the I
2
O Specification, inbound and outbound queues are reserved for each I/O platform (referred to therein as “IOP”—see
FIGS. 2A and 2B
schematically outlining the relationship between a host platform, an IOP1, and IOP2). Note that the I
2
O Specification uses IOP synonymously with an ‘I/O processor entity’ dedicated to processing I/O transactions (consisting of processor, memory, and I/O devices). The inbound queue of an IOP receives messages from all other platforms, including the host system, and the outbound queue of each IOP collectively function as an input queue for the host system. Thus, each IOP provides support for passing messages without requiring additional host system hardware. Once IOPs establish connection, the program modules at each end of the connection can send and receive messages (generally in an asynchronous fashion as non-blocking by nature). In the specific case of an SCSI Controller, for example, it is the SCSI hardware device module that detects and registers devices connected to the SCSI bus—and these devices are accessible through messages passed through the SCSI hardware device module.
According to I
2
O section 6.1.2, reply messages fall into two general categories (as identified by the REPLY bit in the message header's MessageFlags field): “failed” messages and “processed” messages. Failed messages are those that cannot be processed (including messages that cannot be delivered or contain invalid or missing data). A request message “fails” when the message layer cannot deliver the message or the target device does not understand the format of the request (e.g., unknown message version). Section 6.1.2.1 further distinguishes a failed message from one that is processed but is unable to be successfully completed due to “error”: The inability of a device driver module (DDM) to perform or carry out the request is referred to as an “error”. Thus, a successfully completed request is one that is processed without error. Note that in I
2
O, the acronym DDM is often used generically in place of specifying whether the module is a hardware device module (HDM) or an intermediate service module (ISM).
Section 3.4.1.2.2 of I
2
O specifies the template for a “normal single transaction reply message” as shown in FIGS. 3-23; and section 3.4.3.2 identifies a “multiple transaction reply message” model (wherein one or more successful transactions may be combined into one reply message, see section 6.4.4.2.2 of I
2
O).
As shown and explained in more detail in Chapter 2 of the I
2
O Specification (pages 2-19 through 2-22), whether request messages are sent from the host system to a hardware device module or are sent peer-to-peer (from one hardware device module to another), all reply messages built include the Initiator Address, Target Address, and the Initiator Context field from the request message. Once the reply message is built, the hardware device module calls a respective message service. The sending entity allocates a reply message frame, copies the reply message into the frame and places/writes the frame's address in the appropriate message queue. I
2
O FIGS. 2-13 diagrams the flow of events for its conventional process of sending request and reply messages (I
2
O Specification explanation reproduced below, for reference):
1. The operating system issues an I/O request.
2. The OSM (Operating System Module) accepts the request and translates it into a message addressed to the DDM (I
2
O uses the acronym DDM generically for hardware device module, HDM, or intermediate service module, ISM). The Initiator Context field is set to indicate the message handler for the reply. The OSM has the option to place a pointer to the
Gaffin Jeffrey
LSI Logic Corporation
Macheledt Bales LLP
Perveen Rehana
LandOfFree
Method of responding to I/O request and associated reply... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of responding to I/O request and associated reply..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of responding to I/O request and associated reply... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3066396