io_engine/context.rs
1use crate::callback_worker::Worker;
2use crate::driver::aio::AioDriver;
3use crate::driver::uring::UringDriver; // Import UringDriver
4use crate::tasks::{IOCallback, IOEvent};
5use crossfire::BlockingRxTrait;
6use std::io;
7
8pub enum Driver {
9 Aio,
10 Uring,
11}
12
13/// Setup the submission of IO tasks to the underlying driver.
14///
15/// It is generic over the callback type `C`, the submission queue `Q`, and the worker type `W`.
16///
17/// # Channel Selection for `W` (Worker)
18///
19/// When configuring the worker `W` (usually a channel sender `cb_workers`),
20/// you should choose the `crossfire` channel type based on your sharing model:
21///
22/// * **Shared Worker (Multiple Producers):** If you have multiple submission channels sharing the same
23/// callback worker, use the [IOWorkers](crate::callback_worker::IOWorkers) struct,
24/// or pass `crossfire::MTx` (from `mpsc` or `mpmc` channels) with your custom worker implementation.
25/// This allows multiple producers to send completion events to a single consumer (worker).
26///
27/// * **Single Instance (Dedicated Worker):** If you have a single submission channel with its own dedicated
28/// callback worker, use `crossfire::Tx` (from `spsc` channels). This is more efficient for single-producer
29/// scenarios.
30///
31/// * **inline callback:** If you have a very light callback logic, you can use [Inline](crate::callback_worker::Inline)
32pub fn setup<C, Q, W>(
33 depth: usize,
34 rx: Q,
35 cb_workers: W,
36 driver_type: Driver, // New parameter
37) -> io::Result<()>
38where
39 C: IOCallback,
40 Q: BlockingRxTrait<Box<IOEvent<C>>> + Send + 'static,
41 W: Worker<C> + Send + 'static,
42{
43 match driver_type {
44 Driver::Aio => AioDriver::<C, Q, W>::start(depth, rx, cb_workers),
45 Driver::Uring => UringDriver::<C, Q, W>::start(depth as u32, rx, cb_workers),
46 }
47}