Skip to content

[PATCH v6] api: timer: support period setting directly with frequency#2323

Open
TuomasTaipale wants to merge 3 commits intoOpenDataPlane:masterfrom
TuomasTaipale:dev/add_timer_per_type
Open

[PATCH v6] api: timer: support period setting directly with frequency#2323
TuomasTaipale wants to merge 3 commits intoOpenDataPlane:masterfrom
TuomasTaipale:dev/add_timer_per_type

Conversation

@TuomasTaipale
Copy link
Copy Markdown
Collaborator

@TuomasTaipale TuomasTaipale commented Mar 10, 2026

On top of #2320

v5:

  • Petri's comments
  • Fixed implementation and tests
  • Ready for review

v6:

  • Rebased
  • Shijith's comment

@odpbuild odpbuild changed the title api: timer: support period setting directly with frequency [PATCH v1] api: timer: support period setting directly with frequency Mar 10, 2026
@MatiasElo MatiasElo added this to the v1.50.0 milestone Mar 12, 2026
@TuomasTaipale TuomasTaipale force-pushed the dev/add_timer_per_type branch from 0cd8102 to eabd867 Compare March 19, 2026 08:46
@odpbuild odpbuild changed the title [PATCH v1] api: timer: support period setting directly with frequency [PATCH v2] api: timer: support period setting directly with frequency Mar 19, 2026
@TuomasTaipale TuomasTaipale force-pushed the dev/add_timer_per_type branch from eabd867 to 4dd48d2 Compare March 19, 2026 10:10
@odpbuild odpbuild changed the title [PATCH v2] api: timer: support period setting directly with frequency [PATCH v3] api: timer: support period setting directly with frequency Mar 19, 2026
@TuomasTaipale TuomasTaipale force-pushed the dev/add_timer_per_type branch from 4dd48d2 to a9b6979 Compare March 19, 2026 12:28
@odpbuild odpbuild changed the title [PATCH v3] api: timer: support period setting directly with frequency [PATCH v4] api: timer: support period setting directly with frequency Mar 19, 2026
@TuomasTaipale TuomasTaipale force-pushed the dev/add_timer_per_type branch from a9b6979 to c1a881d Compare March 24, 2026 10:19
@odpbuild odpbuild changed the title [PATCH v4] api: timer: support period setting directly with frequency [PATCH v5] api: timer: support period setting directly with frequency Mar 24, 2026
@TuomasTaipale TuomasTaipale marked this pull request as ready for review March 24, 2026 10:47
Copy link
Copy Markdown
Collaborator

@psavol psavol left a comment

Choose a reason for hiding this comment

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

Reviewed API changes.

@shijith
Copy link
Copy Markdown

shijith commented Mar 25, 2026

Hi @TuomasTaipale ,

Instead of adding ODP_TIMER_TYPE_PERIODIC_2, could the period configuration method be a separate mode field inside the periodic sub-struct? as there is really only one periodic timer concept.

typedef enum {
ODP_TIMER_PERIODIC_MODE_MULT = 0, /* base_freq × multiplier /
ODP_TIMER_PERIODIC_MODE_FREQ, /
direct frequency */
} odp_timer_periodic_mode_t;

The mode would sit next to the union it discriminates.
struct {
odp_timer_periodic_mode_t mode;
union {
struct { ... } mult; /* used when mode == MODE_MULT /
struct { ... } freq; /
used when mode == MODE_FREQ */
};
uint32_t uarea_size;
} periodic;

This would also avoid needing to recall a type_1 -> PERIODIC, type_2 -> PERIODIC_2 mapping.

Instead of configuring a single event to be sent for periodic timer
expirations, application now configures a timeout pool to be created as
part of timer pool creation. This enables more flexibility for
implementations to control how they setup the periodic timer expiration
signaling.

Additionally, periodic timers are now allocated with the new
`odp_timer_periodic_alloc()` function the parameters of which now
house a combination of parameters from `odp_timer_alloc()` and
`odp_timer_periodic_start_t`. In particular the `freq_multiplier`
is now part of timer allocation which implementation can utilize
in calculating needed timeout events for a timer as well as an
application provided callback that can be used to initialize the
user areas of the to-be-allocated timeout events.

Lastly, periodic timer related function specifications clarified
in places.

Signed-off-by: Tuomas Taipale <tuomas.taipale@nokia.com>
Add tests for `odp_timeout_is_periodic()`.

Signed-off-by: Tuomas Taipale <tuomas.taipale@nokia.com>
Add alternative method for configuring periodic timer frequency for
timer pools and timers. The new method introduces a new periodic timer
type `ODP_TIMER_TYPE_PERIODIC_FREQ` to be used with periodic timer
capability checks and timer pool creation. Old periodic timer type
`ODP_TIMER_TYPE_PERIODIC` is renamed to `ODP_TIMER_TYPE_PERIODIC_BASE_MUL`
to better reflect the differences between these two types.

Capability checks and timer pool configuration is based on a list of
constraining periodic timer frequencies that are used to dimension the
underlying timer pool resources. Subsequently, timers from the new type
of timer pools can be started directly with a wanted timer frequency.

Signed-off-by: Tuomas Taipale <tuomas.taipale@nokia.com>
@TuomasTaipale TuomasTaipale force-pushed the dev/add_timer_per_type branch from c1a881d to af6f323 Compare March 27, 2026 08:20
@odpbuild odpbuild changed the title [PATCH v5] api: timer: support period setting directly with frequency [PATCH v6] api: timer: support period setting directly with frequency Mar 27, 2026
@TuomasTaipale
Copy link
Copy Markdown
Collaborator Author

Hi @TuomasTaipale ,

Instead of adding ODP_TIMER_TYPE_PERIODIC_2, could the period configuration method be a separate mode field inside the periodic sub-struct? as there is really only one periodic timer concept.

typedef enum { ODP_TIMER_PERIODIC_MODE_MULT = 0, /* base_freq × multiplier / ODP_TIMER_PERIODIC_MODE_FREQ, / direct frequency */ } odp_timer_periodic_mode_t;

The mode would sit next to the union it discriminates. struct { odp_timer_periodic_mode_t mode; union { struct { ... } mult; /* used when mode == MODE_MULT / struct { ... } freq; / used when mode == MODE_FREQ */ }; uint32_t uarea_size; } periodic;

This would also avoid needing to recall a type_1 -> PERIODIC, type_2 -> PERIODIC_2 mapping.

@shijith Thanks for checking. Initially we had this two-level structure for the new periodic types but decided not to go with that as it would be perhaps a bit cumbersome/error-prone for application. Using the existing odp_timer_type_t should be clear enough.

In v6, swapped the type_x fields to base_mul and freq and modified the type constants accordingly.

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.

4 participants