On 06.11.2024 02:00, Tom Rini wrote: > 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! > 1-5, 7-10 are fixes. 6 -- It's almost complete rewrite of legacy tcp stack and whole tcp api. It's NOT possible to fix main issues of legacy tcp stack without a big redesign :-( netcat -- something like a sample of new api usage. It was written to test & debug new api. httpd -- this is what our company is needed.
so I recommend the following variants: 1) minimal: 1-5, 10, some parts of 7 and 9. As I remember these patches does not change current api. Unfortunately they does not fix main tcp issues as well. 2) reasonable: 1-11. This includes new tcp stack and netcat. I think we should have a sample of use new api usage. Fastboot and wget is not enough :-( Mikhail
