DPDK and energy efficiency

Mon Feb 22 22:02:33 UTC 2021

Thanks Jared; that's very interesting.

Earlier today, I had a private exchange of emails regarding the progressive development of architectures specific to the domain of high-speed networking functions. Your note reinforces the notion that this “hard” partitioning of cores is a key part of the DSA (domain-specific architecture) here.

Sent from my Windows 10 device

From: Jared Geiger
Sent: Monday, 22 February 2021 20:53
To: NANOG
Subject: Re: DPDK and energy efficiency

DANOS lets you specify how many dataplane cores you use versus control plane cores. So if you put a 16 core host in to handle 2GB of traffic, you can adjust the dataplane worker cores as needed. Control plane cores don't stay at 100% utilization. 

I use that technique plus DANOS runs on VMware (not oversubscribed) which allows me to use the hardware for other VMs. NICS are attached to the VM via PCI Passthrough which helps eliminate the overhead to the VMware hypervisor itself.

I have an 8 core VM with 4 cores set to dataplane and 4 to control plane. The 4 control plane cores are typically idle only processing BGP route updates, SNMP, logs, etc.

~Jared

On Sun, Feb 21, 2021 at 11:30 PM Etienne-Victor Depasquale <edepa at ieee.org> wrote:
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210222/060f5749/attachment-0001.html>