Tx-no-IPI: initial commit

Change the per-CPU-Tx worker thread from beiing a single thread
that may be migrated by a load balancer to be a set of a per-CPU (pinned)
threads. This way an application thread when it needs to wake a worker it
will wake a worker on the same CPU and thus no IPIs are going to be sent.

 - Move the worker threads initialization into the per-CPU-Tx class (xmitter).
 - Move the initialization code from xmitter::poll_until() to xmitter
   constructor.
 - Name virtio::net tx worker threads as "virtio-tx-0,1,2..."
 - Name vmxnet3 tx worker threads as "vmxnet3-tx-0,1,2..."

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
percpu_xmit: prevent a Tx worker thread from running endlessly on a single CPU

There is a possible situation when a worker thread never releases the
control and sender threads constantly create it a new work (e.g. when
senders create more work than "HW" can handle). In this case worker will
constantly run only on a single CPU creating load disbalance. In order to
handle this case we will check every X packets that we don't stay without
releasing a control for more than Y time. If we do, we will wake the
worker on the CPU "on the right" from our CPU (worker on the last CPU
will wake the one on the first CPU) and this way we will ensure the load
being spread among all CPUs.

We choose X to the a Tx queue size and Y to be 100ms (like a load_balancer period).

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
cli: Move command_filename to util

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
cli: Add help command

Add help command and a new property to commands (desc) which is meant for the
short description when listing all the commands.

Closes #439.

Signed-off-by: Or Cohen <orc@fewbytes.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
cloud-init: Cassandra configuration module

This adds a new "cassandra" section to cloud-init that can be used to
configure Cassandra.

The feature is currently limited to configuring cluster name in user
data as follows:

  cassandra:
      clustername: PekkasCluster

If the module find a "cassandra.yaml.template" file in the filesystem,
it will substitute template marker {{clustername}} with the configured
value.

You can test this with our EC2 simulator by creating an user data file,
starting EC2 simulator with:

  $ sudo scripts/ec2-simulator.py -f cassandra.yaml

then building a cloud-init capable Cassandra image:

  $ make -j16 image=cassandra,httpserver,cloud-init

and starting it with:

  $ ./scripts/run.py

As there's no template file available, cloud-init will warn about it:

  cloud-init: Cassandra configuration:
    'clustername' => 'PekkasCluster'
  cloud-init: warning: '/usr/cassandra/conf/cassandra.yaml.template' template not found.

After adding such a file to the image and changing cluster name to use
{{clustername}} marker, Cassandra starts up with the newly configured
cluster name:

  cloud-init: Cassandra configuration:
    'clustername' => 'PekkasCluster'
  INFO  10:24:56 Hostname: osv.local
  INFO  10:24:56 Loading settings from file:////usr/cassandra/conf//cassandra.yaml
  INFO  10:24:56 Node configuration:[...; cluster_name=PekkasCluster; ...]

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>