From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B97EE13C8E8 for ; Mon, 3 Jun 2024 21:50:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717451422; cv=none; b=jgB52dIovpPbJvx7SjR+Vllq41fc0HYURTfDvehMTdf/kZM6zjLSBzl7DT0aNjRdAcVkEUfeeVqMsjVwsO7KZIpKkDF1E35ak9ixoYwbYEc5zKEaAr0vUXajyn/fqrknX0cESDNNjNcti45eLsdFnWAVSPZ7GPmWvLJRmbKlnLY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717451422; c=relaxed/simple; bh=jQETexEejuJ/VAhqGR17NqtTNOI2iX3uh3MiiJifQJw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mNPKRQ8y1vgh3SFjRAbJzDUx857ssXuxb1DQjfTyWugoncEjBpgw5/Wuf2J1p7rRCEg1Lkrgch9DJtTz8B9kOEea6hpUOgqV0ri+wdEivjO0VEtKiRLCCgYYiY1TscECwBKSX+BdN2gClgHGgPVfGGK+v3FU4AvKx0iuzNjYMk4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fastly.com; spf=pass smtp.mailfrom=fastly.com; dkim=pass (1024-bit key) header.d=fastly.com header.i=@fastly.com header.b=qYHIkmV7; arc=none smtp.client-ip=209.85.160.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fastly.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fastly.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=fastly.com header.i=@fastly.com header.b="qYHIkmV7" Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-245435c02e1so2650270fac.0 for ; Mon, 03 Jun 2024 14:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1717451420; x=1718056220; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=ZziI2v+i5IGjIKB8mlMLCYTpY3QI/oZfBdzVvUiG3pw=; b=qYHIkmV7eR++1Jk87ogdHtjoEcI5ih1MRWLIA3J5MvcNcogA1uejXla+1L9xhQnePr FEOVvJIyyqXHADsMR8Ry+0w6+vaws0JTHn2IVjk9hz8K3AAw4vWrM4OXu2bp00mp0sO4 uTIFOU10bmKcXBYNyAKa7ZM3lX3VldG3zpsG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717451420; x=1718056220; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZziI2v+i5IGjIKB8mlMLCYTpY3QI/oZfBdzVvUiG3pw=; b=BJVdJs3DFs8bA63jkmY3H+KpU9ULLDLD0QFfkvj/2jauvezxoV2dEU5Xbzb34F0tmF 6X5RfUfm0bOu/vMKce32D5BhReDl9MFBu8gMMVgJKWdMuXUaI0yCMql6xHcR80xSWQEG xMNu7rRQN5o4DmgagBQ3qY0QGGO0J03MHgqORIwqKtx1jeWAgHOguURpLZDRVNhlHjq0 M1y/WM1N5EabLw/UjnlLvjPSiuVIOOt4ZYp66P4YtGSjCzBpBk3qFP5nAYcVlrVSxE1J 2V7ptV1uuWza6DSyBJVvlnlRFRrkta1tTGH1CEmXE9OTtlbybZPJjh4b8/6v4N6r5Wop LiMw== X-Forwarded-Encrypted: i=1; AJvYcCVw+hkN4wBv8qJDI9Qx74TCkf+GfsevKZkzhZu/oEcOuSgZAQ8bvfk/x2xpI4ahReU0W/ZOF0E91gxO8Dzt6EzGj1dsvifv X-Gm-Message-State: AOJu0YxgVz96f68NTUZXAfYu8b8olwfcYJeFsmI5rywbF7Et4vtcznvV ubAn045sKUDnA5jmawm0tBZU77+Z4JCkNLL24LdyDCPPiDOUsJYUMSdf8DHA6gY= X-Google-Smtp-Source: AGHT+IExaHxmG4w13jF3tz6Wk1yFelIINj206SDMlX2noHX3ytwoyWzS/nopw4WIncY0zt7vHmmxvA== X-Received: by 2002:a05:6871:88b:b0:24c:ae57:b4ab with SMTP id 586e51a60fabf-2508b80dc81mr12624917fac.11.1717451419771; Mon, 03 Jun 2024 14:50:19 -0700 (PDT) Received: from LQ3V64L9R2 (c-24-6-151-244.hsd1.ca.comcast.net. [24.6.151.244]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70242b09133sm6158526b3a.178.2024.06.03.14.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jun 2024 14:50:19 -0700 (PDT) Date: Mon, 3 Jun 2024 14:50:16 -0700 From: Joe Damato To: Tariq Toukan Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, nalramli@fastly.com, Saeed Mahameed , Leon Romanovsky , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , "open list:MELLANOX MLX5 core VPI driver" , Tariq Toukan Subject: Re: [RFC net-next v3 2/2] net/mlx5e: Add per queue netdev-genl stats Message-ID: Mail-Followup-To: Joe Damato , Tariq Toukan , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, nalramli@fastly.com, Saeed Mahameed , Leon Romanovsky , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , "open list:MELLANOX MLX5 core VPI driver" , Tariq Toukan References: <20240529031628.324117-1-jdamato@fastly.com> <20240529031628.324117-3-jdamato@fastly.com> <5b3a0f6a-5a03-45d7-ab10-1f1ba25504d3@gmail.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: On Tue, Jun 04, 2024 at 12:36:16AM +0300, Tariq Toukan wrote: > > > On 03/06/2024 22:22, Joe Damato wrote: > > On Mon, Jun 03, 2024 at 02:11:14PM +0300, Tariq Toukan wrote: > > > > > ... > > > > > > > I still don't really like this design, so I gave some more thought on > > > this... > > > > > > I think we should come up with a new mapping array under priv, that maps i > > > (from real_num_tx_queues) to the matching sq_stats struct. > > > This array would be maintained in the channels open/close functions, > > > similarly to priv->txq2sq. > > > > > > Then, we would not calculate the mapping per call, but just get the proper > > > pointer from the array. This eases the handling of htb and ptp queues, which > > > were missed in your txq_ix_to_chtc_ix(). > > > > Maybe I am just getting way off track here, but I noticed this in > > drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c in > > set_pflag_tx_port_ts: > > > > if (!err) > > priv->tx_ptp_opened = true; > > > > but what if enable is false, meaning the user is disabling ptp via > > ethtool? > > > > This bool field under priv acts as a flag, means: ptp was ever opened. > It's the same idea as max_opened_tc, but with boolean instead of numeric. OK, but then to avoid double counting ptp, I suppose we don't output ptp stats in base and only when the correct txq_ix is passed in to the tx stats function which refers to the PTP queue? It's either that or we dont include ptp's sqstats in the txq2sq_stats mapping you've proposed, if I understand correctly.