Yes, actually, we have done some effort and practice to ensure that dvr has
a better performance and stability, but i am not sure whether it would be
accepted, so that's why i say : ("I’m not sure whether the following issue
is problematic…"). in my opinion, i think it's very helpful.2014-10-29 20:36 GMT+08:00 Hly <henry4...@gmail.com>: > > > Sent from my iPad > > On 2014-10-29, at 下午6:33, Maru Newby <ma...@redhat.com> wrote: > > > > > On Oct 29, 2014, at 8:12 AM, Yangxurong <yangxur...@huawei.com> wrote: > > > >> Hi, > >> > >> I’m not sure whether following issue is problematic, and both, our team > do some effort, so I submit two blueprints: > >> [1.] optimize dvr flows: > >> Currently, accurate ovs flows in terms of full mac are used to > communicate among distributed router, but here comes problem : (1)the more > distributed router node, the more flows; (2)different distributed router > across DC cannot communicate through tunnel and additional operation under > same mac prefix configuration. So it would be useful to shift the > complete-matching of mac to fuzzy Matching, like prefix matching, reducing > the number of flows and leading to communicate among different DC though > configuring same mac prefix through tunnel. > >> Link: https://blueprints.launchpad.net/neutron/+spec/optimize-dvr-flows > > > > I think we need to focus on paying down technical debt (both in the code > and on the testing side) related to dvr before we seriously consider the > kind of optimization that you are proposing. I’m also unclear as to why we > would want to pursue a solution to a problem whose severity doesn’t appear > to be clear ("I’m not sure whether the following issue is problematic…"). > > > > DVR stability is the first class for sure, but if the code and logic could > be less and simpler, there is more chance of stability. By my > understanding, since DVR mac range has been configured as a prefix, so > prefix based judgement instead of one by one flow setup triggered by > mesh-like message notifying would simplify the code logic, thus indirectly > contribute to overall stability. Also, it would remove hundreds of flows in > the ovs in a middle scale cluster, very helpful for trouble shooting. > > Wu > > > > > Maru > > > >> > >> [2.]add port timestamp: > >> It would be worth adding timestamp fields including create_at, > update_at and delete_at in the table of port in neutron, so users can > monitor port change conveniently, for example portal or management center > wants to query the ports that have changed or refreshed during the latest > 5sec in a large scale application. If not, it's time-consuming and low > effectiveness. > >> Link: https://blueprints.launchpad.net/neutron/+spec/add-port-timestamp > >> > >> Any response I will appreciate. > >> > >> Thanks, > >> Xurong Yang > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
