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

[Tom Rini]

On Tue, Nov 05, 2024 at 12:03:49PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 5 Nov 2024 at 11:26, Tom Rini <trini at konsulko.com> 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.
> 
> It's a strange thing as many people use the existing stack. I
> certainly didn't know it had problems and it has always worked fine
> for me. It just seems like an extreme position, to delay a series for
> such a long time, then drop it because a nascent competition thing has
> landed.

We've only had TCP for 2 years (almost, I didn't merge it until Nov 28,
2022). We've only had reliable wget (using TCP) since April of this
year. While much of the legacy network stack is reliable and robust, TCP
is not. And _that_ was the impetus behind suggesting to instead work on
lwIP rather than fixing up the current TCP stack.

> Let's take it as it is, then say that future bug-fixes and
> enhancements need to be based on lwip (perhaps add something to this
> effect to the headers and docs if not already there?). No one loses
> and everyone should be happy. Once people start using lwip they will
> build confidence in it. I will grow in confidence once it supports the
> sandbox tests.

I would be happy to take the *fixes* portion of this series.

And I do owe Mikhail a reply too, I'm just a tad swamped today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241105/5757ff03/attachment.sig>