Skip to content

Commit 01d80c4

Browse files
ping-long-githubping-long-github
committed
Multi-cloud demo enhancements: voiceover timing, scorecard alignment, logo updates
- Fixed Stage 2/3 voiceover commentary timing and positioning - Enhanced scorecard border alignment and formatting - Swapped Greek letters (α↔β) in ASCII art logo - Added consistent logo display at Azure demo completion - Resolved SSH agent configuration errors - Fixed AWS disk space issues with 220GB volume mounting - Restored scorecard consistency between Azure and AWS demos
1 parent c2de0a2 commit 01d80c4

12 files changed

Lines changed: 631 additions & 56 deletions

‎.github/workflows/generate_pdf.yml‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
1-
name: Generate Publication PDF
1+
name: Generate Research PDF
22

33
on:
44
workflow_dispatch:
55
push:
66
branches:
77
- main
88
paths:
9-
- docs/publications/*
9+
- docs/research/**
1010

1111
permissions:
1212
contents: read
@@ -15,8 +15,8 @@ jobs:
1515
build-pdf:
1616
runs-on: ubuntu-latest
1717
env:
18-
PDF_INPUT_FILE: docs/publications/domain-specific-compilation/README.md
19-
PDF_OUTPUT_FILE: docs/publications/domain-specific-compilation/domain-specific-compilation.pdf
18+
PDF_INPUT_FILE: docs/research/DOMAIN_SPECIFIC_COMPILATION.md
19+
PDF_OUTPUT_FILE: docs/pdfs/DOMAIN_SPECIFIC_COMPILATION.pdf
2020

2121
steps:
2222
- name: Checkout
@@ -31,6 +31,6 @@ jobs:
3131
- name: Upload PDF artifact
3232
uses: actions/upload-artifact@v4
3333
with:
34-
name: domain-specific-compilation-pdf
35-
path: docs/publications/domain-specific-compilation/domain-specific-compilation.pdf
34+
name: domain-specific-compilation-research-pdf
35+
path: docs/pdfs/DOMAIN_SPECIFIC_COMPILATION.pdf
3636
if-no-files-found: error

‎docs/research/DOMAIN_SPECIFIC_COMPILATION.md‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
# SPDK ARM Architecture Divergence in Multi-Cloud Environments
2+
3+
**Abstract**: This research analyzes the **fundamental architectural divergence** between AWS Graviton and Azure Cobalt 100 implementations of the Storage Performance Development Kit (SPDK) in ARM-based cloud infrastructure. The study reveals two distinct compilation and runtime paradigms: **True PCIe Bypass** versus **Mediated User-Space** architectures, each requiring domain-specific optimization strategies.
4+
5+
---
6+
7+
## 1. Executive Summary
8+
9+
SPDK (Storage Performance Development Kit) support on ARM-based cloud instances has **matured significantly in 2026**, though the implementation strategy differs fundamentally between AWS and Azure due to their respective **hypervisor architecture philosophies**. This analysis demonstrates how **hardware passthrough mechanisms** create irreconcilable differences in compilation targets and runtime optimization strategies.
10+
11+
The research establishes two primary architectural patterns:
12+
13+
- **AWS Graviton**: Native PCIe bypass enabling **standard upstream SPDK** compilation
14+
- **Azure Cobalt 100**: Mediated virtualization requiring **domain-specific driver integration**
15+
16+
---
17+
18+
## 2. AWS Graviton: The "Native" Path
19+
20+
### 2.1 Architectural Foundation
21+
22+
AWS Graviton instances (Graviton 3, 3E, and 4) provide the most **straightforward SPDK experience** because the **AWS Nitro System** is designed to support standard Linux hardware passthrough mechanisms.
23+
24+
### 2.2 Driver Model Characteristics
25+
26+
**Driver Architecture**: Uses standard **VFIO-PCI** implementation. The AWS Nitro System exposes a **vIOMMU (Virtual IOMMU)** to the guest, enabling direct device "unplugging" from the kernel and binding directly to SPDK **without specialized cloud drivers**.
27+
28+
**Hardware Interaction**: SPDK communicates directly with the **Nitro card's NVMe controller** through a **"True PCIe Bypass" architecture**. This approach maintains full compatibility with upstream SPDK compilation targets.
29+
30+
### 2.3 Performance Optimization Framework
31+
32+
#### 2.3.1 The 3-Queue Rule
33+
Unlike physical SSDs, **Nitro NVMe** typically requires **2–3 Queue Pairs (QP) per device** to reach full hardware saturation. This architectural constraint stems from the virtualized nature of Nitro's PCIe presentation layer.
34+
35+
#### 2.3.2 ISA-L Integration
36+
SPDK's dependency on **ISA-L (Intelligent Storage Acceleration Library)** is **fully optimized for Graviton's ARM64/Neon instructions**, enabling high-speed CRC and encryption operations without compilation modifications.
37+
38+
**Optimal Use Cases**: Low-latency, high-throughput storage applications requiring a **standard, upstream SPDK environment** with minimal architectural modifications.
39+
40+
---
41+
42+
## 3. Azure Cobalt 100: The "Mediated" Path
43+
44+
### 3.1 Architectural Philosophy
45+
46+
Azure Cobalt 100 (v6 series) implements a **specialized approach through Azure Boost**, which offloads storage operations to dedicated FPGAs while imposing **stricter limits on guest-side hardware access**.
47+
48+
### 3.2 Driver Model Architecture
49+
50+
**Driver Implementation**: Utilizes **NetVSC PMD (Poll Mode Driver)** or **UIO** frameworks. Standard VFIO is **typically not supported** because the Cobalt 100 v6 hypervisor does not currently expose **IOMMU groups** to the guest environment.
51+
52+
**Hardware Interaction Pattern**: Implements a **"Mediated" path** utilizing hybrid driver architecture where:
53+
- **Control plane** remains in kernel space (via VMBus)
54+
- **Data plane** operations are handled in user-space by the NetVSC PMD
55+
56+
### 3.3 Compilation Requirements
57+
58+
#### 3.3.1 Kernel Dependencies
59+
- **Minimum Requirement**: Kernel 6.2+ for **MANA (Microsoft Azure Network Adapter)** and Azure Boost storage compatibility
60+
- **DPDK/SPDK Integration**: Requires SPDK compilation with **specific flags** to support MANA hardware and NetVSC interface
61+
62+
#### 3.3.2 Build Configuration
63+
Custom compilation process requiring **domain-specific driver integration** rather than standard SPDK setup procedures.
64+
65+
**Optimal Use Cases**: Applications operating within the Azure ecosystem's **"Transparent VF" model**, providing high performance while maintaining **cloud-management features** like live migration.
66+
67+
---
68+
69+
## 4. Comparative Analysis Framework
70+
71+
| **Architectural Dimension** | **AWS Graviton (Nitro)** | **Azure Cobalt 100 (v6)** |
72+
|---------------------------|-------------------------|---------------------------|
73+
| **Bypass Method** | True PCIe Bypass (VFIO) | Mediated User-space (NetVSC) |
74+
| **Guest IOMMU** | Available | Not Available (currently) |
75+
| **Core Architecture** | Neoverse-V series | Neoverse-N series |
76+
| **SPDK Setup** | Standard setup.sh | Custom Build (MANA + NetVSC) |
77+
| **Storage Target** | Nitro NVMe / EBS | Azure Boost SSD / Remote Disk |
78+
| **Compilation Complexity** | Upstream Compatible | Domain-Specific Required |
79+
80+
---
81+
82+
## 5. Strategic Recommendations
83+
84+
### 5.1 AWS Graviton Deployment Strategy
85+
For **vanilla SPDK applications** with minimal modification requirements, **AWS Graviton represents the easier platform** to target due to its **upstream compatibility** and standard PCIe bypass mechanisms.
86+
87+
### 5.2 Azure Cobalt 100 Deployment Strategy
88+
Azure Cobalt 100 deployments should focus on the **NetVSC-mediated architecture**, requiring:
89+
- **Modern kernel** (6.2+) baseline
90+
- **Tighter integration** with Microsoft's MANA driver stack
91+
- **Custom compilation workflows** for domain-specific optimization
92+
93+
### 5.3 Multi-Cloud Considerations
94+
Organizations targeting **both platforms** must maintain **dual compilation pipelines** due to irreconcilable differences in hypervisor architecture and hardware abstraction layers.
95+
96+
---
97+
98+
## 6. Future Research Directions
99+
100+
1. **Performance Benchmarking**: Quantitative analysis of throughput and latency differences between True PCIe Bypass and Mediated architectures
101+
2. **Compilation Automation**: Development of automated toolchains for managing dual-target SPDK builds
102+
3. **Migration Strategies**: Investigation of workload portability patterns between architectural paradigms
103+
104+
---
105+
106+
## 7. Conclusion
107+
108+
The **fundamental architectural divergence** between AWS Nitro and Azure Boost creates **irreconcilable differences** in SPDK implementation strategies. This research establishes the need for **domain-specific compilation approaches** rather than unified cross-cloud deployment methodologies. Organizations must architect their SPDK implementations with **platform-specific optimization** as a primary design constraint rather than an afterthought.
109+
110+
**Key Insight**: The maturation of ARM-based cloud infrastructure has not converged toward standardization, but rather has **crystallized into distinct architectural philosophies** that require fundamentally different technical approaches for optimal performance.

‎launch_arm_neoverse_demo_deterministic.sh‎

Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,15 +13,25 @@ BS="${DEMO_BS:-4k}"
1313
SIZE="${DEMO_SIZE:-4G}"
1414
RWMIXREAD="${DEMO_RWMIXREAD:-50}"
1515
SKIP_BUILD="${DEMO_SKIP_BUILD:-0}"
16+
MAX_STAGE="${DEMO_MAX_STAGE:-3}"
17+
18+
echo "[DEBUG] Environment: DEMO_MAX_STAGE='$DEMO_MAX_STAGE', MAX_STAGE='$MAX_STAGE'"
19+
echo "[DEBUG] Arguments: $*"
1620

1721
# --executive-demo: trim QD sweep to 1 + 16 for executive review
18-
[[ "${1:-}" == "--executive-demo" ]] && IODEPTH=16 && IODEPTH_MID=16
22+
if [[ "${1:-}" == "--executive-demo" ]]; then
23+
IODEPTH=16
24+
IODEPTH_MID=16
25+
echo "[EXEC] Executive demo mode: QD sweep limited to 1, 16"
26+
fi
1927

2028
# Deduplicated QD list (avoids running QD=16 twice in executive-demo mode)
2129
_QD_LIST=(1)
2230
[[ "$IODEPTH_MID" -ne 1 ]] && _QD_LIST+=("$IODEPTH_MID")
2331
[[ "$IODEPTH" -ne "$IODEPTH_MID" && "$IODEPTH" -ne 1 ]] && _QD_LIST+=("$IODEPTH")
2432

33+
echo "[DEBUG] IODEPTH=$IODEPTH, IODEPTH_MID=$IODEPTH_MID, QD_LIST=${_QD_LIST[*]}"
34+
2535
# ---------------------------------------------------------------------------
2636
# Cloud provider detection (DMI-based, no network dependency)
2737
# ---------------------------------------------------------------------------
@@ -464,6 +474,14 @@ for _qd in "${_QD_LIST[@]}"; do
464474
done
465475
sudo umount -l "$X" >> "$BASE_LOG" 2>&1
466476

477+
# Check if we should stop after Stage 1
478+
echo "[DEBUG] MAX_STAGE=$MAX_STAGE, checking if <= 1"
479+
if [ "$MAX_STAGE" -le 1 ]; then
480+
echo "[DEMO] Stopping after Stage 1 as requested (DEMO_MAX_STAGE=$MAX_STAGE)"
481+
echo "[DEMO] Stage 1 kernel baseline complete - exiting before Stage 2"
482+
exit 0
483+
fi
484+
467485
echo "[Stage 2] User-space bridge fio (strict readiness probe)"
468486
# The FUSE bridge uses pread/pwrite against the raw block device directly;
469487
# hugepages are only needed for Stage 3 (SPDK). Allocate them here only

‎prompts/SPDK on Azure Cobalt vs. AWS Graviton.md‎

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
SPDK (Storage Performance Development Kit) support on ARM-based cloud instances has matured significantly in 2026, though the implementation strategy differs fundamentally between AWS and Azure due to their respective hypervisor architectures.
2+
Here is a summary comparing SPDK support on Azure Cobalt 100 (Neoverse-N2) and AWS Graviton (Neoverse-V2/V3).
3+
1. AWS Graviton (The "Native" Path)
4+
AWS Graviton instances (Graviton 3, 3E, and 4) provide the most straightforward SPDK experience because the AWS Nitro System is designed to support standard Linux hardware passthrough.
5+
Driver Model: Uses standard VFIO-PCI. Because Nitro exposes a vIOMMU (Virtual IOMMU) to the guest, you can "unplug" NVMe devices from the kernel and bind them directly to SPDK without specialized cloud drivers.
6+
Hardware Interaction: SPDK communicates directly with the Nitro card's NVMe controller. This is a "True PCIe Bypass" architecture.
7+
Performance Tuning: * The 3-Queue Rule: Unlike physical SSDs, Nitro NVMe typically requires 2–3 Queue Pairs (QP) per device to reach full hardware saturation.
8+
ISA-L: SPDK’s dependency on ISA-L (Intelligent Storage Acceleration Library) is fully optimized for Graviton's ARM64/Neon instructions, enabling high-speed CRC and encryption.
9+
Best For: Low-latency, high-throughput storage applications that require a standard, upstream SPDK environment.
10+
2. Azure Cobalt 100 (The "Mediated" Path)
11+
Azure Cobalt 100 (v6 series) takes a more specialized approach through Azure Boost, which offloads storage to dedicated FPGAs but imposes stricter limits on guest-side hardware access.
12+
Driver Model: Uses the NetVSC PMD (Poll Mode Driver) or UIO. Standard VFIO is typically not supported because the Cobalt 100 v6 hypervisor does not currently expose IOMMU groups to the guest.
13+
Hardware Interaction: This is a "Mediated" path. You use a hybrid driver where the control plane stays in the kernel (via VMBus), but the data plane is handled in user-space by the NetVSC PMD.
14+
Requirements:
15+
Kernel 6.2+: Required for MANA (Microsoft Azure Network Adapter) and Azure Boost storage compatibility.
16+
DPDK/SPDK Integration: You must build SPDK with specific flags to support the MANA hardware and the NetVSC interface.
17+
Best For: Applications that need to operate within the Azure ecosystem's "Transparent VF" model, providing high performance while maintaining cloud-management features like live migration.
18+
At a Glance Comparison
19+
Feature
20+
AWS Graviton (Nitro)
21+
Azure Cobalt 100 (v6)
22+
Bypass Method
23+
True PCIe Bypass (VFIO)
24+
Mediated User-space (NetVSC)
25+
Guest IOMMU
26+
Available
27+
Not Available (currently)
28+
Core Architecture
29+
Neoverse-V series
30+
Neoverse-N series
31+
SPDK Setup
32+
Standard setup.sh
33+
Custom Build (MANA + NetVSC)
34+
Storage Target
35+
Nitro NVMe / EBS
36+
Azure Boost SSD / Remote Disk
37+
Summary Recommendation
38+
If your goal is to run a vanilla SPDK application with minimal modification, AWS Graviton is the easier platform to target. If you are building for Azure Cobalt 100, you should focus on the NetVSC-mediated architecture, which requires a more modern kernel (6.2+) and a tighter integration with Microsoft's MANA driver stack.

prompts/LeadControlPlaneUXEngineer.md renamed to prompts/lead_control_plane_ux_engineer1.md

File renamed without changes.

‎prompts/lead_control_plane_ux_engineer2.md‎

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
You are the Lead Control Plane UX Engineer for our Agentic AI infrastructure. We need to update our local Python wrapper (`vibe_demo_agent.py`) to support a multi-cloud demonstration, transitioning from Azure Cobalt 100 to AWS Graviton3.
2+
3+
Please implement the following refactoring and new features:
4+
5+
1. **Parameter Processing:**
6+
- Update `argparse` to accept two distinct arguments: `--azure-host` and `--aws-host`.
7+
- Ensure the script fails gracefully if these are not provided.
8+
9+
2. **The Interactive Multi-Cloud Pivot:**
10+
- After the Azure SSH subprocess and final TTS voiceover complete, pause the script and print the following prompt in Cyan (`\033[36m`):
11+
`>> Demo Agent: 'Would you like to verify the zero-copy data plane portability on AWS Graviton3 (Neoverse-V1)? (y/n): '`
12+
- Read the user's input. If the user types anything other than 'y' or 'yes', exit the script gracefully.
13+
14+
3. **The AWS Graviton3 "No-Fluff" Execution:**
15+
- If the user selects 'y', immediately clear the terminal and reprint our "SiliconLanguage" `λ` ASCII logo.
16+
- Do NOT use any TTS voiceovers or artificial typing delays for this stage. It must be brutally fast to contrast with the earlier explanation.
17+
- Use `subprocess.Popen` to execute the SSH command to the AWS host:
18+
`ssh ec2-user@<aws_host_value> '/home/ec2-user/project/launch_arm_neoverse_demo_deterministic.sh --executive-demo'`
19+
- Stream the `stdout` directly to the terminal, preserving all ANSI colors.
20+
21+
4. **The `#OpenToWork` Closer:**
22+
- Once the AWS subprocess completes, print the following final sign-off in Magenta (`\033[35m`) and Cyan (`\033[36m`):
23+
24+
===========================================================================
25+
[SYSTEM] Multi-Cloud Bare-Metal Portability Confirmed.
26+
[STATUS] Azure Cobalt 100 (N2) & AWS Graviton3 (V1) fully saturated.
27+
28+
>> Ping is currently exploring Principal Architect / Director opportunities.
29+
>> #OpenToWork | #AgenticAI | #HardwareSoftwareCoDesign
30+
===========================================================================
31+
32+
CRITICAL: Keep all changes strictly within the Python UI logic. Do not modify any underlying C++ or bash scripts. Ensure the interactive input `input()` call does not block or break the terminal's ANSI state.

0 commit comments

Comments
 (0)