May be we can create an other task for this?. Steve mentioned that this
verbose is kind of urgent for the multi-node LAVA environment. Let me know
your views.
/Krishna
On 29 July 2015 at 16:40, Stuart Haslam <stuart.has...@linaro.org> wrote:
> On Wed, Jul 29, 2015 at 05:13:40PM +0300, Maxim Uvarov wrote:
> > On 07/29/15 16:43, Stuart Haslam wrote:
> > >On Wed, Jul 29, 2015 at 04:10:06PM +0300, Maxim Uvarov wrote:
> > >>On 07/29/15 16:02, Stuart Haslam wrote:
> > >>>On Wed, Jul 29, 2015 at 03:54:51PM +0300, Maxim Uvarov wrote:
> > >>>>On 07/29/15 15:21, Stuart Haslam wrote:
> > >>>>>On Wed, Jul 29, 2015 at 01:12:23PM +0200, Balakrishna.Garapati
> wrote:
> > >>>>>>corrected alignment issues
> > >>>>>This should go beneath the --- line so that it doesn't end up in the
> > >>>>>commit log.
> > >>>>>
> > >>>>>>Signed-off-by: Balakrishna.Garapati <
> balakrishna.garap...@linaro.org>
> > >>>>>>---
> > >>>>>> example/generator/odp_generator.c | 13 ++++++++++++-
> > >>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
> > >>>>>>
> > >>>>>>diff --git a/example/generator/odp_generator.c
> b/example/generator/odp_generator.c
> > >>>>>>index d6ec758..5cf7e92 100644
> > >>>>>>--- a/example/generator/odp_generator.c
> > >>>>>>+++ b/example/generator/odp_generator.c
> > >>>>>>@@ -26,6 +26,7 @@
> > >>>>>> #define MAX_WORKERS 32 /**< max number of
> works */
> > >>>>>> #define SHM_PKT_POOL_SIZE (512*2048) /**< pkt pool size
> */
> > >>>>>> #define SHM_PKT_POOL_BUF_SIZE 1856 /**< pkt pool buf
> size */
> > >>>>>>+#define DEFAULT_PKT_INTERVAL 1000 /**< interval btw
> each pkt */
> > >>>>>> #define APPL_MODE_UDP 0 /**< UDP mode */
> > >>>>>> #define APPL_MODE_PING 1 /**< ping mode */
> > >>>>>>@@ -370,6 +371,7 @@ static odp_pktio_t create_pktio(const char
> *dev, odp_pool_t pool)
> > >>>>>> static void *gen_send_thread(void *arg)
> > >>>>>> {
> > >>>>>> int thr;
> > >>>>>>+ uint64_t start, now, diff;
> > >>>>>> odp_pktio_t pktio;
> > >>>>>> thread_args_t *thr_args;
> > >>>>>> odp_queue_t outq_def;
> > >>>>>>@@ -391,6 +393,7 @@ static void *gen_send_thread(void *arg)
> > >>>>>> return NULL;
> > >>>>>> }
> > >>>>>>+ start = odp_time_cycles();
> > >>>>>> printf(" [%02i] created mode: SEND\n", thr);
> > >>>>>> for (;;) {
> > >>>>>> int err;
> > >>>>>>@@ -431,6 +434,14 @@ static void *gen_send_thread(void *arg)
> > >>>>>> >= (unsigned int)args->appl.number) {
> > >>>>>> break;
> > >>>>>> }
> > >>>>>>+
> > >>>>>>+ now = odp_time_cycles();
> > >>>>>>+ diff = odp_time_diff_cycles(start, now);
> > >>>>>>+ if (odp_time_cycles_to_ns(diff) > 20 *
> ODP_TIME_SEC) {
> > >>>>>>+ start = odp_time_cycles();
> > >>>>>>+ printf(" [%02i] total send: %ju\n",
> > >>>>>>+ thr,
> odp_atomic_load_u64(&counters.seq));
> > >>>>>Need an fflush(stdout) here to ensure this is visible.
> > >>>>There is "\n" so it should be visible when terminal will allow it. I
> > >>>>think no need for explicit fush. Without "\n" flush is needed.
> > >>>>
> > >>>It depends where the output is going, \n will typically only flush if
> > >>>output is to a terminal. If you're redirecting to a file, or piping
> the
> > >>>output through awk for example, it won't.
> > >>>
> > >>do you need put to file or awk counters from that loop?
> > >Yes actually I piped it through awk to add timestamps so that I could
> > >check timings after Krishna reported issues. More generally I was
> > >thinking about when running this from a script, and the principle of
> > >least surprise.
> > >
> > >>I think on exist generator should return some summary which
> > >>is valuable for logs and parse scripts. Here it should not delay on
> flush.
> > >If we care about delaying we should not be printing at all (from this
> > >thread).
> > >
> > btw! why do we print from worker thread and not from control thread?
> > l2fwd example as I remember prints from control.
> >
>
> I mentioned that (in an off-list mail) to Krishna but said I thought it
> could be changed later, as it's complicated slightly by the different
> modes you can be running in and I figured it's not worth delaying this
> change over. It's questionable though.
>
> --
> Stuart.
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
