Thread (1 message) 1 message, 1 author, 2016-08-11

Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2016-08-11 13:22:22
Also in: lkml, netdev

On Tue, 2016-07-19 at 08:36 -0400, Bob Copeland wrote:
On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
quoted
When a packet is received for transmission,
a PREQ frame is sent to resolve the appropriate path to the desired
destination.
After path was established, any sequential PREQ will be sent only
after
dot11MeshHWMPpreqMinInterval, which usually set to few seconds.

This implementation has an impact in cases where we would like to
resolve the path quickly.
A clear example is when a peer was disconnected from us,
while he acted as a hop to our destination.
Although the path table will be cleared, the next PREQ frame will
be sent only after reaching the MinInterval.
This will cause unwanted delay, possibly of few seconds until the
traffic will resume.

 	if (!(mpath->flags & MESH_PATH_RESOLVING))
-		mesh_queue_preq(mpath, PREQ_Q_F_START);
+		mesh_queue_preq(mpath, PREQ_Q_F_START, true);
What about something like this here instead:

    if (!(mpath->flags & MESH_PATH_RESOLVING)) {
        /* force next preq to be sent without delay */
        ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
        mesh_queue_preq(mpath, PREQ_Q_F_START);
    }
Yaniv, did you disagree with this for some strong reason, or were you
going to resend?

Having a smaller patch seems nicer too.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help