From patchwork Mon Nov 14 12:43:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanislaw Gruszka X-Patchwork-Id: 9427449 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9877F6047D for ; Mon, 14 Nov 2016 12:44:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 94C742879B for ; Mon, 14 Nov 2016 12:44:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 898D528921; Mon, 14 Nov 2016 12:44:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 146952879B for ; Mon, 14 Nov 2016 12:44:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932643AbcKNMoo (ORCPT ); Mon, 14 Nov 2016 07:44:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58330 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932305AbcKNMoo (ORCPT ); Mon, 14 Nov 2016 07:44:44 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BF9F861E7C; Mon, 14 Nov 2016 12:44:43 +0000 (UTC) Received: from localhost (dhcp-27-90.brq.redhat.com [10.34.27.90]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAECigLO024353; Mon, 14 Nov 2016 07:44:43 -0500 Date: Mon, 14 Nov 2016 13:43:23 +0100 From: Stanislaw Gruszka To: Mathias Kresin Cc: linux-wireless@vger.kernel.org, Helmut Schaa , Felix Fietkau Subject: Re: [PATCH 05/10] rt2800: make ba_size depend on ampdu_factor Message-ID: <20161114124323.GA31857@redhat.com> References: <1478095865-8651-1-git-send-email-sgruszka@redhat.com> <1478095865-8651-6-git-send-email-sgruszka@redhat.com> <20161114084536.GB12372@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161114084536.GB12372@redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 14 Nov 2016 12:44:43 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Nov 14, 2016 at 09:45:36AM +0100, Stanislaw Gruszka wrote: > Could you check below patch and see if it helps? If it does not, > could you printk sta->ht_cap.ampdu_density and ba_size values > and provide them here. Actually please print parameters from below patch. I think ba_size should be based on per TID buf_size instead of ampdu_factor, in case STA has buf size different for some TIDs. Also adding Felix to cc since my orginal patch: http://marc.info/?l=linux-wireless&m=147809595316289&w=2 was shamelessly stolen from mt76 driver. Perhaps Felix could provide us some expertise. Thanks Stanislaw diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c index 2515702..35bc38c 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c @@ -7950,6 +7950,8 @@ int rt2800_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif, struct rt2x00_sta *sta_priv = (struct rt2x00_sta *)sta->drv_priv; int ret = 0; + printk("action %d sta %pM tid %u buf_size %u ampdu_factor %u\n", params->action, sta->addr, params->tid, params->buf_size, sta->ht_cap.ampdu_factor); + /* * Don't allow aggregation for stations the hardware isn't aware * of because tx status reports for frames to an unknown station