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

[Alexandru Ardelean]

On Tue, Jan 12, 2016 at 9:25 PM, Alexandru Ardelean <ardeleanalex at gmail.com>
wrote:

> 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
>

Let's step back a bit, and detail what we need atm.
We need OVS running on the more recent kernels, and [of course] to have it
running on embedded devices with 8 MB of flash.

The LTS version (2.3.2) supports up to kernel 3.10 (? not sure; have to
check), and OpenWRT supports 3.18 and 4.1 with plans to move to 4.3 (or 4.4
; discussions are on-going).
Version 2.4 of OVS supports 4.0 ; and I've backported 4.1 support to it.

I think most people using OpenWRT (including me) would be fine with
backporting support for kernel 4.4 back to LTS OVS.
But then, there would be another few people (also including me) that would
want to try the newer stuff (every once in a while) which may not be in LTS.
[Btw] We usually build the OVS kmod from the OVS repo and use that ; we
don't use the kernel's OVS kmod.

Backporting kernel support sounds like a hassle, in general.
So, in order to satisfy all cases with OVS + OpenWRT (which seems to prefer
the newer kernels) , we usually try to use the most recent version of OVS.
And this brings us back to the discussion about it's increase in size with
each release.