On Mon, Feb 17, 2014 at 12:23 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx> >> >> Some interfaces do not need to have any IPv4 or IPv6 >> addresses, so enable an option to specify this. One >> example where this is observed are virtualization >> backend interfaces which just use the net_device >> constructs to help with their respective frontends. >> >> This should optimize boot time and complexity on >> virtualization environments for each backend interface >> while also avoiding triggering SLAAC and DAD, which is >> simply pointless for these type of interfaces. > > Would it not be better/cleaner to use disable_ipv6 and then add a > disable_ipv4 sysctl, then use those with that interface? Sure, but note that the both disable_ipv6 and accept_dada sysctl parameters are global. ipv4 and ipv6 interfaces are created upon NETDEVICE_REGISTER, which will get triggered when a driver calls register_netdev(). The goal of this patch was to enable an early optimization for drivers that have no need ever for ipv4 or ipv6 interfaces. Zoltan has noted though some use cases of IPv4 or IPv6 addresses on backends though, as such this is no longer applicable as a requirement. The ipv4 sysctl however still seems like a reasonable approach to enable optimizations of the network in topologies where its known we won't need them but -- we'd need to consider a much more granular solution, not just global as it is now for disable_ipv6, and we'd also have to figure out a clean way to do this to not incur the cost of early address interface addition upon register_netdev(). Given that we have a use case for ipv4 and ipv6 addresses on xen-netback we no longer have an immediate use case for such early optimization primitives though, so I'll drop this. > The IFF_SKIP_IP seems to duplicate at least part of what disable_ipv6 is > already doing. disable_ipv6 is global, the goal was to make this granular and skip the cost upon early boot, but its been clarified we don't need this. Luis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
