IN AT LEAST ONE DESCRIPTOR

Field

This disclosure relates to generating and/or using, at least in part, at least one descriptor. Background

In one conventional network arrangement, a communication stream is transmitted from a first host to a second host. The stream includes a plurality of packets. Software processes in the first host select the average timing of transmission or maximum latency of the packets so as to maintain a predictable data transmission rate for the packets. The second host includes a buffer to store the packets received from the first host.

In this conventional arrangement, the actual timing of transmission of any given individual packet in the steam may vary, so long as the overall average timing of the

transmission or maximum latency of the packets in the stream (i.e., taking into account all of the packets in the stream) conform to what has been selected for these parameters by the software processes in the first host. In order to prevent buffer overflow in the second host, the size of the buffer in the second host is selected so as to conform to the maximum buffering requirements that may be expected to prevail in a worse case communication scenario involving the stream (i.e., in a worst case communicate scenario given the average packet transmission timing or maximum packet latency selected by the software processes). This may result in more buffer memory being allocated for packet storage than is desirable. This may make buffer memory usage and/or allocation less efficient.

Brief Description of the Several Views of the Drawings

Features and advantages of embodiments will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and in which:

Figure 1 illustrates a system embodiment.

Figure 2 illustrates features in an embodiment.

Figure 3 illustrates features in an embodiment.

Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art. Accordingly, it is intended that the claimed subject matter be viewed broadly.

Detailed Description

Figure 1 illustrates a system embodiment 100. System 100 may include one or more host 10 that may be communicatively coupled to one or more intermediate stations 25 via one or more wireless and/or wired network communication links 50. One or more intermediate stations 25 may be communicatively coupled to one or more other hosts 20 via one or more wireless and/or wired network communication links 51. In this embodiment, one or more hosts 10 may be or comprise one or more senders of one or more packet streams (PS) 52, and one or more intermediate stations 25 and/or one or more hosts 20 may be or comprise one or more intended receivers of one or more of these streams. For example, in this embodiment, one or more hosts 10 may be or comprise one or more "talkers," and one or more hosts 20 may be or comprise one or more media renderer "listeners," in accordance with, for example, Amendment 12:

Forwarding and Queuing Enhancements for Time-Sensitive Streams, Institute of Electrical and Electronics Engineers, Inc. (IEEE) Std. 802.1Qav-2009, approved 9 December 2009 (hereinafter, "Time-Sensitive Steam Protocol" or "TSSP"). One or more intermediate stations 25 may be or comprise one or more not shown bridges and/or switches that together with one or more hosts 20 may be comprised in, for example, one or more not shown bridged local area networks.

In this embodiment, one or more hosts 10, intermediate stations 25, and/or hosts 20 may be geographically remote from each other. In an embodiment, the terms "host computer,"

"host," "server," "client," "network node," "end station," "intermediate station," and "node" may be used interchangeably, and may mean, for example, without limitation, one or more end stations, mobile internet devices, smart phones, media (e.g., audio and/or video) devices, input/output (I/O) devices, tablet computers, appliances, intermediate stations, network interfaces, clients, servers, and/or portions thereof. Also in this embodiment, a "sender" or "talker" may be capable, at least in part, of transmitting, at least in part, one or more packets to one or more "receivers" or "listeners," and a "receiver" or "listener" may be capable, at least in part, of receiving, at least in part, the one or more packets. In this embodiment, a "bridge" and "switch" may be used interchangeably, and may comprise an intermediate station that is capable, at least in part, of receiving, at least in part, one or more packets from one or more talkers, and transmitting, at least in part, the one or more packets to one or more listeners. In this embodiment, a "media renderer" may comprise one or more hosts capable, at least in part, of (1) processing, at least in part, data that may be associated, at least in part, with, (2) encoding, at least in part, audio, video, graphic, display, tactile, image, and/or other and/or additional types of information, and/or (3) decoding, at least in part, such information, where such information may be intended to be, amenable to, and/or capable of, at least in part, human sensory perception, audio and/or video playback and/or recording, and/or other physical measurement and/or stimulus.

In this embodiment, a "network" may be or comprise any mechanism, instrumentality, modality, and/or portion thereof that may permit, facilitate, and/or allow, at least in part, two or more entities to be communicatively coupled together. Also in this embodiment, a first entity may be "communicatively coupled" to a second entity if the first entity is capable of transmitting to and/or receiving from the second entity one or more commands and/or data. In this embodiment, a "wireless network" may mean a network that permits, at least in part, at least two entities to be wirelessly communicatively coupled, at least in part. In this embodiment, a "wired network" may mean a network that permits, at least in part, at least two entities to be

communicatively coupled, at least in part, non-wirelessly. In this embodiment, data and information may be used interchangeably, and may be or comprise one or more commands (for example one or more program instructions), and/or one or more such commands may be or comprise data and/or information. Also in this embodiment, an "instruction" may include data and/or one or more commands.

In this embodiment, one or more hosts 10, one or more intermediate stations 25, and/or one or more hosts 20 may be, constitute, or comprise one or more respective network hops from and/or to which one or more PS 52 may be propagated. In this embodiment, a hop or network hop may be or comprise one or more nodes in a network to and/or from which one or more packets may be transmitted (e.g., in furtherance of reaching and/or to reach an intended destination).

One or more hosts 10 may comprise circuitry 1 18. Circuitry 118 may comprise circuit board (CB) 32 and one or more circuit cards (CC) 102. In this embodiment, CB 32 may comprise, for example, a system motherboard that may be physically and communicatively coupled to one or more CC 102 via a not shown bus connector/slot system. CB 32 may comprise one or more single and/or multi-core host processors (HP) 12 and computer-readable/writable memory 21. CB 32 also may comprise one or more chipsets (CS) 15 which may comprise, e.g., memory, input/output (I/O) controller circuitry, and/or network interface controller circuitry. One or more host processors 12 may be communicatively coupled via the one or more chipsets 15 to memory 21 and CC 102. CC 102 may comprise I/O circuitry 120. I/O circuitry 120 may be or comprise, for example, storage, network interface, and/or other I/O controller circuitry.

Alternatively or additionally, although not shown in the Figures, some or all of I/O circuitry 120 and/or the functionality and components thereof may be comprised in, for example, CB 32 (e.g., in one or more host processors 12 and/or the one or more chipsets 15). Also alternatively, one or more host processors 12, memory 21, the one or more chipsets 15, and/or some or all of the functionality and/or components thereof may be comprised in, for example, I/O circuitry 120 and/or one or more CC 102. Many other alternatives are possible without departing from this embodiment. One or more hosts 20 and/or one or more intermediate stations 25 each may comprise respective components that may be identical or substantially similar, at least in part, in their respective constructions, operations, and/or capabilities to the respective construction, operation, and/or capabilities of the above described (and/other other) components of one or more hosts 10. Of course, alternatively, without departing from this embodiment, the respective constructions, operations, and/or capabilities of one or more hosts 20 and/or one or more intermediate stations 25 (and/or one or more components thereof) may differ, at least in part, from the respective construction, operation, and/or capabilities of one or more hosts 10 (and/or one or more components thereof). In this embodiment, one or more hosts 20 may comprise buffer memory 101 to receive and/or store, at least temporarily, one or more packets (e.g., one or more packets PI ... PN from one or more streams 52) that may be received by one or more hosts 20 via one or more links 51.

In this embodiment, one or more operating systems (OS) 31 and/or one or more drivers 140 may be executed, at least in part, by one or more host processors 12, circuitry 1 18, and/or I/O circuitry 120. When so executed, one or more OS 31 and/or one or more drivers 140 may become resident, at least in part, in memory 21. Additionally, in this embodiment, a value may be "predetermined" if the value, at least in part, and/or one or more algorithms, operations, and/or processes involved, at least in part, in generating and/or producing the value is predetermined, at least in part. Also, in this embodiment, a process, thread, daemon, program, driver, virtual machine, virtual machine monitor, operating system, application, and/or kernel each may (1) comprise, at least in part, and/or (2) result, at least in part, in and/or from, execution of one or more operations and/or program instructions. Although one or more drivers 140 and one or more OS 31 are shown in the drawings as being distinct from each other, one or more drivers 140 may be comprised, at least in part, in one or more OS 31, or vice versa, without departing from this embodiment.

In this embodiment, "circuitry" may comprise, for example, singly or in any combination, analog circuitry, digital circuitry, hardwired circuitry, programmable circuitry, co-processor circuitry, processor circuitry, controller circuitry, state machine circuitry, and/or memory that may comprise program instructions that may be executed by programmable circuitry. Also in this embodiment, a host processor, processor, processor core, core, and/or controller each may comprise respective circuitry capable of performing, at least in part, one or more arithmetic and/or logical operations, such as, for example, one or more respective central processing units. Also in this embodiment, a chipset may comprise circuitry capable of communicatively coupling, at least in part, two or more of the following: one or more host processors, storage, mass storage, one or more nodes, and/or memory. Although not shown in the Figures, one or more hosts 10 may comprise a graphical user interface system. The not shown graphical user interface system may comprise, e.g., a respective keyboard, pointing device, and display system that may permit a human user to input commands to, and monitor the operation of, one or more hosts 10, one or more intermediate stations 25, one or more hosts 20, and/or system 100.

Memory 21 may comprise one or more of the following types of memories:

semiconductor firmware memory, programmable memory, non-volatile memory, read only memory, electrically programmable memory, random access memory, flash memory, magnetic disk memory, optical disk memory, one or more random access memory cells (e.g., embedded in one or more integrated circuit chips that may implement at least in part controller and/or switch functionality), and/or other or later-developed computer-readable and/or writable memory. One or more machine-readable program instructions may be stored in circuitry 118, CB 32, CC 102, memory 21, and/or I/O circuitry 120. In operation of one or more hosts 10, these instructions may be accessed and executed by one or more host processors 12, one or more CS 15, I O circuitry 120, and/or circuitry 118. When so executed by these components, these one or more instructions may result in these components performing operations described herein as being performed by these components of system 100.

In this embodiment, a portion, subset, or fragment of an entity may comprise all of, more than, or less than the entity. Also in this embodiment, the terms "packet" and "frame" may be used interchangeably and may comprise one or more symbols and/or values.

I O circuitry 120 may exchange data and/or commands with one or more host 20 via one or more links 50, one or more intermediate stations 25, and/or one or more links 51, in accordance with one or more communication protocols. For example, in this embodiment, these one or more protocols may be compatible with, at least in part, e.g., one or more Ethernet, Transmission Control Protocol/Internet Protocol (TCP/IP), and/or other protocols.

For example, one or more Ethernet protocols that may be utilized in system 100 may comply or be compatible with, at least in part, IEEE 802.3-2008, December 26, 2008; IEEE 802.1Q-2005, May 19, 2006; IEEE 802.11a-1999, February 11, 1999; IEEE 802.1 lb-1999, February 1 1, 1999; IEEE 802.11g-2003, October 20, 2003; IEEE 802.11n-2009, October 29, 2009; and/or, IEEE P802.1Qat/D6.0, Draft Standard for Local and Metropolitan Area

Networks— Virtual Bridged Local Area Networks— Amendment 9: Stream Reservation Protocol (SRP), April 23, 2010. The TCP/IP protocol that may be utilized in system 100 may comply or be compatible with, at least in part, the protocols described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 791 and 793, published September 1981. Many different, additional, and/or other protocols (including, for example, those stated above) may be used for such data and/or command exchange without departing from this embodiment (e.g., earlier and/or later-developed versions of the aforesaid, related, and/or other protocols).

After, for example, a reset or other event of or in one or more hosts 10, system 100, and/or communication via one or more links 50, etc., I/O circuitry 120 in one or more hosts 10 may transmit, at least in part, to one or more hosts 20, via one or more links 50, one or more intermediate stations 25, and/or one or more links 51, one or more packet steams 52. One or more packet streams 52 may comprise, for example, a plurality of packets PI ... PN that are transmitted from I/O circuitry 120 at respective transmission times Tl ... TN. In this embodiment, in order to permit the respective transmissions of packets PI ... PN to be respectively transmitted from circuitry 120 at respective transmission times Tl ... TN, circuitry 1 18 may generate, at least in part, and/or store in memory 21, prior to the respective

transmissions, one or more (and in this embodiment, a plurality of) descriptors Dl ... DN to be associated (e.g., respectively) with one or more (and in this embodiment, a plurality of) packets PI ... PN in the one or more streams 52. Additionally or alternatively, circuitry 118 and/or circuitry 120 may use, at least in part, one or more descriptors Dl ... DN. The respective transmission times Tl ... TN may be specified (e.g., respectively) in the one or more respective descriptors D 1 ... DN in such a manner as to permit the respective transmission times T 1 ... TN to be explicitly identified and/or identifiable based at least in part upon the one or more respective descriptors Dl ... DN. For example, the respective contents of the respective descriptors D l ... DN may explicitly identify the respective transmission times Tl ... TN of the respective packets PI ... PN in the one or more streams 52.

In this embodiment, a packet stream, communication stream, or communication may be used interchangeably, and may be or comprise a plurality of packets and/or frames, such as, for example, without limitation, a plurality of packets and/or frames that may be related and/or associated with each other, at least in part (e.g., one or more media streams). Also, in this embodiment, a descriptor may comprise one or more commands and/or information associated, at least in part, with data. For example, in this embodiment, descriptors D 1 ... DN may be respectively associated with respective data 180A ... 180N (e.g., media data) to be included, at least in part, in packets P I ... PN, respectively. Although as illustrated in the Figures and described herein, data 180A ... 180N may be distinct from descriptors Dl ... DN, without departing from this embodiment, one or more respective portions of data 180A ... 180N may be respectively comprised, at least in part, in one or more descriptors Dl ... DN.

In this embodiment, each of the respective descriptors D 1 ... DN may comprise a respective field that may specify at least one respective counter value that may expressly identify (e.g., expressly state and/or recite) the one or more respective transmission times Tl ... TN at which the one or more respective packets P I ... PN may be intended to be transmitted by circuitry 120. For example, as shown in Figure 2, one or more descriptors Dl may comprises one or more fields 162 that may expressly identify one or more counter values (CV) 182 that may expressly identify the one or more transmission times Tl at which the one or more packets PI (that are associated with one or more descriptors Dl) are to be transmitted from and/or by circuitry 120. The one or more counter values 182 expressly identified in one or more descriptors D l may be calculated and/or determined with reference to time as measured by a reference clock signal counter value (RCSCV) 184 that may be maintained by (at least in part), for example, I/O circuitry 120. This reference clock signal counter value 184 may be utilized by I/O circuitry 120 and/or one or more drivers 140 to coordinate respective operations carried out the I/O circuitry 120 and/or one or more drivers 140. By way of example, the reference clock signal counter value may be incremented/decremented in synchrony with a reference clock signal, and/or may comply and/or be compatible with, at least in part, IEEE 802.1AS-201 1, IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time- Sensitive Applications in Bridged Local Area Networks, March 30 2011. Of course, other and/or additional techniques may be utilized without departing from this embodiment.

I/O circuitry 120 may determine when to transmit each of the respective packets PI ... PN in the stream 52 based at least in part upon respective comparisons of the respective counter values comprised in the respective descriptors Dl ... DN associated with the respective packets PI ... PN to the respective reference clock signal counter values that prevail at the respective times at which the respective comparison are made. For example, in the case of one or more descriptors Dl, as the reference clock signal counter value 184 changes in synchrony with the reference clock signal, I/O circuitry 120 may compare (e.g., at periodic time intervals) the one or more counter values 182 in the one or more descriptors Dl with the reference clock signal counter value 184. The I/O circuitry 120 may transmit the one or more packets PI associated with the one or more descriptors Dl when (e.g., exactly concurrently with) the reference clock signal counter value 184 matches the one or more counter values 182.

In this embodiment, the execution of one or more drivers 140 in host 10 may result in one or more HP 12, circuitry 1 18, and/or one or more drivers 140 generating and/or storing, at least in part, in memory 21 the data 180A ... 180N and their respective associated descriptors Dl ... DN. For example, as generated, at least in part, by the one or more drivers 140, one or more descriptors D l may comprise one or more fields 162 that may include and/or specify one or more values 182.

Based at least in part upon one or more expected respective latencies and/or the one or more respective transmission times Tl ... TN (e.g., as specified by the one or more respective counter values in the respective descriptors Dl ... DN), I/O circuitry 120 may determine one or more respective earlier times (e.g., that may be respectively earlier than the respective transmission times Tl ... TN). These one or more respective expected latencies may be determined based at least in part upon one or more respective expected fetch latencies associated, at least in part, with respective fetching of data 180A ... 180N, respectively, from host system memory 21 given one or more current power states (e.g., of one or more components of host 10 that may be involved in carrying out the respective fetching of data 180A ... 180N). These one or more respective earlier times may comprise, for example, one or more respective fetch times at which the respective fetch times are to be initiated and/or one or more respective packet generation times at which the packets PI ... PN are to be generated, in order to permit the packets PI ... PN to be respective generated by and/or transmitted from I/O circuitry 120 in accordance with the respective transmission times Tl ... TN identified by the respective counter values in the respective descriptors Dl ... DN.

For example, in the case of data 180A and its associated one or more descriptors Dl, one or more drivers 140 may generate and store in host memory 21 the data 180A and one or more descriptors Dl via one or more operations 302 and one or more operations 304, respectively (see Figure 3). Thereafter, one or more drivers 140 may signal (via one or more data ready operations 306 shown in Figure 3) I/O circuitry 120 that data 180A and one or more descriptors D 1 have been generated and stored in memory 21.

In response, at least in part, to this signaling by one or more drivers 140, I/O circuitry 120 may fetch (via one or more fetch operations 308) one or more descriptors D l, thereby resulting in circuitry 120 receiving one or more descriptors Dl via one or more transfer operations 310. I/O circuitry 120 may determine, based at least in part, upon one or more values 182 in one or more descriptors Dl the one or more transmission times Tl at which one or more packets P I associated with one or more descriptors Dl are intended to be transmitted from and/or by circuitry 120 to one or more hosts 20. Based at least in part upon this and one or more expected latencies (e.g., symbolically illustrated by element 204 in Figure 3), I O circuitry 120 may determine one or more earlier times (e.g., times ET1 and ET2 that are earlier than one or more transmission times Tl) at which one or more respective operations are to be performed in order to permit the transmission of the one or more packets PI to be carried out as scheduled (e.g., at one or more transmission times Tl). In this embodiment, these operations may comprise, for example, the initiation of fetching and/or the fetching of the data 180A (associated with the one or more descriptors Dl) that is to be included in the one or more packets PI, and/or the generation of the one or more packets P 1. Accordingly, one or more earlier times ET 1 may comprise one or more fetch times TF at which such initiation of fetching and/or fetching of data 180A are to take place. Also accordingly, one or more earlier times ET2 may comprise one or more packet generation times PGT at which the generation (at least in part) of one or more packets PI is to occur.

For example, in this embodiment, one or more expected latencies 204 may be determined by circuitry 120, based at least in part, upon one or more expected fetch latencies (e.g., symbolically illustrated by element 206 in Figure 3) and/or one or more expected packet generation latencies (e.g., symbolically illustrated by element 350 in Figure 3). These one or more expected fetch latencies 206 may be associated with and/or be expected to arise from, at least in part, fetching of data 180A from memory 21, given (1) the current power state of one or more components (e.g., host processor 12 and/or chipset 15) and/or (2) one or more expected bus latencies (e.g., symbolically illustrated by element 222 in Figure 3) of one or more not shown buses in host 10 that may be expected to be involved in the fetching of the data 180A from memory 21.

These one or more expected packet generation latencies 350 may be associated with and/or be expected to arise from, at least in part, the operations involved in generating and/or preparing for transmission the one or more packets P I from circuitry 120. These operations may involve, for example, building, buffering, and/or queuing for transmission the one or more packets PI .

For example, depending upon the particular current power state of the host processor 12 and/or chipset 15, prior to and/or in order to be able to fetch data 180A from memory 21, host processor 12 and/or chipset 15 may undergo one or more power state transitions (e.g., from relatively lower power state such as sleep, suspend, or deep sleep state to relatively higher power state such as being fully powered up). These one or more transitions may involve and/or be subject to one or more power state transition latencies 220. When the host processor 12 and/or chipset 15 are fully powered up, one or more direct memory access (DMA) and/or other transfer operations may be initiated and/or carried out that may involve the host processor 12 and/or chipset 15 that may fetch data 180A from memory 21 to I/O circuitry 120. Such operations also may comprise one or bus transactions involving the not shown bus in host 10. These one or more bus transactions may involve one or more expected bus latencies 222. In determining these one or more expected latencies 204 and/or 206, circuitry 120 may take into account these factors.

In this embodiment, initially (e.g., after an initial activation of host 10 and/or circuitry 120), one or more expected latencies 206 and/or 350 may be based at least in part upon one or more pre-programmed latency values 122 (see Figure 1). These one or more pre-programmed latency values 122 may be, comprise, and/or be based upon, for example, one or more predetermined expected latencies for similar operations (e.g., similar to those implicating expected latencies 206 and/or 350), and may be derived based upon simulated and/or empirically determined (e.g., average) latencies for similarly configured hosts (e.g., similar to host 10). Thereafter, circuitry 120 may determine one or more expected latencies 206 based upon one or more values 122 and/or upon actual latency data 124 (see Figure 1). Actual latency data 124 may be derived, at least in part, from measurement (e.g., by circuitry 1 18, one or more drivers 140, and/or circuitry 120) of actual latencies associated, at least in part, with (1) one or more fetch operations 108 (see Figure 1) involving, at least in part, memory 21, that may implicate expected latencies 206 and/or (2) building by and/or preparing for transmission from circuitry 120 one or more actual packets (not shown).

In this embodiment, circuitry 120 may calculate one or more earlier times ETl such that one or more earlier times ETl may occur at or before one or more transmission times Tl minus the sum of the expected latencies 204 and 350. In other words, if one or more latencies 204 sum to LI and one or more latencies 350 sum to L2, respectively, then ETl may occur at or before Tl - (LI + L2). Circuitry 120 may calculate one or more earlier times ET2 such that one or more earlier times ET2 may occur after data 180A has been fetched and received by circuitry 120, but at or before one or more transmission times T 1 minus the sum of one or more expected latencies 350. In other words, ET2 may occur at or before Tl - L2, but after the data 180A has been fetched and received by circuitry 120.

In this embodiment, after circuitry 120 has determined, at least in part, ETl and ET2, circuitry 120 may initiate and/or fetch (e.g., via one or more operations 312), at one or more times ETl, data 180A from memory 21, based at least in part upon information contained in one or more descriptors Dl. This may result in circuitry 120 retrieving and/or receiving (via one or more operations 314) data 180A from memory 21. Thereafter, at one or more times ET2, circuitry 120 may generate and/or prepare for transmission one or more packets PI . Thereafter, at one or more transmission times Tl, circuitry 120 may transmit (via one or more operations 316) one or more packets PI to network 50 for propagation to host 20 (e.g., via one or more stations 25 and/or network 51).

Thus, circuitry 120 may issue, at one or more actual transmission times that may correspond, at least in part, to one or more transmission times Tl, one or more packets PI . This may be the case unless, for example, host 10 (e.g., circuitry 120 and/or 1 18) receives, at least in part, one or more congestion control messages (CCM) 178 (see Figure 1) from one or more intermediate stations 25 and/or one or more hosts 20. If host 10 receives, at least in part, one or more messages 178, circuitry 120 may adjust the actual issuance time of one or more packets P I, based at least in part upon information determined based, at least in part, upon the one or more messages 178, e.g., in order to try to reduce network congestion and/or to prevent overflow of buffer memory 101 in one or more hosts 20. For example, the actual issuance time selected by circuitry 120 may be after the one or more transmission times Tl.

Thus, an embodiment may include circuitry that may generate and/or use, at least in part, at least one descriptor to be associated with at least one packet. The at least one descriptor may specify at least one transmission time at which the at least one packet is to be transmitted. The at least one transmission time may be specified in the at least one descriptor in such a manner as to permit the at least one transmission time to be explicitly identified based at least in part upon the at least one descriptor.

Advantageously, in this embodiment, the actual and/or exact transmission times (e.g., Tl ... TN) for packets P I ... PN in one or more packet streams 52 may be specified in descriptors Dl ... DN associated with the packets PI ... PN. This may permit more careful control and tuning of the timing of packet transmission, and also may reduce and/or bound packet transmission time jitter/variability. This may permit the amount of buffer memory 101 allocated by a receiving host 20 to be more carefully tailored to the specific actual transmission bandwidth of the transmitted packets, instead of being based upon possible worst case scenarios. This may permit the amount of buffer memory 101 allocated to be reduced. This also may make buffer memory usage and/or allocation more efficient. This embodiment also may permit power saving techniques and/or states to continue to be employed (e.g., in connection with host processor 12 and/or chipset 15), without significant modification.

Many other modifications are possible. For example, one or more descriptors Dl ... DN may be stored in memory 21 prior to or contemporaneous with their associated data 180A ... 180N becoming valid. Accordingly, this embodiment should be viewed broadly as

encompassing all such alternatives, modifications, and variations.