public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ben Warren <biggerbadderben@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/4] Network defrag
Date: Wed, 12 Aug 2009 13:53:34 -0700	[thread overview]
Message-ID: <4A832BCE.9060100@gmail.com> (raw)
In-Reply-To: <200908121653.23925.rgetz@blackfin.uclinux.org>

Robin Getz wrote:
> On Wed 12 Aug 2009 16:05, Ben Warren pondered:
>   
>> Hi Robin,
>>
>> Robin Getz wrote:
>>     
>>> On Mon 10 Aug 2009 15:57, Ben Warren pondered:
>>>   
>>>       
>>>> Robin Getz wrote:
>>>>     
>>>>         
>>>>> Thanks to Alessandro for putting it together.
>>>>>
>>>>> Feel free to add my Signed-off (once the docs have been updated
>>>>> explaining what this is all for).
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I'll do that.  Thanks for all your help.
>>>>     
>>>>         
>>> Some info for the docs, when I was troubleshooting a Ubuntu 9.04 install.
>>> ======
>>>
>>> It appears that some tftp servers (the older BSD version,
>>> Debian's "tftpd") doesn't support RFC 2348 (blksize), and always use
>>> a block size of 512 :( You  need to make sure that you install the 
>>> the Peter Anvin version, which does support  RFC 2348, and blksize up
>>> to 65,464 bytes (Debian's "tftpd-hpa"):
>>> http://www.kernel.org/pub/software/network/tftp/ 
>>>   
>>>       
>> Maybe it would make sense to have a message printed if the user 
>> specifies a higher blocksize but the TFTP server doesn't respond to the 
>> 'blksize' request.  Thoughts?
>>     
>
> It doesn't happen today...
>
>   
Obviously.  I'm asking if you think it would be helpful.
> We request 1468 (today), and if don't get an respose to the blksize request, 
> it falls back to 512 (with the BSD tftpd) - no message to the user - it just 
> takes longer, and people complain about a crappy network driver...
>
> To me - this is independent of the defragmentation patch. If we request 1468 
> (MTU) or 1469 (which will be fragmented) - the logic in tftp.c is the same...
>
>   
Agreed.  The code to request 'blksize' has been in place for a while, 
but may be more relevant now that we can have blocks MUCH bigger than 
the default.
> There is already a debug("Blocksize ack... in the code - so I'm assuming that 
> if someone wanted to figure it out - they just need to turn on DEBUG in 
> tftp.c - rather than printing it out all the time...
>
>   
Sure, if you don't mind re-compiling.  I think it might be an 
opt-outable message via puts_quiet()
> -Robin
>   
regards,
Ben

  reply	other threads:[~2009-08-12 20:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-07 11:58 [U-Boot] [PATCH 0/4] Network defrag Alessandro Rubini
2009-08-07 11:58 ` [U-Boot] [PATCH 1/4] net: defragment IP packets Alessandro Rubini
2009-08-07 11:59 ` [U-Boot] [PATCH 2/4] tftp: get the tftp block size from config file and from the environment Alessandro Rubini
2009-08-07 11:59 ` [U-Boot] [PATCH 3/4] nfs: accept CONFIG_NFS_READ_SIZE from config file Alessandro Rubini
2009-08-07 11:59 ` [U-Boot] [PATCH 4/4] arm nomadik: activate defrag choose 4k transfer block size Alessandro Rubini
2009-08-08  9:50 ` [U-Boot] [PATCH 0/4] Network defrag Ben Warren
2009-08-10 19:51   ` Robin Getz
2009-08-10 19:57     ` Ben Warren
2009-08-12 15:48       ` Robin Getz
2009-08-12 20:04         ` Wolfgang Denk
2009-08-13 15:44           ` Robin Getz
2009-08-12 20:05         ` Ben Warren
2009-08-12 20:53           ` Robin Getz
2009-08-12 20:53             ` Ben Warren [this message]
2009-08-12 21:30               ` Wolfgang Denk
2009-08-13 21:47                 ` Robin Getz
2009-08-13 22:01                   ` Wolfgang Denk
2009-08-17 17:15                     ` Robin Getz
2009-08-17 19:05                       ` Wolfgang Denk
2009-08-17 19:55                         ` Robin Getz
2009-08-17 20:20                           ` Wolfgang Denk
2009-08-17 20:35                             ` Robin Getz
2009-08-10 19:59     ` Wolfgang Denk
2009-08-17 17:21   ` Robin Getz
2009-08-17 19:06     ` 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=4A832BCE.9060100@gmail.com \
    --to=biggerbadderben@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox