Re: [PATCH 2/2] ath10k: add per peer tx stats support for 10.2.4 - Toke Høiland-Jørgensen

From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Johannes Berg <johannes@sipsolutions.net>,
	Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "akolli\@codeaurora.org" <akolli@codeaurora.org>,
	"ath10k\@lists.infradead.org" <ath10k@lists.infradead.org>,
	"linux-wireless\@vger.kernel.org"
	<linux-wireless@vger.kernel.org>,
	Anilkumar Kolli <akolli@qti.qualcomm.com>,
	"linux-wireless-owner\@vger.kernel.org"
	<linux-wireless-owner@vger.kernel.org>
Subject: Re: [PATCH 2/2] ath10k: add per peer tx stats support for 10.2.4
Date: Fri, 01 Dec 2017 16:54:12 +0100	[thread overview]
Message-ID: <87a7z230m3.fsf@toke.dk> (raw)
In-Reply-To: <1512143142.25588.17.camel@sipsolutions.net>

Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2017-12-01 at 16:29 +0100, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>=20
>> Yeah, figures. Well, maybe we'll just have to support an asynchronous
>> callback into mac80211 to register airtime usage. Will probably have to
>> add some asynchronicity anyway to avoid doing too much work in the fast
>> path.
>
> I really think we should have that anyway. In fact, perhaps we should
> just enforce it that way? Then ath9k would have to do a bit more work,
> but it's also the slower of the devices :-)
>
> But this plays in with the whole multi-queue RX we discussed before.

Yeah, that's what I meant by 'add some asynchronicity anyway' :)

I guess that once we have an asynchronous scheduler task of some kind,
supporting the callback is easy, but pulling the data out of each packet
needs more work. But since we'll have to do that for ath9k anyway it
becomes more a question of whether it's something that should be
supported in mac80211 or if it should be implemented in each driver.
But since that logic will have to be written from scratch anyway, is
there any reason to not just do it in mac80211 from the beginning?

-Toke