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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF5C5C433FE for ; Sun, 20 Mar 2022 18:03:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245752AbiCTSEl (ORCPT ); Sun, 20 Mar 2022 14:04:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229713AbiCTSEi (ORCPT ); Sun, 20 Mar 2022 14:04:38 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D52A3A72C for ; Sun, 20 Mar 2022 11:03:14 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id bg31-20020a05600c3c9f00b00381590dbb33so7296217wmb.3 for ; Sun, 20 Mar 2022 11:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:cc:references:in-reply-to:content-transfer-encoding; bh=Wur3Gr2lZCA8WSdLdjbJrUbR8JebUaR8BljbfzA1wHE=; b=Ggv9TffUnipbh1pKUc1k8M7NX5m0uX/GmuHOCDbRrQ3QE5BNe3mNiv4wSWrBiZlhQ+ 9rlVECFOklXwSB2tMOo4Yio67kyHT7EzRW+k8ESZRCFuN5Nx2qvMnxavIvaok0xbzfNb R57A2QGk01k0exi993vSHbj15PNmvvm3gUgcUW5xwUyIkMshF2KuZemP+UWh7t1KptMh NT9x/BcuQpjjpubJtBsZbEOsCrUpcgIgv6IouUQxlHS+uHV4F8UvOJ+5TjoUGJYLKkoN OswuTFxwPh7uHi6iy23mhAowAavWH4U8GDCJH5ILXRR8q1xZGXmSw+D07M5q+L9YPBsx G9+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=Wur3Gr2lZCA8WSdLdjbJrUbR8JebUaR8BljbfzA1wHE=; b=4x1mL4WcRw9w37PhlTT/q94rkqWhdqv8W2h220Gnn9LH1TVDmf/8946lryP86J2D6j 69Qo8FOnJFv/y2wc4ksc9hmjbb96rIdwtTwzNqqOQH8ZV0cc7NXT2wo+OT3HPRHKrO9n fNUFiAnK/V8bbm5gwkBW7WenjTzU/nd8ZK51SmuprEg/Fx5l6y1niZqtiFbcMeLzI41A PkhAIB8+MxV8JIy/3Xdwrh5oncRlvqX+33k+NjtAh8cSSmEfSqxFsvWsRm4Mb9NXp9qm Brp+xlz1mbZejSFTzNVl/bKBsioJrJWNUZQpjEBr4BtjEpGq/9rMCD30vWgu+SEIF5uU 8Hzg== X-Gm-Message-State: AOAM530BqV45KuqjS717+FYNFi6/ti1QFjmCnDxxH74dfO5D9Udn4r5b bTZK+U6cnoiGPST+ggvywi/NIQ== X-Google-Smtp-Source: ABdhPJxvHYeRUXTjFPf76c0NGheufnBvl4MJZkjFWLVW09XU/Gu4wlmGmU4t/Lys/fhzY+bO1UDWcA== X-Received: by 2002:a05:600c:3506:b0:389:d567:e9fa with SMTP id h6-20020a05600c350600b00389d567e9famr16229794wmq.74.1647799392724; Sun, 20 Mar 2022 11:03:12 -0700 (PDT) Received: from [192.168.0.69] (188-141-3-169.dynamic.upc.ie. [188.141.3.169]) by smtp.gmail.com with ESMTPSA id p125-20020a1c2983000000b00389cc36a3bfsm15630498wmp.6.2022.03.20.11.03.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Mar 2022 11:03:12 -0700 (PDT) Message-ID: Date: Sun, 20 Mar 2022 18:03:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v2 2/2] wcn36xx: Implement tx_rate reporting Content-Language: en-US From: Bryan O'Donoghue To: Edmond Gagnon , Kalle Valo Cc: Benjamin Li , Kalle Valo , "David S. Miller" , Jakub Kicinski , wcn36xx@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220318195804.4169686-1-egagnon@squareup.com> <20220318195804.4169686-3-egagnon@squareup.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/03/2022 13:21, Bryan O'Donoghue wrote: > On 18/03/2022 19:58, Edmond Gagnon wrote: >> +    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) > { >     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. --- bod