All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Robin Jarry" <rjarry@redhat.com>, <dev@dpdk.org>,
	"Jerin Jacob" <jerinj@marvell.com>,
	"Kiran Kumar K" <kirankumark@marvell.com>,
	"Nithin Dabilpuram" <ndabilpuram@marvell.com>,
	"Zhirun Yan" <yanzhirun_163@163.com>,
	"Saeed Bishara" <saeed.bishara.os@gmail.com>
Subject: RE: [PATCH v9] graph: add optional profiling stats
Date: Sat, 22 Aug 2026 12:18:54 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65A0D@smartserver.smartshare.dk> (raw)
In-Reply-To: <DKVDPNOPM64I.DMED3KJABMT@redhat.com>

> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Saturday, 22 August 2026 11.53
> 
> Hey Morten,
> 
> I have some concerns with the "histogram" implementation. There are
> holes in the data. You will only capture specific batch sizes.
> 
> NB: did you notice we already have a burst size histogram exported in
> the grout metrics:
> 
> https://github.com/DPDK/grout/blob/v0.17.1/modules/infra/api/stats.c#L3
> 13-L336

Thanks for the pointer.
The existing histogram only covers packet burst size.
I want to capture performance data for development (optimization) purposes.

I'll take a look at it, to see if something similar could be relevant for the data I'm aiming to collect.

> 
> Morten Brørup, Jul 03, 2026 at 17:43:

[...]

> >  	if (rte_graph_has_stats_feature()) {
> > -		start = rte_rdtsc();
> > +		cycles = -rte_rdtsc();
> 
> I presume this works but it feels confusing taking a "negative" value
> of an unsigned integer.

Maybe this is more readable:
cycles = rte_rdtsc();
rc = node->process(graph, node, objs, node->idx);
cycles = rte_rdtsc() - cycles;

> 
> >  		rc = node->process(graph, node, objs, node->idx);
> > -		node->total_cycles += rte_rdtsc() - start;
> > +		cycles += rte_rdtsc();
> > +		node->total_cycles += cycles;
> >  		node->total_calls++;
> >  		node->total_objs += rc;
> > +#ifdef RTE_GRAPH_PROFILE
> > +		if (rc <= 1) {
> > +			node->usage_stats[rc].calls++;
> > +			node->usage_stats[rc].cycles += cycles;
> > +		} else if (rc == RTE_GRAPH_PROFILE_BURST_SIZE) {
> > +			node->usage_stats[2].calls++;
> > +			node->usage_stats[2].cycles += cycles;
> > +		} else if (rc == RTE_GRAPH_BURST_SIZE) {
> > +			node->usage_stats[3].calls++;
> > +			node->usage_stats[3].cycles += cycles;
> 
> If you want a reliable histogram, you would need to change these tests
> to the following:
> 
> 		id (rc >= RTE_GRAPH_BURST_SIZE) {
> 			node->usage_stats[3].calls++;
> 			node->usage_stats[3].cycles += cycles;
> 		} else if (rc >= RTE_GRAPH_PROFILE_BURST_SIZE) {
> 			node->usage_stats[2].calls++;
> 			node->usage_stats[2].cycles += cycles;
> 		} else if (rc != 0) {
> 			node->usage_stats[1].calls++;
> 			node->usage_stats[1].cycles += cycles;
> 		} else {
> 			node->usage_stats[0].calls++;
> 			node->usage_stats[0].cycles += cycles;
> 		}
> 
> Otherwise, you will miss lots of odd-sized batches in your histogram
> data.

Correct.
However, I only need a few representative snapshots to help identify what to optimize.
Zero and one object processed are quite frequently, so I want to know how frequent they occur.
BTW, the cycles/object for processing one object is substantially higher than when processing a burst.

For bursts, I want to be able to calculate the cycles/object.
I also want to be able to see how frequent they occur.

I wanted the data to stay within one cache line, so I compromised.
Since I don't need to stay within one cache line, I can improve it with better coverage.

> 
> 
> > +		}
> > +#endif
> >  	} else {
> >  		node->process(graph, node, objs, node->idx);
> >  	}
> 
> 
> --
> Robin
> 
> # Not a flying toy.


  reply	other threads:[~2026-08-22 10:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-19 20:20 [PATCH] graph: add optional profiling stats Morten Brørup
2026-06-19 20:56 ` [PATCH v3] " Morten Brørup
2026-06-21 17:55 ` [PATCH v4] " Morten Brørup
2026-06-21 18:41 ` [PATCH v5] " Morten Brørup
2026-06-23  5:13   ` Jerin Jacob
2026-06-23  6:45     ` Morten Brørup
2026-06-23  6:56       ` Jerin Jacob
2026-06-23  7:10         ` Morten Brørup
2026-06-23  9:08           ` Jerin Jacob
2026-08-10  6:28             ` Morten Brørup
2026-06-23  8:33         ` saeed bishara
2026-06-23 12:04           ` Morten Brørup
2026-06-23 14:10             ` saeed bishara
2026-06-24  7:59               ` Morten Brørup
2026-06-24 13:09                 ` saeed bishara
2026-07-03 13:18 ` [PATCH v6] " Morten Brørup
2026-07-03 13:53 ` [PATCH v7] " Morten Brørup
2026-07-03 14:22 ` [PATCH v8] " Morten Brørup
2026-07-03 15:43 ` [PATCH v9] " Morten Brørup
2026-08-13  6:56   ` Morten Brørup
2026-08-22  9:52   ` Robin Jarry
2026-08-22 10:18     ` Morten Brørup [this message]
2026-08-23  9:25 ` [PATCH v10] " Morten Brørup
2026-08-23 10:40 ` [PATCH v11] " Morten Brørup
2026-08-23 10:57 ` [PATCH v12] " Morten Brørup
2026-08-23 11:57 ` [PATCH v13] " Morten Brørup
2026-08-23 12:52 ` [PATCH v14] " Morten Brørup
2026-08-23 13:42 ` [PATCH v15] " Morten Brørup
2026-08-23 14:25 ` [PATCH v16] " Morten Brørup
2026-08-23 15:01 ` [PATCH v17] " Morten Brørup
2026-08-24 11:15   ` kirankumark
2026-08-24 14:56   ` Jerin Jacob

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=98CBD80474FA8B44BF855DF32C47DC35F65A0D@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=kirankumark@marvell.com \
    --cc=ndabilpuram@marvell.com \
    --cc=rjarry@redhat.com \
    --cc=saeed.bishara.os@gmail.com \
    --cc=yanzhirun_163@163.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.