test: never disable SMP

[IRISZZW]

To turn SMP on pervasively. Tests should be treated with a combination
of flagging specific cases as "1cpu" where we have short-running tests
that can be independently run in an otherwise SMP environment, and via
setting CONFIG_MP_NUM_CPUS=1 where that's not possible (which still
runs the full SMP kernel config, but with only one CPU available).

We have similar fix, commit: c0e3b92, PR: #18531

[abrodkin]

To me provided description looks a bit unclear. I think what was really meant is that SMP is not a property of software configuration, but rather how real hardware is configured. That said it's SoC which should define if it's UP or SMP and then nobody else should override that.

Now given we have some tests which we'd like to execute in subsequent manner and maybe even on the same one CPU core (regardless of how many of those we have to our disposal), that might be solved with limit of CPU cores used in the SMP cluster. And that's what is being implemented here.

Still I'm not sure if all supported in Zephyr SMP SoCs may safely run with reduced amount of cores. ARC platforms are perfectly capable of that, but what about all the rest?

That said IMHO at least wording of the rationale should be improved.

[pfalcon]

That said IMHO at least wording of the rationale should be improved.

+1. And there's a typo straight in the subject line: "nerver".

Regarding changes to tests/net/socket/tls* tests done here: I'm not sure why they have CONFIG_SMP=n in the first place (@rlubos, do you have an idea?), but those tests are intended to be unit tests for just socket TLS functionality, so just as well can stays as they are. (Unless there's a specific issue with CONFIG_SMP=n, which I agree is not communicated well in this patch, and would be a deeper issue than just removing it from tests. Otherwise, for as longs as we have CONFIG_SMP config option, it only makes sense to have tests with it being n).

[pfalcon]

Commented above.

[abrodkin]

Otherwise, for as long as we have CONFIG_SMP config option, it only makes sense to have tests with it being n.
Not clear what do you mean by that. Could you please elaborate a bit more on that?

[IRISZZW]

@andyross Any comments about this PR?

[cfriedt]

I would +1 a request for a clearer description, but I can see why this could be useful.

At risk of doubling the number of tests twister has to go through, maybe it's reasonable to get smp vs non-smp variants in yaml?

[abrodkin]

@IRISZZW could you please revisit this one?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

@IRISZZW - needs to be rebased, I think

[ruuddw]

needs to be rebased, I think

Correct, and some of the tests have already been fixed in separate PRs by Anas. Note that IRISZZW moved on and is no longer working on ARC, @evgeniy-paltsev plans to address the remaining test as part of his work on SMP and ARCv3 cores.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.