All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Updegraff <dave@cray.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] multicast tftp: RFC2090
Date: Fri, 18 May 2007 20:52:36 -0500	[thread overview]
Message-ID: <464E5864.7030203@cray.com> (raw)
In-Reply-To: <464E524C.7040706@gmail.com>

Jerry

IMHO.. its a no-brainer: it costs almost nothing, adds _very_ litte
code, incurs no penatly for FTP servers that dont support it or that
have no other concurrent downloaders... but has a _H_U_G_E_ impact where
its usefull.

I.e. to my view, RCF7090 should be _the_ tftp protocol.  All upside, no
downside that I see.  Aside -- of course! -- from the bugs we have not
yet found in that patch. -;)


> David Updegraff wrote:
>> Ok; here my mulicast TFTP patch.  Have had the opportunity to test with
>> both the RTL8139 and TSEC ethernet drivers, with up to a dozen clients
>> concurrent.
>>
>> In a way I'm tempted to simply remove the #if CONFIG_RFC7090 clutter as
>> it is benign if you happen to be talking to a non-multicast tftp server;
>> and would make things rather more readable.  But too timid...
>>
>> -dbu.
> 
> Hi Dave,
> 
> Interesting, not as much change needed as I would have guessed.
> 
> Now I'm dying of curiosity... what is your impression of the usefulness
> of RFC7090?  It always struck me as a lab curiosity: in fairly
> artificial cases where a bunch of CPU boards are powered up
> simultaneously...
> * a room full of machines with a master breaker
> * a rack of CPUs
> it would be a big win, but that is a fairly unusual setup in the areas I
> hang out in.
> 
> On the other hand, we have a customer that currently has up to 4 units
> in a rack, and in the future possibly more units in a rack, that could
> possibly benefit from RFC2090.
> 
> Best regards,
> gvb

  reply	other threads:[~2007-05-19  1:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-24 15:19 [U-Boot-Users] multicast tftp: RFC2090 David Updegraff
2007-04-24 16:27 ` Wolfgang Denk
2007-04-24 16:27 ` Ben Warren
2007-04-24 16:34   ` David Updegraff
2007-05-01 15:29     ` David Updegraff
2007-05-01 16:16       ` Andy Fleming
2007-05-01 16:41         ` David Updegraff
2007-05-01 19:00           ` Andy Fleming
2007-05-18 17:05             ` David Updegraff
2007-05-19  1:26               ` Jerry Van Baren
2007-05-19  1:52                 ` David Updegraff [this message]
     [not found] <1181312200.8300.81.camel@saruman.qstreams.net>
2007-06-08 15:24 ` Ben Warren
2007-06-08 15:39   ` Wolfgang Denk
2007-06-08 15:41     ` David Updegraff
2007-06-08 18:35     ` Ben Warren
2007-06-08 18:48       ` Wolfgang Denk
2007-06-08 18:51         ` Ben Warren
2007-06-08 19:31           ` David Updegraff
2007-06-11 15:41             ` David Updegraff
2007-06-11 20:29               ` Wolfgang Denk

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=464E5864.7030203@cray.com \
    --to=dave@cray.com \
    --cc=u-boot@lists.denx.de \
    /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.