From: Pedro Tammela <pctammela@mojatatu.com>
To: shaozhengchao <shaozhengchao@huawei.com>,
Matthieu Baerts <matthieu.baerts@tessares.net>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@resnulli.us>, Shuah Khan <shuah@kernel.org>,
Kees Cook <keescook@chromium.org>,
"David S. Miller" <davem@davemloft.net>,
Paul Blakey <paulb@mellanox.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
mptcp@lists.linux.dev
Cc: Shuah Khan <skhan@linuxfoundation.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net 1/3] selftests: tc: set timeout to 15 minutes
Date: Fri, 14 Jul 2023 14:49:01 -0300 [thread overview]
Message-ID: <deeb8fe7-1f0e-bc1c-cde5-74e9af160bf7@mojatatu.com> (raw)
In-Reply-To: <bf7f8867-6b14-dd53-a6e4-2addee4a5ad8@huawei.com>
On 13/07/2023 23:25, shaozhengchao wrote:
>
>
> On 2023/7/14 5:16, Matthieu Baerts wrote:
>> When looking for something else in LKFT reports [1], I noticed that the
>> TC selftest ended with a timeout error:
>>
>> not ok 1 selftests: tc-testing: tdc.sh # TIMEOUT 45 seconds
>>
>> The timeout had been introduced 3 years ago, see the Fixes commit below.
>>
>> This timeout is only in place when executing the selftests via the
>> kselftests runner scripts. I guess this is not what most TC devs are
>> using and nobody noticed the issue before.
>>
>> The new timeout is set to 15 minutes as suggested by Pedro [2]. It looks
>> like it is plenty more time than what it takes in "normal" conditions.
>>
>> Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second
>> timeout per test")
>> Cc: stable@vger.kernel.org
>> Link:
>> https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230711/testrun/18267241/suite/kselftest-tc-testing/test/tc-testing_tdc_sh/log [1]
>> Link:
>> https://lore.kernel.org/netdev/0e061d4a-9a23-9f58-3b35-d8919de332d7@tessares.net/T/ [2]
>> Suggested-by: Pedro Tammela <pctammela@mojatatu.com>
>> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
>> ---
>> tools/testing/selftests/tc-testing/settings | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/testing/selftests/tc-testing/settings
>> b/tools/testing/selftests/tc-testing/settings
>> new file mode 100644
>> index 000000000000..e2206265f67c
>> --- /dev/null
>> +++ b/tools/testing/selftests/tc-testing/settings
>> @@ -0,0 +1 @@
>> +timeout=900
>>
> I remember last year when I tested all the tdc cases(qdisc + filter +
> action + infra) in my vm machine, it took me nearly 20 minutes.
> So I think it should be more than 1200 seconds if all cases need to be
> tested.
>
> Maybe we should really optimize the parallel execution process of tdc.
Let's try to spend some cycles improving the tdc code performance first.
TDC boils down essentially to:
- Setup namespace (if needed)
- Setup network interfaces
- Spawn a few processes
- Match a regex
- Bring down namespace
Nothing above screams expensive, so I'm sure there are some low hanging
fruits to improve the overall wall time even in debug kernels.
next prev parent reply other threads:[~2023-07-14 17:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 21:16 [PATCH net 0/3] selftests: tc: increase timeout and add missing kconfig Matthieu Baerts
2023-07-13 21:16 ` [PATCH net 1/3] selftests: tc: set timeout to 15 minutes Matthieu Baerts
2023-07-14 2:25 ` shaozhengchao
2023-07-14 17:49 ` Pedro Tammela [this message]
2023-07-17 8:32 ` Matthieu Baerts
2023-07-18 1:43 ` shaozhengchao
2023-07-13 21:16 ` [PATCH net 2/3] selftests: tc: add 'ct' action kconfig dep Matthieu Baerts
2023-07-14 2:56 ` shaozhengchao
2023-07-13 21:16 ` [PATCH net 3/3] selftests: tc: add ConnTrack procfs kconfig Matthieu Baerts
2023-07-14 3:25 ` shaozhengchao
2023-07-13 22:41 ` [PATCH net 0/3] selftests: tc: increase timeout and add missing kconfig Jamal Hadi Salim
2023-07-18 8:46 ` Matthieu Baerts
2023-07-19 0:00 ` patchwork-bot+netdevbpf
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=deeb8fe7-1f0e-bc1c-cde5-74e9af160bf7@mojatatu.com \
--to=pctammela@mojatatu.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=matthieu.baerts@tessares.net \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=paulb@mellanox.com \
--cc=shaozhengchao@huawei.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=xiyou.wangcong@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®