From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6F1E53B25D for ; Thu, 1 Sep 2016 05:20:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 633194161D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1472721652; bh=1TMxOO5StIzAQJFJ1v38Ze72YtZKoxXqbhFtq6+w15o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cfA4xmuAG48C0munCKBavflXSTwHJcT1LF1g8vYpQDiaMwPx+XfKrwI1hidOVlFMD ES5LB0r6/BWQivJ8Ree90aGsGMF7dVE5w5PJUAMvV5ufMkSvPCVux7Avd1d/wjXo4N F986/KGOAegDv1bZb52ZBHzK0gZKUL6d1p9IZhSk= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id B2942C40231; Thu, 1 Sep 2016 11:20:51 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Johannes Berg Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org References: <20160824162015.29933-1-toke@toke.dk> <20160830131548.6014-1-toke@toke.dk> <1472677599.5470.13.camel@sipsolutions.net> <87inug81vo.fsf@toke.dk> <1472718860.4249.0.camel@sipsolutions.net> <8737lk816p.fsf@toke.dk> <1472720848.9608.1.camel@sipsolutions.net> Date: Thu, 01 Sep 2016 11:20:51 +0200 In-Reply-To: <1472720848.9608.1.camel@sipsolutions.net> (Johannes Berg's message of "Thu, 01 Sep 2016 11:07:28 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8760qgugb0.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] [PATCH v4] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue. X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 09:20:54 -0000 Johannes Berg writes: >> > They have three possible values ... :) >> >> Ah, no, not the handlers themselves. Meant the invoke_tx_handlers() >> function (or all three of them after my patch; hence the plural). To >> avoid the "0 means true" confusion you alluded to :) >> > > Ah. Actually, even I got confused and thought the return value *was* > the same as the handler. > > I think it doesn't matter to be tricky, gcc is probably going to (have > to) generate exactly the same code like when you explicitly put an if > statement in there, it seems? Yeah, was going to do that anyway. But since I'm touching the code anyway, this might be an opportunity to avoid constructs like this: if (!invoke_tx_handlers(tx)) /* continue sending the packet */ Most other succeed/fail functions seem to be of type bool, so it would help consistency as well. Unless there is some particular reason why this function happens to be using 0 to indicate success? -Toke