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>
This commit is contained in:
committed by
John W. Linville
parent
7e1e386421
commit
f3011cf9de
@@ -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),
|
||||
};
|
||||
|
||||
/**
|
||||
|
Reference in New Issue
Block a user