Reference architecture · Managed resources

Shared PCIe Device Access

Pool compatible PCIe devices and expose them through Device Lending with native drivers or through the SISCI SmartIO extension for application-managed access.

Resource pool NVMe · GPU · FPGA · NIC
Ownership Exclusive devices; virtual functions may be assigned separately
Software Device Lending / SISCI SmartIO
Operations Assign, release, reset and reassign
Reference topology Device pool and lending
Host A Borrower / application Requests an available resource
Host B Borrower / application Uses another assigned resource
Host C Standby / workflow Receives a device after release
NTB fabric Direct or switched PCIe fabric NTB mappings and SmartIO lifecycle control
resource NVMe · GPU · FPGA pool Compatible devices presented through supported models
Control plane PCIe data plane
Operating model

How the architecture works

The sequence describes system behaviour rather than a product feature list.

Prepare

Qualify the device, driver, reset behaviour, lender-side peer-to-peer capability, NTB mapping size, IOMMU policy and platform support for the selected access model.

Assign

Device Lending presents an eligible remote device to one borrower for native driver binding; SISCI SmartIO exposes device resources through an application-managed API.

Release

The workflow quiesces active users, releases or unbinds the device, restores or resets state where required and returns the resource to the pool or local use.

System definition

Reference topology and architectural boundaries

Ownership, data movement, software responsibility and the limits of the pattern are defined separately.

System-level view Device pool and lending
Host A Borrower / application Requests an available resource
Host B Borrower / application Uses another assigned resource
Host C Standby / workflow Receives a device after release
NTB fabric Direct or switched PCIe fabric NTB mappings and SmartIO lifecycle control
resource NVMe · GPU · FPGA pool Compatible devices presented through supported models
Qualification required Application-aware design
Ownership model

Exclusive by default

Device Lending normally assigns a device to one borrowing host at a time.

Concurrent access

Requires explicit support

SR-IOV or an application-managed SmartIO model is needed for supported simultaneous use.

Driver model

Device and release dependent

Native unmodified driver borrowing is documented for Linux; SISCI SmartIO uses an application-managed access path. Device, kernel, platform and release support must be confirmed.

Lifecycle model

Managed assignment

Hot-add, removal, reset, IOMMU grouping and cleanup must be engineered as one workflow.

Engineering criteria

Design decisions that determine whether the architecture will work

These items must be resolved for the actual hosts, endpoints, operating systems, topology and workload.

Access model
Choose Device Lending for exclusive native-driver ownership, SISCI SmartIO for application-managed device access, or separately assigned SR-IOV virtual functions where supported.
Device compatibility
Confirm device class, driver, firmware, reset capability, lender-side P2P support, NTB window requirements and the published platform/kernel support matrix.
Isolation
Review IOMMU groups, requester IDs, ACS behaviour, security boundary and tenant/workflow separation.
Lifecycle automation
Define assignment, quiesce, unbind, reset, handover, failure recovery and audit logging.
Capacity planning
Size device count, fabric ports, lane width, power, cooling and expected concurrency around the workflow schedule.
Implementation layers

Building blocks used to realize the architecture

The final system combines compatible hardware, software, application logic and validation—not one standalone product.

Building block

Borrowing hosts

Independent computers with compatible NTB adapters and supported software.

Building block

Managed fabric

A direct or switched NTB fabric configured for address translation, resource routing and isolation.

Building block

Device pool

Qualified NVMe, GPU, FPGA, NIC or other supported PCIe resources.

Building block

eXpressWare services

SmartIO core services, Device Lending, the SISCI SmartIO extension and release-specific management tools.

Building block

Workflow control

Scheduler, policy, ownership state, audit and failure handling.

Building block

Qualification suite

Assign/release cycles, reset, driver rebinding, load, isolation and recovery tests.

Selection boundary

Where this architecture fits

Use the pattern when its ownership and data-movement model match the engineering requirement.

Deployment fit

Use this architecture

Expensive or specialized PCIe devices sit idle because every host has a dedicated copy.

Architecture boundary

Use another architecture

Several hosts must transparently and concurrently use a device that has no virtualization or application-managed sharing support.

Deployment fit

Typical deployments

Shared NVMe pools, accelerator farms, test resources, FPGA appliances and scheduled engineering workflows.

Project definition

Inputs required before system configuration

Architecture selection starts with the actual platform, traffic, software and recovery requirements.

Device inventory Exact device, firmware, driver, reset method, SR-IOV capability and IOMMU grouping.
Host inventory OS, kernel/driver release, slots, adapters and security policy.
Ownership policy Who may borrow, duration, concurrency, priority, release and audit requirements.
Failure handling Host crash, device timeout, forced reclaim, reset and restoration to service.

Define the topology before selecting the components.

Primionics can review the root-complex model, endpoint inventory, lane and bandwidth budget, software path, operating-system support and qualification requirements for the complete PCIe system.

Discuss the system