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

Tom Rini trini at konsulko.com
Tue Nov 5 19:26:19 CET 2024


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.

-- 
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/3ac5ecbf/attachment.sig>


More information about the U-Boot mailing list