vrnetlab
vrnetlab copied to clipboard
vrnetlab
Lower CPU & RAM for vMX vFPC
According to https://twitter.com/RobinGilijamse/status/817683918824570880 it should be possible to run the vMX vFPC with 1 CPU core and as little as 512MB RAM. Let's try it out!
I have no problem lowering the default CPU core value since vrnetlab isn't meant for fast packet forwarding. When it comes to RAM however it might be nice to still be able to load large tables so we should think twice about the amount of memory we give it. Perhaps we can have an argument for it!?
I've managed to run it on two cores (but with 5 virtual), but it doesn't really lower the cpu usage.
It might run with fever cores, but if it takes the same amount of instruction cycles there is little to gain.
So it turns out this is not with the normal vPFE / vFPC but with something called "RIOT" which is only available in some 14 version and 15.1. It's not supported at all but, as I understand it, was built for internal Juniper development purposes.
@htj right so 5 virtual CPU means 2 for RE and 3 for forwarding plane, or!? And you can pin those virtual CPU cores to fewer physical cores, thus reducing real CPU usage. The vMX forwarding plane busy loops and DPDK polls to achieve high performance but in our scenarios we don't need this, thus if there would be a way to give it fewer cores I do indeed think it would lower CPU usage. With busy polling it will simply consume as many cores as it is given....
Hi (sorry for the response time, mostly working in batch mode right now)
So it wasn't really in purpose I did this :-). I mostly work within a linux vm on os x, and I only map in two cores through vmware because stuff gets weird if i map in more (something with linux seeing them as real cores and not hyperthreaded ones I assume).
I just tried it out. With a 2 core linux vm, vmx will do 100%-130% in the vm, and a bit more reported in os x. This makes my 13" macbook pro audible, but it isn't noisy, and it seems to work.
Logging into the debian docker image, I can only see two cpus there. I haven't tried moving any real traffic though.
As far as I can recall this is better than last time I tried it out, not sure if something was changed. It seems useful on laptop now.
But I think forcing it onto a single core or similar might actually be good.
The following seems to do the trick quite nicely:
docker run -d --privileged --cpu-period=50000 --cpu-quota=35000 vr-vmx:15.1F4.15
This will limit the vmx container to 70% cpu time, and it seems to work.
The downside is significantly longer start-up time, but the control plane seems to work nicely once up.
I haven't done any data plane tests. I do get some error messages in syslog about processing hogging some resources. Not sure if it has any impacts on data plane processing.