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.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
