Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hold till after release -- Max proof size from relay, get Impl for max weight, int tests env hos… #1134

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

thea-leake
Copy link
Contributor

@thea-leake thea-leake commented Dec 15, 2022

Set max block weight proof size from relay chain val, and gen runtime weights with this val.

Description

Sets the proof size for the max block weight based off the value returned from the relay chain, and if that's not available, then use the value set in cumulus (pulled from polkadot).

Changes and Descriptions

Added gen_weight_parameters macro that generates weight params (Get impl) for Runtimes with the max proof size pulled from the relay if in an externalities provided
environment, and the max proof size for relay chains as defined by polkadot used if not.
Provides:

  • MaximumBlockWeight: MAXIMIM_BLOCK_WEIGHT with proof size adjusted for relay chain val.
  • BlockWeightsWithRelayProof: BlockWeights generated with using MaximumBlockWeight with relay proof size set.
  • MessagingReservedWeight: chain messaging reserved weight using MaximumBlockWeight with relay proof size set.
  • MaximumSchedulerWeight: max scheduler weight using MaximumBlockWeight with relay proof size set.

Updates runtimes to use new params generated with relay proof size.

Currently using a Macro as separating these out into a separate module usable by the different runtimes
causes issues with the __construct_runtime_integrity_test::runtime_integrity_tests test for runtime/development
with the cfg!(test) macro returning false when this is in separate module, and then attempted data fetch relay chain with no externalities provided... which panics. Separate module does work for tests with provided externalities env & execute_with though.

Type of change

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Integration tests/unit tests

Checklist:

  • I have added Rust doc comments to structs, enums, traits and functions
  • I have performed a self-review of my code
  • My changes generate no new warnings
  • New and existing unit tests pass locally with my changes
  • I rebased on the latest main branch

@thea-leake thea-leake marked this pull request as ready for review December 15, 2022 15:26
mustermeiszer
mustermeiszer previously approved these changes Dec 15, 2022
Copy link
Collaborator

@mustermeiszer mustermeiszer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that! LGTM!

@mustermeiszer
Copy link
Collaborator

@thea-leake did you agree with Miguel about leaving this out firstly? Should we close this PR then?

@thea-leake
Copy link
Contributor Author

@mustermeiszer yeah I agreed with Miguel to leave the PR out for the release. I think we still want it pulled in, we just wanted to make sure it wasn't merged before the release PR was merged.

@thea-leake
Copy link
Contributor Author

This has been refactored to have the weight param generation with proof size based off the relay chain in one place for all the runtimes.

Currently using a Macro as seperating these out into a seperate module usable by the different runtimes
causes issues with the __construct_runtime_integrity_test::runtime_integrity_tests test for runtime/development
with the cfg!(test) not returning correctly for seperate module, and then attempted data fetch relay chain with no
externalities provided... which panics. Works for tests with provided externalities env & execute_with

Curently have Runtime generic as we would need this to switch back from macro, though we could technically
remove now, though the impl where does provide context for which config would need to be impl for runtime
to fetch the validation data for the relay max proof size.

@thea-leake
Copy link
Contributor Author

@mikiquantum would we want this in review now, or should it wait until the other benchmarking work is done?

@mikiquantum
Copy link
Contributor

Thanks @thea-leake , I would keep it as draft until we cut the release in the next few weeks.

@thea-leake
Copy link
Contributor Author

@mikiquantum sounds good, thanks :)

@thea-leake thea-leake changed the title Max proof size from relay, get Impl for max weight, int tests env hos… Hold till after release -- Max proof size from relay, get Impl for max weight, int tests env hos… Dec 22, 2022
@lemunozm
Copy link
Contributor

Do we know what's the state of this?

@mustermeiszer
Copy link
Collaborator

We can bring this is IMO.

Runtime: cumulus_pallet_parachain_system::Config,
{
fn get() -> frame_support::weights::Weight {
if cfg!(test) {
Copy link
Contributor

@lemunozm lemunozm Apr 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a note:

I guess the need for the macro usage was caused by the fact that only the compiled crate is compiling with test. So if you compile i.e. development-runtime with test then runtime-common (where this lives) will not compile with test.

I think we can avoid to use the macro if we check against std instead.

Another option is to get this value through a function where the cfg(test) value is passed by param.

@@ -837,3 +841,41 @@ pub fn pass_n(env: &mut TestEnv, n: u64) -> Result<(), ()> {

Ok(())
}

fn default_parachains_host_configuration() -> HostConfiguration<BlockNumber> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering whether we cannot get this from the relay chain spec which we use. This configuration is assumed to change over time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants