All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>
Cc: Russell King <rmk@arm.linux.org.uk>,
	Chris Dukes <pakrat@www.uk.linux.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeff Garzik <jgarzik@pobox.com>, Robin Holt <holt@sgi.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	<netdev@oss.sgi.com>
Subject: Re: Make ipconfig.c work as a loadable module.
Date: 07 Mar 2003 19:03:24 -0700	[thread overview]
Message-ID: <m1fzpylimr.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0303071223480.30312-100000@kenzo.iwr.uni-heidelberg.de>

Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de> writes:

> On Fri, 7 Mar 2003, Russell King wrote:
> 
> > Which version is overly bloated?
> > Which version is huge?
> > Which version is compact?
> 
> ... and the size is not important only because we want to make everything 
> smaller, but because of how it's commonly used (at least in the clustering 
> world from which I come):
> 
> the mainboard BIOS or NIC PROC contains PXE/DHCP client; data is 
> transferred through UDP, with very poor (if any) congestion control. 

Only because the implementations suck.  See etherboot.

> Congestion control means here both extreme situations: if packets don't 
> arrive to the client, it might not ask again, ask only a limited number of 
> times or give up after some timeout; if the server has some faster NIC to 
> be able to handle more such requests, it might also send too fast for a 
> single client which might drop packets. In some cases, if such situation 
> occurs, the client just blocks there printing an error message on the 
> console, without trying to restart the whole process and the only way to 
> make it do something is to press the Reset button or plug in a keyboard... 
> When you have tens or hundreds of such nodes, it's not a pleasure !

But this is all before the kernel is loaded.  Having booted a 1000 node
cluster with TFTP and DHCP.  From a single host with even being in the same
town, I think I have some room to talk.
 
> Booting a bunch of such nodes would become problematic if they need 
> to transfer more data (=initrd) to start the kernel and so network booting 
> would become less reliable. Please note that I'm not saying "ipconfig has 
> to stay" - just that any solution should not dramatically increase the 
> size of data transferred before the jump to kernel code.

Right.  But I would suggest fixing your NBP (what PXE load) which must
be < 64K anyway if you have noticeable reliability problems.  Not that
I even suggest using PXE for production use anyway.  But sometimes
you are stuck with what you can do.

Eric

  reply	other threads:[~2003-03-08  1:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-06 21:10 Make ipconfig.c work as a loadable module Robin Holt
2003-03-06 22:34 ` Alan Cox
2003-03-06 22:11   ` Jeff Garzik
2003-03-06 22:25     ` Russell King
2003-03-06 22:32       ` Jeff Garzik
2003-03-07  0:13       ` Alan Cox
2003-03-06 23:19         ` Russell King
2003-03-07  0:29           ` Alan Cox
2003-03-07  0:08             ` Russell King
2003-03-07  1:29               ` Chris Dukes
2003-03-07  9:42                 ` Russell King
2003-03-07 11:46                   ` Bogdan Costescu
2003-03-08  2:03                     ` Eric W. Biederman [this message]
2003-03-08 10:45                       ` Bogdan Costescu
2003-03-08 16:07                         ` Eric W. Biederman
2003-03-08 16:19                           ` Russell King
2003-03-08 16:48                             ` Eric W. Biederman
2003-03-08 17:05                               ` Russell King
2003-03-08 18:01                                 ` Eric W. Biederman
2003-03-07 13:38                   ` Chris Dukes
2003-03-07 14:29                     ` Russell King
2003-03-07 16:23                       ` Richard B. Johnson
2003-03-09  1:21                         ` Horst von Brand
2003-03-09  8:57                           ` Willy Tarreau
2003-03-07 21:47                   ` William Lee Irwin III
2003-03-07 22:00                     ` Chris Friesen
2003-03-07  7:15             ` Michael Mueller
2003-03-07 12:54               ` Alan Cox
2003-03-07 21:33                 ` Michael Mueller
2003-03-09  4:46                 ` Arnaldo Carvalho de Melo
2003-03-07  9:10             ` Denis Vlasenko
2003-03-07 14:43               ` Charles Cazabon
2003-03-07 15:06                 ` John Bradford

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=m1fzpylimr.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bogdan.costescu@iwr.uni-heidelberg.de \
    --cc=holt@sgi.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=pakrat@www.uk.linux.org \
    --cc=rmk@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.