[ovs-dev] [PATCH V2] netdev-linux: Make netdev_linux_get_in6() conform to API definition.

Ben Pfaff blp at nicira.com
Fri Jul 24 20:21:13 UTC 2015


Yes, I think we should.

On Fri, Jul 24, 2015 at 11:38:17AM -0700, Alex Wang wrote:
> Okay, just tried on my 12.04, RTNLGRP_LINK does not notify when the ipv4
> address changes...  so, we should join the corresponding mc groups right?
> 
> Thanks,
> Alex Wang,
> 
> On Fri, Jul 24, 2015 at 11:28 AM, Alex Wang <alexw at nicira.com> wrote:
> 
> >
> > On Fri, Jul 24, 2015 at 10:22 AM, Ben Pfaff <blp at nicira.com> wrote:
> >
> >> On Fri, Jul 24, 2015 at 09:59:04AM -0700, Alex Wang wrote:
> >> > I think we should not do the same for get_in4().  If interface is not
> >> > assigned
> >> > with ipv4 address, ioctl function will return errno 99.  Then user could
> >> > later
> >> > assign a valid ip.  But caching error number makes ovs never check
> >> again.
> >> > (unless react to RTNLGRP_LINK notification and mark it as invalid)
> >> >
> >> > This also makes me wondering, if the same thing could happen to
> >> get_in6()?
> >> > How do we cope with ipv6 address change?
> >>
> >> I assumed we would get a notification when the status changes, which
> >> would allow us to mark it as invalid.  If we don't get the right kind of
> >> notification to invalidate our IPv4/v6 address caches, then we either
> >> shouldn't cache them at all or subscribe to the right kind of
> >> notification.
> >>
> >
> > After checking the code, I think we may be fine,
> >
> > I remembered I asked this offline before:
> >
> > We already have the NETLINK_ROUTE nl_sock joining multicast group
> > RTNLGRP_LINK and resetting the cache flags correctly when there is an
> > event.  However, I could not find any documentation at all regarding the
> > multicast groups...  If RTNLGRP_LINK reports both ipv4/6 address change,
> > then we are fine.  If not, we need to also join the proper multicast groups
> > (e.g. RTNLGRP_IPV6_IFADDR, RTNLGRP_IPV4_IFADDR)
> >
> > Do you know more about this?
> >
> > Thanks,
> > Alex Wang,
> >



More information about the dev mailing list