DPDK patches and discussions
 help / color / mirror / Atom feed
From: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
To: Morten Brorup <mb@smartsharesystems.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] NTT TechnoCross roadmap for 21.02
Date: Thu, 26 Nov 2020 10:20:49 +0900
Message-ID: <20201126102049.C6F8.17218CA3@ntt-tx.co.jp_1> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6144E@smartserver.smartshare.dk>

Hello Morten,

Thanks for your giving me your valuable feedback.
Please see inline tagged with [Hideyuki].

> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Hideyuki Yamashita
> > Sent: Wednesday, November 25, 2020 6:40 AM
> > 
> > Hello,
> > 
> > Following are the work items planned for 21.02 from NTT TechnoCross:
> > I will try to post patch set after 20.11 is released.
> > 
> > ---
> > 1) Introduce API stats function
> > In general, DPDK application consumes CPU usage because it polls
> > incoming packets using rx_burst API in infinite loop.
> > This makes difficult to estimate how much CPU usage is really
> > used to send/receive packets by the DPDK application.
> > 
> > For example, even if no incoming packets arriving, CPU usage
> > looks nearly 100% when observed by top command.
> > 
> > It is beneficial if developers can observe real CPU usage of the
> > DPDK application.
> > Such information can be exported to monitoring application like
> > prometheus/graphana and shows CPU usage graphically.
> 
> This would be very beneficial.
> 
> Unfortunately, this seems to be not so simple for applications like the SmartShare StraightShaper, which is not a simple packet forwarding application, but has multiple pipeline stages. Our application also keeps some packets in queues for shaping purposes, so the number of packets transmitted does not match the number of packets received within some time interval.

[Hideyuki]
Thanks.
I share the same view with you.
DPDK application varies and not all applications "simply forward
incoming packets".
So I think maybe target applications are limited.
Though I believe this enhancement is useful for those applications still.

> > 
> > To achieve above, this patch set provides apistats functionality.
> > apistats provides the followiing two counters for each lcore.
> > - rx_burst_counts[RTE_MAX_LCORE]
> > - tx_burst_counts[RTE_MAX_LCORE]
> > Those accumulates rx_burst/tx_burst counts since the application
> > starts.
> > 
> > By using those values, developers can roughly estimate CPU usage.
> > Let us assume a DPDK application is simply forwarding packets.
> > It calls tx_burst only if it receive packets.
> > If rx_burst_counts=1000 and tx_burst_count=1000 during certain
> > period of time, one can assume CPU usage is 100%.
> > If rx_burst_counts=1000 and tx_burst_count=100 during certain
> > period of time, one can assume CPU usage is 10%.
> > Here we assumes that tx_burst_count equals counts which rx_burst
> > function
> > really receives incoming packets.
> 
> I am not sure I understand what is being counted in these counters. The number of packets in the bursts, or the number of invocations of the rx_burst/tx_burst functions.
[Hideyuki]
Latter.
I think exsisting mechanism may store number of packets.
(maybe I am wrong)

> 
> Here are some data from our purpose built profiler, illustrating how nonlinear this really is. These data are from a SmartShare appliance in live production at an ISP. I hope you find it useful:
> 
> Rx_burst uses ca. 40 CPU cycles if there are no packets, ca. 260 cycles if there is one packet, and down to ca. 40 cycles per packet for a burst of many packets.
> 
> Tx_burst uses ca. 350 cycles for one packet, and down to ca. 20 cycles per packet for a burst of many packets.
[Hideyuki]
Thanks for your sharing useful info!
Ah, I realized that consumption of CPU cycle is not linear like
following.

0 packet receive  -> 0 cycle
1 packet receive ->  1 cycle
10 packets receive -> 10 cycle

It is very interesting.
Thanks for your information.
I will keep your information in my mind.

> One of our intermediate pipeline stages (which not is not receiving or transmitting packets, only processing them) uses ca. 150 cycles for a burst of one packet, and down to ca. 110 cycles for a burst of many packets.

> 
> Nevertheless, your suggested API might be usable by simple ingress->routing->egress applications. So don’t let me discourage you!
[Hideyuki]
Thanks for your supporting my idea.
Yes, I agree with you that for simple forwarding applications, 
this enhancement might be useful to monitor the cpu usage "roughly".

BR,
Hideyuki Yamashita
NTT TechnoCross

> 



  reply	other threads:[~2020-11-26  1:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11  4:18 [dpdk-dev] Arm roadmap for 20.11 Honnappa Nagarahalli
2020-11-25  5:39 ` [dpdk-dev] NTT TechnoCross roadmap for 21.02 Hideyuki Yamashita
2020-11-25 11:01   ` Morten Brørup
2020-11-26  1:20     ` Hideyuki Yamashita [this message]
2020-11-29 14:43       ` Baruch Even
2020-12-01  0:40         ` Hideyuki Yamashita
2020-12-01  5:01           ` [dpdk-dev] Basic question about where to write config for optional feature Hideyuki Yamashita
2020-12-01  9:37             ` Bruce Richardson

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=20201126102049.C6F8.17218CA3@ntt-tx.co.jp_1 \
    --to=yamashita.hideyuki@ntt-tx.co.jp \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git