On Wed, Jul 20, 2016 at 19:40:53, Yeoh Chun-Yeow wrote:
> Johannes Berg
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> time
>
>
>
> In case that you have additional 1 node with 3 paths toward the
> destination (instead of 2 paths like you illustrated), forcing
> additional PREQ doesn't guarantee that you will switch to the fixed path in your "next" attempt.
>
I'm not trying to guarantee a specific path, just build a path without waiting the MinInterval
> 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)
So if the current path is the best, no excessive PREQ frames will be sent.
In case the path is cleared, due to peer removal as described before.
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 ?
Regards,
Yaniv
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
