[Top] [All Lists]

Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's

To: Laurent DENIEL <laurent.deniel@xxxxxxxxxxxxx>, hadi@xxxxxxxxxx
Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves
From: Shmulik Hen <shmulik.hen@xxxxxxxxx>
Date: Mon, 11 Aug 2003 17:20:38 +0300
Cc: bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <3F37A331.88EB0B1D@xxxxxxxxxxxxx>
Organization: Intel corp.
References: <E791C176A6139242A988ABA8B3D9B38A014C9474@xxxxxxxxxxxxxxxxxxxxxxx> <1060607079.1050.144.camel@xxxxxxxxxxxxxxxx> <3F37A331.88EB0B1D@xxxxxxxxxxxxx>
Reply-to: shmulik.hen@xxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.4.3
On Monday 11 August 2003 05:07 pm, Laurent DENIEL wrote:
> HP/Compaq/Digital used to have the same approach with their Netrain
> implementation, and from one release of Tru64 UNIX to another, they
> could no longer support resolution ala milli-seconds but only
> seconds due to the move of such "richness" to user space (among
> other things). I am not saying that doing so on Linux will result
> to the same, but a minimal failover policy shall remain in the
> kernel for performance reason ... (or a user space facility could
> exist to *configure* such policy but without direct interaction
> with user space when the kernel has to decide).
> Laurent

That was my point. Thank you for putting it into better words.
If high availbilty and fast failovers are what's needed, why move it 
out of kernel space and put it in an application ? How fast could it 
work compared to a kernel module ? Why need an extra piece of code 
running in user space (daemon?) to monitor a module when the module 
can do that itself ?

If smarter behavior is needed (e.g. falling to eth4 instead of eth1 
when eth0 fails), we can add some priority mechanism to the driver to 
do that when it decides to swap. Otherwise, we'll be devleoping 
applications from now on, not the Linux kernel :)


<Prev in Thread] Current Thread [Next in Thread>