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 A1EF412B8B for ; Sat, 7 Sep 2024 02:03:45 +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=1725674625; cv=none; b=Mzj6WkwlQZN55AwX+g7m8pMKDf1NiPmDyDKF3zrFITgitIheTuyX3d6aPVgk4y8yclS/vfCJybl30KmLZ1Bi7RrQgMlwfDHFKRDvylvETd1b4wSFDhCBBVW0AAP0UwLhIp5f2dm/nogsVQMx9zQY9USy4cgVXPrvUsdbj5bHOT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725674625; c=relaxed/simple; bh=kotF0tEiYS5fhiJjeu9Pz2HkYeeYw4uk8UEexsEDswo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WD1CNkcOIu5Pkwd5rKajdAWMoKtXHxX8xGSG02EJvtU9pjgLaxbyX8eqRWom0xNQVdFOoVIdER+1caxo007CnLrhDLEImYDp+Av0FZ0Taqt5wy7o4+BLaYRwOAJowN28wZCy0TzPhbaoC+MhG01k9x1GnAX3y5aRErMlXLvwmUE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rEnfWaYD; 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="rEnfWaYD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D99C2C4CEC6; Sat, 7 Sep 2024 02:03:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725674625; bh=kotF0tEiYS5fhiJjeu9Pz2HkYeeYw4uk8UEexsEDswo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rEnfWaYDrZueCIGxZOBGifYECLRFwN4d/tM8v1xViqFTrv9/ApbmCV2qED2xDCIby nySLYiPCYImCT3+7jbfpepo95+wgd0RgtvWGlhvD1lLf8DpVka/cvxx/ZcfQbo8+43 xARCKD6ANJ/tk8P0Lu1DUA/KaQreElD65O6oHqXPbFxvTi1ss7eIgTjdv1PXbYSLCd SDMVLAkVHmUd3w0hKAG5QtT/pmPyc4x4M0VAs4XtDcpvM/7a2YKsw8BtUCldAhuLIe u+WMDD22dycsW/FvBEPS00ac2UuFRjG6Xqo+cInoPtHA20ChZzvbLBJdiuYtFB9JPN O6tiwUKOLM3rw== Date: Fri, 6 Sep 2024 19:03:44 -0700 From: Jakub Kicinski To: Cc: , , , , Edward Cree , , , Subject: Re: [PATCH v2 net-next 6/6] sfc: add per-queue RX and TX bytes stats Message-ID: <20240906190344.2573fdd2@kernel.org> In-Reply-To: References: 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-Transfer-Encoding: 7bit On Thu, 5 Sep 2024 16:41:35 +0100 edward.cree@amd.com wrote: > * @tx_packets: Number of packets sent since this struct was created I think it's number of packets "enqueued", but the doc says: name: tx-packets doc: | Number of wire packets successfully sent. Packet is considered to be successfully sent once it is in device memory (usually this means the device has issued a DMA completion for the packet). Not the end of the world if you prefer to keep as is, but if so maybe just acknowledge in commit message or a code comment that this is not 100% in line with the definition? > + * @tx_bytes: Number of bytes sent since this struct was created. For TSO, > + * counts the superframe size, not the sizes of generated frames on the > + * wire (i.e. the headers are only counted once) Hm. Hm. This is technically not documented but my intuition is that tx_bytes should count wire bytes. tx_packets counts segments / wire packets, looking at ef100_tx.c qstats "bytes" should be the same kind of bytes as counted by the MAC. That way we can hopefully see how many packets "enter" the device from queues, and how many "leave" via the MAC. Helping to calculate drops at various stages. That matters more for packets than bytes, but still.. -- pw-bot: cr