DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
Cc: "Hunt, David" <david.hunt@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/5] add apistats function
Date: Thu, 24 Dec 2020 12:35:31 +0000	[thread overview]
Message-ID: <MWHPR11MB15817212252642960D0AC86C90DD0@MWHPR11MB1581.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20201224154349.9D9A.17218CA3@ntt-tx.co.jp>

> Thanks for your comments.
> I know you kindly provided many valuable comments though I reply the
> following first because I think it is important that my idea/proposal is
> acceptable or not first.
> > Sharing an alternate approach, if RX-TX callbacks are enabled in DPDK (which
> is by default). One can register a callback handler to update counters with the
> following information as `port-queue pair, lcoreid, total rx burst request, total
> empty rx burst, 1-8 pks, 9-16 pkts, 16-32 pkts`. Callback handlers can be
> selectively enabled or disabled too.
> >
> > Can you please help me understand how `rte_apistats` would be different or
> pros of having it as library (that needs to be added to linking and running in
> case of using DPDK applications)?
> You are correct.
> Application can do that by using callback of rx_burst/tx_burst.
> But needs to modify/add the code for RX/TX process logic.

No the RX or TX application logic is not modified as the call back registration is done once right after port_init.

> Point of my patchset is couting is done by library so that APP only needs to
> "retrieve/read" those data if needed (especially for existing applications).

As mentioned in the other patchset the library function is enabled through and not conditionally built. Any application which is built with this patch set will be forced to invoke the calls.

> I think it makes some developers happy becaseu it is relatively easy to measure
> "how cpu core is bysy" easily.

Not sure what do you mean, as there 2 factors which conflicts
1. there are existing uses cases and examples like power, metric, telemetry all uses RX/TX callbacks which does the same.
2. The current logic only helps in RX/TX cores and not other cores. So in case of pipeline model there are only a couple of RX or TX threads.

> (I admit relatively rough measurement though. I think it is trade-off)
> What do you think?

If I consider RX calls there are 3 main metrics
1. How many times RX is invoked.
2. How many times RX returns with `0` packets
3. How many times RX returns with `> 0` packets.

With these values in the current logic you are trying to deduct actual CPU RX usage by `useful work = number of times `> 0` / total RX calls`

As a end user I will always be happy to see telemetry data as `from time t1 to t2, 
1. how many times per second on average RX calls were made.
2. how many times per second on average The calls returned packets in range of 1-4, 5-8, 9-16, 17 and more  `

Current logic is not trying to address this problem. With my current understanding I am not convinced that one needs yet another library when the same can be done either with `RX/TX callback`


  reply	other threads:[~2020-12-24 12:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  7:51 Hideyuki Yamashita
2020-12-04  7:51 ` [dpdk-dev] [PATCH 1/5] maintainers: update maintainers file for apistats Hideyuki Yamashita
2020-12-05 13:27   ` Varghese, Vipin
2020-12-24  6:36     ` Hideyuki Yamashita
2020-12-04  7:51 ` [dpdk-dev] [PATCH 2/5] app/proc-info: add to use apistats Hideyuki Yamashita
2020-12-05 13:15   ` Varghese, Vipin
2020-12-04  7:51 ` [dpdk-dev] [PATCH 3/5] app/test-pmd: " Hideyuki Yamashita
2020-12-05 13:04   ` Varghese, Vipin
2020-12-04  7:51 ` [dpdk-dev] [PATCH 4/5] docs: add description of apistats parameter into proc-info Hideyuki Yamashita
2020-12-05 13:02   ` Varghese, Vipin
2020-12-07  9:48     ` Pattan, Reshma
2020-12-04  7:51 ` [dpdk-dev] [PATCH 5/5] librte_ethdev: add to use apistats Hideyuki Yamashita
2020-12-05 13:01   ` Varghese, Vipin
2020-12-06 17:47   ` Stephen Hemminger
2020-12-24  6:33     ` Hideyuki Yamashita
2020-12-07 12:38   ` Ananyev, Konstantin
2020-12-22  2:48     ` Hideyuki Yamashita
2020-12-22  2:50     ` Hideyuki Yamashita
2020-12-22  9:04       ` Morten Brørup
2020-12-22 13:05       ` Ananyev, Konstantin
2020-12-04  9:09 ` [dpdk-dev] [PATCH 0/5] add apistats function Ferruh Yigit
2020-12-04 10:20 ` David Hunt
2020-12-05 13:23   ` Varghese, Vipin
2020-12-24  6:43     ` Hideyuki Yamashita
2020-12-24 12:35       ` Varghese, Vipin [this message]
2020-12-22  2:16   ` Hideyuki Yamashita
2020-12-07  9:46 ` Thomas Monjalon
2020-12-22  2:22   ` Hideyuki Yamashita
2021-02-22 15:10     ` Ferruh Yigit

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR11MB15817212252642960D0AC86C90DD0@MWHPR11MB1581.namprd11.prod.outlook.com \
    --to=vipin.varghese@intel.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=yamashita.hideyuki@ntt-tx.co.jp \


* 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).