It is still not clear to me in writing that we want this, we did discuss it earlier but Jerin, Bill and Ola have questions on this thread and I am not sure they are all addressed.
On 20 January 2015 at 16:34, Maxim Uvarov <[email protected]> wrote: > Who review this patch please add review-by. > > Mike please add yours because it's validation patch. > > Maxim. > > > On 01/20/2015 05:23 PM, Ciprian Barbu 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 >>> >> _______________________________________________ >> 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
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
