summaryrefslogtreecommitdiffstats
path: root/Documentation/vm
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2015-05-19 13:36:38 +0200
committerJohannes Berg <johannes.berg@intel.com>2015-05-20 15:09:22 +0200
commit252ec2b3aa6f6a9ac29c6539027db600c11bf45e (patch)
treeaa99419180f9711834e4142e8c3c261d8ebdb85a /Documentation/vm
parent22d3a3c829fa9ecdb493d1f1f2838d543f8d86a3 (diff)
downloadtalos-op-linux-252ec2b3aa6f6a9ac29c6539027db600c11bf45e.tar.gz
talos-op-linux-252ec2b3aa6f6a9ac29c6539027db600c11bf45e.zip
mac80211: don't split remain-on-channel for coalescing
Due to remain-on-channel scheduling delays, when we split an ROC while coalescing, we'll usually get a picture like this: existing ROC: |------------------| current time: ^ new ROC: |------| |-------| If the expected response frames are then transmitted by the peer in the hole between the two fragments of the new ROC, we miss them and the process (e.g. ANQP query) fails. mac80211 expects that the window to miss something is small: existing ROC: |------------------| new ROC: |------||-------| but that's normally not the case. To avoid this problem, coalesce only if the new ROC's duration is <= the remaining time on the existing one: existing ROC: |------------------| new ROC: |-----| and never split a new one but schedule it afterwards instead: existing ROC: |------------------| new ROC: |-------------| type=bugfix bug=not-tracked fixes=unknown Reported-by: Matti Gottlieb <matti.gottlieb@intel.com> Reviewed-by: EliadX Peller <eliad@wizery.com> Reviewed-by: Matti Gottlieb <matti.gottlieb@intel.com> Tested-by: Matti Gottlieb <matti.gottlieb@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'Documentation/vm')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud