On Wed, Jan 13, 2016 at 6:47 PM, Jesse Gross <je...@kernel.org> wrote:
> 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. > I have thought about it, but never did get around it. It might be worth to give it a try. Thanks Alex _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
