> > > @@ -1159,6 +1243,19 @@ ipsec_poll_mode_worker(void)
> > > drain_tx_buffers(qconf);
> > > drain_crypto_buffers(qconf);
> > > prev_tsc = cur_tsc;
> > > +#ifdef ENABLE_STATS
> > > + if (lcore_id == rte_get_master_lcore()) {
> > > + /* advance the timer */
> > > + timer_tsc += diff_tsc;
> > > +
> > > + /* if timer has reached its timeout */
> > > + if (unlikely(timer_tsc >= timer_period)) {
> > > + print_stats();
> > > + /* reset the timer */
> > > + timer_tsc = 0;
> > > + }
> > > + }
> > > +#endif /* ENABLE_STATS */
> >
> >
> > Why to do stats collection/display inside data-path?
> > Why not use rte_timer/rte_alarm and make it happen in control thread?
> > Another option - make stats printing at some signal to the process.
> > In that case we don't need to bother with time period at all - it will be
> > user to
> > decide.
> > Again if we remove that print_stats() from data-path it might become cheap
> > enough to always collect it, and we will not need ENABLE_STATS macro at all.
>
> [Anoob] The stats collection will not be cheap because we are updating a
> common structure from multiple cores.
What I am saying - per-lcore stats collection (updating lcore stats by lcore
itself) - should be cheap enough
and can stay in data-path (probably even always, not only when particular
compile flag is enabled).
Global stats collection and display is quite expensive operation,
so we shouldn't keep it in data-path.
We have a control thread within dpdk (for alarms, signals, timers, etc.),
why not to call print_stats from there?
> And the idea is not to
> have a very efficient stats mechanism. When we have more cores engaged, IPsec
> performance is directly dependent on ability of RSS to
> split traffic to multiple cores. Such stats would come handy in understanding
> per core distribution of incoming traffic.
>
> >
