All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Hristos Nenkov <nenkov2004@gmail.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207)
Date: Wed, 11 Nov 2026 15:35:55 +0100	[thread overview]
Message-ID: <20261111143555.GA763965@pevik> (raw)
In-Reply-To: <CAO7_G+wYCDjBpia5UbAJc52v1Rn9uRKoLn=UHhg_U4bs=UYeDA@mail.gmail.com>

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

  reply	other threads:[~2026-11-11 14:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  4:08 [LTP] [RFC] Proposed scope for replacing FTP/HTTP stress tests (#1207) Hristos Nenkov
2026-11-11 14:35 ` Petr Vorel [this message]
2026-11-11 15:38   ` Hristos Nenkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261111143555.GA763965@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=nenkov2004@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.