[OpenWrt-Devel] Open vSwitch integration with netifd
Alexandru Ardelean
ardeleanalex at gmail.com
Wed Mar 4 02:15:19 EST 2020
Hey,
The idea isn't really new, and it's been done before, but did not make
it upstream.
See here:
https://openwrt-devel.openwrt.narkive.com/iX384VOa/rfc-rft-netifd-initial-openvswitch-support
Essentially, the OVS integration is a clone of netifd's bridge integration.
The implementation has some popen() calls to OVS utils, because that
was easier to do really quick.
Ideally, you would use libovs to talk to the OVS daemon that doing
popen(), which [I suspect] was one reason for the patch to not be
acceptable.
There was a discussion [internally] about whether OVS would be better
suited as netifd proto-handler vs as a system-ovs.c file.
Proto-handlers can be done in shell completely and are fine to call
other processes.
Also, proto-handlers can be installed when the OVS package gets
installed, so the proto-handler files would sit here:
https://github.com/openwrt/packages/tree/master/net/openvswitch/files
I don't remember a conclusion about it, or whether that could be done
[as a proto-handler].
I think the system-ovs.c approach was chosen to better integrate with
netifd's event handler for bridges [or similar to bridges].
I don't think we dug too deep to compare the 2 approaches.
But I guess the implementation [as done in that patch] should still
work to some degree.
I don't remember what bugs were fixed with it [or which bugs].
Since it wasn't upstreamed, everything was done in an internal repo.
Funny story. Patch [1] was created to accommodate the size reduction for OVS.
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2013-December/278590.html
Before that patch, OVS would link statically libovs into all it's utils.
Not sure how much this helps you.
The current maintainer of the OVS package may have more [recent] ideas/thoughts.
Some personal conclusions:
Depending on what you want to do with OVS, OVS can be useful or not.
We used it more like a replacement for kernel bridges [because in
theory OVS would scale better],
and since we used netifd + uci to configure it, it sometimes made
things more complicated.
The reason is: OVS has it's own control/controller logic; and we never
used it back then.
We wanted to use it implement L2 switches; some things were done via
OVS, STP/RSTP via mstpd, LLDP via lldpd.
And for that, OVS [being used mostly as a replacement for Linux
bridges] took quite a bit more RAM than I would have liked.
100+ bridges would fill up 128 MB or RAM [for example];
But, at the time, it did fit into 8 MB of flash [some basic OpenWrt +
some userland + OVS]. You may need more now.
On Tue, Mar 3, 2020 at 5:12 PM Kevin Mahoney <kevin.mahoney at zenotec.net> wrote:
>
> I am exploring the idea of extending netifd to support Open vSwitch. I'm curious if anyone has thought of doing this, or has looked into what all it would take to do so. From my limited research, it seems that only a new system-xxxx.c would need to be added to netifd while keeping the rest of the logic the same. Please share your thoughts.
>
> Regards,
>
> Kevin Mahoney
>
> ZenoTec LLC
> 720-864-4320
> kevin.mahoney at zenotec.net
> www.zenotec.net
>
> This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments.
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list