DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Junyu Jiang <junyux.jiang@intel.com>, dev@dpdk.org
Cc: Jeff Guo <jia.guo@intel.com>, Beilei Xing <beilei.xing@intel.com>,
	stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3] net/i40e: fix incorrect byte counters
Date: Mon, 21 Sep 2020 12:41:34 +0100	[thread overview]
Message-ID: <b0eefbab-2c5e-a939-a685-1e838147692e@intel.com> (raw)
In-Reply-To: <20200921095901.7089-1-junyux.jiang@intel.com>

On 9/21/2020 10:59 AM, Junyu Jiang wrote:
> This patch fixed the issue that rx/tx bytes statistics counters
> overflowed on 48 bit limitation by enlarging the limitation.
> 
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Junyu Jiang <junyux.jiang@intel.com>
> ---
>   doc/guides/nics/i40e.rst       |  7 +++++++
>   drivers/net/i40e/i40e_ethdev.c | 32 ++++++++++++++++++++++++++++++++
>   drivers/net/i40e/i40e_ethdev.h |  9 +++++++++
>   3 files changed, 48 insertions(+)
> 
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
> index b7430f6c4..4baa58be6 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -830,3 +830,10 @@ Tx bytes affected by the link status change
>   
>   For firmware versions prior to 6.01 for X710 series and 3.33 for X722 series, the tx_bytes statistics data is affected by
>   the link down event. Each time the link status changes to down, the tx_bytes decreases 110 bytes.
> +
> +RX/TX statistics may be incorrect when register overflowed
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The rx_bytes/tx_bytes statistics register is 48 bit length. Although this limitation is enlarged to 64 bit length
> +on the software side, but there is no way to detect if the overflow occurred more than once. So rx_bytes/tx_bytes
> +statistics data is correct when statistics are updated at least once between two overflows.
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 563f21d9d..212338ef0 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -3052,6 +3052,19 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
>   	return ret;
>   }
>   
> +static void
> +i40e_stat_update_48_in_64(uint64_t *new_bytes,
> +			  uint64_t *prev_bytes,
> +			  bool offset_loaded)
> +{
> +	if (offset_loaded) {
> +		if (I40E_RXTX_BYTES_L_48_BIT(*prev_bytes) > *new_bytes)
> +			*new_bytes += (uint64_t)1 << I40E_48_BIT_WIDTH;
> +		*new_bytes += I40E_RXTX_BYTES_H_16_BIT(*prev_bytes);
> +	}
> +	*prev_bytes = *new_bytes;
> +}
> +

I was more thinking reading stats and extending in same function, 
instead of extracting the extending part into its own function, like:

static void
i40e_stat_update_48_in_64(struct i40e_hw *hw,
		uint32_t hireg,
		uint32_t loreg,
		bool offset_loaded,
		uint64_t *offset,
		uint64_t *stat,
		uint64_t *prev_bytes) {

	i40e_stat_update_48(...)

	/* logic to convert 'stat' to 64 bits */
}

Does it make sense?

  reply	other threads:[~2020-09-21 11:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10  1:54 [dpdk-dev] [PATCH] " Junyu Jiang
2020-09-10  2:18 ` [dpdk-dev] [dpdk-stable] " Han, YingyaX
2020-09-10  5:58   ` Guo, Jia
2020-09-10  6:45     ` Jiang, JunyuX
2020-09-16  1:51 ` [dpdk-dev] [PATCH v2] " Junyu Jiang
2020-09-16  2:39   ` [dpdk-dev] [dpdk-stable] " Han, YingyaX
2020-09-16  5:21   ` [dpdk-dev] " Guo, Jia
2020-09-16  5:50     ` Zhang, Qi Z
2020-09-16 12:30   ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2020-09-18  3:44     ` Jiang, JunyuX
2020-09-18  9:23       ` Igor Ryzhov
2020-09-18 13:42         ` Ferruh Yigit
2020-09-21  1:55           ` Jiang, JunyuX
2020-09-18 13:37       ` Ferruh Yigit
2020-09-21  9:59 ` [dpdk-dev] [PATCH v3] " Junyu Jiang
2020-09-21 11:41   ` Ferruh Yigit [this message]
2020-09-22  7:37 ` [dpdk-dev] [PATCH v4] " Junyu Jiang
2020-09-22  9:06   ` Ferruh Yigit
2020-09-22  9:19 ` [dpdk-dev] [PATCH v5] " Junyu Jiang
2020-09-22 12:59   ` Zhang, Qi Z

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0eefbab-2c5e-a939-a685-1e838147692e@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jia.guo@intel.com \
    --cc=junyux.jiang@intel.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).