From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8F5713B29E for ; Mon, 10 Sep 2018 08:39:07 -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=1536583146; bh=E94QL+ke+1jl98oS1rsEVWqHKrimkmbg/RZfEDtyOUo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cO3ahTqK/MYwBdelcujiyJavXdFr75Xf2jW0XYIdqS2mjn3NKX3B26LL+xaFQDnUU zDdJ6Ig7EO8UWXIkYSybaEVRgZc0Xd1Bb9N9W8jkCgizI+IDM6jamA39i6Xp8ansff 6fPwstBpluHPHyzO/wfYZA9JiYVNeX1K5ZuYI8SD3P9KddINgoCPb7Yi5BFWf+3BrW EBprDSvIq974vE32CIloe0FNtJ1hv/HfdXVydw3SfzKnkncrMIZYuppU2mgzYKUzyH tN0CuYXTpAlfrKu5goP4YRZCP+HH5d2fMQbAVpF9zNSJ8kdfT/g+9Ne0az/87JFxAO 5Esv+zOV3aodw== To: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau In-Reply-To: <1536577419.3224.50.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> Date: Mon, 10 Sep 2018 14:39:05 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zhwpjzme.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 12:39:07 -0000 Johannes Berg writes: > On Mon, 2018-09-10 at 12:57 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Johannes Berg writes: >>=20 >> > On Sat, 2018-09-08 at 00:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wr= ote: >> > >=20 >> > > Usage of the new API is optional, so drivers can be ported one at a = time. >> >=20 >> > With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to >> > getting that patch in, though now the Jewish holidays mean a delay), >> > I'm not sure we'd be able to do this at all in iwlwifi. So this may >> > not be a case of porting one at a time until we can get rid of it ... >>=20 >> Could you elaborate a bit more on how the hwq/txq stuff works in iwl? > > I can try. > >> Does the driver just hand off a TXQ to the hardware on wake_txq(), which >> is then scheduled by the hardware after that? Or how does the mapping to >> hwqs work, and how is the hardware notified that there are still packets >> queued / that new packets have arrived for an already mapped txq? > > Basically, we use the TXQ driver data to do this. On initialization, we > set all TXQs to have no hardware queue mapped. Then, when the first wake > happens for this TXQ, we allocate a hardware queue for this RA/TID. > > From then on, right now we basically just try to refill the hardware > queue from the TXQ whenever the hardware releases frames from that > queue. If there are none, we fall back to putting them on the hardware > queue from the wake signal. OK. So if the TXQ is ineligible to dequeue packets, but still have them queued, there would need to be a signal (such as wake_txq()) when it becomes eligible again, right? -Toke