Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200205191043.21913-1-linus.luessing@c0d3.blue>
 <3300912.TRQvxCK2vZ@bentobox> <3097447.aZuNXRJysd@sven-edge> <87blnblsyv.fsf@codeaurora.org>
In-Reply-To: <87blnblsyv.fsf@codeaurora.org>
From:   Dave Taht <dave.taht@gmail.com>
Date:   Tue, 28 Apr 2020 05:27:25 -0700
Message-ID: <CAA93jw6xoh=Nu3-OcfU5cnO5rct+QGqRf_Tnwx7-BpO8Fhrakw@mail.gmail.com>
Subject: Re: [PATCH] ath10k: increase rx buffer size to 2048
To:     Kalle Valo <kvalo@codeaurora.org>
Cc:     Sven Eckelmann <sven@narfation.org>,
        ath10k <ath10k@lists.infradead.org>,
        =?UTF-8?Q?Linus_L=C3=BCssing?= <linus.luessing@c0d3.blue>,
        Simon Wunderlich <sw@simonwunderlich.de>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ben Greear <greearb@candelatech.com>,
        "David S . Miller" <davem@davemloft.net>,
        =?UTF-8?Q?Linus_L=C3=BCssing?= <ll@simonwunderlich.de>,
        mail@adrianschmutzler.de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 28, 2020 at 5:06 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Sven Eckelmann <sven@narfation.org> writes:
>
> > On Wednesday, 1 April 2020 09:00:49 CEST Sven Eckelmann wrote:
> >> On Wednesday, 5 February 2020 20:10:43 CEST Linus L=C3=BCssing wrote:
> >> > From: Linus L=C3=BCssing <ll@simonwunderlich.de>
> >> >
> >> > Before, only frames with a maximum size of 1528 bytes could be
> >> > transmitted between two 802.11s nodes.
> >> >
> >> > For batman-adv for instance, which adds its own header to each frame=
,
> >> > we typically need an MTU of at least 1532 bytes to be able to transm=
it
> >> > without fragmentation.
> >> >
> >> > This patch now increases the maxmimum frame size from 1528 to 1656
> >> > bytes.
> >> [...]
> >>
> >> @Kalle, I saw that this patch was marked as deferred [1] but I couldn'=
t find
> >> any mail why it was done so. It seems like this currently creates real=
 world
> >> problems - so would be nice if you could explain shortly what is curre=
ntly
> >> blocking its acceptance.
> >
> > Ping?
>
> Sorry for the delay, my plan was to first write some documentation about
> different hardware families but haven't managed to do that yet.
>
> My problem with this patch is that I don't know what hardware and
> firmware versions were tested, so it needs analysis before I feel safe
> to apply it. The ath10k hardware families are very different that even
> if a patch works perfectly on one ath10k hardware it could still break
> badly on another one.
>
> What makes me faster to apply ath10k patches is to have comprehensive
> analysis in the commit log. This shows me the patch author has
> considered about all hardware families, not just the one he is testing
> on, and that I don't need to do the analysis myself.

I have been struggling to get the ath10k to sing and dance using
various variants
of the firmware, on this bug over here:

https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/

The puzzling thing is the loss of bidirectional throughput at codel target =
20,
and getting WAY more (but less than I expected) at codel target 5.

This doesn't quite have bearing the size of the rx ring, except that in my
experiments the rx ring is rather small!! and yet I get way more performanc=
e
out of it....

(still,  as you'll see from the bug, it's WAY better than it used to be)

is NAPI in this driver? I'm afraid to look.
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpa=
tches


--=20
Make Music, Not War

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729