On Wed, 1 Apr 2020 21:51:53 +0100 Kevin Traynor <ktray...@redhat.com> wrote:
> On 01/04/2020 14:10, Matteo Croce wrote: > > DPDK polls the packet in a busy loop. This means that CPU constantly spins > > looking for packets, regardless of the network traffic. > > DPDK does this to reduce latency and avoid using interrupts, at expense of > > efficiency: this might consume more processing power and generate more heat > > than needed, potentially increasing the TCO of a DPDK appliance. > > > > Here comes DPDKoin. DPDKoin is a DPDK PMD, which instead of moving > > packets, mines cryptocurrencies. > > DPDKoin just does a few calculations to every poll cycle, this means that > > when the network is loaded, DPDKoin consumes just a few cycles, but when > > there is no traffic, DPDKoin mines currencies in a busy loop. > > The coins are mined with no extra consumption, as the CPU would spin > > anyway. > > > > This is a system running with two 10G cards running with DPDK: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 8223 root 10 -10 260.6g 597516 19100 S 199.8 0.5 0:17.89 testpmd > > > > And this is the same system with a DPDKoin port added: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 9438 root 10 -10 260.6g 598892 19800 S 199.8 0.5 0:19.43 testpmd > > > > As you can see, we don't observe any change in the CPU usage, and besides, > > the earned coins lowers the appliance TCO. > > > > Just for reference, a test run log follows: > > > > $ sudo testpmd --no-huge -m 1024 --no-pci --vdev eth_dpdkoin0 --vdev > > eth_dpdkoin1 > > EAL: Detected 8 lcore(s) > > EAL: Detected 1 NUMA nodes > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > EAL: Selected IOVA mode 'VA' > > EAL: Probing VFIO support... > > testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=203456, size=2176, > > socket=0 > > testpmd: preferred mempool ops selected: ring_mp_mc > > Configuring Port 0 (socket 0) > > Port 0: 4A:50:3C:33:55:21 > > Configuring Port 1 (socket 0) > > Port 1: BA:BB:0A:BB:0C:CA > > Checking link statuses... > > Done > > No commandline core given, start packet forwarding > > io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support > > enabled, MP allocation mode: native > > Logical Core 1 (socket 0) forwards packets on 2 streams: > > RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 > > RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 > > > > io packet forwarding packets/burst=32 > > nb forwarding cores=1 - nb forwarding ports=2 > > port 0: RX queue number: 1 Tx queue number: 1 > > Rx offloads=0x0 Tx offloads=0x0 > > RX queue: 0 > > RX desc=0 - RX free threshold=0 > > RX threshold registers: pthresh=0 hthresh=0 wthresh=0 > > RX Offloads=0x0 > > TX queue: 0 > > TX desc=0 - TX free threshold=0 > > TX threshold registers: pthresh=0 hthresh=0 wthresh=0 > > TX offloads=0x0 - TX RS bit threshold=0 > > port 1: RX queue number: 1 Tx queue number: 1 > > Rx offloads=0x0 Tx offloads=0x0 > > RX queue: 0 > > RX desc=0 - RX free threshold=0 > > RX threshold registers: pthresh=0 hthresh=0 wthresh=0 > > RX Offloads=0x0 > > TX queue: 0 > > TX desc=0 - TX free threshold=0 > > TX threshold registers: pthresh=0 hthresh=0 wthresh=0 > > TX offloads=0x0 - TX RS bit threshold=0 > > libbitcoin 0.1: mining on CPU2 > > libbitcoin 0.1: mining on CPU4 > > --- > > config/common_base | 5 + > > drivers/net/Makefile | 1 + > > drivers/net/dpdkoin/Makefile | 23 + > > drivers/net/dpdkoin/meson.build | 3 + > > drivers/net/dpdkoin/rte_eth_dpdkoin.c | 696 ++++++++++++++++++ > > .../net/dpdkoin/rte_pmd_dpdkoin_version.map | 3 + > > mk/rte.app.mk | 1 + > > 7 files changed, 732 insertions(+) > > create mode 100644 drivers/net/dpdkoin/Makefile > > create mode 100644 drivers/net/dpdkoin/meson.build > > create mode 100644 drivers/net/dpdkoin/rte_eth_dpdkoin.c > > create mode 100644 drivers/net/dpdkoin/rte_pmd_dpdkoin_version.map > > I see you are requesting this for backport to stable branches. While > this is not fixing a specific commit per se, it is clearly fixing a gap > whereby it would be unfair for stable users to miss out on any potential > bonanza. > > Unfortunately there is a blocker due to validation. Normally, we might > be concerned by lack of it, but in this case the concern is that it > might encourage too much validation and many lengthy stress tests that > could impact release dates. > Could we fund the CI lab with this?
