[U-Boot] [PATCH v5 1/1] NET: Improve TFTP booting performance when CONFIG_USB_KEYBOARD

[Stephen Warren]

On 07/09/2013 09:48 PM, Jim Lin wrote:
> On Tue, 2013-07-09 at 06:17 +0800, Joe Hershberger wrote:
>> Hi Jim and Stephen,
>>
>> On Wed, Jul 3, 2013 at 11:01 PM, Jim Lin <jilin at nvidia.com> wrote:
>>> TFTP booting is slow when a USB keyboard is installed and
>>> CONFIG_USB_KEYBOARD is defined.
>>> This fix is to change Ctrl-C polling to every second when NET transfer
>>> is running.

>>> diff --git a/net/net.c b/net/net.c
>>> index df94789..ec88b02 100644
>>> --- a/net/net.c
>>> +++ b/net/net.c
>>> @@ -322,6 +322,11 @@ int NetLoop(enum proto_t protocol)
>>>  {
>>>         bd_t *bd = gd->bd;
>>>         int ret = -1;
>>> +#ifdef CONFIG_USB_KEYBOARD
>>> +       unsigned long ctrlc_t_start;
>>> +       unsigned long ctrlc_t;
>>> +       int ctrlc_result;
>>> +#endif
>>>
>>>         NetRestarted = 0;
>>>         NetDevExists = 0;
>>> @@ -472,7 +477,24 @@ restart:
>>>                 /*
>>>                  *      Abort if ctrl-c was pressed.
>>>                  */
>>> +#ifdef CONFIG_USB_KEYBOARD
>>
>> It seems this is the result of the USB Keyboard behavior.  Why is it a
>> good idea to litter the TFTP code with this unrelated code?  It seems
> 
> So far this is the best place to resolve this issue.

I'm not convinced; the previous versions of the patch modified the USB
keyboard driver, which seems a much better place to put the bulk of the
code.

Now, it may be a good idea to have other code, such as the network loop,
set a flag to tell the USB keyboard code (or other code) when some more
performance-sensitive/real-time operation is going on with CTRL-C
polling active, so that the USB keyboard code knows when to rate-limit
its activity.

>> the very same check could be down inside of ctrlc() somewhere that is
>> at least console I/O related.  Besides, having it in a common place
>> will allow any operation that accesses the keyboard to benefit from
>> not hanging up on slow USB stuff.
>>
>> It also seems that it should depend on what the actual source of the
>> stdin is, not just if you compiled in CONFIG_USB_KEYBOARD support.
> 
> This issue only goes with USB keyboard installed and CONFIG_USB_KEYBOARD
> defined. Therefore compiled in CONFIG_USB_KEYBOARD support.
> Non-usb-keyboard doesn't have such issue.

Joe's point is that this new code should not be activated when "USB
keyboard support is compiled in", but rather when "USB keyboard support
is actively in use". The difference is that simply because
CONFIG_USB_KEYBOARD is set does not imply that the USB keyboard must be
used; the stdin environment variable need not always contain "usbkbd".
(In fact, removing that string from stdin is how I work around this
issue for now...)

>> Again, something that belongs in the console source.
>>
>>> +               /*
>>> +                * Reduce ctrl-c checking to 1 second once
>>> +                * to improve TFTP boot performance.
>>> +                */
>>> +               if (ctrlc_t_start > get_timer(0))
>>> +                       ctrlc_t_start = get_timer(0);
>>> +               ctrlc_t = get_timer(0) - ctrlc_t_start;
>>
>> Why is it preferable to do the subtraction yourself instead of letting
>> get_timer() do it?  I.e. what compelled did you change this from v4?
> 
> As Wolfgang Denk said in another mail, 
> "An exception is "arch/arm/cpu/sa1100/timer.c" which does not respect
> the "base" argument at all, i. e. which is broken.".
> 
> So this v5 patch uses get_timer(0), like other code did in this file.

That's a bug in the sa1100 timer code. The sa1100 timer code should be
fixed; other code shouldn't have to work around it being broken.

>>> +               if (ctrlc_t > CONFIG_SYS_HZ) {
>>
>> Why is hard-coding it to 1 second a good idea?
>>  Is that really how unresponsive it has to be to not
>>  significantly impact TFTP boot time?
> 
> Do you want me to add a CONFIG setting to have this time adjustable?
> I was thinking "1 second" checking on Ctrl-C should be fine while TFT
> boot is running.

1s polling seems fine to me. If someone else wants something different,
presumably they can add a config option for it?