Skip to content

Conversation

@sanvai01
Copy link

Added wfe and wfet instruction library functions in wait_until header file

Added wfe and wfet instruction library functions in wait_until header file

Signed-off-by: Sanjyot Vaidya <Sanjyot.Vaidya@arm.com>
@odpbuild odpbuild changed the title linux-gen: added wfe and wfet library functions [PATCH v1] linux-gen: added wfe and wfet library functions Sep 12, 2025
@odpbuild odpbuild changed the title [PATCH v1] linux-gen: added wfe and wfet library functions [PATCH v2] linux-gen: added wfe and wfet library functions Sep 12, 2025
_ODP_PRINT("%s\n", ndef);
#endif

_ODP_PRINT(" __ARM_FEATURE_WFXT ");
Copy link
Collaborator

Choose a reason for hiding this comment

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

See my comment in PR 2257 about commit message and merge commits.

}

static inline void
_odp_wait_until_equal_rel_u32(odp_atomic_u32_t *addr, uint32_t expected)
Copy link
Collaborator

Choose a reason for hiding this comment

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

How is this function supposed/allowed to be different from _odp_wait_until_equal_32()? What does the rel part of this function indicate? In ODP, rel in a function name implies release memory ordering, but I cannot see what release ordering would mean in a function that does not stores. Or does ldxr synchronize with acquire loads in other threads? Even if it does, I am not sure providing a release type function would be useful. It could also be cumbersome for a generic C implementation, but since such is not provided in this PR, then why is this even a separate function in this aarch64 specific implementation?

}

static inline void
_odp_wait_until_equal_32(odp_atomic_u32_t *addr, uint32_t expected)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we even need this function with a relaxed memory order? Aren't most (practically all?) concievable uses such that acquire is required? Maybe there is not need to introduce this new function until there is an actual user of it.

__asm__ volatile("sevl" : : : "memory");
do {
#ifdef __ARM_FEATURE_WFXT
__asm__ volatile("wfet %x0" : : "r"(100) : "memory");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why would WFET be useful here and better than WFE? If it is useful, then why not make the same change in the existing _odp_wait_until_equal_acq_u32() function?

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.

2 participants