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 7659C3B29E for ; Mon, 30 Jul 2018 18:48:06 -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=1532990885; bh=ymJLfY5oBXLbZ0Z/OxUovAcu2lXZGKuvM+uJRj5N9Uk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FQopaFv3HwNufPoPpoSSBUSP4C/QqFRVUVFkhGFcnTiTx2SjqNih2NhTOW5i4WyaC EGR8yW0m0Q2tdgJJM9JSYGLJCubZaFkiPWFh60+BClDBk7JvkmCM+cblEaiEobxZ7w S1s38cUSJXMMF/dO6vglub1Kku7oVSpuAWO4gWmluLZG5DxJHuNrWugepb3TE4XN2k izDytbTKR0x9mdxtBUbnrMxi/Z0kiVBP6ygTHYoavovsi9seNAaDwOs+psc4ZxDU3q yuRdHwCrdXIAV+MTxbiU1Nv9DsC/wK0O+YIF2l8Z/X4IE2HYFtD6QDqz/rmrH1NwZT ZYqRR7J755TEw== To: Rajkumar Manoharan Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Felix Fietkau , linux-wireless-owner@vger.kernel.org In-Reply-To: References: <153115421866.7447.6363834356268564403.stgit@alrua-x1> <153115422491.7447.12479559048433925372.stgit@alrua-x1> <361a221dd15e44028fd35440df657a3d@codeaurora.org> <87lgahbisu.fsf@toke.dk> <8d8160cd9c804d1b00ba4e234c8f1520@codeaurora.org> <87k1q09hf1.fsf@toke.dk> <87h8l39rv8.fsf@toke.dk> <01fe0f526e992563e3b1f450f8acc9e4@codeaurora.org> <87wotr2trs.fsf@toke.dk> <25dc507c35c2dff356742626d026989d@codeaurora.org> <877elo48ea.fsf@toke.dk> <9d2d6156f7bfd173ed5098f528d7ed49@codeaurora.org> <87k1pk3n7b.fsf@toke.dk> Date: Tue, 31 Jul 2018 00:48:06 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87effkz6ft.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Make-wifi-fast] [RFC v2 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, 30 Jul 2018 22:48:06 -0000 Rajkumar Manoharan writes: >>> A simple change in argument may break algo. What would be seqno of >>> first packet of txq if queue_skb() isn't reset seqno? >> >> It would be 0, which would be less than the current seqno in all cases >> except just when the seqno counter wraps. >> > > One point should be mentioned in comment section of next_txq() that > the driver has to ensure that next_txq() iteration is serialized i.e > no parallel txq traversal are encouraged. Though txqs_list is maintained > in mac80211, parallel iteration may change the behavior. For example > I thought of get rid of txqs_lock in ath10k as txqs_list is moved to > mac80211. > But it is still needed. right? Hmm, the driver really shouldn't need to do any locking apart from using the next_txq() API. But I think you are right that the seqno mechanism doesn't play well with unserialised access to through next_txq() from multiple CPUs. I'll see what I can do about that, and also incorporate the other changes we've been discussing into a new RFC series. > Hmm.. reorder_txq() API may not needed. Calling next_txq() takes care > of reordering list though the driver is accessing txqs directly. Right, as long as the next_txq() path is still called even while fetch_ind() is active, that should be fine. >>> If we don't handle this case, then ath10k driver can not claim >>> mac80211 ATF support. Agree that MU-MIMO won't work with DDR >>> scheduler. and it will impact MU-MIMO performace in ath10k when >>> mac80211 ATF is claimed by ath10k. >> >> Yeah, so the question is if this is an acceptable tradeoff? Do you have >> any idea how often MU-MIMO actually provides a benefit in the real >> world? >> > Hmm.. We have some criteria of ~1.9 gain in Mu-MIMO test cases with 50 > 11ac clients. Hmm, yeah, that would be a shame to lose; although I do think 50-client deployments are still relatively rare for many people. So maybe we can make airtime fairness something that can be switched on and off for ath10k, depending on whether users think they will be needing MU-MIMO? Until we come up with a scheduler that can handle it, of course... -Toke