[ovs-dev] [PATCH 2/2] openvswitch: make auto-attach logic disable-able

[Alexandru Ardelean]

On Tue, Jan 12, 2016 at 6:23 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Tue, Jan 12, 2016 at 09:26:35AM +0200, Alexandru Ardelean wrote:
> > But as it turns out, OVS is getting bigger and bigger with each release,
> > which means fewer and fewer devices can support it.
>
> When I run "strip" on the version from master, the binary is about 2 MB
> (on i386).  For version 2.0.0, it was about 1.5 MB.  That's not very
> big, and not too much of an increase.
>

I have about the same sizes for OVS.
And we use strip for builds on OpenWRT.

Let me give a bit more context.
If it's too much email/info, I am sorry. I am trying to explain stuff as
best as I can.
The devices I'm referring to, have about 8 MB of flash.
I know this sounds a bit ridiculous (when viewed from a server class POV),
but it's a pretty common size among embedded devices, due to a price + cost
+ type-of-flash+ volume-of-devices equation.
We also have devices with 256 MB flash, so those don't fit into this
discussion.

And now let me detail how this works.

These 2 files get flashed to the (well) flash
-rw-r--r-- 1 user users 5636096 Jan 12 14:15
openwrt-ar71xx-generic-root.squashfs
-rw-r--r-- 1 user users 1095047 Jan 12 14:15
openwrt-ar71xx-generic-uImage-lzma.bin

The uImage file is the kernel (at a minimum) and lzma-ed.
The root.squashfs file contains kmods, busybox (with sh, and some reduced
env-tools like awk, grep, etc), dhcp client, other stuff and of course OVS
(version 2.4.0), also lzma-ed.
The mips compiler produces smaller binaries than x86 (and most archs).
All this makes having all this functionality fit in 8 MBs.
And there might also be room for a lua interpreter, or maybe even a reduced
Python interpreter, or a web server, etc.

The way all this works is: device boots, bootloader uncompresses kernel and
rootfs and mounts it to RAM, where all this runs  ; except for a few bytes
on the flash which are persistent, to keep configuration between reboots.
128 MB of RAM (which is in my case) is more than sufficient to run all this
; 64 MB would also be sufficient to run all this.
And at a CPU of 700 Mhz (MIPS which is slower than x86), runs pretty
decently.

In general, it's safe to say that a 500k increase on the rootfs, ends up to
around 50k ~ 100k (this is just a guess)

Version 2.5.0 (trunk) adds about 100k-200k when compared to 2.4.0.
And of course, if OVS increases it's binary footprint, there's also an
increase in the RAM footprint (when it runs), but for now it's fine, and I
think for another few versions we can handle this increase in OVS' size.
I'm trying to find a way now to tackle version 4.0, when more stuff gets
added.

There are other ways that I see that could work to run OVS on our setups.
Like loading the OVS binaries through the network directly into RAM.
( Atm, we package the OVS binaries into the FW image )

Another aspect of this discussion is that OVS would (normally) have no
place in such devices (with 8 MB flash), but as it turned out, we've had
OVS there for a few releases of OVS (since around version 2.2) and would
like to (if possible) have it there for quite a few more.

In any case (and to finalize), whatever you (and the OVS community) prefer
is fine by me, and we can adapt for OpenWRT.

Thanks
Alex