[LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207)

[LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207)

[Hristos Nenkov]

Hello,

I would like to contribute a replacement for the FTP/HTTP stress tests
described in issue #1207:
https://github.com/linux-test-project/ltp/issues/1207

Before implementing the full replacement, could you confirm whether
someone is already working on it, and whether the following direction
is appropriate?

I propose a separate TCP bulk-transfer tool integrated with the
current LTP API and tst_net.sh, covering upload and download, a large
single transfer, and bounded concurrent transfers for a configurable
duration. Data would be generated and checked in fixed-size buffers
using position-dependent patterns, without creating multi-gigabyte
files. Both IPv4 and IPv6, partial I/O, deadlines and owned-process
cleanup would be covered. Legacy test removal would follow only after
the replacement coverage is demonstrated.

Would you prefer this standalone approach, as suggested in the earlier
discussion, or extending netstress instead? Are the existing
transfer-size and duration settings important compatibility
requirements?

Separately, I have an AI-assisted local prototype adding opt-in TCP
reply validation to netstress. It has built on Ubuntu/WSL and passed
11 isolated receive checks and 8 loopback client checks across
IPv4/IPv6. Those results apply only to that prototype, not the
proposed bulk-transfer replacement. No patch is attached; I have read
the project's guidance on AI-generated changes and understand that
independent review and validation are required before any submission.

Thank you,
Hristos Nenkov

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207)

[Petr Vorel]

Hi Hristos,

> Hello,

> I would like to contribute a replacement for the FTP/HTTP stress tests
> described in issue #1207:
> https://github.com/linux-test-project/ltp/issues/1207

> Before implementing the full replacement, could you confirm whether
> someone is already working on it, and whether the following direction
> is appropriate?

IMHO nobody is working on it ATM.

> I propose a separate TCP bulk-transfer tool integrated with the
> current LTP API and tst_net.sh, covering upload and download, a large
> single transfer, and bounded concurrent transfers for a configurable
> duration. Data would be generated and checked in fixed-size buffers
> using position-dependent patterns, without creating multi-gigabyte
> files. Both IPv4 and IPv6, partial I/O, deadlines and owned-process
> cleanup would be covered. Legacy test removal would follow only after
> the replacement coverage is demonstrated.

> Would you prefer this standalone approach, as suggested in the earlier
> discussion, or extending netstress instead? Are the existing
> transfer-size and duration settings important compatibility
> requirements?

If the diff would be reasonably small it'd be better extend netstress.c.
But I'm not sure if there is much code to be reused.

> Separately, I have an AI-assisted local prototype adding opt-in TCP
> reply validation to netstress. It has built on Ubuntu/WSL and passed
> 11 isolated receive checks and 8 loopback client checks across
> IPv4/IPv6. Those results apply only to that prototype, not the
> proposed bulk-transfer replacement. No patch is attached; I have read
> the project's guidance on AI-generated changes and understand that
> independent review and validation are required before any submission.

Yes, human review before sending to LTP would be nice.

Kind regards,
Petr

> Thank you,
> Hristos Nenkov

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207)

[Hristos Nenkov]

Hi Petr,

Thank you, that helps.

I’ll proceed with the netstress.c direction first and keep the change
as small and separable as possible. I’ll preserve the existing
coverage goals (both transfer directions, large transfer, bounded
concurrent transfers, IPv4/IPv6) rather than treating the small
reply-validation prototype as the full #1207 solution.

Before posting any patch to LTP, I’ll have the final diff and test
results reviewed manually and will only send claims that are backed by
that validation.

Kind regards,
Hristos

On Wed, 11 Nov 2026 15:35:55 +0100, Petr Vorel <pvorel@suse.cz> wrote:
> Hi Hristos,
>
> > Hello,
>
> > I would like to contribute a replacement for the FTP/HTTP stress tests
> > described in issue #1207:
> > https://github.com/linux-test-project/ltp/issues/1207
>
> > Before implementing the full replacement, could you confirm whether
> > someone is already working on it, and whether the following direction
> > is appropriate?
>
> IMHO nobody is working on it ATM.
>
> > I propose a separate TCP bulk-transfer tool integrated with the
> > current LTP API and tst_net.sh, covering upload and download, a large
> > single transfer, and bounded concurrent transfers for a configurable
> > duration. Data would be generated and checked in fixed-size buffers
> > using position-dependent patterns, without creating multi-gigabyte
> > files. Both IPv4 and IPv6, partial I/O, deadlines and owned-process
> > cleanup would be covered. Legacy test removal would follow only after
> > the replacement coverage is demonstrated.
>
> > Would you prefer this standalone approach, as suggested in the earlier
> > discussion, or extending netstress instead? Are the existing
> > transfer-size and duration settings important compatibility
> > requirements?
>
> If the diff would be reasonably small it'd be better extend netstress.c.
> But I'm not sure if there is much code to be reused.
>
> > Separately, I have an AI-assisted local prototype adding opt-in TCP
> > reply validation to netstress. It has built on Ubuntu/WSL and passed
> > 11 isolated receive checks and 8 loopback client checks across
> > IPv4/IPv6. Those results apply only to that prototype, not the
> > proposed bulk-transfer replacement. No patch is attached; I have read
> > the project's guidance on AI-generated changes and understand that
> > independent review and validation are required before any submission.
>
> Yes, human review before sending to LTP would be nice.
>
> Kind regards,
> Petr
>
> > Thank you,
> > Hristos Nenkov

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp