Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp10165051rwd; Wed, 21 Jun 2023 17:49:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4gMdFmH9FC58ZbVcUc7peMfWmS7cM3ljj0QtxA4Ht+UgzIX4i30YWhf000xe8YEZpIyCtC X-Received: by 2002:a05:6a21:6811:b0:ff:8d85:9f24 with SMTP id wr17-20020a056a21681100b000ff8d859f24mr13722211pzb.50.1687394969914; Wed, 21 Jun 2023 17:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687394969; cv=none; d=google.com; s=arc-20160816; b=hS1cTTgxjaW3LPJelfftWiBm7ZKQaUJ1uHmbHk2x6lxuqe5NxLbaV152JDhLxdw+z+ M1nQHwhZ7x5SqKEEKGRXxjg4BM5f5GQEJW6LPuFJq7BE0MkQqSP4+dNpLmI3KK60EUCU hgaQ03OfCUIIXu9tcjqK4fEcYCFsCiAkTbQqOweCTsIyC06OR6I1VVwy8QSL5nXcLn7K xXB7H3UyuGv90SpJoucnuXGBCMyeakYnOeQz2T2qfrWJNnCam7jhVB1U4YkDOaWfWkYW UyZQ/YmNR01Rp+3n1NjRdWIJON+biMGF77MpbxpRY17lPKt0jRGgquSXbMb6IHq0WWy6 Qb8A== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=6s13wams8BJWBgk95FZOGcc7wwPa4JNtp+eFoSIFJsE=; b=IyPM8YLbTe+1xxaaE4CPJyLkYfix2rUzH1JJVQEb2vnx4W3dajJAmvG0v2Whxg2vJj 6Iaq+rrGJ/raA0FFOTv+6z3ivWmpCwqvvEvTuOaXew0uUPe14h9ZZdJuCSl/pHcgxhJp RAQWGU/GiVQmereSY67NHD43t4Hp/k/u23HdyPkwe1gdc+76TJHEE9rEvvth0qp2EVJj uqaEYu8iiddARK0sW/ogPtOyumsQhcXuLY4n7UIVDynUkjwP6coR6eEpzh/GQWn5FE6j du7wfq/Jp1wGmMeZmOGtKnyWz22juXjurmQruw9HZlj5MvUiIv5vhcDEQSZ/jxZ3FcLb l04w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CvdcRMGQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-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 x3-20020a170902fe8300b001aaf2ced278si1936778plm.430.2023.06.21.17.49.18; Wed, 21 Jun 2023 17:49:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=CvdcRMGQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-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 S229628AbjFVAXk (ORCPT + 99 others); Wed, 21 Jun 2023 20:23:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbjFVAXi (ORCPT ); Wed, 21 Jun 2023 20:23:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7BA710D2 for ; Wed, 21 Jun 2023 17:23:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 75DE361708 for ; Thu, 22 Jun 2023 00:23:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E0F5C433C8; Thu, 22 Jun 2023 00:23:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687393416; bh=Qv487yLictNg6YITz+WCFTi0FKLmRQ7tmU2yb4AYrYI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CvdcRMGQKyE8ZfCNSYZDtQmOp7qGeyRIh0DYHTw6aXSQQhF7Hw8s+u+5xkV8Oh5dL Vmw4KEjf/v+OYwwX0+hvhr21h65XG3sUu1yAUWwt98L0TOBIb9YvKDQ5sXokKt1zEB fUrlwzVDWHoBDVNbb8tUt/Nia+enRVXUIdHIiWijVswwXpjjeWc0SLZ2tGGeXJo3CM njXbr25iufGPDFPyFjlm7xmbC7ml/G5wDAu1AFEJTsWuwI2LZMOMh9RZHqWTDzzm6m TR577nO8gMG+ZkwxmpNCKCsigB9KEXrhdncMyMq3oVw41pJWuWuJ9Ccj8vWokh0919 3j9ynEWAziAJA== Date: Wed, 21 Jun 2023 17:23:35 -0700 From: Jakub Kicinski To: Jisheng Zhang Cc: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S . Miller" , Eric Dumazet , Paolo Abeni , Maxime Coquelin , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev, Simon Horman Subject: Re: [PATCH net-next v3 2/2] net: stmmac: use pcpu 64 bit statistics where necessary Message-ID: <20230621172335.33cf0dbb@kernel.org> In-Reply-To: <20230619165220.2501-3-jszhang@kernel.org> References: <20230619165220.2501-1-jszhang@kernel.org> <20230619165220.2501-3-jszhang@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 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-kernel@vger.kernel.org On Tue, 20 Jun 2023 00:52:20 +0800 Jisheng Zhang wrote: > +struct stmmac_pcpu_stats { > + struct u64_stats_sync syncp; > + /* per queue statistics */ > + struct stmmac_txq_stats txq_stats[MTL_MAX_TX_QUEUES]; > + struct stmmac_rxq_stats rxq_stats[MTL_MAX_RX_QUEUES]; > + /* device stats */ > + u64 rx_packets; > + u64 rx_bytes; > + u64 tx_packets; > + u64 tx_bytes; > + /* Tx/Rx IRQ Events */ > + u64 tx_pkt_n; > + u64 rx_pkt_n; > + u64 normal_irq_n; > + u64 rx_normal_irq_n; > + u64 napi_poll; > + u64 tx_normal_irq_n; > + u64 tx_clean; > + u64 tx_set_ic_bit; > + /* TSO */ > + u64 tx_tso_frames; > + u64 tx_tso_nfrags; AFAICT you're using the same structure and syncp for the stats updated from within IRQ and from xmit and NAPI. That's not safe. The documentation of u64_stats_sync suggests using _irqsave() variant for that case but really, I think you should split these stats up. The statistics which are counting packets / bytes should all go into respective queue structs, like struct stmmac_tx_queue, and have their own syncp per context (i.e. separate for xmit and completions if they can run in parallel). Having the counters in queue structs is much more common in drivers, it usually saves memory and allows reporting stats per queue. You can keep the per-cpu stats for IRQs if there's no IRQ struct, if you prefer. -- pw-bot: cr