I am unsure if I need to pay attention to this for 0.7.0

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

Reply via email to