[ovs-dev] [PATCH 2/2] lib: Show tunnel egress interface in ovsdb
Ben Pfaff
blp at nicira.com
Wed Dec 29 18:11:52 UTC 2010
On Wed, Dec 29, 2010 at 01:07:10PM -0500, Ethan Jackson wrote:
> > I infer from netdev_vport_addr_change() that when an address changes the
> > kernel first issues a DELADDR for the old address and then a NEWADDR for
> > the new address. Does it really do that? I would have guessed from
> > what happens elsewhere that it just issues a NEWADDR for the new
> > address, but I haven't actually looked at kernel code here.
>
> I haven't looked at the kernel code, but I have experimentally
> verified that when an address changes a DELADDR is issued before a
> NEWADDR. This makes sense because there would be no way to
> distinguish between changing an interface's address and giving it a
> second address.
OK, sounds fine.
> > Does the kernel issue a DELADDR when a network device is deleted? (Will
> > we "leak" that memory until the next netdev_vport_addr_reset()?)
>
> I'll double check that it gives a DELADDR, if it turns out not to we
> can always force a reset when ovs deletes an interface for whatever
> reason.
OK, sounds fine.
> > It looks like this only considers addresses assigned to network devices.
> > Is that sufficient? Should we be looking at the routing table
> > (e.g. RTM_*ROUTE) instead or in addition?
>
> That's definitely an option, I ended up going this route because it's
> a little bit simpler and I think it's robust enough considering how
> fuzzy the feature is anyways (especially if it evaluates to a bridge
> port). If we use RTM_*ROUTE we will need to maintain an RTM_*ADDR
> created table to allow us to translate kernel interface indicies to
> names as the route code only gives you the numeric index. Do you
> think it's worth the added complexity?
I don't think it's worth it yet.
> > It looks to me like netdev_vport_addr_init() and
> > netdev_vport_addr_destroy() are being called on every creation or
> > destruction of a vport netdev. That doesn't seem right.
>
> Ah oops, I though netdev_vport_create was called once only. I'll just
> refcount it like netdev-linux does.
I'd consider just calling it from the top-level 'init' function for the
netdev vport. (Currently it doesn't define one.) There is no
corresponding 'destroy' function but it's probably not worth worrying
about that.
Thanks,
Ben.
More information about the dev
mailing list