Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
On 05.11.2024 19:02, Peter Robinson wrote: > On Tue, 5 Nov 2024 at 15:15, Simon Glass wrote: >> Hi Peter, >> >> On Tue, 5 Nov 2024 at 06:10, Peter Robinson wrote: >>> On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: Hi Tom, On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. > I highlighted my concerns about it all being together all the way back > in v1, the fact that it should be 3 separate sets of patches. > > The fact that it's at v12 is irrelevant and should never be used as a > reason just merge a patch set, it makes no senses. > >> 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. > LWIP has a HTTP server which is widely tested, that is what should be > used *if* we have to have one, I still have yet to see a useful > usecase, and no CI is not because ultimately how useful is testing > against ourselves, the fact is testing the HTTP client against apache > or nginx is a better real world usecase because the reality is that > U-Boot being the client and the server in that use case isn't really a > real world use case. We are using httpd server in u-boot for the emergency firmware upgrade purposes. It have the following reasons: * No need to install a special tools like tftp server on clients PC. Only a browser is required. * It much easy for support and client both -- the less specific knowledge is required the easy recovery process. Mikhail
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 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 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 > > > > > wrote: > > > > > > > > > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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 signature.asc Description: PGP signature
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 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 wrote: >>> On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: Hi Tom, On Mon, 4 Nov 2024 at 16:32, Tom Rini 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 include
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 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 wrote: > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > >> Hi Tom, > >> > >> On Mon, 4 Nov 2024 at 16:32, Tom Rini 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! -- Tom signature.asc Description: PGP signature
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
Hi Tom, On Tue, 5 Nov 2024 at 11: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 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 > > > > wrote: > > > > > > > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. 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. Regards, Simon
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 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 wrote: > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: >> Hi Tom, >> >> On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. 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). 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? Mikhail Kshevetskiy
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 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 wrote: > > > > > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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 signature.asc Description: PGP signature
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
Hi Tom, On Tue, 5 Nov 2024 at 08:47, Tom Rini 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 wrote: > > > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. Regards, Simon
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
On Tue, 5 Nov 2024 at 15:15, Simon Glass wrote: > > Hi Peter, > > On Tue, 5 Nov 2024 at 06:10, Peter Robinson wrote: > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. I highlighted my concerns about it all being together all the way back in v1, the fact that it should be 3 separate sets of patches. The fact that it's at v12 is irrelevant and should never be used as a reason just merge a patch set, it makes no senses. > 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. LWIP has a HTTP server which is widely tested, that is what should be used *if* we have to have one, I still have yet to see a useful usecase, and no CI is not because ultimately how useful is testing against ourselves, the fact is testing the HTTP client against apache or nginx is a better real world usecase because the reality is that U-Boot being the client and the server in that use case isn't really a real world use case.
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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 wrote: > > > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. -- Tom signature.asc Description: PGP signature
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
Hi Peter, On Tue, 5 Nov 2024 at 06:10, Peter Robinson wrote: > > On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > > > Hi Tom, > > > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. 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. Regards, SImon
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
On Tue, Nov 05, 2024 at 06:03:44AM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. Yes, I'm fine with the fixes, but I'm not sure why we want to add new features to the old stack. We've had exactly zero releases with lwIP included, so counting the number of boards with it enabled is not helpful. I'm sure that once I merge the https support series a whole lot of platforms will switch because that's needed for easier SystemReady IR certification. -- Tom signature.asc Description: PGP signature
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
On Tue, 5 Nov 2024 at 13:03, Simon Glass wrote: > > Hi Tom, > > On Mon, 4 Nov 2024 at 16:32, Tom Rini 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
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
Hi Tom, On Mon, 4 Nov 2024 at 16:32, Tom Rini 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. Regards, Simon
Re: [PATCH v12 00/13] net: tcp: improve tcp support in legacy stack
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. -- Tom signature.asc Description: PGP signature
