[U-Boot] [PATCH] TCP and wget implementation v4

[Joe Hershberger]

On Fri, Jan 5, 2018 at 4:10 PM, Duncan Hare <dh at synoia.com> wrote:
>> >
>> > A note on this TCP implementation. In TCP the transmitting TCP
>> > guarantees delivery of a stream, and the receiving TCP guarantees
>> > ordered of delivery of the stream. In this implementation The
>> > kernel memory buffer and the TCP sequence number is used to order
>> > the stream. for the application, and the application is the kernel
>> > itself. wget is not considered the application, and does receive
>> > packets "out of order."
>>
>> It seems like it would be possible to just store off a packet that is
>> ahead of its neighbor and not call any upper handler until the needed
>> packet arrives. Then all upper layers wouldn't need to know about the
>> reordering.
>
> There is, for u-boot a large number of buffers used on RX, in order
> to have a long work queue  of kernel data.
>
> CONFIG_SYS_RX_ETH_BUFFER 50
>
> The TCP transmit window is approximately 25 such packets, so overruns
> are eliminated.
>
> There are about 3300 kernel data packets in this test kernel, so missing
> a few, 3 to 5, has little impact on elapsed time, and they remain in the
> input buffer pool ahead of the HTTP header,
>
> The only critical order for this implementation is the TCP header.
> Without processing the TCP header we do not know the stream
> address of the first byte of kernel data. It is easy when we know this
> to map TCP stream address to kernel data offset.
>
>> >
>> > Advice on the reset buffer approach are invited. It requires an
>> > interface between the wget application to reset the buffer index.
>>
>> Between wget and what? The TCP implementation? It seems like something
>> that should be abstracted from wget.
>
> wget receives packets without intermediate ordering.
> Ordering data is a function of wget placing the kernel data at the
> correct offset, based of TCP stream location, at the correct memory
> address.
>
> wget is the agent which correctly orders data. There is no
> socket analogue, the abstraction, and a socket's linked list buffer
> reordering, which is the generally recognized reordering point for TCP
> data.
>
> Correct ordering is a primary task of this wget implementation,
> becuse the destination is a kernel image, and this choice very greatly
> simplifies the TCP stack, while reducing code complexity, and limits
> code size.
>
> Reordering would require a new piece of code similar to the fragment
> assemble piece of code in net.h, and that's an amazing, but complex,
> piece of code. My objective was to produce something as
> simple as possible.
>
> The TCP stack delivers packets in the order they come off the wire.
> Wget puts them in the correct order based on TCP sequence number to
> build the kernel image, and the TCP sequence number/ack protocol ensures
> complete delivery of a stream.

OK, it sounds like you've got a solution and a preference, so if it
makes more sense for this embedded implementation to maintain
simplicity, then so be it.

-Joe