ping On Thu, Jan 8, 2015 at 2:37 PM, Bill Fischofer <[email protected]> wrote: > That certainly seems to be the upshot for now from yesterday's discussions. > Whether this is something that will persist longer-term remains to be seen. > > The net is that if you want to pause there a certain amount of choreography > that the application needs to do to perform such role-switching in a > graceful manner. A good reason, perhaps, to consider designing the > application so that pauses are not needed. > > We still need to discuss how to deal with potentially cached work if we want > to be able to support a more robust programming model in which > threads/processes can fail without killing the entire application. > > On Thu, Jan 8, 2015 at 6:27 AM, Ciprian Barbu <[email protected]> > wrote: >> >> On Wed, Jan 7, 2015 at 9:41 PM, Mike Holmes <[email protected]> >> wrote: >> > I am unsure if I need to pay attention to this for 0.7.0 >> >> Still abit unclear after the discussion we had with Petri, but I think >> we need to keep the behavior as it is, meaning applications need to >> take care of the scheduling "cache", and consume everything after >> issuing an odp_schedule_pause call. This would also mean my test case >> behaves as expected. >> >> > >> > On 7 January 2015 at 04:39, Ciprian Barbu <[email protected]> >> > wrote: >> >> >> >> On Tue, Jan 6, 2015 at 4:03 PM, Bill Fischofer >> >> <[email protected]> wrote: >> >> > I think it's something we need to discuss during the sync call. >> >> > >> >> > On Tue, Jan 6, 2015 at 7:48 AM, Mike Holmes <[email protected]> >> >> > wrote: >> >> >> >> >> >> Should a bug be made to track a needed change or is it important for >> >> >> 1.0 >> >> >> and needs to be in the delta doc ? >> >> >> >> >> >> On 6 January 2015 at 08:40, Bill Fischofer >> >> >> <[email protected]> >> >> >> wrote: >> >> >>> >> >> >>> Caches should be transparent. While this may be needed here, it's >> >> >>> a >> >> >>> poor >> >> >>> set of semantics to expose as part of the formal APIs. This is >> >> >>> definitely >> >> >>> something we need to address. My suggestion is that a >> >> >>> odp_schedule_pause() >> >> >>> should cause an implicit cache flush if the implementation is using >> >> >>> a >> >> >>> scheduling cache. That way any cache being used is truly >> >> >>> transparent >> >> >>> and >> >> >>> moreover there won't be unnecessary delays in event processing >> >> >>> since >> >> >>> who >> >> >>> knows how long a pause may last? Clearly it won't be brief since >> >> >>> otherwise >> >> >>> the application would not have bothered with a pause/resume in the >> >> >>> first >> >> >>> place. >> >> >> >> Sorry, I couldn't join you in the ODP call yesterday, mind if you give >> >> a brief update on what was decided? >> >> >> >> >>> >> >> >>> On Tue, Jan 6, 2015 at 7:17 AM, Ciprian Barbu >> >> >>> <[email protected]> >> >> >>> wrote: >> >> >>>> >> >> >>>> On Wed, Dec 17, 2014 at 5:09 PM, Jerin Jacob >> >> >>>> <[email protected]> wrote: >> >> >>>> > On Wed, Dec 17, 2014 at 03:10:11PM +0200, Ciprian Barbu wrote: >> >> >>>> >> Signed-off-by: Ciprian Barbu <[email protected]> >> >> >>>> >> --- >> >> >>>> >> test/validation/odp_schedule.c | 63 >> >> >>>> >> ++++++++++++++++++++++++++++++++++++++---- >> >> >>>> >> 1 file changed, 58 insertions(+), 5 deletions(-) >> >> >>>> >> >> >> >>>> >> diff --git a/test/validation/odp_schedule.c >> >> >>>> >> b/test/validation/odp_schedule.c >> >> >>>> >> index 31be742..bdbcf77 100644 >> >> >>>> >> --- a/test/validation/odp_schedule.c >> >> >>>> >> +++ b/test/validation/odp_schedule.c >> >> >>>> >> @@ -11,9 +11,11 @@ >> >> >>>> >> #define MSG_POOL_SIZE (4*1024*1024) >> >> >>>> >> #define QUEUES_PER_PRIO 16 >> >> >>>> >> #define BUF_SIZE 64 >> >> >>>> >> -#define TEST_NUM_BUFS 100 >> >> >>>> >> +#define NUM_BUFS 100 >> >> >>>> >> #define BURST_BUF_SIZE 4 >> >> >>>> >> -#define TEST_NUM_BUFS_EXCL 10000 >> >> >>>> >> +#define NUM_BUFS_EXCL 10000 >> >> >>>> >> +#define NUM_BUFS_PAUSE 1000 >> >> >>>> >> +#define NUM_BUFS_BEFORE_PAUSE 10 >> >> >>>> >> >> >> >>>> >> #define GLOBALS_SHM_NAME "test_globals" >> >> >>>> >> #define MSG_POOL_NAME "msg_pool" >> >> >>>> >> @@ -229,7 +231,7 @@ static void >> >> >>>> >> schedule_common(odp_schedule_sync_t >> >> >>>> >> sync, int num_queues, >> >> >>>> >> args.sync = sync; >> >> >>>> >> args.num_queues = num_queues; >> >> >>>> >> args.num_prio = num_prio; >> >> >>>> >> - args.num_bufs = TEST_NUM_BUFS; >> >> >>>> >> + args.num_bufs = NUM_BUFS; >> >> >>>> >> args.num_cores = 1; >> >> >>>> >> args.enable_schd_multi = enable_schd_multi; >> >> >>>> >> args.enable_excl_atomic = 0; /* Not needed with a >> >> >>>> >> single >> >> >>>> >> core */ >> >> >>>> >> @@ -261,9 +263,9 @@ static void >> >> >>>> >> parallel_execute(odp_schedule_sync_t >> >> >>>> >> sync, int num_queues, >> >> >>>> >> thr_args->num_queues = num_queues; >> >> >>>> >> thr_args->num_prio = num_prio; >> >> >>>> >> if (enable_excl_atomic) >> >> >>>> >> - thr_args->num_bufs = TEST_NUM_BUFS_EXCL; >> >> >>>> >> + thr_args->num_bufs = NUM_BUFS_EXCL; >> >> >>>> >> else >> >> >>>> >> - thr_args->num_bufs = TEST_NUM_BUFS; >> >> >>>> >> + thr_args->num_bufs = NUM_BUFS; >> >> >>>> >> thr_args->num_cores = globals->core_count; >> >> >>>> >> thr_args->enable_schd_multi = enable_schd_multi; >> >> >>>> >> thr_args->enable_excl_atomic = enable_excl_atomic; >> >> >>>> >> @@ -459,6 +461,56 @@ static void >> >> >>>> >> test_schedule_multi_1q_mt_a_excl(void) >> >> >>>> >> ENABLE_EXCL_ATOMIC); >> >> >>>> >> } >> >> >>>> >> >> >> >>>> >> +static void test_schedule_pause_resume(void) >> >> >>>> >> +{ >> >> >>>> >> + odp_queue_t queue; >> >> >>>> >> + odp_buffer_t buf; >> >> >>>> >> + odp_queue_t from; >> >> >>>> >> + int i; >> >> >>>> >> + int local_bufs = 0; >> >> >>>> >> + >> >> >>>> >> + queue = odp_queue_lookup("sched_0_0_n"); >> >> >>>> >> + CU_ASSERT(queue != ODP_QUEUE_INVALID); >> >> >>>> >> + >> >> >>>> >> + pool = odp_buffer_pool_lookup(MSG_POOL_NAME); >> >> >>>> >> + CU_ASSERT_FATAL(pool != ODP_BUFFER_POOL_INVALID); >> >> >>>> >> + >> >> >>>> >> + >> >> >>>> >> + for (i = 0; i < NUM_BUFS_PAUSE; i++) { >> >> >>>> >> + buf = odp_buffer_alloc(pool); >> >> >>>> >> + CU_ASSERT(buf != ODP_BUFFER_INVALID); >> >> >>>> >> + odp_queue_enq(queue, buf); >> >> >>>> >> + } >> >> >>>> >> + >> >> >>>> >> + for (i = 0; i < NUM_BUFS_BEFORE_PAUSE; i++) { >> >> >>>> >> + buf = odp_schedule(&from, ODP_SCHED_NO_WAIT); >> >> >>>> >> + CU_ASSERT(from == queue); >> >> >>>> >> + odp_buffer_free(buf); >> >> >>>> >> + } >> >> >>>> >> + >> >> >>>> >> + odp_schedule_pause(); >> >> >>>> >> + >> >> >>>> >> + while (1) { >> >> >>>> >> + buf = odp_schedule(&from, ODP_SCHED_NO_WAIT); >> >> >>>> >> + if (buf == ODP_BUFFER_INVALID) >> >> >>>> >> + break; >> >> >>>> >> + >> >> >>>> >> + CU_ASSERT(from == queue); >> >> >>>> >> + odp_buffer_free(buf); >> >> >>>> >> + local_bufs++; >> >> >>>> >> + } >> >> >>>> >> + >> >> >>>> >> + CU_ASSERT(local_bufs < NUM_BUFS_PAUSE - >> >> >>>> >> NUM_BUFS_BEFORE_PAUSE); >> >> >>>> > >> >> >>>> > Whats is the expected behavior here, Shouldn't it be >> >> >>>> > CU_ASSERT(local_bufs == 0) ? >> >> >>>> > meaning, the complete pause ? >> >> >>>> >> >> >>>> Sorry about the delay, I've been playing around with mutt and I >> >> >>>> must >> >> >>>> have accidentally marked this email as read. >> >> >>>> The explanation here is that after pausing the scheduling, there >> >> >>>> might >> >> >>>> still be locally reserved buffers (see the odp_schedule_pause >> >> >>>> documentation). For linux-generic for instance the scheduler >> >> >>>> dequeues >> >> >>>> buffers in bursts, odp_scheduler_pause only stops further >> >> >>>> dequeues, >> >> >>>> buffers may still be in the 'reservoirs'. With that in mind, the >> >> >>>> check >> >> >>>> above makes sure that after pausing only a limited number of >> >> >>>> packets >> >> >>>> are still scheduled, or else said pausing seems to work, not all >> >> >>>> packets being drained. >> >> >>>> >> >> >>>> > >> >> >>>> >> + >> >> >>>> >> + odp_schedule_resume(); >> >> >>>> >> + >> >> >>>> >> + for (i = local_bufs + NUM_BUFS_BEFORE_PAUSE; i < >> >> >>>> >> NUM_BUFS_PAUSE; i++) { >> >> >>>> >> + buf = odp_schedule(&from, ODP_SCHED_WAIT); >> >> >>>> >> + CU_ASSERT(from == queue); >> >> >>>> >> + odp_buffer_free(buf); >> >> >>>> >> + } >> >> >>>> >> +} >> >> >>>> >> + >> >> >>>> >> static int create_queues(void) >> >> >>>> >> { >> >> >>>> >> int i, j, prios; >> >> >>>> >> @@ -594,6 +646,7 @@ struct CU_TestInfo test_odp_schedule[] = { >> >> >>>> >> {"schedule_multi_mq_mt_prio_a", >> >> >>>> >> test_schedule_multi_mq_mt_prio_a}, >> >> >>>> >> {"schedule_multi_mq_mt_prio_o", >> >> >>>> >> test_schedule_multi_mq_mt_prio_o}, >> >> >>>> >> {"schedule_multi_1q_mt_a_excl", >> >> >>>> >> test_schedule_multi_1q_mt_a_excl}, >> >> >>>> >> + {"schedule_pause_resume", >> >> >>>> >> test_schedule_pause_resume}, >> >> >>>> >> CU_TEST_INFO_NULL, >> >> >>>> >> }; >> >> >>>> >> >> >> >>>> >> -- >> >> >>>> >> 1.8.3.2 >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> _______________________________________________ >> >> >>>> >> lng-odp mailing list >> >> >>>> >> [email protected] >> >> >>>> >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> lng-odp mailing list >> >> >>>> [email protected] >> >> >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >>> >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> lng-odp mailing list >> >> >>> [email protected] >> >> >>> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Mike Holmes >> >> >> Linaro Sr Technical Manager >> >> >> LNG - ODP >> >> > >> >> > >> > >> > >> > >> > >> > -- >> > Mike Holmes >> > Linaro Sr Technical Manager >> > LNG - ODP > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
