From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
<bruce.richardson@intel.com>
Cc: <dev@dpdk.org>
Subject: RE: rte_eth_stats_get seems slow
Date: Sun, 27 Apr 2025 09:00:31 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9FC03@smartserver.smartshare.dk> (raw)
In-Reply-To: <20250426082352.260b9b5d@hermes.local>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, 26 April 2025 17.24
>
> On Fri, 25 Apr 2025 13:52:55 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > Bruce,
> >
> > rte_eth_stats_get() on Intel NICs seems slow to me.
> >
> > E.g. getting the stats on a single port takes ~132 us (~451,000 CPU
> cycles) using the igb driver, and ~50 us using the i40e driver.
> >
> > Referring to the igb driver source code [1], it's 44 calls to
> E1000_READ_REG(), so the math says that each one takes 3 us (~10,000
> CPU cycles).
> >
> > Is this expected behavior?
> >
> > It adds up, e.g. it takes a full millisecond to fetch the stats from
> eight ports using the igb driver.
> >
> > [1]:
> https://elixir.bootlin.com/dpdk/v24.11.1/source/drivers/net/e1000/igb_e
> thdev.c#L1724
> >
> >
> > Med venlig hilsen / Kind regards,
> > -Morten Brørup
> >
>
> Well reading each stat requires a PCI access. And PCI accesses are non-
> cached.
You're right, thank you for reminding me. I was caught by surprise that getting 7 counters took so long.
Perhaps reading 44 NIC registers over the PCI bus is required to calculate those summary counters. Or nobody cared to optimize this function to only read the necessary registers.
We periodically poll the ethdev stats in a management thread, and I noticed the duration because of the jitter it caused in that thread.
It's not a real problem. If it was, we could easily move it to a separate thread or poll the counters iteratively port by port, instead of all ports in one go.
A longwinded way of saying: Probably not worth optimizing. ;-)
prev parent reply other threads:[~2025-04-27 7:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 11:52 Morten Brørup
2025-04-26 15:23 ` Stephen Hemminger
2025-04-27 7:00 ` Morten Brørup [this message]
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=98CBD80474FA8B44BF855DF32C47DC35E9FC03@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.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).