US20040177172A1 - Handling service requests - Google Patents
Handling service requests Download PDFInfo
- Publication number
- US20040177172A1 US20040177172A1 US10/757,913 US75791304A US2004177172A1 US 20040177172 A1 US20040177172 A1 US 20040177172A1 US 75791304 A US75791304 A US 75791304A US 2004177172 A1 US2004177172 A1 US 2004177172A1
- Authority
- US
- United States
- Prior art keywords
- request
- identifier
- information
- requests
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims description 32
- 230000002093 peripheral effect Effects 0.000 claims description 8
- 230000001419 dependent effect Effects 0.000 claims 2
- 238000003491 array Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 4
- 230000003111 delayed effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/40—Bus structure
- G06F13/4004—Coupling between buses
- G06F13/4027—Coupling between buses using bus bridges
- G06F13/4031—Coupling between buses using bus bridges with arbitration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F2213/0024—Peripheral component interconnect [PCI]
Definitions
- This invention relates to handling service requests.
- An input/output (I/O) hub connected to peripheral components can issue multiple requests for information from the peripheral components.
- the circuit processes the returned information. Sometimes, the requests are returned in the order in which they are issued. In other cases, the requests are returned in the order in which they are completed by the peripheral component. The completion order can differ from the issuance order.
- FIGS. 1 and 2 are block diagrams.
- FIGS. 3 and 4 are flowcharts.
- control logic 102 generates and manages identifiers for multiple requests that are made to target components 170 for information to be returned.
- the control logic enables outbound logic 110 to issue multiple requests that are either ordered or unordered. The ability to handle unordered requests, as well as ordered requests, reduces the delay in receiving completions of these requests.
- control logic is operated separately from the outbound logic so that the outbound logic can send requests as usual without needing to track requests that have been sent, but not yet fulfilled. Thus, the outbound logic is not delayed in sending outbound requests.
- system 100 includes an input/output (I/O) chip 105 , a bus 150 , and a bridge chip 160 that is connected to multiple target components 170 (only two are shown, but there may be many).
- the I/O chip 105 can be a Server I/O Hub Component (SIOH)
- the bus 150 can be the a Hublink Bus
- the bridge chip 160 can be a peripheral component interconnect (PCI) to PCI bridge. Communication from the I/O chip 105 to the target components 170 is mediated by the bus 150 and the bridge chip 160 .
- SIOH Server I/O Hub Component
- PCI peripheral component interconnect
- the I/O chip 105 includes the outbound logic 110 , an inbound logic 120 , and a configuration block 130 .
- the outbound logic 110 generates multiple requests to the target components 170 for information to be returned. Responses to these requests, so-called completions, are returned to the inbound logic 120 .
- the outbound logic can send requests as needed, even before previous requests have been completed.
- the outbound logic 110 sends the requests to the bridge chip 160 with a request header 111 .
- the request header includes header information 135 that identifies the request and a pipe identifier 112 that was provided by the control unit 130 during the preceding request cycle. That is, in each request cycle, the control unit 130 generates and provides to the outbound logic 110 a pipe identifier 112 to be used in the header of the next outbound request generated by the outbound logic.
- pipe we mean one or more requests that are ordered with respect to each other. Of course, when the pipe refers to a single request, the order is irrelevant.
- the pipe identifier indicates the order of completions for requests in a series of requests.
- completions having the same pipe identifier are received in the same order by the in bound logic 120 with respect to one another as the order in which the corresponding requests were sent originally by the outbound logic 110 .
- Completions that have different pipe identifiers can be returned to the SIOH 105 in any order with respect to each other.
- the outbound logic 110 When the outbound logic 110 sends a request to the bridge chip 160 , the outbound logic 110 also sends the request header 111 to the control unit 130 .
- the control unit 130 stores the header 111 in a register array 131 .
- the control unit 130 includes as many register arrays 131 as the number of outstanding requests that it can handle.
- Each register array 131 includes seven bits of control information 137 : a validity bit 132 that indicates that the request is pending, the pipe identifier 133 , and a priority value 134 that defines an order of requests that have a common pipe identifier.
- the request header also includes the identifying header information 135 used by the outbound logic 110 . This header information 135 can include routing information and other pertinent information such as length of transaction, type of transaction (e.g., input/output, memory, or configuration) and completion status (e.g., normal, master, or target abort).
- the control unit 130 stores 210 the control information 137 for each request header 111 and the header information 135 in the first empty slot of the register arrays 131 .
- an empty slot is always available, as the outbound logic 110 is prevented from sending a request if the register arrays are full 131 . This check is described below.
- the seven bits of control information 137 are set 320 .
- the valid bit 132 is set to 1, indicating that the slot is occupied by an outstanding (uncompleted) request.
- the 3-bit pipe identifier field 133 is set.
- the 3-bit priority field 134 is set to indicate the priority of the current request relative to other requests that have the same pipe identifier.
- the control unit 130 includes a counter that tracks a current priority value for each outstanding pipe identifier. If the current request has a unique pipe identifier, this field is set to the highest priority value, e.g., 001. If the current request is one of multiple requests that are ordered, then it is given the highest available priority value. For example, the second request in the series would receive a priority value of 010.
- the pipe identifier generator block 136 determines 330 the pipe identifier for the next request, Nx_Pipe_ID 112 . The determination depends on whether the current request is strongly ordered with respect to other outstanding requests, or if it can be returned in any order.
- the control unit 130 queries a configuration block 115 for a configuration bit, Serial_Pipe_ID_Enable 116 , of the bridge chip 160 to determine if the request requires ordering.
- the configuration bit 116 is set when the system 100 is configured, e.g., at start-up or during a reset.
- the pipe identifier generator block 136 If the bridge chip 160 is configured for out-of-order completions, then the pipe identifier generator block 136 generates a unique pipe identifier for the next request. The block queries each entry of its storage block until it finds an empty slot. It then sets the Nx_Pipe_ID 112 to the number of the empty slot, in this way essentially reserving that slot for use when the outbound logic 110 sends the request.
- Nx_Pipe_ID 112 is not assigned until one of the slots is freed by a completion.
- the block sets Nx_Pipe_ID 112 to 0 , or, in some implementations, to the pipe identifier of the current request.
- the control unit 130 sends 114 the Nx_Pipe_ID 112 to the outbound logic 110 .
- Nx_Pipe_ID 112 is not valid until a completion is received and a slot in the register array is freed. Consequently, Nx_Pipe_ID 112 is not sent to the outbound logic 110 until a valid value can be assigned.
- the requirement for an Nx_Pipe_ID 112 at the outbound logic 110 prevents the outbound logic 110 from issuing another request until a completion is received and Nx_Pipe_ID 112 is assigned.
- the outbound logic 110 appends Nx_Pipe_ID 112 to the next request header and sends the request header to bus 150 for routing to the bridge 160 and then to target components 170 .
- Responses for each request are returned by way of the bridge chip 160 to the inbound logic 120 on the I/O chip 105 .
- the bridge chip 160 can receive partial or entire completions from the target components 170 .
- the bridge chip 160 might receive four 32-byte completion packets for a 128-byte request.
- the bridge chip 160 compares the pipe identifiers of outstanding requests and determines if they are the same or if they differ. If the pipe identifiers differ, the bridge chip 160 returns packets for the completions as they are received, i.e., whether or not responses are in the original order of their corresponding requests. Conversely, if the pipe identifiers are the same, the bridge chip 160 returns completions for the requests in the original order in which the bridge chip 160 received the requests (i.e., a first-in, first-out order).
- completion headers 151 for these completions are received 410 at the control unit 130 within the inbound logic 120 from the bridge chip 160 by way of the bus 150 .
- the control unit 130 passes the request header 141 of each response to the outbound completion tracker 140 which monitors the multiple partial completions received from the bridge chip 160 .
- Information about the size of the partial completion is used to determine if all required partial completions have been received.
- the control unit 130 also matches 420 the pipe identifier of each completion header 151 to the pipe identifiers 133 stored in the register arrays 131 for the outstanding requests.
- the bridge chip 160 returns these strongly ordered completions in the order that it receives them, identifying the highest priority value header for a received completion header in the register arrays 131 invariably matches the correct request header.
- the outbound completion tracker 140 is queried 430 to determine if all packets (i.e., partial completions) for the completion in question have been received. If they have not all been received, the control unit 130 does not retire the request.
- the control unit 130 retires 440 the request.
- the retiring process includes authorizing the completion to be sent onwards from the I/O chip 105 , e.g., to another chip on the chipset, clearing the valid bit in the register array 131 for the retired request to 0, and decrementing the priority field 134 for all other outstanding request headers with the same pipe identifier as the retired request.
- the decrementing process increases the priority of the outstanding request headers and insures that the completions are retired in order of their priority.
- a chipset can include multiple instances of the outbound logic 110 and the inbound logic 120 housing the control unit 130 .
- a chipset can include multiple hublink buses 160 , each for a particular I/O bridge chip 160 . In this case, one set of these logics is used to interface with each of the hublink buses 160 .
- the different I/O bridge chips 160 can be dedicated respectively for strongly ordered request handling or out-of-order request handling, the control unit 130 is able to manage either mode.
- the control unit 130 can also manage both type of requests as is required by a bridge chip 160 that switches between streams that demand strongly ordered completions and streams that accept out-of-order completions.
- control logic 130 may be located externally to the inbound logic 120 .
- control unit 130 can be located within the outbound logic 110 using appropriate communication with the inbound logic 120 .
- the completion tracker 140 can likewise be located in either the inbound 110 or outbound logic 120 or neither.
- the techniques described here are not limited to any particular hardware or software configuration; they may find applicability in any computing or processing environment.
- the techniques may be implemented in hardware, software, or a combination of the two.
- the techniques may be implemented in programs executing on programmable machines such as computers and other devices that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements).
- aspects of the invention are implemented as hardware, other aspects can be implemented in a high-level programming language to communicate with a machine system.
- a program can also be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
- An exemplary program is used to control the control unit 130 .
- a program may be stored on a storage medium or device, e.g., compact disc read only memory (CD-ROM), hard disk, magnetic diskette, or similar medium or device, that is readable by a general or special purpose programmable machine for configuring and operating the machine when the storage medium or device is read by the computer to perform the procedures described in this document.
- a storage medium or device e.g., compact disc read only memory (CD-ROM), hard disk, magnetic diskette, or similar medium or device, that is readable by a general or special purpose programmable machine for configuring and operating the machine when the storage medium or device is read by the computer to perform the procedures described in this document.
- the system may also be implemented as a machine-readable storage medium, configured with a program, where the storage medium so configured causes a machine to operate in a specific and predefined manner.
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Bus Control (AREA)
- Computer And Data Communications (AREA)
Abstract
A first component that stores information about requests for information directed to an interface (e.g., a bus of a computer system connected to components), receives an indication of a request sent by a second component to the interface. The first component sends an identifier for a subsequent request to the second component.
Description
- This application is a continuation application of and claims priority to U.S. application Ser. No. 10/008,595, filed on Dec. 6, 2001, the contents of which are hereby incorporated by reference in their entirety.
- This invention relates to handling service requests.
- An input/output (I/O) hub connected to peripheral components, can issue multiple requests for information from the peripheral components. The circuit processes the returned information. Sometimes, the requests are returned in the order in which they are issued. In other cases, the requests are returned in the order in which they are completed by the peripheral component. The completion order can differ from the issuance order.
- FIGS. 1 and 2 are block diagrams.
- FIGS. 3 and 4 are flowcharts.
- Referring to FIG. 1, in a
computer system 100, control logic 102 generates and manages identifiers for multiple requests that are made to targetcomponents 170 for information to be returned. The control logic enablesoutbound logic 110 to issue multiple requests that are either ordered or unordered. The ability to handle unordered requests, as well as ordered requests, reduces the delay in receiving completions of these requests. - The control logic is operated separately from the outbound logic so that the outbound logic can send requests as usual without needing to track requests that have been sent, but not yet fulfilled. Thus, the outbound logic is not delayed in sending outbound requests.
- Referring to FIG. 1,
system 100 includes an input/output (I/O)chip 105, abus 150, and a bridge chip 160 that is connected to multiple target components 170 (only two are shown, but there may be many). For example, the I/O chip 105 can be a Server I/O Hub Component (SIOH), thebus 150 can be the a Hublink Bus, and the bridge chip 160 can be a peripheral component interconnect (PCI) to PCI bridge. Communication from the I/O chip 105 to thetarget components 170 is mediated by thebus 150 and the bridge chip 160. - The I/
O chip 105 includes theoutbound logic 110, aninbound logic 120, and aconfiguration block 130. Theoutbound logic 110 generates multiple requests to thetarget components 170 for information to be returned. Responses to these requests, so-called completions, are returned to theinbound logic 120. The outbound logic can send requests as needed, even before previous requests have been completed. - Referring also to FIG. 2, the
outbound logic 110 sends the requests to the bridge chip 160 with arequest header 111. The request header includesheader information 135 that identifies the request and apipe identifier 112 that was provided by thecontrol unit 130 during the preceding request cycle. That is, in each request cycle, thecontrol unit 130 generates and provides to the outbound logic 110 apipe identifier 112 to be used in the header of the next outbound request generated by the outbound logic. By “pipe”, we mean one or more requests that are ordered with respect to each other. Of course, when the pipe refers to a single request, the order is irrelevant. - The pipe identifier indicates the order of completions for requests in a series of requests. When completions are returned to the
SIOH 105, completions having the same pipe identifier are received in the same order by the inbound logic 120 with respect to one another as the order in which the corresponding requests were sent originally by theoutbound logic 110. Completions that have different pipe identifiers can be returned to the SIOH 105 in any order with respect to each other. - When the
outbound logic 110 sends a request to the bridge chip 160, theoutbound logic 110 also sends therequest header 111 to thecontrol unit 130. - Referring also to FIG. 3, after receiving 310 the
request header 111, thecontrol unit 130 stores theheader 111 in aregister array 131. Generally, thecontrol unit 130 includes asmany register arrays 131 as the number of outstanding requests that it can handle. Eachregister array 131 includes seven bits of control information 137: avalidity bit 132 that indicates that the request is pending, thepipe identifier 133, and apriority value 134 that defines an order of requests that have a common pipe identifier. The request header also includes the identifyingheader information 135 used by theoutbound logic 110. Thisheader information 135 can include routing information and other pertinent information such as length of transaction, type of transaction (e.g., input/output, memory, or configuration) and completion status (e.g., normal, master, or target abort). - The
control unit 130 stores 210 thecontrol information 137 for eachrequest header 111 and theheader information 135 in the first empty slot of theregister arrays 131. Generally, an empty slot is always available, as theoutbound logic 110 is prevented from sending a request if the register arrays are full 131. This check is described below. - When a request header is received from the outbound logic, the seven bits of
control information 137 are set 320. First, thevalid bit 132 is set to 1, indicating that the slot is occupied by an outstanding (uncompleted) request. Second, the 3-bitpipe identifier field 133 is set. Third, the 3-bit priority field 134 is set to indicate the priority of the current request relative to other requests that have the same pipe identifier. Thecontrol unit 130 includes a counter that tracks a current priority value for each outstanding pipe identifier. If the current request has a unique pipe identifier, this field is set to the highest priority value, e.g., 001. If the current request is one of multiple requests that are ordered, then it is given the highest available priority value. For example, the second request in the series would receive a priority value of 010. - The pipe
identifier generator block 136 determines 330 the pipe identifier for the next request, Nx_Pipe_ID 112. The determination depends on whether the current request is strongly ordered with respect to other outstanding requests, or if it can be returned in any order. Thecontrol unit 130 queries aconfiguration block 115 for a configuration bit, Serial_Pipe_ID_Enable 116, of the bridge chip 160 to determine if the request requires ordering. Typically, theconfiguration bit 116 is set when thesystem 100 is configured, e.g., at start-up or during a reset. - If the bridge chip160 is configured for out-of-order completions, then the pipe
identifier generator block 136 generates a unique pipe identifier for the next request. The block queries each entry of its storage block until it finds an empty slot. It then sets the Nx_Pipe_ID 112 to the number of the empty slot, in this way essentially reserving that slot for use when theoutbound logic 110 sends the request. - If there are no empty slots, then Nx_Pipe_ID112 is not assigned until one of the slots is freed by a completion.
- If the
target component 170 for the current request requires strongly ordered completions, theblock sets Nx_Pipe_ID 112 to 0, or, in some implementations, to the pipe identifier of the current request. - Referring again to FIG. 2, after Nx_Pipe_ID112 is determined, the
control unit 130 sends 114 theNx_Pipe_ID 112 to theoutbound logic 110. As mentioned above, when all register arrays are in use, Nx_Pipe_ID 112 is not valid until a completion is received and a slot in the register array is freed. Consequently, Nx_Pipe_ID 112 is not sent to theoutbound logic 110 until a valid value can be assigned. The requirement for anNx_Pipe_ID 112 at theoutbound logic 110 prevents theoutbound logic 110 from issuing another request until a completion is received and Nx_Pipe_ID 112 is assigned. - When Nx_Pipe_ID112 is received, the
outbound logic 110 appends Nx_Pipe_ID 112 to the next request header and sends the request header tobus 150 for routing to the bridge 160 and then to targetcomponents 170. - Responses for each request are returned by way of the bridge chip160 to the
inbound logic 120 on the I/O chip 105. For any of the outstanding requests, the bridge chip 160 can receive partial or entire completions from thetarget components 170. For example, the bridge chip 160 might receive four 32-byte completion packets for a 128-byte request. - When returning completions for outstanding requests, the bridge chip160 compares the pipe identifiers of outstanding requests and determines if they are the same or if they differ. If the pipe identifiers differ, the bridge chip 160 returns packets for the completions as they are received, i.e., whether or not responses are in the original order of their corresponding requests. Conversely, if the pipe identifiers are the same, the bridge chip 160 returns completions for the requests in the original order in which the bridge chip 160 received the requests (i.e., a first-in, first-out order).
- Referring again to FIG. 2 and also to FIG. 4,
completion headers 151 for these completions, both partial and entire, are received 410 at thecontrol unit 130 within theinbound logic 120 from the bridge chip 160 by way of thebus 150. Thecontrol unit 130 passes therequest header 141 of each response to theoutbound completion tracker 140 which monitors the multiple partial completions received from the bridge chip 160. Information about the size of the partial completion is used to determine if all required partial completions have been received. - The
control unit 130 also matches 420 the pipe identifier of eachcompletion header 151 to thepipe identifiers 133 stored in theregister arrays 131 for the outstanding requests. - If different request headers have the same pipe identifier, as is the case for strongly ordered completions, then the request header with the highest priority value is forwarded to the
completion tracker 140. - Because the bridge chip160 returns these strongly ordered completions in the order that it receives them, identifying the highest priority value header for a received completion header in the
register arrays 131 invariably matches the correct request header. - The
outbound completion tracker 140 is queried 430 to determine if all packets (i.e., partial completions) for the completion in question have been received. If they have not all been received, thecontrol unit 130 does not retire the request. - If they have all been received, then the
control unit 130 retires 440 the request. The retiring process includes authorizing the completion to be sent onwards from the I/O chip 105, e.g., to another chip on the chipset, clearing the valid bit in theregister array 131 for the retired request to 0, and decrementing thepriority field 134 for all other outstanding request headers with the same pipe identifier as the retired request. The decrementing process increases the priority of the outstanding request headers and insures that the completions are retired in order of their priority. - Generally, the storing and retiring operations can occur concurrently on the
system 100. A chipset can include multiple instances of theoutbound logic 110 and theinbound logic 120 housing thecontrol unit 130. For example, a chipset can include multiple hublink buses 160, each for a particular I/O bridge chip 160. In this case, one set of these logics is used to interface with each of the hublink buses 160. While the different I/O bridge chips 160 can be dedicated respectively for strongly ordered request handling or out-of-order request handling, thecontrol unit 130 is able to manage either mode. Of course, thecontrol unit 130 can also manage both type of requests as is required by a bridge chip 160 that switches between streams that demand strongly ordered completions and streams that accept out-of-order completions. - Other implementations are within the scope of the following claims. For example, the
control logic 130 may be located externally to theinbound logic 120. For example, thecontrol unit 130 can be located within theoutbound logic 110 using appropriate communication with theinbound logic 120. Thecompletion tracker 140 can likewise be located in either the inbound 110 oroutbound logic 120 or neither. - Further, the techniques described here are not limited to any particular hardware or software configuration; they may find applicability in any computing or processing environment. The techniques may be implemented in hardware, software, or a combination of the two. The techniques may be implemented in programs executing on programmable machines such as computers and other devices that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements).
- Whereas some aspects of the invention are implemented as hardware, other aspects can be implemented in a high-level programming language to communicate with a machine system. However, a program can also be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. An exemplary program is used to control the
control unit 130. - A program may be stored on a storage medium or device, e.g., compact disc read only memory (CD-ROM), hard disk, magnetic diskette, or similar medium or device, that is readable by a general or special purpose programmable machine for configuring and operating the machine when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be implemented as a machine-readable storage medium, configured with a program, where the storage medium so configured causes a machine to operate in a specific and predefined manner.
Claims (42)
1. A method comprising:
sending a first request for information to an interface, the first request including an identifier; and
assigning an identifier for a subsequent request dependent on an ordering requirement associated with the first request.
2. The method of claim 1 in which the ordering requirement is based on a configuration parameter associated with the interface.
3. The method of claim 1 in which the subsequent request identifier indicates the ordering requirement for the first request.
4. The method of claim 3 in which the subsequent request identifier indicates that the requested information be received from the interface in a predetermined order.
5. The method of claim 3 in which subsequent request identifier indicates that the requested information may be received in any order for the respective requests.
6. The method of claim 3 in which the subsequent request identifier differs from the identifier for the first request if the ordering requirement allows requested information to be received from the interface out-of-order.
7. The method of claim 3 in which the subsequent request identifier is the same as the identifier for the first request if the ordering requirement requires that requested information be received from the interface in a given order.
8. The method of claim 1 in which the first request includes a request header that comprises the identifier for the first request.
9. The method of claim 1 further comprising storing information that orders the subsequent request with respect to the first request.
10. The method of claim 1 in which the assigning and the sending occur at separate components.
11. The method of claim 10 in which the component that does the sending comprises outbound logic.
12. The method of claim 10 in which the component that does the assigning comprises the control unit.
13. The method of claim 10 in which the component that assigns the identifier also detects receipt of the requested information.
14. The method of claim 10 in which the component that assigns the subsequent request identifier communicates the subsequent request identifier to the component that sends the first request.
15. A method comprising:
sending a first request for information to an interface, the first request including an identifier; and
assigning an identifier for a subsequent request dependent on an ordering requirement associated with the first request, the identifiers for the first and subsequent requests comprises a pipe identifier and a priority value.
16. The method of claim 15 further comprising, if information for the first request is received, decrementing priority values for other requests that have the same pipe identifier as the first request.
17. The method of claim 15 in which the identifiers are stored in a register.
18. A method comprising:
at a first component that stores information about requests for information directed to an interface, receiving an indication that a request for information has been sent by a second component to the interface; and
sending an identifier for a subsequent request to the second component.
19. The method of claim 18 in which the subsequent request identifier indicates an ordering requirement for a previous request.
20. The method of claim 18 in which the first component updates the stored information if requested information for one of the requests is received.
21. The method of claim 20 in which the indication comprises a request header.
22. The method of claim 20 in which the identifier comprises a pipe identifier.
23. The method of claim 22 in which the identifier further comprises a priority value.
24. The method of claim 18 in which the identifier is included in the subsequent request by the second component to the interface.
25. The method of claim 24 in which the interface determines from the identifier if the information requested by the subsequent request requires ordering relative to information requested by other requests.
26. An apparatus comprising:
a first component configured to send requests for information to an interface, the requests including an identifier; and
a second component configured to
store information about the requests,
receive indications of each request from the first component, and
send, to the first component, an identifier for a subsequent request if an indication for a request is received from the first component.
27. The apparatus of claim 26 in which the second component is further configured to receive the requested information from the interface.
28. The apparatus of claim 26 in which the identifier comprises a pipe identifier.
29. The apparatus of claim 28 in which the identifier further comprises a priority value.
30. The apparatus of claim 26 in which the second component is further configured to send the identifier for each request if an indication for the immediately preceding request is received.
31. The apparatus of claim 26 in which the second component is further configured to assign the identifier as a function of an ordering requirement associated with the interface.
32. The apparatus of claim 26 in which the interface is configured to communicate with multiple peripheral devices.
33. An apparatus comprising:
a device that is configured to generate requests for information, each request including an identifier that indicates an ordering requirement for requested information; and
an interface that is configured to receive the requests from the device, send the requested information to the device, and communicate with a peripheral device to obtain the requested information.
34. The apparatus of claim 33 in which the identifier of a respective request indicates the ordering requirement for information requested by an earlier request.
35. The apparatus of claim 33 in which the identifier comprises a pipe identifier.
36. The apparatus of claim 33 in which the device is configured to generate different identifiers for each request if the requests can be received in an order other than the order that the requests are generated, and the interface is configured to send the requested information to the device in an order other than the order that the requests are generated if different identifiers are detected for the requests.
37. A system comprising:
an apparatus configured to generate and track requests for information from a peripheral device and, for a first request, specify, in a subsequent request, if the requested information for the first request is to be returned to the apparatus in a predetermined order or in any arbitrary order; and
an interface configured to relay the requests and the requested information between the apparatus and the peripheral device and return the requested information for the first request in the predetermined order if the subsequent request specifies.
38. The system of claim 37 comprising a plurality of sets of the apparatus and the interface.
39. The system of claim 38 in which each set is configured to return the requested information either in a predetermined order or in any arbitrary order.
40. A machine-accessible medium, having stored thereon one or more sequences of instructions for causing a digital data processing unit to perform operations comprising:
receiving an indication of a request for information sent by a component to an interface;
storing information about the request for information; and
sending an identifier for a subsequent request to the component.
41. The medium of claim 40 in which the sent identifier indicates to the interface the order in which the information for the request and the subsequent request are to be delivered.
42. The medium of claim 40 in which the digital processing unit comprises the control unit.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/757,913 US20040177172A1 (en) | 2001-12-06 | 2004-01-14 | Handling service requests |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/008,595 US6694383B2 (en) | 2001-12-06 | 2001-12-06 | Handling service requests |
US10/757,913 US20040177172A1 (en) | 2001-12-06 | 2004-01-14 | Handling service requests |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/008,595 Continuation US6694383B2 (en) | 2001-12-06 | 2001-12-06 | Handling service requests |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040177172A1 true US20040177172A1 (en) | 2004-09-09 |
Family
ID=21732492
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/008,595 Expired - Lifetime US6694383B2 (en) | 2001-12-06 | 2001-12-06 | Handling service requests |
US10/757,913 Abandoned US20040177172A1 (en) | 2001-12-06 | 2004-01-14 | Handling service requests |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/008,595 Expired - Lifetime US6694383B2 (en) | 2001-12-06 | 2001-12-06 | Handling service requests |
Country Status (1)
Country | Link |
---|---|
US (2) | US6694383B2 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7234017B2 (en) * | 2005-02-24 | 2007-06-19 | International Business Machines Corporation | Computer system architecture for a processor connected to a high speed bus transceiver |
US7330925B2 (en) * | 2005-02-24 | 2008-02-12 | International Business Machines Corporation | Transaction flow control mechanism for a bus bridge |
US7275124B2 (en) | 2005-02-24 | 2007-09-25 | International Business Machines Corporation | Method and system for controlling forwarding or terminating of a request at a bus interface based on buffer availability |
US7275125B2 (en) * | 2005-02-24 | 2007-09-25 | International Business Machines Corporation | Pipeline bit handling circuit and method for a bus bridge |
US7206886B2 (en) * | 2005-02-24 | 2007-04-17 | International Business Machines Corporation | Data ordering translation between linear and interleaved domains at a bus interface |
US20060190655A1 (en) * | 2005-02-24 | 2006-08-24 | International Business Machines Corporation | Apparatus and method for transaction tag mapping between bus domains |
US7194567B2 (en) * | 2005-02-24 | 2007-03-20 | International Business Machines Corporation | Method and system for ordering requests at a bus interface |
US7469312B2 (en) * | 2005-02-24 | 2008-12-23 | International Business Machines Corporation | Computer system bus bridge |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5488706A (en) * | 1992-12-18 | 1996-01-30 | Amdahl Corporation | Retry request system in a pipeline data processing system where each requesting unit preserves the order of requests |
US5923897A (en) * | 1996-04-01 | 1999-07-13 | Microsoft Corporation | System for adapter with status and command registers to provide status information to operating system and processor operative to write eject command to command register |
US6009484A (en) * | 1997-02-28 | 1999-12-28 | Ncr Corporation | Priority-based I/O task processing in computers |
US6021451A (en) * | 1994-05-20 | 2000-02-01 | Intel Corporation | Method and apparatus for maintaining transaction ordering and arbitrating in a bus bridge |
US6061664A (en) * | 1995-10-10 | 2000-05-09 | Koninklijke Ptt Nederland N.V. | System for facilitating the ordering and paying of services by means of a communication network |
US6202112B1 (en) * | 1998-12-03 | 2001-03-13 | Intel Corporation | Arbitration methods to avoid deadlock and livelock when performing transactions across a bridge |
US6389526B1 (en) * | 1999-08-24 | 2002-05-14 | Advanced Micro Devices, Inc. | Circuit and method for selectively stalling interrupt requests initiated by devices coupled to a multiprocessor system |
US20020073258A1 (en) * | 1998-09-03 | 2002-06-13 | Compaq Computer Corporation | High speed peripheral interconnect apparatus, method and system |
US6587894B1 (en) * | 1998-11-16 | 2003-07-01 | Infineon Technologies Ag | Apparatus for detecting data collision on data bus for out-of-order memory accesses with access execution time based in part on characterization data specific to memory |
-
2001
- 2001-12-06 US US10/008,595 patent/US6694383B2/en not_active Expired - Lifetime
-
2004
- 2004-01-14 US US10/757,913 patent/US20040177172A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5488706A (en) * | 1992-12-18 | 1996-01-30 | Amdahl Corporation | Retry request system in a pipeline data processing system where each requesting unit preserves the order of requests |
US6021451A (en) * | 1994-05-20 | 2000-02-01 | Intel Corporation | Method and apparatus for maintaining transaction ordering and arbitrating in a bus bridge |
US6061664A (en) * | 1995-10-10 | 2000-05-09 | Koninklijke Ptt Nederland N.V. | System for facilitating the ordering and paying of services by means of a communication network |
US5923897A (en) * | 1996-04-01 | 1999-07-13 | Microsoft Corporation | System for adapter with status and command registers to provide status information to operating system and processor operative to write eject command to command register |
US6009484A (en) * | 1997-02-28 | 1999-12-28 | Ncr Corporation | Priority-based I/O task processing in computers |
US20020073258A1 (en) * | 1998-09-03 | 2002-06-13 | Compaq Computer Corporation | High speed peripheral interconnect apparatus, method and system |
US6587894B1 (en) * | 1998-11-16 | 2003-07-01 | Infineon Technologies Ag | Apparatus for detecting data collision on data bus for out-of-order memory accesses with access execution time based in part on characterization data specific to memory |
US6202112B1 (en) * | 1998-12-03 | 2001-03-13 | Intel Corporation | Arbitration methods to avoid deadlock and livelock when performing transactions across a bridge |
US6389526B1 (en) * | 1999-08-24 | 2002-05-14 | Advanced Micro Devices, Inc. | Circuit and method for selectively stalling interrupt requests initiated by devices coupled to a multiprocessor system |
Also Published As
Publication number | Publication date |
---|---|
US6694383B2 (en) | 2004-02-17 |
US20030110321A1 (en) | 2003-06-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8225048B2 (en) | Systems and methods for resource access | |
US7181556B2 (en) | Transaction request servicing mechanism | |
JP4083987B2 (en) | Communication system with multi-level connection identification | |
US7822908B2 (en) | Discovery of a bridge device in a SAS communication system | |
JP4466653B2 (en) | Method and apparatus for transmitting data from a plurality of sources via a communication bus | |
CN100481043C (en) | Method, system, and program for handling input/output commands | |
US6678773B2 (en) | Bus protocol independent method and structure for managing transaction priority, ordering and deadlocks in a multi-processing system | |
US5787306A (en) | Automatic assignment of I/O addresses in a computer system | |
US7069373B2 (en) | USB endpoint controller flexible memory management | |
EP1091294B1 (en) | Method and apparatus for assigning resources to logical partition clusters | |
US7716193B2 (en) | Ensuring timely servicing of desired transactions in a database server | |
EP0405859A2 (en) | Data storage device for a digital data processing system | |
US8244950B2 (en) | Buffering non-posted read commands and responses | |
US6973516B1 (en) | Method and apparatus for a controller capable of supporting multiple protocols | |
US6539439B1 (en) | Method and apparatus for interfacing a bus at an independent rate with input/output devices | |
US6694383B2 (en) | Handling service requests | |
US7827343B2 (en) | Method and apparatus for providing accelerator support in a bus protocol | |
CN102918515A (en) | Storing data in any of a plurality of buffers in a memory controller | |
NL8702394A (en) | INTERFACE FOR A CONNECTION NETWORK BETWEEN SEPARATE STATIONS ON THE ONE PART AND A PHYSICAL MEDIUM USED FOR MESSAGE TRANSMISSION BETWEEN THESE STATIONS. | |
US5204954A (en) | Remote storage management mechanism and method | |
US7107367B1 (en) | Method for efficient buffer tag allocation | |
US20060085573A1 (en) | Multi-context selection with PCI express to support hardware partitioning | |
US9170962B2 (en) | Dynamic designation of retirement order in out-of-order store queue | |
US6701391B1 (en) | System for stop buffering when a count of stored data blocks from a DVD matches an associated data block number of a requested data block set | |
CN111367694B (en) | Event processing method, server and computer storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |