> From: Robin Jarry [mailto:[email protected]] > Sent: Tuesday, 9 December 2025 12.47 > > Morten Brørup, Dec 09, 2025 at 12:13: > > Looking at patch 2/2, I disagree with the approach. > > > > RTE_LIBRTE_GRAPH_STATS should control all stats, incl. total_calls > and > > total_objs. Then, if enabled, the total_cycles stats can be > controlled > > by rte_graph_cycle_stats_enable(). > > > > Your v1 series introduces unnecessary overhead for applications not > > caring about total_calls/total_objs stats and thus built without > > RTE_LIBRTE_GRAPH_STATS. > > My issue is that I would like the total_objs stat but without the > overhead of rte_rdtsc() being called twice for every node visit.
I get that. My proposal provides that. > > And also, I would like to be able to enable/disable these stats *at > runtime*. Why would you enable/disable total_calls/total_objs at runtime? > Having it behind a compile time constant makes it very not > flexible. Agree, but instrumentation has a performance cost, and should be possible to disable at compile time. > > I could have two booleans to control whether total_calls/total_objs are > updated *and* whether total_cycles are computed. But that seems a bit > overkill and it would mean two fields to check (two branches) instead > of > one per node. > > Is it really that bad to update two uint64_t counters? The cost is unnecessary. It's instrumentation. > > -- > Robin > > > Your canceled check is your receipt. Please change your cookie generator to not make it look a quote from the person you are replying to.
