[U-Boot] [PATCH v10 3/3] Adding wget

[Simon Glass]

Hi Duncan,

On 22 April 2018 at 21:22, Duncan Hare <dh at synoia.com> wrote:
>
>
> ________________________________
>>From: Simon Glass <sjg at chromium.org>
>>To: Duncan Hare <dh at synoia.com>
>>Sent: Sunday, April 22, 2018 1:10 PM
>>Subject: Re: [PATCH v10 3/3] Adding wget
>>
>>Hi Duncan,
>
>>On 17 April 2018 at 15:58, Duncan Hare <dh at synoia.com> wrote:
>>> From: Simon Glass <sjg at chromium.org>
>
>>> It has been through patman, and the only errors flagged a packed
>>> structures,
>>> necessary for packed headers.
>
>>It should be possible in the Python test to enable an http server on
>> localhost with a few lines of code, and then connect to it in the test?
>
> Yes server at port 80. The server can be tested with the wget command
which
> can be installed on linux.
> I doubt that loop-back like this will produce the scrambling of packet
order
> which is a feature of push down stacks for packet queues
> in the internet.
>
> The pi is easy to overrun when testing on a low latency network, because
the
> TCP send window size is defined by the number of
> net_rx_buffers, which is controlled the CONFIG_SYS_RX_ETH_BUFFER in
> include.net.h,  which sets PKTBUFSRX at the beginning of include/net.h,
> which in-turn defines a buffer pool in net/net.c, array named
net_pkt_buf.
>
> Hence my comment in a different thread about buffering on the pi. Few of
the
> socs appear to use net_pkt_buf  buffers for net traffic.
>
> If there are too many transmission errors the sending tcp drops the
> connection. My solution to this is to halve the size of
> CONFIG_SYS_RX_ETH_BUFFER until transmission works.
>
> If I was thinking about a buffer pool for in the drivers, I'd implement it
> in net/net.c. Interface "getbuffer," returns a pointer,
> and increments an index to the next net_rx_buffer with no protection for
> overrun. Overrun is managed by ack numbers in TCP
> and timeout in UDP.
>
> Possibly CONFIG_SYS_RX_ETH_BUFFER could come under Kconfig.

Just to be clear, I was wondering about having an automated test. Manual
tests are not very useful since people won't do them. See 'make tests' for
all the test that we currently run. I'm pretty sure you could standard up a
little server, run your wget, then shut it down, all within a pytest test.

Regards,
Simon