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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AD3D9CFD37E for ; Tue, 25 Nov 2025 10:16:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 67ACE610A7; Tue, 25 Nov 2025 10:16:38 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id dVTNPZQFotRb; Tue, 25 Nov 2025 10:16:37 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A71446081E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1764065797; bh=TetX4l+WgxRtvj8B+Ro8HemF14SDJ4C0ROoIyMI5/Iw=; h=Date:From:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kPgIo6yuBLb3IwP+qQwlRogqPVgJ5e1x2+bhpq8CPUUrBKIbU0ZoBEDt+LeN5hmNB uKJvTIcN4DBqRXB9mMGMuYAferaR4ky+UH7t2Nxn0SD5zJcnoTk3bKKwxJrbDAXJM1 JlT5wL1uswsfWg7cNEw4+sd7D2MgK5jBgm5KQPDfQ1t2F5UmKqXgZR+m+WRganwIoi qrVaFhxPE1pAC0QCWzbVMRgmVtQAp2afL7r9N2Yvyq/9fcpBORmp0q96TqqYYcHz1C PP9N3UIeUqgg9ht/MDoVh4A7NJUXlVLhTfuygmCOXSra5FhqTS0C4boR3A8I+bMZIF 7dZD6nf6XDk2w== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp3.osuosl.org (Postfix) with ESMTP id A71446081E; Tue, 25 Nov 2025 10:16:37 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists1.osuosl.org (Postfix) with ESMTP id 45A18359 for ; Tue, 25 Nov 2025 10:16:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 376AE60F9D for ; Tue, 25 Nov 2025 10:16:36 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id IYmM2mfVOQHk for ; Tue, 25 Nov 2025 10:16:35 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp3.osuosl.org 493EE6072D DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 493EE6072D Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) by smtp3.osuosl.org (Postfix) with ESMTPS id 493EE6072D for ; Tue, 25 Nov 2025 10:16:35 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 0F0D440B81; Tue, 25 Nov 2025 10:16:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74DA6C4CEF1; Tue, 25 Nov 2025 10:16:33 +0000 (UTC) Date: Tue, 25 Nov 2025 10:16:31 +0000 From: Simon Horman To: Jacob Keller Cc: Aleksandr Loktionov , Alexander Lobakin , Tony Nguyen , Przemek Kitszel , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Message-ID: References: <20251120-jk-refactor-queue-stats-v4-0-6e8b0cea75cc@intel.com> <20251120-jk-refactor-queue-stats-v4-3-6e8b0cea75cc@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251120-jk-refactor-queue-stats-v4-3-6e8b0cea75cc@intel.com> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764065794; bh=7E9Z3qVoq+7y8LsemeRstJN9txhp8hp5rPn+YXZEZ7o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jHUsFJK0FOB2Rk0SKdN7vFe+USWSskei3ELRJ0LnIo6BxrL3WGUw4ALkDQthb7ePT L3ge5lhLDsOJdQ3vehsxLMqh+hhwAQEBV45+suPUVIA9EwkidBuSSUFZvpgampmO76 RjvmUGcbMjaM4OpwDoklT6xKbBD6D2vwi60pjJQ5pxjoCntRnrC85/+IWGP9HR8f9T OjJ+0665pc9yb4spxBoQi0pOfm6q8d9WyuJhUN94w3b+wmeWK37bak1zg7NJMeACkz htzWkTymrHR79fifxPe5KihV8Peg3iqaeO0nf9UwpGgvXktJ+Ar8kY4Xvbxe2UkPld 1lVpMdH9fU+bg== X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=jHUsFJK0 Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 3/6] ice: remove ice_q_stats struct and use struct_group X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Thu, Nov 20, 2025 at 12:20:43PM -0800, Jacob Keller wrote: > The ice_qp_reset_stats function resets the stats for all rings on a VSI. It > currently behaves differently for Tx and Rx rings. For Rx rings, it only > clears the rx_stats which do not include the pkt and byte counts. For Tx > rings and XDP rings, it clears only the pkt and byte counts. > > We could add extra memset calls to cover both the stats and relevant > tx/rx stats fields. Instead, lets convert stats into a struct_group which > contains both the pkts and bytes fields as well as the Tx or Rx stats, and > remove the ice_q_stats structure entirely. > > The only remaining user of ice_q_stats is the ice_q_stats_len function in > ice_ethtool.c, which just counts the number of fields. Replace this with a > simple multiplication by 2. I find this to be simpler to reason about than > relying on knowing the layout of the ice_q_stats structure. > > Now that the stats field of the ice_ring_stats covers all of the statistic > values, the ice_qp_reset_stats function will properly zero out all of the > fields. > > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Jacob Keller I agree this is both more consistent and cleaner. I do feel there might be a yet cleaner way to handle things in place of multiplication by 2. But I can't think of such a way at this time. Reviewed-by: Simon Horman From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F397CA4E for ; Tue, 25 Nov 2025 10:16:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764065795; cv=none; b=kASYz7HEgpepCjk5lnjgS5SErSmDD1Q5rIk95bWrRlN8+ssWnVLkUviN9gDqnXM3rOEto+4jbkAHAP3tPsHaUjjc8Y+KszmZDDR5UQfyngrh1bkuAGJqR6y89np7C8HaGXqpV/oU+5p6w7adGrVIY027I4TzvxZwcoEkvtlpXdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764065795; c=relaxed/simple; bh=7E9Z3qVoq+7y8LsemeRstJN9txhp8hp5rPn+YXZEZ7o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lsvq0utNfbL8KjKMK8dPldz9KJSXdG2x3jddDbLst87UULJcwv82Qo+lEm4YVEdclqlGpmIlGlI0dtWWJvqrfO5lSZbXq2ckPlP5F7Fbt/d7o6SgCWK7PlBRNiNGLz+0hF1OFr2pxmSlc+bL4ZB1Topuvw4KZYlIaNAIXjtQTXU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jHUsFJK0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jHUsFJK0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74DA6C4CEF1; Tue, 25 Nov 2025 10:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764065794; bh=7E9Z3qVoq+7y8LsemeRstJN9txhp8hp5rPn+YXZEZ7o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jHUsFJK0FOB2Rk0SKdN7vFe+USWSskei3ELRJ0LnIo6BxrL3WGUw4ALkDQthb7ePT L3ge5lhLDsOJdQ3vehsxLMqh+hhwAQEBV45+suPUVIA9EwkidBuSSUFZvpgampmO76 RjvmUGcbMjaM4OpwDoklT6xKbBD6D2vwi60pjJQ5pxjoCntRnrC85/+IWGP9HR8f9T OjJ+0665pc9yb4spxBoQi0pOfm6q8d9WyuJhUN94w3b+wmeWK37bak1zg7NJMeACkz htzWkTymrHR79fifxPe5KihV8Peg3iqaeO0nf9UwpGgvXktJ+Ar8kY4Xvbxe2UkPld 1lVpMdH9fU+bg== Date: Tue, 25 Nov 2025 10:16:31 +0000 From: Simon Horman To: Jacob Keller Cc: Aleksandr Loktionov , Alexander Lobakin , Tony Nguyen , Przemek Kitszel , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Subject: Re: [PATCH iwl-next v4 3/6] ice: remove ice_q_stats struct and use struct_group Message-ID: References: <20251120-jk-refactor-queue-stats-v4-0-6e8b0cea75cc@intel.com> <20251120-jk-refactor-queue-stats-v4-3-6e8b0cea75cc@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251120-jk-refactor-queue-stats-v4-3-6e8b0cea75cc@intel.com> On Thu, Nov 20, 2025 at 12:20:43PM -0800, Jacob Keller wrote: > The ice_qp_reset_stats function resets the stats for all rings on a VSI. It > currently behaves differently for Tx and Rx rings. For Rx rings, it only > clears the rx_stats which do not include the pkt and byte counts. For Tx > rings and XDP rings, it clears only the pkt and byte counts. > > We could add extra memset calls to cover both the stats and relevant > tx/rx stats fields. Instead, lets convert stats into a struct_group which > contains both the pkts and bytes fields as well as the Tx or Rx stats, and > remove the ice_q_stats structure entirely. > > The only remaining user of ice_q_stats is the ice_q_stats_len function in > ice_ethtool.c, which just counts the number of fields. Replace this with a > simple multiplication by 2. I find this to be simpler to reason about than > relying on knowing the layout of the ice_q_stats structure. > > Now that the stats field of the ice_ring_stats covers all of the statistic > values, the ice_qp_reset_stats function will properly zero out all of the > fields. > > Reviewed-by: Aleksandr Loktionov > Signed-off-by: Jacob Keller I agree this is both more consistent and cleaner. I do feel there might be a yet cleaner way to handle things in place of multiplication by 2. But I can't think of such a way at this time. Reviewed-by: Simon Horman