Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200204120614.28861-1-yhchuang@realtek.com> <CAB4CAwdFez_WbRQb2jZQtqspSkO5ujL31ZLt4XshNcWiSqHByA@mail.gmail.com>
 <CAMrEMU_KJbwAK-onH0sRUgUPxDuZtD5bPJN6XmF=a9NqpfeJ+g@mail.gmail.com>
In-Reply-To: <CAMrEMU_KJbwAK-onH0sRUgUPxDuZtD5bPJN6XmF=a9NqpfeJ+g@mail.gmail.com>
From:   Brian Norris <briannorris@chromium.org>
Date:   Fri, 7 Feb 2020 12:41:09 -0800
Message-ID: <CA+ASDXPHWNN+TvrJFi_6w+ep_TBtLJ0refKenNb0tc8Vs+YjgQ@mail.gmail.com>
Subject: Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
To:     Justin Capella <justincapella@gmail.com>
Cc:     Chris Chiu <chiu@endlessm.com>, Tony Chuang <yhchuang@realtek.com>,
        Kalle Valo <kvalo@codeaurora.org>,
        linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 7, 2020 at 11:41 AM Justin Capella <justincapella@gmail.com> wrote:
> Instead of permanently disabling could a module parameter or other
> configurable be used? I appreciate the performance enhancements but
> don't like the idea of disabling functionality

It feels like you have that backwards: Tony is claiming that
(a) TX AMSDU does not give any performance benefit on 2.4GHz
(b) TX AMSDU gives a severe performance degradation on 2.4GHz with certain APs

That sounds like a case where the feature should be disabled by
default. (A separate module parameter to re-enable it experimentally
sounds like it could be OK, although it's not likely I would use it or
recommend doing so. But that doesn't sound like what you're
suggesting.)

I say "claiming" above, but I have fielded evidence for (b) at least.
I don't know much about (a), but limited tests haven't showed any real
loss for me.

HTH,
Brian