>From: Simon Glass <s...@chromium.org> >To: Duncan Hare <d...@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 <d...@synoia.com> wrote: >> From: Simon Glass <s...@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 queuesin 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 ofnet_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 TCPand timeout in UDP. Possibly CONFIG_SYS_RX_ETH_BUFFER could come under Kconfig. >Regards, >Simon RegardsDuncan _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
