From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org (smtp.codeaurora.org [198.145.29.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9CE373B29E for ; Mon, 30 Jul 2018 20:19:19 -0400 (EDT) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id EAAD360714; Tue, 31 Jul 2018 00:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1532996358; bh=EETBaELzKiJbN9mPqCnGpahLlnTKNl4xzlMnQmeXmdw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iQl/4SF16hfebZwxcGk/O1/Ul7n8m0Yo9wkycDMJzr5k7LJNt82BFy/syHiG9alEx Edh5qyum18HWpY3U9E0Mz5rWOb8R9b11Zy2h7/1l0G7/6FIJwOkzKDWSjpaEkEx5iJ 25Cmqac9CKNbGhoeT+WM2S2oOF8l3Nz8ZCVdmGdM= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 7E4AF602A7; Tue, 31 Jul 2018 00:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1532996358; bh=EETBaELzKiJbN9mPqCnGpahLlnTKNl4xzlMnQmeXmdw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iQl/4SF16hfebZwxcGk/O1/Ul7n8m0Yo9wkycDMJzr5k7LJNt82BFy/syHiG9alEx Edh5qyum18HWpY3U9E0Mz5rWOb8R9b11Zy2h7/1l0G7/6FIJwOkzKDWSjpaEkEx5iJ 25Cmqac9CKNbGhoeT+WM2S2oOF8l3Nz8ZCVdmGdM= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 30 Jul 2018 17:19:18 -0700 From: Rajkumar Manoharan To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Felix Fietkau , linux-wireless-owner@vger.kernel.org In-Reply-To: <87effkz6ft.fsf@toke.dk> References: <153115421866.7447.6363834356268564403.stgit@alrua-x1> <153115422491.7447.12479559048433925372.stgit@alrua-x1> <361a221dd15e44028fd35440df657a3d@codeaurora.org> <87lgahbisu.fsf@toke.dk> <8d8160cd9c804d1b00ba4e234c8f1520@codeaurora.org> <87k1q09hf1.fsf@toke.dk> <87h8l39rv8.fsf@toke.dk> <01fe0f526e992563e3b1f450f8acc9e4@codeaurora.org> <87wotr2trs.fsf@toke.dk> <25dc507c35c2dff356742626d026989d@codeaurora.org> <877elo48ea.fsf@toke.dk> <9d2d6156f7bfd173ed5098f528d7ed49@codeaurora.org> <87k1pk3n7b.fsf@toke.dk> <87effkz6ft.fsf@toke.dk> Message-ID: X-Sender: rmanohar@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Subject: Re: [Make-wifi-fast] [RFC v2 1/4] mac80211: Add TXQ scheduling API 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: Tue, 31 Jul 2018 00:19:19 -0000 On 2018-07-30 15:48, Toke Høiland-Jørgensen wrote: > Rajkumar Manoharan writes: > > Hmm, the driver really shouldn't need to do any locking apart from > using > the next_txq() API. But I think you are right that the seqno mechanism > doesn't play well with unserialised access to through next_txq() from > multiple CPUs. I'll see what I can do about that, and also incorporate > the other changes we've been discussing into a new RFC series. > Great.. :) >> Hmm.. reorder_txq() API may not needed. Calling next_txq() takes care >> of reordering list though the driver is accessing txqs directly. > > Right, as long as the next_txq() path is still called even while > fetch_ind() is active, that should be fine. > I am still wondering how and when to refill deficit in case next_txq() won't be called. :( Will post RFC change on top of yours. -Rajkumar