On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote: > Chun-Yeow Yeoh > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving > time > > On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote: > > > To improve that, added an 'immediate' flag to be used when the > > > path needs > to be resolved. > > > Once set, a PREQ frame will be send w/o considering the > > > MinInterval > parameter. > > > > Suggest that you try to reduce the mesh_hwmp_preq_min_interval to > > your desired value instead of introducing a new patch specific to > > your use case. > > > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute > > to specify the minimum interval of time during which a mesh STA can > > send only one Action frame containing a PREQ element. This is to > > avoid flooding of broadcast PREQ frame especially when the number of > > mesh STA is increased. > > Good point, according to 13.10.9.3, conditions for sending PREQ include: > > "The mesh STA has not sent a PREQ element for the target mesh STAs > less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case, > the transmission of the PREQ has to be postponed until this condition becomes true." > As I see it, the key point here is "for the target meh STA", Today, the code will not send a PREQ to ANY target if dot11MeshHWMPpreqMinInterval didn't passed. The information is saved in the 'ifmsh->last_preq', and not per path. Another point is, that this is a case where we had a valid path, but lost it due to our next hop peer disconnect. Reducing the dot11MeshHWMPpreqMinInterval will just flood the network, Our goal is to improve the healing time, it's not a specific use case, it will improve network performance. Thanks, Yaniv -- 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
