[dpdk-users] e1000 port stats
Van Haaren, Harry
harry.van.haaren at intel.com
Tue Dec 8 11:54:15 CET 2015
From: Sridhar.V.Iyer [mailto:sridhariyer at versa-networks.com]
> From gdb (KVM e1000), I see that the control is going to em_ethdev.c and not igb_ethdev.c (where the patch you provided applies). I added a similar patch in em_ethdev.c, but that didn’t help.
>
> However, when I apply the following patch, I seem to get the correct byte count:
>
> sridhar at sridhar-dev1:~/devel/15.2R1$ git diff
> diff --git a/usr/lib/DPDK/lib/librte_pmd_e1000/em_ethdev.c b/usr/lib/DPDK/lib/librte_pmd_e1000/em_ethdev.c
> index 8f9921c..83076ab 100644
> --- a/usr/lib/DPDK/lib/librte_pmd_e1000/em_ethdev.c
> +++ b/usr/lib/DPDK/lib/librte_pmd_e1000/em_ethdev.c
> @@ -828,8 +828,10 @@ eth_em_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *rte_stats)
> stats->roc += E1000_READ_REG(hw, E1000_ROC);
> stats->rjc += E1000_READ_REG(hw, E1000_RJC);
>
> - stats->tor += E1000_READ_REG(hw, E1000_TORH);
> - stats->tot += E1000_READ_REG(hw, E1000_TOTH);
> + stats->tor += E1000_READ_REG(hw, E1000_TORL);
> + stats->tor += ((uint64_t)E1000_READ_REG(hw, E1000_TORH) << 32);
> + stats->tot += E1000_READ_REG(hw, E1000_TOTL);
> + stats->tot += ((uint64_t)E1000_READ_REG(hw, E1000_TOTH) << 32);
>
> stats->tpr += E1000_READ_REG(hw, E1000_TPR);
> stats->tpt += E1000_READ_REG(hw, E1000_TPT);
This part looks good - fixes reading the register for em pf driver.
Send this snippet as a patch to dev at dpdk.org - it is a valuable addition. Perhaps wait until after 2.2 has been released - then a new development window will open for PMD patches like this one.
> @@ -882,8 +884,8 @@ eth_em_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *rte_stats)
>
> rte_stats->ipackets = stats->gprc;
> rte_stats->opackets = stats->gptc;
> - rte_stats->ibytes = stats->gorc;
> - rte_stats->obytes = stats->gotc;
> + rte_stats->ibytes = stats->tor;
> + rte_stats->obytes = stats->tot;
>
> GORC/GOTC account for good octets and TOR/TOT account for total octets. The packets are being delivered to the application, so they > aren’t being dropped.
This part makes an assumption that because you're not dropping packets now, means they will never be dropped. This is not a valid assumption: when a CPU gets overloaded packets will get dropped, which will invalidate the statistics: we need to find a better solution.
Cheers, -Harry
More information about the users
mailing list