On Tue, Jan 12, 2016 at 11:12 PM, Alexandru Ardelean <ardeleana...@gmail.com> wrote: > On Tue, Jan 12, 2016 at 9:25 PM, Alexandru Ardelean <ardeleana...@gmail.com> > wrote: > >> On Tue, Jan 12, 2016 at 6:23 PM, Ben Pfaff <b...@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.
Why not use the upstream kernel module? The out of tree kernel module is primarily a backport which people use to get newer features on older kernels. If you are using newer kernels than the OVS release then that's not really a concern. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
