Make sense! Thanks for explain :) On Wednesday, August 10, 2016, Zong Kai Li <[email protected]> wrote:
> On Thu, Aug 11, 2016 at 1:51 PM, Han Zhou <[email protected] > <javascript:;>> wrote: > > > > > > On Tue, Aug 9, 2016 at 8:55 PM, Zong Kai LI <[email protected] > <javascript:;>> wrote: > >> > >> This patch renames table Address_Set to Set, Address_Set.addresses to > >> Set.members to reflect a more broad purpose, that we can define other > >> types > >> of sets than address set. > >> > >> Per discussion around [1] and [2], this patch only does rename work on > >> table > >> Address_Set, and consider put future purpose on using table Set, to > create > >> port set which will be used to improve and skinny ACLs, in following > >> pacthes. > >> > >> Since it only renames table Address_Set, and up to now, only address set > >> get > >> supported, so this patch doesn't rename variables and methods which used > >> for > >> address set, such as [3]. > >> > >> [1] http://openvswitch.org/pipermail/dev/2016-August/077121.html > >> [2] http://openvswitch.org/pipermail/dev/2016-August/077224.html > >> [3] > >> > >> https://github.com/openvswitch/ovs/blob/master/ > ovn/controller/lflow.c#L41-L42 > >> > >> https://github.com/openvswitch/ovs/blob/master/ > ovn/controller/lflow.c#L62-L205 > >> > > Hi Zongkai, > > > > The port set is a great idea! But do we really need to rename the > > Address_Set table? Can we just have 2 tables: Address_Set and Port_Set > (and > > we can add more in the future if needed)? If we really want to put them > in > > the same table, then a new column "type" is needed here, right? > > > > Thanks, > > Han > > Haha, Han, you pointed the same thought as I think about it at the first > time :D > > It's expansive to create another table named Port_Set, if we don't > have any other plan for Port_Set than using in ACL, since processing > around Port_Set is so similar to Address_Set. So, to rename/extend > Address_Set to common Set, will keep things simple. > > A new column "type" is a good point, I used it in my another patch > [1], but later I doubt whether it's necessary. Some facts I want to > share: > 1) ovn-controller don't care what kind of data in a set, it do care > whether a set can be found by a macro, a set name. > 2) it's user responsibility to keep all data in a set are in the same > logical type, just like ovn-nb.xml says "A single address set must > contain addresses of the same type.", and I also did a simple test: > ovn-nbctl list address-set as1 > _uuid : 88b2600b-fe4f-4ee0-88ee-3caa68888493 > addresses : ["10.0.0.10", "10.0.0.10/24", > "fdd5:edde:a711:0:f816:3eff:fe08:e810"] > external_ids : {} > name : "as1" > > So, all behaviors are user defined. What data behind a macro/set name, > user defines that. We can add IPv4 addresses strings into set A, and > add set A name as a macro in ip4.dst/ip4.src field in ACL, by this we > can call this set as an address set; or we can add string strings > which are port names in to set B, and add set B name as a macro in > inport/outport field in ACL, and by this, we can call this set as a > port name set. > And yes, bring "type" column can help us to add some verification on > data in a set, but it doesn't matter if we don't have it. > > [1] http://patchwork.ozlabs.org/patch/655463/ > > Thanks and have a nice day. :) > Zongkai, LI > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
