-
Notifications
You must be signed in to change notification settings - Fork 970
Allow configuration of worst case buy execution weight #7944
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
Allow configuration of worst case buy execution weight #7944
Conversation
…-buy-execution-weight
…-buy-execution-weight
I remember back in that PR there were a couple of things that needed to be analyzed:
|
CC @RomarQ |
Any opinion on this? |
the case where does not even need to go into the Trader. This PR allows | ||
developers to set the worst-case scenario as they wish. | ||
crates: | ||
- name: pallet-xcm-benchmarks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- name: pallet-xcm-benchmarks | |
- name: pallet-xcm-benchmarks | |
- bump: major |
It's major since you're adding a function with no default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well.. shit! how are we gonna backport then?
I guess we'll have to limit "backport" to just 2503 which hasn't been published yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, nevermind, that's fine, we don't really need to backport this too far back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am actually adding a default value, unless you want me to change it. If I dont add a default value I need to put a worst case scenario in all runtimes, and I dont really know what is the worst case scenario in each of them. I can try to guess, but a few hints would be good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that you changed fee_asset
, there's no default. Everyone needs to change that function so it's a breaking change.
If we don't need to backport then it's fine.
@franciscoaguirre I actually applied @bkontur suggestion and converted polkadot-sdk/polkadot/xcm/xcm-executor/src/lib.rs Line 1358 in ec32daa
If you want as part of this PR I can also add a weight value so that the benchmarking of the buyExecution instruction corresponds to worst case |
@girazoki I think a |
This is done know. Now I think the only thing "left", but maybe that is for a separate PR, is to adjust assethub to its worst case scenario, which I believe is when you try to buy weight with an asset different than the parent. I have an idea in mind for this, let me know guys if you want to make it as part of this PR. |
@franciscoaguirre do you have an opinion on this? should I adapt assetshub for its worst case? or should I leave it for another PR? because otherwise I think this PR is "ready" |
@girazoki We can do it in a separate PR |
the case where does not even need to go into the Trader. This PR allows | ||
developers to set the worst-case scenario as they wish. | ||
crates: | ||
- name: pallet-xcm-benchmarks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that you changed fee_asset
, there's no default. Everyone needs to change that function so it's a breaking change.
If we don't need to backport then it's fine.
Pull Request is not mergeable
@acatangiu I fixed the errors from the merge queue I think, can you put it back? |
Head branch was pushed to by a user without write access
Alright now apparently |
c800a0d
* master: (120 commits) [CI] Improve GH build status checking (#8331) [CI/CD] Use original PR name in prdoc check for the backport PR's to the stable branches (#8329) Add new host APIs set_storage_or_clear and get_storage_or_zero (#7857) push to dockerhub (#8322) Snowbridge - V1 - Adds 2 hop transfer to Rococo (#7956) [AHM] Prepare `election-provider-multi-block` for full lazy data deletion (#8304) Check umbrella version (#8250) [AHM] Fully bound staking async (#8303) migrate parachain-templates tests to `gha` (#8226) staking-async: add missing new_session_genesis (#8310) New NFT traits: granular and abstract interface (#5620) Extract create_pool_with_native_on macro to common crate (#8289) XCMP: use batching when enqueuing inbound messages (#8021) Snowbridge - Tests refactor (#8014) Allow configuration of worst case buy execution weight (#7944) Fix faulty pre-upgrade migration check in pallet-session (#8294) [pallet-revive] add get_storage_var_key for variable-sized keys (#8274) add poke_deposit extrinsic to pallet-recovery (#7882) `txpool`: use tracing for structured logging (#8001) [revive] eth-rpc refactoring (#8148) ...
Adds `worst_case_buy_execution` to the Config trait of `pallet-xcm-benchmarks` with a default implementation that mimics the code that existed previous to this PR. Rationale: not allowing to set the `WeightLimit` and the `FeeAsset` might mean that we dont benchmark the worst case, as with `WeightLimit::Unlimited` the `Trader` does not even execute: https://github.com/paritytech/polkadot-sdk/blob/c01dbebeaa6394691974de46dd2d41a582f6a4c2/polkadot/xcm/xcm-executor/src/lib.rs#L833 The new configurable function allows projects to customize the parameters with which the benchmark is run to make sure they account for the worst-case scenario **This is very likely the case of the assethub system chain**, with several traders being analyzed and possibly several reads being made: https://github.com/paritytech/polkadot-sdk/blob/38d2fa859861005157ccb249dca1378f015e0b06/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs#L403 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Adds `worst_case_buy_execution` to the Config trait of `pallet-xcm-benchmarks` with a default implementation that mimics the code that existed previous to this PR. Rationale: not allowing to set the `WeightLimit` and the `FeeAsset` might mean that we dont benchmark the worst case, as with `WeightLimit::Unlimited` the `Trader` does not even execute: https://github.com/paritytech/polkadot-sdk/blob/c01dbebeaa6394691974de46dd2d41a582f6a4c2/polkadot/xcm/xcm-executor/src/lib.rs#L833 The new configurable function allows projects to customize the parameters with which the benchmark is run to make sure they account for the worst-case scenario **This is very likely the case of the assethub system chain**, with several traders being analyzed and possibly several reads being made: https://github.com/paritytech/polkadot-sdk/blob/38d2fa859861005157ccb249dca1378f015e0b06/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs#L403 --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
Adds
worst_case_buy_execution
to the Config trait ofpallet-xcm-benchmarks
with a default implementation that mimics the code that existed previous to this PR.Rationale: not allowing to set the
WeightLimit
and theFeeAsset
might mean that we dont benchmark the worst case, as withWeightLimit::Unlimited
theTrader
does not even execute:polkadot-sdk/polkadot/xcm/xcm-executor/src/lib.rs
Line 833 in c01dbeb
The new configurable function allows projects to customize the parameters with which the benchmark is run to make sure they account for the worst-case scenario
This is very likely the case of the assethub system chain, with several traders being analyzed and possibly several reads being made:
polkadot-sdk/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs
Line 403 in 38d2fa8