On Thu, Sep 15, 2016 at 7:48 AM, Ben Pfaff <b...@ovn.org> wrote: > On Thu, Sep 01, 2016 at 09:56:30AM +0000, Zongkai LI wrote: >> This patch adds default_dhcpv4_options and default_dhcpv6_options columns for >> Logical_Switch, which should help CMS not to calculate and set dhcpv4_options >> and dhcpv6_options columns for lswitch ports on lswitchs one by one, when >> most of lswitch ports on the same lswitch are using the DHCPv4_Options and >> DHCPv6_Options. Default DHCP(v4 and v6) Options should benefit in case >> scalling up and DB synchronization between CMS and OVN NB. >> >> v1 -> v2 >> add ACL lflows support for lswitch ports using default_dhcpvx_options from >> lswitch. >> >> v2 -> v3 >> update ovn dhcpv4 and dhcpv6 tests for lswitch ports using specific dhcp >> options than defualt ones in lswitch. > > The CMS can point the multiple dhcpvx_options column in as many rows as > it likes to the same row in the DHCP_Options table, so I don't know why > this offers an advantage.
Sorry for my poor english, I couldn't get your points well. "The CMS can point the multiple dhcpvx_options column in as many rows as it likes to the same row in the DHCP_Options table", do you mean the CMS can point multiple options in a DHCP_Options row option column ? This patch won't help CMS on that. The deep reason I submitted this patch is, we locate a DHCP_Options row for Logical_Switch_Port.dhcpvx_options to refer by scanning DHCP_Options table to find a row matching some rules we defined. Like "subnet_id" and "port_id" defined in external_ids column, the OpenStack integrator, networking-ovn uses them to locate a certain DHCP_Options row for a port to set its dhcpvx_options. It works, but not necessary for case [1] most ports from the same logical-switch using the same dhcpvx_options, since we will locate the same uuid duplicately. It's possible for CMS to use some cache to store mappings between networks/subnets and DHCP_Options rows uuids, but I don't think this is a CMS-friendly approach. By adding default dhcpvx options in Logical_Switch, CMS will skip the scanning step for ports using the default dhcp options cases, such as creating a new port, logical switch port lost with/without dhcp options lost(or become stale) when DB sync, and logical switch port exist but dhcp options lost when DB sync. This is a option way let CMS to handle dhcp options, it won't change current approach how DHCP_Options and Logical_Switch_Port.dhcpvx_options works. It won't benefit too much scenarios, but at least for case [1] it would. Thanks, Zongkai, LI _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev