Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Apr 2005 16:11:41 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Andre Oppermann <andre@FreeBSD.org>, sam@FreeBSD.org
Cc:        net@FreeBSD.org
Subject:   Re: if_link_state_change() patch for review
Message-ID:  <20050419121141.GB5862@cell.sick.ru>
In-Reply-To: <4264F4BC.4F3B57AE@freebsd.org>
References:  <20050419064747.GC734@cell.sick.ru> <4264D430.D39B81D0@freebsd.org> <20050419120324.GA5862@cell.sick.ru> <4264F4BC.4F3B57AE@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

[cc'ing Sam, since we together have came to that printf]

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050419121141.GB5862>