From: Matthew Hall <mhall@mhcomputing.net>
To: "Zhang, Helin" <helin.zhang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor
Date: Thu, 14 Jan 2016 02:44:23 -0500 [thread overview]
Message-ID: <20160114074423.GB15470@mhcomputing.net> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A988A1E@SHSMSX104.ccr.corp.intel.com>
On Thu, Jan 14, 2016 at 07:15:51AM +0000, Zhang, Helin wrote:
> That's disappointing if Skylake is like that. Let's have a learning first,
> and then check if we can fix that. But in addition, DPDK provide interrupt
> based packet receiving mechanism, can it be one of your choice?
Maybe I am wrong. But I could not disprove what the Linux p_state driver
Documentation file and other places claimed, which is that the clockrate
control is no-opped, because the white papers on Intel HWP are not findable in
the Intel website, or by using Google with the operator "site:intel.com".
The IRQ based part is still enabled and works quite well in a very trivial
test so far... but the clockrate callback handlers are null and the governor
setting gets corrupted, both due to failed init of librte_power. So I will
have to rebuild DPDK with the librte_power ACPI + KVM init commented out and
the fastpath clockrate callback functions commented out of course. It is minor
so I can do it to see what will happen.
> If no objection, I will find time later (may be in a month) to investigate
> that. Of cause, please try to investigate that from your side.
Agreed.
> That's always there, for example, DPDK can exit accidently, without caring
> anything. Then you can have the similar issue again.
Of course, it could. But if there was some kind of shutdown function, at least
then I could call it from the signal handler I already have which closes the
ports (this prevents nasty port lockups on virtio-net port DMA memory zones
which can happen on future runs otherwise).
> It seems that you are so important for Intel. :) I don't have Skylake in hand. :(
:) Hahaha... newegg.com to the rescue. I guess we need to be sure there is
some program to test the stuff in DPDK for the new kernels and hardware. It
appears we are pretty far behind now... I saw several threads about things
that were behind just today.
> Regards,
> Helin
Matthew.
next prev parent reply other threads:[~2016-01-14 7:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-06 0:08 Matthew Hall
2016-01-03 7:51 ` Matthew Hall
2016-01-12 15:17 ` Zhang, Helin
2016-01-14 7:03 ` Matthew Hall
2016-01-14 7:11 ` Matthew Hall
2016-01-14 7:15 ` Zhang, Helin
2016-01-14 7:44 ` Matthew Hall [this message]
2017-02-27 5:56 Threqn Peng
2017-03-01 9:22 ` Threqn Peng
2018-03-02 7:18 longtb5
2018-03-02 7:20 ` longtb5
2018-03-05 10:16 ` Hunt, David
2018-03-05 10:48 ` longtb5
2018-03-05 11:25 ` Hunt, David
2018-03-05 12:23 ` longtb5
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=20160114074423.GB15470@mhcomputing.net \
--to=mhall@mhcomputing.net \
--cc=dev@dpdk.org \
--cc=helin.zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).