[PATCH v13 00/10] net: tcp: improve tcp support in legacy stack
Simon Glass
sjg at chromium.org
Wed Nov 20 16:33:38 CET 2024
Hi Tom,
On Sun, 17 Nov 2024 at 12:52, Tom Rini <trini at konsulko.com> wrote:
>
> On Sun, Nov 17, 2024 at 12:45:12PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 16 Nov 2024 at 09:29, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sat, Nov 16, 2024 at 05:49:06PM +0300, Mikhail Kshevetskiy wrote:
> > > >
> > > > On 16.11.2024 03:31, Tom Rini wrote:
> > > > > On Thu, Nov 14, 2024 at 06:36:33AM +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.
> > > > > Can you please work with CI to get everything there to pass? Thanks. See
> > > > > https://docs.u-boot.org/en/latest/develop/ci_testing.html if needed for
> > > > > help on starting that.
> > > > >
> > > > Hello Tom,
> > > > Could you look to https://github.com/u-boot/u-boot/pull/692 ?
> > > > It fails 2 times on ut_lib_test_udelay, but this seems unrelated to my
> > > > changes.
> > >
> > > Yes, unfortunately Simon's recent moving of the tests caused that one to
> > > fail more frequently now. I've hit re-run, if that's not something
> > > available to you, just now.
> >
> > Perhaps we should skip that test (return -EAGAIN) for sandbox?
>
> It would be good to understand why:
> - if (abs(error) > 100)
> - return -EINVAL;
> + ut_assert(abs(error) <= 100);
>
> is not actually functionally equivalent, seemingly.
-EINVAL is consider an error
-EAGAIN is considered a request to skip the test
Regards,
Simon
More information about the U-Boot
mailing list