DPDK

DPDK(Data Plane Development Kit) 고성능 패킷 처리 구조를 심층 분석합니다. EAL 초기화와 hugepage/NUMA 메모리 모델, IOVA(VA/PA), PMD poll-mode 루프, rte_mbuf/ring/graph/mempool 데이터 경로, VFIO/UIO 및 bifurcated PMD, AF_XDP와 representor/rte_flow/hairpin, dmadev, OVS-DPDK·VPP·testpmd 운영 시나리오, trace·metrics·power 관리와 하드닝·트러블슈팅까지 실무 중심으로 다룹니다.

DPDK는 Intel이 주도하여 개발한 고성능 패킷 처리 프레임워크로, 커널 네트워크 스택을 완전히 바이패스하여 유저 공간에서 NIC를 직접 제어합니다. 표준 커널 드라이버가 인터럽트 기반으로 패킷을 처리하는 반면, DPDK는 폴링(polling) 기반 PMD(Poll Mode Driver)를 사용하여 컨텍스트 스위칭과 인터럽트 오버헤드를 제거합니다. 10~400GbE 환경에서 수십~수백 Mpps(백만 패킷/초)의 처리량을 단일 서버에서 달성할 수 있으며, 통신사(NFV), 클라우드(가상 스위칭), 금융(초저지연 트레이딩), CDN, 보안 장비 등에서 핵심 기술로 사용됩니다.

DPDK 아키텍처 개요

커널 네트워크 스택 vs DPDK 비교

EAL (Environment Abstraction Layer)

EAL은 DPDK의 초기화 계층으로, 애플리케이션이 하드웨어와 OS 세부 사항에 독립적으로 동작하도록 추상화합니다. rte_eal_init() 호출 시 수행되는 핵심 작업:

/* DPDK 애플리케이션 기본 구조 */
#include <rte_eal.h>
#include <rte_ethdev.h>
#include <rte_mbuf.h>

int main(int argc, char *argv[])
{
    /* EAL 초기화: hugepage 매핑, 코어 설정, PCI 스캔 */
    int ret = rte_eal_init(argc, argv);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "EAL init failed\\n");

    /* Mempool 생성 (패킷 버퍼 풀) */
    struct rte_mempool *mbuf_pool = rte_pktmbuf_pool_create(
        "MBUF_POOL",
        8192,              /* 풀 크기 (mbuf 개수) */
        256,               /* per-core 캐시 크기 */
        0,                 /* priv_size */
        RTE_MBUF_DEFAULT_BUF_SIZE,  /* 데이터룸 크기 */
        rte_socket_id()    /* NUMA 소켓 */
    );

    /* 포트 설정 및 시작 */
    struct rte_eth_conf port_conf = { 0 };
    rte_eth_dev_configure(port_id, nb_rx_q, nb_tx_q, &port_conf);
    rte_eth_rx_queue_setup(port_id, 0, 1024, rte_eth_dev_socket_id(port_id),
                          NULL, mbuf_pool);
    rte_eth_tx_queue_setup(port_id, 0, 1024, rte_eth_dev_socket_id(port_id),
                          NULL);
    rte_eth_dev_start(port_id);

    /* 메인 패킷 처리 루프 (busy-poll) */
    while (!force_quit) {
        struct rte_mbuf *bufs[32];
        uint16_t nb_rx = rte_eth_rx_burst(port_id, 0, bufs, 32);
        if (nb_rx == 0)
            continue;

        /* 패킷 처리 ... */
        process_packets(bufs, nb_rx);

        uint16_t nb_tx = rte_eth_tx_burst(port_id, 0, bufs, nb_rx);
        for (uint16_t i = nb_tx; i < nb_rx; i++)
            rte_pktmbuf_free(bufs[i]);  /* 전송 실패 mbuf 반환 */
    }

    rte_eal_cleanup();
    return 0;
}

PMD (Poll Mode Driver)

PMD는 DPDK의 핵심으로, 커널 드라이버 없이 유저 공간에서 NIC를 직접 제어합니다. NIC의 PCIe BAR를 mmap()하여 하드웨어 레지스터에 직접 접근하고, DMA 디스크립터 링(descriptor ring)을 유저 공간 메모리에 배치합니다.

• Interrupt 오버헤드: 초당 수백만 개의 Interrupt가 발생하여 CPU 부하 증가
• 컨텍스트 스위치: 커널-유저 공간 전환 비용 발생
• 복사 오버헤드: 패킷이 커널 버퍼 → 유저 버퍼로 복사

PMD는 이 문제를 해결하기 위해 폴링(Polling) 방식으로 동작합니다. 애플리케이션이 직접 NIC를 폴링하여 패킷을 수신하므로 오버헤드가 없습니다.

RX (수신) 동작 원리

PMD의 RX 동작은 생산자-소비자(Producer-Consumer) 패턴을 따릅니다:

이 과정이 매번 반복되며, PMD는 Interrupt 없이도 패킷을 지속적으로 수신할 수 있습니다.

/* PMD의 RX burst 내부 (간략화) — ixgbe_recv_pkts() 기반 */
static uint16_t
pmd_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
{
    struct pmd_rx_queue *rxq = rx_queue;
    volatile union rx_desc *rxdp;  /* 하드웨어 descriptor 포인터 */
    uint16_t nb_rx = 0;

    while (nb_rx < nb_pkts) {
        rxdp = &rxq->rx_ring[rxq->rx_tail];

        /* DD 비트 확인: NIC가 DMA를 완료했는가? */
        if (!(rxdp->wb.status & RX_DESC_DD))
            break;  /* 더 이상 수신된 패킷 없음 */

        /* mbuf 회수 및 메타데이터 설정 */
        struct rte_mbuf *mb = rxq->sw_ring[rxq->rx_tail];
        mb->pkt_len = rxdp->wb.pkt_len;
        mb->data_len = rxdp->wb.pkt_len;
        mb->hash.rss = rxdp->wb.rss_hash;
        mb->vlan_tci = rxdp->wb.vlan_tag;

        rx_pkts[nb_rx++] = mb;

        /* 새 mbuf를 할당하여 descriptor에 채움 (NIC에 반환) */
        struct rte_mbuf *nmb = rte_mbuf_raw_alloc(rxq->mb_pool);
        rxdp->read.pkt_addr = rte_mbuf_data_iova(nmb);
        rxq->sw_ring[rxq->rx_tail] = nmb;

        rxq->rx_tail = (rxq->rx_tail + 1) & rxq->rx_tail_mask;
    }

    /* tail 레지스터 갱신 → NIC에 새 descriptor 사용 가능 알림 */
    if (nb_rx)
        rte_write32(rxq->rx_tail, rxq->tail_ptr);

    return nb_rx;
}

/* PMD의 TX burst 내부 (간략화) */
static uint16_t
pmd_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
    struct pmd_tx_queue *txq = tx_queue;
    uint16_t nb_tx = 0;

    /* 이전에 전송 완료된 descriptor 정리 (mbuf 반환) */
    tx_free_bufs(txq);

    while (nb_tx < nb_pkts) {
        volatile union tx_desc *txdp = &txq->tx_ring[txq->tx_tail];
        struct rte_mbuf *mb = tx_pkts[nb_tx];

        /* TX descriptor에 mbuf의 DMA 주소와 길이 설정 */
        txdp->read.buffer_addr = rte_mbuf_data_iova(mb);
        txdp->read.cmd_type_len = mb->data_len | TX_DESC_EOP | TX_DESC_RS;

        txq->sw_ring[txq->tx_tail] = mb;
        txq->tx_tail = (txq->tx_tail + 1) & txq->tx_tail_mask;
        nb_tx++;
    }

    /* tail 레지스터 갱신 → NIC가 전송 시작 */
    rte_wmb();  /* 메모리 배리어: descriptor 쓰기 완료 보장 */
    rte_write32(txq->tx_tail, txq->tail_ptr);

    return nb_tx;
}

TX (송신) 동작 원리

TX 동작은 RX의 역순으로 진행됩니다:

Rx/Tx 오프로드 플래그

DPDK PMD는 NIC 하드웨어의 오프로드 기능을 ol_flags와 tx_offload 필드로 노출합니다. 올바른 오프로드 설정은 CPU 부하를 NIC으로 이전하여 처리량을 크게 향상시킵니다.

/* Tx 오프로드 설정 예시: TSO + Checksum */
struct rte_eth_conf port_conf = {
    .txmode = {
        .offloads = RTE_ETH_TX_OFFLOAD_IPV4_CKSUM
                   | RTE_ETH_TX_OFFLOAD_TCP_CKSUM
                   | RTE_ETH_TX_OFFLOAD_TCP_TSO,
    },
};

/* 패킷 송신 시 mbuf 오프로드 필드 설정 */
pkt->ol_flags = RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_IP_CKSUM
              | RTE_MBUF_F_TX_TCP_CKSUM | RTE_MBUF_F_TX_TCP_SEG;
pkt->l2_len = sizeof(struct rte_ether_hdr);   /* 14 */
pkt->l3_len = sizeof(struct rte_ipv4_hdr);     /* 20 */
pkt->l4_len = sizeof(struct rte_tcp_hdr);      /* 20 (옵션 없음) */
pkt->tso_segsz = 1460;                         /* MSS */

/* Checksum: pseudo-header checksum을 앱이 계산, 나머지는 NIC */
rte_ipv4_phdr_cksum(ip_hdr, pkt->ol_flags);

/* NIC capability 조회 */
struct rte_eth_dev_info dev_info;
rte_eth_dev_info_get(port_id, &dev_info);
printf("RX offloads: 0x%lx\\n", dev_info.rx_offload_capa);
printf("TX offloads: 0x%lx\\n", dev_info.tx_offload_capa);

벡터화 PMD와 스칼라 PMD

DPDK PMD는 동일 NIC에 대해 여러 코드 경로를 제공합니다. 벡터화(vectorized) PMD는 SSE/AVX2/AVX-512/NEON SIMD 명령어를 사용하여 한 번에 여러 descriptor를 처리하므로 스칼라 경로 대비 1.5~3배의 처리량을 달성합니다.

인터럽트 모드 (하이브리드 폴링)

DPDK는 100% busy-poll만 지원하는 것이 아닙니다. Rx 인터럽트 모드를 사용하면 빈 폴링 시 epoll_wait()로 블로킹하여 CPU를 절약하고, 패킷이 도착하면 VFIO eventfd 인터럽트로 깨어나 폴링을 재개합니다.

/* 인터럽트 모드: 빈 폴링 시 epoll 대기 */
while (!force_quit) {
    uint16_t nb_rx = rte_eth_rx_burst(port_id, queue_id, pkts, 32);

    if (nb_rx == 0) {
        /* 패킷 없음 → 인터럽트 활성화 후 대기 */
        rte_eth_dev_rx_intr_enable(port_id, queue_id);
        struct rte_epoll_event ev;
        rte_epoll_wait(epfd, &ev, 1, timeout_ms);
        rte_eth_dev_rx_intr_disable(port_id, queue_id);
        continue;
    }

    /* 패킷 있음 → 일반 폴링 처리 */
    process_packets(pkts, nb_rx);
}

rte_mbuf 구조체

rte_mbuf는 DPDK의 패킷 버퍼로, 커널의 sk_buff에 대응하지만 설계 철학이 다릅니다. sk_buff는 동적으로 할당되며 메타데이터가 풍부한 반면, rte_mbuf는 Mempool에서 사전 할당되어 고정 크기의 경량 구조체입니다.

/* rte_mbuf 핵심 필드 (lib/mbuf/rte_mbuf_core.h) */
struct rte_mbuf {
    /* 캐시라인 0 (핫 필드) */
    void         *buf_addr;       /* 가상 주소: headroom + 데이터 시작 */
    rte_iova_t    buf_iova;       /* IO 가상 주소 (DMA용, IOVA) */

    union {
        struct {
            uint32_t pkt_len;       /* 전체 패킷 길이 (체인 포함) */
            uint16_t data_len;      /* 이 세그먼트의 데이터 길이 */
            uint16_t vlan_tci;      /* VLAN Tag */
        };
    };
    uint64_t      ol_flags;       /* Offload 플래그 (checksum, TSO, VLAN...) */

    union {
        uint32_t rss;            /* RSS 해시값 */
        struct {
            uint16_t hash;
            uint16_t id;
        } fdir;                     /* Flow Director 필터 ID */
    } hash;

    uint16_t      data_off;       /* buf_addr부터 데이터 시작까지 오프셋 (headroom) */
    uint16_t      refcnt;         /* 참조 카운트 (공유 mbuf) */
    uint16_t      nb_segs;        /* 체인된 세그먼트 수 */
    uint16_t      port;           /* 입력 포트 ID */

    /* 캐시라인 1 (TX offload) */
    uint64_t      tx_offload;     /* L2/L3/L4 len, TSO segsz 등 (비트필드) */
    struct rte_mempool *pool;    /* 소속 Mempool (반환 시 사용) */
    struct rte_mbuf    *next;    /* 다음 세그먼트 (체인) */

    /* 메모리 배치: rte_mbuf 구조체 + headroom + packet data + tailroom */
    /* 자세한 배치는 아래 SVG 참고 */
};

멀티 세그먼트 mbuf (Scatter-Gather)

단일 mbuf의 데이터 영역(기본 2048B)보다 큰 패킷(Jumbo Frame, 최대 9KB)은 여러 mbuf를 next 포인터로 체이닝하여 표현합니다. 이를 Scatter-Gather라고 하며, NIC의 SG DMA 기능과 연동됩니다.

/* 멀티 세그먼트 mbuf 순회 */
struct rte_mbuf *seg = pkt;
uint32_t total_len = 0;

while (seg != NULL) {
    uint8_t *data = rte_pktmbuf_mtod(seg, uint8_t *);
    process_segment(data, seg->data_len);
    total_len += seg->data_len;
    seg = seg->next;
}
/* total_len == pkt->pkt_len 이어야 정상 */

/* 멀티 세그먼트를 단일 세그먼트로 선형화 (필요 시) */
if (rte_pktmbuf_linearize(pkt) != 0)
    rte_pktmbuf_free(pkt);  /* 선형화 실패 (headroom 부족) */

Ring 라이브러리

DPDK rte_ring은 고정 크기, FIFO, lock-free 큐로, 코어 간 패킷 전달, 멀티프로세스 IPC, 태스크 분배 등에 사용됩니다. CAS(Compare-And-Swap) 연산 기반으로 락 없이 다수 생산자/소비자를 지원합니다.

/* Ring 기본 사용 */
struct rte_ring *ring = rte_ring_create(
    "MY_RING",
    1024,                /* 크기 (2의 거듭제곱이어야 함) */
    rte_socket_id(),     /* NUMA 소켓 */
    RING_F_SP_ENQ | RING_F_SC_DEQ  /* 단일 생산자/소비자 (더 빠름) */
);

/* 생산자: 패킷을 Ring에 삽입 */
struct rte_mbuf *pkts[32];
unsigned nb = rte_eth_rx_burst(port, 0, pkts, 32);
unsigned sent = rte_ring_enqueue_burst(ring, (void **)pkts, nb, NULL);

/* 소비자: Ring에서 패킷 추출 (다른 코어) */
struct rte_mbuf *dequeued[32];
unsigned got = rte_ring_dequeue_burst(ring, (void **)dequeued, 32, NULL);

Mempool과 메모리 관리

rte_mempool은 고정 크기 객체의 풀로, DPDK에서 mbuf 할당/해제의 핵심입니다. Hugepage 위에 구축되며, per-core 캐시로 코어 간 경합을 최소화합니다.

/* Mempool 생성과 NUMA 인식 */
struct rte_mempool *pool;

/* 기본: 패킷 mbuf 풀 */
pool = rte_pktmbuf_pool_create(
    "PKT_POOL",
    65535,                   /* 총 mbuf 개수 (2^n - 1 권장) */
    512,                     /* per-core 캐시 크기 (0이면 캐시 비활성) */
    0,                       /* priv_size: mbuf당 추가 메타데이터 크기 */
    RTE_MBUF_DEFAULT_BUF_SIZE,  /* 2048 + 128(headroom) = 2176 */
    rte_socket_id()          /* NUMA 노드 */
);

/* 고급: 외부 메모리로 Mempool 생성 (huge 1GB) */
struct rte_pktmbuf_extmem ext_mem = {
    .buf_ptr  = mmap_addr,      /* 사전 매핑된 hugepage 주소 */
    .buf_iova = iova_addr,      /* IOMMU 매핑된 DMA 주소 */
    .buf_len  = 1ULL << 30,    /* 1GB */
    .elt_size = 2176,           /* mbuf + data 크기 */
};
pool = rte_pktmbuf_pool_create_extbuf("EXT_POOL", 65535, 512,
                                        0, 2176, rte_socket_id(),
                                        &ext_mem, 1);

DPDK 커널 인터페이스: VFIO vs UIO

DPDK가 유저 공간에서 NIC를 제어하려면 커널의 도움이 필요합니다. PCIe BAR 메모리를 유저 공간에 매핑하고, DMA를 위한 물리/IO 주소 변환을 제공하는 두 가지 메커니즘:

# ━━━ VFIO 기반 DPDK 디바이스 바인딩 ━━━

# 1. IOMMU 활성화 확인
dmesg | grep -i iommu
# "DMAR: IOMMU enabled" 또는 "AMD-Vi: IOMMU performance counters supported"

# 2. vfio-pci 모듈 로드
modprobe vfio-pci

# 3. NIC 상태 확인
dpdk-devbind --status

# Network devices using kernel driver
# 0000:03:00.0 'Ethernet Controller X710' if=ens3f0 drv=i40e
# 0000:03:00.1 'Ethernet Controller X710' if=ens3f1 drv=i40e

# 4. 커널 드라이버에서 언바인딩 → VFIO에 바인딩
ip link set ens3f0 down
dpdk-devbind --bind=vfio-pci 0000:03:00.0

# 5. 바인딩 확인
dpdk-devbind --status
# Network devices using DPDK-compatible driver
# 0000:03:00.0 'Ethernet Controller X710' drv=vfio-pci

# ━━━ Hugepage 설정 ━━━

# 2MB hugepage 1024개 = 2GB
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# NUMA 노드별 설정 (듀얼 소켓)
echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
echo 512 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

# 1GB hugepage (부팅 커맨드라인에서만 예약 가능)
# GRUB: default_hugepagesz=1G hugepagesz=1G hugepages=4

# hugetlbfs 마운트
mount -t hugetlbfs nodev /dev/hugepages

# ━━━ UIO 기반 (레거시, IOMMU 없는 환경) ━━━
modprobe uio_pci_generic
dpdk-devbind --bind=uio_pci_generic 0000:03:00.0
# ⚠ DMA 격리 없음 — 프로덕션에서 비권장

/* 커널 VFIO-PCI 드라이버가 DPDK에 제공하는 인터페이스 */

/* 1. Container FD — IOMMU 도메인 (DMA 매핑 관리) */
container_fd = open("/dev/vfio/vfio", O_RDWR);
ioctl(container_fd, VFIO_SET_IOMMU, VFIO_TYPE1v2_IOMMU);

/* 2. Group FD — IOMMU 그룹 */
group_fd = open("/dev/vfio/15", O_RDWR);
ioctl(group_fd, VFIO_GROUP_SET_CONTAINER, &container_fd);

/* 3. Device FD — 특정 PCI 디바이스 */
device_fd = ioctl(group_fd, VFIO_GROUP_GET_DEVICE_FD, "0000:03:00.0");

/* 4. BAR 매핑 — NIC 레지스터에 직접 접근 */
struct vfio_region_info reg = { .argsz = sizeof(reg), .index = 0 };
ioctl(device_fd, VFIO_DEVICE_GET_REGION_INFO, &reg);
bar0 = mmap(NULL, reg.size, PROT_READ | PROT_WRITE, MAP_SHARED,
            device_fd, reg.offset);
/* 이제 bar0[offset]으로 NIC 레지스터 직접 read/write 가능 */

/* 5. DMA 매핑 — hugepage를 IOMMU에 등록 */
struct vfio_iommu_type1_dma_map dma = {
    .argsz = sizeof(dma),
    .flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE,
    .vaddr = (uint64_t)hugepage_vaddr,
    .iova  = (uint64_t)hugepage_vaddr,  /* VA=IOVA 모드 */
    .size  = hugepage_size,
};
ioctl(container_fd, VFIO_IOMMU_MAP_DMA, &dma);
/* NIC DMA가 이 hugepage 영역에 접근 가능 */

IOVA 모드: VA vs PA

현재 DPDK EAL은 Linux에서 버스가 요구하는 모드, 물리 주소 접근 가능 여부, IOMMU 그룹 존재 여부를 함께 보고 IOVA 모드를 고릅니다. 공식 Programmer's Guide는 대부분의 경우 RTE_IOVA_VA를 기본 선호 모드로 설명합니다. VFIO + IOMMU가 있으면 VA와 IOVA를 같게 둘 수 있어 초기화와 DMA 매핑이 단순해지기 때문입니다.

비특권 실행과 EAL 메모리 옵션

최신 Linux GSG는 비특권 DPDK 실행을 공식적으로 다룹니다. 핵심은 hugepage 예약은 root가 먼저 수행하고, 그 뒤에는 hugetlbfs 디렉터리와 /dev/vfio/* 권한을 사용자나 전용 그룹에 넘겨주는 방식입니다. 멀티프로세스가 필요 없다면 --in-memory를 사용해 hugetlbfs 파일 접근 자체를 생략할 수도 있습니다.

# 1. root가 hugepage 예약
sudo dpdk-hugepages.py -p 1G --setup 2G

# 2. 사용자 전용 hugepage 마운트 생성
export HUGEDIR=$HOME/huge-1G
mkdir -p "$HUGEDIR"
sudo dpdk-hugepages.py --mount --directory "$HUGEDIR" \
  --user "$(id -u)" --group "$(id -g)"

# 3. VFIO 디바이스를 일반 사용자에게 넘김
sudo dpdk-devbind --bind=vfio-pci --uid "$(id -u)" --gid "$(id -g)" \
  0000:03:00.0

# 4. 필요 리소스 한도 조정 (/etc/security/limits.d/dpdk.conf)
* soft memlock unlimited
* hard memlock unlimited
* soft nofile 1048576
* hard nofile 1048576

# 5. 비특권 testpmd 실행
dpdk-testpmd -l 2-5 -n 4 \
  --huge-dir "$HUGEDIR" \
  --iova-mode=va \
  -a 0000:03:00.0 \
  -- -i --rxq=2 --txq=2 --forward-mode=io

bifurcated PMD와 Linux control plane

모든 DPDK 포트가 VFIO/UIO로 디바이스 전체를 탈취하는 것은 아닙니다. 최신 DPDK 문서는 일부 NIC가 bifurcated driver 모델을 제공한다고 설명합니다. 이 모델에서는 커널 드라이버가 netdev와 control plane을 유지하고, DPDK PMD는 데이터 경로를 분담합니다. 대표적인 예가 mlx5 계열입니다.

패킷 처리 파이프라인 모델

DPDK 애플리케이션은 두 가지 기본 패킷 처리 모델을 사용합니다:

단계 간 전달은 rte_ring으로 수행합니다. 장점은 단계별 독립 확장, 단점은 Ring 통과 지연과 NUMA 크로싱 비용입니다.

/* Run-to-Completion 모델 구현 예시 (RSS 기반 L2 포워딩) */

/* 포트 설정: 코어 수만큼 RX/TX 큐 생성 */
struct rte_eth_conf port_conf = {
    .rxmode = {
        .mq_mode = RTE_ETH_MQ_RX_RSS,    /* RSS 활성화 */
    },
    .rx_adv_conf = {
        .rss_conf = {
            .rss_hf = RTE_ETH_RSS_IP | RTE_ETH_RSS_TCP | RTE_ETH_RSS_UDP,
        },
    },
};
rte_eth_dev_configure(port_id, nb_cores, nb_cores, &port_conf);

/* 각 코어에 RX/TX 큐 1개씩 할당 */
for (int q = 0; q < nb_cores; q++) {
    rte_eth_rx_queue_setup(port_id, q, 1024, socket_id, NULL, mbuf_pool);
    rte_eth_tx_queue_setup(port_id, q, 1024, socket_id, NULL);
}

/* 워커 함수: 각 코어가 독립적으로 실행 */
static int
worker_main(void *arg)
{
    unsigned core_id = rte_lcore_id();
    unsigned queue_id = core_to_queue[core_id];

    while (!force_quit) {
        struct rte_mbuf *pkts[32];
        uint16_t nb_rx = rte_eth_rx_burst(port_id, queue_id, pkts, 32);

        for (uint16_t i = 0; i < nb_rx; i++) {
            struct rte_ether_hdr *eth = rte_pktmbuf_mtod(pkts[i],
                                        struct rte_ether_hdr *);
            /* MAC 주소 스왑 (L2 포워딩) */
            struct rte_ether_addr tmp = eth->dst_addr;
            eth->dst_addr = eth->src_addr;
            eth->src_addr = tmp;
        }

        uint16_t nb_tx = rte_eth_tx_burst(port_id, queue_id, pkts, nb_rx);
        for (uint16_t i = nb_tx; i < nb_rx; i++)
            rte_pktmbuf_free(pkts[i]);
    }
    return 0;
}

/* 모든 워커 코어에서 실행 시작 */
rte_eal_mp_remote_launch(worker_main, NULL, CALL_MAIN);

Graph 라이브러리 — 노드 기반 패킷 실행기

rte_graph는 DPDK의 패킷 처리 로직을 "노드 그래프"로 표현하는 런타임입니다. 예전의 수동 while (rx_burst → process → tx_burst) 루프를 대체한다기보다, 그 루프를 재사용 가능한 노드 단위로 정규화해 주는 계층이라고 보는 편이 정확합니다. 최신 Programmer's Guide는 Graph가 run-to-completion(RTC)와 dispatch 두 실행 모델을 제공하고, 통계/멀티프로세스/그래프 export까지 지원한다고 설명합니다.

/* Graph 생성 흐름의 핵심만 남긴 예시 */
struct rte_graph_param graph_conf = {
    .socket_id = rte_socket_id(),
    .nb_node_patterns = 1,
    .node_patterns = (const char *[]){ "*" },
};

rte_graph_t graph_id = rte_graph_create("graph0", &graph_conf);
struct rte_graph *graph = rte_graph_lookup("graph0");

/* 메인 루프는 rte_graph_walk() 한 줄로 단순화 */
while (!force_quit)
    rte_graph_walk(graph);

AF_XDP PMD — 커널 통합 고성능 경로

AF_XDP는 DPDK의 완전한 커널 바이패스와 커널 네트워크 스택 사이의 중간 지점입니다. 커널의 XDP 훅에서 패킷을 유저 공간으로 제로카피 전달하므로, VFIO 바인딩 없이 커널 드라이버를 유지하면서 고성능 패킷 처리가 가능합니다.

# ━━━ AF_XDP PMD로 DPDK 실행 ━━━

# NIC은 커널 드라이버에 그대로 유지 (VFIO 바인딩 불필요!)
ip link show ens3f0
# ens3f0: ... state UP ... driver: i40e

# AF_XDP PMD로 DPDK 앱 실행
dpdk-l2fwd -l 0-3 -n 4 \
  --vdev net_af_xdp0,iface=ens3f0,start_queue=0,queue_count=4 \
  -- -p 0x1

# 제로카피 모드 (NIC 드라이버가 지원하는 경우)
# i40e, ice, mlx5 등이 AF_XDP 제로카피 지원
dpdk-l2fwd -l 0-3 -n 4 \
  --vdev net_af_xdp0,iface=ens3f0,start_queue=0,queue_count=4 \
  -- -p 0x1
# 제로카피는 NIC 드라이버가 자동 감지하여 활성화

rte_flow, representor, embedded switch

현대 NIC와 DPU는 단순한 RX/TX 큐 이상의 기능을 제공합니다. PF/VF/SF 앞단의 embedded switch(eSwitch)를 하드웨어가 직접 처리하고, DPDK는 representor 포트와 rte_flow transfer 규칙으로 이 내부 스위치를 제어합니다. 이 개념을 이해해야 OVS hardware offload, SR-IOV, SmartNIC, switchdev 구성이 한 그림으로 연결됩니다.

# representor 포트를 함께 열어 eSwitch를 제어하는 예시
dpdk-testpmd -l 2-7 -n 4 \
  -a 0000:03:00.0,representor=vf[0-3] \
  -- -i

# rte_flow 관점에서는 attr.transfer = 1 이면
# 큐가 아니라 eSwitch 도메인에 규칙을 넣겠다는 뜻입니다.

/* eSwitch transfer 규칙의 핵심만 남긴 예시 */
struct rte_flow_attr attr = {
    .ingress = 1,
    .transfer = 1,   /* 큐가 아닌 eSwitch 도메인 */
};

/* 패턴/액션은 NIC별 지원 범위가 다르므로
 * 반드시 rte_flow_validate()와 rte_eth_dev_info_get()로 먼저 확인 */
rte_flow_validate(port_id, &attr, pattern, actions, &error);

rte_flow 패턴·액션 카탈로그

rte_flow는 NIC 하드웨어에 패킷 분류/액션 규칙을 설치하는 통합 API입니다. 패턴(pattern)으로 매칭 조건을 정의하고, 액션(action)으로 매칭된 패킷의 처리를 지정합니다. NIC별 지원 범위가 다르므로 반드시 rte_flow_validate()로 검증해야 합니다.

/* rte_flow 규칙 생성 — IPv4 TCP 포트 80을 Queue 2로 전달 */
struct rte_flow_attr attr = { .ingress = 1 };

/* 패턴: ETH / IPv4 / TCP dst_port=80 */
struct rte_flow_item_eth eth_spec = { 0 };
struct rte_flow_item_ipv4 ipv4_spec = { 0 };
struct rte_flow_item_tcp tcp_spec = {
    .hdr.dst_port = rte_cpu_to_be_16(80),
};
struct rte_flow_item_tcp tcp_mask = {
    .hdr.dst_port = 0xFFFF,
};

struct rte_flow_item pattern[] = {
    { .type = RTE_FLOW_ITEM_TYPE_ETH,  .spec = &eth_spec },
    { .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_spec },
    { .type = RTE_FLOW_ITEM_TYPE_TCP,  .spec = &tcp_spec, .mask = &tcp_mask },
    { .type = RTE_FLOW_ITEM_TYPE_END },
};

/* 액션: Queue 2 + 카운터 */
struct rte_flow_action_queue queue = { .index = 2 };
struct rte_flow_action_count count = { 0 };

struct rte_flow_action actions[] = {
    { .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &count },
    { .type = RTE_FLOW_ACTION_TYPE_QUEUE, .conf = &queue },
    { .type = RTE_FLOW_ACTION_TYPE_END },
};

/* 검증 후 생성 */
struct rte_flow_error error;
if (rte_flow_validate(port_id, &attr, pattern, actions, &error) == 0) {
    struct rte_flow *flow = rte_flow_create(port_id, &attr,
                                              pattern, actions, &error);
} else {
    printf("Flow validate failed: %s\\n", error.message);
}

Connection Tracking (CT) 오프로드

DPDK 22.x 이후 rte_flow는 하드웨어 기반 Connection Tracking을 지원합니다. 커널의 conntrack처럼 TCP/UDP 연결 상태(NEW, ESTABLISHED, RELATED, INVALID)를 NIC eSwitch 하드웨어가 추적하고, rte_flow 규칙에서 상태를 기반으로 패킷을 분류/드롭합니다. OVS hardware offload의 stateful firewall 지원에 핵심입니다.

/* CT 오프로드: ESTABLISHED 연결은 하드웨어에서 직접 전달 */
struct rte_flow_item_conntrack ct_item = {
    .flags = RTE_FLOW_CONNTRACK_FLAG_ESTABLISHED,
};

struct rte_flow_item ct_pattern[] = {
    { .type = RTE_FLOW_ITEM_TYPE_ETH },
    { .type = RTE_FLOW_ITEM_TYPE_IPV4 },
    { .type = RTE_FLOW_ITEM_TYPE_TCP },
    { .type = RTE_FLOW_ITEM_TYPE_CONNTRACK, .spec = &ct_item },
    { .type = RTE_FLOW_ITEM_TYPE_END },
};

/* ESTABLISHED → representor로 직접 전달 (CPU 바이패스) */
struct rte_flow_action ct_actions[] = {
    { .type = RTE_FLOW_ACTION_TYPE_PORT_ID, .conf = &repr_port },
    { .type = RTE_FLOW_ACTION_TYPE_END },
};

Flow isolated mode

isolated mode는 "명시적으로 설치한 rte_flow 규칙만 포트에 들어오게 하겠다"는 선언입니다. 이 모드를 켜면 PMD의 기본 RSS/기본 큐 처리 경로를 차단하고, 포트 전체를 flow rule 기반 제어면으로 바꾸게 됩니다. 하드웨어 오프로드 어플라이언스나 엄격한 서비스 체인에서 특히 유용합니다.

testpmd> flow isolate 0 true
testpmd> flow create 0 ingress pattern eth / ipv4 / tcp / end \
          actions queue index 0 / end
testpmd> flow list 0

Hairpin queue와 intra-device 포워딩

hairpin queue는 패킷을 호스트 메모리까지 올리지 않고 NIC 내부에서 다른 RX/TX 큐나 포트로 되돌리는 기능입니다. OVS hardware offload, representor 기반 서비스 체인, 고속 TAP 없는 VM 브리징, 장치 내부 loopback 테스트에서 중요합니다. 최신 testpmd 문서도 hairpin 관련 명령과 포트 프록시 조회 기능을 별도로 다룹니다.

/* Hairpin capability 조회 후 큐 구성하는 패턴 */
struct rte_eth_hairpin_cap cap;
rte_eth_dev_hairpin_capability_get(port_id, &cap);

struct rte_eth_hairpin_conf hp = {
    .peer_count = 1,
    .manual_bind = 1,
    .tx_explicit = 1,
};

rte_eth_rx_hairpin_queue_setup(port_id, rxq_id, 1024, &hp);
rte_eth_tx_hairpin_queue_setup(port_id, txq_id, 1024, &hp);

Virtio/Vhost-user 아키텍처

DPDK 환경에서 VM과의 패킷 교환은 vhost-user 프로토콜을 통해 이루어집니다. QEMU 게스트의 virtio-net 프론트엔드와 호스트의 DPDK vhost 백엔드가 공유 메모리(hugepage) 위의 virtqueue를 통해 제로카피로 패킷을 전달합니다. 이 구조를 이해해야 OVS-DPDK, Snabbswitch, VPP 등 가상 스위칭의 성능 특성을 설명할 수 있습니다.

# ━━━ QEMU vhost-user 설정 ━━━

# 1. vhost-user 소켓 경로 (OVS-DPDK가 생성)
# /tmp/vhost-user0

# 2. QEMU 실행 (vhost-user 백엔드 연결)
qemu-system-x86_64 \
  -m 4G -smp 4 \
  -object memory-backend-file,id=mem,size=4G,mem-path=/dev/hugepages,share=on \
  -numa node,memdev=mem \
  -chardev socket,id=char0,path=/tmp/vhost-user0,server=off \
  -netdev vhost-user,id=net0,chardev=char0,vhostforce=on,queues=4 \
  -device virtio-net-pci,netdev=net0,mq=on,vectors=10 \
  ...

# 핵심 옵션 설명:
# share=on        — hugepage를 호스트와 게스트가 공유 (필수)
# vhostforce=on   — vhost-user 강제 사용
# queues=4        — 멀티큐 virtio (vCPU 수에 맞춤)
# vectors=10      — MSI-X 벡터 수 (2*queues + 2)

OVS-DPDK (Open vSwitch + DPDK)

OVS-DPDK는 Open vSwitch의 데이터플레인을 DPDK로 교체하여 가상 스위칭 성능을 극대화한 구성입니다. 클라우드/NFV 환경에서 VM/컨테이너 간 네트워크 트래픽을 유저 공간에서 처리하여, 기존 커널 OVS 대비 5~10배의 처리량을 달성합니다.

# ━━━ OVS-DPDK 설정 예시 ━━━

# 1. OVS에 DPDK 초기화 파라미터 설정
ovs-vsctl --no-wait set Open_vSwitch . \
  other_config:dpdk-init=true \
  other_config:dpdk-socket-mem="1024,1024" \
  other_config:dpdk-lcore-mask=0x3 \
  other_config:dpdk-hugepage-dir="/dev/hugepages"

# 2. OVS 데몬 재시작
systemctl restart openvswitch-switch

# 3. DPDK 브릿지 생성
ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev

# 4. DPDK 물리 포트 추가 (VFIO 바인딩된 NIC)
ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 \
  type=dpdk options:dpdk-devargs=0000:03:00.0

# 5. vhost-user 포트 추가 (VM 연결용)
ovs-vsctl add-port br0 vhost-user0 -- set Interface vhost-user0 \
  type=dpdkvhostuserclient \
  options:vhost-server-path="/tmp/vhost-user0"

# 6. PMD 스레드 CPU 할당 (NUMA 인식)
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x3C

# 7. 플로우 설정 (OpenFlow)
ovs-ofctl add-flow br0 "in_port=dpdk-p0,actions=output:vhost-user0"
ovs-ofctl add-flow br0 "in_port=vhost-user0,actions=output:dpdk-p0"

# ━━━ 성능 확인 ━━━
ovs-appctl dpif-netdev/pmd-stats-show   # PMD 스레드 통계
ovs-appctl dpif-netdev/pmd-rxq-show     # RX 큐 매핑
ovs-appctl dpctl/dump-flows             # 데이터패스 플로우
ovs-appctl coverage/show                # 내부 이벤트 카운터

DPDK 성능 튜닝

# ━━━ 시스템 레벨 DPDK 성능 튜닝 ━━━

# CPU 격리 (GRUB 커맨드라인)
# GRUB_CMDLINE_LINUX="isolcpus=4-15 nohz_full=4-15 rcu_nocbs=4-15 \
#   intel_pstate=disable processor.max_cstate=1 intel_idle.max_cstate=0 \
#   default_hugepagesz=1G hugepagesz=1G hugepages=8 \
#   iommu=pt intel_iommu=on"

# NUMA 토폴로지 확인 — NIC이 어느 NUMA 노드에 있는지
cat /sys/bus/pci/devices/0000:03:00.0/numa_node
# 0  → NUMA 노드 0의 코어와 메모리를 사용해야 함

# 해당 NUMA 노드의 코어 확인
lscpu | grep "NUMA node0"
# NUMA node0 CPU(s): 0-7,16-23

# irqbalance 비활성화 + DPDK 코어에서 IRQ 배제
systemctl stop irqbalance
# /proc/irq/default_smp_affinity에서 DPDK 코어 제외
echo 000F > /proc/irq/default_smp_affinity  # 코어 0-3만 IRQ 허용

# CPU 주파수 고정 (Turbo Boost는 유지, P-state 전환 최소화)
cpupower -c 4-15 frequency-set -g performance

# 코어별 C-state 확인
turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz,IRQ,C1%,C6% sleep 1

QoS/Traffic Management (rte_sched)

rte_sched는 DPDK의 계층적 QoS 스케줄러로, 통신사 NFV와 엔터프라이즈 네트워크에서 가입자/서비스별 대역폭 보장과 트래픽 셰이핑을 유저 공간에서 구현합니다. 커널의 tc/HTB/TBF에 대응하지만, DPDK 데이터 경로 내에서 패킷 단위로 동작하므로 수십 Mpps 수준의 처리량에서도 정밀한 QoS를 유지할 수 있습니다.

/* rte_sched QoS 스케줄러 설정 (간략화) */
struct rte_sched_subport_params subport_params = {
    .tb_rate = 1250000000,       /* 10 Gbps in bytes/s */
    .tb_size = 1000000,           /* 토큰 버킷 크기 */
    .tc_rate = {
        [0] = 500000000,          /* TC0: 4 Gbps (Best Effort) */
        [1] = 375000000,          /* TC1: 3 Gbps (Assured Forwarding) */
        [2] = 250000000,          /* TC2: 2 Gbps (Expedited Forwarding) */
        [3] = 125000000,          /* TC3: 1 Gbps */
    },
    .tc_period = 10,              /* TC 갱신 주기 (ms) */
};

struct rte_sched_pipe_params pipe_profiles[] = {
    {   /* 프로필 0: 일반 가입자 100 Mbps */
        .tb_rate = 12500000,       /* 100 Mbps */
        .tb_size = 100000,
        .tc_rate = { 6250000, 3125000, 3125000, 0 },
        .tc_period = 40,
        .wrr_weights = { 1, 1, 1, 1 },
    },
};

/* 스케줄러 생성 및 패킷 큐잉/디큐잉 */
struct rte_sched_port *sched = rte_sched_port_config(&port_params);
rte_sched_subport_config(sched, 0, &subport_params, 0);
rte_sched_pipe_config(sched, 0, pipe_id, 0);

/* 데이터 경로에서: classify → enqueue → dequeue */
rte_sched_port_pkt_write(sched, pkts, nb_pkts, subport, pipe, tc, queue);
uint16_t nb_enq = rte_sched_port_enqueue(sched, pkts, nb_pkts);
uint16_t nb_deq = rte_sched_port_dequeue(sched, out_pkts, 32);
rte_eth_tx_burst(port_id, 0, out_pkts, nb_deq);

Eventdev — 이벤트 기반 패킷 스케줄링

rte_eventdev는 DPDK의 이벤트 기반 프로그래밍 모델로, 하드웨어 이벤트 스케줄러(Intel DLB2 등)나 소프트웨어 구현을 통해 패킷을 워커 코어에 동적으로 분배합니다. Run-to-Completion과 Pipeline 모델의 장점을 결합합니다.

Eventdev 동작 모델 요약
- RX Adapter가 이벤트를 생성해 Scheduler Queue(Atomic/Ordered/Parallel)에 분배
- Worker(Core 4~6)가 큐에서 이벤트를 처리
- TX Adapter가 처리 완료 이벤트를 송신 큐로 전달

큐 타입:
- Atomic: 같은 플로우는 동일 워커로 전달 (순서 보장)
- Ordered: 병렬 처리 후 출력 시 순서 재정렬
- Parallel: 순서 무관, 최대 처리량

장점:
- 트래픽 부하에 따라 워커 수를 유연하게 조정
- Atomic 큐로 플로우별 락 없는 처리 보장
- 하드웨어 스케줄러(DLB2)는 CPU 오버헤드 없이 이벤트 분배

Cryptodev — 암호화 가속 프레임워크

rte_cryptodev는 DPDK의 암호화 추상화 계층으로, 하드웨어 가속기(Intel QAT, Marvell OCTEON, ARM CE)와 소프트웨어 구현(AESNI, OpenSSL, ARMv8 CE)을 동일한 API로 접근합니다. IPSec VPN, TLS 프록시, MACsec, 디스크 암호화 가속 등에서 DPDK 데이터 경로와 통합되어 패킷 단위 암호 연산을 인라인 또는 lookaside 방식으로 처리합니다.

/* Cryptodev 세션 생성 및 암호화 요청 (간략화) */

/* 1. Crypto 디바이스 설정 */
struct rte_cryptodev_config conf = {
    .nb_queue_pairs = 1,
    .socket_id = rte_socket_id(),
};
rte_cryptodev_configure(cdev_id, &conf);

/* 2. 세션 풀 생성 */
struct rte_mempool *sess_pool = rte_cryptodev_sym_session_pool_create(
    "SESS_POOL", 256, 0, 0, 0, rte_socket_id());

/* 3. 대칭 암호화 세션: AES-128-CBC + HMAC-SHA256 */
struct rte_crypto_sym_xform cipher_xform = {
    .type = RTE_CRYPTO_SYM_XFORM_CIPHER,
    .cipher = {
        .op = RTE_CRYPTO_CIPHER_OP_ENCRYPT,
        .algo = RTE_CRYPTO_CIPHER_AES_CBC,
        .key = { .data = key, .length = 16 },
        .iv = { .offset = IV_OFFSET, .length = 16 },
    },
    .next = &auth_xform,  /* 인증 체이닝 */
};

void *session = rte_cryptodev_sym_session_create(cdev_id,
    &cipher_xform, sess_pool);

/* 4. 암호화 요청 (enqueue/dequeue) */
struct rte_crypto_op *ops[32];
rte_crypto_op_bulk_alloc(op_pool, RTE_CRYPTO_OP_TYPE_SYMMETRIC,
                        ops, 32);

for (int i = 0; i < 32; i++) {
    ops[i]->sym->m_src = pkts[i];  /* mbuf 연결 */
    rte_crypto_op_attach_sym_session(ops[i], session);
}

uint16_t enq = rte_cryptodev_enqueue_burst(cdev_id, 0, ops, 32);
/* ... 다른 작업 수행 ... */
uint16_t deq = rte_cryptodev_dequeue_burst(cdev_id, 0, ops, 32);

DPDK 멀티프로세스 모드

DPDK는 primary-secondary 프로세스 모델을 지원합니다. Primary 프로세스가 EAL 초기화, 포트 설정, Mempool 생성을 수행하고, Secondary 프로세스가 공유 메모리(hugepage)를 통해 동일한 자원에 접근합니다.

# 멀티프로세스 실행 예시

# Primary 프로세스 시작
dpdk-l2fwd -l 0-3 -n 4 --proc-type primary -- -p 0x3

# Secondary 프로세스 (패킷 덤프)
dpdk-pdump -l 4 --proc-type secondary -- \
  --pdump 'port=0,queue=*,rx-dev=/tmp/rx.pcap'

# Secondary 프로세스 (통계 모니터링)
dpdk-proc-info --proc-type secondary -- --stats

컨테이너·Kubernetes 통합

DPDK를 컨테이너화하면 배포·확장·롤백이 용이하지만, hugepage 마운트, VFIO 디바이스 노출, CPU 격리, NUMA 인식 스케줄링 등 추가 설정이 필요합니다. Kubernetes 환경에서는 SR-IOV Device Plugin과 Multus CNI가 DPDK 워크로드에 VF를 동적 할당하는 표준 패턴입니다.

# Kubernetes DPDK Pod 스펙 예시
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-testpmd
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: dpdk-app:24.11
    command: ["dpdk-testpmd"]
    args:
      - "-l"
      - "2-5"
      - "-n"
      - "4"
      - "--iova-mode=va"
      - "--in-memory"
      - "--"
      - "-i"
      - "--rxq=2"
      - "--txq=2"
    resources:
      requests:
        cpu: "4"
        memory: "4Gi"
        hugepages-1Gi: "2Gi"
        intel.com/sriov_dpdk: "1"
      limits:
        cpu: "4"
        memory: "4Gi"
        hugepages-1Gi: "2Gi"
        intel.com/sriov_dpdk: "1"
    securityContext:
      capabilities:
        add: ["IPC_LOCK", "SYS_RAWIO"]
    volumeMounts:
    - name: hugepages
      mountPath: /dev/hugepages
  volumes:
  - name: hugepages
    emptyDir:
      medium: HugePages-1Gi

# ━━━ Docker 직접 실행 예시 ━━━

# SR-IOV VF 생성
echo 4 > /sys/class/net/ens3f0/device/sriov_numvfs

# VF를 vfio-pci에 바인딩
dpdk-devbind --bind=vfio-pci 0000:03:02.0

# VFIO 그룹 번호 확인
ls -la /sys/bus/pci/devices/0000:03:02.0/iommu_group
# → /sys/kernel/iommu_groups/42

# Docker 실행 (privileged 없이!)
docker run --rm -it \
  --device /dev/vfio/42 \
  --device /dev/vfio/vfio \
  -v /dev/hugepages:/dev/hugepages \
  --ulimit memlock=-1:-1 \
  --cpuset-cpus=4-7 \
  dpdk-app:24.11 \
  dpdk-testpmd -l 4-7 -n 4 -a 0000:03:02.0 -- -i

DPDK 디버깅과 모니터링

# ━━━ DPDK 디버깅/모니터링 명령 모음 ━━━

# 포트 통계 (기본 + 확장)
dpdk-proc-info -- --stats
dpdk-proc-info -- --xstats  # NIC별 상세 카운터 (rx_good_bytes, tx_errors, ...)

# 실시간 패킷 캡처 (secondary 프로세스)
dpdk-pdump -l 8 --proc-type secondary -- \
  --pdump 'port=0,queue=*,rx-dev=/tmp/capture.pcap'
# 캡처 파일을 tcpdump/Wireshark로 분석
tcpdump -r /tmp/capture.pcap

# dumpcap 스타일 캡처 (pcapng)
dpdk-dumpcap --list-interfaces
dpdk-dumpcap -i "0000:03:00.0" -c 1000 -w /tmp/trace.pcapng

# 텔레메트리 API (DPDK 20.05+)
# UNIX 소켓 경로: /var/run/dpdk/rte/dpdk_telemetry.vX
dpdk-telemetry.py
# 대화형 쿼리:
# --> /ethdev/stats,0
# --> /ethdev/xstats,0
# --> /eal/params
# --> /mempool/list

# testpmd로 성능 측정
dpdk-testpmd -l 0-3 -n 4 -a 0000:03:00.0 -- \
  -i \
  --forward-mode=io \
  --rxq=4 --txq=4 \
  --nb-cores=3 \
  --burst=32

# testpmd 내부 명령:
# testpmd> start
# testpmd> show port stats all
# testpmd> show fwd stats all
# testpmd> show port xstats 0
# testpmd> stop

# Mempool 상태 확인
dpdk-proc-info -- --mempool=MBUF_POOL

# EAL 로그 레벨 (런타임 조정)
# --log-level=lib.eal:8   (DEBUG)
# --log-level=pmd.net.mlx5:7  (INFO)

/* 프로그래밍 방식 통계 수집 */
struct rte_eth_stats stats;
rte_eth_stats_get(port_id, &stats);

printf("Port %u: RX %lu pkts (%lu bytes) TX %lu pkts (%lu bytes)\\n",
       port_id,
       stats.ipackets, stats.ibytes,
       stats.opackets, stats.obytes);
printf("  RX errors: %lu  TX errors: %lu  RX no-mbuf: %lu\\n",
       stats.ierrors, stats.oerrors, stats.rx_nombuf);

/* 확장 통계 (xstats): NIC별 상세 카운터 */
int len = rte_eth_xstats_get(port_id, NULL, 0);
struct rte_eth_xstat *xstats = malloc(len * sizeof(*xstats));
struct rte_eth_xstat_name *names = malloc(len * sizeof(*names));
rte_eth_xstats_get(port_id, xstats, len);
rte_eth_xstats_get_names(port_id, names, len);

for (int i = 0; i < len; i++)
    printf("  %s: %lu\\n", names[i].name, xstats[i].value);

추가 런타임 서비스: DMA, 전력, 메트릭, 추적

DPDK는 ethdev와 mempool만으로 끝나지 않습니다. 최신 Programmer's Guide는 DMA 엔진 추상화(dmadev), 유휴 폴링 완화용 전력 관리, 메트릭 레지스트리, 저오버헤드 trace 라이브러리를 별도 서브시스템으로 제공합니다. 패킷 처리 코드가 어느 정도 안정되면, 실제 운영 품질은 이 주변 서비스에서 갈리는 경우가 많습니다.

dmadev — 복사/메모리 이동 오프로딩

rte_dmadev는 패킷 그 자체를 처리하는 장치가 아니라 메모리 이동 작업을 오프로딩하는 계층입니다. 공식 문서는 submission/completion ring 기반 API와 ring-less API를 함께 설명합니다. 패킷 payload 복사, 배치 memcpy, 압축/암호화 전 사전 정렬, 소프트웨어 파이프라인의 copy stage 분리에 유용합니다.

/* dmadev로 메모리 복사 enqueue */
uint16_t vchan = 0;
uint16_t job = rte_dma_copy(dev_id, vchan,
                            src_iova, dst_iova, copy_len,
                            0);
rte_dma_submit(dev_id, vchan);

/* 완료 수거 */
uint16_t done = rte_dma_completed(dev_id, vchan,
                                  32, last_idx, NULL, NULL);

유휴 폴링과 전력 관리

DPDK는 본질적으로 busy-poll 프레임워크이지만, 최신 power management 문서는 empty poll 기반 절전, monitor/pause instruction, CPU frequency scaling 연계를 별도로 제공합니다. 즉 "DPDK는 항상 100% CPU를 태운다"는 단순화는 반만 맞습니다. 낮은 부하 구간에서 지연 허용치가 있다면, empty poll 횟수를 기준으로 절전과 지연을 절충할 수 있습니다.

Metrics와 Trace

Metrics 라이브러리는 이름이 등록된 메트릭 집합에 값을 채워 넣는 모델이고, Trace 라이브러리는 저오버헤드 순환 버퍼에 이벤트를 남긴 뒤 파일로 내보내는 모델입니다. 관측 대상을 "지속적 수치"와 "순간 사건"으로 분리하면 설계가 단순해집니다.

/* Metrics 등록 예시 */
int key = rte_metrics_reg_name("rx_missed_errors");
uint64_t values[1] = { rx_missed };
rte_metrics_update_values(RTE_METRICS_GLOBAL, &key, values, 1);

/* Trace는 데이터 평면 이벤트를 남기고, 필요 시 파일로 덤프 */
rte_trace_point_emit_u16(port_id);
rte_trace_save();

testpmd 기반 재현 실습

testpmd는 DPDK를 배울 때 가장 중요한 도구입니다. 포트 초기화, 큐 배치, 오프로드 플래그, xstats, flow rule, representor, hairpin을 하나씩 검증할 수 있기 때문입니다. 실무에서는 "내 애플리케이션이 이상하다"라고 보기 전에 먼저 testpmd로 하드웨어와 EAL 조합이 정상인지 확인해야 합니다.

랩 환경 준비

# 1. hugepage 준비
sudo dpdk-hugepages.py -p 1G --setup 2G
dpdk-hugepages.py --show

# 2. 장치 바인딩 상태 확인
dpdk-devbind --status

# 3. VFIO 바인딩
sudo modprobe vfio-pci
sudo ip link set ens3f0 down
sudo dpdk-devbind --bind=vfio-pci 0000:03:00.0

# 4. interactive testpmd 시작
dpdk-testpmd -l 2-5 -n 4 \
  --iova-mode=va \
  -a 0000:03:00.0 \
  -- -i \
  --nb-cores=2 \
  --rxq=2 --txq=2 \
  --burst=32 \
  --port-topology=chained

세션 중 확인 명령

testpmd> show port info all
testpmd> show port stats all
testpmd> show rxq info 0 0
testpmd> show txq info 0 0
testpmd> set fwd macswap
testpmd> set burst 64
testpmd> start
testpmd> stop
testpmd> show fwd stats all
testpmd> show port xstats 0
testpmd> clear port stats all
testpmd> dump mempool
testpmd> quit

패킷 캡처와 관찰 포인트

VPP (FD.io) — 유저 공간 네트워크 스택

VPP(Vector Packet Processing)는 Cisco가 개발한 고성능 유저 공간 네트워크 스택으로, DPDK PMD 위에서 동작하며 L2~L4 스위칭/라우팅, NAT, IPSec, ACL 등 커널 네트워크 스택의 기능을 유저 공간에서 구현합니다.

DPDK 관련 커널 소스 구조

DPDK 자체는 유저 공간 라이브러리이지만, 커널 측에서 DPDK 동작을 지원하는 핵심 구성 요소:

# DPDK 관련 커널 설정 (CONFIG_*)

# VFIO (권장)
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_NOIOMMU=y          # no-IOMMU 모드 (테스트용)

# UIO (레거시)
CONFIG_UIO=m
CONFIG_UIO_PCI_GENERIC=m

# IOMMU
CONFIG_IOMMU_SUPPORT=y
CONFIG_INTEL_IOMMU=y            # Intel VT-d
CONFIG_AMD_IOMMU=y              # AMD-Vi
CONFIG_IOMMU_DEFAULT_DMA_LAZY=y # IOVA 지연 해제 (성능)

# Hugepage
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_TRANSPARENT_HUGEPAGE=y   # THP (DPDK는 명시적 hugetlbfs 선호)

# AF_XDP
CONFIG_XDP_SOCKETS=y
CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=m

# NUMA
CONFIG_NUMA=y
CONFIG_NUMA_BALANCING=y

DPDK 빌드 시스템과 버전 변천

DPDK는 22.11 LTS 이후 Meson + Ninja를 유일한 공식 빌드 시스템으로 사용합니다. 이전의 make 기반 빌드는 21.11에서 완전히 제거되었습니다. ABI 안정성 정책은 LTS 릴리스 간에 유지되며, 연 1회 LTS와 분기별 안정 릴리스로 운영됩니다.

# ━━━ DPDK Meson 빌드 (권장) ━━━

# 의존성 설치 (Debian/Ubuntu)
apt install build-essential meson ninja-build python3-pyelftools \
    libnuma-dev libpcap-dev pkg-config

# 소스 다운로드 및 빌드
tar xf dpdk-24.11.tar.xz && cd dpdk-24.11
meson setup build
# 또는 옵션 지정:
meson setup build \
  -Dplatform=native \
  -Dexamples=l2fwd,l3fwd,testpmd \
  -Dmax_ethports=32 \
  -Ddisable_drivers=net/bnxt,net/enic \
  -Ddefault_library=shared
ninja -C build
ninja -C build install
ldconfig

# pkg-config로 DPDK 연동 확인
pkg-config --cflags --libs libdpdk

# ━━━ 애플리케이션 빌드 (Meson 연동) ━━━
# meson.build 예시:
# project('my_app', 'c')
# dpdk_dep = dependency('libdpdk')
# executable('my_app', 'main.c', dependencies: dpdk_dep)

코어 빌드 옵션 상세

Meson 빌드 시스템에서 -D옵션=값 형태로 지정하는 핵심 빌드 옵션의 전체 목록입니다. meson configure build 명령으로 현재 설정을 확인할 수 있습니다.

드라이버·라이브러리 선택 옵션

DPDK는 200개 이상의 PMD(Poll Mode Driver)를 포함하며, 불필요한 드라이버를 제외하면 빌드 시간과 바이너리 크기를 크게 줄일 수 있습니다.

# ━━━ 최소 드라이버 빌드 (mlx5 + virtio만) ━━━
meson setup build \
  -Denable_drivers=net/mlx5,net/virtio,common/mlx5 \
  -Ddisable_libs=pipeline,table,port,fib,rib,reorder \
  -Ddisable_apps=test \
  -Dplatform=generic \
  -Ddefault_library=static \
  -Db_lto=true

크기 제한 및 리소스 상수

DPDK의 내부 자료 구조 크기를 컴파일 타임에 결정하는 상수입니다. 기본값은 범용 서버를 기준으로 설정되어 있으며, 임베디드 환경이나 대규모 NIC 환경에서는 조정이 필요합니다.

기능 토글 옵션

빌드에 포함할 기능을 세밀하게 제어하는 옵션입니다.

크로스 컴파일 설정

DPDK는 Meson의 크로스 컴파일 파일(cross-file)을 사용하여 ARM, RISC-V 등 다양한 아키텍처용 빌드를 지원합니다.

# ━━━ ARM64 크로스 컴파일 파일 (aarch64_cross.txt) ━━━

[binaries]
c = 'aarch64-linux-gnu-gcc'
cpp = 'aarch64-linux-gnu-g++'
ar = 'aarch64-linux-gnu-ar'
strip = 'aarch64-linux-gnu-strip'
pkgconfig = 'aarch64-linux-gnu-pkg-config'

[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'armv8-a'
endian = 'little'

[properties]
platform = 'generic'
cpu_instruction_set = 'generic'

# ━━━ 크로스 컴파일 빌드 명령 ━━━

# ARM64 크로스 컴파일 (BlueField DPU 등)
meson setup build-arm64 \
  --cross-file config/arm/arm64_bluefield_platform \
  -Dplatform=generic \
  -Denable_drivers=net/mlx5,common/mlx5,regex/mlx5,vdpa/mlx5 \
  -Ddefault_library=static

ninja -C build-arm64
DESTDIR=/opt/dpdk-arm64 ninja -C build-arm64 install

# RISC-V 크로스 컴파일 (실험적, DPDK 23.11+)
meson setup build-riscv \
  --cross-file config/riscv/riscv64_linux_gcc \
  -Dplatform=generic

ninja -C build-riscv

make → Meson 전환 매핑

DPDK 21.11에서 make 빌드가 제거되었습니다. 기존 CONFIG_RTE_* 환경 변수와 대응하는 Meson 옵션 매핑입니다.

실전 빌드 레시피

환경별 최적화된 빌드 명령 모음입니다.

# ━━━ 1. 최소 CI 빌드 (빠른 검증) ━━━
meson setup build-ci \
  -Dbuildtype=debugoptimized \
  -Dwerror=true \
  -Dtests=true \
  -Dexamples=l2fwd,l3fwd \
  -Ddisable_drivers=raw/*,crypto/*,compress/*,regex/*,ml/* \
  -Dcheck_includes=true
ninja -C build-ci
meson test -C build-ci --suite fast-tests

# ━━━ 2. 프로덕션 mlx5 빌드 (최대 성능) ━━━
meson setup build-prod \
  -Dbuildtype=release \
  -Dplatform=native \
  -Denable_drivers=net/mlx5,common/mlx5,regex/mlx5 \
  -Ddefault_library=static \
  -Db_lto=true \
  -Dmax_ethports=16 \
  -Dmax_lcores=64 \
  -Dtests=false \
  -Denable_trace_fp=true \
  -Dmbuf_refcnt_atomic=false \
  -Dc_args='-march=icelake-server -mtune=icelake-server'
ninja -C build-prod
sudo ninja -C build-prod install && sudo ldconfig

# ━━━ 3. 디버그 빌드 (문제 추적) ━━━
meson setup build-debug \
  -Dbuildtype=debug \
  -Doptimization=0 \
  -Ddebug=true \
  -Dtests=true \
  -Dexamples=all \
  -Dlog_default_level=debug \
  -Denable_trace_fp=true \
  -Dc_args='-fsanitize=address,undefined' \
  -Dc_link_args='-fsanitize=address,undefined'
ninja -C build-debug

# ━━━ 4. 문서 빌드 (Doxygen + Sphinx) ━━━
apt install doxygen python3-sphinx python3-sphinx-rtd-theme
meson setup build-doc \
  -Denable_docs=true \
  -Dtests=false \
  -Dexamples=
ninja -C build-doc doc

# ━━━ 5. ARM64 DPU 빌드 (NVIDIA BlueField-3) ━━━
meson setup build-bf3 \
  --cross-file config/arm/arm64_bluefield_platform \
  -Dplatform=generic \
  -Denable_drivers=net/mlx5,common/mlx5,regex/mlx5,vdpa/mlx5,compress/mlx5 \
  -Ddefault_library=static \
  -Db_lto=true \
  -Dmax_ethports=8 \
  -Dtests=false \
  -Dprefix=/opt/dpdk
ninja -C build-bf3
DESTDIR=/mnt/bf3-rootfs ninja -C build-bf3 install

DPDK 주요 버전 변천

버전별 옵션 변경 이력

DPDK 버전 업그레이드 시 빌드 스크립트를 수정해야 하는 옵션 변경 사항입니다.

타 바이패스 프레임워크 비교

DPDK는 유일한 커널 바이패스 기술이 아닙니다. 각 프레임워크는 서로 다른 설계 철학과 트레이드오프를 가집니다.

DPDK 구동 시 NVMe 성능 저하 분석

DPDK와 NVMe 드라이버는 직접 코드 경로를 공유하지 않지만, PCIe 버스·CPU 코어·메모리 계층·커널 인프라 수준에서 다수의 간접 간섭 경로가 존재합니다. DPDK 애플리케이션을 기동한 뒤 NVMe SSD의 IOPS·지연이 갑자기 악화되는 현상은 대부분 아래 17가지 원인 중 하나(또는 복합)에 해당합니다.

1. PCIe 버스 대역폭 경합

DPDK 10 GbE 라인레이트(~14.88 Mpps, 64B 프레임)는 PCIe 3.0 x8 대역폭의 상당 부분을 소비합니다. NVMe가 같은 Root Complex 하위 Switch에 연결되면 TLP(Transaction Layer Packet) 수준에서 중재 경합이 발생합니다.

2. CPU 코어·IRQ Affinity 충돌

DPDK PMD는 전용 코어에서 100% CPU를 소비하는 폴링 루프를 실행합니다. NVMe 인터럽트(IRQ)가 같은 코어에 할당되면, IRQ 처리가 지연되어 NVMe I/O 완료 레이턴시가 급증합니다.

# NVMe IRQ를 DPDK 미사용 코어(예: 코어 8~15)로 제한
for irq in $(grep nvme /proc/interrupts | awk '{print $1}' | tr -d ':'); do
    echo ff00 > /proc/irq/$irq/smp_affinity    # 코어 8~15 마스크
done

# irqbalance에서 DPDK 코어(0~7) 제외
echo 'IRQBALANCE_BANNED_CPUS="00ff"' >> /etc/default/irqbalance
systemctl restart irqbalance

3. NUMA 토폴로지 불일치

NUMA 시스템에서 NVMe 컨트롤러가 NUMA 노드 0에 연결되었는데, 애플리케이션이 NUMA 노드 1에서 I/O를 발급하면 Cross-NUMA 메모리 접근으로 지연이 30~100% 증가합니다. DPDK가 hugepage를 특정 NUMA 노드에서 대량 할당하면, 반대 노드의 NVMe 드라이버가 사용할 로컬 메모리가 부족해집니다.

4. Hugepage 메모리 경합

DPDK는 기동 시 수 GB~수십 GB의 1G/2M hugepage를 예약합니다. 이로 인해 시스템 전체의 가용 메모리가 감소하여 NVMe 드라이버와 파일시스템에 영향을 줍니다.

5. IOMMU/VFIO 오버헤드

DPDK는 vfio-pci를 통해 NIC에 접근하며, 이때 IOMMU가 DMA 주소 변환을 수행합니다. NVMe도 IOMMU를 통과하므로, IOTLB 경합과 IOMMU 그룹 공유 문제가 발생할 수 있습니다.

6. LLC 캐시 오염 / 메모리 대역폭 포화

DPDK PMD는 대량의 패킷 버퍼를 연속적으로 접근하며 LLC(Last Level Cache)를 오염시킵니다. NVMe 드라이버의 Completion Queue 엔트리와 I/O 메타데이터가 캐시에서 밀려나면 성능이 저하됩니다.

7. 전원 관리·스케줄러·RCU 간섭

DPDK PMD의 busy-poll 루프는 커널의 전원 관리, 스케줄러, RCU 콜백 처리와 충돌할 수 있습니다.

# DPDK 코어 0~7 격리 + RCU 오프로드 (GRUB 커널 파라미터)
GRUB_CMDLINE_LINUX="isolcpus=0-7 nohz_full=0-7 rcu_nocbs=0-7 \
    intel_idle.max_cstate=1 processor.max_cstate=1 \
    intel_iommu=on iommu=pt"

8. blk-mq 큐 매핑·MSI-X·Thermal

NVMe 드라이버의 blk-mq 큐 할당, MSI-X 벡터 분배, 열 관리 등도 DPDK와의 상호작용에서 영향을 받습니다.

9. 종합 진단 체크리스트와 스크립트

아래 체크리스트를 순서대로 확인하면, DPDK–NVMe 간섭의 대부분을 빠르게 진단할 수 있습니다.

#!/bin/bash
# dpdk-nvme-diag.sh — DPDK/NVMe 간섭 종합 진단 스크립트
set -euo pipefail

echo "=== 1. PCIe 토폴로지 ==="
lspci -tv 2>/dev/null | head -40

echo -e "\n=== 2. NUMA 노드 확인 ==="
for dev in /sys/class/net/*/device/numa_node; do
    [ -f "$dev" ] && echo "$(dirname $(dirname $dev) | xargs basename): $(cat $dev)"
done
for dev in /sys/block/nvme*/device/numa_node; do
    [ -f "$dev" ] && echo "$(echo $dev | grep -o 'nvme[0-9]*'): $(cat $dev)"
done

echo -e "\n=== 3. NVMe IRQ Affinity ==="
for irq in $(grep nvme /proc/interrupts 2>/dev/null | awk '{print $1}' | tr -d ':'); do
    echo "IRQ $irq: $(cat /proc/irq/$irq/smp_affinity_list 2>/dev/null)"
done

echo -e "\n=== 4. Hugepage 상태 (노드별) ==="
for node in /sys/devices/system/node/node*; do
    for hp in "$node"/hugepages/hugepages-*; do
        [ -d "$hp" ] && echo "$(basename $node) $(basename $hp): \
free=$(cat $hp/free_hugepages)/total=$(cat $hp/nr_hugepages)"
    done
done

echo -e "\n=== 5. 메모리 상태 ==="
free -m

echo -e "\n=== 6. THP 설정 ==="
cat /sys/kernel/mm/transparent_hugepage/enabled 2>/dev/null

echo -e "\n=== 7. IOMMU 모드 ==="
dmesg 2>/dev/null | grep -i "iommu.*mode\|iommu.*pass" | tail -3

echo -e "\n=== 8. IOMMU 그룹 (NIC/NVMe) ==="
for dev in $(lspci -D | grep -iE 'nvme|ethernet' | awk '{print $1}'); do
    grp=$(find /sys/kernel/iommu_groups/ -name "$dev" 2>/dev/null | grep -o 'iommu_groups/[0-9]*')
    echo "$dev → $grp"
done

echo -e "\n=== 9. C-state (turbostat) ==="
command -v turbostat &>/dev/null && turbostat --show Avg_MHz,Busy%,CoreTmp -n 1 2>/dev/null | head -10 \
    || echo "turbostat not available"

echo -e "\n=== 10. blk-mq 큐 매핑 ==="
for mq in /sys/block/nvme*/mq/*/cpu_list; do
    [ -f "$mq" ] && echo "$(echo $mq | grep -o 'nvme[^/]*/mq/[0-9]*'): $(cat $mq)"
done

echo -e "\n=== 진단 완료 ==="

운영 하드닝과 트러블슈팅

DPDK 장애는 대개 "패킷 처리 코드"보다 권한, IOMMU 그룹, hugepage 배치, NUMA 불일치, 보안 부팅에서 먼저 발생합니다. 따라서 운영 체크리스트를 코드 리뷰와 별도로 가져가는 편이 안전합니다.

하드닝 체크리스트

자주 보는 증상과 원인

보안 공격 표면과 위협 모델

DPDK는 커널 네트워크 스택을 우회하므로 커널이 제공하는 보안 계층(Netfilter, SELinux, seccomp, 네임스페이스)을 사용할 수 없습니다. 따라서 DPDK 애플리케이션 자체가 신뢰 경계(trust boundary)가 되며, 공격 표면을 명시적으로 인식하고 완화해야 합니다.