QP Negotiation Framework - Complete Workflow Diagram

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.

Complete End-to-End Workflow

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

Loading

Key Workflow Components Analysis

1. Framework Initialization Workflow

• 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

2. Session Creation Workflow

• 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

3. QP Exchange Workflow

• 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

4. Complete QP Negotiation

• Purpose: Full end-to-end RDMA QP setup process
• Stages:
  1. RDMA Info Exchange: Exchange QP numbers, addresses, keys
  2. RDMA Ready Exchange: Signal readiness and synchronize state
  3. RDMA Done Exchange (Optional): Final cleanup and confirmation
• Result: Fully negotiated and ready RDMA connections

5. Error Handling

• 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

Network Topology Context

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.

IPv6 Networking Considerations

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