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 7217F3CB35 for ; Mon, 10 Sep 2018 09:18:43 -0400 (EDT) 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=1536585522; bh=WJ+nCkrQ/OwHk/x98T4aVy44ew17ZJzI1Jg6SByxuG8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VEcstYyu6WIoaqJIjGhcIsf9fL7PjGNhwfJO4VTYNMWUabhDsIWmNYUGZyzm73jDF d1z0DZH36eDS1Vvj4IsMAJFgxhKn4Jv2S4/nLGhFGiEg4Q478KH4XY6euNRwGYz9tY Yky7qlL0NChUe8pJ/nuVwSkk+o6BwIjCprdLaX7f05QpLRkR9PdJHe1l6dsk4iA4rF PZEIU7gUif2I0S6VUCX0Y2TeW9P6b9PYbQFVBG4LCVjVN9pyu2wwBuc/2VjS4KEbXN rOPE9l4zpeUiM4rrtNXgxqyaEXCeJsonT/SYNhAk54cDskGbvFnGi+1KxJJ7XipMmB YelVxJqUzJlFg== To: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau In-Reply-To: <1536585051.3224.72.camel@sipsolutions.net> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <153635897010.14170.2992498632345986102.stgit@alrua-x1> <1536565717.3224.12.camel@sipsolutions.net> <87musplivy.fsf@toke.dk> <1536577419.3224.50.camel@sipsolutions.net> <87zhwpjzme.fsf@toke.dk> <1536583587.3224.71.camel@sipsolutions.net> <87wortjy8n.fsf@toke.dk> <1536585051.3224.72.camel@sipsolutions.net> Date: Mon, 10 Sep 2018 15:18:41 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r2i1jxse.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH RFC v3 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: Mon, 10 Sep 2018 13:18:43 -0000 Johannes Berg writes: > On Mon, 2018-09-10 at 15:08 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Johannes Berg writes: >>=20 >> > On Mon, 2018-09-10 at 14:39 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wr= ote: >> >=20 >> > > > From then on, right now we basically just try to refill the hardwa= re >> > > > queue from the TXQ whenever the hardware releases frames from that >> > > > queue. If there are none, we fall back to putting them on the hard= ware >> > > > queue from the wake signal. >> > >=20 >> > > OK. So if the TXQ is ineligible to dequeue packets, but still have t= hem >> > > queued, there would need to be a signal (such as wake_txq()) when it >> > > becomes eligible again, right? >> >=20 >> > Right. It wouldn't have to be wake_txq, but that seems as appropriate = as >> > anything else. >> >=20 >> > If we were to use ieee80211_airtime_may_transmit(), we'd have to have >> > something that tells us "I previously told you it may not transmit, but >> > now I changed my mind" :-) >>=20 >> Yes, exactly. Hmm, I'll see what I can come up with :) > > No need to look at this right now - let's get this stuff sorted out > first :) Right, sure, I'll get the port of ath9k done first; but doesn't hurt to think about API compatibility with the other drivers at the same time as well... If we have the start_schedule() / end_schedule() pair anyway, the latter could notify any TXQs that became eligible during the scheduling round. Also, instead of having the three different API functions (next_txq()/may_tx()/schedule_txq()), we could have get_txq(txq)/put_txq(t= xq) which would always need to be paired; but the argument to get_txq() could be optional, and if the driver passes NULL it means "give me the next available TXQ". So for ath9k it would be: start_schedule(ac); while ((txq =3D get_txq(NULL)) { queue_aggregate(txq); put_txq(txq); } end_schedule(ac); And for ath10k/iwlwifi it would be: on_hw_notify(txq) { start_schedule(ac); if (txq =3D get_txq(txq)) { queue_packets(txq); put_txq(txq); } end_schedule(ac); } I think that would be simpler, API-wise? -Toke