Netutils-linux

Good news first

There is optional dmidecode support, now you can see how good your RAM is:


Bad news

Python 2.6 is deprecated so hard, so it's probably impossible to use pytest to run tests in Travis-ci anymore. I tried to jump into details and problem is probably not in pytest or python, but in pip. pip 8.0.1 installed by yum in CentOS 6 installed the latest version of pytest without any problems while pip 9.0.1 refused. I don't know how to set version of pip for python 2.6 environment in Travis, so I just removed it from .travis.yml.
What does it mean? Higher probability of making bugs specific for python 2.6 - some modern syntax usage, etc. But is it a problem?

Main py2.6 users are CentOS 6 users. Where are python3.4 in EPEL in CentOS 6, so it's still possible to use.
Also, there are Carbon Reductor 7 users. Well, most of them have old versions installed already and everything works. In Carbon Reductor 8 I will move netutils-linux from py2.6 env to 3.4 in January when I'll upgrade to a new version (from... 2.0?).

We (Carbon Soft) also offer a help in migrating from Carbon Reductor 7 to Carbon Reductor 8. So probably no one will suffer from bugs (I hope), but feel free to create issues.

Fixed:

- Highlighting of CPU/NIC had been able to break `rss-ladder`
- numa and socket layout were mixed-up
- lscpu output could not be parsed correctly in python3 and everything that needs CPU topology thought that you had only one logical CPU

And WOW, A FEATURE OF YEAR:

- you may pass file with `lscpu -p` output to `network-top` in debugging purposes.

Basic /proc/net/snmp file watcher:


Finished in just one day!

There is much more to do: https://github.com/strizhechenko/netutils-linux/issues/144


Well, the only difference between rps and xps tuning if queue prefix (rx and tx)... So here are [25 lines changed](https://github.com/strizhechenko/netutils-linux/commit/1e9269ff16c2ba64979cb40ab6030e274b158aea) and you are able to distribute packets transmitting between CPUs even with single-queue NIC!

Example:


autoxps eth0
Using mask 'ff' for eth0-tx-0

Autorps didn't work in systems with multiple NUMA-nodes or CPU sockets before, because it had been calculating cpu mask by total cpu count and wasn't aware of CPU/NUMA topology.

It has been rewritten in python. Now you can:

1. Use it on single-queue NICs in multinuma systems. CPU socket/NUMA node to bind network packet processing will be chosen automatically (rss-ladder is able to do it too!) by reading `/sys/class/net/$NIC/device/numa_node` (fallback - 0).
2. `--force` it to work with multiqueue NIC.
3. Pass custom CPU mask. `--cpu-mask=fe`
4. Pass custom CPU list `--cpus 0 2 4 6` (in the end of options).
5. Test it before using by `--dry-run`: it will print something like `Using mask 'fc0' for eth0-rx-0`.
6. Explicitely define socket to bind queues by `--socket=1`. Why would you ever need it? Because you may found out that moving this nic to external NUMA-node gives you better performance than put all your NIC's on the device's local NUMA-node (and you can't put NIC in this NUMA-node's PCI slot right now).

Also I accidentally drop .pylintrc in repo and fixed all small pep8 violations and other code smells that landscape.io was hiding with default settings.

It still works absolutely like the previous bash version. Even the output is the same.
But it has 2 new features: `--offset` and `--cpus`. Also it uses argparse module and it's **much** easier to add new features now.

If you have 2 NICs with 4 queues and 1 socket with 8 cpus, you may be want
distribution like this:

eth0: [0, 1, 2, 3]
eth1: [4, 5, 6, 7]

so run:


rss-ladder eth0
rss-ladder --offset=4 eth1


If you have bugged NIC missing packets while RSS used on multiple CPUs
(it may be caused by DMA/RAM problems) you may use the following workaround:

bind all the NIC queues to **one** cpu, using:


rss-ladder eth0 --cpus 0


you also able to specify multiple cpus, e.g.:


rss-ladder eth0 --cpus 0 1


P.S: `--cpus` should be defined in the end of parameters, after device.