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:
> >
> > 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
--
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
