netdev.vger.kernel.org archive mirror
 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  2:03 UTC|newest]

Thread overview: 29+ 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-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

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 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).