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

eSwitch 내부 패킷 흐름 심화

DPU의 eSwitch는 단순한 L2 스위치가 아니라 프로그래머블 패킷 파이프라인입니다. 패킷이 eSwitch에 도착하면 flow steering 파이프라인을 거쳐 fast path(HW 오프로드) 또는 slow path(소프트웨어 폴백)로 분기됩니다. 이 구조를 이해해야 오프로드 실패 원인을 진단할 수 있습니다.

/* drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
 *
 * eSwitch FDB(Forwarding DataBase) 플로우 테이블 생성
 * Level 0~3의 계층적 파이프라인을 하드웨어에 설정
 */

static int esw_create_offloads_fdb_tables(struct mlx5_eswitch *esw)
{
    struct mlx5_flow_namespace *root_ns;
    struct mlx5_flow_table *fdb;
    int err;

    root_ns = mlx5_get_fdb_sub_ns(esw->dev, 0);

    /* Level 0: TC flower fast path — 사용자 규칙이 설치되는 테이블
     * tc filter add dev rep0 ingress flower ... skip_sw
     * 위 명령의 규칙이 여기에 HW 오프로드됨
     */
    fdb = mlx5_create_auto_grouped_flow_table(root_ns,
            &ft_attr);  /* max_fte = 수백만, autogroup = true */
    esw->fdb_table.offloads.tc = fdb;

    /* Level 1: Slow FDB — TC miss 시 representor로 전달하는 기본 규칙
     * FDB에서 매칭되지 않은 패킷 → representor netdev → CPU
     */
    fdb = mlx5_create_flow_table(root_ns, &ft_attr_slow);
    esw->fdb_table.offloads.slow_fdb = fdb;

    /* miss 규칙: FDB에 없는 패킷을 representor로 전달 */
    err = esw_add_fdb_miss_rule(esw);

    return err;
}

/* eSwitch 패킷 수신 경로:
 *
 * [Wire/VF] → NIC RX → Flow Steering → FDB Lookup
 *                                          │
 *                        ┌─────────────────┴──────────────────┐
 *                        │ HIT                                │ MISS
 *                        ▼                                    ▼
 *                   HW Action 실행                     Slow FDB rule
 *                   (forward/modify/                   → representor
 *                    encap/decap/ct)                    → CPU netdev rx
 *                        │                                    │
 *                        ▼                                    ▼
 *                   [Egress Port]                     OVS/TC SW 처리
 *                   CPU 관여 없음                     → flow install
 *                                                     → 이후 HW offload
 */

/* TC flower 오프로드 콜백 — representor의 ndo_setup_tc에서 호출 */
static int mlx5e_rep_setup_tc(struct net_device *dev,
                             enum tc_setup_type type,
                             void *type_data)
{
    struct mlx5e_priv *priv = netdev_priv(dev);

    switch (type) {
    case TC_SETUP_CLSFLOWER:
        /* TC flower 규칙을 eSwitch FDB에 설치/삭제/조회 */
        return mlx5e_rep_setup_tc_cls_flower(priv, type_data);
    case TC_SETUP_CLSMATCHALL:
        return mlx5e_rep_setup_tc_cb(type_data);
    default:
        return -EOPNOTSUPP;
    }
}

TC Flower 오프로드 커널 내부 경로

TC flower 규칙이 사용자 공간에서 eSwitch 하드웨어까지 전달되는 전체 커널 호출 경로를 추적합니다. 이 경로를 이해하면 오프로드 실패 시 정확히 어느 단계에서 -EOPNOTSUPP가 반환되는지 파악할 수 있습니다.

/* net/sched/cls_flower.c — TC flower 규칙 파싱 및 콜백 */

static int fl_change(struct net *net, struct sk_buff *in_skb,
                    struct tcf_proto *tp, unsigned long base,
                    u32 handle, struct nlattr **tca,
                    void **arg, u32 flags,
                    struct netlink_ext_ack *extack)
{
    struct cls_fl_head *head = fl_head_dereference(tp);
    struct cls_fl_filter *fnew;
    int err;

    /* 1단계: Netlink 속성에서 flower 매칭 키 파싱 */
    err = fl_set_key(net, tca[TCA_OPTIONS], &fnew->key, &fnew->mask, extack);
    if (err)
        goto errout;

    /* 2단계: 액션(mirred, ct, nat, vlan 등) 파싱 */
    err = tcf_exts_validate(net, tp, tca, ...);

    /* 3단계: HW 오프로드 시도 (skip_sw인 경우 필수) */
    if (!(flags & TCA_FLAGS_SKIP_HW)) {
        err = fl_hw_replace_filter(tp, fnew, rtnl_held, extack);
        if (err && (flags & TCA_FLAGS_SKIP_SW))
            goto errout;  /* skip_sw + HW 실패 → 전체 실패 */
    }

    return 0;
}

/* fl_hw_replace_filter() → 드라이버의 ndo_setup_tc 호출 */
static int fl_hw_replace_filter(struct tcf_proto *tp,
                                struct cls_fl_filter *f, ...)
{
    struct tc_cls_flower_offload cls_flower = {};
    struct flow_rule *rule;

    /* flower 키 → flow_rule 변환 */
    cls_flower.rule = flow_rule_alloc(tcf_exts_num_actions(&f->exts));
    cls_flower.command = FLOW_CLS_REPLACE;

    /* 드라이버 콜백 호출:
     * net_device->netdev_ops->ndo_setup_tc(TC_SETUP_CLSFLOWER, &cls_flower)
     * → mlx5e_rep_setup_tc_cls_flower()
     */
    return tc_setup_cb_call(block, TC_SETUP_CLSFLOWER, &cls_flower, ...);
}

/* drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
 * mlx5 드라이버에서 flower 규칙을 eSwitch FDB로 변환
 */
static int mlx5e_tc_add_fdb_flow(struct mlx5e_priv *priv,
                                struct mlx5e_tc_flow *flow,
                                struct netlink_ext_ack *extack)
{
    struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
    struct mlx5_flow_attr *attr = flow->attr;
    int err;

    /* 1. 매칭 키 파싱: flower key → mlx5 match spec */
    err = parse_cls_flower(priv, flow, &parse_attr->spec, ...);
    if (err)
        return err;  /* HW 미지원 매칭 필드 → -EOPNOTSUPP */

    /* 2. 액션 파싱: flower action → mlx5 flow action */
    err = parse_tc_fdb_actions(priv, &rule->action, flow, extack);
    if (err)
        return err;  /* HW 미지원 액션 → -EOPNOTSUPP */

    /* 3. eSwitch FDB에 HW 규칙 설치 → FW 커맨드 전송 */
    flow->rule[0] = mlx5_eswitch_add_offloaded_rule(esw, &parse_attr->spec,
                                                      attr);

    return 0;
}

Conntrack HW Offload 심화

Conntrack(CT) offload는 stateful 방화벽의 연결 추적을 eSwitch 하드웨어에서 수행합니다. 소프트웨어 conntrack은 CPU 코어당 수십만 PPS가 한계이지만, HW CT offload는 수억 PPS를 처리하면서도 호스트 CPU를 전혀 사용하지 않습니다.

# ━━━ TC ct action으로 Stateful 방화벽 HW Offload ━━━

# Chain 0: Pre-CT — 모든 ingress 패킷을 conntrack으로 전달
tc filter add dev enp3s0f0np0_0 ingress prio 1 chain 0 \
    flower skip_sw \
    action ct zone 1 pipe \
    action goto chain 1

# Chain 1: Established 연결 허용 (fast path)
tc filter add dev enp3s0f0np0_0 ingress prio 1 chain 1 \
    flower skip_sw ct_state +est+trk \
    action mirred egress redirect dev enp3s0f0np0

# Chain 1: NEW + 허용 목적지만 commit하고 전달
tc filter add dev enp3s0f0np0_0 ingress prio 2 chain 1 \
    flower skip_sw ct_state +new+trk ip_proto tcp dst_port 80 \
    action ct commit zone 1 pipe \
    action mirred egress redirect dev enp3s0f0np0

# Chain 1: 그 외 NEW → drop (방화벽 정책)
tc filter add dev enp3s0f0np0_0 ingress prio 3 chain 1 \
    flower skip_sw ct_state +new+trk \
    action drop

# ━━━ CT + NAT HW Offload ━━━

# SNAT: 내부 → 외부 (소스 IP 변환)
tc filter add dev enp3s0f0np0_0 ingress prio 1 chain 0 \
    flower skip_sw ip_proto tcp \
    action ct zone 1 nat src addr 203.0.113.1 pipe \
    action goto chain 1

# DNAT: 외부 → 내부 (목적지 IP 변환)
tc filter add dev enp3s0f0np0 ingress prio 1 chain 0 \
    flower skip_sw ip_proto tcp dst_ip 203.0.113.1 dst_port 443 \
    action ct zone 1 nat dst addr 10.0.0.100 port 8443 pipe \
    action goto chain 1

# CT offload 상태 확인
tc -s filter show dev enp3s0f0np0_0 ingress
# ... in_hw in_hw_count 1 ← HW CT 오프로드 활성

# conntrack 하드웨어 엔트리 수 확인
devlink resource show pci/0000:03:00.0 | grep ct
# name ct_table size 2097152 occ 45230  ← 현재 45K 연결 HW 추적

SR-IOV vs SF vs vDPA 가상화 비교

DPU는 호스트에 가상 디바이스를 노출하는 세 가지 주요 메커니즘을 제공합니다. 각 방식은 성능, 유연성, 마이그레이션 지원에서 서로 다른 트레이드오프를 가집니다.

/* include/linux/vdpa.h — vDPA 핵심 구조체 */
struct vdpa_device {
    struct device dev;
    struct vdpa_mgmt_dev *mdev;     /* 관리 디바이스 (mlx5_core.sf 등) */
    const struct vdpa_config_ops *config;
    unsigned int index;
    bool features_valid;
    bool use_va;
    u32 nvqs;                        /* virtqueue 수 */
    struct vdpa_mgmt_dev *mdev;
};

/* vDPA config ops — DPU 드라이버가 구현 */
struct vdpa_config_ops {
    /* VQ 설정 */
    int  (*set_vq_address)(...);      /* VQ 메모리 매핑 */
    void (*set_vq_num)(...);          /* VQ depth 설정 */
    void (*kick_vq)(...);             /* VQ doorbell */

    /* 디바이스 설정 */
    u64  (*get_device_features)(...); /* HW 지원 virtio feature */
    u8   (*get_status)(...);
    void (*set_status)(...);

    /* 라이브 마이그레이션 */
    int  (*suspend)(...);              /* 데이터 경로 일시 중지 */
    int  (*resume)(...);               /* 데이터 경로 재개 */
    int  (*get_vq_state)(...);         /* VQ 상태 스냅샷 */
    int  (*set_vq_state)(...);         /* VQ 상태 복원 */
};

/* mlx5 vDPA 드라이버: DPU에서 virtio-net HW 가속 구현
 * drivers/vdpa/mlx5/net/mlx5_vnet.c
 *
 * 데이터 경로:
 *   VM virtio-net ←→ vhost-vdpa ←→ mlx5_vdpa ←→ eSwitch HW
 *                                                  │
 *                                            wire speed 포워딩
 *
 * 라이브 마이그레이션:
 *   1. suspend() → HW 데이터 경로 중지
 *   2. get_vq_state() → VQ avail/used idx 스냅샷
 *   3. (마이그레이션 전송)
 *   4. set_vq_state() → 대상 DPU에서 VQ 상태 복원
 *   5. resume() → HW 데이터 경로 재개
 */

mlx5_core 드라이버 모듈 구조

NVIDIA DPU(BlueField)와 ConnectX SmartNIC의 핵심 드라이버인 mlx5_core는 리눅스 네트워크 드라이버 중 가장 복잡한 구조를 가집니다. auxiliary_bus를 통해 이더넷, RDMA, vDPA, crypto 등의 기능을 독립 서브드라이버로 분리합니다.

/* drivers/net/ethernet/mellanox/mlx5/core/main.c
 *
 * mlx5_core 초기화 흐름: PCI probe → 기능별 서브드라이버 등록
 */

/* 핵심 구조체 — DPU/SmartNIC 전체 상태 */
struct mlx5_core_dev {
    struct pci_dev     *pdev;
    struct mlx5_priv    priv;           /* eswitch, health 등 */
    struct mlx5_port_caps port_caps;
    u8                  issi;          /* 인터페이스 사양 버전 */

    /* FW 커맨드 인터페이스 */
    struct mlx5_cmd     cmd;
    struct mlx5_eq_table *eq_table;     /* 이벤트 큐 테이블 */

    /* Capabilities — HW 기능 비트맵 */
    struct mlx5_caps    caps;
    u64                hca_caps_cur[MLX5_CAP_NUM];
    u64                hca_caps_max[MLX5_CAP_NUM];

    /* devlink 인터페이스 */
    struct devlink     *devlink;

    /* eSwitch — DPU/switchdev 핵심 */
    struct mlx5_eswitch *priv.eswitch;
};

/* 초기화 순서 */
static int mlx5_init_one(struct mlx5_core_dev *dev)
{
    int err;

    /* 1. FW 핸드셰이크: INIT_HCA, 이벤트 핸들러 등록 */
    err = mlx5_function_setup(dev, true);

    /* 2. 리소스 테이블 초기화: PD, MR, CQ, QP 풀 */
    err = mlx5_init_once(dev);

    /* 3. eSwitch 초기화 (DPU/switchdev 모드) */
    mlx5_eswitch_init(dev);

    /* 4. devlink 등록 (사용자 공간 관리 인터페이스) */
    mlx5_devlink_register(dev);

    /* 5. auxiliary_bus 디바이스 등록 → 서브드라이버 probe */
    mlx5_register_device(dev);
    /* → mlx5_core.eth.0  → mlx5e_probe()   (Ethernet)
     * → mlx5_core.rdma.0 → mlx5_ib_probe()  (RDMA)
     * → mlx5_core.vnet.0 → mlx5v_probe()    (vDPA)
     * → mlx5_core.sf.N   → mlx5_sf_probe()  (Scalable Functions)
     */

    return 0;
}

/* 소스 트리 구조 (drivers/net/ethernet/mellanox/mlx5/core/):
 *
 * main.c          — PCI probe/remove, mlx5_core_dev 관리
 * cmd.c           — FW 커맨드 mailbox (동기/비동기)
 * eq.c            — 이벤트 큐 (인터럽트 핸들러)
 * health.c        — 하드웨어 헬스 모니터 (watchdog)
 * devlink.c       — devlink 파라미터, 리소스, 헬스 리포터
 *
 * en_main.c       — Ethernet netdev 생성/초기화
 * en_rx.c / en_tx.c — 데이터 경로 (NAPI poll, xmit)
 * en_tc.c         — TC flower 오프로드 파싱/설치
 * en_rep.c        — Representor netdev
 *
 * eswitch.c       — eSwitch 코어 (모드 전환, vport 관리)
 * eswitch_offloads.c — FDB 오프로드 규칙 관리
 *
 * en_accel/       — 가속기 서브시스템
 *   ipsec.c       — IPsec xfrm offload
 *   ktls.c        — kTLS offload
 *
 * sf/             — Scalable Functions
 *   sf.c          — SF 생성/삭제
 *   devlink.c     — SF devlink 포트
 *
 * steering/       — Flow Steering 엔진
 *   fs_core.c     — Flow Table / Flow Group / FTE 관리
 *   fs_cmd.c      — FW 커맨드로 HW 테이블 조작
 */

DPU 부팅 및 프로비저닝

DPU는 독립적인 컴퓨팅 플랫폼이므로 자체 부팅 프로세스가 있습니다. BlueField DPU를 기준으로 부팅 시퀀스와 프로비저닝 절차를 살펴봅니다.

# ━━━ BFB 이미지를 통한 DPU 프로비저닝 ━━━

# 1. 호스트에서 RShim 드라이버 로드
modprobe rshim
systemctl start rshim

# RShim 디바이스 확인
ls /dev/rshim0/
# boot  console  misc
# boot: BFB 이미지 설치 경로
# console: DPU 시리얼 콘솔

# 2. DPU에 BFB 이미지 설치 (호스트에서)
cat DOCA_2.9_BSP_4.9_Ubuntu_22.04.bfb > /dev/rshim0/boot
# → DPU가 자동으로 재부팅되며 이미지 설치 시작
# → 10~15분 소요 (eMMC 쓰기)

# 3. DPU 콘솔 접속 (설치 상태 모니터링)
screen /dev/rshim0/console 115200
# 또는
minicom -D /dev/rshim0/console

# 4. 설치 완료 후 DPU SSH 접속
# RShim은 tmfifo_net0 인터페이스를 제공 (192.168.100.2)
ssh ubuntu@192.168.100.2

# ━━━ DPU 펌웨어 업데이트 ━━━

# DPU ARM에서 FW 업데이트
mlxfwmanager --online -d /dev/mst/mt41692_pciconf0 -u
# → NVIDIA 서버에서 최신 FW 다운로드 및 설치
# → DPU 리셋 필요 (mlxfwreset)

# FW 리셋 (서비스 중단 발생)
mlxfwreset -d /dev/mst/mt41692_pciconf0 reset

# ━━━ PXE 기반 무인 프로비저닝 ━━━

# DPU UEFI에서 PXE 부팅 우선순위 설정
mlxconfig -d /dev/mst/mt41692_pciconf0 set INTERNAL_CPU_BOOT_OPTION=PXE
# → DHCP + TFTP → 커널/rootfs 네트워크 부팅
# → cloud-init으로 초기 설정 자동화

# ━━━ DPU NIC 모드 설정 (SEPARATED_HOST / EMBEDDED_CPU) ━━━

# NIC 모드 확인
mlxconfig -d /dev/mst/mt41692_pciconf0 query | grep -i "internal_cpu_model"
# INTERNAL_CPU_MODEL = EMBEDDED_CPU(1)

# 모드 설명:
# EMBEDDED_CPU(1) — DPU 모드: ARM SoC가 eSwitch 관리자
# SEPARATED_HOST(0) — NIC 모드: 호스트가 직접 NIC 제어

DPU 멀티테넌트 아키텍처

클라우드 환경에서 DPU의 핵심 가치는 인프라 레이어와 테넌트 레이어의 완전한 분리입니다. DPU ARM에서 인프라 서비스(네트워크, 보안, 스토리지)를 강제 적용하면서, 호스트에는 bare metal 수준의 성능을 제공합니다.

OVS 오프로드 파이프라인 비교

OVS(Open vSwitch)는 세 가지 데이터 경로 모드를 제공합니다. DPU 환경에서 가장 높은 성능을 달성하려면 TC flower HW offload 또는 DOCA offload를 사용합니다.

DPU 성능 벤치마킹 및 튜닝

DPU 오프로드의 효과를 정량적으로 측정하고 최적화하기 위한 벤치마킹 방법론과 튜닝 포인트를 다룹니다.

# ━━━ 기본 성능 측정 도구 ━━━

# 1. iperf3 — 대역폭 측정
# 서버 (수신 측)
iperf3 -s -p 5201

# 클라이언트 (송신 측) — 100GbE 전체 대역폭 테스트
iperf3 -c 10.0.0.2 -p 5201 -P 8 -t 30 -l 1M
# 결과: ~98 Gbps (오프로드 활성 시 CPU ~5%)

# 2. TRex / pktgen — PPS 측정
# 64바이트 패킷으로 최대 PPS 측정 (100GbE = 148.8 Mpps 이론값)
# HW offload 시 wire speed(~148 Mpps) 달성 가능
# SW OVS: ~5-10 Mpps / OVS-DPDK: ~30-50 Mpps

# 3. wrk / nginx — kTLS 오프로드 벤치마크
# kTLS HW offload ON vs OFF 비교
# 서버: nginx with ssl + sendfile (kTLS 자동 활성)
wrk -t 8 -c 200 -d 30s https://10.0.0.2/1GB.bin
# HW offload ON:  ~45 Gbps, CPU ~15%
# HW offload OFF: ~20 Gbps, CPU ~95%

# ━━━ 오프로드 효과 측정 방법 ━━━

# CPU 사용률 비교 (offfload 전후)
mpstat -P ALL 1 10

# 인터럽트 분포 확인 (HW offload 시 인터럽트 감소)
watch -n 1 "cat /proc/interrupts | grep mlx5"

# ethtool 카운터로 오프로드 패킷 수 확인
ethtool -S enp3s0f0np0 | grep -E "rx_packets|tx_packets|rx_bytes|tx_bytes"
ethtool -S enp3s0f0np0 | grep -E "offload|hw_"

# OVS dpctl 통계 — 오프로드 vs 소프트웨어 비율
ovs-appctl dpctl/dump-flows type=offloaded | wc -l   # HW offload 플로우 수
ovs-appctl dpctl/dump-flows type=ovs | wc -l         # SW 플로우 수
ovs-appctl coverage/show | grep -i "upcall"         # upcall 빈도 (낮을수록 좋음)

# ━━━ DPU 튜닝 포인트 ━━━

# 1. IRQ affinity — NUMA 정렬
# DPU PCIe 슬롯의 NUMA 노드 확인
cat /sys/class/net/enp3s0f0np0/device/numa_node
# IRQ를 같은 NUMA 노드의 CPU에 바인딩
# mlx5 드라이버는 기본적으로 최적 affinity 설정

# 2. Ring buffer 크기 조정
ethtool -g enp3s0f0np0
ethtool -G enp3s0f0np0 rx 8192 tx 8192

# 3. Adaptive coalescing (인터럽트 병합)
ethtool -C enp3s0f0np0 adaptive-rx on adaptive-tx on

# 4. aRFS (Accelerated Receive Flow Steering)
ethtool -K enp3s0f0np0 ntuple on
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 5. XDP (DPU에서 XDP 활용)
# DPU ARM에서 XDP 프로그램으로 패킷 필터링 가속
ip link set dev enp3s0f0np0 xdpdrv obj xdp_filter.o sec xdp

# 6. eSwitch 인라인 모드 (매칭 깊이 설정)
# none: L2만 매칭 / link: L2+L3 / network: L2~L4 / transport: L2~L4+tunnel
devlink dev eswitch set pci/0000:03:00.0 inline-mode transport

# 7. TC flower 규칙 최적화
# 규칙 수가 많으면 grouped flow table 사용 (자동)
# 불필요한 규칙 정리로 HW 테이블 용량 확보
tc -s filter show dev enp3s0f0np0_0 ingress | grep "in_hw"

DPU 실전 트러블슈팅

DPU 운영 중 발생하는 일반적인 문제와 체계적인 디버깅 절차를 정리합니다.

# ━━━ 체계적 DPU 디버깅 절차 ━━━

# Step 1: 기본 상태 확인
devlink dev show                              # DPU 디바이스 인식 확인
devlink dev info pci/0000:03:00.0             # FW 버전 확인
devlink dev eswitch show pci/0000:03:00.0     # eSwitch 모드 확인
devlink health show pci/0000:03:00.0          # HW 헬스 상태

# Step 2: 드라이버 로그 확인
dmesg | grep -i "mlx5_core\|eswitch\|flower\|offload" | tail -50

# Step 3: 오프로드 상태 확인
tc -s filter show dev enp3s0f0np0_0 ingress   # in_hw 플래그 확인
tc -s filter show dev enp3s0f0np0 ingress
ovs-appctl dpctl/dump-flows type=offloaded | head -20

# Step 4: 리소스 사용량 확인
devlink resource show pci/0000:03:00.0        # HW 테이블 사용량

# Step 5: skip_hw/skip_sw 테스트로 문제 격리
# SW 전용 테스트 (HW 문제 격리)
tc filter add dev rep0 ingress flower ... action ... skip_hw
# HW 전용 테스트 (SW 문제 격리)
tc filter add dev rep0 ingress flower ... action ... skip_sw

# Step 6: FW 진단 (NVIDIA 도구)
mlxdump -d /dev/mst/mt41692_pciconf0 fsdump --type FT  # Flow Table 덤프
mst status                                              # MST 디바이스 상태
flint -d /dev/mst/mt41692_pciconf0 query                # FW 상세 정보

# Step 7: DPU ARM 측 진단 (RShim 또는 SSH)
ssh ubuntu@192.168.100.2 "dmesg | tail -30"    # DPU 커널 로그
ssh ubuntu@192.168.100.2 "ovs-vsctl show"      # DPU OVS 상태
ssh ubuntu@192.168.100.2 "systemctl status"    # DPU 서비스 상태

# ━━━ 고급 디버깅: ftrace로 TC offload 경로 추적 ━━━

# TC flower 오프로드 호출 경로 추적
echo 'mlx5e_rep_setup_tc*' > /sys/kernel/debug/tracing/set_ftrace_filter
echo 'mlx5_eswitch_add*' >> /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on

# TC 규칙 추가 시도
tc filter add dev enp3s0f0np0_0 ingress flower ... skip_sw action ...

# 추적 결과 확인
cat /sys/kernel/debug/tracing/trace
# → mlx5e_rep_setup_tc_cls_flower()
# → mlx5e_tc_add_fdb_flow()
# → parse_cls_flower()
# → parse_tc_fdb_actions()
# → mlx5_eswitch_add_offloaded_rule()

echo 0 > /sys/kernel/debug/tracing/tracing_on

흔한 실수와 해결법

커널 소스 참조 가이드

/* 주요 CONFIG 옵션 — DPU 관련 커널 빌드 설정 */

/* 필수 */
CONFIG_NET_SWITCHDEV=y          /* switchdev 프레임워크 */
CONFIG_NET_DEVLINK=y            /* devlink 서브시스템 */
CONFIG_AUXILIARY_BUS=y          /* auxiliary_bus */
CONFIG_NET_CLS_FLOWER=m         /* TC flower classifier */
CONFIG_NET_ACT_CT=m             /* TC ct action (conntrack) */
CONFIG_NET_ACT_MIRRED=m         /* TC mirred action */
CONFIG_NET_ACT_TUNNEL_KEY=m     /* TC tunnel_key action */
CONFIG_NET_ACT_PEDIT=m          /* TC pedit (header rewrite) */
CONFIG_NET_ACT_VLAN=m           /* TC vlan push/pop */

/* NVIDIA mlx5 */
CONFIG_MLX5_CORE=m              /* mlx5 핵심 드라이버 */
CONFIG_MLX5_CORE_EN=y           /* Ethernet 지원 */
CONFIG_MLX5_ESWITCH=y           /* eSwitch 지원 */
CONFIG_MLX5_TC_CT=y             /* CT offload */
CONFIG_MLX5_TC_SAMPLE=y         /* 패킷 샘플링 */
CONFIG_MLX5_CORE_IPOIB=y        /* IPoIB 지원 */
CONFIG_MLX5_EN_IPSEC=y          /* IPsec HW offload */
CONFIG_MLX5_EN_TLS=y            /* kTLS HW offload */
CONFIG_MLX5_SF=y                /* Scalable Functions */
CONFIG_MLX5_VDPA_NET=m          /* vDPA */
CONFIG_MLX5_INFINIBAND=m        /* RDMA/RoCE */

/* vDPA 프레임워크 */
CONFIG_VDPA=m
CONFIG_VHOST_VDPA=m
CONFIG_VIRTIO_VDPA=m

/* IPsec / xfrm */
CONFIG_XFRM_OFFLOAD=y           /* xfrm HW offload 프레임워크 */
CONFIG_INET_ESP=m               /* ESP 프로토콜 */
CONFIG_INET_ESP_OFFLOAD=m       /* ESP HW offload */

/* kTLS */
CONFIG_TLS=m                    /* 커널 TLS */
CONFIG_TLS_DEVICE=y             /* TLS HW offload */