| Message ID | 1440601873-22462-1-git-send-email-ivan.khoronzhuk@linaro.org |
|---|---|
| State | New |
| Headers | show |
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.
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.
On Wed, Aug 26, 2015 at 06:47:59PM +0300, 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. Right, the actual requirement is that; odp_schedule(NULL, odp_schedule_wait_time(x)); waits for a minimum of x ns, maybe the test should actually be checking for that rather than testing the return value of odp_schedule_wait_time() which is implementation defined. > 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. Looks like it, especially as it may cause collisions with ODP_SCHED_WAIT (0) and ODP_SCHED_NO_WAIT (1).
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;
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.
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.
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.
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. On Thu, Sep 3, 2015 at 1:28 AM, Ivan Khoronzhuk <ivan.khoronzhuk@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 > https://lists.linaro.org/mailman/listinfo/lng-odp >
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.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@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 > >
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.khoronzhuk@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.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@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 >
It could send some packet or simply handle an error case (packet should have arrived now, something went wrong?) 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.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@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.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@linaro.org> <mailto:ivan.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@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> <mailto:lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > -- > Regards, > Ivan Khoronzhuk > >
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. But enough digression. Sorry to sidetrack this thread. :) On Fri, Sep 4, 2015 at 8:20 AM, Nicolas Morey-Chaisemartin <nmorey@kalray.eu > wrote: > It could send some packet or simply handle an error case (packet should > have arrived now, something went wrong?) > > 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.khoronzhuk@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.khoronzhuk@linaro.org>ivan.khoronzhuk@linaro.org <mailto: >>> ivan.khoronzhuk@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 >> > > >
On 4 September 2015 at 15:36, Bill Fischofer <bill.fischofer@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 < > nmorey@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.khoronzhuk@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.khoronzhuk@linaro.org>ivan.khoronzhuk@linaro.org <mailto: >>>> ivan.khoronzhuk@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 > >
Scheduler timeout (wait time) enables application to wait on a schedule call, for an finite time. Otherwise application would need to wait infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also using a timer, but it would be waste when a HW scheduler has this finite wait time option build in. Also the “a la carte” principle fits here: user can use the scheduler API without the timer API, if he does not really need timers, just a way to break scheduler to from waiting for ever.
Application may use this e.g. to poll some other (non-ODP) resource when it seems that ODP side (of the application) is lightly loaded (e.g. no single event in last 100ms).
-Petri
From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of ext Ola Liljedahl
Sent: Monday, September 07, 2015 3:36 PM
To: Bill Fischofer
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [Patch] validation: scheduler: increase time check
On 4 September 2015 at 15:36, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@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 <nmorey@kalray.eu<mailto:nmorey@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.khoronzhuk@linaro.org<mailto:ivan.khoronzhuk@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.khoronzhuk@linaro.org<mailto:ivan.khoronzhuk@linaro.org> <mailto:ivan.khoronzhuk@linaro.org<mailto:ivan.khoronzhuk@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> <mailto: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<mailto:lng-odp@lists.linaro.org>
https://lists.linaro.org/mailman/listinfo/lng-odp
On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolainen@nokia.com> wrote: > Scheduler timeout (wait time) enables application to wait on a schedule > call, for an finite time. Otherwise application would need to wait > infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed > (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also > using a timer, but it would be waste when a HW scheduler has this finite > wait time option build in. Also the “a la carte” principle fits here: user > can use the scheduler API without the timer API, if he does not really need > timers, just a way to break scheduler to from waiting for ever. > > > > Application may use this e.g. to poll some other (non-ODP) resource when > it seems that ODP side (of the application) is lightly loaded (e.g. no > single event in last 100ms). > Yes there are probably use cases for a timeout from odp_schedule. But the examples given below (e.g. timeout receiving some packet) are not valid, such cases should be handled with timers. The timeout is an event itself that should be scheduled by the scheduler so that the proper synchronisation (e.g. accessing some state associated with the queue) can be achieved. If odp_schedule() timeouts and returns without an event, the application should *not* start doing packet processing. Scheduler timeouts are for other types of application background processing and maintenance. > > -Petri > > > > > > *From:* lng-odp [mailto:lng-odp-bounces@lists.linaro.org] *On Behalf Of *ext > Ola Liljedahl > *Sent:* Monday, September 07, 2015 3:36 PM > *To:* Bill Fischofer > *Cc:* LNG ODP Mailman List > *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time > check > > > > On 4 September 2015 at 15:36, Bill Fischofer <bill.fischofer@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 < > nmorey@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.khoronzhuk@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.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@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 > > >
From: ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org]
Sent: Monday, September 07, 2015 4:51 PM
To: Savolainen, Petri (Nokia - FI/Espoo)
Cc: Bill Fischofer; LNG ODP Mailman List
Subject: Re: [lng-odp] [Patch] validation: scheduler: increase time check
On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia.com<mailto:petri.savolainen@nokia.com>> wrote:
Scheduler timeout (wait time) enables application to wait on a schedule call, for an finite time. Otherwise application would need to wait infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also using a timer, but it would be waste when a HW scheduler has this finite wait time option build in. Also the “a la carte” principle fits here: user can use the scheduler API without the timer API, if he does not really need timers, just a way to break scheduler to from waiting for ever.
Application may use this e.g. to poll some other (non-ODP) resource when it seems that ODP side (of the application) is lightly loaded (e.g. no single event in last 100ms).
Yes there are probably use cases for a timeout from odp_schedule. But the examples given below (e.g. timeout receiving some packet) are not valid, such cases should be handled with timers. The timeout is an event itself that should be scheduled by the scheduler so that the proper synchronisation (e.g. accessing some state associated with the queue) can be achieved. If odp_schedule() timeouts and returns without an event, the application should not start doing packet processing. Scheduler timeouts are for other types of application background processing and maintenance.
Yes, the scheduler timeout should not be used for driving bulk of the ODP event/packet processing. It enables integration of non-ODP SW (which don’t produce events), or driving back ground processing (started only when app is idling).
-Petri
Isn't that why we have the distinction between control and worker threads now? It sounds like a job for a control thread to handle the "non-ODP" stuff while the worker threads should just be heads-down doing the main application processing as directed by the scheduler. On Mon, Sep 7, 2015 at 9:19 AM, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolainen@nokia.com> wrote: > > > > > *From:* ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org] > *Sent:* Monday, September 07, 2015 4:51 PM > *To:* Savolainen, Petri (Nokia - FI/Espoo) > *Cc:* Bill Fischofer; LNG ODP Mailman List > *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time > check > > > > On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > > Scheduler timeout (wait time) enables application to wait on a schedule > call, for an finite time. Otherwise application would need to wait > infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed > (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also > using a timer, but it would be waste when a HW scheduler has this finite > wait time option build in. Also the “a la carte” principle fits here: user > can use the scheduler API without the timer API, if he does not really need > timers, just a way to break scheduler to from waiting for ever. > > > > Application may use this e.g. to poll some other (non-ODP) resource when > it seems that ODP side (of the application) is lightly loaded (e.g. no > single event in last 100ms). > > Yes there are probably use cases for a timeout from odp_schedule. But the > examples given below (e.g. timeout receiving some packet) are not valid, > such cases should be handled with timers. The timeout is an event itself > that should be scheduled by the scheduler so that the proper > synchronisation (e.g. accessing some state associated with the queue) can > be achieved. If odp_schedule() timeouts and returns without an event, the > application should *not* start doing packet processing. Scheduler > timeouts are for other types of application background processing and > maintenance. > > > > > > Yes, the scheduler timeout should not be used for driving bulk of the ODP > event/packet processing. It enables integration of non-ODP SW (which don’t > produce events), or driving back ground processing (started only when app > is idling). > > > > -Petri > > >
Can any of this discussion be translated into a paragraph in the users guide, explaining the philosophy described here ? The difference between control and worker tasks, how to achieve background processing, how to integrate with non event driven SW etc. On 7 September 2015 at 10:22, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Isn't that why we have the distinction between control and worker threads > now? It sounds like a job for a control thread to handle the "non-ODP" > stuff while the worker threads should just be heads-down doing the main > application processing as directed by the scheduler. > > On Mon, Sep 7, 2015 at 9:19 AM, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolainen@nokia.com> wrote: > >> >> >> >> >> *From:* ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org] >> *Sent:* Monday, September 07, 2015 4:51 PM >> *To:* Savolainen, Petri (Nokia - FI/Espoo) >> *Cc:* Bill Fischofer; LNG ODP Mailman List >> *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time >> check >> >> >> >> On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) < >> petri.savolainen@nokia.com> wrote: >> >> Scheduler timeout (wait time) enables application to wait on a schedule >> call, for an finite time. Otherwise application would need to wait >> infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed >> (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also >> using a timer, but it would be waste when a HW scheduler has this finite >> wait time option build in. Also the “a la carte” principle fits here: user >> can use the scheduler API without the timer API, if he does not really need >> timers, just a way to break scheduler to from waiting for ever. >> >> >> >> Application may use this e.g. to poll some other (non-ODP) resource when >> it seems that ODP side (of the application) is lightly loaded (e.g. no >> single event in last 100ms). >> >> Yes there are probably use cases for a timeout from odp_schedule. But the >> examples given below (e.g. timeout receiving some packet) are not valid, >> such cases should be handled with timers. The timeout is an event itself >> that should be scheduled by the scheduler so that the proper >> synchronisation (e.g. accessing some state associated with the queue) can >> be achieved. If odp_schedule() timeouts and returns without an event, the >> application should *not* start doing packet processing. Scheduler >> timeouts are for other types of application background processing and >> maintenance. >> >> >> >> >> >> Yes, the scheduler timeout should not be used for driving bulk of the ODP >> event/packet processing. It enables integration of non-ODP SW (which don’t >> produce events), or driving back ground processing (started only when app >> is idling). >> >> >> >> -Petri >> >> >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
We should have an application design "deep dive" discussion during SFO15. Let's get that on the schedule. Timely since the theme as we move into 2016 needs to be ODP Applications. On Mon, Sep 7, 2015 at 10:53 AM, Mike Holmes <mike.holmes@linaro.org> wrote: > Can any of this discussion be translated into a paragraph in the users > guide, explaining the philosophy described here ? > > The difference between control and worker tasks, how to achieve background > processing, how to integrate with non event driven SW etc. > > On 7 September 2015 at 10:22, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> Isn't that why we have the distinction between control and worker threads >> now? It sounds like a job for a control thread to handle the "non-ODP" >> stuff while the worker threads should just be heads-down doing the main >> application processing as directed by the scheduler. >> >> On Mon, Sep 7, 2015 at 9:19 AM, Savolainen, Petri (Nokia - FI/Espoo) < >> petri.savolainen@nokia.com> wrote: >> >>> >>> >>> >>> >>> *From:* ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org] >>> *Sent:* Monday, September 07, 2015 4:51 PM >>> *To:* Savolainen, Petri (Nokia - FI/Espoo) >>> *Cc:* Bill Fischofer; LNG ODP Mailman List >>> *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time >>> check >>> >>> >>> >>> On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) < >>> petri.savolainen@nokia.com> wrote: >>> >>> Scheduler timeout (wait time) enables application to wait on a schedule >>> call, for an finite time. Otherwise application would need to wait >>> infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed >>> (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also >>> using a timer, but it would be waste when a HW scheduler has this finite >>> wait time option build in. Also the “a la carte” principle fits here: user >>> can use the scheduler API without the timer API, if he does not really need >>> timers, just a way to break scheduler to from waiting for ever. >>> >>> >>> >>> Application may use this e.g. to poll some other (non-ODP) resource when >>> it seems that ODP side (of the application) is lightly loaded (e.g. no >>> single event in last 100ms). >>> >>> Yes there are probably use cases for a timeout from odp_schedule. But >>> the examples given below (e.g. timeout receiving some packet) are not >>> valid, such cases should be handled with timers. The timeout is an event >>> itself that should be scheduled by the scheduler so that the proper >>> synchronisation (e.g. accessing some state associated with the queue) can >>> be achieved. If odp_schedule() timeouts and returns without an event, the >>> application should *not* start doing packet processing. Scheduler >>> timeouts are for other types of application background processing and >>> maintenance. >>> >>> >>> >>> >>> >>> Yes, the scheduler timeout should not be used for driving bulk of the >>> ODP event/packet processing. It enables integration of non-ODP SW (which >>> don’t produce events), or driving back ground processing (started only when >>> app is idling). >>> >>> >>> >>> -Petri >>> >>> >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > >
The patch in question is transformed to new one: [lng-odp] [Patch] linux-generic: odp_schedule: fix odp_schdule_wait_time Please, review. On 07.09.15 17:19, Savolainen, Petri (Nokia - FI/Espoo) wrote: > *From:*ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org] > *Sent:* Monday, September 07, 2015 4:51 PM > *To:* Savolainen, Petri (Nokia - FI/Espoo) > *Cc:* Bill Fischofer; LNG ODP Mailman List > *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time check > > On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia.com <mailto:petri.savolainen@nokia.com>> wrote: > > Scheduler timeout (wait time) enables application to wait on a schedule call, for an finite time. Otherwise application would need to wait infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also using a timer, but it would be waste when a HW scheduler has this finite wait time option build in. Also the “a la carte” principle fits here: user can use the scheduler API without the timer API, if he does not really need timers, just a way to break scheduler to from waiting for ever. > > Application may use this e.g. to poll some other (non-ODP) resource when it seems that ODP side (of the application) is lightly loaded (e.g. no single event in last 100ms). > > Yes there are probably use cases for a timeout from odp_schedule. But the examples given below (e.g. timeout receiving some packet) are not valid, such cases should be handled with timers. The timeout is an event itself that should be scheduled by the scheduler so that the proper synchronisation (e.g. accessing some state associated with the queue) can be achieved. If odp_schedule() timeouts and returns without an event, the application should *not* start doing packet processing. Scheduler timeouts are for other types of application background processing and maintenance. > > Yes, the scheduler timeout should not be used for driving bulk of the ODP event/packet processing. It enables integration of non-ODP SW (which don’t produce events), or driving back ground processing (started only when app is idling). > > -Petri > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
https://lists.linaro.org/pipermail/lng-odp/2015-September/015093.html On 09.09.15 13:24, Ivan Khoronzhuk wrote: > The patch in question is transformed to new one: > [lng-odp] [Patch] linux-generic: odp_schedule: fix odp_schdule_wait_time > Please, review. > > On 07.09.15 17:19, Savolainen, Petri (Nokia - FI/Espoo) wrote: >> *From:*ext Ola Liljedahl [mailto:ola.liljedahl@linaro.org] >> *Sent:* Monday, September 07, 2015 4:51 PM >> *To:* Savolainen, Petri (Nokia - FI/Espoo) >> *Cc:* Bill Fischofer; LNG ODP Mailman List >> *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time check >> >> On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia.com <mailto:petri.savolainen@nokia.com>> wrote: >> >> Scheduler timeout (wait time) enables application to wait on a schedule call, for an finite time. Otherwise application would need to wait infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also using a timer, but it would be waste when a HW scheduler has this finite wait time option build in. Also the “a la carte” principle fits here: user can use the scheduler API without the timer API, if he does not really need timers, just a way to break scheduler to from waiting for ever. >> >> Application may use this e.g. to poll some other (non-ODP) resource when it seems that ODP side (of the application) is lightly loaded (e.g. no single event in last 100ms). >> >> Yes there are probably use cases for a timeout from odp_schedule. But the examples given below (e.g. timeout receiving some packet) are not valid, such cases should be handled with timers. The timeout is an event itself that should be scheduled by the scheduler so that the proper synchronisation (e.g. accessing some state associated with the queue) can be achieved. If odp_schedule() timeouts and returns without an event, the application should *not* start doing packet processing. Scheduler timeouts are for other types of application background processing and maintenance. >> >> Yes, the scheduler timeout should not be used for driving bulk of the ODP event/packet processing. It enables integration of non-ODP SW (which don’t produce events), or driving back ground processing (started only when app is idling). >> >> -Petri >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >
diff --git a/test/validation/scheduler/scheduler.c b/test/validation/scheduler/scheduler.c index 788f5c7..42f889a 100644 --- a/test/validation/scheduler/scheduler.c +++ b/test/validation/scheduler/scheduler.c @@ -84,7 +84,7 @@ void scheduler_test_wait_time(void) wait_time = odp_schedule_wait_time(0); - wait_time = odp_schedule_wait_time(1); + wait_time = odp_schedule_wait_time(100); CU_ASSERT(wait_time > 0); wait_time = odp_schedule_wait_time((uint64_t)-1LL);
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, Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> --- test/validation/scheduler/scheduler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)