From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753370AbcGSMhB (ORCPT ); Tue, 19 Jul 2016 08:37:01 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:36615 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014AbcGSMg6 (ORCPT ); Tue, 19 Jul 2016 08:36:58 -0400 Date: Tue, 19 Jul 2016 08:36:48 -0400 From: Bob Copeland To: Yaniv Machani Cc: linux-kernel@vger.kernel.org, Maital Hahn , Johannes Berg , "David S. Miller" , linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time Message-ID: <20160719123648.GC11996@localhost> References: <20160713114528.24835-1-yanivma@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160713114528.24835-1-yanivma@ti.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); } Maybe a little more magic, but it has a comment explaining it and doesn't add a bool parameter everywhere. Or, maybe even just do it inside mesh_queue_preq() based on having PREQ_Q_F_START && !PREQ_Q_F_REFRESH (if those are the only cases where "true" is passed). Generally I try to avoid bool parameters where possible because when you look at a callsite, you don't know immediately what "true" and "false" mean, and also each one you add doubles the code paths through a given function. -- Bob Copeland %% http://bobcopeland.com/