Skip to content

Config schema: dataplane

This page lists the fields for the top-level dataplane: block — the dataplane runtime model Conduit uses to spread the per-query pipeline across OS threads. For the behavior in context — what each runtime does, the worker roles, and the slot pool — see Runtime and concurrency.

The runtime is chosen once at process startup. Changing dataplane: requires a restart to take effect; it does not apply on reload.

dataplane

Property Value
Type Mapping (object)
Required No — defaults apply when the block is omitted
Location Top-level key in the config file

When dataplane: is omitted, Conduit runs the sync runtime with the defaults in the table below.

Block fields

FieldTypeRequiredDefaultDescription
runtimestringnosyncDataplane execution model: sync or split_io. See Runtime values.
policy_workersintegerno1Number of policy worker threads under split_io. Must be ≥ 1 when runtime: split_io; ignored under sync.
io_workersintegerno1Number of I/O poll worker threads under split_io. Each value of N starts N independent poll loops (each with its own upstream egress sockets). Must be ≥ 1 when runtime: split_io; ignored under sync.
slot_chunk_sizeintegerno256Growth chunk (in transaction slots) for the slot pool. Applies to both runtimes; must be ≥ 1 when set. See Slot chunk size.

Runtime values

Value Status Behavior
sync (default) Shipped One ingress worker runs the whole pipeline on its own thread, including the blocking upstream wait, then sends the reply before taking the next query. See Sync runtime.
split_io Shipped Separate ingress, policy, and I/O worker pools; upstream waits are parked so ingress keeps accepting queries during slow upstreams. See Split I/O runtime.

Any other value is rejected by conduitctl validate --file. Use sync or split_io.

Worker pools (split_io)

policy_workers and io_workers size the two non-ingress pools that split_io adds:

  • policy_workers — threads that run the orchestrator phases (Request rules, Lookup including forward-provider submit) and finish each transaction at Response rules / Send. Raise it for more concurrent policy and Rhai execution.
  • io_workers — threads that own the upstream sockets, match replies to parked transactions, and enforce forward.timeout_ms. io_workers: N runs exactly N I/O poll threads (restart required to change). Raise it for more upstream socket fan-out when a single poller is saturated.

Both default to 1 and are ignored under sync (which has no separate policy/I/O pools — the ingress thread does everything). Ingress thread count is not set here: it comes from listeners.threads (per listener). See Worker counts and limits and Listeners.

Slot chunk size

Both runtimes track in-flight queries in a preallocated transaction slot pool that grows in chunks up to orchestrator.txn_table_capacity (default 1024). slot_chunk_size sets how many slots each growth step allocates (default 256) — a tuning knob that trades startup/steady-state memory against allocation frequency under rising load. It does not change the pool's ceiling; that is orchestrator.txn_table_capacity (Orchestrator). See Transaction slot pool.

Reload and restart

The dataplane: block is a start-time setting.

Change Effect
Edit dataplane: on disk + reload (SIGHUP or conduitctl reload), or conduitctl apply a patch The runtime snapshot updates, but the running runtime model and worker counts do not change
Restart Required for a new runtime, policy_workers, io_workers, or slot_chunk_size to take effect

This differs from dynamic blocks such as shutdown:, which are read live. See Architecture — Runtime snapshot for which changes need a restart.

Validation summary

conduitctl validate --file … rejects:

  • runtime other than sync or split_io.
  • policy_workers: 0 or io_workers: 0 when runtime is split_io.
  • slot_chunk_size: 0 when the field is set.

Under sync, policy_workers and io_workers are not validated for range because they are unused.

Example configuration

Default — omit the block (equivalent to runtime: sync):

# no dataplane: block — sync runtime
listeners:
  threads: 2

Split I/O runtime with four policy workers and one I/O worker:

dataplane:
  runtime: split_io
  policy_workers: 4
  io_workers: 1
listeners:
  threads: 2
  reuse_port: true

Larger slot-pool growth chunk for a high-capacity deployment:

dataplane:
  runtime: split_io
  policy_workers: 8
  io_workers: 2
  slot_chunk_size: 1024
orchestrator:
  txn_table_capacity: 65536