Patent Application
20130054864
Not applicable.
The disclosed subject matter relates generally to computer systems and, more particularly, to buffer management using freelist buffers.
In computer systems, devices communicate with one another over buses. The communication efficiency over the bus directly ties into the overall performance of the system. One bus technology used for high speed communication between devices is commonly referred to as HyperTransport (HT). In general, an HT bus is a bidirectional, serial/parallel, high-bandwidth, low-latency, point-to-point link.
In typical HT bus implementations a plurality of virtual channels are defined for communication between devices. Exemplary devices include microprocessors, graphics processors, I/O devices, bridge devices, external caches, network interfaces, cryptoprocessors, etc. Each device maintains a plurality of buffers for communicating across the channel. These buffers are hard-allocated for particular virtual channels. Exemplary channels include a request channel, a response channel, a posted request channel, a probe virtual channel, etc. Multiple virtual channels are provided to avoid deadlocks in the network. For example, without separate virtual channels, the buffers could be allocated to a plurality of request transactions, leaving no buffers available for responses.
For each channel, a number of buffers are hard-allocated for receiving packets of the particular type. The device transmitting the particular packet maintains a count of buffers available for each virtual channel. When a particular packet is sent over the channel, the available buffer count for that channel is decremented by the transmitting device. The receiving device decodes an incoming packet to identify the appropriate virtual channel, and stores the incoming packet in a buffer allocated for the appropriate virtual channel. As the receiving device completes particular requests, thereby freeing up previously used buffers, it sends to the transmitting device a buffer release packet indicating the number of buffers for the various virtual channels that have been released. By maintaining buffer counts for each virtual channel and tracking buffers as they are released, the relative bandwidths of the virtual channels can be controlled.
The performance of the HT bus is affected by the total number of buffers available for communication over the HT bus and the relative buffer counts hard-allocated to each virtual channel. In general, increasing the performance of the HT bus involves allocating more buffers to the various virtual channels. Increasing buffer counts increases the cost of the devices by consuming additional silicon real estate. The number of buffers hard-allocated to each virtual channel is also a performance compromise. The devices communicating over the bus will experience different workloads at different times depending on the particular tasks being performed. The general hard allocation scheme represents an average expected balance between the channels. If a particular task requires different relative uses the virtual channels, the performance of the HT bus may be negatively affected by less efficient usage. There may be a shortage of buffers for one virtual channel, while a different virtual channel experiences a surplus.
This section of this document is intended to introduce various aspects of art that may be related to various aspects of the disclosed subject matter described and/or claimed below. This section provides background information to facilitate a better understanding of the various aspects of the disclosed subject matter. It should be understood that the statements in this section of this document are to be read in this light, and not as admissions of prior art. The disclosed subject matter is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.
The following presents a simplified summary of the disclosed subject matter in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an exhaustive overview of the disclosed subject matter. It is not intended to identify key or critical elements of the disclosed subject matter or to delineate the scope of the disclosed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later.
One aspect of the disclosed subject matter is seen in a device including a link interface circuit, a first plurality of allocated buffers, and a second plurality of non-allocated buffers. The link interface circuit is operable to communicate over a communications link using a plurality of virtual channels. A different subset of the plurality of allocated buffers is allocated to each of the virtual channels. The non-allocated buffers are not allocated to a particular virtual channel. The link interface circuit is operable to receive a first transaction over the communications link and assign the first transaction to one of the allocated buffers or one of the non-allocated buffers.
Another aspect of the disclosed subject matter is seen a method for communicating over a communications link using a plurality of virtual channels. The method includes allocating a first plurality of allocated buffers to the virtual channels. A different subset of the plurality of allocated buffers is allocated to each of the virtual channels. A second plurality of non-allocated buffers is designated. The non-allocated buffers are not allocated to a particular virtual channel. A first transaction is received over the communications link. The first transaction is assigned to one of the allocated buffers or one of the non-allocated buffers.
The disclosed subject matter will hereafter be described with reference to the accompanying drawings, wherein like reference numerals denote like elements, and:
While the disclosed subject matter is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the disclosed subject matter to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosed subject matter as defined by the appended claims.
One or more specific embodiments of the disclosed subject matter will be described below. It is specifically intended that the disclosed subject matter not be limited to the embodiments and illustrations contained herein, but include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. Nothing in this application is considered critical or essential to the disclosed subject matter unless explicitly indicated as being “critical” or “essential.”
The disclosed subject matter will now be described with reference to the attached figures. Various structures, systems and devices are schematically depicted in the drawings for purposes of explanation only and so as to not obscure the disclosed subject matter with details that are well known to those skilled in the art. Nevertheless, the attached drawings are included to describe and explain illustrative examples of the disclosed subject matter. The words and phrases used herein should be understood and interpreted to have a meaning consistent with the understanding of those words and phrases by those skilled in the relevant art. No special definition of a term or phrase, i.e., a definition that is different from the ordinary and customary meaning as understood by those skilled in the art, is intended to be implied by consistent usage of the term or phrase herein. To the extent that a term or phrase is intended to have a special meaning, i.e., a meaning other than that understood by skilled artisans, such a special definition will be expressly set forth in the specification in a definitional manner that directly and unequivocally provides the special definition for the term or phrase.
Referring now to the drawings wherein like reference numbers correspond to similar components throughout the several views and, specifically, referring to
In the illustrated embodiment, the southbridge node 120 performs various functions in the system 100, including, but not limited to, PCI bus support, ISA bus support, LPC bridge support (for Super I/O connections to keyboard, mouse, parallel port, serial port, IR port, floppy controller, etc.) BIOS flash storage, system management bus support, DMA controller support to allow ISA or LPC devices direct access to main memory without needing help from the CPU, interrupt control support, mass storage controller support to allow direct attachment of system hard drives, real-time clock support, power management, nonvolatile BIOS memory support, audio sound interface support, out-of-band management controller support, Ethernet support, RAID support, USB support, audio codec support, and/or FireWire support.
In general, the link between the general nodes 100 may be a coherent HT link 140, while the link 150 between the southbridge node 120 and one of the general nodes 110A, 110B may be non-coherent HT. In general, coherent HT links 140 provide interfaces between the processors' coherent domains, while non-coherent HT links 150 are used for attaching I/O devices, such as the I/O devices 130 attached through the southbridge node 120.
For purposes of the following illustrations, the application of the present subject matter is described in the context of the coherent HT link 140. However, the concepts may also be applied to the non-coherent HT link 150, or even a communication link between devices using a completely different protocol.
Turning now to
Turning now to
There are various ways in which the hard-allocated buffers 210 and the freelist buffers 220 may be managed. In one embodiment, freelist headers 320 may be provided for every transaction 300. The HTIC 205 of the receiving device decodes the HT packet to determine the type of transaction, and uses the freelist header 320 to determine if a hard-allocated buffer 210 or a freelist buffer 220 should be used. The HTIC 205 of the transmitting device decrements the buffer counter 230 for the hard-allocated buffer 210 or the freelist buffer 220 used. Upon retiring the transaction, the receiving device sends a release packet to the transmitting device, and the transmitting device increments the associated counter 230 to restore the available buffers 210, 220.
In another embodiment, the freelist header 320 is not used on certain transactions 310. The freelist header 320 is only used to communicate that a buffer routing that differs from a default buffer routing is being used. In one embodiment, the majority of buffers 200 may be freelist buffers 220, and all virtual channels may be configured to default to the freelist buffers 220. This configuration reduces the latency affect by reducing the throughput for the default transactions 310. Only those transactions 300 targeting a hard-allocated buffer 210 would require a freelist header 320.
In another embodiment, a different default buffer routing may be determined for each virtual channel. For example, requests can be configured to default to a hard-allocated buffer 210 for the request virtual channel, while responses can be configured to default to the freelist buffers 220. Default transactions 310 for requests and responses can then be communicated without a freelist header 320, thereby increasing throughput. In such a configuration, freelist headers 320 would only be necessary if the request were to be processed using a freelist buffer 220 or a response were to be processed using a hard-allocated buffer 210 for the response virtual channel.
An exemplary transaction flow for this configuration is described in reference to
In one embodiment, the default configurations of the virtual channels may be fixed at the time the system 100 is initialized. In another embodiment, a particular node 110A, 110B may dynamically change its default buffer configuration. For example, if the type of task being processed by the node 110A, 110B changes, and it expected that the duration of the new environment would be sufficient to warrant a change, the node 110A, 110B may place the HT link 140 in a quiescent state and wait for all transactions to be completed and the associated buffers 200 released. The node 110A, 110B may then communicate its new default configurations to the opposing node, and communication may resume on the HT link 140 with the new default configurations in effect. The efficiency gained from changing the default configurations depends on factors such as the expected duration of new processing environment and the cost associated with placing the HT link 140 into a quiescent state.
It is contemplated that, in some embodiments, different kinds of hardware descriptive languages (HDL) may be used in the process of designing and manufacturing very large scale integration circuits (VLSI circuits), such as semiconductor products and devices and/or other types semiconductor devices. Some examples of HDL are VHDL and Verilog/Verilog-XL, but other HDL formats not listed may be used. In one embodiment, the HDL code (e.g., register transfer level (RTL) code/data) may be used to generate GDS data, GDSII data and the like. GDSII data, for example, is a descriptive file format and may be used in different embodiments to represent a three-dimensional model of a semiconductor product or device. Such models may be used by semiconductor manufacturing facilities to create semiconductor products and/or devices. The GDSII data may be stored as a database or other program storage structure. This data may also be stored on a computer readable storage device (e.g., storage 510, disks 520, 525, solid state storage, and the like). In one embodiment, the GDSII data (or other similar data) may be adapted to configure a manufacturing facility (e.g., through the use of mask works) to create devices capable of embodying various aspects of the instant invention. In other words, in various embodiments, this GDSII data (or other similar data) may be programmed into the computing apparatus 500, and executed by the processor 505 using the application 565, which may then control, in whole or part, the operation of a semiconductor manufacturing facility (or fab) to create semiconductor products and devices. For example, in one embodiment, silicon wafers containing a node 110A, 110B of
The particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.
