[ovs-dev] [PATCH v1] ovn: rename Address_Set to Set to reflect a more broad purpose

Han Zhou zhouhan at gmail.com
Thu Aug 11 07:03:59 UTC 2016


Make sense! Thanks for explain :)

On Wednesday, August 10, 2016, Zong Kai Li <zealokii at gmail.com> wrote:

> On Thu, Aug 11, 2016 at 1:51 PM, Han Zhou <zhouhan at gmail.com
> <javascript:;>> wrote:
> >
> >
> > On Tue, Aug 9, 2016 at 8:55 PM, Zong Kai LI <zealokii at gmail.com
> <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
>



More information about the dev mailing list