From: Sridhar.V.Iyer [mailto:[email protected]] > 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
