On Tue, Nov 05, 2024 at 09:59:57PM +0300, Mikhail Kshevetskiy wrote: > > 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.
I'm sure it would be engineering-wise prohibitive. And, thank you for contributing your TCP related fixes upstream, it is appreciated and in the absence of the lwIP work would have been entirely uncontroversial. > 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). That is always a challenge, yes. > 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? In a quick look, 1-10 look like bugfixes to the stack with 11 being netcat and 12/13 being httpd, and I assume that's what Peter meant by 3 series instead of 1. So those first 10. And thanks again! -- Tom
signature.asc
Description: PGP signature
