DPDK and energy efficiency

Etienne-Victor Depasquale edepa at ieee.org
Tue Feb 23 07:22:17 UTC 2021


>
> Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption
> by changing the adaptive polling rate.  It doesn’t, per the survey, "keep
> utilization at 100% regardless of packet activity.”
>
Robert, you seem to be conflating DPDK
with DANOS' power control algorithms that modulate DPDK's default behaviour.

Let me know what you think; otherwise, I'm pretty confident that DPDK does:

> "keep utilization at 100% regardless of packet activity.”


Keep in mind that this is a bare-bones survey intended for busy,
knowledgeable people (the ones you'd find on NANOG) -
not a detailed breakdown of modes of operation of DPDK or DANOS.
DPDK has been designed for fast I/O that's unencumbered by the trappings of
general-purpose OSes,
and that's the impression that needs to be forefront.
Power control, as well as any other dimensions of modulation,
are detailed modes of operation that are well beyond the scope of a
bare-bones 2-question survey
intended to get an impression of how widespread DPDK's core operating
inefficiency is.

Cheers,

Etienne

On Mon, Feb 22, 2021 at 10:20 PM Robert Bays <robert at gdk.org> wrote:

> Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption
> by changing the adaptive polling rate.  It doesn’t, per the survey, "keep
> utilization at 100% regardless of packet activity.”  Adaptive polling
> changes in DPDK optimize for tradeoffs between power consumption,
> latency/jitter and drops during throughput ramp up periods.  Ideally your
> DPDK implementation has an algorithm that tries to automatically optimize
> based on current traffic patterns.
>
> In DANOS refer to the “system default dataplane power-profile” config
> command tree for adaptive polling settings.  Interface RX/TX affinity is
> configured on a per interface basis under the “interfaces dataplane” config
> command tree.
>
> -robert
>
>
> > On Feb 22, 2021, at 11:46 AM, Jared Geiger <jared at compuwizz.net> wrote:
> >
> > 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
>
>

-- 
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/20210223/8b7272e3/attachment.html>


More information about the NANOG mailing list