Wifi packet merging

Abstract

The disclosed apparatus for packet merging comprises: detecting a trigger condition for initiating packet merging of packet traffic; and sending a notification to the endpoint device to start packet merging. The device may observe status in response to starting the packet merging, and report performance of the packet merging. A system may include a controller that detects a trigger condition for packet merging and notifies an endpoint device via a notification register. The controller may read a status register to report packet merge performance based on the read status. Various other methods, systems, and computer readable media are also disclosed.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. non-provisional application No. 18 / 194,311, filed on March 31, 2023, entitled “WIFIPACKET COALESCING,” which claims the benefit of U.S. Provisional Application No. 63 / 414,444, filed on October 7, 2022, the disclosure of which is incorporated by reference in its entirety. Background Art

[0003] Computing devices, particularly those that run on battery power, typically have power management strategies to more efficiently utilize available power resources. For example, a computing device may enter a low-power state, thereby trading off reduced computing performance with reduced power consumption. Low-power states are typically entered during idle periods when activity (e.g., input / output (I / O) activity) is low so as not to negatively impact the user experience. Low-power states may be interrupted and automatically terminated in response to activity. However, some types of activity, such as WIFI packet activity (e.g., WIFI network traffic / activity), may be sporadic in nature, such that low-power states are not effectively utilized. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The accompanying drawings illustrate several exemplary implementations and are a part of the specification. Together with the following description, these drawings demonstrate and explain the various principles of the present disclosure.

[0005] Figure 1 is a block diagram of an exemplary system for WIFI packet merging.

[0006] FIG. 2A to FIG. 2B is a diagram correlating group activity with low power states.

[0007] Figure 3 is a diagram of components for an exemplary handshake between a power management module and an endpoint device.

[0008] Figure 4 is a flow chart of an exemplary method for WIFI packet merging.

[0009] In all drawings, the same reference numerals and descriptions indicate similar but not necessarily identical elements. Although the exemplary implementations described herein are susceptible to various modifications and alternative forms, specific implementations have been shown by way of example in the drawings and will be described in detail herein. However, the exemplary implementations described herein are not intended to be limited to the specific forms disclosed. On the contrary, the present disclosure covers all modifications, equivalents, and alternatives that fall within the scope of the appended claims. DETAILED DESCRIPTION

[0010] The present disclosure as a whole relates to WIFI packet merging. As will be explained in more detail below, a specific implementation of the present disclosure determines when it is desirable to enter a low power state and initiates packet merging to better maintain the low power state. By doing so, the systems and methods described herein can improve the functionality of the computer itself by more effectively managing packet activity, which in turn can reduce the overall power consumption of the device and improve power management.

[0011] As will be described in greater detail below, the present disclosure describes various systems and methods for WIFI packet coalescing by determining a desired time for increasing the duration of a low power state and instructing an endpoint device receiving the packets to begin packet coalescing.

[0012] In one example, a device for WIFI packet merging includes a controller configured to (i) detect a trigger condition for packet merging for packet traffic, (ii) send a notification to an endpoint device to initiate packet merging, and (iii) observe a status in response to initiating packet merging. In some examples, the controller is further configured to report packet merging performance based on the observed status.

[0013] In some examples, the trigger condition corresponds to a power management policy. In some examples, the power management policy corresponds to at least one of a low power mode or a battery power mode (e.g., a DC mode). In some examples, the power management policy corresponds to power consumption based on a current workload. In some examples, the power management policy corresponds to low input / output (I / O) activity.

[0014] In some examples, the notification includes the type of packet traffic to be merged. In some examples, the type of packet traffic corresponds to bulk traffic. In some examples, the type of packet traffic corresponds to isochronous traffic.

[0015] In some examples, the controller is configured to send a notification to the endpoint device via a register. In some examples, the endpoint device stores a state in the register. In some examples, the state corresponds to an observed idle duration. In some examples, the controller is further configured to send feedback to the endpoint device based on the state.

[0016] In some examples, the observed idle duration corresponds to an amount of time the endpoint device has stored packets in a buffer of the endpoint device. In some examples, the controller is further configured to report packet coalescing performance by analyzing whether the observed idle duration reaches an expected idle duration. In some examples, the controller is further configured to report the packet coalescing performance to the endpoint device to provide feedback on packet coalescing.

[0017] In one specific implementation, a system for WIFI packet merging includes a notification register, a status register, and a controller, the controller being configured to: (i) detect a trigger condition for packet merging of packet traffic; (ii) store a notification of initiating packet merging in the notification register; and (iii) observe a state from the status register in response to initiating packet merging. In some examples, the controller is further configured to report packet merging performance based on the observed state.

[0018] In some examples, the trigger condition corresponds to at least one of a power management policy, a low power mode, a battery power mode, power consumption based on current workload, or low input / output (I / O) activity. In some examples, the notification includes the type of packet traffic to be merged. In some examples, the state corresponds to an idle duration.

[0019] In some examples, the state corresponds to an observed idle duration corresponding to an amount of time that the endpoint device has stored packets in a buffer of the endpoint device. In some examples, the controller is further configured to report packet coalescing performance by analyzing whether the observed idle duration reaches an expected idle duration. In some examples, the controller is further configured to report the packet coalescing performance via a notification register to provide feedback on packet coalescing.

[0020] In one specific implementation, a method for WIFI packet coalescing includes: (i) detecting a trigger condition for packet coalescing of packet traffic corresponding to a power management policy; (ii) sending a notification to an endpoint device via a notification register to initiate packet coalescing of a type of packet traffic; and (iii) in response to initiating packet coalescing, observing an idle duration of the endpoint device via a status register. In some examples, the method also includes reporting packet coalescing performance based on the observed idle duration.

[0021] In some examples, the power management policy also corresponds to at least one of a low power mode, a battery power mode, power consumption based on a current workload, or low input / output (I / O) activity.

[0022] In some examples, the type of packet traffic corresponds to at least one of bulk traffic or isochronous traffic.In some examples, the method further includes analyzing the idle duration and sending feedback to the endpoint device based on the analyzing the idle duration.

[0023] In some examples, the observed idle duration corresponds to an amount of time the endpoint device has stored packets in a buffer of the endpoint device. In some examples, reporting the packet coalescing performance includes analyzing whether the observed idle duration reaches an expected idle duration. In some examples, reporting the packet coalescing performance also includes providing feedback about the packet coalescing via a notification register.

[0024] According to the general principles described herein, the features of any specific implementation described herein can be used in combination with each other. These and other specific implementations, features and advantages will be more fully understood after reading the following detailed description in conjunction with the accompanying drawings and claims.

[0025] refer to Figures 1 to 4 , the following will provide a detailed description of WIFI packet merging. Figure 1 Provides a detailed description of the example system. FIG. 2A to FIG. 2B Provides detailed description of group activities in low power states. Figure 3 A detailed description of the components for an exemplary handshake between a power management module and an endpoint device is provided. Figure 4 A detailed description of the corresponding computer-implemented method is provided.

[0026] Figure 1 1 is a block diagram of an exemplary system 100 for group merging. The system 100 corresponds to a computing device, such as a desktop computer, a laptop computer, a server, a tablet device, a mobile device, a smartphone, a wearable device, an augmented reality device, a virtual reality device, a network device, and / or an electronic device. Figure 1 As shown, system 100 includes one or more memory devices, such as memory 120. Memory 120 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and / or computer-readable instructions. Examples of memory 120 include, but are not limited to, random access memory (RAM), read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), optical drive, cache, variations or combinations of one or more of the above components, and / or any other suitable memory.

[0027] like Figure 1As shown, the exemplary system 100 includes one or more physical processors, such as processor 110. Processor 110 generally represents a hardware-implemented processing unit of any type or form capable of interpreting and / or executing computer-readable instructions. In some examples, processor 110 accesses and / or modifies data and / or instructions stored in memory 120. Examples of processor 110 include, but are not limited to, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a field programmable gate array (FPGA) implementing a soft-core processor, an application-specific integrated circuit (ASIC), a system on a chip (SoC), a digital signal processor (DSP), a neural network engine (NNE), an accelerator, a graphics processing unit (GPU), one or more of the above parts, one or more of the above variations or combinations, and / or any other suitable physical processor.

[0028] like Figure 1 As further illustrated, processor 110 includes controller 112, notification register 114, and status register 116. Controller 112 corresponds to control circuitry and includes circuitry and / or instructions (e.g., firmware and / or software) for device power management. Notification register 114 corresponds to a public / visible local storage device that can be used for communication (e.g., by storing notifications that can be read by a recipient device). Status register 116 corresponds to a public / visible local storage device that can be used to store status reports, as will be further described below.

[0029] FIG. 2A to FIG. 2B A diagram of WIFI packet activity is shown for a computing device such as system 100. The computing device may have an endpoint device (e.g., a WIFI transmitter / receiver and / or other network interface device) that sends and receives data packets for a communication protocol such as WIFI. Figure 2A A diagram 200 illustrating grouping activities, and Figure 2B Diagram 201 illustrates consolidated packet activity across three Internet Protocol (IP) channels, although in other implementations the three IP channels may correspond to interrupt channels.

[0030] During idle periods (e.g., durations of low activity), the computing device may enter a low power state 240 in which the power consumption of the device is reduced. During sufficiently long idle periods, the device may also enter a deep low power state 242 in which the power consumption of the device is further reduced. However, packet 230 may interrupt the low power state and may force the device to wake up and process packet 230. Figure 2AAs illustrated, packets 230 may be received sporadically across IP1, IP2, and IP3. When all three channels are silent, the device may enter a low power state. Receiving a packet along any channel will interrupt the low power state. Thus, if Figure 2A As shown, it may be difficult for a device to be idle long enough to enter a deep low power state 242 .

[0031] Figure 2B This example illustrates how packet coalescing allows for more consistent idle periods. By instructing an endpoint device to coalesce packets, the endpoint device can buffer received packets and provide the buffered packets at more regular intervals (e.g., in bursts rather than scattered forms). Figure 2B As shown, the device may enter the deep low power state 242 more regularly and reliably because sporadic packets are less likely to interrupt idle periods.

[0032] although Figure 2A and Figure 2B And the examples described herein relate to WIFI packets, but in other examples, the packets may correspond to other communication protocols. Figure 2A and Figure 2B Low power state 240 and deep low power state 242 are described, but in other examples, power management of a device may include various other types of low power states.

[0033] Figure 3 Exemplary paths between a power management module and an endpoint device are illustrated. Figure 3 Device 300 corresponding to system 100 is shown. Device 300 includes a power management module 350 (which in some examples corresponds to controller 112), an input / output (I / O) module 352, an interface 354, and an endpoint device 360. Power management module 350 represents circuitry and / or software (e.g., firmware) for managing power consumption of device 300, such as through a power management policy. I / O module 352 represents circuitry and / or software (e.g., firmware) for communicating with input devices. Interface 354 represents circuitry and / or software (e.g., firmware) for communication between various components of device 300. Endpoint device 360 ​​represents circuitry and / or software (e.g., firmware) for interfacing / communicating with an external device, which in some implementations corresponds to network communication (e.g., WIFI).

[0034] To avoid using drivers or processor interactions to communicate between the power management module 350 and the endpoint device 360, in some implementations, registers in the interface 354 can be used to store messages. For example, the interface 354 can have a notification register 314 (corresponding to the notification register 114) and a status register 316 (corresponding to the status register 116). The notification register 314 and / or the status register 316 can be public / visible to the power management module 350 and the endpoint device 360.

[0035] The power management module 350 may determine, for example, based on a power management policy, when it is desirable to enable packet coalescing. For example, when the device 300 is in battery power (e.g., direct current (DC) mode and / or battery saving mode), it is desirable to reduce power consumption. Other criteria for desiring reduced power consumption include reduced demand for power consumption of the current workload, low I / O activity, etc. To notify the endpoint device 360 ​​to initiate packet coalescing, the power management module 350 stores a notification for the endpoint device 360 ​​in the notification register 314.

[0036] In some implementations, the notification may include additional instructions. For example, the notification may indicate what type of packet traffic to merge, such as bulk traffic, isochronous traffic (e.g., traffic delivered with a time constraint such as ensuring audio and video synchronization), etc. In addition, in some examples, the notification may indicate the desired buffering. For example, the desired buffering may correspond to a time period (e.g., 2 ms) or the total number and / or size of packets to be buffered.

[0037] Endpoint device 360 ​​may read the notification from notification register 314 and perform packet coalescing by buffering received packets. Although endpoint device 360 ​​may attempt to follow the instructions provided in the notification, in some implementations, endpoint device 360 ​​may deviate from these instructions. For example, endpoint device 360 ​​may choose not to buffer packets that are considered high priority or time sensitive.

[0038] To measure buffering performance, endpoint device 360 ​​may store a status report in status register 316. For example, the status report may indicate an idle duration achieved by buffering (e.g., average idle duration, minimum idle duration, etc.). In some examples, if buffering is ineffective, the minimum idle duration may be 0 ms.

[0039] Additionally, in some implementations, the power management module 350 can analyze the status report. For example, the power management module 350 can determine the performance of the provided instructions and provide feedback (e.g., new notifications) to the endpoint device 360 ​​to improve the buffering scheme. In some examples, the power management module 350 can dynamically manage packet merging.

[0040] Figure 4 is a flow chart of an exemplary computer-implemented method 400 for WIFI packet merging. Figure 4 The steps shown in may be performed by any suitable computer executable code and / or computing system, including Figure 1 and / or Figure 3 In one example, Figure 4 Each of the steps shown in represents an algorithm whose structure includes and / or is represented by multiple sub-steps, examples of which are provided in more detail below.

[0041] like Figure 4 As shown, at step 402, one or more of the systems described herein detects a trigger condition for packet merging of packet traffic. For example, the controller 112 and / or the power management module 350 detects one or more trigger conditions for packet merging of packet traffic.

[0042] The systems described herein can perform step 402 in various ways. In one example, the triggering condition corresponds to a power management policy. For example, the power management policy corresponds to at least one of a low power mode, a battery power mode (e.g., a DC mode and / or a battery saver mode). In some examples, the power management policy corresponds to power consumption based on a current workload, and / or low input / output (I / O) activity.

[0043] Additionally, in some examples, the notification includes the type of packet traffic to be merged. The type of packet traffic may correspond to bulk traffic, isochronous traffic, and / or other types of traffic.

[0044] At step 404, one or more of the systems described herein sends a notification to the endpoint device to initiate packet coalescing. For example, the controller 112 and / or the power management module 350 sends a notification (eg, to the endpoint device 360) to initiate packet coalescing.

[0045] The systems described herein may perform step 404 in various ways. In one example, the notification is sent to the endpoint device via a register (such as notification register 114 and / or notification register 314).

[0046] In some implementations, the notification may include additional information and / or instructions for the endpoint device. For example, the expected idle duration for traffic merging may be communicated to the endpoint device. After the expected idle duration has elapsed, the endpoint device may resume traffic. In some examples, the endpoint device may resume traffic more quickly (e.g., before the expected idle duration has elapsed) based on internal indications such as buffer status (e.g., the buffer is full and should be flushed), response timers, etc. Thus, the endpoint device may resume traffic based on the expected idle duration or the internal indication (whichever occurs first).

[0047] At step 406, one or more of the systems described herein observes status in response to initiating packet coalescing. For example, controller 112 and / or power management module 350 observes status reports (eg, provided by endpoint device 360) in response to initiating packet coalescing.

[0048] The systems described herein may perform step 406 in various ways. In one example, the endpoint device stores a state in a register (such as state register 116 and / or state register 316) for reading by controller 112 and / or power management module 350. In some examples, the state corresponds to an observed idle duration. In some examples, the observed idle duration may correspond to a buffering performance of the endpoint device, such as the amount of time the endpoint device has stored packets in a buffer.

[0049] Furthermore, in some implementations, one or more of the systems described herein reports packet coalescing performance based on observed conditions. For example, the controller 112 and / or the power management module 350 reports the packet coalescing performance of the endpoint device.

[0050] In one example, the controller 112 and / or the power management module 350 can analyze the observed status report to determine whether the observed idle duration reaches the expected idle duration, which can indicate whether the group coalescing is successful. In some examples, the analysis can include determining the group coalescing performance in response to the initial notification, such as the validity of the notification, whether any additional information provided in the notification affects the group coalescing performance, etc. In some examples, the analysis can be used to update the expected idle duration.

[0051] In some implementations, the controller 112 and / or the power management module 350 may report the packet coalescing performance internally (e.g., using the analysis to modify the trigger conditions and / or notifications). In some implementations, the controller 112 and / or the power management module 350 may report the packet coalescing performance to the endpoint device (e.g., via notifications and / or notification registers 114), such as by sending feedback about the packet coalescing to the endpoint device. For example, the controller 112 and / or the power management module 350 may send feedback to the endpoint device 360 ​​(e.g., via a new notification) for improving the packet coalescing performance. In some examples, the new notification may also include instructions for subsequent actions, such as another packet coalescing in response to the packet coalescing performance (e.g., updated instructions for the packet coalescing).

[0052] As described in detail above, the present invention is directed to WIFI packet merging for improved power management. The power management firmware of the SOC may send a message to the endpoint device to enable packet merging so that the endpoint device buffers received packets. In one specific implementation, the message is sent through various components to reach the endpoint device. Once the packet merging feature is enabled, the endpoint device buffers the packets and reports the time period for which the packets are buffered in a status register that can be read by the SOC, which time period corresponds to the idle duration. The SOC may perform further analysis of the idle duration. For example, in order to achieve improved residency in a deep sleep state, particularly for battery life use cases such as video conferencing, sufficient idle duration (e.g., about 5ms) in a frame window may be used.

[0053] The WIFI traffic can be dispersed, which can keep the SOC awake and further prevent the SOC from entering a deep sleep state. Therefore, the packet coalescing feature described herein can be used to increase the burstiness of WIFI traffic.

[0054] In one example for the packet coalescing feature, the IO firmware may send a message to the endpoint device through the interface private configuration space. The message does not necessarily involve any driver or CPU interaction. It may convey information such as enabling / disabling the feature and notification to start packet coalescing. Use cases of interest include DC mode, operation in the lowest operating power state, etc. These may be slow moving or infrequent events. The message may also indicate what type of traffic may be coalesced (e.g., bulk traffic vs. isochronous traffic).

[0055] The endpoint device reports status about the minimum idle duration observed by the device in a visible register of the interface. The status register may also have a time corresponding to no activity coming out of the device. For example, if the packet combination is not successful, the minimum idle duration may be zero. It is expected that the endpoint device allocates enough buffer to achieve a 5ms idle duration.

[0056] As described above, the computing devices and systems described and / or illustrated herein broadly represent any type or form of computing device or system capable of executing computer-readable instructions (such as those contained in the modules described herein). In its most basic configuration, these computing devices each include at least one storage device and at least one physical processor.

[0057] In some examples, the term "memory device" generally refers to any type or form of volatile or non-volatile storage device or medium capable of storing data and / or computer-readable instructions. In one example, a memory device stores, loads, and / or maintains one or more of the modules and / or circuits described herein. Examples of storage devices include, but are not limited to, random access memory (RAM), read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), optical disk drive, cache, variations or combinations of one or more of the above components, or any other suitable memory.

[0058] In some examples, the term "physical processor" generally refers to any type or form of hardware-implemented processing unit capable of interpreting and / or executing computer-readable instructions. In one example, the physical processor accesses and / or modifies one or more modules stored in the above-mentioned memory device. Examples of physical processors include, but are not limited to, microprocessors, microcontrollers, central processing units (CPUs), field programmable gate arrays (FPGAs) implementing soft-core processors, application-specific integrated circuits (ASICs), systems on chips (SoCs), digital signal processors (DSPs), neural network engines (NNEs), accelerators, graphics processing units (GPUs), one or more of the above, one or more variations or combinations of the above, or any other suitable physical processors.

[0059] Although illustrated as separate elements, the modules described and / or illustrated herein can represent parts of a single module or application. In addition, in some specific implementations, one or more modules in these modules can represent one or more software applications or programs, which, when executed by a computing device, cause the computing device to perform one or more tasks. For example, one or more modules in the modules described and / or illustrated herein represent modules stored and configured to run on one or more computing devices or systems in the computing device described and / or illustrated herein. In some specific implementations, a module can be implemented as a circuit or circuit. One or more modules in these modules can also represent all or part of one or more special-purpose computers configured to perform one or more tasks.

[0060] In addition, one or more of the modules described herein convert data, physical devices, and / or representations of physical devices from one form to another. For example, one or more of the modules described herein may receive workload data to be converted, convert the data, output the conversion results to initiate group merging, use the conversion results to analyze performance, and store the conversion results to further instruct endpoint devices. Additionally or alternatively, one or more of the modules described herein may convert a processor, volatile memory, non-volatile memory, and / or any other portion of a physical computing device from one form to another by executing on a computing device, storing data on a computing device, and / or otherwise interacting with a computing device.

[0061] In some implementations, the term "computer-readable medium" generally refers to any form of device, carrier, or medium that can store or carry computer-readable instructions. Examples of computer-readable media include, but are not limited to, transmission-type media, such as carrier waves, and non-transitory media, such as magnetic storage media (e.g., hard drives, tape drives, and floppy disks), optical storage media (e.g., compact disks (CDs), digital video disks (DVDs), and Blu-ray disks), electronic storage media (e.g., solid-state drives and flash memory media), and other distribution systems.

[0062] The order of process parameters and steps described and / or illustrated herein is given by way of example only and may be varied as desired. For example, although the steps illustrated and / or described herein are shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various exemplary methods described and / or illustrated herein may also omit one or more steps described or illustrated herein, or include additional steps in addition to those disclosed.

[0063] The foregoing description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary implementations disclosed herein. This exemplary description is not intended to be exhaustive or limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the present disclosure. The implementations disclosed herein should be considered in all respects to be illustrative and not restrictive. In determining the scope of the present disclosure, reference should be made to the appended claims and their equivalents.

[0064] Unless otherwise indicated, the terms "connected to" and "coupled to" (and their derivatives) as used in the specification and claims will be deemed to allow both direct and indirect (i.e., via other elements or components) connections. In addition, the terms "a" or "an" as used in the specification and claims will be deemed to mean "at least one". Finally, for ease of use, the terms "including" and "having" (and their derivatives) as used in the specification and claims are interchangeable with the word "comprising" and have the same meaning.

Claims

1. A device, comprising: A controller, the controller being configured to: detecting a trigger condition for packet merging of packet traffic; Sending a notification to the endpoint device to start group merging; as well as A state is observed in response to initiating the packet merging.

2. The apparatus of claim 1, wherein the trigger condition corresponds to a power management policy.

3. The apparatus of claim 2, wherein the power management policy corresponds to at least one of a low power mode, a battery power mode, power consumption based on a current workload, or low input / output (I / O) activity. The apparatus of claim 1 , wherein the controller is further configured to report packet merging performance based on the observed status. The apparatus of claim 4 , wherein the state corresponds to an observed idle duration.

6. The device of claim 5, wherein the observed idle duration corresponds to an amount of time that the endpoint device has stored packets in a buffer of the endpoint device. 7 . The apparatus of claim 5 , wherein the controller is further configured to report the packet merging performance by analyzing whether the observed idle duration reaches an expected idle duration.

8. The device of claim 4, wherein the controller is further configured to report the packet merging performance to the endpoint device to provide feedback regarding the packet merging.

9. The apparatus of claim 1, wherein the notification includes a type of packet traffic to be merged.

10. The apparatus of claim 9, wherein the type of the packet traffic corresponds to batch traffic or isochronous traffic.

11. The device of claim 1, wherein the controller is configured to send the notification to the endpoint device via a register.

12. The device of claim 1, wherein the endpoint device stores the status in a register.

13. A system, comprising: Notification register; Status register; and A controller, the controller being configured to: detecting a trigger condition for packet merging of packet traffic; storing a notification of initiating group merging in the notification register; as well as A status is observed from the status register in response to initiating the packet merging.

14. The system of claim 13, wherein the state corresponds to an observed idle duration corresponding to an amount of time an endpoint device has stored packets in a buffer of the endpoint device. 15 . The system of claim 14 , wherein the controller is further configured to report packet merging performance based on the observed status by analyzing whether the observed idle duration reaches an expected idle duration.

16. The system of claim 13, wherein the controller is further configured to report packet coalescing performance via the notification register based on the observed status to provide feedback on the packet coalescing.

17. A method comprising: detecting a trigger condition for packet merging of packet traffic corresponding to a power management policy; sending a notification to the endpoint device via a notification register to initiate packet merging of a type of packet traffic; as well as In response to initiating the packet coalescing, an observed idle duration of the endpoint device is observed via a status register.

18. The method of claim 17, further comprising reporting packet coalescing performance based on the observed idle duration, wherein the observed idle duration corresponds to an amount of time that the endpoint device has stored packets in a buffer of the endpoint device.

19. The method of claim 18, wherein reporting the packet coalescing performance comprises analyzing whether the observed idle duration reaches an expected idle duration.

20. The method of claim 18, wherein reporting the packet coalescing performance further comprises providing feedback regarding the packet coalescing via the notification register.

Images