
Hi Tom,
On Tue, 5 Nov 2024 at 08:47, Tom Rini trini@konsulko.com wrote:
On Tue, Nov 05, 2024 at 08:15:25AM -0700, Simon Glass wrote:
Hi Peter,
On Tue, 5 Nov 2024 at 06:10, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, 5 Nov 2024 at 13:03, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Mon, 4 Nov 2024 at 16:32, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 28, 2024 at 05:31:30PM +0300, Mikhail Kshevetskiy wrote:
Legacy TCP stack is bad. Here are some of the known issues:
- tcp packet from other connection can break a current one
- tcp send sequence always starts from zero
- bad tcp options processing
- strange assumptions on packet size for selective acknowledge
- tcp interface assumes one of the two scenarios:
so it's not possible to upload large amount of data from the board to remote host.
- data downloading from remote host to a board
- request-response exchange with a small packets
- wget test generate bad tcp stream, test should fail but it passes instead
This series of patches fixes all of the above issues.
I know Peter asked on the last one, but I want to ask as well. With lwIP merged, why do we want to add features to the old stack? I can see fixing issues, but not adding new functionality as well. Thanks.
Let's apply this. It has tests and the old stack is still used by a lot of boards. At present lwip is only used on one. There is more work to do on the new stack, including finishing off the sandbox implementation.
I agree with applying the fixes pieces, I do not agree with apply the HTTP server pieces. This series should actually be split into 3
But what is your objection?
I would much rather just apply it ASAP. It has already gone through 12 versions, during which lwip has been prepared and applied.
Yes, and to be blunt, the first bit of feedback I provided was "can you please look at the lwIP series instead?".
The HTTP server is a useful feature and we should be able to use it to test networking in U-Boot in a more self-contained and performant manner.
I very much do not want to add more features to the legacy TCP stack. We're likely, long term, to still need some cut-back version of the old stack for the limited SPL cases.
This series has been in progress for a long time and it seems unfair to just drop it, with one one board on the new stack.
Regards, Simon