Based on the analysis of section 3 "Detailed Workflow" from the plugin-agnostic QP negotiation design document, this diagram illustrates the complete end-to-end workflow including all major phases: Framework Initialization, Session Creation, QP Exchange, and Error Handling.
graph TB
%% Framework Initialization Phase
subgraph "1. Framework Initialization"
A[QpFramework.__init__] --> B[Initialize Plugin Registry]
B --> C[Initialize Session Manager]
C --> D{Plugin Registration Method?}
D -->|Manual| E[framework.register_plugin<br/>VendorPlugin]
D -->|Auto-Discovery| F[framework.discover_plugins<br/>Future Enhancement]
E --> G[Validate Plugin Interface]
F --> G
G --> H[Check Conflicts with Existing Plugins]
H --> I[Call plugin.initialize]
I --> J[Plugin Validation Complete]
J --> K[Verify Required Methods]
K --> L[Check Variant Availability]
L --> M[Validate Configuration Parameters]
M --> N[Framework Ready]
end
%% Session Creation Phase
subgraph "2. Session Creation"
N --> O[framework.get_variant<br/>plugin_id, variant_id, config]
O --> P[Validate Plugin Exists & Initialized]
P --> Q[Check Variant Available in Plugin]
Q --> R[Create Variant Instance with Config]
R --> S[Return Configured Variant Instance]
S --> T{Determine Transport Type}
T -->|Python Module| U[Load PythonModuleTransport]
T -->|C++ .so Library| V[Load SoLibraryTransport]
U --> W[Configure Transport with Connection Parameters]
V --> W
W --> X[framework.create_session<br/>variant, server_address]
X --> Y[Initialize ClientServerTransport]
Y --> Z[Establish Connection to QP Server]
Z --> AA[Validate Connectivity and Readiness]
AA --> BB[Session Ready]
end
%% QP Exchange Phase
subgraph "3. QP Exchange Process"
BB --> CC[session.execute_exchange_with_server<br/>variant.rdma_info_exchange]
%% Single Exchange Loop
subgraph "Single Exchange Loop"
CC --> DD[Framework calls variant method<br/>peer_data=None initial call]
DD --> EE[Plugin serializes local QP data<br/>vendor-specific format]
EE --> FF[Plugin maintains internal state<br/>for multi-round exchanges]
FF --> GG[Returns data: serialized_data<br/>completed: False]
GG --> HH[transport.send_message<br/>sends data to server]
HH --> II[transport.receive_message<br/>waits for server response]
II --> JJ[Handle network errors and retries]
JJ --> KK[Framework calls variant method<br/>peer_data=received_data]
KK --> LL[Plugin deserializes and<br/>processes peer data]
LL --> MM[Plugin updates internal state<br/>and local QP structures]
MM --> NN[Returns local_rcvd_data: processed_data<br/>completed: True/False]
NN --> OO{Exchange Complete?}
OO -->|completed=False| HH
OO -->|completed=True| PP[Update exchange history<br/>for debugging/monitoring]
end
PP --> QQ[RDMA Info Exchange Complete]
end
%% Complete QP Negotiation
subgraph "4. Complete QP Negotiation"
QQ --> RR[Stage 1: RDMA Info Exchange]
RR --> SS[Exchange QP numbers, addresses, keys]
SS --> TT[Establish RDMA connection parameters]
TT --> UU[Validate QP pair connectivity]
UU --> VV[Stage 2: RDMA Ready Exchange]
VV --> WW[session.execute_exchange_with_server<br/>variant.rdma_ready_exchange]
WW --> XX[Signal readiness for RDMA operations]
XX --> YY[Synchronize QP state transitions]
YY --> ZZ[Confirm both sides ready for data transfer]
ZZ --> AAA{Optional Stage 3?}
AAA -->|Yes| BBB[Stage 3: RDMA Done Exchange]
AAA -->|No| FFF[QP Negotiation Complete]
BBB --> CCC[session.execute_exchange_with_server<br/>variant.rdma_done_exchange]
CCC --> DDD[Signal completion of RDMA operations]
DDD --> EEE[Cleanup temporary resources]
EEE --> FFF
end
%% Error Handling
subgraph "5. Error Handling"
GGG[Transport Layer Errors]
GGG --> HHH[Connection Timeout]
GGG --> III[Server Unreachable]
HHH --> JJJ[Retry with Exponential Backoff]
III --> KKK[Failover to Backup Server<br/>Future Enhancement]
LLL[Plugin Layer Errors]
LLL --> MMM[Serialization Failure]
LLL --> NNN[Invalid Peer Data]
LLL --> OOO[Resource Exhaustion]
LLL --> PPP[Vendor Library Error]
LLL --> QQQ[Configuration Error]
MMM --> RRR[Log Error Details, Abort Exchange]
NNN --> RRR
OOO --> RRR
PPP --> RRR
QQQ --> RRR
SSS[Framework Layer Errors]
SSS --> TTT[Plugin Not Found]
SSS --> UUU[Variant Not Available]
SSS --> VVV[Session Timeout]
SSS --> WWW[Unexpected Exception]
TTT --> XXX[Attempt Dynamic Loading or Report Error]
UUU --> YYY[List Available Variants, Suggest Alternatives]
VVV --> ZZZ[Cleanup Session, Report Error]
WWW --> AAAA[Log Full Stack Trace, Abort Exchange]
end
%% Error connections (showing where errors can occur)
HH -.->|Error| GGG
II -.->|Error| GGG
EE -.->|Error| LLL
LL -.->|Error| LLL
O -.->|Error| SSS
X -.->|Error| SSS
%% Styling
classDef initPhase fill:#e1f5fe
classDef sessionPhase fill:#f3e5f5
classDef exchangePhase fill:#e8f5e8
classDef negotiationPhase fill:#fff3e0
classDef errorPhase fill:#ffebee
class A,B,C,D,E,F,G,H,I,J,K,L,M,N initPhase
class O,P,Q,R,S,T,U,V,W,X,Y,Z,AA,BB sessionPhase
class CC,DD,EE,FF,GG,HH,II,JJ,KK,LL,MM,NN,OO,PP,QQ exchangePhase
class RR,SS,TT,UU,VV,WW,XX,YY,ZZ,AAA,BBB,CCC,DDD,EEE,FFF negotiationPhase
class GGG,HHH,III,JJJ,KKK,LLL,MMM,NNN,OOO,PPP,QQQ,RRR,SSS,TTT,UUU,VVV,WWW,XXX,YYY,ZZZ,AAAA errorPhase
- Purpose: Set up the QP negotiation framework with plugin support
- Key Steps:
- Initialize core components (plugin registry, session manager)
- Register vendor plugins (manual or auto-discovery)
- Validate plugin compliance and configuration
- Output: Ready-to-use framework with registered plugins
- Purpose: Establish a communication session between client and server
- Key Steps:
- Select and configure vendor variant
- Determine and load appropriate transport adapter (Python/C++ .so)
- Establish client-server connection
- Output: Active session ready for QP exchanges
- Purpose: Core data exchange mechanism for QP information
- Key Features:
- Iterative exchange pattern supporting multi-round negotiations
- Plugin-controlled serialization/deserialization
- Framework-managed transport operations
- State tracking and completion detection
- Flow: Initial call → Serialize → Send → Receive → Process → Check completion → Repeat if needed
- Purpose: Full end-to-end RDMA QP setup process
- Stages:
- RDMA Info Exchange: Exchange QP numbers, addresses, keys
- RDMA Ready Exchange: Signal readiness and synchronize state
- RDMA Done Exchange (Optional): Final cleanup and confirmation
- Result: Fully negotiated and ready RDMA connections
- Scope: Comprehensive error management across all layers
- Categories:
- Transport Layer: Network timeouts, server connectivity issues
- Plugin Layer: Serialization failures, vendor library errors
- Framework Layer: Plugin/variant not found, configuration issues
- Strategy: Log details, attempt recovery where possible, graceful abort on critical errors
This workflow is designed for the IxN → Arista Switch → Device2 topology you mentioned, where:
- IxN: Acts as the traffic generator/client in the QP negotiation
- Arista Switch: Provides L2/L3 connectivity with IPv6 neighbor discovery support
- Device2: Acts as the server/peer in the QP negotiation
The framework's client-server model maps well to this topology, with the QP negotiation server potentially running on Device2 and IxN connecting as a client through the Arista switch infrastructure.
For IPv6 neighbor discovery in your setup:
- The transport layer supports IPv6 addressing
- Neighbor discovery protocol (NDP) handling is transparent to the QP negotiation framework
- The Arista switch handles IPv6 routing and neighbor resolution
- Framework can work with IPv6 addresses for server connectivity


