How is AP supposed to handle power-save packets from peer?

Michal Kazior michal.kazior at tieto.com
Thu Jul 9 22:20:13 PDT 2015


On 10 July 2015 at 02:03, Ben Greear <greearb at candelatech.com> wrote:
> Suppose one is doing heavy download (AP -> peer traffic), and there are lots of frames in the
> NIC's tx buffers (ath10k firmware, in this case).
>
> Then, peer sends a power-save pkt telling AP it is going off-channel or otherwise
> will be unavailable.

I assume you're exploring the worst-case scenario when all tx buffers
are consumed and peer goes to sleep, am I correct?


>
> What is the appropriate behaviour from the AP?  Can the firmware just drop all those tx frames to
> make room to handle other stations?  Maybe report ACK failure and hope the upper level stacks
> retransmit as appropriate?
>
> Or, is the host supposed to flush the peer's packets to clear out the frames?
>
> Or, is firmware somehow supposed to keep all the frames for when the peer comes back?

Firmware will keep frames buffered until station wakes up again.

There's a timeout to detect stale stations as far as I'm aware and the
default value is 10s (sounds familiar? this goes back to mgmt tx/
credit starvation). This makes to handle stations that go to sleep and
then out of range/away. AP doesn't need to keep frames buffered till
the end of time. Once the timeout is hit firmware stops caring about
station's last seen sleep state transition and marks it as awake and
just sends frames to it (with tons of retransmits if it's really not
there anymore since there'd be noone to ACK) - in which case you'll
get no_ack=1 in tx status.

See: WMI_10X_VDEV_PARAM_AP_DETECT_OUT_OF_SYNC_SLEEPING_STA_TIME_SECS

Ideally there should be little to no buffer bloat but it's difficult
to do that considering aggregation sizes of 11ac..


Michał



More information about the ath10k mailing list