netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent DENIEL <laurent.deniel@thalesatm.com>
To: "David S. Miller" <davem@redhat.com>
Cc: hadi@cyberus.ca, jgarzik@pobox.com, shmulik.hen@intel.com,
	bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com
Subject: Re: [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves
Date: Tue, 12 Aug 2003 16:10:49 +0200	[thread overview]
Message-ID: <3F38F569.C1EC7769@thalesatm.com> (raw)
In-Reply-To: 20030812060845.0e0ba2e8.davem@redhat.com

"David S. Miller" a écrit :
> 
> On 12 Aug 2003 08:59:17 -0400
> jamal <hadi@cyberus.ca> wrote:
> 
> > You dont think asking "what if the application dies" is in the same
> > calibre as "what happens when the kernel oopses"?
> 
> Don't sweat it Jamal, some people just don't get it :-)
> 
> Look, people, when userlevel routing daemon dies your system
> effectively stops to route.

That's why in really *safe* systems, we do not use routing daemon
but only static routes ;-)

And there is a BIG difference : 

When user level daemon dies, you have to be sure that some stuff
exists to monitor and recover from that situation (either by 
restarting the faulty deamon (if it could recover in time which
I doubt with the bonding case), or by switching to a new machine
in a fault tolerant configuration). With kernel ooops, there is
NOTHING to do in such in such a fault tolerant systems, since the
machine is unusable (this is the same as a hardware failure).

But people does not understand the constraints of really safe
systems.

> Policy belongs strictly at user space.
> 
> One of the great things about what Jamal spends his time working
> on is finally a strict seperation of the control layer from everything
> else.  And part of this is moving all of the control logic into userspace.
> Once that is accomplished, I can have my toilet flush every time a TCP
> packet is routed through my system and this won't crap up the kernel.
> 
> If you don't see the value in that, perhaps you shouldn't be partaking
> in this discussion :-)

This is OK as long as your kernel and user space stuff remains suitable
for highly fault tolerant systems and which does not require big montains
of user stuff to do the same as a few line of code in the kernel. Remember
the aim of bonding : NIC fault tolerance or load balancing. I am not against
a user space configurable policy for more complex job but the initial aim of 
the bonding shall remain coded in the kernel (and is only usable in the above 
mentioned systems in that way).

Laurent

  reply	other threads:[~2003-08-12 14:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-09 10:29 [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Hen, Shmulik
2003-08-11  2:51 ` jamal
2003-08-11 10:08   ` Shmulik Hen
2003-08-11 13:47     ` jamal
2003-08-11 14:07       ` [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves Laurent DENIEL
2003-08-11 14:20         ` Shmulik Hen
2003-08-11 14:34           ` jamal
2003-08-11 16:25             ` Shmulik Hen
2003-08-11 16:43               ` Jeff Garzik
2003-08-11 17:31                 ` [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Laurent DENIEL
2003-08-11 17:43                   ` Jeff Garzik
2003-08-12  6:31                     ` Laurent DENIEL
2003-08-12 12:59                       ` jamal
2003-08-12 13:08                         ` David S. Miller
2003-08-12 14:10                           ` Laurent DENIEL [this message]
     [not found]                             ` <1060698412.1063.7.camel@jzny.localdomain>
2003-08-12 14:36                               ` Laurent DENIEL
2003-08-12 15:05                                 ` jamal
2003-08-12  2:32                   ` jamal
2003-08-11 21:27                 ` [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves Mark Huth
2003-08-11 21:41                 ` Jay Vosburgh
2003-08-11 23:15                   ` [SET 2][PATCH 2/8][bonding] Propagating master's settings to slaves Shmulik Hen
2003-08-11 23:28                     ` [Bonding-devel] " Jay Vosburgh
2003-08-12  2:36                     ` jamal
2003-08-12  2:33                   ` [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master's settings toslaves jamal
2003-08-12  2:31               ` jamal
     [not found] <E791C176A6139242A988ABA8B3D9B38A0251E69F@hasmsx403.iil.intel.com>
2003-08-12 14:03 ` [Bonding-devel] Re: [SET 2][PATCH 2/8][bonding] Propagating master'ssettings toslaves Shmulik Hen
2003-08-12 14:04   ` David S. Miller
2003-08-12 14:29   ` jamal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F38F569.C1EC7769@thalesatm.com \
    --to=laurent.deniel@thalesatm.com \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=davem@redhat.com \
    --cc=hadi@cyberus.ca \
    --cc=jgarzik@pobox.com \
    --cc=netdev@oss.sgi.com \
    --cc=shmulik.hen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).