On 05.11.2024 21:26, Tom Rini wrote: > On Tue, Nov 05, 2024 at 09:07:17AM -0700, Simon Glass wrote: >> Hi Tom, >> >> On Tue, 5 Nov 2024 at 08:47, Tom Rini <tr...@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 <pbrobin...@gmail.com> wrote: >>>>> On Tue, 5 Nov 2024 at 13:03, Simon Glass <s...@chromium.org> wrote: >>>>>> Hi Tom, >>>>>> >>>>>> On Mon, 4 Nov 2024 at 16:32, Tom Rini <tr...@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: >>>>>>>> - data downloading from remote host to a board >>>>>>>> - request-response exchange with a small packets >>>>>>>> so it's not possible to upload large amount of data from the >>>>>>>> board to remote host. >>>>>>>> * 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. > Well, I continue to not say that we should drop the series, but that we > should take the fixes and not the new features. Because as far as I can > tell, the current TCP stack is in such a shape that it's not > production-usable anywhere and so the number of users argument is > irrelevant. > I expected something like this when lwip was finally merged. I was a bit surprised when Simon decide to merge this patch series.
At the moment we have no plans to update u-boot or backport lwip patches to u-boot-2023.10. So we will use our solution based on a legacy stack. I understand that we should switch to lwip somewhere in the future. Unfortunately it's not a fast and easy process (update u-boot, rewrite http based firmware upgrade, test new u-boot for several hardware configurations, test customer devices migrations and so on). Also we are limited in resources, so I am able to put my hands on u-boot only from time to time. So this is a long story. Tom, Simon, Peter: what patches do you want to accept? Mikhail Kshevetskiy
