METHOD AND APPARATUS FOR
PROCESSING CHAIN MESSAGES (SGL
FIELD OF THE INVENTION
The present invention relates to a message-based I/O architecture generally and, more particularly, to a method and/or apparatus for processing chain messages.
BACKGROUND OF THE INVENTION
A device driver interfaces a particular hardware device to a specific operating system (OS). The device driver can be split into two modules: one that contains all the OS-specific code and the other for hardware-specific code. The OS-specific module of the device driver can convert operating system calls into I/O transactions. The hardwarespecific module of the driver contains vendor-specific code that converts the hardware level interface of the hardware device to the functions required for the particular class of device.
A message-based interface can be used to enable direct message passing between any two device driver modules for a particular class of I/O (message class). Message classes can include (i) LAN ports, such as Ethernet or Token Ring controllers; (ii) random block storage devices, such as hard disk drives and CD-ROM drives; (iii) sequential storage devices and variable block-size devices, such as tape drives; (iv) host bus adapters such as SCSI ports; (v) SCSI devices; (vi) peer data services; (vii) hot plug controller; (viii) IDE controllers and devices; (ix) floppy disk controllers and devices; (x) Fibre Channel; and (xi) WAN ports, such as ATM controllers.
When information is sent to a storage controller, the information frequently does not fit into a single message frame. The information can be split into multiple message frames. When the information is split (segmented) into multiple frames, a "link" or "chain" is needed to re-assemble the information from the multiple message frames.
Conventional hardware and/or firmware solutions traverse a scatter gather list (SGL) to find a "link" or "chain". The conventional methods for finding the link or chain can require significant processor and hardware overhead. Conventional message chaining is limited to extending SGLs.
SUMMARY OF THE INVENTION
The present invention concerns a message-based I/O architecture comprising a list describing one or more source buffers and a message header. The list may be segmented in multiple memory locations. The message header may be configured to (i) indicate whether the list is segmented and (ii) provide information for linking the list when the list is segmented.
The objects, features and advantages of the present invention include providing a method and apparatus for processing chain messages that may (i) simplify checks for chains for dedicated hardware components and embedded firmware, (ii) provide an indication that a chain exists in a message frame header, and/or (iii) provide a location where chain information is located.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other objects, features and advantages of the present invention will be apparent from the following detailed description and the appended claims and drawings in which:
FIG. 1 is a block diagram illustrating a message header in accordance with a preferred embodiment of the present invention;
FIG. 2 is a block diagram illustrating an example of a 5 simple scatter gather element in accordance with a preferred embodiment of the present invention;
FIG. 3 is a block diagram illustrating a chain SG element in accordance with a preferred embodiment of the present invention;
10 FIG. 4 is a block diagram illustrating a transaction context SG element in accordance with a preferred embodiment of the present invention; and
FIG. 5 is a flow diagram illustrating an example SCSI I/O message with a chained SGL in accordance with a preferred
15 embodiment of the present invention.
DETAILED DESCRIPTION OF THE
Referring to FIG. 1, a block diagram illustrating a mes2Q sage header 100 implemented in accordance with a preferred embodiment of the present invention is shown. The message header 100 may be implemented as a number of bytes at the beginning of a message frame. In one example, the message header 100 may be implemented as the first 12 bytes of a message frame. The message header 100 may comprise a field 102, a field 104, a field 106, a field 108, a field 110, and a field 112. The field 102 may be implemented as a function field. The field 104 may be implemented as a chain offset field. The field 106 may be implemented as a function 3Q dependent field. The field 108 may be implemented as a second function dependent field. The field 110 may be implemented as a message flags field. The field 112 may be implemented as a message context field.
The field 102 may contain a function number for a 35 particular message. The function number may be used to differentiate one message from another message. The function number may be used to set a format for a remainder of the message.
The field 104 may contain information indicating whether
40 a scatter gather list (SGL) associated with the message header 100 is segmented into multiple memory locations. When the SGL is not segmented, the field 104 may contain a null value. When the SGL is segmented, the field 104 may contain an offset from the beginning of the message frame
45 to a location of a scatter gather (SG) element containing chaining information. In one example, the offset may be expressed as a number of 32-bit words.
The fields 106 and 108 may be formatted to support the function specified by the field 102. The field 110 may
50 contain a number of bits indicating a state of a number of message flags. In one example, a reserved bit may be set to a logical LOW ("0"). However, other states for reserved bits may be identified in specific messages.
The field 112 may contain a value specified by a host
55 driver to uniquely identify a particular message when processing replies. The value specified by the host is generally returned unmodified in a reply. However, when a protocol that uses context replies is implemented, the values that may be used in the field 112 may be restricted. In particular, the
60 protocol may restrict the use of one or more bits of the field 112. For example, a protocol for SCSI IO message passing may use a number of bits of the field 112 (e.g., the upper three bits) to implement (i) an address field (e.g., one or more bits that indicate whether a reply is an address reply or
65 a context reply) and (ii) a type field (e.g., one or more bits that indicate a type of the context reply) when the reply is a context reply.