SmartNIC/DPU

Linux SmartNIC/DPU 하드웨어 가속 — DPU 아키텍처, devlink, Representor, OVS TC Offload, auxiliary_bus, IPsec/TLS 오프로드, 스토리지 오프로드 종합 가이드. 커널 내부 데이터 경로, 핵심 자료구조/API, 운영 환경 튜닝 포인트와 장애 디버깅 절차까지 실무 관점으로 다룹니다.

SmartNIC / DPU 기반 네트워크 가속

DPU(Data Processing Unit)는 단순 NIC를 넘어 자체 프로세서(ARM SoC), 메모리, 스토리지 인터페이스, 하드웨어 가속기를 탑재한 독립적인 컴퓨팅 플랫폼입니다. 데이터센터의 네트워킹, 보안, 스토리지 처리를 호스트 CPU에서 DPU로 오프로드하여 인프라 오버헤드를 제거하고, 호스트 CPU를 애플리케이션 워크로드에 전용할 수 있습니다.

NIC vs SmartNIC vs DPU 비교

DPU 하드웨어 아키텍처

DPU의 핵심 특징은 완전한 Linux 커널을 자체 ARM SoC에서 구동한다는 점입니다. 호스트와 독립적인 OS를 실행하면서 네트워크, 스토리지, 보안 서비스를 제공하고, 호스트에는 SR-IOV VF나 Virtio 디바이스만 노출합니다. 이로써 호스트 OS가 침해되더라도 인프라 서비스(방화벽, 암호화, 스토리지 가상화)의 무결성이 유지됩니다.

주요 DPU/IPU 제품군

DPU 오프로드 기능 상세

커널의 DPU 지원 서브시스템

리눅스 커널은 DPU를 지원하기 위해 여러 서브시스템을 활용합니다. 핵심은 devlink(디바이스 구성), switchdev(eSwitch 제어), representor port(VF/SF를 호스트에서 관리), auxiliary bus(다기능 디바이스 분할)입니다.

devlink: DPU 구성 및 관리

devlink은 DPU/SmartNIC를 관리하는 핵심 커널 인터페이스입니다. eSwitch 모드 전환, 포트 기능 설정, 리소스 할당, 펌웨어 관리, 헬스 리포터 등을 통합적으로 제어합니다.

# ━━━ devlink 기본 관리 ━━━

# DPU 디바이스 목록 조회
devlink dev show
# pci/0000:03:00.0: fw.mgmt 24.39.1002 fw.app 24.39.1002

# 펌웨어 버전 상세 조회
devlink dev info pci/0000:03:00.0
# driver: mlx5_core
# fw.mgmt: 24.39.1002
# fw.undi: 14.32.17
# fw.psid: MT_0000000835

# ━━━ eSwitch 모드 전환 ━━━

# legacy 모드 → switchdev 모드 (eSwitch 활성화)
# ⚠️ 모드 전환 시 네트워크 순간 단절 발생
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# eSwitch 인라인 모드 설정 (매칭 깊이)
devlink dev eswitch set pci/0000:03:00.0 inline-mode transport

# 현재 eSwitch 모드 확인
devlink dev eswitch show pci/0000:03:00.0
# mode switchdev inline-mode transport encap-mode basic

# ━━━ SR-IOV VF 관리 ━━━

# VF 생성 (PCIe SR-IOV)
echo 8 > /sys/class/net/enp3s0f0np0/device/sriov_numvfs

# VF의 MAC, VLAN, 대역폭 설정
ip link set enp3s0f0np0 vf 0 mac 00:11:22:33:44:55
ip link set enp3s0f0np0 vf 0 vlan 100
ip link set enp3s0f0np0 vf 0 max_tx_rate 10000  # Mbps

# VF representor 포트 확인 (switchdev 모드에서 자동 생성)
ip link show | grep "enp3s0f0np0_"
# enp3s0f0np0_0  ← VF0 representor
# enp3s0f0np0_1  ← VF1 representor

# ━━━ Scalable Functions (SF) ━━━

# SF 생성 (SR-IOV VF의 경량 대안, BlueField/ConnectX-7+)
devlink port add pci/0000:03:00.0 flavour pcisf pfnum 0 sfnum 88
devlink port function set pci/0000:03:00.0/32768 hw_addr 00:00:00:00:88:88 state active

# SF 포트 기능 설정
devlink port function set pci/0000:03:00.0/32768 \
    roce true \
    migratable true \
    ipsec_crypto true \
    ipsec_packet true

# SF의 auxiliary 디바이스 활성화
devlink port function set pci/0000:03:00.0/32768 state active

# 생성된 SF 확인
devlink port show pci/0000:03:00.0/32768
# pci/0000:03:00.0/32768: type eth netdev en3f0pf0sf88 flavour pcisf
#   controller 0 pfnum 0 sfnum 88 splittable false
#   function: hw_addr 00:00:00:00:88:88 state active opstate attached

Representor Port 아키텍처

Representor port는 switchdev 모드에서 DPU가 호스트 측에 노출하는 가상 netdev입니다. 각 VF/SF에 대응하는 representor가 생성되어, 호스트에서 TC flower 규칙을 통해 VF/SF 트래픽을 제어할 수 있습니다. 이는 OVS offload의 핵심 메커니즘입니다.

/* drivers/net/ethernet/mellanox/mlx5/core/eswitch.h */
struct mlx5_eswitch_rep {
    struct mlx5_eswitch *esw;
    u16 vport;                      /* 연결된 VF/SF의 vport 번호 */
    u16 vlan;                       /* 기본 VLAN */
    struct net_device *netdev;       /* representor netdev */
    struct mlx5_flow_handle *send_to_vport_rule;
    struct mlx5e_rep_priv *rep_data;
};

/* Representor의 역할:
 * 1. VF/SF로 향하는 slow-path 패킷의 수신/송신 경로
 * 2. TC flower 규칙의 연결점 (representor에 규칙 설치 → eSwitch HW로 오프로드)
 * 3. OVS 브릿지의 포트로 연결 (ovs-vsctl add-port br0 enp3s0f0np0_0)
 * 4. conntrack offload의 앵커 포인트
 */

/* drivers/net/ethernet/mellanox/mlx5/core/en_rep.c */
static const struct net_device_ops mlx5e_netdev_ops_rep = {
    .ndo_open         = mlx5e_rep_open,
    .ndo_stop         = mlx5e_rep_close,
    .ndo_start_xmit   = mlx5e_xmit,           /* slow-path 송신 */
    .ndo_setup_tc     = mlx5e_rep_setup_tc,   /* TC flower 오프로드 진입점 */
    .ndo_get_stats64  = mlx5e_rep_get_stats,  /* HW 카운터 기반 통계 */
};

OVS TC Flower Offload 동작 원리

Open vSwitch(OVS)는 가상 스위칭의 표준이지만, 소프트웨어 처리로 인해 CPU 오버헤드가 큽니다. DPU의 eSwitch를 활용하면 OVS 플로우를 하드웨어로 오프로드하여 호스트 CPU 사용을 90% 이상 줄일 수 있습니다.

# ━━━ OVS-DPDK + TC Flower HW Offload 설정 ━━━

# 1. eSwitch를 switchdev 모드로 전환
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 2. OVS에서 하드웨어 오프로드 활성화
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_sw

# 3. OVS 브릿지에 PF와 VF representor 연결
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int enp3s0f0np0       # PF (uplink)
ovs-vsctl add-port br-int enp3s0f0np0_0     # VF0 representor
ovs-vsctl add-port br-int enp3s0f0np0_1     # VF1 representor

# 4. 오프로드 동작 흐름:
#   a) 첫 패킷: eSwitch → representor → OVS userspace → flow 결정
#   b) OVS가 TC flower 규칙을 representor에 설치
#   c) 드라이버가 TC flower → eSwitch HW 규칙으로 변환
#   d) 이후 패킷: eSwitch HW에서 직접 포워딩 (CPU 바이패스)

# 오프로드된 플로우 확인
tc -s filter show dev enp3s0f0np0_0 ingress
# filter protocol ip pref 2 flower chain 0
#   eth_type ipv4
#   src_ip 10.0.0.5
#   dst_ip 10.0.0.10
#   in_hw in_hw_count 1    ← HW 오프로드 확인
#     action order 1: mirred (Egress Redirect to device enp3s0f0np0_1)
#     hw_stats immediate

# OVS 오프로드 통계 확인
ovs-appctl dpctl/dump-flows type=offloaded
# recirc_id(0),in_port(2),eth(...),ipv4(src=10.0.0.5,dst=10.0.0.10,...)
# packets:1523400, bytes:97497600, used:0.001s, flags:SFPR

auxiliary_bus: DPU 다기능 디바이스 분할

auxiliary_bus는 하나의 PCIe 디바이스가 여러 기능(네트워크, RDMA, crypto, vDPA 등)을 독립적인 커널 드라이버에 분배하기 위한 메커니즘입니다. DPU처럼 다기능 디바이스에서 핵심적인 역할을 합니다.

/* include/linux/auxiliary_bus.h */
struct auxiliary_device {
    struct device dev;
    const char *name;   /* "mlx5_core.eth.0", "mlx5_core.rdma.0" 등 */
    u32 id;
};

struct auxiliary_driver {
    int (*probe)(struct auxiliary_device *adev,
                const struct auxiliary_device_id *id);
    void (*remove)(struct auxiliary_device *adev);
    const char *name;
    struct device_driver driver;
    const struct auxiliary_device_id *id_table;
};

/* mlx5 DPU에서 auxiliary_bus 활용 예시:
 *
 * mlx5_core (PCI 드라이버)
 *   ├── mlx5_core.eth.0     → mlx5e (이더넷 netdev)
 *   ├── mlx5_core.rdma.0    → mlx5_ib (RDMA/RoCE)
 *   ├── mlx5_core.vnet.0    → mlx5_vnet (vDPA - virtio 에뮬레이션)
 *   ├── mlx5_core.sf.88     → Scalable Function #88
 *   └── mlx5_core.crypto.0  → Crypto offload
 *
 * 각 기능이 독립 드라이버로 동작하며, 개별 로드/언로드 가능
 */

/* Scalable Function 등록 (drivers/net/ethernet/mellanox/mlx5/core/sf/) */
static int mlx5_sf_dev_probe(struct auxiliary_device *adev,
                             const struct auxiliary_device_id *id)
{
    struct mlx5_sf_dev *sf_dev = container_of(adev, struct mlx5_sf_dev, adev);
    struct mlx5_core_dev *mdev;

    mdev = mlx5_sf_dev_to_mdev(sf_dev);
    /* SF용 mlx5_core_dev 초기화 → 독립 netdev + RDMA + crypto 생성 */
    return mlx5_init_one(mdev);
}

IPsec / TLS 인라인 암호화 오프로드

DPU는 IPsec ESP와 TLS(kTLS)의 암호화/복호화를 하드웨어에서 수행하여 라인 레이트 암호화를 제공합니다. 커널의 xfrm_dev_offload 인터페이스를 통해 SA를 NIC에 직접 설치합니다.

/* include/net/xfrm.h — 하드웨어 오프로드 구조체 */
struct xfrm_dev_offload {
    struct net_device *dev;
    struct net_device *real_dev;  /* bond/vlan의 실제 HW 디바이스 */
    unsigned long offload_handle; /* 드라이버의 HW 오브젝트 핸들 */
    u8 dir : 2;                  /* XFRM_DEV_OFFLOAD_IN/OUT */
    u8 type : 2;                 /* CRYPTO (암호만) / PACKET (전체) */
    u8 flags : 2;
};

/* IPsec 오프로드 타입:
 * XFRM_DEV_OFFLOAD_CRYPTO — 암호화/복호화만 HW, 헤더 처리는 SW
 *   → ESP trailer/header는 커널이 추가, 암호 연산만 NIC 가속
 *   → 대부분의 NIC에서 지원 (ConnectX-6+, E810)
 *
 * XFRM_DEV_OFFLOAD_PACKET — 전체 IPsec 처리를 HW에서 수행
 *   → ESP 헤더 추가, SPI 매칭, anti-replay, 암호화 모두 NIC
 *   → 호스트 CPU 관여 0%. 최대 성능
 *   → BlueField-2/3에서 지원 (full offload)
 */

/* mlx5 드라이버의 IPsec offload 등록 */
/* drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c */
static const struct xfrmdev_ops mlx5e_ipsec_xfrmdev_ops = {
    .xdo_dev_state_add    = mlx5e_xfrm_add_state,    /* SA를 HW에 설치 */
    .xdo_dev_state_delete = mlx5e_xfrm_del_state,    /* HW SA 삭제 */
    .xdo_dev_state_free   = mlx5e_xfrm_free_state,   /* 리소스 해제 */
    .xdo_dev_offload_ok   = mlx5e_ipsec_offload_ok,  /* 오프로드 가능 여부 확인 */
    .xdo_dev_policy_add   = mlx5e_xfrm_add_policy,   /* SP를 HW에 설치 */
    .xdo_dev_policy_delete= mlx5e_xfrm_del_policy,
};

# ━━━ IPsec HW Offload 설정 예시 ━━━

# 1. 디바이스의 IPsec offload 지원 확인
ethtool -k enp3s0f0np0 | grep esp
# esp-hw-offload: on
# esp-tx-csum-hw-offload: on

# 2. IPsec SA 추가 시 offload 지정
ip xfrm state add \
    src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x1000 mode transport \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload dev enp3s0f0np0 dir out   # ← HW offload 지정

ip xfrm state add \
    src 10.0.0.2 dst 10.0.0.1 \
    proto esp spi 0x2000 mode transport \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload dev enp3s0f0np0 dir in

# 3. packet offload (full offload — BlueField-2/3)
ip xfrm state add \
    src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x3000 mode tunnel \
    aead "rfc4106(gcm(aes))" 0x$(openssl rand -hex 20) 128 \
    offload packet dev enp3s0f0np0 dir out  # ← packet 전체 오프로드

# 4. HW offload 상태 확인
ip xfrm state list
# ... offload type packet dev enp3s0f0np0 dir out ...

# 5. kTLS offload (TLS 1.3)
ethtool -k enp3s0f0np0 | grep tls
# tls-hw-tx-offload: on
# tls-hw-rx-offload: on
# tls-hw-record: on

# nginx에서 kTLS + HW offload 활용 (커널 5.2+)
# setsockopt(fd, SOL_TLS, TLS_TX, ...) → 커널이 자동 HW 오프로드

DPU 스토리지 오프로드

DPU는 네트워크뿐만 아니라 스토리지 가상화도 오프로드합니다. NVMe-oF(NVMe over Fabrics) 타겟을 DPU에서 실행하거나, virtio-blk 백엔드를 DPU의 ARM에서 처리하여 호스트 CPU를 완전히 해방시킵니다.

# ━━━ NVMe-oF SNAP (BlueField DPU) ━━━

# DPU ARM 측에서 NVMe-oF SNAP 컨트롤러 생성
# → 호스트에 가상 NVMe 디바이스가 나타남

# 1. SNAP 서비스 시작 (DPU ARM에서)
snap_rpc.py controller_nvme_create \
    --pf_id 0 \
    --nqn nqn.2022-01.com.nvidia:subsys1

# 2. 원격 NVMe-oF 타겟 연결
snap_rpc.py subsystem_nvme_create \
    --nqn nqn.2022-01.com.nvidia:subsys1 \
    --trtype rdma \
    --traddr 192.168.100.10 \
    --trsvcid 4420

# 호스트에서 확인 (별도 드라이버 불필요)
nvme list
# /dev/nvme0n1  SNAP Virtual NVMe  1.95 TB

# ━━━ vDPA (virtio DataPath Acceleration) ━━━

# DPU에서 vDPA 디바이스 생성 → VM에 virtio-net HW 가속 제공
# 호스트 커널의 vDPA bus + vhost-vdpa로 QEMU에 연결

# 1. vDPA management 디바이스 확인
vdpa mgmtdev show
# auxiliary/mlx5_core.sf.4:
#   supported_classes net

# 2. vDPA 디바이스 생성
vdpa dev add name vdpa0 mgmtdev auxiliary/mlx5_core.sf.4 \
    mac 00:11:22:33:44:55 max_vqp 8

# 3. QEMU에서 vhost-vdpa 디바이스로 VM에 연결
# -netdev vhost-vdpa,vhostdev=/dev/vhost-vdpa-0,id=vdpa0
# -device virtio-net-pci,netdev=vdpa0

DPU 보안 아키텍처

DPU의 가장 중요한 가치 중 하나는 인프라 보안의 격리입니다. 호스트 OS와 독립된 신뢰 도메인에서 보안 서비스를 실행하여, 호스트가 침해되더라도 인프라 무결성을 유지합니다.

# ━━━ BlueField DPU 보안 모드 설정 ━━━

# DPU 동작 모드 확인 (mlxconfig)
mlxconfig -d /dev/mst/mt41692_pciconf0 query | grep -i "internal_cpu"
# INTERNAL_CPU_MODEL = EMBEDDED_CPU(1)

# 호스트 권한 모드 설정
# Privileged:    호스트가 DPU PF를 직접 제어 (개발/테스트용)
# Restricted:    DPU ARM이 모든 제어권 보유, 호스트는 VF만 사용
# Restricted+:   호스트가 DPU 리셋/재부팅도 불가
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_PAGE_SUPPLIER=ECPF
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_ESWITCH_MANAGER=ECPF
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_OFFLOAD_ENGINE=ENABLED

# ━━━ DPU 기반 격리된 방화벽 ━━━

# DPU ARM에서 nftables 방화벽 실행 (호스트 독립)
# → eSwitch를 통과하는 모든 호스트 트래픽에 적용
# → 호스트 root 권한으로도 우회 불가
nft add table inet host_fw
nft add chain inet host_fw input { type filter hook ingress device enp3s0f0np0 priority 0 \; }
nft add rule inet host_fw input ip saddr != 10.0.0.0/8 drop

# DPU의 독립 로깅 (syslog → 중앙 서버)
# 호스트 침해 시에도 DPU 로그는 보존

DPU 프로그래밍 모델

/* P4 프로그래밍 예시 — DPU의 프로그래머블 파이프라인에서 실행
 * Intel IPU (IPDK) 또는 AMD Pensando에서 P4 컴파일러로 HW 테이블 생성
 */

/* 커스텀 헤더 파싱 및 매칭 */
header custom_header_t {
    bit<16> type_id;
    bit<32> tenant_id;
    bit<16> service_tag;
}

parser CustomParser(packet_in pkt, out headers_t hdr) {
    state start {
        pkt.extract(hdr.ethernet);
        transition select(hdr.ethernet.etherType) {
            0x8100: parse_vlan;
            0x0800: parse_ipv4;
            0xFE01: parse_custom;  /* 커스텀 프로토콜 */
            default: accept;
        }
    }
    state parse_custom {
        pkt.extract(hdr.custom);
        transition parse_ipv4;
    }
}

/* 매칭 테이블: tenant_id 기반 라우팅 */
table tenant_routing {
    key = {
        hdr.custom.tenant_id : exact;
        hdr.ipv4.dstAddr     : lpm;
    }
    actions = {
        forward_to_port;
        apply_encryption;
        drop;
    }
    size = 1048576;  /* 100만 엔트리 */
}

DPU 모니터링 및 디버깅

# ━━━ devlink 헬스 리포터 ━━━
# DPU 하드웨어 상태 모니터링

devlink health show pci/0000:03:00.0
# reporter fw_fatal:
#   state healthy error 0 recover 0
# reporter fw:
#   state healthy error 0 recover 0
# reporter vnic:
#   state healthy error 0 recover 0

# 헬스 리포터 상세 덤프
devlink health dump show pci/0000:03:00.0 reporter fw

# ━━━ eSwitch 플로우 카운터 ━━━
# HW 오프로드된 플로우의 패킷/바이트 통계

tc -s filter show dev enp3s0f0np0_0 ingress
# filter ... flower ...
#   Sent 98234567 bytes 1523400 pkt (hardware)
#   action ... mirred ... (hardware)
#     Sent 98234567 bytes 1523400 pkt

# ━━━ DPU 리소스 사용량 ━━━

# 사용 가능한 HW 리소스 조회
devlink resource show pci/0000:03:00.0
# name flow_table size 4194304 occ 152340
# name flow_counter size 16777216 occ 304680
# name encap_entries size 65536 occ 1024

# ━━━ ethtool 확장 통계 ━━━

ethtool -S enp3s0f0np0 | grep -E "offload|hw_"
# rx_vport_rdma_unicast_packets: 4523100
# tx_vport_rdma_unicast_packets: 3891200
# rx_hw_timestamp: 15234001

# ━━━ SF/VF 개별 통계 ━━━

# Scalable Function 상태 확인
devlink port function show pci/0000:03:00.0/32768
# function:
#   hw_addr 00:00:00:00:88:88 state active opstate attached
#   roce true migratable true ipsec_crypto true

# ━━━ 디버깅 팁 ━━━
# HW offload 문제 시: skip_hw → skip_sw 순서로 테스트
# 1단계: skip_hw로 SW 경로에서 규칙이 올바른지 확인
tc filter add dev rep0 ingress flower ... action ... skip_hw
# 2단계: skip_sw로 HW 전용으로 전환, in_hw 확인
tc filter add dev rep0 ingress flower ... action ... skip_sw

# 오프로드 실패 원인 확인 (커널 로그)
dmesg | grep -i "offload\|eswitch\|flower"
# mlx5_core: TC flower offload failed: -EOPNOTSUPP (지원 안 되는 액션)
# mlx5_core: flow table full, falling back to software