From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: "Pattan, Reshma" <reshma.pattan@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Hunt, David" <david.hunt@intel.com>,
"Ma, Liang J" <liang.j.ma@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] examples/l3fwd-power: add telemetry mode support
Date: Wed, 22 May 2019 10:46:15 +0100 [thread overview]
Message-ID: <22aae3d5-65d7-1175-c1f9-01d83a6853c3@intel.com> (raw)
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F2A460482@irsmsx110.ger.corp.intel.com>
On 21-May-19 3:53 PM, Pattan, Reshma wrote:
>
>
>> -----Original Message-----
>> From: Burakov, Anatoly
>> Sent: Monday, May 20, 2019 2:17 PM
>> To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org
>> Cc: Hunt, David <david.hunt@intel.com>; Ma, Liang J <liang.j.ma@intel.com>
>> Subject: Re: [PATCH v1] examples/l3fwd-power: add telemetry mode support
>>
>
> <snip>
>
>>> ---
>>
>> <snip>
>>
>>> + poll_count = 0;
>>> + prev_tel_tsc = cur_tsc;
>>> + /* update stats for telemetry */
>>> + rte_spinlock_lock(&stats[lcore_id].telemetry_lock);
>>> + stats[lcore_id].ep_nep[0] = ep_nep[0];
>>> + stats[lcore_id].ep_nep[1] = ep_nep[1];
>>> + stats[lcore_id].fp_nfp[0] = fp_nfp[0];
>>> + stats[lcore_id].fp_nfp[1] = fp_nfp[1];
>>> + stats[lcore_id].br = br;
>>> + rte_spinlock_unlock(&stats[lcore_id].telemetry_lock);
>>
>> Locking here seems relatively rare (per-lcore and once every N polls), but any
>> locking on a hotpath makes me nervous. What is the current performance
>> impact of this? Should we bother improving?
>
> The performance impact is negligible, in thousands.
In thousands of packets? Out of?
>
>>>
>>> if (!strncmp(lgopts[option_index].name,
>>> @@ -1869,6 +2068,52 @@ init_power_library(void)
>>> return ret;
>>> }
>>> static void
>>> +update_telemetry(__attribute__((unused)) struct rte_timer *tim,
>>> + __attribute__((unused)) void *arg)
>>> +{
>>
>> I would question the need to put telemetry on a high precision 10ms timer. Is
>> there any reason why we cannot gather telemetry, say, once every 100ms, and
>> why we cannot do so from interrupt thread using alarm API? Using high-
>> precision timer API here seems like an overkill.
>
> The l3-power uses the timers , so followed the same. But I am ok
> to use ALARM api.
Maybe just change the timer period then? 10ms to update telemetry looks
way too often to me. Do we really expect telemetry to be gathered every
10ms?
>
> Thanks,
> Reshma
>
--
Thanks,
Anatoly
next prev parent reply other threads:[~2019-05-22 9:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 18:17 [dpdk-dev] [PATCH v1] examples/l3fwd-power: add telemetry mode support Reshma Pattan
2019-05-20 13:17 ` Burakov, Anatoly
2019-05-21 14:53 ` Pattan, Reshma
2019-05-22 9:46 ` Burakov, Anatoly [this message]
2019-05-22 13:06 ` Pattan, Reshma
2019-05-22 15:16 ` Stephen Hemminger
2019-05-24 9:34 ` [dpdk-dev] [PATCH v2] " Reshma Pattan
2019-05-24 10:14 ` Burakov, Anatoly
2019-06-13 13:44 ` [dpdk-dev] [PATCH v3] " Reshma Pattan
2019-06-24 15:16 ` Thomas Monjalon
2019-06-24 16:48 ` Pattan, Reshma
2019-06-24 16:45 ` [dpdk-dev] [PATCH v4] " Reshma Pattan
2019-06-28 9:53 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22aae3d5-65d7-1175-c1f9-01d83a6853c3@intel.com \
--to=anatoly.burakov@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=liang.j.ma@intel.com \
--cc=reshma.pattan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.