diff options
author | Javier Cardona <javier@cozybit.com> | 2011-11-03 21:11:10 -0700 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2011-11-09 16:01:02 -0500 |
commit | f3011cf9deb689bd68279c728c501a4166983c19 (patch) | |
tree | 7d9945a2934c6de78063c358a6d350af8b6a19a9 /net/mac80211/mesh.h | |
parent | 7e1e386421e2ec7804b77f2c1c8e2517e82ecb7e (diff) | |
download | kernel_goldelico_gta04-f3011cf9deb689bd68279c728c501a4166983c19.zip kernel_goldelico_gta04-f3011cf9deb689bd68279c728c501a4166983c19.tar.gz kernel_goldelico_gta04-f3011cf9deb689bd68279c728c501a4166983c19.tar.bz2 |
mac80211: Avoid filling up mesh preq queue with redundant requests
Don't accept redundant PREQs for a given destination. This fixes a
problem under high load:
kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed
kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full
kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full
(...)
The 802.11s protocol has a provision to limit the rate of path requests
(PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no
limit on the rate at which PREQs were being queued up. There is a valid
reason for queuing PREQs: this way we can even out PREQ bursts. But
queueing multiple PREQs for the same destination is useless.
Reported-by: Pedro Larbig <pedro.larbig@carhs.de>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/mac80211/mesh.h')
-rw-r--r-- | net/mac80211/mesh.h | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h index 0f2c4e6..622cc96 100644 --- a/net/mac80211/mesh.h +++ b/net/mac80211/mesh.h @@ -31,6 +31,8 @@ * @MESH_PATH_FIXED: the mesh path has been manually set and should not be * modified * @MESH_PATH_RESOLVED: the mesh path can has been resolved + * @MESH_PATH_REQ_QUEUED: there is an unsent path request for this destination + * already queued up, waiting for the discovery process to start. * * MESH_PATH_RESOLVED is used by the mesh path timer to * decide when to stop or cancel the mesh path discovery. @@ -41,6 +43,7 @@ enum mesh_path_flags { MESH_PATH_SN_VALID = BIT(2), MESH_PATH_FIXED = BIT(3), MESH_PATH_RESOLVED = BIT(4), + MESH_PATH_REQ_QUEUED = BIT(5), }; /** |