> On Wed, May 6, 2020 at 11:41 PM Han Zhou <hz...@ovn.org> wrote: > > > > > > > On Wed, May 6, 2020 at 12:49 AM Numan Siddique <num...@ovn.org> wrote: > > >
[...] > > > I forgot to mention, Lorenzo have similar ideas for moving the arp > > resolve lflows for NAT entries to mac_binding rows. > > > > > > > I am hesitate to the approach of moving to mac_binding as solution to this > > particular problem, because: > > 1. Although cost of each mac_binding entry may be much lower than a > > logical flow entry, it would still be O(n^2), since LRP is part of the key > > in the table. > > > > Agree. I realize it now. Hi Han and Numan, what about moving to mac_binding table just entries related to NAT where we configured the external mac address since this info is known in advance. I can share a PoC I developed few weeks ago. Regards, Lorenzo > > Thanks > Numan > > > > 2. It is better to separate the static and dynamic part clearly. Moving to > > mac_binding will lose this clarity in data, and also the ownership of the > > data as well (now mac_binding entries are added only by ovn-controllers). > > Although I am not in favor of solving the problem with this approach > > (because of 1)), maybe it makes sense to reduce number of logical flows as > > a general improvement by moving all neighbour information to mac_binding > > for scalability. If we do so, I would suggest to figure out a way to keep > > the data clarity between static and dynamic part. > > > > For this particular problem, we just don't want the static part populated > > because most of them are not needed except one per LRP. However, even > > before considering optionally disabling the static part, I wanted to > > understand firstly why separating the join LS would not solve the problem. > > > > >> > > >> > > >> Thanks > > >> Numan > > >> > > >>> > > >>> > 2. In most places in ovn-kubernetes, our MAC addresses are > > >>> > programmatically related to the corresponding IP addresses, and in > > >>> > places where that's not currently true, we could try to make it true, > > >>> > and then perhaps the thousands of rules could just be replaced by a > > >>> > single rule? > > >>> > > > >>> This may be a good idea, but I am not sure how to implement in OVN to > > make it generic, since most OVN users can't make such assumption. > > >>> > > >>> On the other hand, why wouldn't splitting the join logical switch to > > 1000 LSes solve the problem? I understand that there will be 1000 more > > datapaths, and 1000 more LRPs, but these are all O(n), which is much more > > efficient than the O(n^2) exploding. What's the other scale issues created > > by this? > > >>> > > >>> In addition, Girish, for the external LS, I am not sure why can't it > > be shared, if all the nodes are connected to a single L2 network. (If they > > are connected to separate L2 networks, different external LSes should be > > created, at least according to current OVN model). > > >>> > > >>> Thanks, > > >>> Han > > >>> _______________________________________________ > > >>> discuss mailing list > > >>> disc...@openvswitch.org > > >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > _______________________________________________ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
signature.asc
Description: PGP signature
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
