Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1895865pxp; Mon, 21 Mar 2022 07:13:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxrR42f8zbYdjOmr7JTgnWMiJg4k4OuWqTWQovF886NiS6ef8zDf9w6dk1WwiNt07ownc8 X-Received: by 2002:a17:902:e892:b0:153:db4c:8ccf with SMTP id w18-20020a170902e89200b00153db4c8ccfmr12915158plg.17.1647872029130; Mon, 21 Mar 2022 07:13:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647872029; cv=none; d=google.com; s=arc-20160816; b=J/EtjbP5RqQeJJGnr3FJf125uOJUD3UaOJ+kRJlwTzkn+MSfdvSgfAdcU+4b6f/uSH XoUq0DoXLIOC4dN2RV5rDPprPUQjijCaw+KemilWmqINGHJkKsJj6ONgvCsEQFgeqKvd 8niExO77LrdeuiwgSBoNh20tC4aRH6KwZ6n0dIlY8Nr8OSzLPXsi1HWziZTHLuzXiKrA uzSTCA1EI/A57kPKLxshVsv6FghYSaf7qliq4PD6qQNU8bW2Ab0dPozXxKVAFqgOnOFR dMiMJSEs/+8572XiFfjnVk+UGo5J6rY1kTNd4zelE77Ccb570XuETp1R+IYoWbdafeHq dR8Q== 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 :message-id:date:user-agent:references:in-reply-to:subject:cc:to :from:dkim-signature; bh=Yr4H9L8AVTY/UOQp+fniSW4ZcPnYYmP67WBo3TWjXS0=; b=bR9nIHuDF/Fub3TGDCIdxupz3KaGmeOgrW+TQf5nYvVytDrTlF63VCosQmrmfB80nr csaq3lpqexbS4h77rw1cudPttL/be25KFDr49BjyfcXQMSEhENgqMS8U7am4O8RWHXdw w6Lmiv7bNexR9PrhRN+kBWsq18dID2cjmrZeOBXkbdGqfRJEQyvd9h31PR/sqEpSOMt8 qTn0eVb/z8M1C8Ghy+tyQlLSWbNMrzDSlCpOqlzTY82lNzIMGewQAJNoe+sBiU+YRSii 2GO016PvN0xdCO3AIatf7vNx8ajfffT/wCBlHJCRMmYH94DnNzCeR+LzKmU+AlLdguYo Ccxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u6DkRcZ8; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j7-20020a17090276c700b00153b2d164ebsi9708064plt.243.2022.03.21.07.13.35; Mon, 21 Mar 2022 07:13:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u6DkRcZ8; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343586AbiCTTQz (ORCPT + 70 others); Sun, 20 Mar 2022 15:16:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233934AbiCTTQy (ORCPT ); Sun, 20 Mar 2022 15:16:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 378D2D3AF3; Sun, 20 Mar 2022 12:15:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA9176121F; Sun, 20 Mar 2022 19:15:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B809C340EE; Sun, 20 Mar 2022 19:15:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647803730; bh=5yU1VY41IGpB26hHV6JgEd0Xh2QyTxC+F9+H8KW7OsY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=u6DkRcZ8fJI95fjed2Wb/xkpzXzZXcJ6T3ppsjhbWJDs/X0De6DQQV0uBOX70SJ0b dyoqIOrG4iWEmaAWpKtc074CZ9O75ITf6vKKl8xXsQvnS25JBT1yZu/aWUDETL0WZc XI3PM30mymypLSbkJk01Trr0zgX3Gx9UVHj9N8zz1fcw/DP+KEoIdq/L6bOgqQlTo1 qQ9JKFz3HR7YVj1YF8X0j6OUy6qHNCF+cBLr5Gfa8j2O+gmaw5Mdr1gAeCBu46xJ2P Lj6GhXUkh3W7AT/ZWYXQs6IbQcQ8SWslHxcwvXOhTOebOkj2z7HHlTLozoNS2CRvgb +qJt+V9uiNOLg== From: Kalle Valo To: Bryan O'Donoghue Cc: Edmond Gagnon , Benjamin Li , "David S. Miller" , Jakub Kicinski , wcn36xx@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] wcn36xx: Implement tx_rate reporting In-Reply-To: (Bryan O'Donoghue's message of "Sun, 20 Mar 2022 18:03:10 +0000") References: <20220318195804.4169686-1-egagnon@squareup.com> <20220318195804.4169686-3-egagnon@squareup.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Date: Sun, 20 Mar 2022 21:15:25 +0200 Message-ID: <87pmmgo2pe.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Bryan O'Donoghue writes: > On 20/03/2022 13:21, Bryan O'Donoghue wrote: >> On 18/03/2022 19:58, Edmond Gagnon wrote: >>> +=C2=A0=C2=A0=C2=A0 INIT_DELAYED_WORK(&wcn->get_stats_work, wcn36xx_get= _stats_work); >> >> Instead of forking a worker and polling we could add the relevant >> SMD command to >> >> static int wcn36xx_smd_tx_compl_ind(struct wcn36xx *wcn, void *buf, >> size_t len) >> { >> =C2=A0=C2=A0=C2=A0 wcn36xx_smd_get_stats(wcn, 0xSomeMask); >> } >> >> That way we only ever ask for and report a new TX data rate when we >> know a TX event - and hence a potential TX data-rate update - has >> taken place. >> >> --- >> bod >> > > Thinking a bit more > > - Do the SMD get_stats in the tx completion > This might be a problem initiating another SMD transaction inside > of an SMD callback. But is the most straight forward way to > get the data while avoiding alot of needless polling. > > - Schedule your worker from the TX completion > Again you should only care about gathering the data when you know > something has happened which necessitates gathering that data > like TX completion > > - Schedule your worker from the RX indication routine > Seems not as logical as the first two but it might be easier > to schedule the worker in the RX data handler > > Either way, I do think you should only gather this data on an event, > not as a continuous poll. I agree, a continuous poll is not a good idea as it affects power consumption. What about struct ieee80211_ops::sta_statistics? AFAIK that's called only when user space is requestings stats so the overhead should be minimal. --=20 https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc= hes