<snip> > Subject: Re: Random failure in service_autotest > > David Marchand <david.march...@redhat.com> writes: > > > On Wed, Jul 15, 2020 at 3:09 PM Lukasz Wojciechowski > > <l.wojciec...@partner.samsung.com> wrote: > >> > >> > >> W dniu 15.07.2020 o 15:02, David Marchand pisze: > >> > On Wed, Jul 15, 2020 at 2:56 PM Aaron Conole <acon...@redhat.com> > wrote: > >> >> I guess the service_lcore_attr_get failed, but with no useful > >> Why do you suspect service_lcore_attr_get() ? > > > > https://travis-ci.com/github/ovsrobot/dpdk/jobs/361097992#L18697 > > > > RTE>>service_autotest > > + ------------------------------------------------------- + + Test > > Suite : service core test suite + > > ------------------------------------------------------- + + TestCase > > [ 0] : unregister_all succeeded + TestCase [ 1] : service_name > > succeeded + TestCase [ 2] : service_get_by_name succeeded Service > > dummy_service Summary > > dummy_service: stats 1 calls 0 cycles 0 avg: 0 Service dummy_service > > Summary > > dummy_service: stats 0 calls 0 cycles 0 avg: 0 + TestCase [ 3] : > > service_dump succeeded + TestCase [ 4] : service_attr_get succeeded > > > > *** > > + TestCase [ 5] : service_lcore_attr_get failed > > *** > > > > + TestCase [ 6] : service_probe_capability succeeded + TestCase [ 7] > > : service_start_stop succeeded + TestCase [ 8] : > > service_lcore_add_del skipped + TestCase [ 9] : > > service_lcore_start_stop succeeded + TestCase [10] : > > service_lcore_en_dis_able succeeded + TestCase [11] : > > service_mt_unsafe_poll skipped + TestCase [12] : service_mt_safe_poll > > skipped perf test for MT Safe: 56.9 cycles per call + TestCase [13] : > > service_app_lcore_mt_safe succeeded perf test for MT Unsafe: 83.4 > > cycles per call + TestCase [14] : service_app_lcore_mt_unsafe > > succeeded + TestCase [15] : service_may_be_active succeeded + > > TestCase [16] : service_active_two_cores skipped + > > ------------------------------------------------------- + > > > > > >> >> information. We should have the test suite app turn the log level > >> >> all the way up. I realize it will increase the log data even > >> >> higher, but without it, we have no idea why this test failed. > >> >> > >> >> Something like the following > >> >> --- > >> >> > >> >> diff --git a/app/test/test.c b/app/test/test.c index > >> >> 94d26ab1f6..c47cb075f9 100644 > >> >> --- a/app/test/test.c > >> >> +++ b/app/test/test.c > >> >> @@ -150,6 +150,9 @@ main(int argc, char **argv) > >> >> > >> >> prgname = argv[0]; > >> >> > >> >> + rte_log_set_global_level(RTE_LOG_DEBUG); > >> >> + rte_log_set_level(RTE_LOGTYPE_EAL, RTE_LOG_DEBUG); > >> >> + > >> >> recursive_call = getenv(RECURSIVE_ENV_VAR); > >> >> if (recursive_call != NULL) { > >> >> ret = do_recursive_call(); > >> >> --- > >> >> > >> >> That way we can at least debug when it happens. > >> > Debugging is one thing. > >> > But here service_lcore_attr_get() has a lot of asserts that should > >> > trigger a straight error. > >> > > >> Yes, but without debugs enabled, the assert message won't be printed out. > > > > Changing the whole debug levels could have side effects on the > > libraries being tested: maybe hide races (too bad) or reveal races > > (that would be interesting ;-)). > > 6 of one, 1/2 dozen of the other. > > Maybe there are bugs where people run code inside log level tests that get > omitted otherwise. > > > On the other hand, what I am saying is that using debug level logs for > > test asserts might not be the best solution. Agree, at least error level is required. Please check: https://patches.dpdk.org/patch/74134/
> > Yeah, that's also a good idea :)
