[PATCH v12 00/13] net: tcp: improve tcp support in legacy stack

[Mikhail Kshevetskiy]

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 <trini at 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 at gmail.com> wrote:
>>>>>>> On Tue, 5 Nov 2024 at 13:03, Simon Glass <sjg at chromium.org> wrote:
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> On Mon, 4 Nov 2024 at 16:32, Tom Rini <trini at 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