When init params are set to defaults...
odp_init_param_init(&init);
odp_init_global(&instance, &init, NULL);
... this patch causes -15% (about 1Mpps per cpu) packet rate degradation with
l2fwd. The timer poll function shows up as the second highest CPU cycle
consumer on perf. The defaults needs to be less aggressive: a tradeoff between
somewhat improved timer accuracy for some timer using applications vs.
performance degradation for all application using the scheduler (also with the
default inits)...
The patch actually disables the polling when passing NULL as init param. API
defines that NULL and odp_init_param_init(&init) result the same config ("all
defaults"). This implementation mismatch helps now when most applications pass
NULL, and thus timer polling is kept disabled by default.
When contributing to a central piece of data plane code, it would be really
important to measure packet rate before and after the change...
-Petri
From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
Sent: Friday, June 23, 2017 5:23 PM
To: Honnappa Nagarahalli <honnappa.nagaraha...@linaro.org>
Cc: Brian Brooks <brian.bro...@arm.com>; Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com>; lng-odp-forward <lng-odp@lists.linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCH v4] timer: allow timer processing to run
on worker cores
Merged to api-next.
I think this patch is clean and we can do further improvements / tuning later.
Regards,
Maxim.
On 22 June 2017 at 21:48, Honnappa Nagarahalli
<mailto:honnappa.nagaraha...@linaro.org> wrote:
On 22 June 2017 at 10:30, Maxim Uvarov <mailto:maxim.uva...@linaro.org> wrote:
> On 06/22/17 17:55, Brian Brooks wrote:
>> On 06/22 10:27:01, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>> I was asking to make sure that performance impact has been checked also
>>> when timers are not used, e.g. l2fwd performance before and after the
>>> change. It would be also appropriate to test impact in the worst case:
>>> l2fwd type application + a periodic 1sec timeout. Timer is on, but timeouts
>>> come very unfrequently (compared to packets).
>>>
>>> It seems that no performance tests were run, although the change affects
>>> performance of many applications (e.g. OFP has high packet rate with
>>> timers). Configuration options should be set with defaults that are
>>> acceptable trade-off between packet processing performance and timeout
>>> accuracy.
>>
>> If timers are not used, the overhead is just checking a RO variable
>> (post global init). If timers are used, CONFIG_ parameters have been
>> provided. The defaults for these parameters came from the work to
>> drastically reduce jitter of timer processing which is documented
>> here [1] and presented at Linaro Connect here [2].
>>
>> If you speculate that these defaults might need to be changed, e.g.
>> l2fwd, we welcome collaboration and data. But, this is not a blocking
>> issue for this patch right now.
>>
>> [1]
>> https://docs.google.com/document/d/1sY7rOxqCNu-bMqjBiT5_keAIohrX1ZW-eL0oGLAQ4OM/edit?usp=sharing
>> [2] http://connect.linaro.org/resource/bud17/bud17-320/
>>
>
> 1) we have all adjustable configs here
> ./platform/linux-generic/include/odp_config_internal.h
> that might be also needs to be there.
>
That file has all the global config values. These are internal to this
timer implementation, hence they do not need to be moved.
>
> 2) Do we need something special in CI to check different config values?
Nope.
>
> 3) Why it's compile time config values and not run time?
These config values are particular to this timer implementation.
Similar to config values in
./platform/linux-generic/include/odp_config_internal.h, these also
will be compile time constants.
>
> Maxim.
>
>
>>> -Petri
>>>
>>>
>>> From: Maxim Uvarov [mailto:mailto:maxim.uva...@linaro.org]
>>> Sent: Thursday, June 22, 2017 11:22 AM
>>> To: Honnappa Nagarahalli <mailto:honnappa.nagaraha...@linaro.org>
>>> Cc: Savolainen, Petri (Nokia - FI/Espoo)
>>> <mailto:petri.savolai...@nokia.com>; lng-odp-forward
>>> <mailto:lng-odp@lists.linaro.org>
>>> Subject: Re: [lng-odp] [API-NEXT PATCH v4] timer: allow timer processing to
>>> run on worker cores
>>>
>>> Petri, do you want to test performance before patch inclusion?
>>> Maxim.
>>>
>>> On 21 June 2017 at 21:52, Honnappa Nagarahalli
>>> <mailto:mailto:honnappa.nagaraha...@linaro.org> wrote:
>>> We have not run any performance application. In our Linaro connect
>>> meeting, we presented numbers on how it improves the timer resolution.
>>> At this point, there is enough configuration options to control the
>>> effect of calling timer in the scheduler. For applications that do not
>>> want to use the timer, there should not be any change. For
>>> applications that use timers non-frequently, the check frequency can
>>> be controlled via the provided configuration options.
>>>
>>> On 20 June 2017 at 02:34, Savolainen, Petri (Nokia - FI/Espoo)
>>> <mailto:mailto:petri.savolai...@nokia.com> wrote:
>>>> Do you have some performance numbers? E.g. how much this slows down an
>>>> application which does not use timers (e.g. l2fwd), or an application that
>>>> uses only few, non-frequent timeouts?
>>>>
>>>> Additionally, init.h/feature.h is not yet in api-next - so this would not
>>>> build yet.
>>>>
>>>>
>>>> -Petri
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: lng-odp
>>>>> [mailto:mailto:mailto:mailto:lng-odp-boun...@lists.linaro.org] On Behalf
>>>>> Of
>>>>> Honnappa Nagarahalli
>>>>> Sent: Tuesday, June 20, 2017 7:07 AM
>>>>> To: Bill Fischofer <mailto:mailto:bill.fischo...@linaro.org>
>>>>> Cc: lng-odp-forward <mailto:mailto:lng-odp@lists.linaro.org>
>>>>> Subject: Re: [lng-odp] [API-NEXT PATCH v4] timer: allow timer processing
>>>>> to run on worker cores
>>>>>
>>>>> Are you saying we should be good to merge this now?
>>>>>
>>>>> On 19 June 2017 at 17:42, Bill Fischofer
>>>>> <mailto:mailto:bill.fischo...@linaro.org>
>>>>> wrote:
>>>>>> On Mon, Jun 19, 2017 at 4:19 PM, Honnappa Nagarahalli
>>>>>> <mailto:mailto:honnappa.nagaraha...@linaro.org> wrote:
>>>>>>> Hi Bill/Maxim,
>>>>>>> I do not see any further comments, can we merge this to api-next?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Honnappa
>>>>
>>>>
>>>
>
