> > > @@ -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. > > >