On Thu, Mar 10, 2016 at 1:45 AM, Han Zhou <zhou...@gmail.com> wrote: > This is a great idea!! Just like what ipset has helped for iptables. >
Thanks for the feedback. Yes, ipset was what inspired the idea. :-) > And I agree with the "additional step" (as pointed out by Ryan) that we > should enable this for SB lflow, considering the scaling problem of > lflow_run() we are already facing. > > With this approach, the expanded physical flows on each hypervisor will > still be O(N) for a given port in a group with N ports, but it should have > huge improvement for performance along the path: neutron -> nb -> sb -> > ovn-controller. > > For the downside #1, I wonder why not just have a global address set table > (maybe one for NB and one for SB) instead of one per logical switch? > Security-group needs to be enforced across logical switches anyway. > > For the downside #2, I tend to disagree. It seems more clean for > networking-ovn to add/delete addresses to/from a set when attached/detached > to/from a sec-group without worrying about ACL refreshes. And the flow is > clear so I think it is still straightforward for trouble shooting. > I think my message may have been a bit confusing. The two downsides I mentioned were related to how we might improve the current situation without adding the address-set feature. I agree that a global address-set table makes sense, not per logical switch. That was my intention. I was trying to discuss what we could do today, which is to combine the rules for all ports using the same "remote_group_id" rule on a single logical switch into a single ACL. It's not that important, because I don't like the idea that much anyway. :-) > > Let me know if you need a hand to work together with you on this :) > Thanks! If we move forward with this, an easy way to split up could be for me to write the OVN code and you could help with the Neutron plugin side. How does that sound? > > P.S. > > To further solve the O(N) problem on hypervisor, we can utilize the tunnel > metadata to carry group-id, so that we will need only O(1) physical flows > on each hypervisor. But there will be 2 limitations with the tunnel: > 1. It won't work in bridged networks where there is no tunnel. > 2. It is straightforward to represent a group-id in tunnel metadata, but > sometimes a port can belong to more than one groups, which is not easy to > be encoded in tunnel header, and even harder for matching by openflow rules. > In these 2 cases it can fallback to the address set approach. I will post > a separate thread to describe the end-to-end design for the tunnel metadata > idea (seems not urgent though, now that we have the address set solution). > Thanks for sharing the idea. I look forward to your thread about it. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
