From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org (smtp.codeaurora.org [198.145.29.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A146D3B29E for ; Tue, 18 Sep 2018 14:51:44 -0400 (EDT) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E4D336083C; Tue, 18 Sep 2018 18:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1537296703; bh=IoNCgIjbGHQamZ4KD8R7ddit5K7g1SFxXBefQ/PVamw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BskElkwXKna/ITZInO2WRso9KMllpDBXmULfubsIzTq+RYMMi+SdwucIJWxPBHNjG 7a6Xt/0KIANuc3atqmkrfeF8rc6FILLS6V0rOfSQ9PF5tKkIQWJprth6XXbKOb2LGz oXI/NzJa1jTtDUJ21ntoZzN8uIWWTNdRjlPePYrw= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 7EB4C607F4; Tue, 18 Sep 2018 18:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1537296703; bh=IoNCgIjbGHQamZ4KD8R7ddit5K7g1SFxXBefQ/PVamw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BskElkwXKna/ITZInO2WRso9KMllpDBXmULfubsIzTq+RYMMi+SdwucIJWxPBHNjG 7a6Xt/0KIANuc3atqmkrfeF8rc6FILLS6V0rOfSQ9PF5tKkIQWJprth6XXbKOb2LGz oXI/NzJa1jTtDUJ21ntoZzN8uIWWTNdRjlPePYrw= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 18 Sep 2018 11:51:43 -0700 From: Rajkumar Manoharan To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Felix Fietkau , Kan Yan , linux-wireless-owner@vger.kernel.org In-Reply-To: <87o9cvksiv.fsf@toke.dk> References: <153711966150.9231.13481453399723518107.stgit@alrua-x1> <153711973109.9231.7094211814263758096.stgit@alrua-x1.karlstad.toke.dk> <13400b5f9bdb5e36c6afabd071cc7b0d@codeaurora.org> <87o9cvksiv.fsf@toke.dk> Message-ID: X-Sender: rmanohar@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Subject: Re: [Make-wifi-fast] [PATCH RFC v4 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: Tue, 18 Sep 2018 18:51:44 -0000 On 2018-09-18 03:29, Toke Høiland-Jørgensen wrote: > Rajkumar Manoharan writes: > >> On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote: >> return_txq() should return a bool to inform the driver that whether >> txq is queued back or not. > > What would the driver do with that return value, exactly? > never mind.. got lost with earlier schedule_txq API. >> Otherwise the same txq will be served indefinitely until txq becomes >> empty. This problem occurs when the driver is running out of hw >> descriptors or driver sends only N frames (< backlog_packets). > > No, if it's using next_txq(), the API guarantees that the same TXQ will > not be returned more than once between a set of calls to > schedule_start()/schedule_end() (by way of the seqno mechanism). I > didn't add the same check to may_transmit(), because I assumed the > driver would not be looping in this case. Is that not correct? > Yeah.. you are correct. sorry for the noise. >> Also an option to add the node at head or tail would be preferred. If >> return_txq adds node at head of list, then it is forcing the driver to >> serve same txq until it becomes empty. Also this will not allow the >> driver to send N frames from each txqs. > > The whole point of this patch set is to move those kinds of decisions > out of the driver and into mac80211. The airtime scheduler won't > achieve > fairness if it allows queues to be queued to the end of the rotation > before its deficit turns negative. And obviously there's some lag in > this since we're using after-the-fact airtime information. > Hmm.. As you know ath10k kind of doing fairness by serving fixed frames from each txq. This approach will be removed from ath10k. > For ath9k this has not really been a problem in my tests; if the lag > turns out to be too great for ath10k (which I suppose is a possibility > since we don't get airtime information on every TX-compl), I figure we > can use the same estimated airtime value that is used for throttling > the > queues to adjust the deficit immediately... > Thats true. I am porting Kan's changes of airtime estimation for each msdu for firmware that does not report airtime. -Rajkumar