Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1144174pxy; Fri, 23 Apr 2021 00:59:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZPzqYD+X7DU1AgIuDOLNfhJ6yNPvy4rlOsGCQanS2B/43P1gz3B1hANvSuqeorBVky3fF X-Received: by 2002:a17:906:cc88:: with SMTP id oq8mr2978090ejb.66.1619164759017; Fri, 23 Apr 2021 00:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619164759; cv=none; d=google.com; s=arc-20160816; b=onpAg02w54OzOZL6gcR/cw3AimD6OkN93geElbj/3FAEGYdIkyQOBD46rThMeQc4Z2 lFg0Kkdck206rF9SMuowgYkX0lS9nCeDD4rXpRZMHTu52mwHbfxf5XEHcuXSxNpWfOhP 9GEpyIOSbqi6AHTdUFzA5B7KOnFQ+J9Umo5t+hkqldfbF/H19OE+Kd4AgrvGxF97y7OI LRt2XWlvaFAWDNNTJZMFaOivSyIyX/k3t1yO+v5ZxWi9gLctUDE9fSSQlEI03w/UAzjJ y/Gxm5Ab4nDWJ0yEL1d/YtJl7oekHCi5MFPfvg+pAUQtA9ovu7lm2IR3t1bpzlMo0ejV yHSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=A98QKLDc1dXqV6C5LQiVugcSbqFHRiTJ4JNXDfZGKHI=; b=UM4FbkePFiAeJSwKo8EcA/IxBV3zviNamCJKBbzOvnrhe6UNJj6TFYLlxMu2SSUsRC SThX+2Qmv83gwCtQNLFi0KAAqfipiYJYTK10mwmT00J84jIO9gh58V27JtXcZALoNzGr JRXgVyMJs6SsmpLuMxm7ushBbW8FsB1r8wUOu53JYfS1ypqVtQELWdJRgMJXRiOColgH BLZ8Jr6iZUULcsfF6EVCeDCoJMvEE15KgpSlvzDtNUYH2ywlFmest+reblG7iqVjmtDy fRaCyHcdcI76Hx3heNcjaQrH40uHQRhzB2ksZC5LIYrXkoWQaCdc0LVYE86zPoPkkVem bgRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si4559961edx.163.2021.04.23.00.58.56; Fri, 23 Apr 2021 00:59:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230125AbhDWH7U (ORCPT + 99 others); Fri, 23 Apr 2021 03:59:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbhDWH7U (ORCPT ); Fri, 23 Apr 2021 03:59:20 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C260C061574 for ; Fri, 23 Apr 2021 00:58:44 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lZqhy-00FZHv-77; Fri, 23 Apr 2021 09:58:38 +0200 Message-ID: Subject: Re: [PATCHv2] mac80211: increment rx stats according to USES_RSS flag From: Johannes Berg To: Thiraviyam Mariyappan Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org Date: Fri, 23 Apr 2021 09:58:37 +0200 In-Reply-To: <1ee8d562986128767c037d20aedb96a5@codeaurora.org> References: <1613563010-1489-1-git-send-email-tmariyap@codeaurora.org> (sfid-20210217_125904_154301_738B3086) <1ee8d562986128767c037d20aedb96a5@codeaurora.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wed, 2021-04-21 at 22:18 +0530, Thiraviyam Mariyappan wrote: > In case of Mesh fast_rx is not applicable, but still USES_RSS can be > enabled from driver when parallel RX is supported by HW/Driver, > right?  Yes, I guess that's true. > Hence checked for USES_RSS support to update per cpu stats.Please > correct me if the meaning of USES_RSS is misunderstood and it applies > only when fast_rx for a STA is enabled. > Well, actually using multi-queue is pointless or even counter-productive when you don't have fast-RX, since then you'll run into a common lock, and doing much processing on multiple CPUs but under a common lock might well be worse than doing it on a single CPU in the first place, since you'll bounce the lock around all the time. However, you're right that the driver might generally advertise USES_RSS, but then not do it for mesh, but that throws off some statistics. Something like this might then be a much better fix though? diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c index ec6973ee88ef..f87e883862d9 100644 --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -2092,7 +2092,7 @@ sta_get_last_rx_stats(struct sta_info *sta) struct ieee80211_local *local = sta->local; int cpu; - if (!ieee80211_hw_check(&local->hw, USES_RSS)) + if (!sta->pcpu_rx_stats) return stats; for_each_possible_cpu(cpu) { @@ -2192,9 +2192,7 @@ static void sta_set_tidstats(struct sta_info *sta, int cpu; if (!(tidstats->filled & BIT(NL80211_TID_STATS_RX_MSDU))) { - if (!ieee80211_hw_check(&local->hw, USES_RSS)) - tidstats->rx_msdu += - sta_get_tidstats_msdu(&sta->rx_stats, tid); + tidstats->rx_msdu += sta_get_tidstats_msdu(&sta->rx_stats, tid); if (sta->pcpu_rx_stats) { for_each_possible_cpu(cpu) { @@ -2308,8 +2306,7 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo, if (!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES64) | BIT_ULL(NL80211_STA_INFO_RX_BYTES)))) { - if (!ieee80211_hw_check(&local->hw, USES_RSS)) - sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats); + sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats); if (sta->pcpu_rx_stats) { for_each_possible_cpu(cpu) { johannes