On 4 September 2015 at 15:36, Bill Fischofer <bill.fischo...@linaro.org>
wrote:
> That's saying that a specific worker has knowledge of what events it
> should be receiving and when. The whole point of event scheduling is that
> an individual worker thread is not aware of such considerations, but simply
> process events that are scheduled to it.
>
> What you're describing is an application that is polling rather than
> scheduling. To treat odp_schedule() as a type of poll sort of misses the
> point of having an event model.
>
I am with you here Bill.
>
> But enough digression. Sorry to sidetrack this thread. :)
>
> On Fri, Sep 4, 2015 at 8:20 AM, Nicolas Morey-Chaisemartin <
> nmo...@kalray.eu> wrote:
>
>> It could send some packet or simply handle an error case (packet should
>> have arrived now, something went wrong?)
>>
> Use timers/timeouts for that.
As Bill writes, an individual worker thread does not have any global
knowledge of the application state so a timeout from odp_schedule() doesn't
mean anything.
>> All this could be probably implemented by the user with timers and make
>> the code better, but programmers are lazy and
>> variable timeout is very easy to use and much lighter than creating a
>> pool of timers and so on...
>>
>>
>> On 09/04/2015 03:13 PM, Bill Fischofer wrote:
>>
>> My point wasn't about the validation test but about the utility of the
>> variable timeout feature of the API itself. Can anyone really come up with
>> a use case where Wait for X, 2X, 3X have distinct meanings such that a
>> worker thread would choose one vs. another? In a portable manner? Exactly
>> what will the worker thread do after waiting if it returns empty handed
>> other than wait again?
>>
>> On Fri, Sep 4, 2015 at 4:56 AM, Ivan Khoronzhuk <
>> ivan.khoronz...@linaro.org> wrote:
>>
>>> Bill,
>>>
>>> On 04.09.15 05:46, Bill Fischofer wrote:
>>>
>>>> The time waiting is of dubious value (and portability) in a system with
>>>> dedicated worker threads. What else are they planning to do? Is that the
>>>> best design for the application? There are valid common uses for
>>>> ODP_SCHED_WAIT and ODP_SCHED_NO_WAIT. Everything else is questionable.
>>>> Periodic processing should be done via timers that trigger events rather
>>>> than by guesswork on the part of workers.
>>>>
>>>
>>> I tend to leave it as proposed Nicolas to cover existent examples.
>>> It cannot touch cases where timers are used, I guess.
>>>
>>> if (ns && !cycle)
>>> cycle = 1;
>>>
>>> ODP_SCHED_NO_WAIT (1) like check once, so if we passed ~ 1ns we wanted
>>> to schedule at least once.
>>> Currently it can lead to wait forever ODP_SCHED_WAIT (0).
>>>
>>>
>>>> On Thu, Sep 3, 2015 at 1:28 AM, Ivan Khoronzhuk <
>>>> <ivan.khoronz...@linaro.org>ivan.khoronz...@linaro.org <mailto:
>>>> ivan.khoronz...@linaro.org>> wrote:
>>>>
>>>>
>>>>
>>>> On 03.09.15 09:20, Nicolas Morey-Chaisemartin wrote:
>>>>
>>>>
>>>>
>>>> On 09/02/2015 11:16 PM, Ivan Khoronzhuk wrote:
>>>>
>>>>
>>>>
>>>> On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote:
>>>>
>>>>
>>>> On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote:
>>>>
>>>>
>>>>
>>>> On 26.08.15 18:22, Stuart Haslam wrote:
>>>>
>>>> On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan
>>>> Khoronzhuk wrote:
>>>>
>>>> It's needed because time resolution can be
>>>> a little more than 1ns
>>>> and in this case odp_schedule_wait_time(1)
>>>> returns 0, and test
>>>> generates warn w/o reason. So increase
>>>> scheduler wait time check
>>>> from 1ns to 100ns.
>>>>
>>>> It's hard to imagine time source with
>>>> resolution more than 100ns,
>>>> so every implementation can return positive
>>>> value from
>>>> odp_schedule_wait_time(). In case if
>>>> resolution is more than 100ns
>>>> it's normal to warn about it at validation
>>>> stage,
>>>>
>>>>
>>>> The wait parameter is documented as the
>>>> *minimum* time to wait for an
>>>> event so the existing check looks OK to me.
>>>> Implementations with a lower
>>>> resolution should round up.
>>>>
>>>>
>>>> It defined as "minimum" time to wait for
>>>> odp_schedule and others,
>>>> for odp_schedule_wait_time() it's not defined as
>>>> minimum, it's simple
>>>> convert function.
>>>>
>>>> Not shure, but any of the functions I saw in
>>>> linux-generic doesn't round ticks up.
>>>> It seems that it was decided to allow application
>>>> to do it, if needed.
>>>>
>>>> But if so, we have much more to change ).
>>>>
>>>> In case if you are right, linux-generic
>>>> implementation should be corrected,
>>>> as it doesn't round it up.
>>>>
>>>> Thanks.
>>>>
>>>> I ran into this issue with our port as our clock are <
>>>> 1GHz.
>>>> So 1 ns is < 1 cycle which tends to break a few things
>>>> on the linux generic port.
>>>>
>>>> I fix this particular issue like this:
>>>> uint64_t odp_schedule_wait_time(uint64_t ns)
>>>> {
>>>> uint64_t cycle = odp_time_ns_to_cycles(ns);
>>>> if(cycle == 0)
>>>> cycle = 1;
>>>> return cycle;
>>>> }
>>>>
>>>> Not the nicest patch but it works.
>>>> The test should probably be changed to if(ns && !cycle)
>>>> so ns=0 returns 0;
>>>>
>>>> Yes.
>>>>
>>>> As said Stuart it may cause collisions with ODP_SCHED_WAIT
>>>> (0)
>>>> and ODP_SCHED_NO_WAIT (1)
>>>>
>>>> I will correct it a little later.
>>>>
>>>> I don't think the collision with ODP_SCHED_NO_WAIT is too bad.
>>>> We only fall into this case if a cycle is larger than 1 ns so waiting not
>>>> waiting or waiting less thana cycle is close to the same thing.
>>>>
>>>>
>>>> Maybe you are right.
>>>>
>>>> --
>>>> Regards,
>>>> Ivan Khoronzhuk
>>>>
>>>> _______________________________________________
>>>> lng-odp mailing list
>>>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>>>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>>>
>>>>
>>>>
>>> --
>>> Regards,
>>> Ivan Khoronzhuk
>>>
>>
>>
>>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
