네. 가능합니다. 오히려 지금 말씀하신 구조라면 private network가 구축되기 전에 RDMA 사전 검증을 해보는 것이 꽤 좋은 방법입니다.

다만 핵심은 “L3 routing이 가능하냐”가 아니라, RoCEv2가 그 L3 구간을 통과하도록 구성되어 있고 중간 스위치/라우터가 RDMA QoS를 제대로 보장하느냐입니다.

결론부터

현재 구조가 예를 들어:

GPU Node
  CX-6
  10.10.10.10/24
       |
       |  Ethernet
       v
   [Switch]
       |
       | L3 Routing
       v
   [Router/L3 Switch]
       |
       v
   [Storage Switch]
       |
       v
AIStor Storage Node
E810
10.20.20.10/24

이라면 RoCEv2 RDMA 자체는 L3 routed 환경에서도 테스트할 수 있습니다.

RoCEv2는 IP/UDP 기반이므로 L3 routing이 가능합니다. 실제로 AIStor의 최신 RDMA 문서도 RoCEv2에서 DSCP를 사용해 L3 hop을 거쳐도 priority가 유지되도록 구성하는 방식을 설명하고 있습니다. (MinIO AIStor Documentation)

다만 여기서 중요한 차이가 있습니다.

---

1. ib_write_bw 테스트는 충분히 해볼 수 있음

예를 들어:

GPU Node
CX-6
  |
  | 10.10.10.0/24
  |
Switch
  |
  | L3
  |
Switch/Router
  |
  | 10.20.20.0/24
  |
Storage Node
E810

이라면 GPU Node에서:

ibv_devinfo
rdma link show
ibv_devices

로 CX-6 RDMA device가 정상인지 확인하고,

Storage Node에서도 E810 RDMA device가 정상인지 확인한 뒤,

# Storage
ib_write_bw -d <rdma_device> -x <gid_index>

# GPU node
ib_write_bw -d <rdma_device> -x <gid_index> <storage_ip>

형태로 GPU Node ↔ Storage Node RDMA bandwidth test를 시도할 수 있습니다.

AIStor 문서에서도 ib_write_bw를 이용한 point-to-point RDMA 검증을 기본적인 fabric 테스트로 제시하고 있습니다. (MinIO AIStor Documentation)

---

2. 그런데 한 가지가 굉장히 중요합니다

질문하신

L3 routing이지만 스위치에서 지원한다면

여기서 "지원한다"의 의미를 정확히 확인해야 합니다.

단순히

IP routing 가능

한 것만으로는 부족합니다.

RoCEv2에서는 다음이 중요합니다.

        GPU Node                         Storage Node
       ConnectX-6                           E810
          |                                   |
          | RoCEv2                            |
          v                                   v
       Switch ─── L3 ─── Router ─── L3 ─── Switch
                 │
                 │
          DSCP / QoS
          ECN
          PFC
          Buffer

특히 PFC/ECN/DSCP가 L3 구간에서도 의도대로 동작하는지가 중요합니다.

AIStor는 RoCE fabric에서 inter-node RDMA를 사용할 경우 end-to-end lossless fabric을 요구하고, PFC와 ECN/DCQCN을 사용하도록 설명하고 있습니다. (MinIO AIStor Documentation)

---

3. 오히려 지금 테스트하면 좋은 이유

현재 상황에서는 저는 다음 순서로 테스트하는 것을 추천합니다.

Phase A — 지금 바로

GPU Node CX-6
       │
       │ external network
       │
       ▼
Storage Node E810

여기서:

① RDMA device 확인

GPU:

rdma link
ibv_devices
ibv_devinfo

Storage:

rdma link
ibv_devices
ibv_devinfo

---

② GID 확인

show_gids

또는 환경에 따라:

ibv_devinfo -v

여기서 RoCE v2 GID를 찾아야 합니다.

---

③ 기본 RDMA bandwidth

ib_write_bw

→ point-to-point

그 다음:

ib_read_bw
ib_send_bw
ib_write_lat
ib_read_lat

까지.

---

④ 여러 message size

예를 들어:

2KB
4KB
8KB
16KB
64KB
256KB
1MB
4MB
16MB
64MB

로 측정합니다.

그리고 CX-6가 예를 들어 200GbE라면 단순히:

200Gbps가 나왔다.

만 보는 것이 아니라

Bandwidth
Latency
CPU utilization
PFC pause
ECN
packet drop
retry

를 같이 봐야 합니다.

---

4. 단, E810 ↔ CX-6 조합은 조금 주의

여기가 이번 테스트에서 상당히 중요합니다.

GPU Node:

B300
  |
ConnectX-6

Storage:

AIStor
  |
Intel E810

이라면 RDMA 자체는 양쪽 NIC가 RDMA/RoCE를 지원하면 가능합니다.

하지만 GPUDirect RDMA는 이야기가 달라집니다.

NVIDIA Network Operator의 GPUDirect RDMA 지원은 NVIDIA ConnectX/BlueField 계열 NIC를 대상으로 합니다. (NVIDIA Docs)

따라서:

B300
  │
  │ GPUDirect RDMA
  ▼
ConnectX-6
  │
  │ RoCEv2
  ▼
E810
  │
  ▼
AIStor

여기서 GPU → CX-6 구간의 GPU Direct는 가능성을 검증할 수 있지만,

CX-6 → E810 → AIStor

구간은 일반적인 RoCE RDMA 경로입니다.

즉 이 테스트는 두 가지를 분리해서 보는 게 좋습니다.

---

5. 지금 할 수 있는 테스트를 3단계로 나누면

제가 지금 상황이라면 이렇게 하겠습니다.

Test 1 — RDMA fabric

GPU Node CX-6
      │
      │ L3 routed RoCEv2
      ▼
Storage E810

테스트:

ib_write_bw
ib_read_bw
ib_send_bw
ib_write_lat

목적

"현재 external network의 L3 경로에서 RoCEv2 자체가 통과하는가?"

---

Test 2 — GPU Direct RDMA

GPU Node 내부에서:

B300
 │
 │ PCIe P2P
 ▼
CX-6

을 검증합니다.

확인:

nvidia-smi topo -m
lspci -tv

그리고 GPU memory를 RDMA buffer로 사용하는 테스트를 합니다.

여기서는 PCIe ACS, GPU-NIC topology, GPU driver, CUDA, RDMA driver가 중요합니다. AIStor도 GPU-Direct RDMA에서 GPU-to-NIC PCIe peer-to-peer DMA를 요구하고 있습니다. (MinIO AIStor Documentation)

---

Test 3 — AIStor S3 over RDMA

최종적으로:

B300
 │
 │ GPUDirect
 ▼
CX-6
 │
 │ RoCEv2 / L3
 ▼
E810
 │
 ▼
AIStor

까지 가는 겁니다.

AIStor의 S3 over RDMA는 GetObject, PutObject, UploadPart 같은 payload operation에 RDMA path를 사용할 수 있고, GPU memory를 대상으로 하려면 GPU-to-NIC peer-to-peer DMA가 추가로 필요합니다. (MinIO AIStor Documentation)

---

6. 그리고 이 테스트의 가장 큰 가치

이렇게 하면 private network가 완성되기 전에 상당 부분을 선행 검증할 수 있습니다.

제가 보면 지금 상황에서 아래처럼 바꾸는 게 좋습니다.

기존 계획

① HW
 ↓
② GPU Driver/Burn
 ↓
③ Private Network 구축
 ↓
④ RDMA
 ↓
⑤ vLLM
 ↓
⑥ AIStor

보다는:

① HW / BIOS / Firmware
        ↓
② GPU Driver / CUDA / NCCL / Burn-in
        ↓
③ CX-6 / E810 RDMA stack
        ↓
④ CX-6 ↔ E810
   L3 Routed RoCEv2
   ib_write_bw / ib_read_bw
        ↓
⑤ GPU ↔ CX-6
   GPUDirect RDMA
        ↓
⑥ vLLM
        ↓
⑦ Compute ↔ GPU
        ↓
⑧ Private Network 구축
        ↓
⑨ Private RoCE Fabric
   PFC / ECN / DSCP / MTU
        ↓
⑩ AIStor S3 over RDMA
        ↓
⑪ GPU → CX-6 → RoCE → AIStor
        ↓
⑫ E2E

이게 훨씬 효율적입니다.

특히 지금 external network가 이미 GPU Node ↔ Storage Node 간 L3 routing이 가능하고, 스위치가 RoCE QoS/ECN/PFC를 지원한다면, private network를 기다릴 이유가 없습니다.

다만 현재 external network에서 RDMA가 성공했다고 해서 private network의 RDMA fabric까지 PASS라고 판정하면 안 됩니다. Private network에서는 새로운 switch, VLAN/VRF, MTU, DSCP, PFC, ECN, buffer 설정이 들어가기 때문입니다. AIStor도 lossless RoCE에서는 경로상의 모든 스위치/호스트에서 일관된 QoS 구성이 필요하다고 명시합니다. (MinIO AIStor Documentation)

특히 제가 지금 확인하고 싶은 건 4개입니다.

1. GPU Node CX-6가 몇 Gbps 포트인지
2. Storage Node E810이 몇 Gbps 포트인지
3. 중간 L3 Switch/Router 모델
4. 그 장비가 RoCEv2 + PFC + ECN + DSCP QoS를 L3 routed 환경에서 지원하는지

이 4개만 알면, 지금 external network를 이용해서 바로 할 수 있는 RDMA 사전검증 절차를 GPU node ↔ Storage node 기준으로 명령어까지 포함해서 Test Case/Pass-Fail 표 형태로 만들어 드릴 수 있습니다.