Hello,
The solution should be "rte_epoll_wait". 10G NIC burst handling with in
"rte_epoll_wait" state(rx-queue number:12), pkt loss rate is about 0.003%.
Patch mail list(http://dpdk.org/ml/archives/dev/2015-February/014191.html)
As for "cpu scaling frequence", I think the better choice should be
leaving it to P-State, since driver-controlling is better than user's
acknowledgement of hardware state.
FYI.
Best Regards,
Peng
On 27 February 2017 at 13:56, Threqn Peng <phyo...@gmail.com> wrote:
> Hey guys,
>
> I have the same problem which have been discussed in January
> 2016(*http://dpdk.org/ml/archives/dev/2016-January/031374.html
> <http://dpdk.org/ml/archives/dev/2016-January/031374.html>*), about intel
> cpu scaling frequency control in linux user space. But it seems no more
> progress/solution relate to this problem until now.
>
> I also checked the example code:"L3 Forwarding with Power Management
> Sample Application" in newest dpdk version (17.02) , no update yet.
>
> Is it true that, newer cpufreq driver p-state only support two
> control-mode: "performance" and "powersave", and we can't do any more about
> cpu working frequency control, for power-saving?
>
> Thanks for your help.
>
> Best Regards,
> Peng
>
