From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm20-vm3.bullet.mail.ne1.yahoo.com (nm20-vm3.bullet.mail.ne1.yahoo.com [98.138.91.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B0E693BA8D for ; Thu, 5 Jan 2017 10:17:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1483629478; bh=eow6CmnXtVwHmsc1QzCLx1fr2Gxrh0fe+KVrrBbdUhM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ok/fHUZjZpW0QR1UpBJmEQKsKZwoKgzJlwrD5LHV3r4PJSPsQeHOkUMuB9ariUCEF/im1saXZxSl5CA1NCtizt7a6+3aisHe/hja2GEn1loPB85h22S66N5LbA8Ane3XMkZIGKjmVwBWkqFM2iSPyuMLx4IMS4j1YUAJV7aLVOrh9dTa3dQfyAWBF/ItfiTov64boOnky/BMIWzFx2cMdEAojiyPXlXulnKdynbb7CciGvPhL0SDTxzUPMbGnIUZpdzy/c5fjY5qYxRX3RBNohH5LGuQEboWSc8bpcvCPSR+OZ1W9RByycGOaPFw3H+et3mPN4rSpEuueTh/mLZkNQ== Received: from [98.138.101.131] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2017 15:17:58 -0000 Received: from [98.138.89.196] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2017 15:17:58 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 05 Jan 2017 15:17:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 913758.13113.bm@omp1054.mail.ne1.yahoo.com X-YMail-OSG: dTetrQoVM1njZAk5a9j7xnBE5liip406et8J5Dsd.Q7t1SqL0STJJvWuOB5f.Pa naFQvwhq7qQRcxAh5.Cxf6CQL13XHAILWz6k03Nz4IGhgiOvszA2YGpCGb.59jNH5h1UenNld59A Q1U52YqiKNiLVk58FBaIDImH1BRyI49Zae7rD3WL2YodvVOXmaspRGYCao1aHytuQK_0v80g.T4V X3MWLQddadXJzeDc_TUfvqhKE.UfpgX_gGdI6ATcDSB8sefGOAu9p4vpG6ZPi6NehIrGZTOEO6Tn g8DlKTDFMOyxJPhaovJNTLcemCqbHTUBGyZvvutp341MiEl5xvlFuTX.XEpo1WEI398YV.a_3Pdr a0L97_Fs5KdUZXg9gPaHVLS25p1ooaWa.cBjepOVMDiohio554pmzBVMH8meBgW2VsCBvHGCFXca Ue.Pbu4825Dtg3YIOXp_BhXs2XKPfZCglxQQ7WuQI0Az7swnCwaXRl6CPeeohi3b6eItNFA35 Received: from jws200063.mail.ne1.yahoo.com by sendmailws105.mail.ne1.yahoo.com; Thu, 05 Jan 2017 15:17:58 +0000; 1483629478.504 Date: Thu, 5 Jan 2017 15:17:57 +0000 (UTC) From: "L. D. Pinney" Reply-To: "L. D. Pinney" To: Dave Taht , Michal Kazior Cc: "make-wifi-fast@lists.bufferbloat.net" , Loganaden Velvindron , LEDE Development List , Felix Fietkau Message-ID: <1431268961.444746.1483629477614@mail.yahoo.com> In-Reply-To: References: <46229222-ccb9-549d-578d-a8f4c9b83de4@nbd.name> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_444745_2073469746.1483629477611" X-Mailman-Approved-At: Fri, 06 Jan 2017 10:26:44 -0500 Subject: Re: [Make-wifi-fast] [LEDE-DEV] ath9k airtime fairness stabiity issues? 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: Thu, 05 Jan 2017 15:17:59 -0000 ------=_Part_444745_2073469746.1483629477611 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Dave : Can you please stop cross posting? It's quite annoying to see this unrelated babble about UN-related ath10k wh= en subject is ath9k Felix says it a no go on ath9k airtime fairness for the release....AND that= 's all we really need to know :) Larry=20 On Thursday, January 5, 2017 11:08 PM, Dave Taht = wrote: =20 On Thu, Jan 5, 2017 at 6:03 AM, Michal Kazior wr= ote: > On 5 January 2017 at 14:23, Felix Fietkau wrote: >> On 2017-01-05 14:22, Loganaden Velvindron wrote: >>> On Thu, Jan 5, 2017 at 4:59 PM, Dave Taht wrote: >>>> Felix: >>>> >>>> Was there a bugreport?=C2=A0 (don't see one) >>>> >>>> Do you have a specific device or behavior triggering this revert? >>>> >>>> >>>> On Thu, Jan 5, 2017 at 4:42 AM, Dave Taht wrote: >>>>> https://github.com/lede-project/source/commit/c296ba834db4ce8c71e0ad7= 030aab188fe60b27b >>>> >>>> >>> >>> Hi nbd & Toke, >>> >>> Would it be possible to enable it only on platforms like the tp-link >>> archer c7 v2 and the ubnt, where we have confirmed test reports for >>> the upcoming release ? >> I think it's quite unlikely that these issues are hardware specific. >> It's probably more related to the environment, types of clients, or even >> traffic patterns. > > Some people are complaining ath10k is unstable for them when > wake_tx_queue is enabled. I suspect the ATF problem in ath9k might be > providing extra opportunities to hit the same bug. Hmm. I would assume most ath10k users are on a multi-core? > I think RCU is not properly handled. txq_info shares lifecycle of > sta_info and should therefore be protected in the same manner. When > you queue up ieee80211_txq in a driver and use it later you > effectively break RCU. Grabbing rcu_read_lock() *later*, e.g. when > re-scheduling tx is not sufficient to protect from the possible race > of part1/part2 of station destroying logic and driver accessing its > internal txq list. Sounds like a promising theory. Most of our testing was on single-core devices, with the multi-core x86 version being kernel mainline (4.8ish), and not the lede backport. I long had mildly poor results in terms of throughput on the apu2 (x86 dual core), but assumed it was due to poor antennas. (no crashes) The omnia is a dual core arm, but I don't have one of those. As it turns out the UAP-lite I flashed ~2 days back is crashed right now, and another box was failing to get dhcp addresses (why I was looking at multicast), not even over ethernet. (someone remind me to not take a vacation over the holidays, next time there's holidays) > There seems to be a mechanism to hook up with to fix that already - > drv_sta_pre_rcu_remove(). > > I've been seldom looking at the ath10k problem and noticed this bit. I > didn't get a chance (and probably won't, any time soon) to take a > closer look, nor test/verify it for that matter. > > > Micha=C5=82 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev =20 ------=_Part_444745_2073469746.1483629477611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Dave :

Can you please sto= p cross posting?

It's quite annoying to= see this unrelated babble about UN-related ath10k when subject is ath9k

Felix says it a no go on ath9k airtime fa= irness for the release....AND that's all we really need to know :)


Larry


On Thursday, January 5= , 2017 11:08 PM, Dave Taht <dave.taht@gmail.com> wrote:

On Thu, Jan 5, 2017 at 6:03 AM= , Michal Kazior <michal.kazior@tieto.com&g= t; wrote:
> On 5 January 2017 at 14:23, Felix Fietkau = <nbd@nbd.name> wrote:
>> On 2017-01-0= 5 14:22, Loganaden Velvindron wrote:
>>> On Thu,= Jan 5, 2017 at 4:59 PM, Dave Taht <dave.taht@gmail.co= m> wrote:
>>>> Felix:
>>>>
>>>> Was there a bugreport= ?  (don't see one)
>>>>
>>>> Do you have a specific device or behavior triggering thi= s revert?
>>>>
>>>= >
>>>> On Thu, Jan 5, 2017 at 4:42 AM, Dav= e Taht <dave.taht@gmail.com> wrote:
>>>>> https://github.com/lede-project/source/commit/c296ba834db4ce8c7= 1e0ad7030aab188fe60b27b
>>>>
>>>>
>>>
>= ;>> Hi nbd & Toke,
>>>
>>> Would it be possible to enable it only on platforms like th= e tp-link
>>> archer c7 v2 and the ubnt, where w= e have confirmed test reports for
>>> the upcomi= ng release ?
>> I think it's quite unlikely that th= ese issues are hardware specific.
>> It's probably = more related to the environment, types of clients, or even
>> traffic patterns.
>
> = Some people are complaining ath10k is unstable for them when
> wake_tx_queue is enabled. I suspect the ATF problem in ath9k might= be
> providing extra opportunities to hit the same bu= g.

Hmm. I would assume most ath10k use= rs are on a multi-core?

> I think R= CU is not properly handled. txq_info shares lifecycle of
= > sta_info and should therefore be protected in the same manner. When> you queue up ieee80211_txq in a driver and use it late= r you
> effectively break RCU. Grabbing rcu_read_lock(= ) *later*, e.g. when
> re-scheduling tx is not suffici= ent to protect from the possible race
> of part1/part2= of station destroying logic and driver accessing its
>= ; internal txq list.

Sounds like a pro= mising theory. Most of our testing was on single-core
dev= ices, with the multi-core x86 version being kernel mainline
(4.8ish), and not the lede backport.

I long had mildly poor results in terms of throughput on the apu2 (x86dual core), but assumed it was due to poor antennas. (no cr= ashes)

The omnia is a dual core arm, b= ut I don't have one of those.

As it tu= rns out the UAP-lite I flashed ~2 days back is crashed right
now, and another box was failing to get dhcp addresses (why I was
looking at multicast), not even over ethernet.

(someone remind me to not take a vacation over the ho= lidays, next time
there's holidays)
> There seems to be a mechanism to hook up with to fix t= hat already -
> drv_sta_pre_rcu_remove().
>
> I've been seldom looking at the ath10k pr= oblem and noticed this bit. I
> didn't get a chance (a= nd probably won't, any time soon) to take a
> closer l= ook, nor test/verify it for that matter.
>
>
> Micha=C5=82



--
Dave = T=C3=A4ht
Let's go make home routers and wifi faster! Wit= h better software!
http://blog.cerowrt.org


______= _________________________________________
Lede-dev mailin= g list
Lede-dev@lists= .infradead.org
http://lists.in= fradead.org/mailman/listinfo/lede-dev


<= /div>
------=_Part_444745_2073469746.1483629477611--