[dpdk-dev] NTT TechnoCross roadmap for 21.02

Hideyuki Yamashita yamashita.hideyuki at ntt-tx.co.jp
Tue Dec 1 01:40:37 CET 2020


Hello Baruch,

Thanks for your feedback to our roadmap.
And thanks for your sharing your thought.

As you pointed out, I agree that there are different ways 
to measure/estimate cpu usage.
I think my proposal is "roughly way".

I understand that there are some interests on this enhancement.
(measure cpu usage)
I think it is good.

Anyway I will start preparing patch itself first
and want to hear "how others think about my idea/proposal".

Thanks!

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hi,
> 
> The way we do this accounting is completely different, it depends on having
> logic that says you are in idle state and counts the start and stop time
> from entering to exiting the idle function. It then subtracts the idle time
> from the stat period time and that gives you the time (also percentage)
> that you spend idle polling. The idle loop at the most basic form only does
> the polling and excludes time when there were packets received (or other
> things your app does not connected to DPDK on the same core).
> 
> Using the counters for the number of polls is going to be harder to use and
> far less effective.
> 
> Baruch
> 
> 
> 
> On Thu, Nov 26, 2020 at 3:21 AM Hideyuki Yamashita <
> yamashita.hideyuki at ntt-tx.co.jp> wrote:
> 
> > Hello Morten,
> >
> > Thanks for your giving me your valuable feedback.
> > Please see inline tagged with [Hideyuki].
> >
> > > > From: dev [mailto:dev-bounces at 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
> >
> > >
> >
> >
> >
> 
> -- 
> Baruch Even
> Platform Team Manager at WekaIO
> +972-54-2577223
>  *?*  baruch at weka.io  *?* https://www.weka.io/
> <https://www.weka.io/?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature>
> The World's Fastest File System
> <https://www.weka.io/promo/2020-10-esg-validation-paper/?utm_source=WiseStamp&utm_medium=email&utm_term=&utm_content=&utm_campaign=signature>





More information about the dev mailing list