DPDK and energy efficiency

Etienne-Victor Depasquale edepa at ieee.org
Mon Feb 22 12:00:04 UTC 2021


Here are a few references.
Strictly speaking, DPDK and SR-IOV are orthogonal. DPDK is intended to
facilitate cloud-native operation through hardware independence. SR-IOV
presumes SR-IOV-compliant hardware.

[1] Z. Xu, F. Liu, T. Wang, and H. Xu, “Demystifying the energy efficiency
of Network Function Virtualization,”
in 2016 IEEE/ACM 24th International Symposium on Quality of Service
(IWQoS), Jun. 2016, pp. 1–10.
DOI: 10.1109/IWQoS.2016.7590429.

[2] S. Fu, J. Liu, and W. Zhu, “Multimedia Content Delivery with Network
Function Virtualization: The Energy Perspective,”
 IEEE MultiMedia, vol. 24, no. 3, pp. 38–47, 2017, ISSN: 1941-0166.
DOI: 10.1109/MMUL.2017.3051514.

[3] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards Power
Efficient High Performance Packet I/O,”
IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 4, pp.
981–996, April 2020,
ISSN:1558-2183. DOI: 10.1109/TPDS.2019.2957746.

[4] G. Li, D. Zhang, Y. Li, and K. Li, “Toward energy
efficiency optimization of pktgen-DPDK for green network testbeds,”
China Communications, vol. 15, no. 11, pp. 199–207, November 2018,
ISSN: 1673-5447. DOI: 10.1109/CC.2018.8543100.


On Mon, Feb 22, 2021 at 12:45 PM Etienne-Victor Depasquale <edepa at ieee.org>
wrote:

> The way I saw, the questions induce the public to conclude that DPDK
>> ALWAYS has 100% CPU usage, which is not true.
>
>
> I don't concur.
>
> Every research paper I've read indicates that, regardless of whether it
> has packets to process or not, DPDK PMDs (poll-mode drivers) prevent the
> CPU from falling into an LPI (low-power idle).
>
> When it has no packets to process, the PMD runs the processor in a polling
> loop that keeps utilization of the running core at 100%.
>
> Cheers,
>
> Etienne
>
> On Mon, Feb 22, 2021 at 12:33 PM Douglas Fischer <fischerdouglas at gmail.com>
> wrote:
>
>> I'm very happy to see interest in DPDK and power consumption.
>>
>> But IMHO, the questions do not cover the actual reality of DPDK.
>> That característic of "100% CPU" depends on several aspects, like:
>>  - How old are the hardware on DPDK.
>>  - What type of DPDK Instructions are made(Very Dynamic as
>> Statefull CGNAT, ou Static ACLs?)
>>  - Using or not the measurements of DPDK Input/Drop/Fowarding.
>>  - CPU Affinity done according to the demand of traffic
>>  - SR-IOV (sharing resources) on DPDK.
>>
>> The way I saw, the questions induce the public to conclude that DPDK
>> ALWAYS has 100% CPU usage, which is not true.
>>
>>
>> Em seg., 22 de fev. de 2021 às 04:30, Etienne-Victor Depasquale <
>> edepa at ieee.org> escreveu:
>>
>>> Hello folks,
>>>
>>> I've just followed a thread regarding use of CGNAT and noted a
>>> suggestion (regarding DANOS) that includes use of DPDK.
>>>
>>> As I'm interested in the breadth of adoption of DPDK, and as I'm a
>>> researcher into energy and power efficiency, I'd love to hear your feedback
>>> on your use of power consumption control by DPDK.
>>>
>>> I've drawn up a bare-bones, 2-question survey at this link:
>>>
>>> https://www.surveymonkey.com/r/J886DPY.
>>>
>>> Responses have been set to anonymous.
>>>
>>> Cheers,
>>>
>>> Etienne
>>>
>>> --
>>> Ing. Etienne-Victor Depasquale
>>> Assistant Lecturer
>>> Department of Communications & Computer Engineering
>>> Faculty of Information & Communication Technology
>>> University of Malta
>>> Web. https://www.um.edu.mt/profile/etiennedepasquale
>>>
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210222/e8c2eb9b/attachment.html>


More information about the NANOG mailing list