Re: DPDK and energy efficiency
A great deal of this discussion could be resolved by the use of a $20
in-line 120VAC watt meter [1] plugged into something as simple as a $500 1U
server with some of the DPDK-enabled network cards connected to its PCI-E
bus, running DANOS.
Characterizing the idle load, average usage load, and absolute maximum
wattage load of an x86-64 platform is excessively difficult or complicated.
[1]
https://www.homedepot.com/p/Kill-A-Watt-Electricity-Monitor-P4400/202196386
On Thu, Mar 4, 2021 at 11:28 AM Etienne-Victor Depasquale
wrote:
> *TL;DR - DPDK applications embody the phrase caveat emptor.*
>
> As Robert Bays put it: "Please ask your open source dev and/or vendor of
> choice to verify."
> On the other hand, I do not recommend taking the following (citing Robert
> Bays again) for granted:
> "But the reality is [open source projects and commercial products] have
> all been designed from day one not to unnecessarily consume power."
>
> This note is presented in two sections.
> Section 1 presents the preamble necessary to avoid misinformation.
> Section 2 presents the survey.
>
> If so inclined, please read on.
>
> *SECTION 1*
> There are three issues at stake:
>
> 1. the ground truth about the power/energy efficiency of (current)
> deployments that use DPDK,
> 2. my choice of words for the first question, as this constitutes the
> claimed source of misinformation, and
> 3. apportionment of responsibility for the attained level of
> power/energy efficiency of a deployment that uses DPDK,
>
> *Issue #1: ground truth on current deployments*
> I base on (a) research papers and (b) Pawel Malachowski's data. Numbered
> references are listed at the end of this e-mail.
>
> [1] investigates software data planes, including OvS-DPDK. Citing directly:
> "DPDK-OVS always works with high power consumption even when [there is] no
> traffic to handle.
> Considering the inefficiency [][in] power, DPDK provides power management
> APIs to compromise
> between power consumption and performance."
> "For DPDK-OVS, due to the feature of DPDK’s Polling Mode Driver (PMD),
> once the first DPDK port is added to vswitchd process,
> it creates a polling thread and polls DPDK device in continuous loop.
> Therefore CPU utilization for that thread is always 100%,
> and the power consumption r[]ises to about 138 Watt"
>
> [2] investigates multimedia content delivery and benchmarks *DPDK-OvS* in
> the process. Citing directly:
> "Even when no traffic was in transit,
> OvS-DPDK consumed approximately three
> times more energy than the other two data
> planes, adding 250 percent energy overhead
> (15.57 W) on top of the host OS."
>
> [3] proposes the use of ACPI P-states and the halt instruction to control
> power consumption,
> in the context of *a bespoke application*. Citing directly:
> "For example, a Xeon(R) E5-2620 v3 dual socket CPU consumes
> about 22W of power when it is idle; but if a DPDK-based software
> router runs on it, the CPU power soars to 83W even
> when no packets arrive. That is a power gap of more than
> 60W."
>
> [4] investigates the energy-efficient use of *Pktgen-DPDK*. Citing
> directly:
> "We find that high performance comes at the cost of high energy
> consumption."
>
> Pawel Malachowski shows a list of cores (13 out of 16) in use by a DPDK
> application
> ("DPDK-based 100G DDoS scrubber currently lifting some low traffic using
> cores 1-13
> on 16 core host. It uses naive DPDK::rte_pause() throttling to enter C1").
> The list shows the cores spending most of their time in C1.
> This means that cores are in a low-power-idle state and therefore not in
> an active (C0) state.
> This shows a power-aware DPDK application.
>
> *Issue #2: my choice of words, as a source of misinformation*
> Issue has been taken with the text of question 1.
> I addressed this to the NANOG community,
> who are busy and knowledgeable.
> I chose, *with hindsight wrongly*, to paraphrase,
> with the expectation that a reader would interpret correctly.
> A better expression, that would still have been terse, would be:
> "Are you aware that *naïve* use of DPDK on a processor core keeps
> utilization at 100% regardless of packet activity?"
>
>
> *Issue #3: apportionment of responsibility for the attained level of
> power/energy efficiency of a deployment that uses DPDK*
> Pawel Malachowski states that "It consumes 100% only if you busy poll
> (which is the default approach)."
>
> Since it is the application that exploits the DPDK API,
> and since the DPDK API promotes run-to-completion (
> https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html),
> then *it is the application that determines power consumption*
> but it is DPDK's poll-mode driver *that poses a real threat to power
> efficiency, if used in "the default approach".*
>
> Robert Bays states:
> "The vast majority of applications that this audience would actually
> install in their networks do not do tight polling all the time and
> therefore don’t consume 100% of the CPU all
Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?
First, take a look at this: https://www.peeringdb.com/asn/18894 Now look at these (or use your own BGP table analysis tools): https://bgp.he.net/AS18894 https://stat.ripe.net/18894 The claimed prefixes announced, traffic levels and POPs appear to have no correlation with reality in global v4/v6 BGP tables. It is also noteworthy that I have inquired with a number of persons I know who are active in network engineering in NYC, and nobody has ever encountered this company.
Re: gnail rejecting logwatch reports
Rejected with what error codes? Let’s carry this off list ... can you send through the full headers ? -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Mar 4, 2021, at 11:11, jimmy keffer wrote: > > i have a server that use gmail for smtp it working excpt its rejecting > my logwatch reports other mail is sending fine the reject page at > google is no help > thanks jimmy
Re: DPDK and energy efficiency
*TL;DR - DPDK applications embody the phrase caveat emptor.*
As Robert Bays put it: "Please ask your open source dev and/or vendor of
choice to verify."
On the other hand, I do not recommend taking the following (citing Robert
Bays again) for granted:
"But the reality is [open source projects and commercial products] have all
been designed from day one not to unnecessarily consume power."
This note is presented in two sections.
Section 1 presents the preamble necessary to avoid misinformation.
Section 2 presents the survey.
If so inclined, please read on.
*SECTION 1*
There are three issues at stake:
1. the ground truth about the power/energy efficiency of (current)
deployments that use DPDK,
2. my choice of words for the first question, as this constitutes the
claimed source of misinformation, and
3. apportionment of responsibility for the attained level of power/energy
efficiency of a deployment that uses DPDK,
*Issue #1: ground truth on current deployments*
I base on (a) research papers and (b) Pawel Malachowski's data. Numbered
references are listed at the end of this e-mail.
[1] investigates software data planes, including OvS-DPDK. Citing directly:
"DPDK-OVS always works with high power consumption even when [there is] no
traffic to handle.
Considering the inefficiency [][in] power, DPDK provides power management
APIs to compromise
between power consumption and performance."
"For DPDK-OVS, due to the feature of DPDK’s Polling Mode Driver (PMD),
once the first DPDK port is added to vswitchd process,
it creates a polling thread and polls DPDK device in continuous loop.
Therefore CPU utilization for that thread is always 100%,
and the power consumption r[]ises to about 138 Watt"
[2] investigates multimedia content delivery and benchmarks *DPDK-OvS* in
the process. Citing directly:
"Even when no traffic was in transit,
OvS-DPDK consumed approximately three
times more energy than the other two data
planes, adding 250 percent energy overhead
(15.57 W) on top of the host OS."
[3] proposes the use of ACPI P-states and the halt instruction to control
power consumption,
in the context of *a bespoke application*. Citing directly:
"For example, a Xeon(R) E5-2620 v3 dual socket CPU consumes
about 22W of power when it is idle; but if a DPDK-based software
router runs on it, the CPU power soars to 83W even
when no packets arrive. That is a power gap of more than
60W."
[4] investigates the energy-efficient use of *Pktgen-DPDK*. Citing directly:
"We find that high performance comes at the cost of high energy
consumption."
Pawel Malachowski shows a list of cores (13 out of 16) in use by a DPDK
application
("DPDK-based 100G DDoS scrubber currently lifting some low traffic using
cores 1-13
on 16 core host. It uses naive DPDK::rte_pause() throttling to enter C1").
The list shows the cores spending most of their time in C1.
This means that cores are in a low-power-idle state and therefore not in an
active (C0) state.
This shows a power-aware DPDK application.
*Issue #2: my choice of words, as a source of misinformation*
Issue has been taken with the text of question 1.
I addressed this to the NANOG community,
who are busy and knowledgeable.
I chose, *with hindsight wrongly*, to paraphrase,
with the expectation that a reader would interpret correctly.
A better expression, that would still have been terse, would be:
"Are you aware that *naïve* use of DPDK on a processor core keeps
utilization at 100% regardless of packet activity?"
*Issue #3: apportionment of responsibility for the attained level of
power/energy efficiency of a deployment that uses DPDK*
Pawel Malachowski states that "It consumes 100% only if you busy poll
(which is the default approach)."
Since it is the application that exploits the DPDK API,
and since the DPDK API promotes run-to-completion (
https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html),
then *it is the application that determines power consumption*
but it is DPDK's poll-mode driver *that poses a real threat to power
efficiency, if used in "the default approach".*
Robert Bays states:
"The vast majority of applications that this audience would actually
install in their networks do not do tight polling all the time and
therefore don’t consume 100% of the CPU all the time."
*Would this audience (an audience of network operators) **truly not be
interested in using OvS-DPDK ?*
*Caveat emptor.*
*SECTION 2: Survey results*
*Q1*
[image: image.png]
*Q2*
[image: image.png]
[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
gnail rejecting logwatch reports
i have a server that use gmail for smtp it working excpt its rejecting my logwatch reports other mail is sending fine the reject page at google is no help thanks jimmy
Re: ROVv6 does not behave the same way as ROVv4: What rookie mistake(s) did I make?
Tue, Mar 02, 2021 at 09:18:06PM +0700, Pirawat WATANAPONGSE via NANOG: > For a “second validator”, which choice is better: second copy of the same > software, or different software altogether? Arrcus ArcIQ has a validator, RTR server, and has monitoring capabilities and support.
