From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 708513BA8E for ; Mon, 19 Nov 2018 18:02:52 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1542668571; bh=r0zkPtNh1fdkyLfxhd6PdDI3vCgInr/zZWfL+E2RVN0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WP8lfD1424sd4hOC5gofgjso1gd1YdxfLwxLHAZ6iBAPjZ/Xx2RoNlBMGhjNTFp/Q YLg+skMX3hZGmDh3nvDTeZ7ppUrZ+CjSXp/2sRmsnTl1ZPkOH470lxJx6eIeyTxQdy SOJlwL2SohtfMufUGxxxBb85/9blCGdxFPF3vohh6SfsdD5HUYkuRItwJQB33m6Afw P3CvaTC66J0OljbDH6b4PF+cob/ZHX1jUyjrJ3zDmRfT0JTtAI6In01pVbKz8E1mqC SGiCDz9Z1RaNbSVzFWrk7Hiu0QhEwk/NC5EvveKw8IE9/K4mWIAqu3d0EEpaIvn0bV 1vJxTNWJbx9mw== To: Felix Fietkau , Rajkumar Manoharan , linux-wireless@vger.kernel.org, ath10k@lists.infradead.org Cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> References: <1542063113-22438-1-git-send-email-rmanohar@codeaurora.org> <1542063113-22438-4-git-send-email-rmanohar@codeaurora.org> <871s7nv9pl.fsf@toke.dk> <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> Date: Mon, 19 Nov 2018 15:02:50 -0800 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1l8smat.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs 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: Mon, 19 Nov 2018 23:02:52 -0000 Hi Felix Thinking a bit more about this, I think that rather than having the driver work around the API as in your example... > do { > struct ieee80211_txq *pending_txq[4]; > int n_pending_txq = 0; > int i; > > if (hwq->pending < 4) > break;p > > nframes = 0; > > ieee80211_txq_schedule_start(hw, ac) > do { > bool requeue = false; > > struct ieee80211_txq *txq; > > txq = ieee80211_next_txq(hw, ac); > if (!txq) > break; > > nframes += schedule_txq(txq, &requeue); > if (requeue) > pending_txq[n_pending_txq++] = txq; > > } while (n_pending_txq < ARRAY_SIZE(pending_txq)); > > for (i = n_pending_txq; i > 0; i--) > ieee80211_return_txq(hw, pending_txq[i - 1]); > > ieee80211_txq_schedule_end(hw, ac) > } while (nframes); ... really what we want is that the driver can just do this: ieee80211_txq_schedule_start(hw, ac); while ((txq = ieee80211_next_txq(hw, ac)) { schedule_txq(txq, &requeue); return_txq(txq); } ieee80211_txq_schedule_end(hw, ac); and expect so get through all eligible TXQs. Note that there will be cases where there is only a single eligible TXQ (such as the example I gave in the other email); in which case the current version is fine. But there is (probably) also going to be cases where more than one TXQ is eligible at the same time, which we cannot handle with the current RR scheduler. However, I think that assuming we can get the scheduler to guarantee that it will return all eligible TXQs between each pair of calls to schedule_start()/schedule_end(), we should be fine with the current API. Do you agree with this? -Toke