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 5E7243B29E for ; Mon, 10 Sep 2018 06:57:39 -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=1536577058; bh=lrHC1B+K8ttmzFZ+KLzcoh+ToTgbai+7DAqfa6UViz4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=yTRS7cc8EUQYR7tOwbxGGz4U6t06hzaq+NI+vA5XbQGOW9O8ILPqseoVwKQAgIXVZ jMFFry2+1fCRWBweQXWF1wp5CQCbc8e6jObPQLjswTO/dR5conFSq+PWSiSek5Mm2k /FOFdflHOLZdqtjaImrMQSkpQsjF7VKOLyxTQ/k1IH5Q/oH5rH4GjwpKs/s15PROF8 +U8flFAaEGDy8noFPPBPbfPgT9+jl4IVo1vKmKXj/8186XRkD+mUYep8shfGIl5tLz oYTNkDM5pIE+DopF51zuRH6YybcdE9rKsxgJH8tSUevwza2JQDafWcbkPu8O0lq7PM kANT1i4EWEPLQ== To: Johannes Berg , linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net Cc: Rajkumar Manoharan , Felix Fietkau In-Reply-To: <1536565717.3224.12.camel@sipsolutions.net> References: <153635803319.14170.10011969968767927187.stgit@alrua-x1> <153635897010.14170.2992498632345986102.stgit@alrua-x1> <1536565717.3224.12.camel@sipsolutions.net> Date: Mon, 10 Sep 2018 12:57:37 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87musplivy.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 10:57:39 -0000 Johannes Berg writes: > On Sat, 2018-09-08 at 00:22 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Usage of the new API is optional, so drivers can be ported one at a time. > > 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 ... Could you elaborate a bit more on how the hwq/txq stuff works in iwl? 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? > It would be nice to be able to use it, for better queue behaviour, but > it would mean much more accounting in iwlwifi? Not even sure off the > top of my head how to do that. I think we'll need to have some kind of fallback airtime estimation in mac80211 that calculates airtime from packet size and rate information. Not all drivers can get this from the hardware, it seems. See my reply to Kan about the BQL-like behaviour as well. Does iwl get airtime usage information for every packet on tx complete? -Toke