RTIO: Add Workqueue support for delayed work items

[ubieda]

Is your enhancement proposal related to a problem? Please describe.
Based on a discussion in #74389, it was brought up that some RTIO users may need to perform transactions spaced by time-intervals. This is similar to how the Zephyr Workqueue works. Right now it is not possible as the RTIO Workqueue service does not have any means to achieve this.

Describe the solution you'd like
Add the ability to the RTIO Workqueue service to achieve this functionality.

This could be, for instance, achieved by adding an API rtio_work_req_schedule() similar to rtio_work_req_submit but with a k_timeout_t parameter describing when this item is due for execution.

Describe alternatives you've considered
Have users implement this functionality out of the RTIO workqueue service (e.g: have an additional delayed work item which in turn submits the RTIO workq item). This may be a short-term solution but does not seem scalable as more users re-invent the same functionality.

Additional considerations
This is a well-known feature already supported by the Zephyr workqueue, and that users are familiar with, which is why IMO it makes sense to include it under this service.

[ubieda]

@FlorianWeber1018 LMK if you have any additional inputs on this!

[josuah]

This is an interesting addition for combining RTIO and this particular Video driver:

• drivers: video: API enhancement #72959 (comment) (RTIO proposal)

• zephyr/drivers/video/video_sw_generator.c

  Lines 91 to 98 in 14b3293

  	static int video_sw_generator_stream_start(const struct device *dev)
  	{
  	struct video_sw_generator_data *data = dev->data;
  	k_work_schedule(&data->buf_work, K_MSEC(1000 / VIDEO_PATTERN_FPS));
  	return 0;
  	}

[ubieda]

This is an interesting addition for combining RTIO and this particular Video driver:

• drivers: video: API enhancement #72959 (comment) (RTIO proposal)

• zephyr/drivers/video/video_sw_generator.c

  Lines 91 to 98 in 14b3293

  	static int video_sw_generator_stream_start(const struct device *dev)
  	{
  	struct video_sw_generator_data *data = dev->data;
  	k_work_schedule(&data->buf_work, K_MSEC(1000 / VIDEO_PATTERN_FPS));
  	return 0;
  	}

Thanks for sharing this! I'll find some time soon on this addition

[ubieda]

Since the RTIO Workqueue is built on top of P4WQ, I'm thinking of implementing this feature for P4WQ and simply have RTIOWQ use it. Any thoughts/objections on this approach @teburd @andyross?

[FlorianWeber1018]

gently ping @teburd @andyross.
#79637 and #74389 are waiting for this feature.

[bearsh]

this would be a great addition since quite some hardware sensors do need a significant delay between triggering a new measurement and fetching the data.

[teburd]

We should add a OP_DELAY that wraps a k_timer to solve this in an asynchronous manner

[ubieda]

We should add a OP_DELAY that wraps a k_timer to solve this in an asynchronous manner

Sounds good. I'm planning to come back to this soon

[teburd]

We may need a k_timer pool :/

[ubieda]

We may need a k_timer pool :/

I was counting on the k_timer struct not being that significant to be contained within the SQE union (similar to tiny_tx) but I see it goes way beyond in size compared to the other elements.

I agree a pool is the way to go in this case (edit: I dropped some comments below after thinking through a bit more).

FWIW - If we're concerned on RTIO memory footprint, we can always hide it behind a Kconfig setting (turned off by default, unless used by a client).

[ubieda]

Hopefully not going off in a tangent here: one thing we may want to discuss is how do we want to assist users properly sizing the different pools that RTIO has for it to properly work. They already have to account for:

• SQE queue size.
• CQE queue size.
• RTIO mempool.
• RTIO workqueue size.
• RTIO timers pool (now).

Otherwise we may be making RTIO harder to use (or to trust it won't just break at run-time in X corner case).

[ubieda]

Ok, I've come with a PR to address this feature, using a separate SQE OP (OP_DELAY). This is not inherently a RTIO Workqueue delay, but this use-case can be covered by simply chaining a delay with a RTIO workqueue item.

PR Link: #88808