From owner-freebsd-net@FreeBSD.ORG Tue Apr 19 09:49:38 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 2D94316A4CE for ; Tue, 19 Apr 2005 09:49:38 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CAAE43D5A for ; Tue, 19 Apr 2005 09:49:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 46468 invoked from network); 19 Apr 2005 09:51:51 -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 09:51:51 -0000 Message-ID: <4264D430.D39B81D0@freebsd.org> Date: Tue, 19 Apr 2005 11:49:36 +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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 09:49:38 -0000 Gleb Smirnoff wrote: > > Dear networkers, > > we are working on fixing LORs in if_link_state_change() path, and > adding possibility to call if_link_state_change() pseudorecursively, > when link of interface depends on link of the other. > > I'm posting this patch for wider review. An important point about it > is that, if several link events occur VERY quickly, only the last one > will be processed. I don't know of any software that will be broken by > such behavoir. If you know some, please tell me. I assume this is per interface and not for all interfaces together. You have to be careful here indeed. If the link is rapidly flapping then you only want to report changes in status. For example when it going down, up, down and all these events got queued it doesn't make sense to report down->down. This could indeed confuse some tools and isn't very useful. Either you check the first event vs. the last one if there is a change in state or you just take the events as trigger to have a look at the interface status when the ithread runs. There however you'd have to track the previous state to detect changes. -- Andre