В Thu, 12 Feb 2015 15:25:08 +0100 Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> пишет:
> On Thu, Feb 12, 2015 at 12:52:00PM +0000, Rauta, Alin wrote: > > > Yes, but the updates need to be done for all links and I'm not sure > > > adding this is a good thing. > > > I'm now having 64 links on the switch and I need the failure detection in > > > networkd to be quite fast because however even now it's probably slower > > > due to evaluating dynamically the BindCarrier strings when comparing this > > > with the previous solution with an UFD group monitoring some interfaces > > > and with some internal counters knowing exactly when to issue "link_down" > > > for an interface. So adding "bound_by" and "bound_to" makes the solution > > > even slower. > > > > > How many times per second will you be avaluating this? > > Each time an event happens: a link appears, disappears, changes flags or > > names. > Yes, I know the causes. I'm asking how often they can realisticly occur. > You misunderstand. It is not how often they occur but how fast reaction is. When (final) uplink goes down we want to bring dependent interfaces down as soon as possible. > > > Besides this, having only one function > > > "sd_network_link_get_carrier_bound_to" makes also sense because only the > > > behavior of "bond_to" links is controlled by this feature. "bound_by" > > > means almost nothing for an interface. A tool like "networkctl" may take > > > into account to display only the "bound_to" links because that's what's > > > relevant. The fact that "networkctl" displays both "bound_to" and > > > "bound_by" it's a good thing, but it doesn't mean each tool should do > > > that. > > > > > If a link goes down, isn't the "bound_by" list useful to look at links > > > which need to be checked and potentiallly brought down? > > It can be useful, that's why "networkctl" has the updates, but are talking > > about the showing functionality or about the run-time "up-down" game > > between interfaces ? > > The latter. > > Zbyszek > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
