From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 25 Apr 2018 05:01:18 +0000 Subject: [U-Boot] [PATCH v10 3/3] Adding wget In-Reply-To: <2109276801.3390689.1524453754403@mail.yahoo.com> References: <20180414234336.26636-1-DH@synoia.com> <20180414234336.26636-4-DH@synoia.com> <217820715.1487025.1524002336830@mail.yahoo.com> <2109276801.3390689.1524453754403@mail.yahoo.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Duncan, On 22 April 2018 at 21:22, Duncan Hare wrote: > > > ________________________________ >>From: Simon Glass >>To: Duncan Hare >>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 wrote: >>> From: Simon Glass > >>> 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