DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xing, Beilei" <beilei.xing@intel.com>
To: "Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/i40e: exclude LLDP packet count
Date: Mon, 11 Dec 2017 08:49:54 +0000	[thread overview]
Message-ID: <94479800C636CB44BD422CB454846E013207E1D4@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <1512437375-17322-1-git-send-email-qi.z.zhang@intel.com>


> -----Original Message-----
> From: Zhang, Qi Z
> Sent: Tuesday, December 5, 2017 9:30 AM
> To: Xing, Beilei <beilei.xing@intel.com>
> Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> Subject: [PATCH] net/i40e: exclude LLDP packet count
> 
> When use port stats register to calcuate the packet count,  LLDP packets are

Patch looks OK for me except some typos.
calcuate -> calculate

> counted in statistics which is not expected, the patch exclude this number
> from total number.
> 
> Fixes: 763de290cbd1 ("net/i40e: fix packet count for PF") Cc stable@dpdk.org
> 
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
>  drivers/net/i40e/i40e_ethdev.c | 58
> +++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 811cc9f..4cbb259 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2531,6 +2531,22 @@ i40e_read_stats_registers(struct i40e_pf *pf,
> struct i40e_hw *hw)
>  			    pf->offset_loaded,
>  			    &pf->internal_stats_offset.rx_broadcast,
>  			    &pf->internal_stats.rx_broadcast);
> +	/* Get total internal tx packet count */
> +	i40e_stat_update_48(hw, I40E_GLV_UPTCH(hw->port),
> +			    I40E_GLV_UPTCL(hw->port),
> +			    pf->offset_loaded,
> +			    &pf->internal_stats_offset.tx_unicast,
> +			    &pf->internal_stats.tx_unicast);
> +	i40e_stat_update_48(hw, I40E_GLV_MPTCH(hw->port),
> +			    I40E_GLV_MPTCL(hw->port),
> +			    pf->offset_loaded,
> +			    &pf->internal_stats_offset.tx_multicast,
> +			    &pf->internal_stats.tx_multicast);
> +	i40e_stat_update_48(hw, I40E_GLV_BPTCH(hw->port),
> +			    I40E_GLV_BPTCL(hw->port),
> +			    pf->offset_loaded,
> +			    &pf->internal_stats_offset.tx_broadcast,
> +			    &pf->internal_stats.tx_broadcast);
> 
>  	/* exclude CRC size */
>  	pf->internal_stats.rx_bytes -= (pf->internal_stats.rx_unicast + @@ -
> 2560,16 +2576,32 @@ i40e_read_stats_registers(struct i40e_pf *pf, struct
> i40e_hw *hw)
>  	ns->eth.rx_bytes -= (ns->eth.rx_unicast + ns->eth.rx_multicast +
>  		ns->eth.rx_broadcast) * ETHER_CRC_LEN;
> 
> -	/* Workaround: it is possible I40E_GLV_GORCH[H/L] is updated
> before
> +	/* exlude internal rx bytes

exclude

> +	 * Workaround: it is possible I40E_GLV_GORCH[H/L] is updated
> before
>  	 * I40E_GLPRT_GORCH[H/L], so there is a small window that cause
> negtive

negative

>  	 * value.
> +	 * same to I40E_GLV_UPRC[H/L], I40E_GLV_MPRC[H/L],
> I40E_GLV_BPRC[H/L].
>  	 */
>  	if (ns->eth.rx_bytes < pf->internal_stats.rx_bytes)
>  		ns->eth.rx_bytes = 0;
> -	/* exlude internal rx bytes */
>  	else
>  		ns->eth.rx_bytes -= pf->internal_stats.rx_bytes;
> 
> +	if (ns->eth.rx_unicast < pf->internal_stats.rx_unicast)
> +		ns->eth.rx_unicast = 0;
> +	else
> +		ns->eth.rx_unicast -= pf->internal_stats.rx_unicast;
> +
> +	if (ns->eth.rx_multicast < pf->internal_stats.rx_multicast)
> +		ns->eth.rx_multicast = 0;
> +	else
> +		ns->eth.rx_multicast -= pf->internal_stats.rx_multicast;
> +
> +	if (ns->eth.rx_broadcast < pf->internal_stats.rx_broadcast)
> +		ns->eth.rx_broadcast = 0;
> +	else
> +		ns->eth.rx_broadcast -= pf->internal_stats.rx_broadcast;
> +
>  	i40e_stat_update_32(hw, I40E_GLPRT_RDPC(hw->port),
>  			    pf->offset_loaded, &os->eth.rx_discards,
>  			    &ns->eth.rx_discards);
> @@ -2598,12 +2630,32 @@ i40e_read_stats_registers(struct i40e_pf *pf,
> struct i40e_hw *hw)
>  	ns->eth.tx_bytes -= (ns->eth.tx_unicast + ns->eth.tx_multicast +
>  		ns->eth.tx_broadcast) * ETHER_CRC_LEN;
> 
> -	/* exclude internal tx bytes */
> +	/* exlude internal tx bytes

exclude

> +	 * Workaround: it is possible I40E_GLV_GOTCH[H/L] is updated
> before
> +	 * I40E_GLPRT_GOTCH[H/L], so there is a small window that cause
> negtive

negative.

> +	 * value.
> +	 * same to I40E_GLV_UPTC[H/L], I40E_GLV_MPTC[H/L],
> I40E_GLV_BPTC[H/L].
> +	 */
>  	if (ns->eth.tx_bytes < pf->internal_stats.tx_bytes)
>  		ns->eth.tx_bytes = 0;
>  	else
>  		ns->eth.tx_bytes -= pf->internal_stats.tx_bytes;
> 
> +	if (ns->eth.tx_unicast < pf->internal_stats.tx_unicast)
> +		ns->eth.tx_unicast = 0;
> +	else
> +		ns->eth.tx_unicast -= pf->internal_stats.tx_unicast;
> +
> +	if (ns->eth.tx_multicast < pf->internal_stats.tx_multicast)
> +		ns->eth.tx_multicast = 0;
> +	else
> +		ns->eth.tx_multicast -= pf->internal_stats.tx_multicast;
> +
> +	if (ns->eth.tx_broadcast < pf->internal_stats.tx_broadcast)
> +		ns->eth.tx_broadcast = 0;
> +	else
> +		ns->eth.tx_broadcast -= pf->internal_stats.tx_broadcast;
> +
>  	/* GLPRT_TEPC not supported */
> 
>  	/* additional port specific stats */
> --
> 2.7.4

  reply	other threads:[~2017-12-11  8:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05  1:29 Qi Zhang
2017-12-11  8:49 ` Xing, Beilei [this message]
2017-12-11  8:51   ` 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=94479800C636CB44BD422CB454846E013207E1D4@SHSMSX101.ccr.corp.intel.com \
    --to=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    /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).