>> I just take another look on your patch: >> >> @@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct >> ieee80211_sub_if_data *sdata, } >> >> if (!(mpath->flags & MESH_PATH_RESOLVING)) >> - mesh_queue_preq(mpath, PREQ_Q_F_START); >> + mesh_queue_preq(mpath, PREQ_Q_F_START, true); >> >> if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN) >> skb_to_free = skb_dequeue(&mpath->frame_queue); >> >> You modification is intended to add this "immediate" PREQ generation >> whenever the data frame is transmitted. In case the current path is >> indeed the best one, the PREQ will still generate without waiting for >> dot11MeshHWMPpreqMinInterval. The network is unnecessary flooded with >> PREQ. > > To my understanding, if you already have a path established, it will not send a new PREQ (as it's not in RESOLVING state) The mesh path is in resolving state means that the mesh STA has just triggered the discovery process. It sends out a PREQ and waits for PREP from your destined mesh STA. After receiving the PREP, the path is established and in active state. Then, the mesh STA is allowed to send another PREQ but limited by the dot11MeshHWMPpreqMinInterval. > So if the current path is the best, no excessive PREQ frames will be sent. Your patch is indeed allowed the mesh STA with on-going data transmission to send PREQ immediately no matter whether the path is already a best path or not. > In case the path is cleared, due to peer removal as described before. For your case, it happens to you that the leaving mesh STA is the one used for constructing the best path. So you want a quick PREQ to re-construct it back. > > The test use case is simple, and from our tests the impact on performance big related to our expectation, > I assume the question is, what are the performance expectations/requirements from the 802.11s mesh network ? You specified your test case, nothing wrong. But there is other use cases that we don't really need the "immediate" PREQ and indeed would like to limit by dot11MeshHWMPpreqMinInterval. Moving forward, I would suggest that a patch to turn it on or off with comments saying that turning this on may consume more airtime due to the overhead of broadcast PREQ no longer limited by dot11MeshHWMPpreqMinInterval and this feature is by default off. --- Chun-Yeow -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
