[ovs-dev] [PATCH 2/2] lib: Show tunnel egress interface in ovsdb

Ethan Jackson ethan at nicira.com
Wed Dec 29 18:07:10 UTC 2010


> 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.

>
> 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.

> 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?

> 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.

Ethan




More information about the dev mailing list