Petri unless you don't think this fits I suggest we apply it to test what is in the repo now
On 20 January 2015 at 09:23, Ciprian Barbu <[email protected]> wrote: > PING! > > On Wed, Jan 14, 2015 at 7:14 PM, Mike Holmes <[email protected]> > wrote: > > Without any clear change in sight, lets test what we have, this has > been on > > the list for a month > > > > On 14 January 2015 at 08:35, Ciprian Barbu <[email protected]> > wrote: > >> > >> On Wed, Jan 14, 2015 at 3:28 PM, Ola Liljedahl < > [email protected]> > >> wrote: > >> > On 7 January 2015 at 20:41, Mike Holmes <[email protected]> > wrote: > >> >> I am unsure if I need to pay attention to this for 0.7.0 > >> > We need to have a decision (and implementation) for ODP 1.0 though. > >> > Scheduling and its semantics are important aspects of ODP. > >> > >> The odp_schedule_pause API is already documented and implemented, I > >> didn't exactly catch from Petri if we will keep the behavior for 1.0, > >> but what is the problem with covering this API in its current form for > >> at least 0.7 and 0.8? > >> > >> > > >> >> > >> >> 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 > >> >> > > > > > > > > > > -- > > 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
