HRMP - set DefaultChannelSizeAndCapacityWithSystem with dynamic values according to the ActiveConfig
#4332
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ording to the `ActiveConfig`
bkontur
added
R0-silent
|
@xlc wdyt? |
|
bot bench polkadot-pallet --runtime=rococo --pallet=runtime_parachains::hrmp |
|
lgtm |
…=westend --target_dir=polkadot --pallet=runtime_parachains::hrmp
…=rococo --target_dir=polkadot --pallet=runtime_parachains::hrmp
|
bot clean |
4 tasks
franciscoaguirre
approved these changes
Apr 30, 2024
acatangiu
approved these changes
May 1, 2024
dcolley
added a commit
to metaspan/polkadot-sdk
that referenced
this pull request
May 6, 2024
* 'master' of https://github.com/metaspan/polkadot-sdk: (65 commits) Introduces `TypeWithDefault<T, D: Get<T>>` (paritytech#4034) Publish `polkadot-sdk-frame` crate (paritytech#4370) Add validate field to prdoc (paritytech#4368) State trie migration on asset-hub westend and collectives westend (paritytech#4185) Fix: dust unbonded for zero existential deposit (paritytech#4364) Bridge: added subcommand to relay single parachain header (paritytech#4365) Bridge: fix zombienet tests (paritytech#4367) [WIP][CI] Add more GHA jobs (paritytech#4270) Allow for 0 existential deposit in benchmarks for `pallet_staking`, `pallet_session`, and `pallet_balances` (paritytech#4346) Deprecate `NativeElseWasmExecutor` (paritytech#4329) More `xcm::v4` cleanup and `xcm_fee_payment_runtime_api::XcmPaymentApi` nits (paritytech#4355) sc-tracing: enable env-filter feature (paritytech#4357) deps: update jsonrpsee to v0.22.5 (paritytech#4330) Add PoV-reclaim enablement guide to polkadot-sdk-docs (paritytech#4244) cargo: Update experimental litep2p to latest version (paritytech#4344) Bridge: ignore client errors when calling recently added `*_free_headers_interval` methods (paritytech#4350) Make parachain template great again (and async backing ready) (paritytech#4295) [Backport] Version bumps and reorg prdocs from 1.11.0 (paritytech#4336) HRMP - set `DefaultChannelSizeAndCapacityWithSystem` with dynamic values according to the `ActiveConfig` (paritytech#4332) Statement Distribution Per Peer Rate Limit (paritytech#3444) ...
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 7, 2024
Closes: #4003 (please see for the problem description) ## TODO - [x] add more tests covering `WrapVersion` corner cases (e.g. para has lower version, ...) - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo is here: #4332) ## Questions / possible improvements - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version discovery with [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25), there is possibility to avoid this overhead in this HRMP case to create new `WrapVersion` adapter for `pallet_xcm` which would not use `note_unknown_version`. Is it worth to do it or not? - [ ] There's a possibility to decouple XCM functionality from the HRMP pallet, allowing any relay chain to generate its own notifications. This approach wouldn't restrict notifications solely to the XCM. However, it's uncertain whether it's worthwhile or desirable to do so? It means making HRMP pallet more generic. E.g. hiding HRMP notifications behind some trait: ``` trait HrmpNotifications { fn on_channel_open_request( sender: ParaId, proposed_max_capacity: u32, proposed_max_message_size: u32) -> primitives::DownwardMessage; fn on_channel_accepted(recipient: ParaId) -> primitives::DownwardMessage; fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient: ParaId) -> primitives::DownwardMessage; } ``` and then we could have whatever adapter, `impl HrmpNotifications for VersionedXcmHrmpNotifications {...}`, ``` impl parachains_hrmp::Config for Runtime { .. type HrmpNotifications = VersionedXcmHrmpNotifications; .. } ``` --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <git@kchr.de>
bkontur
added a commit
that referenced
this pull request
May 27, 2024
…ues according to the `ActiveConfig` (#4332) This PR enhances the capability to set `DefaultChannelSizeAndCapacityWithSystem` for HRMP. Currently, all testnets (Rococo, Westend) have a hard-coded value set as 'half of the maximum' determined by the live `ActiveConfig`. While this approach appears satisfactory, potential issues could arise if the live `ActiveConfig` are adjusted below these hard-coded values, necessitating a new runtime release with updated values. Additionally, hard-coded values have consequences, such as Rococo's benchmarks not functioning: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6082656. The proposed solution here is to utilize `ActiveConfigHrmpChannelSizeAndCapacityRatio`, which reads the current `ActiveConfig` and calculates `DefaultChannelSizeAndCapacityWithSystem`, for example, "half of the maximum" based on live data. This way, whenever `ActiveConfig` is modified, `ActiveConfigHrmpChannelSizeAndCapacityRatio` automatically returns adjusted values with the appropriate ratio. Thus, manual adjustments and new runtime releases become unnecessary. Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1541001420 Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1549291588 --------- Co-authored-by: command-bot <>
5 tasks
EgorPopelyaev
pushed a commit
that referenced
this pull request
May 27, 2024
…ues according to the `ActiveConfig` (#4332) This PR enhances the capability to set `DefaultChannelSizeAndCapacityWithSystem` for HRMP. Currently, all testnets (Rococo, Westend) have a hard-coded value set as 'half of the maximum' determined by the live `ActiveConfig`. While this approach appears satisfactory, potential issues could arise if the live `ActiveConfig` are adjusted below these hard-coded values, necessitating a new runtime release with updated values. Additionally, hard-coded values have consequences, such as Rococo's benchmarks not functioning: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6082656. The proposed solution here is to utilize `ActiveConfigHrmpChannelSizeAndCapacityRatio`, which reads the current `ActiveConfig` and calculates `DefaultChannelSizeAndCapacityWithSystem`, for example, "half of the maximum" based on live data. This way, whenever `ActiveConfig` is modified, `ActiveConfigHrmpChannelSizeAndCapacityRatio` automatically returns adjusted values with the appropriate ratio. Thus, manual adjustments and new runtime releases become unnecessary. Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1541001420 Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1549291588 --------- Co-authored-by: command-bot <>
2 tasks
fellowship-merge-bot bot
pushed a commit
to polkadot-fellows/runtimes
that referenced
this pull request
May 29, 2024
Allows any parachain to have bidirectional channel with any system parachains. Relates to: polkadot-fellows/RFCs#82 Relates to: paritytech/polkadot-sdk#3721 Relates to: paritytech/polkadot-sdk#4332 <!-- Remember that you can run `/merge` to enable auto-merge in the PR --> <!-- Remember to modify the changelog. If you don't need to modify it, you can check the following box. Instead, if you have already modified it, simply delete the following line. --> - [x] regenerate weights for `runtime_parachains::hrmp` - [ ] Does not require a CHANGELOG entry ## Polkadot weights (the threshold moved from the default 5 to 0.1 to see some differences) ``` subweight compare commits --path-pattern "./relay/polkadot/**/weights/**/*.rs" --format markdown --no-color --change added changed --method asymptotic --ignore-errors --threshold 0.1 remotes/polkadot-fellows/main origin/bko-hrmp-patch ``` | File | Extrinsic | Old | New | Change [%] | |-------------------------------------------------------|-------------------------------|----------|----------|------------| | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | poke_channel_deposits | 137.20us | 140.03us | +2.06 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | hrmp_accept_open_channel | 555.89us | 563.03us | +1.28 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | hrmp_close_channel | 556.97us | 563.79us | +1.22 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | hrmp_init_open_channel | 732.03us | 740.10us | +1.10 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | force_open_hrmp_channel | 1.16ms | 1.17ms | +0.98 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | establish_system_channel | 1.15ms | 1.16ms | +0.69 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | force_process_hrmp_open | 102.05ms | 102.47ms | +0.42 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | force_clean_hrmp | 91.52ms | 91.86ms | +0.37 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | clean_open_channel_requests | 16.56ms | 16.61ms | +0.35 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | force_process_hrmp_close | 75.41ms | 75.65ms | +0.33 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | hrmp_cancel_open_request | 422.12us | 415.03us | -1.68 | | relay/polkadot/src/weights/runtime_parachains_hrmp.rs | establish_channel_with_system | | 1.67ms | Added | ## Kusama weights (the threshold moved from the default 5 to 0.1 to see some differences) ``` subweight compare commits --path-pattern "./relay/kusama/**/weights/**/*.rs" --format markdown --no-color --change added changed --method asymptotic --ignore-errors --threshold 0.1 remotes/polkadot-fellows/main origin/bko-hrmp-patch ``` | File | Extrinsic | Old | New | Change [%] | |-----------------------------------------------------|-------------------------------|----------|----------|------------| | relay/kusama/src/weights/runtime_parachains_hrmp.rs | poke_channel_deposits | 137.23us | 140.25us | +2.20 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | hrmp_close_channel | 557.39us | 564.18us | +1.22 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | hrmp_accept_open_channel | 556.49us | 563.23us | +1.21 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | hrmp_init_open_channel | 735.26us | 743.59us | +1.13 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | force_open_hrmp_channel | 1.16ms | 1.17ms | +0.97 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | establish_system_channel | 1.15ms | 1.16ms | +0.84 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | hrmp_cancel_open_request | 413.79us | 416.03us | +0.54 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | force_process_hrmp_open | 101.96ms | 102.43ms | +0.46 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | clean_open_channel_requests | 16.54ms | 16.61ms | +0.45 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | force_clean_hrmp | 91.43ms | 91.82ms | +0.43 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | force_process_hrmp_close | 75.34ms | 75.63ms | +0.40 | | relay/kusama/src/weights/runtime_parachains_hrmp.rs | establish_channel_with_system | | 1.67ms | Added |
hitchhooker
pushed a commit
to ibp-network/polkadot-sdk
that referenced
this pull request
Jun 5, 2024
Closes: paritytech#4003 (please see for the problem description) ## TODO - [x] add more tests covering `WrapVersion` corner cases (e.g. para has lower version, ...) - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo is here: paritytech#4332) ## Questions / possible improvements - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version discovery with [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25), there is possibility to avoid this overhead in this HRMP case to create new `WrapVersion` adapter for `pallet_xcm` which would not use `note_unknown_version`. Is it worth to do it or not? - [ ] There's a possibility to decouple XCM functionality from the HRMP pallet, allowing any relay chain to generate its own notifications. This approach wouldn't restrict notifications solely to the XCM. However, it's uncertain whether it's worthwhile or desirable to do so? It means making HRMP pallet more generic. E.g. hiding HRMP notifications behind some trait: ``` trait HrmpNotifications { fn on_channel_open_request( sender: ParaId, proposed_max_capacity: u32, proposed_max_message_size: u32) -> primitives::DownwardMessage; fn on_channel_accepted(recipient: ParaId) -> primitives::DownwardMessage; fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient: ParaId) -> primitives::DownwardMessage; } ``` and then we could have whatever adapter, `impl HrmpNotifications for VersionedXcmHrmpNotifications {...}`, ``` impl parachains_hrmp::Config for Runtime { .. type HrmpNotifications = VersionedXcmHrmpNotifications; .. } ``` --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <git@kchr.de>
4 tasks
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
…ues according to the `ActiveConfig` (paritytech#4332) ## Summary This PR enhances the capability to set `DefaultChannelSizeAndCapacityWithSystem` for HRMP. Currently, all testnets (Rococo, Westend) have a hard-coded value set as 'half of the maximum' determined by the live `ActiveConfig`. While this approach appears satisfactory, potential issues could arise if the live `ActiveConfig` are adjusted below these hard-coded values, necessitating a new runtime release with updated values. Additionally, hard-coded values have consequences, such as Rococo's benchmarks not functioning: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6082656. ## Solution The proposed solution here is to utilize `ActiveConfigHrmpChannelSizeAndCapacityRatio`, which reads the current `ActiveConfig` and calculates `DefaultChannelSizeAndCapacityWithSystem`, for example, "half of the maximum" based on live data. This way, whenever `ActiveConfig` is modified, `ActiveConfigHrmpChannelSizeAndCapacityRatio` automatically returns adjusted values with the appropriate ratio. Thus, manual adjustments and new runtime releases become unnecessary. Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1541001420 Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1549291588 --------- Co-authored-by: command-bot <>
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
Closes: paritytech#4003 (please see for the problem description) ## TODO - [x] add more tests covering `WrapVersion` corner cases (e.g. para has lower version, ...) - [x] regenerate benchmarks `runtime_parachains::hrmp` (fix for Rococo is here: paritytech#4332) ## Questions / possible improvements - [ ] A `WrapVersion` implementation for `pallet_xcm` initiates version discovery with [note_unknown_version](https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L2527C5-L2527C25), there is possibility to avoid this overhead in this HRMP case to create new `WrapVersion` adapter for `pallet_xcm` which would not use `note_unknown_version`. Is it worth to do it or not? - [ ] There's a possibility to decouple XCM functionality from the HRMP pallet, allowing any relay chain to generate its own notifications. This approach wouldn't restrict notifications solely to the XCM. However, it's uncertain whether it's worthwhile or desirable to do so? It means making HRMP pallet more generic. E.g. hiding HRMP notifications behind some trait: ``` trait HrmpNotifications { fn on_channel_open_request( sender: ParaId, proposed_max_capacity: u32, proposed_max_message_size: u32) -> primitives::DownwardMessage; fn on_channel_accepted(recipient: ParaId) -> primitives::DownwardMessage; fn on_channel_closing(initiator: ParaId, sender: ParaId, recipient: ParaId) -> primitives::DownwardMessage; } ``` and then we could have whatever adapter, `impl HrmpNotifications for VersionedXcmHrmpNotifications {...}`, ``` impl parachains_hrmp::Config for Runtime { .. type HrmpNotifications = VersionedXcmHrmpNotifications; .. } ``` --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <git@kchr.de>
This was referenced Aug 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR enhances the capability to set
DefaultChannelSizeAndCapacityWithSystemfor HRMP. Currently, all testnets (Rococo, Westend) have a hard-coded value set as 'half of the maximum' determined by the liveActiveConfig. While this approach appears satisfactory, potential issues could arise if the liveActiveConfigare adjusted below these hard-coded values, necessitating a new runtime release with updated values. Additionally, hard-coded values have consequences, such as Rococo's benchmarks not functioning: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6082656.Solution
The proposed solution here is to utilize
ActiveConfigHrmpChannelSizeAndCapacityRatio, which reads the currentActiveConfigand calculatesDefaultChannelSizeAndCapacityWithSystem, for example, "half of the maximum" based on live data. This way, wheneverActiveConfigis modified,ActiveConfigHrmpChannelSizeAndCapacityRatioautomatically returns adjusted values with the appropriate ratio. Thus, manual adjustments and new runtime releases become unnecessary.Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1541001420
Relates to a comment/discussion: https://github.com/paritytech/polkadot-sdk/pull/3721/files#r1549291588