parachain-system: send core selector ump signal #5888
Conversation
|
/cmd prdoc --help |
Command help: |
|
/cmd prdoc --pr 5888 |
|
Command "prdoc --pr 5888" has started 🚀 See logs here |
|
Command "prdoc --pr 5888" has finished ✅ See logs here |
| @@ -1418,6 +1429,21 @@ impl<T: Config> Pallet<T> { | |||
| CustomValidationHeadData::<T>::put(head_data); | |||
| } | |||
|
|
|||
| /// Send the ump signals | |||
| #[cfg(feature = "experimental-ump-signals")] | |||
There was a problem hiding this comment.
Wondering if it would be a good idea to hide the `select_core_for_child runtime API behind this feature ?
There was a problem hiding this comment.
I don't think it helps us. The parachain can implement the API without any problem. I introduced the compile-time feature because otherwise the relay chain would have rejected these candidates
| @@ -260,8 +262,7 @@ where | |||
| relay_parent, | |||
| params.para_id, | |||
| &mut params.relay_client, | |||
| // Use depth 0, to preserve behaviour. | |||
| ClaimQueueOffset(0), | |||
| ClaimQueueOffset(DEFAULT_CLAIM_QUEUE_OFFSET), | |||
There was a problem hiding this comment.
Didn't we want to use 0 to preserve old behaviour ?
There was a problem hiding this comment.
the problem with using 0 is this:
we have a DEFAULT_CLAIM_QUEUE_OFFSET of 1 (as you also suggested).
The default implementation of the SelectCore trait uses DEFAULT_CLAIM_QUEUE_OFFSET.
if we instead use here offset 0 and the runtime is updated to use offset 1, there will be a discrepancy and the collator will not advertise to the right core. we need these two places to use the same offset.
There was a problem hiding this comment.
Explanation makes sense to me, offset of 1 should also not break anything here.
There was a problem hiding this comment.
an alternative would be to set the DEFAULT_CLAIM_QUEUE_OFFSET to 0 and have some kind of LookaheadCoreSelector impl of SelectCore that uses a claim queue offset of 1.
the current state of the PR (with lookahead using offset 1) breaks the coretime-shared-core zombienet test because core sharing doesn't work between paras if one of the paras is not producing blocks. will be fixed by #5461
There was a problem hiding this comment.
actually I think using a default claim queue offset of 0 is a must, because if the UMP signal is not present, the runtime will assume offset 0: #5423
There was a problem hiding this comment.
and another reason to use default offset 0 is because the claim queue size is at least 1 (so an offset of 1 will not work on a network that is configured with size 1)
There was a problem hiding this comment.
an alternative would be to set the DEFAULT_CLAIM_QUEUE_OFFSET to 0 and have some kind of LookaheadCoreSelector impl of SelectCore that uses a claim queue offset of 1.
I've implemented this now
alindima
added
T9-cumulus
| @@ -260,8 +262,7 @@ where | |||
| relay_parent, | |||
| params.para_id, | |||
| &mut params.relay_client, | |||
| // Use depth 0, to preserve behaviour. | |||
| ClaimQueueOffset(0), | |||
| ClaimQueueOffset(DEFAULT_CLAIM_QUEUE_OFFSET), | |||
There was a problem hiding this comment.
Explanation makes sense to me, offset of 1 should also not break anything here.
louismerlin
changed the title
louismerlin
changed the title
Runtime side of #5048
Send the core selector ump signal in cumulus. Guarded by a compile time feature until nodes are upgraded to a version that includes #5423 for gracefully handling ump signals.