Abstract:
In general, in one aspect, a method includes determining a repeated, periodic DMA (Direct Memory Access) coalescing interval based, at least in part, on a power sleep state of a host platform. The method also includes buffering data received at the device in a FIFO (First-In-First-Out) queue during the interval and DMA-ing the data enqueued in the FIFO to a memory external to the device after expiration of the repeated, periodic DMA coalescing interval.

Description:
REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation in part and claims priority to U.S. Ser. No. 12/208,654, filed Sep. 11, 2008, entitled “Buffering Techniques for Power Management”. 
     
    
     BACKGROUND 
       [0002]    Networks enable computers and other devices to communicate. For example, networks can carry data representing video, audio, e-mail, and so forth. Typically, data sent across a network is divided into smaller messages known as packets. By analogy, a packet is much like an envelope you drop in a mailbox. A packet typically includes “payload” and a “header”. The packet&#39;s “payload” is analogous to the letter inside the envelope. The packet&#39;s “header” is much like the information written on the envelope itself. The header can include information to help network devices handle the packet appropriately. For example, the header can include an address that identifies the packet&#39;s destination. 
         [0003]    Systems receiving packets typically include devices known as Network Interface Controllers (NICs) (a.k.a. Network Adaptors). Traditionally, upon receipt of a packet, a NIC will perform a Direct Memory Access (DMA) of packet data to host memory. This Direct Memory Access frees the host processor from the duty of overseeing transfer of data between memory and the NIC. Once in host memory, the NIC can generate an interrupt to alert a host processor to the arrival of the packet. In response, a protocol stack executed by the host processor typically processes the packet in accordance with different layers of network communication protocols. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  is a diagram of a system including a network interface controller (NIC). 
           [0005]      FIG. 2  is a diagram illustrating Direct Memory Access (DMA) coalescing. 
           [0006]      FIG. 3  is a diagram of a network interface controller implementation of DMA coalescing. 
           [0007]      FIG. 4  is a diagram illustrating DMA coalescing logic. 
           [0008]      FIG. 5  is a diagram illustrating enablement and disablement of DMA coalescing. 
           [0009]      FIG. 6  is a diagram illustrating adaptive determination of a DMA coalescing timer. 
           [0010]      FIG. 7  is a diagram illustrating coordination of DMA coalescing with interrupt moderation. 
           [0011]      FIG. 8  is a diagram illustrating multiple devices implementing DMA coalescing. 
           [0012]      FIG. 9  is a diagram illustrating coordination of multiple devices implementing DMA coalescing. 
           [0013]      FIG. 10  is a diagram illustrating a coordinator of multiple devices implementing DMA coalescing. 
           [0014]      FIGS. 11A and 11B  are diagrams illustrating coordination of multiple devices implementing DMA coalescing. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]      FIG. 1  depicts a host system  100  featuring processor(s)  102  and host memory  104 . Host system  100  processor  102  may execute applications that communicate over a network via a coupled network interface controller (NIC)  106 . The NIC  106  handles receipt and transmission of packets over a network connection (e.g., a wired or wireless physical medium). The NIC  106  may be a discrete component (e.g., a card) or integrated on a motherboard and/or processor die. 
         [0016]    To process received packets, NIC  106  transfers packets to host memory  104  for subsequent processing by the host (e.g., by a network protocol stack and/or application software). To reduce the burden of network communication on processor(s)  102 , NIC  106  features a Direct Memory Access (DMA) engine that moves packet data from the NIC  106  to host memory  104 . While DMA reduces the burden of packet processing on a processor  102 , the frequency and unpredictability of DMA activity can prevent the long periods of inactivity needed for the host system  100  to enter low power states. 
         [0017]    As an example, host  100  may feature the ability to enter power saving states, often referred to as sleep modes (e.g., Cn in ACPI (Advanced Configuration and Power Interface) where increasing values of n correspond to deeper power saving modes). Such sleep states can reduce power consumed by varying platform components by varying degrees. A longer sleep duration can permit a system to enter a deeper power saving mode. However, repeated DMA operations can prevent the host  100  from extended idle periods, preventing deeper power saving states. For example, network traffic tends to have short gaps between packets, even for lightly loaded traffic, creating short, choppy periods of inactivity whose modest duration prevents the host  100  from having a long enough idle duration to enter lower power states. 
         [0018]    As shown in  FIG. 2 , the system can coalesce DMA operations to increase periods of time without NIC initiated DMA activity. For example, instead of initiating a DMA transfer after receipt of each packet, a NIC  106  can buffer received packets and initiate DMA transfer of multiple queued packets in succession. This concentrates NIC initiated DMA operations into a smaller period of time which can, in turn, increase the possibility of host  100  entering a deeper power saving mode. 
         [0019]    To illustrate,  FIG. 2  depicts traditional DMA transfer  200  of packets as they arrive. This distribution of DMA operations over time creates, by happenstance, a short, difficult to predict, periods of time (e.g.,  202 ) where DMA activity temporarily ceases. By comparison,  FIG. 2  also depicts a sample illustration of DMA coalescing  204  where NIC  106  buffers received packets during a DMA coalescing duration  208   a.  After this duration  208   a,  the NIC  106  initiates  208   b  DMA transfer of the buffered packets. As shown, this can reliably generate larger, more regular periods  208   a  without DMA activity initiated by the NIC  106 . As shown, DMA coalescing  204  can let the platform enter a deeper idle state (e.g., ACPI C6 state) and stay there longer, increasing power savings. As shown in  FIG. 2 , the scheme can create a repeating cycle having a first phase where DMA coalescing queues received packets  208   a  and a second phase where DMA coalescing is stopped and the packets are DMA-ed  208   b  to the host. 
         [0020]      FIG. 3  depicts a sample architecture of a NIC  300  implementing DMA coalescing in greater detail. As shown, the NIC  300  features PHY(s)  310  and MAC(s)  308  (media access controllers) which handle physical layer and link layer operations, respectively. The NIC  300  also includes DMA engine(s)  302 . Received (Rx) packets are queued in ingress Rx FIFO  312 . Likewise, packets to transmit (Tx) are enqueued in egress Tx FIFO  314 . Again, instead of initiating a DMA for received (Rx) packets as soon as the packet reaches the top of Rx FIFO  312 , Rx packets can be buffered in Rx FIFO  312  during a DMA coalescing period. After the coalescing period elapses, DMA engine(s)  302  can dequeue the buffered packets from RxFIFO  312  and initiate DMA transfers. 
         [0021]    Typically, a NIC  300  performs DMA transfers through the use of descriptors that identify candidate buffers in host memory  104  to store packets. A descriptor may identify, for example, a location within a buffer within host memory  104  and a length of buffer available to store a packet. Generally, a host  100  transfers descriptors for available buffers to NIC  300  by a host DMA engine (not shown). The NIC  300  then uses these descriptors to instruct the DMA engine  302  where to transfer packet data in host memory  104 . The NIC  300  also generates a return descriptor which identifies the location of the packet and may identify features of the packet such as packet length, hash values, packet types, checksum pass/fail and so forth. The host  100 , in turn, uses the return descriptor to determine the location of a packet in host memory. Thus, in addition to the DMA of a packet to host memory, DMA of descriptors and return descriptors between the host and NIC may also be confined to the period of DMA operation. 
         [0022]    As shown in  FIG. 3 , DMA coalescing is controlled by DMA coalescing logic  304  of NIC  300 .  FIG. 4  illustrates a sample implementation of DMA coalescing logic. The sample implementation repeatedly disables  402  and enables  416  NIC DMA operations. In typical operation, a DMA coalescing timer  406  controls DMA operations. That is, packets are enqueued until expiration of the timer. This ensures packets do not remain queued indefinitely. 
         [0023]    Potentially, a DMA coalescing period may be terminated before expiration of the timer. For example, to ensure Rx FIFO  312  has sufficient space to buffer received packets while the host platform transitions from a lower power idle state to an active state, RxFIFO watermark  404  logic may cause a DMA flush of queued data before expiration of a DMA coalescing timer period. For instance, to make sure packets will not be dropped due to the lack of available Rx FIFO  312  space, space watermark logic  404  may initiate a DMA flush of queue packets if the remaining Rx FIFO space falls below (T exit *W) where T exit  is the exit latency duration of the low power idle state and W is the link speed carrying the data being queued. After the flushing, DMA coalescing is restarted. 
         [0024]    The timer  404  value can be set statically or dynamically. A fixed timer  408  value may be set by a user or automatically determined by a NIC, device driver, or other entity. Generally, greater DMA coalescing periods can result in larger idle periods. However, extended coalescing periods can increase packet processing latency as packets await DMA transfer. Thus, selecting a fixed timer  408  value may reflect different packet processing objectives. 
         [0025]    For example, the timer  404  value can be set to attempt to keep the platform at the lowest power idle state long enough to gain the most power benefit. Lower power states typically have longer entry and exit latencies (e.g., longer transition durations to power components up or down). Additionally, different power state transitions may also consume different amounts of power. Based on these factors, there exists a break-even idle time for each idle state where the benefit to entering the state is greater than the power consumed by state transitions. In other words, to gain power benefit for entering the lowest power idle state, the platform needs to stay idle for longer than a break-even time, denoted by T be . T be  is platform-specific and varies for each power state. In a typical Operating System (OS) policy, a platform can enter the lowest power idle state only when the CPU utilization is less than or equal to certain threshold, denoted by F util  %. For example, in the current Windows Vista™ policy, F util  %=40 %. In such environments, the coalescing timer may need to generate at least T be  idle time at F util  % CPU utilization level to reduce overall power consumption. A minimum coalescing time period can be calculated as: 
         [0000]        Tc _min= T   be /(1 −F   util  %) 
         [0000]    Thus, when CPU utilization&lt;F util  %, Tc_min will generate idle time longer than T be . Again, when the CPU utilization&gt;F util  %, due to OS policy, a platform may not enter the lowest power idle state.
 
Using a longer coalescing timeout than Tc_min can potentially provide better power savings, however, this may come at the expense of increased latency for received packets. Thus, a metric may be used to limit the coalescing timeout value. For example, a minimum throughput constraint may be used. For instance, assume each user connecting to a server generally achieves Internet throughput at W user  bps (e.g., 800 Kbps) and the server generally uses L TCP  bits (e.g., 64 KBytes) as the TCP window size. The equivalent round-trip time for the user is L TCP /W user . Further, assume a maximal tolerable user throughput drop after coalescing, F drop  % (e.g., 1 %), of the original throughput. The maximal coalescing time, Tc_max, can be determined as follows:
 
         [0000]      { W   user   −L   TCP /( L   TCP   /W   user   +Tc _max)}/ W   user   =F   drop  % 
         [0000]    A system can automatically select a coalescing timeout value between (or equal to one of) Tc_min and Tc_max. Alternately, this value may be selected based on a user&#39;s preference. The approach described above is merely an example. Additionally, while the above described a throughput metric a wide variety of other constraining metrics may be used to limit the potential values of the coalescing timer  404 . 
         [0026]    Instead of a static coalescing timer value, DMA coalescing may dynamically respond to system conditions such as resource usage and/or network traffic volume. For example, as shown in  FIG. 5 , DMA coalescing may be dynamically enabled  504  or disabled  502  based on the volume of network traffic. For instance, if network traffic is very low, DMA coalescing will not significantly reduce the frequency of active DMA transfer periods. Alternately, if network traffic is too high, the opportunities to idle will be fewer, reducing the value of DMA coalescing with respect to the performance impact/latency caused by its operation. Thus, as shown in  FIG. 5 , a policy may disable  502  DMA coalescing if network traffic falls outside a range of beneficial DMA coalescing operation. DMA coalescing may resume  504  when network traffic again falls within the desired range. The range test may be over a configurable period of time. Additionally, the range test may need to be met for some number of consecutive (e.g., 3 consecutive 1 second periods) and/or non-consecutive periods (e.g., at least 4 out of 5) before enabling  504 /disabling  502 . The volume of traffic may be measured, for example, by a count of Rx and/or Tx packets over a period of time. 
         [0000]    The DMA coalescing period can be also be dynamically adjusted by adaptive timer  410 . For example, as shown in  FIG. 6 , the adaptive timer  410  may repeatedly attempt to increase  606  the DMA coalescing interval until  604  an increase significantly degrades platform throughput or fails to significantly increase overall performance. For instance, in the sample shown, the DMA coalescing value is initialized (e.g., to tc_min). Thereafter, a rate check  604  is performed that compares the Tx packet count (Tx current−timer−value ) for some duration (e.g., 1 second) under the current DMA coalescing duration against a Tx packet count (Tx higher−timer−value ) for the same duration under a higher DMA coalescing duration. If increasing the coalescing duration would degrade performance beyond some threshold, the adaptive timer  410  may leave  608  the coalescing duration at its current value. For example, if 
         [0000]      ( Tx   higher−timer−value   /Tx   current−timer−value )&lt; F   drop  % 
         [0000]    then the rate check  604  may fail  608 . The adaptive timer  410  may require the rate check  604  to fail multiple times (e.g., 3) before abandoning  608  the attempt to increase the coalescing duration. The adaptive timer  410  may repeat the process above periodically. That is, the coalescing duration may be reset and attempts to increase it repeated after some period of time. Potentially, the reset value for the coalescing timer may change over time, for example, based on performance (e.g., an average of the previous initial value and the current value). 
         [0027]    The process shown in  FIG. 6  may operate on a pre-established stepping-stone set of coalescing durations spanning tc_min and Tc_max. Alternately, the next coalescing duration to try may also be dynamically determined. 
         [0028]      FIG. 6  is merely an illustration of a sample process for dynamically altering the coalescing duration. A wide variety of other ways of dynamically determining the coalescing duration may be used. For example, an Rx packet count may be used instead of or in addition to a Tx packet count. Additionally or alternately, other techniques for adapting the coalescing duration may be based on measurements of different metrics that yield a coalescing duration value. 
         [0029]    Other logic blocks may also affect DMA coalescing. For example, a DMA coalescing period may be aborted based on packets that are very delay sensitive  414 . For example, the delay sensitive trigger  414  may receive identification of packets matching packet filter rules. The filter(s) may examine packet contents such a header fields (e.g., source IP address, IP port, destination IP address, IP port, protocol type, control bits, size, Ethernet type, TCP (Transmission Control Protocol) flags, VLAN (Virtual Local Area Network) priority, and so forth) to identify packets having predefined characteristics. After the packet filter(s) detect a packet match, coalescing can be stopped and restarted after a DMA transfer of queued data. Again, this can reduce the impact of DMA coalescing on time sensitive communication. For example, packets having a high QoS (Quality of Service), connection management packets, and/or TCP segments flagged as URGent can be sent to the a host protocol stack without delay of DMA coalescing. 
         [0030]    The coalescing logic can also respond to other conditions. For example, logic  412  can monitor the amount of data (e.g., packets) DMA-ed over time. For example, if, over several consecutive DMA coalescing periods, only a single packet is DMA-ed in each period, DMA coalescing can be disabled for some duration. This and the detection of other special conditions can be performed by logic  412 . 
         [0031]    Coalescing described above can potentially create larger periods of time at a platform where DMA activity is absent. However, DMA activity is not the sole source of interruptions to idle periods on a platform. For example, in some implementations, a NIC may generate a processor interrupt after DMA transfer for every packet received. In response to the interrupt, a host processor can initiate packet processing for the received packet. Frequent interrupts, however, impose substantial processing overhead, for example, as processing contexts are swapped out to handle packet processing operations. To reduce this overhead, many devices implement a technique known as interrupt moderation. That is, instead of signaling a processor interrupt for each packet received and placed in host memory, interrupt moderation can enable a queue of packets to build and signal a single interrupt for multiple packets. This reduction in the number of interrupts alleviates some of the burden of processing packets on a host. 
         [0032]    Typically, interrupt moderation schemes operate at a given moderation interval. For example,  FIG. 7  depicts a typical interrupt moderation scheme  700  implemented by a system that does not use DMA coalescing. As shown, a NIC can generate interrupts  702   a,    702   b,    702   c  at repeated intervals (e.g., 50 micro-seconds). 
         [0033]    As illustrated in  FIG. 7 , implementing DMA coalescing on a NIC that also implements interrupt moderation  710  can further reduce the number of interrupts. For example, as shown, after a DMA coalescing period and an initial DMA transaction, the NIC generates an interrupt  712   a  to initiate receive processing of packets identified in the NIC receive queue(s). In accordance with a traditional interrupt moderation scheme, a second interrupt  712   b  is generated after the interrupt moderation interval to initiate receive processing of additional packets DMA-ed during the interval between interrupts  712   a  and  712   b.  Finally, a third interrupt  712   c  is generated after the interrupt moderation interval to process packets DMA-ed between intervals  712   b  and  712   c  In the absence of DMA transactions during the DMA coalescing period, no interrupt is generated until the next period of active DMA transfers. 
         [0034]    Comparing  700  and  710  illustrates how DMA coalescing can reduce processor interrupts and create a significant idle period  714 . However, as shown, an interrupt  712   c  occurs during an otherwise “quiet” DMA coalescing period causing the overall platform idle duration to shorten to  714  instead of an amount of time closer to the coalescing duration  716 . Additionally, packet processing operations may further incur into time period  714 . In other words, because the interrupts are not aligned with the period of DMA transfers, a portion of potential idle duration may be lost. However, better coordination of interrupt signaling with DMA coalescing can free much of the DMA coalescing period  716  from interrupt activity, increasing the platform idle duration for longer and deeper platform idle state residency. 
         [0035]    As shown in  FIG. 7 , aligning  720  interrupt signaling with DMA coalescing can potentially increase the platform idle duration  724  and reduce the number of interrupts generated and their associated processor overhead. In the example shown, after a DMA coalescing period and a first DMA transaction is issued, a first interrupt  722   a  is signaled. In response, the host protocol stack begins processing of the coalesced packets. Thereafter, another interrupt  722   b  may be generated aligned with the end of the active period of DMA transfers, as opposed to at a later time (e.g., interrupt  712   c ). Again, comparing  720  with  710 B illustrates an increase in the potential platform idle duration (e.g., from  714  to  724 ) and a reduction in interrupts (e.g., from three to one or two). 
         [0036]    Again, many variations and alternate implementations are possible. For example, while many NICs feature a single Rx FIFO, some NICs may feature multiple Rx FIFOs such as NICs implementing Receive Side Scaling (RSS). In such implementations, an interrupt may be signaled for each Rx FIFO or each Rx FIFO having data. After a new DMA coalescing period begins, an additional interrupt for each Rx FIFO can be issued that still has unprocessed packets. 
         [0037]    As described above, DMA coalescing can concentrate DMA activity initiated by a device into a more compact period of time. However, potentially, multiple devices on the same host platform may perform DMA coalescing. For example, the host platform  100  in  FIG. 1  may feature multiple NICs and/or other I/O devices.  FIG. 8  illustrates sample operation of multiple devices  800 ,  810  performing DMA coalescing without coordination. As shown in this example, DMA transfers  802   b  of one device  800  occur during the DMA coalescing period of another  810 , and vice versa. As shown, these interfering DMA coalescing schedules can chop platform idle durations into periods  822  potentially shorter than any given device&#39;s DMA coalescing duration, reducing potential power savings achieved by DMA coalescing. 
         [0038]    As shown in  FIG. 9 , however, coordinating DMA coalescing across devices can create longer idle durations. For example, as shown, this coordination can synchronize the DMA coalescing of devices  900 ,  910  to consolidate the periods of active DMA transfers of these devices into a shorter, overlapping duration. As shown, the net result  920  leaves a longer platform idle duration  922   a  than achieved  822  in  FIG. 8 . 
         [0039]    Alignment of DMA activity can be implemented in a wide variety of ways. For example,  FIG. 10  illustrates a coordinator  952  that controls the DMA activity of different devices  954   a - 954   n.  In a sample implementation shown in  FIG. 11A and 11B , each device  954   a - 954   n  can maintain its own DMA coalescing policy and schedule, however, DMA activity by any of one device can trigger a DMA flush and reset of the DMA coalescing duration for other devices. For instance, as shown in  FIG. 11A , the coordinator  952  receives notification from device  954   a  after the device&#39;s DMA coalescing duration ends (e.g., after the first DMA transfer by the device  954   a ). As shown in  FIG. 11B , in response, the coordinator  952  can notify other devices (e.g., device  954   b - 954   n ) which, in turn, can end their DMA coalescing periods and flush any coalesced DMA activity to the host. Thereafter, the devices  954   a - 954   n  can resume their own DMA coalescing schemes. 
         [0040]    In the implementation shown, the devices&#39; maintain their own DMA coalescing policies but respond to the coordinator&#39;s  952  signal by stopping the current coalescing duration and starting a new one. Other implementations, however, may operate differently. For example, the coordinator can signal each device  954   a - 954   n  to start and/or end a DMA coalescing period, for example, after a predefined period of time (e.g., every 10 ms) much like a heartbeat signal. Alternately, the coordinator  952  can instead determine and provide a DMA schedule for one or more devices  954   a - 954   n  to follow. Such a schedule may be determined based on priority of I/O handled by the device, throughput, latency tolerance, device FIFO capacity, and other factors. Potentially, the resulting schedule may be uniform for each device, though they may differ. The schedules and/or heartbeats derived by the coordinater  952  may dynamically adapt to the DMA idle performance achieved by the platform and/or based on varying DMA activity volume of the devices. 
         [0041]    The coordinator  952  may be implemented in a variety of hardware and/or software. For example, the coordinator  952  may be implemented as a software device driver. For instance, in Linux, a single NIC driver instance controls multiple Ethernet NICs and can be modified to implement coordinator  952  operations. For example, a received interrupt from one NIC can trigger a DMA alignment message to the other NICs. A software approach, such as that described above, would not require hardware changes to the devices or standardization. Alternately, the coordinator  952  may be implemented as an application and/or as a part of an operating system. Further, the coordinator  952  can be implemented as dedicated or programmable hardware, for example, in a chipset or I/O hub coupling the devices to the platform. Communication between the coordinator  952  and the devices  954   a - 954   n  can occur, for example, via configuration registers exposed by the devices  954   a - 954   n  and/or or via a software API (Application Programming Interface) such as a network driver interface specification. 
         [0042]    While the above frequently described DMA coalescing performed by a NIC, DMA coalescing can be applied to other hardware subsystems/devices. Examples of such hardware subsystems include disk drive controllers, graphics cards, sound cards, and so forth. Additionally, while the above described DMA transfer of packets such packets may not be transferred as a monolithic structure. For example, packet headers and payloads may be split and transferred into non-contiguous locations in host memory. 
         [0043]    The term circuitry as used herein includes hardwired circuitry, digital circuitry, analog circuitry, programmable circuitry, and so forth. The programmable circuitry may operate on computer programs disposed on a computer readable storage medium that implement techniques described above. The term packet as used herein encompasses frames (e.g., Ethernet frames), segments (e.g., TCP segments), Internet Protocol datagrams (e.g., IPv4 and IPv6) and other protocol data units (PDUs) used in networks. 
         [0044]    Other embodiments are within the scope of the following claims.