From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 12:21:42 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BF5E16A4CE for ; Tue, 19 Apr 2005 12:21:42 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D39243D46 for ; Tue, 19 Apr 2005 12:21:41 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48611 invoked from network); 19 Apr 2005 12:23:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Apr 2005 12:23:54 -0000 Message-ID: <4264F7D4.F5A9775F@freebsd.org> Date: Tue, 19 Apr 2005 14:21:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20050419064747.GC734@cell.sick.ru> <4264D430.D39B81D0@freebsd.org> <20050419120324.GA5862@cell.sick.ru> <4264F4BC.4F3B57AE@freebsd.org> <20050419121141.GB5862@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sam@FreeBSD.org cc: net@FreeBSD.org Subject: Re: if_link_state_change() patch for review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 12:21:42 -0000 Gleb Smirnoff wrote: > > On Tue, Apr 19, 2005 at 02:08:28PM +0200, Andre Oppermann wrote: > A> Gleb Smirnoff wrote: > A> > A> You have to be careful here indeed. If the link is rapidly flapping > A> > A> then you only want to report changes in status. For example when > A> > A> it going down, up, down and all these events got queued it doesn't > A> > A> make sense to report down->down. This could indeed confuse some > A> > A> tools and isn't very useful. Either you check the first event vs. > A> > A> the last one if there is a change in state or you just take the events > A> > A> as trigger to have a look at the interface status when the ithread > A> > A> runs. There however you'd have to track the previous state to detect > A> > A> changes. > A> > > A> > I do not know any applications which would be confused, yet. Also, while > A> > event coalescing is possible theoretically, I failed to reproduce it. I've > A> > added a debugging printf, so we will see if anyone experiences these > A> > coalescing events at all. > A> > A> It doesn't really make sense, so we better don't do it and document > A> that fact. > > Well, the printf won't hurt anyone. And it is really interesting if this > is practically possible. I don't care about an printf. I just asked Claudio(@openbsd.org) what OpenBGPd is assuming. It doesn't fall over if it gets an up->up or down->down event but they assumed it doesn't happen and the linke state change message will report either all state changes or those where at the time of reporting the state changed relative to the last report. The same assumption is true for the OpenIGPd we are working on at the moment. >From an (routing) application point of view only effective state changes are interesting and only those should be provided. -- Andre