[Olsr-dev] Dynamic adding of interfaces
Thu Apr 12 12:33:18 CEST 2012
On Thu, Apr 12, 2012 at 11:55 AM, Mitar <(spam-protected)> wrote:
> On Thu, Apr 12, 2012 at 11:15 AM, Markus Kittenberger
> <(spam-protected)> wrote:
> > is to define many interfaces in olsrd.conf that do not exist,.. (-;
> > e.g. put a interface list of e.g. tap0 .. tap100 into olsrd.conf
> There is no way to specify for example "tap+" like any interface which
> starts with "tap"?
> > so maybe the olsrd interface polling will slow down quadratically, as
> > has an interface list, and the kernel too. (and uses it for for name to
> > translations of interfaces)
> Yes, and it probably has to map from name to ID all the time, because
> interface could change in mean-time (replaced with some other tunnel),
> but with the same name.
with the netlink listener this is no issue anyways (not sure if it was one
imho the best (for sane performance on really many interfaces) would be to
remove the polling, and make sure the netlink listeners alone really handle
all possible changes.
(handling adding and removing of interfaces is easy via netlink events, but
polling also checks for addresses (is easy via netlink too) and some other
settings, and i guess they are (beside just keeping polling in olsrd for
safety) the reason why we still poll the interfaces)
> How does it "subscribe" to changes?
olsrd more or less listens to the netlink events u can listen to in shell
ip monitor link
it could subscribe to more (e.g. ip monitor all)
> By interface name or interface ID?
afair it just subscribes to all interface (=RTMGRP_LINK) events
> Does Linux API provides some way of saying to listen for all such and
> such interfaces?
don't think so. (a listener can just select which multicast groups it wants
to join, e.g. RTMGRP_LINK or ROUTE or NEIGH or IFADDR ...)
but filtering the events in olsrd after receive is not that hard.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Olsr-dev