From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E062C43387 for ; Thu, 27 Dec 2018 10:25:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E6C6F21741 for ; Thu, 27 Dec 2018 10:25:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730276AbeL0KZj (ORCPT ); Thu, 27 Dec 2018 05:25:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39294 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727771AbeL0KZj (ORCPT ); Thu, 27 Dec 2018 05:25:39 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 860FADA31E; Thu, 27 Dec 2018 10:25:38 +0000 (UTC) Received: from localhost (ovpn-204-120.brq.redhat.com [10.40.204.120]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C0F860C66; Thu, 27 Dec 2018 10:25:37 +0000 (UTC) Date: Thu, 27 Dec 2018 11:25:36 +0100 From: Stanislaw Gruszka To: Tom Psyborg Cc: linux-wireless@vger.kernel.org, Randy Oostdyk , Daniel Golle , Felix Fietkau , Mathias Kresin Subject: Re: [PATCH v2 3/3] rt2x00: do not print error when queue is full Message-ID: <20181227102535.GA25885@redhat.com> References: <1545318971-28351-1-git-send-email-sgruszka@redhat.com> <1545318971-28351-3-git-send-email-sgruszka@redhat.com> <20181221095938.GA29536@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 27 Dec 2018 10:25:38 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sat, Dec 22, 2018 at 02:12:13PM +0100, Tom Psyborg wrote: > On 21/12/2018, Stanislaw Gruszka wrote: > > On Thu, Dec 20, 2018 at 06:52:03PM +0100, Tom Psyborg wrote: > >> Shouldn't you now also revert the commits from > >> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commitdiff;h=de1c58a64bd66319e770d2587da07d8c9c90174a > >> since they caused throughput regression? > > > > For the record: this is not about currently posted patch and you > > reference this: > > https://lore.kernel.org/linux-wireless/1538697102-3764-1-git-send-email-pozega.tomislav@gmail.com/ > > > > I'm not convinced for reverting. I would rater fix the problem > > on top of the patches. > > > > Let me get this straight: You made these patches to fix wlan stalls > when "arrived at non-free entry" error message appears, but in turn > they result in lower throughput. Now you are moving err printks to dbg > level since the printks themselfs are causing wlan problems. Why would > you waste life fixing patches that don't do any good? Just revert all > of them! I move prints to debug level for for "arrived at non-free entry" from "Dropping frame due to full tx queue" . For some users those 5 patches improve things, they fix problem of router connection hung completely. Printk problem is connection stall due to CPU being busy, but is possible to reconnect to AP after that. It's different issue. Also 'result in lower throughput' is over-generalized statement. More precise would be 'it lower throughput on some test cases', but even in those specific cases, throughput vary randomly with and without patches. > > Looking at those images, the performance vary also on "good" case and > > there is entry 12.6 Mbits/s there, where the lowest entry on "bad" case > > is 32.5 Mbits/s . However, yes, if performance do not drop for unknown > > reason, it is 51.4 Mbits/s with patches and 56.6 Mbits/s on good case. > > > > Could you specify after applying which one of those 5 patches > > throughput regression starts ? > > > > Thanks > > Stanislaw > > > > I cannot test that ATM but the best would be to revert all of them. Ok, could anyone else confirm this throughput regression and point offending commit ? > And, for the future reference, please try sending them to the > openwrt-devel list first for testing before deciding to go upstream. Sure, I can send patches to openwrt-devel. However, for the record, I informed about those patches interested people including you in August: https://lore.kernel.org/linux-wireless/20180815114029.GA1862@redhat.com/ month before I submitted them upstream. Thanks Stanislaw