Network Device 드라이버 (net_device)

Linux 네트워크 디바이스 드라이버를 고처리량 데이터 경로와 운영 안정성 관점에서 심층 정리합니다. net_device/net_device_ops 초기화, NAPI 기반 RX 폴링, TX 큐 관리와 BQL, MSI-X/IRQ affinity 최적화, checksum/TSO/GRO 등 오프로드 기능, XDP/AF_XDP 연계, ethtool 통계와 링크 상태 관리, 물리 NIC와 TUN/TAP 같은 가상 netdev 공통 모델, tracepoint/perf/bpftrace를 활용한 병목 분석까지 실전 네트워크 드라이버 개발에 필요한 핵심을 다룹니다.

개요: net_device 드라이버의 역할

struct net_device 드라이버는 커널 네트워크 스택과 실제/가상 링크 계층 사이의 어댑터입니다. 유저스페이스 입장에서는 eth0, ens3, tap0 모두 동일한 netdev 인터페이스처럼 보이지만, 내부 구현은 물리 NIC/가상 디바이스에 따라 크게 달라집니다.

드라이버 수명주기와 필수 호출 순서

가장 흔한 실수는 등록/해제 순서를 뒤섞는 것입니다. 특히 NAPI, IRQ, queue start/stop 순서는 패킷 손실과 use-after-free를 바로 유발합니다.

/* 개념 예시: net_device 수명주기와 등록 순서 */
#include <linux/netdevice.h>
#include <linux/etherdevice.h>

struct my_priv {
    struct net_device *ndev;
    struct napi_struct napi;
    spinlock_t tx_lock;
    void __iomem *bar0;
    int irq;
};

static int my_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
    struct net_device *ndev;
    struct my_priv *priv;
    int ret;

    ndev = alloc_etherdev_mqs(sizeof(*priv), 8, 8);
    if (!ndev)
        return -ENOMEM;

    priv = netdev_priv(ndev);
    priv->ndev = ndev;
    spin_lock_init(&priv->tx_lock);

    netif_napi_add(ndev, &priv->napi, my_napi_poll);
    ndev->netdev_ops = &my_netdev_ops;
    ndev->ethtool_ops = &my_ethtool_ops;

    ret = register_netdev(ndev);
    if (ret) {
        netif_napi_del(&priv->napi);
        free_netdev(ndev);
        return ret;
    }

    return 0;
}

static void my_remove(struct pci_dev *pdev)
{
    struct net_device *ndev = pci_get_drvdata(pdev);
    struct my_priv *priv = netdev_priv(ndev);

    unregister_netdev(ndev);
    netif_napi_del(&priv->napi);
    free_netdev(ndev);
}

핵심 콜백: net_device_ops 계약

net_device_ops는 드라이버와 코어 네트워크 스택 간의 ABI 역할을 합니다. 모든 콜백을 구현할 필요는 없지만, open/stop/xmit/statistics의 책임 분리는 명확해야 합니다.

/* 개념 예시: open/stop에서 NAPI-IRQ 순서 보장 */
static int my_ndo_open(struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);

    my_hw_rx_ring_init(priv);
    my_hw_tx_ring_init(priv);

    napi_enable(&priv->napi);
    my_enable_irq(priv);
    netif_tx_start_all_queues(ndev);
    return 0;
}

static int my_ndo_stop(struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);

    netif_tx_disable(ndev);
    my_disable_irq(priv);
    napi_disable(&priv->napi);
    my_hw_rx_ring_cleanup(priv);
    my_hw_tx_ring_cleanup(priv);
    return 0;
}

RX 경로: IRQ, NAPI, budget 처리

수신 경로는 인터럽트 기반 진입 후 NAPI poll로 전환하는 모델이 표준입니다. 드라이버는 budget를 존중하며 완료 시 napi_complete_done()를 호출해야 합니다.

/* 개념 예시: IRQ top-half와 NAPI poll 연계 */
static irqreturn_t my_irq_handler(int irq, void *data)
{
    struct my_priv *priv = data;

    my_mask_rx_irq(priv);
    napi_schedule_irqoff(&priv->napi);
    return IRQ_HANDLED;
}

static int my_napi_poll(struct napi_struct *napi, int budget)
{
    struct my_priv *priv = container_of(napi, struct my_priv, napi);
    int work_done = 0;

    while (work_done < budget) {
        struct sk_buff *skb = my_rx_one_skb(priv);

        if (!skb)
            break;

        skb->protocol = eth_type_trans(skb, priv->ndev);
        napi_gro_receive(napi, skb);
        work_done++;
    }

    if (work_done < budget) {
        napi_complete_done(napi, work_done);
        my_unmask_rx_irq(priv);
    }

    return work_done;
}

RX 전체 파이프라인

아래 다이어그램은 물리 와이어 수신부터 애플리케이션 소켓 버퍼 도달까지의 전체 수신 경로를 보여줍니다. 각 단계에서 일어나는 핵심 동작에 주의하세요.

GRO (Generic Receive Offload) 동작 원리

GRO는 네트워크 스택 진입 전에 동일 flow의 연속 패킷들을 하나의 대형 sk_buff로 집계(merge)하여 프로토콜 스택 처리 횟수를 줄이는 소프트웨어 오프로드 기술입니다. 하드웨어 LRO(Large Receive Offload)와 달리 GRO는 프로토콜 레이어에서 stateless하게 동작하여 포워딩 환경에서도 안전하게 사용할 수 있습니다.

GRO 집계 과정은 다음과 같습니다:

1. NAPI poll에서 napi_gro_receive() 호출 시, GRO 엔진은 napi→gro_hash[] 테이블에서 동일 flow를 검색합니다.
2. 매칭되는 flow가 있으면 현재 패킷의 payload를 기존 skb의 frag_list 또는 frags[]에 병합합니다.
3. flow가 완료되거나(PSH, FIN 등) 타이머/카운트 제한에 도달하면 집계된 대형 skb를 netif_receive_skb()로 전달합니다.
4. 매칭되지 않으면 새 flow 엔트리를 생성하거나 즉시 전달합니다.

/* GRO 수신 경로 핵심 흐름 (개념 예시) */
gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
    gro_result_t ret;

    skb_gro_reset_offset(skb);

    ret = dev_gro_receive(napi, skb);    /* flow 매칭 + 병합 시도 */

    switch (ret) {
    case GRO_MERGED:
    case GRO_MERGED_FREE:
        break;                              /* 병합 성공, skb 보관 */
    case GRO_HELD:
        break;                              /* 새 flow로 보관 */
    case GRO_NORMAL:
        gro_normal_one(napi, skb, 1);    /* GRO 불가, 즉시 전달 */
        break;
    case GRO_CONSUMED:
        break;
    }
    return ret;
}

/* NAPI poll 종료 시 GRO flush — 보관 중인 flow를 모두 전달 */
void napi_complete_done(struct napi_struct *napi, int work_done)
{
    gro_normal_list(napi);           /* 버퍼링된 GRO 패킷 일괄 전달 */
    /* ... napi state 전환, IRQ 재활성화 ... */
}

NAPI 상태 머신

NAPI는 명확한 상태 전환 규약을 가진 상태 머신으로 동작합니다. 드라이버가 이 규약을 정확히 따르지 않으면 인터럽트 누수(IRQ 재활성화 누락)나 poll 미진입 같은 심각한 버그가 발생합니다.

/* NAPI enable/disable 올바른 순서 (개념 예시) */

/* === ndo_open: 활성화 순서 === */
static int my_open(struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);

    /* 1. 하드웨어 초기화 (ring 할당, DMA 설정) */
    my_hw_init(priv);

    /* 2. NAPI 활성화 — 이 시점부터 napi_schedule 가능 */
    napi_enable(&priv->napi);

    /* 3. IRQ 등록 — NAPI enable 후에 해야 schedule이 동작 */
    request_irq(priv->irq, my_irq_handler, 0, "mynic", priv);

    /* 4. TX 큐 시작 */
    netif_tx_start_all_queues(ndev);

    return 0;
}

/* === ndo_stop: 비활성화 순서 === */
static int my_stop(struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);

    /* 1. TX 큐 정지 — 새 xmit 진입 차단 */
    netif_tx_disable(ndev);

    /* 2. IRQ 비활성화 — 새 napi_schedule 차단 */
    disable_irq(priv->irq);

    /* 3. napi_disable — 진행 중인 poll 완료를 대기 (barrier 역할) */
    napi_disable(&priv->napi);
    /* 이 시점 이후 poll 콜백이 절대 실행되지 않음을 보장 */

    /* 4. IRQ 해제 */
    free_irq(priv->irq, priv);

    /* 5. 하드웨어 정리 (ring 해제, DMA 해제) */
    my_hw_cleanup(priv);

    return 0;
}

TX 경로: ndo_start_xmit, 큐 정지/재개, BQL

송신 경로의 핵심은 링 용량 관리입니다. TX ring이 포화됐을 때는 NETDEV_TX_BUSY를 남발하지 말고 queue stop/wake 모델을 일관되게 유지해야 합니다.

/* 개념 예시: 멀티큐 TX stop/wake + BQL 경로 */
static netdev_tx_t my_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);
    struct netdev_queue *txq = netdev_get_tx_queue(ndev, skb_get_queue_mapping(skb));
    unsigned long flags;

    spin_lock_irqsave(&priv->tx_lock, flags);

    if (my_tx_ring_avail(priv) < MAX_SKB_FRAGS + 2) {
        netif_tx_stop_queue(txq);
        spin_unlock_irqrestore(&priv->tx_lock, flags);
        return NETDEV_TX_BUSY;
    }

    my_map_skb_to_tx_desc(priv, skb);
    netdev_tx_sent_queue(txq, skb->len);
    my_ring_doorbell(priv);

    spin_unlock_irqrestore(&priv->tx_lock, flags);
    return NETDEV_TX_OK;
}

static void my_tx_complete(struct my_priv *priv, u16 qid)
{
    struct netdev_queue *txq = netdev_get_tx_queue(priv->ndev, qid);
    u32 bytes = 0, pkts = 0;

    my_reclaim_tx_desc(priv, &bytes, &pkts);
    netdev_tx_completed_queue(txq, pkts, bytes);

    if (netif_tx_queue_stopped(txq) && my_tx_ring_avail(priv) > 64)
        netif_tx_wake_queue(txq);
}

TX 전체 파이프라인

아래 다이어그램은 유저스페이스 send() 호출부터 물리 와이어 송출, TX 완료 인터럽트, 디스크립터 회수까지의 전체 송신 경로를 보여줍니다.

BQL (Byte Queue Limits): 버퍼블로트 방지와 동적 큐 제한

BQL(Byte Queue Limits)은 커널 lib/dynamic_queue_limits.c에 구현된 동적 큐 깊이 제어 알고리즘입니다. NIC TX 큐에 쌓을 수 있는 바이트 수를 실시간으로 조정하여, 큐가 과도하게 깊어지는 버퍼블로트(bufferbloat)를 방지하면서도 충분한 처리량을 유지합니다. TX 경로 앞 절에서 netdev_tx_sent_queue/netdev_tx_completed_queue를 호출한 것이 바로 BQL API입니다. 이 절에서는 그 내부 알고리즘, 자료구조, sysfs 튜닝, 그리고 qdisc와의 상호작용을 깊이 있게 살펴봅니다.

버퍼블로트 문제와 BQL의 필요성

NIC의 TX ring이 크거나 드라이버가 큐 깊이를 제한하지 않으면, 상위 계층(qdisc, TCP 혼잡 제어)이 내린 결정과 무관하게 수백 ms에서 수 초 분량의 패킷이 하드웨어 큐에 쌓일 수 있습니다. 이 "버퍼블로트"는 지연(latency)을 극적으로 증가시키면서 처리량(throughput)은 거의 높이지 않습니다. BQL은 "지금 하드웨어에 내려보낸 바이트"와 "아직 완료되지 않은 바이트"를 추적하여 큐 깊이를 필요 최소한으로 동적 조절합니다.

BQL 동작 원리: 동적 한계 조정 알고리즘

BQL의 핵심은 lib/dynamic_queue_limits.c에 구현된 DQL(Dynamic Queue Limits) 알고리즘입니다. 드라이버가 패킷을 큐에 넣을 때(dql_queued)와 완료될 때(dql_completed)를 추적하여, 현재 inflight(미완료) 바이트가 LIMIT을 초과하면 큐를 멈추고, 완료 시 실제 사용 패턴에 따라 LIMIT을 올리거나 내립니다.

/* DQL 알고리즘 의사코드 (lib/dynamic_queue_limits.c 기반) */

/* ① 드라이버가 패킷을 큐에 넣을 때 */
void dql_queued(struct dql *dql, u32 count)
{
    dql->last_obj_cnt  = count;
    dql->num_queued   += count;

    /* inflight = num_queued - num_completed */
    if (inflight >= dql->adj_limit)
        netif_tx_stop_queue();   /* 큐 정지 — LIMIT 도달 */
}

/* ② TX 완료 인터럽트에서 */
void dql_completed(struct dql *dql, u32 count)
{
    dql->num_completed += count;
    ovlimit = dql->num_queued - dql->num_completed - dql->limit;

    if (ovlimit <= 0) {
        /* BELOW: inflight가 LIMIT 아래 — 과잉 제거 */
        dql->slack = min(dql->slack, ovlimit + dql->slack_start);
        if (slack_expired)
            new_limit = dql->limit - (ovlimit + dql->slack);
    } else {
        /* ABOVE: inflight가 LIMIT 이상 — LIMIT 확장 */
        new_limit = dql->limit + count / 16;  /* 완료분의 1/16 증가 */
    }
    dql->limit = clamp(new_limit, dql->min_limit, dql->max_limit);

    if (inflight < dql->adj_limit)
        netif_tx_wake_queue();   /* 큐 재개 */
}

핵심 자료구조: struct dql

BQL의 상태는 struct dql(include/linux/dynamic_queue_limits.h)에 저장됩니다. 각 TX 큐(struct netdev_queue)마다 하나의 dql 인스턴스가 내장되어 있습니다.

/* include/linux/dynamic_queue_limits.h */
struct dql {
    unsigned int  num_queued;       /* 큐에 넣은 누적 바이트 (단조 증가) */
    unsigned int  adj_limit;        /* 현재 유효 한계 (limit - num_completed) */
    unsigned int  last_obj_cnt;     /* 마지막 dql_queued 호출의 count */

    unsigned int  limit       ____cacheline_aligned_in_smp;
                                     /* 동적 LIMIT (바이트 단위) */
    unsigned int  num_completed;    /* 완료된 누적 바이트 (단조 증가) */

    unsigned int  prev_ovlimit;     /* 이전 주기의 오버리밋 값 */
    unsigned int  prev_num_queued;  /* 이전 주기의 num_queued */
    unsigned int  prev_last_obj_cnt;/* 이전 주기의 last_obj_cnt */

    unsigned int  lowest_slack;     /* 관찰된 최소 여유분 */
    unsigned long slack_start_time; /* slack 관찰 시작 시각 */

    unsigned int  max_limit;        /* sysfs 설정: LIMIT 상한 (기본 DQL_MAX_LIMIT) */
    unsigned int  min_limit;        /* sysfs 설정: LIMIT 하한 (기본 0) */
    unsigned int  slack_hold_time;  /* slack 관찰 윈도우 (기본 HZ=1초) */
};

드라이버 API 통합

드라이버가 BQL을 사용하려면 TX 경로의 세 지점에서 API를 호출합니다. 모든 API는 바이트 단위로 동작하며, 패킷 수가 아닌 누적 바이트를 전달해야 합니다.

/* BQL 드라이버 API 3종 — 호출 시점과 인자 */

/* ① ndo_start_xmit() 내부, skb를 ring에 넣은 직후 */
netdev_tx_sent_queue(txq, skb->len);
/*  txq  : netdev_get_tx_queue(ndev, queue_index)
 *  bytes: 전송한 바이트 수 (skb->len)
 *  내부: dql_queued(&txq->dql, bytes)
 *  inflight ≥ limit이면 __netif_tx_stop_queue() 호출 */

/* ② TX 완료 인터럽트/NAPI에서, 디스크립터 회수 후 */
netdev_tx_completed_queue(txq, pkts, bytes);
/*  pkts : 완료된 패킷 수 (BQL 자체는 bytes만 사용)
 *  bytes: 완료된 바이트 수
 *  내부: dql_completed(&txq->dql, bytes)
 *  LIMIT 재조정 + 큐 wake 판단 */

/* ③ ndo_stop() 또는 링크 다운/리셋 시 */
netdev_tx_reset_queue(txq);
/*  모든 BQL 카운터 초기화 (num_queued, num_completed 등)
 *  인터페이스 down → up 사이클에서 반드시 호출
 *  빠뜨리면 stale 카운터로 큐가 영구 정지될 수 있음 */

sysfs 인터페이스와 튜닝

각 TX 큐의 BQL 파라미터는 /sys/class/net/<dev>/queues/tx-<N>/byte_queue_limits/ 경로에 노출됩니다. 운영 환경에서 BQL 동작을 관찰하고 미세 조정할 수 있는 핵심 인터페이스입니다.

# BQL sysfs 파일 확인 (예: eth0의 tx-0 큐)
ls /sys/class/net/eth0/queues/tx-0/byte_queue_limits/
# 출력: hold_time  inflight  limit  limit_max  limit_min

# 현재 동적 LIMIT 확인 (알고리즘이 결정한 값)
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit

# inflight 바이트 확인 (현재 NIC에서 처리 중인 양)
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight

# LIMIT 상한 조정 (기본값: DQL_MAX_LIMIT = 매우 큰 값)
# 지연에 민감한 워크로드에서 상한을 낮추면 지연이 더 줄어들 수 있음
echo 30000 > /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max

# LIMIT 하한 조정 (기본값: 0)
# 너무 낮은 LIMIT으로 인한 성능 저하 방지
echo 1500 > /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min

# slack 관찰 윈도우 조정 (기본값: 1000 = HZ, 즉 1초)
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time

# 모든 큐의 BQL limit 한 번에 확인
for q in /sys/class/net/eth0/queues/tx-*/byte_queue_limits/limit; do
    echo "$(dirname $(dirname $q)): $(cat $q)"
done

BQL과 qdisc/TC의 상호작용

BQL은 qdisc 아래, NIC ring 위에 위치합니다. 패킷 흐름에서 BQL의 정확한 위치를 이해하면 fq_codel 같은 AQM(Active Queue Management)과의 시너지를 극대화할 수 있습니다.

실전 디버깅과 모니터링

BQL이 올바르게 동작하는지 확인하고, 문제 발생 시 원인을 추적하는 방법입니다.

# ── BQL 상태 종합 확인 ──
# 모든 TX 큐의 limit과 inflight를 한 번에 출력
for q in /sys/class/net/eth0/queues/tx-*/byte_queue_limits; do
    echo "=== $(basename $(dirname $q)) ==="
    echo "  limit:    $(cat $q/limit)"
    echo "  inflight: $(cat $q/inflight)"
    echo "  max:      $(cat $q/limit_max)"
    echo "  min:      $(cat $q/limit_min)"
done

# ── tc 통계와 BQL 연계 확인 ──
# qdisc의 backlog과 BQL의 inflight를 비교하여 병목 위치 판단
tc -s qdisc show dev eth0

# ── bpftrace로 BQL limit 변화 실시간 추적 ──
# dql_completed 호출 시 limit 값 변화를 추적
bpftrace -e 'kprobe:dql_completed {
    $dql = (struct dql *)arg0;
    printf("cpu=%d limit=%u completed=%u\n",
           cpu, $dql->limit, arg1);
}'

# ── perf로 BQL 관련 함수 호출 빈도 확인 ──
perf stat -e 'probe:dql_queued,probe:dql_completed' -a sleep 5

# ── 문제 진단 체크리스트 ──
# 1. limit이 0이면? → netdev_tx_reset_queue() 누락 가능
# 2. inflight가 limit과 같고 큐 정지? → 정상 (완료 대기 중)
# 3. limit이 limit_max에 고정? → 트래픽이 항상 LIMIT 소진 → limit_max 낮출 것
# 4. limit이 매우 작고 throughput 저하? → limit_min을 MTU 이상으로 설정

LLTX (NETIF_F_LLTX): lockless TX 계약과 실무 주의점

NETIF_F_LLTX는 TX 잠금을 네트워크 코어가 아닌 드라이버가 직접 책임지는 오래된 모델입니다. 즉, ndo_start_xmit() 동시 호출에 대한 직렬화/경합 제어를 드라이버가 스스로 보장해야 하며, 큐 stop/wake, timeout 복구, completion 경로까지 하나의 동시성 계약으로 맞춰야 합니다.

LLTX를 유지해야 하는 코드베이스라면 아래 4가지를 반드시 고정 규칙으로 문서화해야 합니다.

1. xmit 직렬화 규칙
   ndo_start_xmit()의 re-entry 허용 범위(전역/큐별)를 명시하고 락 순서를 고정
2. queue 상태 전이 규칙
   netif_tx_stop_queue()/netif_tx_wake_queue() 호출 조건을 단일 함수로 중앙화
3. completion 메모리 순서
   descriptor reclaim 이후 wake 판단 전까지의 barrier 규칙을 아키텍처별로 검증
4. timeout 복구 규칙
   ndo_tx_timeout()에서 즉시 리셋하지 말고 workqueue로 이관해 중복 reset 방지

/* LLTX 유지보수 시 권장되는 최소 패턴 (개념 예시) */
static netdev_tx_t my_lltx_xmit(struct sk_buff *skb, struct net_device *ndev)
{
    struct my_priv *priv = netdev_priv(ndev);
    unsigned long flags;

    /* LLTX에서는 드라이버가 자체 직렬화를 반드시 보장 */
    spin_lock_irqsave(&priv->tx_lock, flags);

    if (!my_has_room(priv)) {
        my_stop_txq_if_needed(priv);
        spin_unlock_irqrestore(&priv->tx_lock, flags);
        return NETDEV_TX_BUSY;
    }

    my_post_desc(priv, skb);
    my_kick_doorbell(priv);
    spin_unlock_irqrestore(&priv->tx_lock, flags);
    return NETDEV_TX_OK;
}

통계와 ethtool 연동

운영 환경에서는 “성능이 안 나온다”보다 “왜 안 나오는가”를 보여주는 통계가 더 중요합니다. ethtool -S로 확인 가능한 드라이버 통계를 설계하면 장애 분석 시간이 크게 줄어듭니다.

/* 개념 예시: ethtool 통계 구조와 per-CPU 집계 */
struct my_pcpu_stats {
    u64 rx_packets;
    u64 rx_bytes;
    u64 tx_packets;
    u64 tx_bytes;
    struct u64_stats_sync syncp;
};

static void my_ndo_get_stats64(struct net_device *ndev,
                               struct rtnl_link_stats64 *stats)
{
    int cpu;

    for_each_possible_cpu(cpu) {
        struct my_pcpu_stats *pcpu = per_cpu_ptr(my_stats, cpu);
        u64 rx_pkts, rx_bytes, tx_pkts, tx_bytes;
        unsigned int start;

        do {
            start = u64_stats_fetch_begin(&pcpu->syncp);
            rx_pkts = pcpu->rx_packets;
            rx_bytes = pcpu->rx_bytes;
            tx_pkts = pcpu->tx_packets;
            tx_bytes = pcpu->tx_bytes;
        } while (u64_stats_fetch_retry(&pcpu->syncp, start));

        stats->rx_packets += rx_pkts;
        stats->rx_bytes += rx_bytes;
        stats->tx_packets += tx_pkts;
        stats->tx_bytes += tx_bytes;
    }
}

링크 계층: PHY, phylib, phylink

현대 NIC/MAC 드라이버는 PHY 연결을 phylink로 통합하는 추세입니다. SFP, fixed-link, in-band status를 동시에 다뤄야 하는 경우 phylink가 사실상 표준입니다.

/* 개념 예시: phylink 초기화와 플랫폼별 연결 분기 */
static const struct phylink_mac_ops my_phylink_ops = {
    .mac_config = my_mac_config,
    .mac_link_up = my_mac_link_up,
    .mac_link_down = my_mac_link_down,
};

static int my_phylink_init(struct my_priv *priv)
{
    struct phylink_config *cfg = &priv->phylink_config;
    struct fwnode_handle *fwnode = dev_fwnode(priv->dev);
    phy_interface_t iface = priv->phy_mode; /* DT/ACPI 설정에서 파생 */

    priv->phylink = phylink_create(cfg, fwnode, iface,
                                 &my_phylink_ops);
    if (IS_ERR(priv->phylink))
        return PTR_ERR(priv->phylink);

    /* 펌웨어 타입(OF/fwnode)에 맞는 connect 경로를 선택 */
    if (is_of_node(fwnode))
        return phylink_of_phy_connect(priv->phylink, to_of_node(fwnode), 0);
    return phylink_fwnode_phy_connect(priv->phylink, fwnode, 0);
}

XDP, AF_XDP, 드라이버 오프로드

XDP 지원 드라이버는 RX hot path 초기에 프로그램을 실행해 drop/redirect를 빠르게 처리합니다. ndo_bpf, zero-copy AF_XDP, page_pool의 조합이 고성능 경로의 핵심입니다.

/* 개념 예시: XDP action 분기와 프레임 반환 계약 */
static int my_xdp_run(struct my_priv *priv, struct xdp_buff *xdp)
{
    u32 act;

    act = bpf_prog_run_xdp(rcu_dereference(priv->xdp_prog), xdp);

    switch (act) {
    case XDP_PASS:
        return XDP_PASS;
    case XDP_DROP:
        xdp_return_frame_rx_napi(xdp);
        return XDP_DROP;
    case XDP_TX:
        my_xdp_xmit(priv, xdp);
        return XDP_TX;
    default:
        xdp_return_frame_rx_napi(xdp);
        return XDP_ABORTED;
    }
}

멀티큐, RSS, IRQ affinity 설계

10/25/100GbE 구간에서는 단일 큐 모델이 거의 항상 병목입니다. 드라이버는 RX/TX 큐, MSI-X vector, NAPI 인스턴스를 1:1 또는 N:1로 설계하고, NUMA/CPU 토폴로지에 맞춰 IRQ affinity를 배치해야 합니다.

/* 개념 예시: 멀티큐 qvec와 MSI-X 벡터 매핑 */
struct my_qvec {
    struct napi_struct napi;
    int qid;
    int irq;
};

static int my_alloc_qvecs(struct my_priv *priv, int num_q)
{
    int i;

    for (i = 0; i < num_q; i++) {
        struct my_qvec *qv = &priv->qvec[i];

        qv->qid = i;
        netif_napi_add(priv->ndev, &qv->napi, my_qvec_poll);
        my_request_msix_vector(priv, i, &qv->irq, my_msix_irq_handler);
    }

    return 0;
}

RX 메모리 경로: page_pool과 DMA recycling

고속 수신 경로에서 alloc_pages()/dma_map를 패킷마다 반복하면 CPU 비용이 폭증합니다. page_pool 기반 재사용은 대부분의 고성능 NIC 드라이버에서 사실상 표준 패턴입니다.

/* 개념 예시: page_pool 기반 RX 메모리 재사용 */
static int my_rx_pool_init(struct my_priv *priv)
{
    struct page_pool_params pp = {
        .flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
        .order = 0,
        .pool_size = 4096,
        .nid = dev_to_node(priv->dev),
        .dev = priv->dev,
        .dma_dir = DMA_FROM_DEVICE,
    };

    priv->rx_pp = page_pool_create(&pp);
    if (IS_ERR(priv->rx_pp))
        return PTR_ERR(priv->rx_pp);

    return 0;
}

static void my_rx_recycle_page(struct my_priv *priv, struct page *page)
{
    page_pool_recycle_direct(priv->rx_pp, page);
}

제어 경로: RTNL, RTNETLINK, feature 토글

데이터 경로가 빠르더라도 제어 경로가 불안정하면 운영 장애가 반복됩니다. MTU 변경, queue 개수 변경, 링크 down/up, offload 토글은 모두 RTNL 보호 하에서 일관되게 처리해야 합니다.

/* 개념 예시: MTU 변경 시 stop/open 오류 경로 보강 */
static int my_ndo_change_mtu(struct net_device *ndev, int new_mtu)
{
    int ret;
    int old_mtu = ndev->mtu;

    if (new_mtu < 68 || new_mtu > 9700)
        return -EINVAL;

    if (netif_running(ndev)) {
        ret = my_ndo_stop(ndev);
        if (ret)
            return ret;

        ndev->mtu = new_mtu;
        ret = my_ndo_open(ndev);
        if (ret) {
            ndev->mtu = old_mtu;
            return ret;
        }
        return 0;
    }

    ndev->mtu = new_mtu;
    return 0;
}

static int my_ndo_set_features(struct net_device *ndev, netdev_features_t features)
{
    netdev_features_t changed = ndev->features ^ features;

    if (changed & NETIF_F_TSO)
        my_hw_toggle_tso(ndev, !!(features & NETIF_F_TSO));
    if (changed & NETIF_F_GRO)
        my_hw_toggle_gro(ndev, !!(features & NETIF_F_GRO));

    return 0;
}

TC/NFT 오프로드와 switchdev 연계

데이터센터 NIC는 tc flower 규칙을 하드웨어 테이블로 오프로드해 CPU 부하를 낮춥니다. 이때 드라이버는 수용 가능한 매치/액션 집합을 명확히 제한하고, 부분 실패 시 fallback 정책을 분명히 해야 합니다.

/* 개념 예시: TC setup type별 오프로드 분기 */
static int my_ndo_setup_tc(struct net_device *ndev, enum tc_setup_type type, void *type_data)
{
    switch (type) {
    case TC_SETUP_BLOCK:
        return my_tc_block_cb_setup(ndev, type_data);
    case TC_SETUP_QDISC_MQPRIO:
        return my_mqprio_setup(ndev, type_data);
    default:
        return -EOPNOTSUPP;
    }
}

리셋/장애 복구: devlink health와 watchdog

실서비스에서는 드라이버의 평균 성능보다 복구 전략이 더 중요합니다. TX timeout, 펌웨어 hang, PCI AER 오류에서 자동 복구가 되지 않으면 장기 장애로 이어집니다.

/* 개념 예시: tx_timeout 복구를 workqueue로 분리 */
static void my_tx_timeout(struct net_device *ndev, unsigned int txqueue)
{
    struct my_priv *priv = netdev_priv(ndev);

    netdev_warn(ndev, "tx timeout on queue %u\\n", txqueue);
    schedule_work(&priv->reset_work);
}

static void my_reset_work(struct work_struct *work)
{
    struct my_priv *priv = container_of(work, struct my_priv, reset_work);

    rtnl_lock();
    my_ndo_stop(priv->ndev);
    my_hw_function_reset(priv);
    my_ndo_open(priv->ndev);
    rtnl_unlock();
}

• watchdog: ndo_tx_timeout()에서 즉시 heavy reset을 수행하지 말고 workqueue로 이관
• devlink health: reporter dump/recover 콜백으로 운영팀의 장애 자동화와 연동
• AER 연계: PCIe fatal/non-fatal 이벤트를 reset state machine과 통합

오프로드 계약: checksum/GSO/GRO/VLAN

오프로드 기능은 “켜고 끄는 옵션”이 아니라 드라이버와 스택 사이의 계약입니다. advertise한 기능을 데이터 경로에서 일관되게 지키지 않으면 패킷 손실, checksum 오류, MTU 이상 동작이 발생합니다.

/* 개념 예시: feature dependency를 fix_features에서 강제 */
static netdev_features_t my_ndo_fix_features(struct net_device *ndev,
                                       netdev_features_t features)
{
    /* HW가 IPv6 TSO를 지원하지 않으면 강제 비활성화 */
    if (!(features & NETIF_F_IP_CSUM))
        features &= ~NETIF_F_TSO;

    if (!my_hw_supports_tso6(ndev))
        features &= ~NETIF_F_TSO6;

    return features;
}

static netdev_features_t my_ndo_features_check(struct sk_buff *skb,
                                            struct net_device *ndev,
                                            netdev_features_t features)
{
    /* 헤더 길이/세그먼트 조건 미충족 시 SW fallback */
    if (skb_is_gso(skb) && skb_shinfo(skb)->gso_segs > 512)
        features &= ~(NETIF_F_GSO_MASK);

    return features;
}

PTP 하드웨어 타임스탬프와 시간 동기화

금융/통신/분산 DB 워크로드에서는 네트워크 성능만큼 시간 정확도가 중요합니다. PTP 지원 NIC 드라이버는 SIOCSHWTSTAMP 설정, TX timestamp completion, PHC 노출을 안정적으로 제공해야 합니다.

/* 개념 예시: HW timestamp 사용자 요청 검증 */
static int my_hwtstamp_set(struct net_device *ndev, struct ifreq *ifr)
{
    struct hwtstamp_config cfg;

    if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
        return -EFAULT;

    if (cfg.tx_type != HWTSTAMP_TX_OFF && cfg.tx_type != HWTSTAMP_TX_ON)
        return -ERANGE;

    my_hw_config_timestamp(ndev, &cfg);

    if (copy_to_user(ifr->ifr_data, &cfg, sizeof(cfg)))
        return -EFAULT;

    return 0;
}

• PHC: /dev/ptpN 제공과 ptp4l/phc2sys 연동 검증
• TX timestamp: skb 소유권과 timestamp completion 경합 방지
• RX filter: 지원 가능한 timestamp filter를 정확히 반환

SR-IOV, representor, 스위치 모드 전환

클라우드 환경에서는 PF/VF 분리와 representor netdev 운영이 기본입니다. 드라이버는 legacy 모드와 switchdev 모드 전환 시 control-plane 일관성을 보장해야 합니다.

/* 개념 예시: eswitch 모드 전환과 대표자 netdev 동기화 */
static int my_eswitch_mode_set(struct my_priv *priv, u16 mode)
{
    if (mode == DEVLINK_ESWITCH_MODE_SWITCHDEV)
        return my_enable_representors(priv);
    if (mode == DEVLINK_ESWITCH_MODE_LEGACY)
        return my_disable_representors(priv);

    return -EOPNOTSUPP;
}

검증 매트릭스: 릴리스 전 체크 항목

TX 큐 선택: ndo_select_queue, XPS, CPU locality

멀티큐 NIC에서 ndo_start_xmit() 성능은 큐 선택 품질에 크게 좌우됩니다. 플로우 해시, CPU affinity, XPS 정책이 맞지 않으면 lock 경합과 cache miss가 급증합니다.

/* 개념 예시: qdisc/XPS 힌트를 반영한 TX queue 선택 */
static u16 my_ndo_select_queue(struct net_device *dev, struct sk_buff *skb,
                               struct net_device *sb_dev)
{
    u32 hash = skb_get_hash(skb);
    u16 q = reciprocal_scale(hash, dev->real_num_tx_queues);

    /* 로컬 CPU 우선 정책이 있으면 q를 재매핑 */
    q = my_xps_remap(dev, q, raw_smp_processor_id());
    return q;
}

• XPS: /sys/class/net/<dev>/queues/tx-*/xps_cpus와 드라이버 큐 매핑 일치
• RFS/RPS와 충돌 회피: RX CPU와 TX completion CPU가 지나치게 분산되지 않도록 설계
• NUMA: queue memory, IRQ, NAPI poll CPU를 같은 노드로 묶어 캐시 효율 확보

Doorbell 메커니즘과 DMA 메모리 배리어

약한 메모리 모델 CPU(ARM64 등)에서 descriptor write와 doorbell MMIO write의 순서가 보장되지 않으면 간헐적 TX hang이 생깁니다. 게시 경로에서 barrier 사용 규칙을 문서화해야 합니다.

Doorbell이란?

Doorbell은 PCIe BAR 공간의 장치 레지스터에 MMIO write를 수행하여 NIC에 새 작업(디스크립터)이 준비되었음을 알리는 메커니즘입니다. Doorbell이 없으면 NIC이 링 버퍼를 지속적으로 폴링해야 하며, 이는 PCIe 대역폭 낭비와 전력 소모 증가를 초래합니다.

Doorbell의 핵심 속성은 다음과 같습니다.

• 단일 원자적 MMIO write: 일반적으로 4바이트(32비트) 크기이며, CPU의 단일 스토어 명령으로 실행됩니다.
• PCIe 트랜잭션 비용: doorbell 1회당 수백 나노초(200~500 ns)가 소요되며, PCIe TLP(Transaction Layer Packet) 오버헤드를 포함합니다.
• 메모리 배리어 선행 필수: doorbell 이전에 반드시 적절한 메모리 배리어(dma_wmb())가 선행되어야 디바이스가 완전한 디스크립터를 읽을 수 있습니다.

서브시스템별 Doorbell 비교

Doorbell 메커니즘은 NIC뿐 아니라 다양한 PCIe 디바이스 서브시스템에서 사용됩니다. 아래 표는 주요 서브시스템별 doorbell 특성을 비교합니다.

Doorbell 최적화 기법

Doorbell은 PCIe MMIO 트랜잭션이므로 호출 빈도를 줄이는 것이 성능 최적화의 핵심입니다. 주요 기법은 다음과 같습니다.

• 배치 게시(Batch Posting): 여러 디스크립터를 작성한 후 doorbell을 1회만 수행합니다. NVMe의 commit_rqs 콜백이 대표적인 패턴으로, 다수의 SQ entry를 기록한 뒤 마지막에 한 번만 tail doorbell을 갱신합니다. NIC 드라이버에서도 xmit_more 플래그를 확인하여 배치 doorbell을 구현할 수 있습니다.
• Shadow Doorbell: MMIO 대신 호스트 메모리 영역에 tail 값을 기록하고, 디바이스가 해당 메모리를 폴링하는 방식입니다. NVMe 1.3+ 스펙의 Shadow Doorbell Buffer가 대표적이며, PCIe MMIO 왕복 비용을 제거하여 수십 퍼센트의 IOPS 향상을 달성할 수 있습니다.
• Write Combining: doorbell 레지스터가 위치한 PCIe BAR 페이지를 WC(Write Combining) 매핑하여, 여러 doorbell write가 단일 PCIe 트랜잭션으로 합쳐지도록 합니다. 이를 통해 PCIe TLP 오버헤드를 줄이고 대역폭 효율을 향상시킵니다.

/* 개념 예시: doorbell 전 메모리 배리어 보장 */
static void my_post_tx_desc(struct my_priv *priv, struct my_desc *d)
{
    priv->tx_ring[d->idx] = *d;

    /* descriptor 메모리 write 완료 보장 */
    dma_wmb();

    /* 이후 doorbell write */
    writel(d->idx, priv->tx_doorbell);
}

Busy Poll/NAPI 조합과 지연 최적화

초저지연 워크로드에서는 interrupt moderation보다 busy-poll이 유리할 수 있습니다. 드라이버는 NAPI 상태 전이를 안정적으로 유지해 busy-poll 사용자와 일반 트래픽이 충돌하지 않게 해야 합니다.

# 실습 예제: busy poll 파라미터 조정 및 즉시 확인
# 소켓 단위 busy poll (마이크로초)
sysctl -w net.core.busy_poll=50
sysctl -w net.core.busy_read=50

# NIC interrupt moderation과 함께 튜닝
ethtool -C eth0 rx-usecs 0
ethtool -C eth0 tx-usecs 0

회귀 테스트: packetdrill, kselftest, fault injection

netdev 드라이버는 환경 의존성이 커서 재현 테스트가 어렵습니다. 릴리스 전에 최소 회귀 시나리오를 자동화하면 “간헐적 링크 다운” 같은 문제를 조기에 차단할 수 있습니다.

QoS/DCB: mqprio, ETS, PFC 운영 포인트

데이터센터 환경에서는 대역폭 분배와 무손실 트래픽 제어가 중요합니다. 드라이버가 mqprio, DCB, PFC를 부분 지원하는 경우 지원 범위를 명확히 노출해야 운영 오해를 줄일 수 있습니다.

# 실습 예제: mqprio/ethtool로 큐 정책 검증
# mqprio qdisc 예시 (TC별 큐 매핑)
tc qdisc replace dev eth0 root mqprio num_tc 4 \
  map 0 1 2 3 3 3 3 3 \
  queues 1@0 1@1 2@2 4@4 hw 1

# DCB/PFC 상태 확인 예시 (환경별 도구 상이)
dcbtool gc eth0 dcb
ethtool --show-priv-flags eth0

PREEMPT_RT와 NAPI threaded 모드

실시간 커널에서는 IRQ/softirq 모델이 일반 커널과 다르게 동작합니다. 드라이버는 spinlock 길이를 줄이고, napi poll 지연 상한을 보장하도록 설계해야 합니다.

• 긴 IRQ-off 구간 제거: TX reclaim 루프를 짧게 쪼개고 예산 기반 처리 유지
• 락 경쟁 최소화: 큐별 락 분리, 필요 시 lockless ring 고려
• 우선순위 설계: IRQ thread/NAPI 실행 CPU를 RT 태스크와 분리
• 지연 측정: cyclictest와 네트워크 부하를 동시 실행해 tail latency 확인

Netpoll/kdump 경로 지원

패닉 상황에서 네트워크 로그 덤프가 필요하면 netpoll/netconsole 경로가 사용됩니다. 일반 데이터 경로와 독립된 최소 송신 경로를 유지해야 crash dump 신뢰성이 올라갑니다.

/* 개념 예시: netpoll 경로의 재진입/잠금 제약 */
static void my_netpoll_send_skb(struct net_device *ndev, struct sk_buff *skb)
{
    struct my_priv *priv = netdev_priv(ndev);

    /* 최소 TX 경로: sleep 금지, 동적 메모리 할당 최소화 */
    if (!my_tx_ring_has_space(priv)) {
        dev_kfree_skb_any(skb);
        return;
    }
    my_map_skb_to_tx_desc(priv, skb);
    my_ring_doorbell(priv);
}

보안 하드닝: 입력 검증과 경계 조건

네트워크 드라이버 취약점은 원격 트리거 가능성이 있습니다. 길이 검증, ring index 범위 확인, DMA 주소 검증은 성능 최적화보다 우선되어야 합니다.

가상 netdev: TUN/TAP, veth, virtio-net

가상 인터페이스도 본질적으로는 net_device입니다. 차이는 “패킷을 어디로 내보내는가”에 있습니다. 물리 NIC는 DMA 링으로, TUN/TAP은 파일 디스크립터로, veth는 peer netdev로 전달합니다.

/* 개념 예시: drivers/net/tun.c 핵심 경로 요약 */
static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
{
    struct tun_struct *tun = netdev_priv(dev);

    if (!ptr_ring_produce(&tun->tx_ring, skb))
        return NETDEV_TX_OK;

    /* 유저스페이스가 fd read()로 수신 */
    dev_kfree_skb_any(skb);
    return NETDEV_TX_OK;
}

동기화, RTNL, 메모리 모델

netdev 코드의 동기화는 단일 락으로 끝나지 않습니다. 설정 경로는 RTNL, 데이터 경로는 per-queue spinlock/NAPI, 통계 경로는 u64_stats_sync를 조합합니다.

• RTNL 보호 영역: 장치 등록/이름 변경/링크 설정 같은 제어 경로
• NAPI 컨텍스트: RX poll은 softirq 문맥에서 동작
• TX 락: 멀티큐에서 queue별 락 또는 lockless ring 설계
• RCU: XDP program pointer, filter table 조회 경로
• 메모리 배리어: descriptor 게시 전 doorbell write ordering 보장

디버깅 체크리스트와 실전 트러블슈팅

# 실습 예제: 큐/오프로드/통계 빠른 점검
# 큐/오프로드/통계 빠른 점검
ethtool -i eth0
ethtool -k eth0
ethtool -l eth0
ethtool -S eth0 | grep -E "drop|error|timeout|busy"

# 소프트넷 병목 확인
cat /proc/net/softnet_stat

# netdev 관련 tracepoint 예시
trace-cmd record -e net -e napi -e skb

운영 관측: 필수 대시보드 지표

드라이버 품질은 장애가 났을 때 “원인을 빠르게 찾을 수 있는가”로 평가됩니다. 아래 지표를 대시보드로 상시 수집하면 회귀를 조기에 감지할 수 있습니다.

Bring-up 30분 체크리스트

1. 장치 인식 확인
   lspci -nn, dmesg | grep -i <driver>로 probe 성공 여부 확인
2. 링크 기본 동작
   ip link set dev eth0 up, ethtool eth0로 speed/duplex/link 검증
3. 기본 송수신
   ping, 단일 iperf3로 RX/TX 모두 정상 동작 확인
4. 오프로드/큐 설정
   ethtool -k/-l/-x 확인 후 장비 정책에 맞게 조정
5. 에러 카운터 스냅샷
   ethtool -S eth0 초기값 저장, 10분 부하 후 증분 비교
6. 리셋 복구
   의도적 link flap 또는 함수 리셋 후 자동 복구 성공 여부 확인
7. 관측/알람 연계
   링크/에러/reset 지표가 모니터링 시스템에 수집되는지 검증

코드 리뷰 체크리스트 (net_device 전용)

• 수명주기: register_netdev() 이후/이전 해제 순서가 정확한가
• NAPI: poll budget 준수, complete/unmask 순서가 안전한가
• TX 계약: queue stop/wake, NETDEV_TX_BUSY 반환 조건이 일관적인가
• 동기화: RTNL, spinlock, RCU 경계가 명확하고 lock inversion 위험이 없는가
• 오프로드: advertise feature와 실제 HW 동작이 일치하는가
• 에러 경로: DMA map 실패, IRQ 요청 실패, reset 실패 시 자원 정리가 누락되지 않는가
• 텔레메트리: 장애 분석에 필요한 통계/로그/devlink dump가 충분한가

제조사별 NIC 드라이버 상세 매트릭스

같은 net_device 모델이라도 벤더별로 펌웨어 의존성, 오프로드 범위, reset 전략이 다릅니다. 운영 환경에서는 “벤더별 특성”을 분리해서 튜닝/장애 대응해야 재현성이 올라갑니다.

Intel: e1000e / igb / ixgbe / i40e / ice / idpf

Intel은 리눅스 네트워크 드라이버 생태계에서 가장 오랜 역사와 가장 넓은 드라이버 포트폴리오를 보유하고 있습니다. 1GbE 데스크톱용 e1000e부터 100GbE 데이터센터용 ice, 그리고 차세대 가상화 인터페이스 idpf까지 세대별 설계 철학이 뚜렷하게 달라집니다. 각 드라이버의 아키텍처 차이를 이해하면 성능 튜닝과 장애 진단 전략을 드라이버 세대에 맞춰 정확히 수립할 수 있습니다.

# 실습 예제: Intel 계열 NIC 운영 점검 루틴
# Intel 계열 공통 점검
ethtool -i eth0
ethtool -S eth0 | grep -Ei "fdir|tx_timeout|rx_missed|reset"
dmesg | grep -Ei "ixgbe|i40e|ice|idpf|firmware|ddp"

# 드라이버별 모듈 파라미터 확인
modinfo e1000e | grep parm
modinfo ice | grep parm

e1000e: 싱글 큐 레거시 아키텍처

e1000e는 Intel PRO/1000 계열 PCIe GbE 컨트롤러를 위한 드라이버로, 싱글 TX/RX 큐 모델을 채택합니다. 멀티큐를 지원하지 않기 때문에 RSS, 큐별 NAPI 분리, XDP 등 최신 데이터 경로 최적화를 적용할 수 없지만, 단순한 구조 덕분에 안정성이 매우 높아 서버 관리 인터페이스(BMC/IPMI 전용 포트)와 임베디드 환경에서 여전히 널리 사용됩니다.

e1000e가 지원하는 주요 칩 변형은 다음과 같습니다. 세대별로 전력 관리와 부가 기능에 차이가 있으며, 특히 I219는 Intel vPro 플랫폼의 AMT(Active Management Technology) 트래픽을 처리하는 ME(Management Engine) 연동 경로가 있어 드라이버 동작이 미묘하게 다릅니다.

# 실습 예제: e1000e 진단 및 전력 관리
# 드라이버/칩 정보 확인
ethtool -i eth0
# 출력 예: driver: e1000e, firmware-version: 0.13-4, bus-info: 0000:00:1f.6

# EEE 상태 확인 및 비활성화 (링크 flap 방지)
ethtool --show-eee eth0
ethtool --set-eee eth0 eee off

# WoL 설정 확인 및 활성화
ethtool -s eth0 wol g
ethtool -s eth0 wol d   # WoL 비활성화

# 셀프 테스트 (offline 모드: 링크 일시 단절)
ethtool -t eth0 offline

# 링크 flap 이력 확인
dmesg | grep -i "e1000e.*link\|e1000e.*changed"
ethtool -S eth0 | grep -E "rx_no_buffer|tx_timeout|rx_crc_errors"

igb: 멀티큐 RSS 모델

igb는 Intel I350, I210, I211 계열 GbE 컨트롤러를 지원하며, e1000e와 달리 멀티큐 RSS(Receive Side Scaling)를 기본 지원합니다. 서버급 환경에서 1GbE 인터페이스를 고밀도로 운영하거나, PTP(Precision Time Protocol) 하드웨어 타임스탬프가 필요한 경우 igb가 권장됩니다.

# 실습 예제: igb RSS 및 PTP 설정
# RSS 큐 수 확인 및 변경
ethtool -l eth0
ethtool -L eth0 combined 4

# RSS indirection table 확인
ethtool -x eth0
# indirection table을 큐 0,1에만 집중
ethtool -X eth0 equal 2

# RSS 해시 키 확인
ethtool -x eth0 | head -5

# SR-IOV VF 생성 (I350 전용)
echo 4 > /sys/class/net/eth0/device/sriov_numvfs
ip link show eth0

# PTP 하드웨어 타임스탬프 설정 (I210)
ethtool -T eth0
# ptp4l로 PTP 동기화 실행
ptp4l -i eth0 -m -H
# phc2sys로 시스템 클록 동기화
phc2sys -s eth0 -c CLOCK_REALTIME -O 0 -m

# IRQ affinity 확인
grep eth0 /proc/interrupts
cat /proc/irq/*/smp_affinity_list | head -8

ixgbe: 10GbE 고성능 아키텍처

ixgbe는 Intel 82599, X540, X550 시리즈 10GbE 컨트롤러를 지원하며, Linux 10GbE 시장에서 가장 오래 검증된 드라이버입니다. 128개 TX/RX 큐, Flow Director, DCB(Data Center Bridging), SR-IOV(최대 64 VF) 등 데이터센터급 기능을 폭넓게 제공합니다.

# 실습 예제: ixgbe 성능 튜닝 및 Flow Director
# 큐/링 설정 확인
ethtool -l eth0          # 큐 수 확인
ethtool -g eth0          # 링 크기 확인
ethtool -G eth0 rx 4096 tx 4096  # 링 크기 증가

# Flow Director ATR 활성화 확인
ethtool -k eth0 | grep ntuple
ethtool -K eth0 ntuple on

# Perfect Filter 규칙 추가
ethtool -N eth0 flow-type tcp4 src-ip 10.0.0.1 dst-port 443 action 0
ethtool -N eth0 flow-type udp4 dst-port 4789 action 4  # VXLAN

# 활성 FDIR 규칙 및 통계
ethtool -n eth0
ethtool -S eth0 | grep fdir

# DCB/PFC 설정 (lldptool 사용)
lldptool -T -i eth0 -V PFC enableTx=yes
lldptool -T -i eth0 -V ETS-CFG willing=no \
  up2tc=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 \
  tsa=0:ets,1:ets,2:ets,3:ets,4:ets,5:ets,6:ets,7:ets \
  tcbw=12,12,12,12,13,13,13,13

# XDP 프로그램 로딩
ip link set dev eth0 xdpdrv obj xdp_prog.o sec xdp

# IRQ affinity 최적화 (CPU당 큐 1:1 매핑)
# Intel 제공 set_irq_affinity 스크립트 사용
./set_irq_affinity.sh local eth0

# 성능 모니터링
ethtool -S eth0 | grep -E "rx_bytes|tx_bytes|rx_packets|tx_packets"
ethtool -S eth0 | grep -E "tx_timeout|rx_missed|fdir"

i40e: AdminQ 기반 제어 경로

i40e는 Intel XL710/X710/XXV710 시리즈(10/25/40GbE)를 지원하며, 이전 세대(ixgbe)와 근본적으로 다른 AdminQ(Admin Queue) 기반 펌웨어 제어 모델을 도입했습니다. 드라이버가 하드웨어 레지스터를 직접 조작하는 대신, AdminQ 메시지를 통해 펌웨어에 명령을 전달하는 구조입니다. 이 설계는 SR-IOV VF 관리에서 virtchnl 프로토콜로 확장되어, PF 드라이버가 VF의 리소스 요청을 중재합니다.

# 실습 예제: i40e AdminQ 및 VF 관리
# 펌웨어 버전 확인
ethtool -i eth0
devlink dev info pci/0000:03:00.0

# AdminQ 이벤트 로그 확인
dmesg | grep -i "i40e.*adminq\|i40e.*aq\|i40e.*fw"

# VF 생성 및 관리
echo 8 > /sys/class/net/eth0/device/sriov_numvfs
ip link set eth0 vf 0 mac 00:11:22:33:44:55
ip link set eth0 vf 0 vlan 100
ip link set eth0 vf 0 trust on
ip link set eth0 vf 0 rate 1000   # TX rate 제한 (Mbps)

# ADQ (Application Device Queue) 설정
# TC 4개 생성, 각각 큐 4개 할당
tc qdisc add dev eth0 root mqprio num_tc 4 \
  map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 \
  queues 4@0 4@4 4@8 4@12 hw 1 mode channel

# VF 통계 모니터링
ethtool -S eth0 | grep "vf_"
ip -s link show eth0

idpf: virtchnl2 기반 차세대 인프라 드라이버

idpf(Infrastructure Data Path Function)는 Intel의 차세대 네트워크 드라이버로, 하드웨어 추상화를 극대화한 virtchnl2 프로토콜 기반 설계입니다. 기존 iavf 드라이버가 특정 세대의 PF(i40e/ice)에 종속적이었던 것과 달리, idpf는 Control Plane(CP)과 Data Plane을 완전히 분리하여 모든 세대의 Intel NIC에 대한 통합 VF/인프라 드라이버 역할을 목표로 합니다.

# 실습 예제: idpf 드라이버 확인 및 큐 모델 점검
# idpf 드라이버 로딩 확인
lsmod | grep idpf
ethtool -i eth1    # driver: idpf 확인

# virtchnl2 capability 협상 결과 확인
dmesg | grep -i "idpf.*cap\|idpf.*queue\|idpf.*split"

# 큐 설정 확인 (Split Queue 모델 여부)
ethtool -l eth1
ethtool -S eth1 | grep -E "tx_q|rx_q|comp_q|buf_q"

# 큐 수 변경
ethtool -L eth1 combined 8

# CP(Control Plane) 연결 상태 확인
dmesg | grep -i "idpf.*mailbox\|idpf.*cp\|idpf.*control"

# 기본 통계 확인
ethtool -S eth1 | head -30
ip -s link show eth1

ICE vs i40e: 아키텍처 진화

ICE(E810)는 i40e(XL710/X710)의 후속 세대로, AdminQ 기반 펌웨어 제어 모델을 계승하면서도 DDP 필수화, devlink 완전 통합, eswitch/representor 모델, 하드웨어 PTP 타임스탬프 등 근본적인 아키텍처 확장을 도입했습니다. 특히 DDP가 패킷 파서를 런타임에 재프로그래밍하는 모델은 i40e에서는 선택적이었지만, ICE에서는 정상 동작의 전제 조건이 되었습니다.

ICE eswitch: Representor 모델과 Switchdev

ICE E810은 eswitch(Embedded Switch)를 통해 NIC 내부에 가상 스위치를 구성하고, 각 VF에 대응하는 representor netdev를 호스트에 노출합니다. 이 모델은 OVS(Open vSwitch) TC offload의 핵심 인프라이며, switchdev 모드로 전환하면 호스트의 TC subsystem이 NIC 하드웨어 필터 규칙을 직접 제어할 수 있습니다.

Representor 모델은 NIC 내부의 각 VF 포트에 대응하는 호스트 측 netdev(representor)를 생성합니다. OVS나 TC는 이 representor를 일반 netdev처럼 다루면서 스위칭 규칙을 설정하고, ICE 드라이버가 해당 규칙을 NIC 하드웨어에 오프로드합니다. Slow path(매칭 실패) 패킷은 representor를 통해 호스트 OVS로 올라와 소프트웨어 처리됩니다.

# 실습 예제: ICE eswitch switchdev 모드 설정
# 1. 현재 eswitch 모드 확인
devlink dev eswitch show pci/0000:af:00.0
# 출력: pci/0000:af:00.0: mode legacy

# 2. VF 생성
echo 4 > /sys/class/net/eth0/device/sriov_numvfs

# 3. switchdev 모드 전환
devlink dev eswitch set pci/0000:af:00.0 mode switchdev
# representor netdev 생성 확인
ip link show | grep "eth0_"

# 4. OVS 브리지에 representor 연결
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0_0   # VF0 representor
ovs-vsctl add-port br0 eth0_1   # VF1 representor
ovs-vsctl add-port br0 enp1s0f0 # Uplink representor

# 5. TC flower 규칙 추가 (HW 오프로드)
# VF0 → VF1 MAC 기반 포워딩
tc filter add dev eth0_0 ingress protocol ip \
  flower dst_mac aa:bb:cc:dd:ee:01 \
  action mirred egress redirect dev eth0_1

# 6. HW 오프로드 상태 확인
tc -s filter show dev eth0_0 ingress
# "in_hw" 플래그가 있으면 HW 오프로드 성공

# 7. eswitch 통계 확인
ethtool -S eth0 | grep "tx_repr\|rx_repr"
devlink dev eswitch show pci/0000:af:00.0

# 8. legacy 모드로 복원
ovs-vsctl del-br br0
devlink dev eswitch set pci/0000:af:00.0 mode legacy

eswitch switchdev 모드에서 지원하는 주요 tc flower 매칭 필드와 액션은 다음과 같습니다.

# 실습 예제: eswitch tc flower 고급 규칙
# VXLAN 터널 패킷을 VF0으로 스티어링
tc filter add dev enp1s0f0 ingress protocol ip \
  flower enc_dst_ip 10.0.0.1 enc_key_id 100 enc_dst_port 4789 \
  action tunnel_key unset \
  action mirred egress redirect dev eth0_0

# VF0 → 외부: VXLAN 캡슐화
tc filter add dev eth0_0 ingress protocol ip \
  flower src_mac aa:bb:cc:dd:ee:00 \
  action tunnel_key set id 100 src_ip 10.0.0.1 dst_ip 10.0.0.2 dst_port 4789 \
  action mirred egress redirect dev enp1s0f0

# VLAN 기반 트래픽 분리
tc filter add dev eth0_0 ingress protocol 802.1q \
  flower vlan_id 100 \
  action vlan pop \
  action mirred egress redirect dev eth0_1

# 오프로드된 규칙 수 확인
tc -s filter show dev eth0_0 ingress | grep "in_hw\|not_in_hw"
tc -s filter show dev enp1s0f0 ingress | grep "in_hw"

# devlink 포트 정보 확인
devlink port show pci/0000:af:00.0

# eswitch 장애 진단
devlink health show pci/0000:af:00.0
dmesg | grep -i "ice.*eswitch\|ice.*repr\|ice.*switchdev"

DDP 트러블슈팅 확장

ICE 드라이버가 DDP 패키지 로드에 실패하면 Safe Mode로 폴백하여 RSS, Flow Director, SR-IOV 고급 기능이 모두 비활성화된다. 주요 실패 원인과 해결 방법은 다음과 같다.

E810 SKU별 TCAM 진입 한계: E810-C(100GbE, dual-port)는 TCAM 진입을 E810-XXV(25GbE)보다 더 많이 지원한다. E810-C는 FD(Flow Director) 진입 최대 512개 기본 설정인 반면, E810-XXV는 256개로 제한될 수 있다. ethtool -n eth0 rx-flow-hash tcp4 및 ethtool --show-ntuple eth0으로 현재 사용 규칙 수와 최대 용량을 확인할 수 있다.

i40e AdminQ Timeout 복구

i40e 드라이버에서 AdminQ(Administration Queue) timeout은 PF와 펌웨어 간 명령 채널이 응답하지 않을 때 발생한다. 이 오류는 FW hang, PCI 전송 오류, 또는 과도한 AdminQ 명령 큐잉으로 발생한다.

AdminQ timeout 감지: i40e_aq_send_msg_to_vf가 I40E_AQ_RC_EAGAIN을 반환하거나 타임아웃 워크큐가 트리거되면 드라이버는 PF 리셋 시퀀스를 시작한다. PF 리셋이 완료되면 VF에게 VIRTCHNL_OP_RESET_VF 메시지를 전송하여 VF 드라이버(iavf)가 채널을 재설정하도록 지시한다.

# DDP 로드 상태 확인
dmesg | grep -E "ice.*ddp|ice.*package|ice.*safe mode"
ls -la /lib/firmware/intel/ice/ddp/

# AdminQ 오류 확인 (i40e)
dmesg | grep -E "i40e.*AdminQ|i40e.*AQ timeout|i40e.*reset"

# i40e 드라이버 통계에서 AdminQ 오류 카운터 확인
ethtool -S eth0 | grep -E "admin_queue|aq_"

# VF 리셋 이력 확인
dmesg | grep -E "iavf.*reset|i40e.*VF.*reset"

# i40e AdminQ 링 크기 조정 (모듈 파라미터)
modprobe i40e adminq_work_limit=64

# ice DDP 패키지 수동 지정
modprobe ice fw_name=intel/ice/ddp/ice-1.3.30.0.pkg

Intel 공통 성능 튜닝 체크리스트

Intel NIC 드라이버 세대와 관계없이 공통적으로 적용할 수 있는 성능 튜닝 포인트를 정리합니다. 특히 10GbE 이상의 고대역폭 환경에서는 커널 파라미터, IRQ affinity, 링 버퍼 크기 등을 체계적으로 점검해야 합니다.

# Intel NIC 공통 성능 튜닝 스크립트
IFACE=eth0

# 링 버퍼 최대화
ethtool -G $IFACE rx 4096 tx 4096

# RSS 큐 수를 물리 코어 수에 맞춤
CORES=$(nproc --all)
ethtool -L $IFACE combined $CORES

# GRO, TSO, Checksum 오프로드 활성화 확인
ethtool -K $IFACE gro on tso on tx on rx on

# IRQ affinity 자동 설정 (irqbalance 대신 수동)
systemctl stop irqbalance
# Intel 제공 스크립트 또는 수동 설정
IRQS=$(grep $IFACE /proc/interrupts | awk '{print $1}' | tr -d ':')
CPU=0
for IRQ in $IRQS; do
  echo $CPU > /proc/irq/$IRQ/smp_affinity_list
  CPU=$((CPU + 1))
done

# XPS 설정 (TX 큐를 대응 CPU에 매핑)
for i in $(seq 0 $((CORES - 1))); do
  printf "%x" $((1 << i)) > /sys/class/net/$IFACE/queues/tx-$i/xps_cpus
done

# Busy Polling (저지연 환경)
sysctl -w net.core.busy_poll=50
sysctl -w net.core.busy_read=50

# NUMA 노드 확인 및 프로세스 고정
NUMA=$(cat /sys/class/net/$IFACE/device/numa_node)
echo "NIC NUMA node: $NUMA"
# numactl --cpunodebind=$NUMA --membind=$NUMA ./application

Intel NIC 드라이버 계열은 세대마다 설계 철학이 진화해 왔으며, 최신 커널에서는 ice + idpf 조합이 가장 포괄적인 기능 세트를 제공합니다. 기존 i40e/ixgbe 환경에서 업그레이드를 검토할 때는 DDP 패키지 배치, devlink 인프라 준비, SR-IOV VF 마이그레이션 계획을 사전에 수립하는 것이 중요합니다.

# Intel NIC 드라이버 세대별 빠른 점검 스크립트
# 시스템의 모든 Intel NIC 드라이버 요약
for dev in /sys/class/net/*/device/driver; do
  IFACE=$(echo "$dev" | cut -d'/' -f5)
  DRIVER=$(basename $(readlink "$dev"))
  case "$DRIVER" in
    e1000e|igb|ixgbe|i40e|ice|idpf|iavf)
      FW=$(ethtool -i "$IFACE" 2>/dev/null | grep firmware | awk '{print $2}')
      QUEUES=$(ethtool -l "$IFACE" 2>/dev/null | grep Combined | tail -1 | awk '{print $2}')
      echo "$IFACE: driver=$DRIVER fw=$FW queues=$QUEUES"
      ;;
  esac
done

# DDP 패키지 상태 확인 (ice 전용)
if lsmod | grep -q ice; then
  echo "=== ICE DDP Status ==="
  ls -la /lib/firmware/intel/ice/ddp/ 2>/dev/null
  dmesg | grep -i "ice.*ddp\|ice.*package" | tail -5
fi

# devlink 지원 드라이버 일괄 점검
devlink dev info 2>/dev/null | head -20

NVIDIA/Mellanox: mlx5e / mlx4_en

NVIDIA(구 Mellanox)의 ConnectX 시리즈는 데이터센터 네트워킹의 사실상 표준으로, 하드웨어 기반 RDMA, SR-IOV, 정밀 패킷 스티어링, XDP 제로카피 등 리눅스 커널의 최신 네트워킹 기능을 가장 적극적으로 지원하는 NIC 플랫폼이다. 커널 드라이버는 mlx5_core(통합 코어)와 mlx5e(이더넷), mlx5_ib(InfiniBand/RoCE) 모듈로 구성되며, 레거시 ConnectX-3 이하는 mlx4_core/mlx4_en으로 지원된다.

mlx5 하드웨어 및 소프트웨어 아키텍처

mlx5 드라이버는 ConnectX-4 이상의 하드웨어를 지원하는 통합 코어 드라이버 mlx5_core를 기반으로 한다. 하드웨어 내부는 패킷 수신/발신 경로를 세밀하게 제어할 수 있는 스티어링 엔진, 가상 포트(vPort), 작업 큐(WQ) 체계로 구성되며, 소프트웨어 스택은 이더넷·RDMA·vDPA 등 다양한 서브시스템을 단일 코어 위에서 분기한다.

ConnectX 시리즈의 하드웨어 블록 구조는 다음과 같다. 물리 포트에서 수신된 패킷은 스티어링 엔진(Flow Steering Engine)을 거쳐 가상 포트(vPort)별로 분류되고, 각 vPort에 연결된 작업 큐(WQ)의 수신 큐(RQ) 또는 송신 큐(SQ)로 전달된다. 완료 이벤트는 CQ(Completion Queue)를 통해 EQ(Event Queue)로 전파되며, 최종적으로 MSI-X 인터럽트가 호스트 CPU에 전달된다.

소프트웨어 스택은 mlx5_core가 HCA(Host Channel Adapter) 초기화, 커맨드 인터페이스, EQ/CQ 관리 등의 공통 기반을 제공하며, 그 위에 이더넷(mlx5e), InfiniBand/RoCE(mlx5_ib), vDPA(mlx5_vdpa) 서브시스템이 독립적으로 동작한다.

ConnectX 세대별 기능 진화는 다음 표와 같다. 각 세대는 대역폭뿐 아니라 하드웨어 오프로드 범위가 크게 확장되었다.

# mlx5 디바이스 정보 확인
lspci -d 15b3: -vvv | head -30
ethtool -i enp1s0f0np0

# mlx5 드라이버 로드 상태 및 파라미터 확인
modinfo mlx5_core
cat /sys/module/mlx5_core/parameters/prof_sel

# devlink 디바이스 정보
devlink dev show pci/0000:01:00.0
devlink dev info pci/0000:01:00.0

# HCA capabilities 확인 (디버깅용)
devlink dev param show pci/0000:01:00.0
rdma dev show mlx5_0

mlx5 Flow Steering 파이프라인

mlx5의 패킷 스티어링은 하드웨어 내장 Flow Table 계층 구조를 기반으로 동작한다. 세 가지 주요 도메인이 존재한다: NIC Flow Table(일반 NIC RX/TX 경로), FDB(Forwarding DataBase, eSwitch 경로), RDMA Flow Table(RDMA 트래픽 경로). 각 도메인 내에서 패킷은 우선순위 기반으로 Flow Table을 순차 탐색하며, 첫 번째 매칭 규칙의 액션이 수행된다.

NIC RX Flow Table은 일반적으로 다음 계층으로 구성된다: Bypass(tc flower offload 규칙) → Kernel(ethtool ntuple 등) → Leftovers(기본 RSS/steering). FDB는 eSwitch Switchdev 모드에서 활성화되며, VF/SF 간 패킷 전달과 OVS offload의 핵심이다.

TC flower offload는 mlx5에서 가장 강력한 스티어링 기능 중 하나다. tc flower 필터를 skip_sw 플래그와 함께 추가하면 하드웨어 Flow Table에 직접 규칙이 삽입되며, 소프트웨어 경로를 완전히 우회한다.

# TC flower offload: 특정 IP의 트래픽을 VF representor로 리다이렉트
tc qdisc add dev enp1s0f0np0 ingress
tc filter add dev enp1s0f0np0 ingress protocol ip \
    flower skip_sw \
    src_ip 10.0.0.0/24 \
    action mirred egress redirect dev enp1s0f0np0_0

# VXLAN encap offload
tc filter add dev enp1s0f0np0_0 egress protocol ip \
    flower skip_sw \
    src_ip 192.168.1.0/24 \
    action tunnel_key set id 100 src_ip 10.0.0.1 dst_ip 10.0.0.2 \
    action mirred egress redirect dev vxlan_sys_4789

# Connection Tracking offload (CX-6+)
tc filter add dev enp1s0f0np0 ingress protocol ip \
    flower skip_sw ct_state +trk+est \
    action goto chain 1
tc filter add dev enp1s0f0np0 ingress protocol ip chain 1 \
    flower skip_sw \
    action ct commit \
    action mirred egress redirect dev enp1s0f0np0_0

# OVS HW offload 활성화 (OVS 2.8+)
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_sw
systemctl restart openvswitch

# offload된 flow 통계 확인
tc -s filter show dev enp1s0f0np0 ingress

mlx5 eSwitch: Legacy vs Switchdev 모드

mlx5 eSwitch는 NIC 내부의 가상 스위치로, SR-IOV VF와 PF 간의 트래픽을 관리한다. 두 가지 동작 모드가 있다: Legacy 모드는 전통적인 MAC/VLAN 기반 L2 스위칭을 제공하며, Switchdev 모드는 각 VF/SF에 대한 representor netdev를 생성하여 TC/OVS 기반의 정밀한 프로그래머블 데이터 경로를 제공한다.

eSwitch 모드 전환 시에는 기존 VF 설정이 초기화되므로, 운영 중인 VM의 네트워크 연결이 일시적으로 끊어질 수 있다. 사전에 VF를 unbind하고 전환 후 다시 bind하는 절차가 필요하다.

# 현재 eSwitch 모드 확인
devlink dev eswitch show pci/0000:01:00.0

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

# Switchdev 모드로 전환 (VF unbind 필요)
echo 0000:01:00.2 > /sys/bus/pci/drivers/mlx5_core/unbind
echo 0000:01:00.3 > /sys/bus/pci/drivers/mlx5_core/unbind
devlink dev eswitch set pci/0000:01:00.0 mode switchdev
echo 0000:01:00.2 > /sys/bus/pci/drivers/mlx5_core/bind
echo 0000:01:00.3 > /sys/bus/pci/drivers/mlx5_core/bind

# Representor 디바이스 확인
ip link show type mlx5_rep 2>/dev/null || ip link show | grep repr

# OVS bridge에 representor 추가
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int enp1s0f0np0     # uplink representor
ovs-vsctl add-port br-int enp1s0f0np0_0   # VF0 representor
ovs-vsctl add-port br-int enp1s0f0np0_1   # VF1 representor

# Scalable Functions (SF) 생성 (CX-6 Dx+)
devlink port add pci/0000:01:00.0 flavour pcisf pfnum 0 sfnum 8
devlink port function set pci/0000:01:00.0/32768 \
    hw_addr 00:11:22:33:44:55 state active

# Legacy 모드로 복귀
devlink dev eswitch set pci/0000:01:00.0 mode legacy

mlx5e XDP 및 AF_XDP 제로카피

mlx5e는 MPWQE(Multi-Packet Work Queue Entry) 기반의 효율적인 XDP 경로를 제공한다. MPWQE는 하나의 WQE에 여러 패킷을 담는 Striding RQ 방식으로, 메모리 효율과 캐시 친화성이 높다. XDP 프로그램은 RQ에서 패킷을 수신한 직후, SKB 할당 전에 실행되어 XDP_DROP, XDP_TX, XDP_REDIRECT, XDP_PASS 결정을 내린다.

AF_XDP 제로카피 모드에서 mlx5e는 UMEM(User Memory)을 직접 RQ에 매핑하여 커널 버퍼 복사 없이 사용자 공간으로 패킷을 전달한다. 아래는 세대별 AF_XDP 성능 데이터이다.

# XDP 프로그램 로드 (native 모드)
ip link set dev enp1s0f0np0 xdp obj xdp_prog.o sec xdp

# XDP 프로그램 상태 확인
ip link show dev enp1s0f0np0
bpftool prog show
bpftool net show dev enp1s0f0np0

# AF_XDP 소켓 성능 테스트 (xdp-tools)
xdp-bench rx enp1s0f0np0 -m native
xsk_fwd -i enp1s0f0np0 -q 0 -z    # zero-copy 모드

# XDP 통계 확인
ethtool -S enp1s0f0np0 | grep xdp
# rx_xdp_drop, rx_xdp_redirect, rx_xdp_tx, rx_xdp_tx_full 등

# Multi-buffer XDP (CX-6 Dx+, jumbo frame 지원)
ip link set dev enp1s0f0np0 mtu 9000
ip link set dev enp1s0f0np0 xdp obj xdp_mb_prog.o sec xdp

# XDP 프로그램 해제
ip link set dev enp1s0f0np0 xdp off

mlx5 RDMA: RoCEv2 / GPUDirect / ODP

mlx5_ib 모듈은 ConnectX NIC의 RDMA 기능을 IB verbs 인터페이스로 노출한다. RoCEv2(RDMA over Converged Ethernet v2)는 UDP/IP 캡슐화를 사용하여 표준 이더넷 스위치 인프라 위에서 RDMA를 제공하며, GPUDirect RDMA는 GPU 메모리에 대한 직접 DMA를 지원하여 AI/HPC 워크로드에서 핵심 역할을 한다.

# RDMA 디바이스 및 포트 상태 확인
rdma dev show
rdma link show mlx5_0/1
ibstat mlx5_0

# RoCEv2 모드 설정 (기본값)
cma_roce_mode -d mlx5_0 -p 1 -m 2    # RoCE v2

# ECN 설정 (DCQCN)
mlnx_qos -i enp1s0f0np0 --trust dscp
mlnx_qos -i enp1s0f0np0 --pfc 0,0,0,1,0,0,0,0  # TC3에 PFC

# GPUDirect RDMA (nvidia-peermem 로드)
modprobe nvidia-peermem
cat /sys/module/nvidia_peermem/version

# RDMA 대역폭 테스트
ib_write_bw -d mlx5_0 -x 3 --report_gbits    # server
ib_write_bw -d mlx5_0 -x 3 --report_gbits 10.0.0.1  # client

# ODP (On-Demand Paging) 확인
rdma dev show mlx5_0 -j | jq '.[] | .caps'

RoCEv2와 Ethernet 드라이버 상호작용 심화

RoCEv2 트래픽은 mlx5_ib가 생성하지만, 실제 패킷 전송은 mlx5e(Ethernet 드라이버)의 SQ(Send Queue)를 공유한다. CQ(Completion Queue)와 EQ(Event Queue) 인프라도 Ethernet과 RDMA 경로가 공유하므로, RDMA 워크로드가 CQ를 고갈시키면 Ethernet 트래픽에도 영향이 미칠 수 있다.

PFC(Priority Flow Control)와 ECN(Explicit Congestion Notification)은 RoCEv2 환경에서 필수다. RoCEv2는 패킷 드롭에 취약하므로(TCP의 재전송과 달리 RDMA는 재전송 메커니즘이 제한적), lossless 패브릭 구성이 요구된다. PFC는 특정 우선순위 큐에서 혼잡이 발생할 때 해당 우선순위 트래픽만 일시 정지시켜 패킷 드롭 없이 버퍼 압력을 완화한다. ECN(DCQCN 알고리즘)은 네트워크 혼잡이 시작될 때 송신 속도를 선제적으로 낮춘다.

DSCP 기반 우선순위 매핑: mlx5는 RoCEv2 패킷에 특정 DSCP 값을 부여하고, 스위치와 NIC가 해당 DSCP를 TC(Traffic Class)로 매핑하여 PFC와 ECN을 적용한다. 일반적으로 RoCEv2는 DSCP 26(CS3) 또는 DSCP 46(EF)을 사용하며, mlnx_qos 도구로 NIC 측 매핑을 설정한다.

# RoCEv2 설정 검증 명령어

# 1. RoCE 모드 확인 (v2 = 2)
cma_roce_mode -d mlx5_0 -p 1
# port 1 RoCE mode: RoCE v2

# 2. PFC 설정 확인 (TC3에 PFC 적용 예시)
mlnx_qos -i enp1s0f0np0 --pfc
# pfc: 0,0,0,1,0,0,0,0  (TC3만 lossless)

# 3. DSCP → 우선순위 매핑 확인
mlnx_qos -i enp1s0f0np0 --trust dscp
mlnx_qos -i enp1s0f0np0 --dscp2prio

# 4. ECN 설정 확인
cat /sys/kernel/debug/mlx5/0000:*/cc_params/cc_algo 2>/dev/null
# DCQCN이 활성화되어 있어야 함

# 5. CQ/EQ 인프라 공유 상태 확인
rdma stat show mlx5_0
ethtool -S enp1s0f0np0 | grep -E "rx_cq_|tx_cq_"

# 6. RoCE 트래픽 카운터 확인
rdma stat show -j mlx5_0 | jq '.[] | select(.type=="mr")'
perfquery -d mlx5_0 -x 3 -l    # 포트 카운터 (패킷 드롭 확인)

mlx5 devlink Health Reporter

mlx5 드라이버는 devlink health 프레임워크를 통해 하드웨어 오류 감지, 진단, 자동 복구를 제공한다. 각 reporter는 특정 하드웨어/소프트웨어 구성 요소를 모니터링하며, 오류 발생 시 진단 정보(dump)를 수집하고 자동 복구를 시도한다.

# Health reporter 목록 및 상태 확인
devlink health show pci/0000:01:00.0

# 특정 reporter 상세 정보
devlink health show pci/0000:01:00.0 reporter fw

# 진단 정보 조회
devlink health diagnose pci/0000:01:00.0 reporter fw
devlink health diagnose pci/0000:01:00.0 reporter vnic

# 덤프 수집 (FW 오류 분석용)
devlink health dump show pci/0000:01:00.0 reporter fw_fatal

# 수동 복구 트리거
devlink health recover pci/0000:01:00.0 reporter tx

# Auto-recovery 설정
devlink health set pci/0000:01:00.0 reporter fw \
    auto_recover true grace_period 60000
devlink health set pci/0000:01:00.0 reporter fw_fatal \
    auto_dump true

# Health 이벤트 모니터링 (실시간)
devlink health -j monitor

mlx5 펌웨어 관리

ConnectX NIC의 펌웨어 업데이트는 devlink 프레임워크를 통해 수행된다. 업데이트 프로세스는 FW 이미지 다운로드, 무결성 검증, 플래시 기록, 활성화의 단계로 진행되며, flash_only 옵션을 사용하면 NIC 리셋 없이 다음 부팅 시 적용할 수 있다.

# 현재 FW 버전 확인
devlink dev info pci/0000:01:00.0
ethtool -i enp1s0f0np0 | grep firmware

# FW 업데이트 (즉시 활성화)
devlink dev flash pci/0000:01:00.0 \
    file fw-ConnectX7-rel-28_39_1002-MCX713106AS-VEA_Ax-UEFI-14.32.17-FlexBoot-3.7.300.bin

# FW 업데이트 (다음 리부팅 시 적용)
devlink dev flash pci/0000:01:00.0 \
    file firmware.mfa2 component fw \
    overwrite settings

# FW reset (live reset, 서비스 중단 최소화)
devlink dev reload pci/0000:01:00.0 action fw_activate

# 설정 보존 여부 확인
mlxconfig -d /dev/mst/mt4129_pciconf0 query

# NIC 설정 변경 (mlxconfig, OFED 도구)
mlxconfig -d /dev/mst/mt4129_pciconf0 set SRIOV_EN=1 NUM_OF_VFS=16

mlx5 최대 강점: 타 드라이버 비교 심층 분석

mlx5e는 단일 드라이버 안에서 가장 넓은 범위의 커널 네트워킹 기능을 프로덕션 수준으로 지원하는 유일한 NIC 드라이버이다. 여기서는 mlx5의 핵심 강점을 다른 드라이버와 정량적·구조적으로 비교하여, 왜 데이터센터 표준이 되었는지를 분석한다.

강점 1: Flow Steering — 압도적 규칙 용량과 유연성

mlx5의 하드웨어 Flow Steering Engine은 64M+ 이상의 flow rules을 지원한다(ConnectX-7 기준). 이는 경쟁 드라이버 대비 수백~수천 배의 격차이다. 단순한 숫자 차이를 넘어, Flow Table 계층 구조의 아키텍처적 유연성이 핵심 차별점이다.

왜 mlx5가 이렇게 큰 용량을 제공하는가?

• RDMA 유산: InfiniBand에서 수백만 QP(Queue Pair)를 관리하던 하드웨어 테이블 인프라를 Ethernet steering에 재활용. 다른 NIC 벤더는 이런 대규모 테이블 엔진을 보유하고 있지 않다.
• EM + TCAM 이중 구조: Exact Match 테이블(해시 기반, 대용량)과 TCAM(ternary match, 와일드카드)을 병행하여, 정확한 플로우는 EM에서 O(1)로 검색하고 서브넷/마스크 매칭은 TCAM에서 처리한다.
• Flow Table 계층(goto chain): 여러 Flow Table을 goto chain으로 연결하여 파이프라인을 구성할 수 있다. 이는 OVS offload에서 복잡한 다중 매칭 파이프라인을 단일 HW 경로로 구현하는 핵심이다.

# mlx5 Flow Steering 용량 확인
devlink resource show pci/0000:01:00.0

# 현재 HW offloaded flow 수 확인
tc -s filter show dev enp1s0f0np0 ingress | grep -c "in_hw"

# OVS HW offload 시 flow 통계
ovs-appctl dpctl/dump-flows type=offloaded | wc -l

# 비교: ice 드라이버의 제한적 steering
# ice는 tc flower 지원하지만, 16K entries 이후 SW fallback
ethtool --show-priv-flags enp2s0f0 | grep flow-director

강점 2: XDP/AF_XDP — 최고 성능과 가장 완전한 구현

mlx5e의 XDP 구현은 커널 커뮤니티에서 참조 구현(reference implementation)으로 간주된다. MPWQE(Multi-Packet Work Queue Entry) 기반 Striding RQ가 핵심 차별점으로, 하나의 WQE에 여러 패킷을 배치하여 descriptor 오버헤드를 최소화한다.

mlx5 XDP 성능의 비밀: MPWQE Striding RQ

• 일반 NIC: 1 descriptor = 1 패킷. 35 Mpps에서 초당 35M 회 descriptor 갱신 → PCIe/CPU 오버헤드 병목
• mlx5 MPWQE: 1 WQE = 1 대형 페이지(64KB), 여러 패킷이 stride 방식으로 배치. descriptor 갱신 빈도가 수십 배 감소, page_pool 즉시 재활용
• Inline WQE: 소형 패킷은 WQE 안에 페이로드를 직접 삽입하여 DMA 왕복 제거. XDP_TX에서 추가 속도 이점

# mlx5 Striding RQ 모드 확인
ethtool --show-priv-flags enp1s0f0np0 | grep striding
# rx_striding_rq: on  ← MPWQE 활성화

# XDP 성능 벤치마크 (mlx5 vs ice)
ethtool -G enp1s0f0np0 rx 8192
ethtool -C enp1s0f0np0 rx-usecs 0
xdp-bench drop enp1s0f0np0 -m native    # mlx5: ~35 Mpps
xdp-bench drop enp2s0f0 -m native       # ice: ~25 Mpps

# AF_XDP 제로카피 비교
xsk_fwd -i enp1s0f0np0 -q 0 -z -p      # mlx5: ~22 Mpps
xsk_fwd -i enp2s0f0 -q 0 -z -p         # ice: ~16 Mpps

# bpftrace: XDP 경로 지연 측정
bpftrace -e 'kprobe:mlx5e_xdp_handle { @start[tid] = nsecs; }
kretprobe:mlx5e_xdp_handle /@start[tid]/ {
    @ns = hist(nsecs - @start[tid]); delete(@start[tid]);
}'

강점 3: 오프로드 범위 — 유일한 Full-Stack HW Offload

mlx5e는 커널 네트워킹 스택의 거의 모든 기능을 하드웨어로 오프로드할 수 있는 유일한 드라이버이다. TC flower + Connection Tracking + NAT + 터널(VXLAN/GRE/Geneve) + IPsec + kTLS + MACsec를 동시에 하드웨어에서 처리한다.

클라우드 네이티브 환경에서 패킷은 여러 처리 단계를 거친다: OVS/eBPF 매칭 → VXLAN 캡슐화 → Connection Tracking → NAT 변환 → IPsec 암호화. mlx5는 이 전체 파이프라인을 HW에서 처리하여 CPU를 완전히 해방한다. 다른 드라이버는 일부 단계에서 SW fallback이 발생하여 CPU 오버헤드가 급증한다.

강점 4: 가상화 — SR-IOV + Scalable Functions

mlx5는 전통적 SR-IOV(1024 VFs)에 더해 Scalable Functions(SF)라는 고유한 기능을 제공한다. SF는 VF와 달리 PCIe function을 소비하지 않으므로, 하드웨어 PCIe 한계(통상 256 functions)를 초월하여 수천 개의 독립 네트워크 기능을 생성할 수 있다.

# SR-IOV VF 생성
echo 16 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs

# Scalable Function 생성 (mlx5 전용, CX-6 Dx+)
devlink port add pci/0000:01:00.0 flavour pcisf pfnum 0 sfnum 88
devlink port function set pci/0000:01:00.0/32768 \
    hw_addr 00:11:22:33:44:55 state active

# SF의 독립 devlink 인스턴스 확인
devlink dev show
# pci/0000:01:00.0  ← PF
# auxiliary/mlx5_core.sf.4  ← SF 독립 인스턴스

# 비교: ice VF 생성 (최대 256, SF 미지원)
echo 256 > /sys/bus/pci/devices/0000:02:00.0/sriov_numvfs

강점 5: RDMA/GPUDirect — AI/HPC 독점적 지위

AI 훈련과 HPC 워크로드에서 mlx5는 사실상 유일한 선택지이다. RoCEv2, InfiniBand, GPUDirect RDMA, GPUDirect Storage, On-Demand Paging(ODP)을 모두 단일 NIC에서 제공하는 드라이버는 mlx5뿐이다.

# GPUDirect RDMA 환경 확인
nvidia-smi topo -m
cat /proc/driver/nvidia-peermem/version

# GPUDirect RDMA 대역폭 테스트
ib_write_bw -d mlx5_0 --use_cuda=0 -x 3 --report_gbits

# NCCL all-reduce 벤치마크 (multi-GPU, SHARP 가속)
nccl-tests/build/all_reduce_perf -b 1M -e 1G -g 8

강점 6: 관측성 및 관리 — 업계 최고 devlink 통합

mlx5 드라이버는 커널 devlink 프레임워크의 최초이자 가장 완전한 구현체이다. devlink 프레임워크 자체가 mlx5 요구사항에 맞춰 설계되었으며, 이후 다른 드라이버들이 점진적으로 채택하고 있다.

# 패킷 드롭 원인 추적 (mlx5 전용 trap)
devlink trap show pci/0000:01:00.0
devlink trap set pci/0000:01:00.0 trap source_mac_is_multicast action trap

# SF별 rate limiting (QoS)
devlink port function rate add pci/0000:01:00.0/sf_group \
    tx_share 1gbit tx_max 10gbit

# FW live reset (재부팅 불필요, CX-6+)
devlink dev reload pci/0000:01:00.0 action fw_activate

종합 비교: 드라이버별 강약점 매트릭스

워크로드별 최적 드라이버 선택 가이드

# mlx5 종합 프로파일링
devlink dev info pci/0000:01:00.0       # HW/FW 정보
ethtool -k enp1s0f0np0 | grep -E "tc-hw|ntuple|rx-gro-hw"
ethtool -S enp1s0f0np0 | head -50       # 성능 카운터
devlink health show pci/0000:01:00.0    # Health 상태
devlink resource show pci/0000:01:00.0  # 리소스 사용률

# bpftrace: mlx5e NAPI poll 효율성
bpftrace -e 'kprobe:mlx5e_napi_poll { @polls = count(); }
kretprobe:mlx5e_napi_poll /retval > 0/ { @pkts = hist(retval); }
interval:s:5 { print(@polls); print(@pkts); clear(@polls); clear(@pkts); }'

mlx4 레거시 드라이버 및 mlx5 마이그레이션

mlx4_core/mlx4_en은 ConnectX-2, ConnectX-3, ConnectX-3 Pro를 지원하는 레거시 드라이버이다. mlx5와 비교하여 스티어링 유연성, SR-IOV 확장성, offload 기능에서 상당한 차이가 있다. ConnectX-3 Pro는 mlx4와 mlx5 모두에서 부분적으로 지원되지만, mlx4가 권장된다.

mlx4에서 mlx5로의 마이그레이션은 하드웨어 교체(ConnectX-3 → ConnectX-5/6/7)를 수반한다. 소프트웨어 관점에서 주요 변경 사항과 마이그레이션 절차는 다음과 같다.

# mlx4 → mlx5 마이그레이션 전 현재 설정 백업
ethtool -i eth0                        # 드라이버 확인 (mlx4_en)
mlxconfig -d /dev/mst/mt4099_pciconf0 query > mlx4_config_backup.txt
ip addr show eth0 > mlx4_ip_backup.txt

# 하드웨어 교체 후 mlx5 드라이버 확인
lspci -d 15b3: -k                      # mlx5_core가 로드되어야 함
ethtool -i enp1s0f0np0                 # driver: mlx5_core

# SR-IOV 마이그레이션 (mlx4 → mlx5 방식)
# 기존 mlx4: modprobe mlx4_core num_vfs=4,0 port_type_array=2,2
# 새 mlx5:
echo 4 > /sys/class/net/enp1s0f0np0/device/sriov_numvfs

# Switchdev 모드 활용 (mlx4에서 불가했던 기능)
devlink dev eswitch set pci/0000:01:00.0 mode switchdev

# 기존 mlx4 NIC 관련 모듈 정리
echo "blacklist mlx4_core" >> /etc/modprobe.d/blacklist-mlx4.conf
echo "blacklist mlx4_en" >> /etc/modprobe.d/blacklist-mlx4.conf

ConnectX-3 CI vs CQ 모델

mlx4는 완료 처리를 위해 두 가지 모델을 제공한다. CI(Completion Index) 모드는 드라이버가 CQ를 폴링하지 않고 완료 인덱스를 직접 쿼리하여 처리하는 방식으로, TX 경로의 저지연에 유리하다. 반면 CQ(Completion Queue) 폴링 모드는 NAPI 루프 안에서 CQE 배치를 한꺼번에 처리하므로 높은 처리량(throughput) 환경에 적합하다. CI 모드는 코어당 처리 패킷이 적을 때 캐시 압력을 줄이고, CQ 폴링 모드는 패킷이 몰릴 때 배치 효율로 CPU 사이클을 절약한다.

ConnectX-3는 IB 포트와 Ethernet 포트를 동일 HCA 위에서 멀티플렉싱한다. mlx4_core는 부팅 시 포트 타입(IB vs Ethernet)을 port_type_array 모듈 파라미터로 설정하며, 각 포트는 독립적인 CQ/QP 자원 풀을 갖는다. 두 포트가 공유하는 HCA 리소스(EQ, MPT 등)는 mlx4_core가 중재한다.

QP 리소스 한계: mlx4는 포트당 최대 QP 및 CQ 수가 하드웨어에 고정되어 있으며, SR-IOV 환경에서는 VF 수 제한이 64로 고정된다(SRIOV_MAX_FUNCS = 64). 이 제한은 mlx4_core 내부 리소스 파티셔닝 테이블이 64-entry로 설계된 데서 기인한다. ConnectX-4 이상(mlx5)에서는 이 한계가 1024 VF으로 확장되었다.

mlx4 운영 가이드

ConnectX-3 환경에서 중요한 모니터링 지표와 커널 호환성은 다음과 같다.

커널 호환성: mlx4 드라이버는 커널 4.x ~ 6.x에서 모두 컴파일되지만, 커널 5.15 이후로는 신규 기능 추가 없이 보안 패치와 버그 수정만 이루어지는 유지보수 모드(maintenance mode)다. 커널 6.8부터는 일부 레거시 compat 코드가 제거되었으므로, ConnectX-3 Pro 사용 환경에서는 커널 버전 업그레이드 전 OFED 호환성을 반드시 확인해야 한다. 권장 마이그레이션 시점: 커널 6.x 이상 + ConnectX-3 조합은 ConnectX-5/6으로의 하드웨어 업그레이드가 강력히 권장된다.

BlueField DPU와 mlx5

NVIDIA BlueField DPU(Data Processing Unit)는 mlx5 NIC에 ARM 코어 클러스터를 내장하여 네트워크 처리를 호스트 CPU에서 완전히 분리(offload)하는 아키텍처다.

호스트에서 BlueField는 두 가지 netdev로 나타난다: 호스트 representor(호스트 측 트래픽을 DPU ARM에서 제어)와 물리 포트 representor(외부 네트워크 포트). DPU ARM 위에서 OVS, eBPF, connection tracking이 실행되며, 호스트 CPU는 패킷 처리 부담에서 해방된다.

ConnectX-3(mlx4) → ConnectX-4+(mlx5) 마이그레이션 시 주요 아키텍처 차이: mlx5는 단일 mlx5_core 모듈이 Ethernet, RDMA, vDPA를 모두 담당하는 통합 구조이며, eSwitch, Scalable Function(SF), devlink health 등이 mlx4에는 없는 핵심 기능이다. DPU 오프로드 기능(DOCA SDK)은 mlx5 기반 BlueField에서만 사용 가능하다.

Broadcom: bnxt_en / bnx2x / tg3

Broadcom은 서버 및 데이터센터 시장에서 가장 광범위한 NIC 포트폴리오를 보유하고 있습니다. 최신 Thor2(BCM57608) 시리즈부터 레거시 Tigon3까지, 세 가지 주요 드라이버가 리눅스 커널에서 관리됩니다.

bnxt_en 아키텍처: HWRM과 링 모델

bnxt_en 드라이버의 핵심 설계 원칙은 HWRM(Hardware Resource Manager) 펌웨어 인터페이스입니다. 호스트 드라이버는 하드웨어 레지스터를 직접 조작하지 않고, HWRM 명령 채널을 통해 모든 설정과 리소스 관리를 수행합니다. 이 구조는 펌웨어 업데이트만으로 새로운 기능을 추가할 수 있는 유연성을 제공합니다.

링(Ring) 모델은 bnxt_en의 데이터 경로 핵심입니다. 4가지 링 타입이 서로 연동하여 패킷 송수신을 처리합니다.

# bnxt_en 링 및 채널 설정 확인
ethtool -g enp3s0f0
ethtool -l enp3s0f0

# 링 크기 최적화 (고처리량 서버)
ethtool -G enp3s0f0 rx 4096 tx 4096

# 결합 채널 수 조정 (CPU 수에 맞춤)
ethtool -L enp3s0f0 combined 16

# HWRM 버전 및 펌웨어 정보 확인
ethtool -i enp3s0f0
# firmware-version: 228.1.105.2 (HWRM 1.10.2.128)

# 인터럽트 코얼레싱 (적응형)
ethtool -C enp3s0f0 adaptive-rx on adaptive-tx on

# 하드웨어 GRO 활성화
ethtool -K enp3s0f0 rx-gro-hw on

/* bnxt_en HWRM 명령 전송 핵심 구조 */
struct hwrm_req {
    __le16 req_type;          /* 명령 타입 */
    __le16 cmpl_ring;         /* 완료 링 ID */
    __le16 seq_id;            /* 시퀀스 번호 */
    __le16 target_id;         /* 대상 (PF/VF) */
    __le64 resp_addr;         /* 응답 DMA 주소 */
};

/* 링 그룹: TX + RX + CP + AGG를 하나로 묶음 */
struct bnxt_ring_grp_info {
    u16 fw_stats_ctx;         /* 통계 컨텍스트 FW ID */
    u16 fw_grp_id;            /* FW 그룹 ID */
    u16 rx_fw_ring_id;
    u16 agg_fw_ring_id;
    u16 cp_fw_ring_id;
};

HWRM Timeout 감지 및 복구

bnxt_hwrm_do_send_msg()는 HWRM 명령을 펌웨어로 전송하고 완료를 기다리는 핵심 함수입니다. 기본 타임아웃은 500ms이며, HWRM_FUNC_QCFG나 링 초기화처럼 복잡한 명령은 최대 10초까지 대기합니다. 타임아웃이 발생하면 드라이버는 펌웨어 사망(FW Fatal)으로 간주하고 복구 절차를 시작합니다.

PF 충돌 → VF 연쇄 영향: PF 드라이버의 HWRM 채널이 실패하면, 모든 VF는 HWRM 프록시를 잃습니다. VF는 다음 HWRM 요청에서 타임아웃을 만나고, 이를 FLR(Function Level Reset) 트리거로 처리합니다. FLR 이후 VF 드라이버는 HWRM_FUNC_VF_CFG를 다시 발행하여 채널을 재확립합니다.

PF HWRM 채널 실패
        │
        ├─ PF: bnxt_fw_reset() 호출
        │       └─ bnxt_fw_fatal_reporter 활성화
        │
        └─ VF들: 다음 HWRM 요청 → 타임아웃(500ms)
                └─ bnxt_vf_hwrm_timeout_notify()
                        ├─ netif_carrier_off()
                        ├─ FLR 요청 (PCIe FLR)
                        └─ 채널 재확립 (HWRM_FUNC_VF_CFG)

HWRM 명령 트레이싱

HWRM 명령 흐름을 추적하는 방법은 devlink health reporter, ftrace, bpftrace 세 가지가 있습니다. devlink reporter는 FW 이상 상태를 진단하고, ftrace/bpftrace는 정상 동작 중 지연을 측정하는 데 사용됩니다.

# devlink health reporter: FW 상태 확인
devlink health show pci/0000:03:00.0
# reporter: bnxt_fw_reporter — FW 링크 이벤트 추적
# reporter: bnxt_fw_fatal_reporter — FW 크래시 덤프
devlink health diagnose pci/0000:03:00.0 reporter bnxt_fw_reporter
devlink health dump show pci/0000:03:00.0 reporter bnxt_fw_fatal_reporter

# ftrace: HWRM send/receive 함수 추적
echo 'bnxt_hwrm_do_send_msg' > /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
# 작업 수행 후
cat /sys/kernel/debug/tracing/trace | grep bnxt_hwrm | head -20
echo 0 > /sys/kernel/debug/tracing/tracing_on
echo nop > /sys/kernel/debug/tracing/current_tracer

# bpftrace: HWRM 명령 레이턴시 히스토그램
bpftrace -e '
kprobe:bnxt_hwrm_do_send_msg { @start[tid] = nsecs; }
kretprobe:bnxt_hwrm_do_send_msg
/@start[tid]/
{
    @latency_us = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}
END { print(@latency_us); }'

# HWRM 타임아웃 카운터 확인 (ethtool 통계)
ethtool -S enp3s0f0 | grep -i hwrm
# hwrm_req_timeout: 타임아웃 발생 횟수
# hwrm_resp_err: 응답 오류 횟수

# 현재 HWRM 타임아웃 설정 확인
ethtool -i enp3s0f0
# 모듈 파라미터로 타임아웃 조정 (ms 단위)
modprobe bnxt_en hwrm_min_timeout=1000

bnxt_en TruFlow 오프로드 엔진

TruFlow는 Broadcom Thor/Thor2 NIC에 내장된 프로그래머블 패킷 처리 파이프라인입니다. TC flower 규칙을 하드웨어로 직접 오프로드하여 호스트 CPU 부하를 제거하고, 수백만 개의 플로우 규칙을 와이어 스피드로 처리합니다.

# TC flower를 이용한 TruFlow 오프로드 예시

# switchdev 모드 활성화 (TruFlow 필수 전제)
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# ingress qdisc 추가
tc qdisc add dev enp3s0f0 ingress

# VXLAN 터널 트래픽을 VF representor로 포워드
tc filter add dev enp3s0f0 protocol ip parent ffff: \
  flower enc_dst_ip 10.0.0.1 enc_key_id 100 enc_dst_port 4789 \
  action tunnel_key unset \
  action mirred egress redirect dev enp3s0f0_0

# NAT 오프로드 (SNAT)
tc filter add dev enp3s0f0 protocol ip parent ffff: \
  flower ip_proto tcp src_ip 192.168.1.0/24 \
  action pedit ex munge ip src set 10.0.0.1 \
  action csum ip4h tcp \
  action mirred egress redirect dev enp3s0f0

# 오프로드된 플로우 통계 확인
tc -s filter show dev enp3s0f0 ingress

# TruFlow 테이블 사용량 확인
devlink resource show pci/0000:03:00.0

TruFlow TCAM 프래그먼테이션

TCAM은 와일드카드 규칙을 우선순위 순서로 저장합니다. 규칙 추가/삭제가 반복되면 우선순위 홀(priority hole)이 발생하여 실제 사용 가능한 용량이 표시 용량보다 줄어드는 프래그먼테이션 현상이 일어납니다.

프래그먼테이션 발생 메커니즘: 우선순위 1000의 규칙을 삽입하면 기존 규칙들이 물리적으로 재배치됩니다. 규칙 삭제 시 해당 슬롯은 빈 상태로 남고, 새 규칙 삽입 시 우선순위 위치가 맞지 않으면 그 슬롯을 재사용하지 못합니다. 이 과정이 반복되면 TCAM의 논리 용량이 줄어듭니다.

Defragmentation: 펌웨어는 TCAM 사용률이 임계값(기본 80%)을 초과하면 자동으로 defrag를 시작합니다. Defrag 중에는 새 규칙 설치가 최대 수십 ms 지연될 수 있으므로, 고속 플로우 설치 환경에서는 주의가 필요합니다.

# TCAM/EM 리소스 사용량 모니터링
devlink resource show pci/0000:03:00.0
# 예시 출력:
#   resource TCAM: size 16384 unit entry occ 12800 -> 78%
#   resource EM:   size 4194304 unit entry occ 980000 -> 23%

# TC flower 현재 오프로드 규칙 수 확인
tc filter show dev enp3s0f0 ingress | grep -c 'handle'

# 오프로드 성공/실패 구분 (in_hw 플래그)
tc filter show dev enp3s0f0 ingress | grep -A3 'flower'
# in_hw: HW 오프로드 성공 / not_in_hw: 소프트웨어 폴백

TruFlow 용량 계획 가이드

EM 해시 충돌: Exact Match 테이블은 해시 기반이므로 생일 역설(birthday paradox)에 따른 충돌이 발생합니다. 테이블 크기가 N이고 k개의 엔트리가 채워졌을 때, 예상 충돌 확률은 약 k²/(2N)입니다. Thor2의 4M EM 테이블에서 100만 엔트리 사용 시 예상 충돌률은 약 12%입니다. 충돌 시 엔트리는 소프트웨어로 폴백됩니다.

TCAM vs EM 결정 기준:

• 와일드카드 규칙 (prefix match, mask 포함) → TCAM 사용
• 5-tuple 정확 매칭 (src_ip/dst_ip/src_port/dst_port/proto 고정) → EM 사용
• 혼합 시나리오 → 계층적 룩업: TCAM 우선, 미스 시 EM

CT 엔트리 추정 공식:

필요 EM 엔트리 = 동시 연결 수 × 2 (양방향) × 1.1 (10% 헤드룸)

예시: 동시 연결 50만 개
  = 500,000 × 2 × 1.1 = 1,100,000 엔트리 필요
  Thor2 4M EM: 충분 (사용률 26%)
  Thor 1M EM:  부족 → TCAM 보조 또는 소프트웨어 폴백

# 현재 EM 사용량 및 헤드룸 계산
EM_MAX=$(devlink resource show pci/0000:03:00.0 | awk '/EM/{print $4}')
EM_OCC=$(devlink resource show pci/0000:03:00.0 | awk '/EM/{print $6}')
echo "EM 사용률: $((EM_OCC * 100 / EM_MAX))%"
echo "남은 헤드룸: $((EM_MAX - EM_OCC)) 엔트리"

# CT 오프로드 통계 (conntrack + TruFlow)
conntrack -S | grep -E 'found|insert_failed|drop'
# insert_failed가 증가하면 EM 용량 부족 신호

# TruFlow 오프로드 상태 요약
devlink resource show pci/0000:03:00.0 | grep -E 'TCAM|EM'

bnxt_en SR-IOV 및 devlink 지원

bnxt_en의 SR-IOV 구현은 HWRM을 통한 완전한 VF 리소스 분할을 특징으로 합니다. PF 드라이버가 HWRM 프록시 역할을 하여 VF의 모든 하드웨어 요청을 중개합니다.

# SR-IOV VF 생성
echo 8 > /sys/class/net/enp3s0f0/device/sriov_numvfs

# VF MAC 주소 설정 (보안 강화)
ip link set enp3s0f0 vf 0 mac 00:11:22:33:44:55
ip link set enp3s0f0 vf 0 vlan 100
ip link set enp3s0f0 vf 0 spoofchk on
ip link set enp3s0f0 vf 0 trust on         # 필요시 promiscuous 허용

# VF 대역폭 제한 (Mbps)
ip link set enp3s0f0 vf 0 max_tx_rate 1000
ip link set enp3s0f0 vf 0 min_tx_rate 100

# devlink 정보 확인
devlink dev info pci/0000:03:00.0
devlink port show pci/0000:03:00.0

# switchdev 모드 전환 (VF representor 생성)
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# devlink health reporter
devlink health show pci/0000:03:00.0
devlink health diagnose pci/0000:03:00.0 reporter fw

# 펌웨어 업데이트 (devlink flash)
devlink dev flash pci/0000:03:00.0 file bnxt_fw.pkg

bnx2x 레거시: 57810 NPAR 아키텍처

bnx2x는 BCM57810 시리즈의 10GbE 드라이버로, NPAR(NIC Partitioning) 기능이 핵심 차별점입니다. NPAR은 SR-IOV와 달리 하드웨어 수준에서 물리 포트를 완전히 독립된 가상 NIC으로 분할합니다.

# bnx2x NPAR 설정 확인 (펌웨어 유틸리티 사용)
bnxtnvm -dev=eth0 listcfg

# 현재 대역폭 할당 확인
ethtool -i eth0 | grep firmware

# bnx2x 디버그 레벨 설정
modprobe bnx2x debug=0x20

# 실행 중 디버그 변경
echo 0x20 > /sys/module/bnx2x/parameters/debug

# bnx2x 드라이버 통계
ethtool -S eth0 | grep -E 'rx_|tx_|brb_|pfc_'

bnx2x NPAR 운영 심화

NPAR은 단순한 포트 분할을 넘어 세밀한 대역폭 보장과 프로토콜 오프로드 분리를 제공합니다. 실제 운영 환경에서는 파티션별 최소/최대 대역폭 설정과 SR-IOV 조합이 핵심 사용 패턴입니다.

대역폭 할당 예시 (4 파티션, 10GbE 포트):

NPAR + SR-IOV 조합: NPAR 파티션 위에 SR-IOV VF를 할당할 수 있습니다. 각 파티션은 독립된 PCI Function이므로 VF는 해당 파티션의 대역폭 한도 내에서만 동작합니다. 예를 들어 NPAR 0(최대 40%) 위에 4개 VF를 생성하면, VF들은 합산 40% 한도 내에서 경쟁합니다.

MCP 펌웨어 업데이트 위험: bnx2x의 MCP(Management Controller Processor) 펌웨어 업데이트는 오류 발생 시 NIC이 완전히 응답 불능 상태(bricking)가 될 수 있습니다. 안전한 업데이트 절차는 다음과 같습니다.

1. 모든 트래픽 중지: ip link set eth0 down (모든 NPAR 파티션)
2. 현재 펌웨어 백업: bnxtnvm -dev=eth0 backup
3. 이중화 경로 확인: 다른 NIC으로 관리 접속 유지
4. 업데이트 실행: bnxtnvm -dev=eth0 update -f new_fw.pkg
5. 업데이트 중 절전 모드/재부팅 금지 (전원 차단 = 브릭킹)

# NPAR 대역폭 설정 확인 (펌웨어 NVM에서 읽음)
bnxtnvm -dev=eth0 listcfg | grep -i bandwidth

# NPAR 파티션 별 인터페이스 목록
ip link show | grep -E 'eth[0-3]'

# 각 파티션 통계 (MCP BW 중재 결과 확인)
ethtool -S eth0 | grep -E 'npar|partition|bw'

# SR-IOV VF 생성 (NPAR 0 파티션 위에)
echo 4 > /sys/class/net/eth0/device/sriov_numvfs
# VF들은 NPAR 0의 대역폭 한도 내에서 동작

# NPAR + SR-IOV 상태 확인
ip link show eth0

# MCP 펌웨어 버전 확인
ethtool -i eth0 | grep -E 'firmware|version'
# firmware-version: BC1.5.1.0 NCSI v1.3.22.0

tg3 아키텍처: BMC 사이드밴드 통합

tg3 드라이버는 BCM5719/BCM5720 시리즈를 관리하며, 서버 관리 포트로 널리 사용됩니다. 이 NIC의 가장 큰 특징은 BMC(Baseboard Management Controller)와의 사이드밴드 채널을 통한 원격 관리 통합입니다.

# tg3 드라이버 정보 확인
ethtool -i eth0
# driver: tg3, firmware-version: 5719-v1.46 NCSI v1.5.18.0

# APE 펌웨어 상태 (dmesg)
dmesg | grep -i "tg3.*ape"

# BMC 공유 모드 확인
ipmitool lan print 1

# tg3 WoL(Wake on LAN) 설정
ethtool -s eth0 wol g

# PHY 속도 고정 (Auto-negotiation 비활성화 시)
ethtool -s eth0 speed 1000 duplex full autoneg off

# tg3 코얼레싱 최적화 (저지연)
ethtool -C eth0 rx-usecs 10 tx-usecs 10 rx-frames 4

# 흔한 문제: EEE(Energy Efficient Ethernet) 비호환 스위치
ethtool --set-eee eth0 eee off

tg3 TX/RX Descriptor 링 포맷

tg3의 TX 경로는 4개의 TX Producer 링이 단일 Consumer 모델로 수렴하는 구조입니다. 각 Producer 링은 우선순위가 다른 트래픽(일반/고우선순위/iSCSI/콘솔)에 할당되며, MAC은 Consumer 측에서 이를 스케줄링합니다.

TX Descriptor 포맷: 각 TX BD(Buffer Descriptor)는 64비트로 구성되며 start/mid/end 플래그로 멀티-BD 패킷(TSO, 점보 프레임)을 표현합니다. vlan_tag 필드는 VLAN 태그를 하드웨어가 직접 삽입하도록 지시하며, TSO 관련 mss/hdr_len도 BD에 인라인으로 포함됩니다.

/* tg3 TX Buffer Descriptor (64비트, drivers/net/ethernet/broadcom/tg3.h) */
struct tg3_tx_buffer_desc {
    u32 addr_hi;          /* 상위 32비트 DMA 주소 */
    u32 addr_lo;          /* 하위 32비트 DMA 주소 */
    u32 len_flags;        /* [31:16]=길이, [15:0]=플래그 */
    u32 vlan_tag;         /* VLAN 태그 (HW 삽입) */
};

/* len_flags 플래그 주요 비트 */
/* TXD_FLAG_START (0x0002): 패킷 첫 번째 BD */
/* TXD_FLAG_END   (0x0001): 패킷 마지막 BD */
/* TXD_FLAG_TSO   (0x0800): TSO 사용 (mss/hdr_len 유효) */
/* TXD_FLAG_VLAN  (0x0400): VLAN 태그 삽입 지시 */

RX Descriptor 모드: tg3는 Standard RX 링(단일 SKB 버퍼, 일반 패킷)과 Jumbo RX 링(페이지 기반 분산 버퍼, 점보 프레임)을 분리 운영합니다. Standard 링의 기본 버퍼 크기는 1536바이트이며, Jumbo 링은 9KB 이상의 패킷을 여러 페이지로 분할하여 수신합니다.

APE(Application Processing Engine) FW 상호작용

BCM5719/5720의 APE는 내장 ARM 코어로, NC-SI 프로토콜 처리와 BMC 통신을 전담합니다. 호스트 드라이버와 APE는 공유 메모리 영역을 통해 통신하며, 동기화를 위해 spinlock 계열의 APE lock을 사용합니다.

/* tg3 APE 락 메커니즘 (drivers/net/ethernet/broadcom/tg3.c) */
static int tg3_ape_lock(struct tg3 *tp, int locknum)
{
    int i, off;
    u32 status;

    off = APE_LOCK_GRANT + 4 * locknum;
    /* 락 요청 */
    tg3_ape_write32(tp, APE_LOCK_REQ + 4 * locknum,
                    APE_LOCK_REQ_DRIVER);
    /* 최대 APE_LOCK_TIMEOUT 동안 대기 */
    for (i = 0; i < APE_LOCK_TIMEOUT; i++) {
        status = tg3_ape_read32(tp, off);
        if (status == APE_LOCK_GRANT_DRIVER)
            return 0;
        udelay(10);
    }
    return -EBUSY;
}

/* NC-SI: BMC가 동일 포트를 통해 네트워크에 접근하는 프로토콜 */
/* BMC 트래픽은 APE가 처리 → 호스트 ethtool 통계에 미포함 */

BMC 공유 MAC 필터링: 호스트 OS와 BMC가 같은 MAC 주소를 사용하므로, tg3 드라이버는 APE lock을 획득한 후 MAC 필터 테이블을 업데이트합니다. BMC 전용 멀티캐스트 그룹(NC-SI management)은 APE 펌웨어가 별도 관리하며, 호스트 드라이버의 필터 변경이 BMC 통신을 끊지 않도록 APE에 사전 통보합니다.

APE 이벤트 처리: 링크 상태 변화나 시스템 종료 시 tg3 드라이버는 APE에 이벤트를 알립니다. tg3_ape_driver_state_change()가 이를 처리하며, ACPI S5(soft off) 상태에서도 BMC의 WoL(Wake-on-LAN) 기능이 유지됩니다.

tg3 트러블슈팅 가이드

EEE 링크 드롭 (BCM57766): BCM57766을 포함한 일부 BCM 기가비트 NIC은 EEE(Energy Efficient Ethernet) 협상 시 스위치 호환성 문제로 링크가 간헐적으로 드롭됩니다. 증상은 수 분~수십 분 간격으로 링크가 재협상되며, dmesg에 tg3 eth0: Link is down → Link is up이 반복됩니다.

TSO 체크섬 오류: ethtool -S의 tx_collisions 카운터는 실제 충돌이 아닌 내부 재시도를 의미하는 경우가 있습니다. TSO 관련 체크섬 오류는 tx_errors 증가로 나타나며, 특정 펌웨어 버전에서 TSO를 비활성화하면 해결됩니다.

PHY 자동협상 실패: MDI/MDIX 자동감지가 실패하는 환경(일부 구형 스위치)에서는 강제 속도 설정이 필요합니다. autoneg off 설정 시 MDI/MDIX도 수동으로 지정해야 합니다.

# EEE 링크 드롭 증상 확인
dmesg | grep -E 'tg3|eth0' | grep -E 'up|down' | tail -20

# EEE 비활성화 (BCM57766 링크 드롭 워크어라운드)
ethtool --set-eee eth0 eee off
# 영구 적용: /etc/NetworkManager/dispatcher.d/ 또는 udev rule 사용

# TSO 체크섬 오류 확인 및 비활성화
ethtool -S eth0 | grep -E 'tx_errors|tx_collisions'
ethtool -K eth0 tso off
# 체크섬 오류가 줄어드는지 확인
ethtool -S eth0 | grep tx_errors

# PHY 강제 속도 설정 (자동협상 실패 시)
ethtool -s eth0 speed 1000 duplex full autoneg off
# MDI 모드 강제 (크로스 케이블 연결 시)
ethtool -s eth0 mdix on

# APE 펌웨어 상태 및 NC-SI 버전 확인
ethtool -i eth0
# firmware-version: 5719-v1.46 NCSI v1.5.18.0 (APE FW 버전 포함)

# tg3 통계 전체 덤프 (APE/WoL 관련 포함)
ethtool -S eth0 | grep -E 'ape|wol|eee|phy'

Marvell/NXP 계열: mvneta / mvpp2 / enetc / dpaa2

Marvell과 NXP는 임베디드 및 산업용 네트워킹에서 강력한 입지를 가지고 있습니다. Marvell의 Armada 시리즈는 네트워크 어플라이언스에, NXP의 Layerscape/QorIQ 시리즈는 산업용 TSN 및 데이터 플레인 가속에 널리 사용됩니다.

mvneta / mvpp2: Marvell 패킷 프로세서

Marvell Armada SoC의 네트워크 서브시스템은 PPv2(Packet Processor v2)라는 하드웨어 패킷 처리 엔진을 내장하고 있습니다. PPv2는 파싱, 분류, 폴리싱, RSS를 하드웨어에서 수행하여 CPU 부하를 최소화합니다.

/* Device Tree 예시: mvpp2 포트 설정 */
&cp0_ethernet {
    status = "okay";
};

&cp0_eth0 {
    status = "okay";
    phy-mode = "10gbase-r";     /* SFI/10G 모드 */
    managed = "in-band-status";  /* phylink in-band AN */
    sfp = <&sfp_cp0_eth0>;      /* SFP 케이지 연결 */
};

&cp0_eth1 {
    status = "okay";
    phy-mode = "sgmii";
    phy = <&cp0_phy0>;          /* Copper PHY 연결 */
};

/* BM Pool 설정 (커널 코드) */
#define MVPP2_BM_LONG_BUF_SIZE   2048
#define MVPP2_BM_SHORT_BUF_SIZE  512
#define MVPP2_BM_POOL_SIZE_MAX   8192

# mvpp2 인터페이스 정보 확인
ethtool -i eth0
# driver: mvpp2, firmware-version: N/A

# RSS 설정 (mvpp2)
ethtool -X eth0 hfunc toeplitz
ethtool -N eth0 rx-flow-hash tcp4 sdfn

# XDP 프로그램 로드
ip link set dev eth0 xdp obj xdp_prog.o sec xdp

# mvpp2 코얼레싱
ethtool -C eth0 rx-usecs 64 rx-frames 32

# PHY/SFP 상태 확인
ethtool eth0
ethtool -m eth0          # SFP 모듈 EEPROM 정보

ENETC: IEEE TSN 지원

NXP LS1028A SoC에 내장된 ENETC(Enhanced Network Controller)는 리눅스 커널에서 가장 포괄적인 IEEE TSN(Time-Sensitive Networking) 지원을 제공합니다. 802.1Qbv(시간 인식 스케줄링), 802.1Qci(스트림 필터), 802.1Qbu(프레임 프리엠션)를 하드웨어 수준에서 구현합니다.

# 802.1Qbv: taprio qdisc 설정 (시간 인식 스케줄링)
tc qdisc replace dev eno0 parent root handle 100 taprio \
  num_tc 4 \
  map 0 0 1 1 2 2 3 3 0 0 0 0 0 0 0 0 \
  queues 1@0 1@1 1@2 1@3 \
  base-time 1000000000 \
  sched-entry S 0x08 125000 \
  sched-entry S 0x04 375000 \
  sched-entry S 0x03 500000 \
  flags 0x02                # 0x02 = 하드웨어 오프로드

# taprio 상태 확인
tc qdisc show dev eno0

# 802.1Qci: PSFP 스트림 필터 설정
tc qdisc add dev eno0 clsact
tc filter add dev eno0 ingress protocol 802.1Q \
  flower vlan_prio 6 dst_mac 01:00:5e:00:01:01 \
  action gate index 1 \
    sched-entry open  125000 -1 \
    sched-entry close 875000 -1

# 802.1Qbu: 프레임 프리엠션 활성화
ethtool --set-frame-preemption eno0 \
  fp on \
  preemptible-queues-mask 0x0f \
  min-frag-size 60

# PTP 하드웨어 타임스탬프 설정
ptp4l -i eno0 -H -2 --step_threshold=1 &
phc2sys -s eno0 -c CLOCK_REALTIME -O 0 &

dpaa2 아키텍처: WRIOP/DPIO 객체 모델

NXP의 DPAA2(Data Path Acceleration Architecture 2)는 LX2160A 등 고성능 Layerscape SoC에서 사용되는 정교한 네트워크 가속 프레임워크입니다. 기존의 고정 하드웨어 블록 대신, 소프트웨어 정의 객체 모델을 채택하여 유연한 데이터 플레인 구성을 가능하게 합니다.

DPAA2의 핵심은 MC(Management Complex) 펌웨어가 관리하는 객체(object) 시스템입니다. 각 객체는 독립된 하드웨어 리소스를 추상화하며, DPRC(Data Path Resource Container) 안에서 그룹화됩니다.

데이터 경로에서 패킷은 WRIOP(Packet I/O Engine)이 처리하고, QBMan(Queue-Based Manager) 포털을 통해 CPU와 데이터를 교환합니다.

# restool을 이용한 dpaa2 객체 관리

# 현재 객체 목록 조회
restool dprc show dprc.1
restool dpni info dpni.0
restool dpmac info dpmac.1

# DPNI 객체 생성 (네트워크 인터페이스)
restool dpni create \
  --num-tcs=8 \
  --num-queues=8 \
  --options=DPNI_OPT_HAS_KEY_MASKING

# DPIO 객체 생성 (per-CPU 포털)
restool dpio create \
  --channel-mode=DPIO_LOCAL_CHANNEL \
  --num-priorities=8

# DPBP 객체 생성 (버퍼 풀)
restool dpbp create

# 객체를 컨테이너에 연결
restool dprc assign dprc.1 --object=dpni.0 --plugged=1
restool dprc assign dprc.1 --object=dpio.0 --plugged=1

# DPNI와 DPMAC 연결 (L2 바인딩)
restool dprc connect dprc.1 \
  --endpoint1=dpni.0 \
  --endpoint2=dpmac.1

# 자식 DPRC 생성 (VM 할당용)
restool dprc create dprc.1 \
  --options=DPRC_CFG_OPT_ALLOC_ALLOWED

# dpaa2-eth 드라이버 운영

# 인터페이스 정보
ethtool -i eth0
# driver: dpaa2-eth
# firmware-version: 10.28.0

# 채널/큐 설정
ethtool -l eth0
ethtool -L eth0 combined 8

# RSS 설정
ethtool -X eth0 hfunc toeplitz
ethtool -N eth0 rx-flow-hash tcp4 sdfn

# XDP 프로그램 로드
ip link set eth0 xdp obj dpaa2_xdp.o sec xdp_prog

# WRIOP 통계 확인
ethtool -S eth0 | grep -E 'rx_|tx_|ch_'

# fsl-mc 버스 디바이스 확인
ls /sys/bus/fsl-mc/devices/
cat /sys/bus/fsl-mc/devices/dpni.0/driver

# DPL(Data Path Layout) 적용
# U-Boot에서: fsl_mc apply dpl 0x80100000

Realtek/Aquantia: r8169 / r8125 / atlantic

Realtek은 가장 널리 보급된 소비자/임베디드용 NIC 칩셋 제조사이며, Aquantia(현 Marvell 인수)는 멀티기가비트(2.5G/5G/10G) 시장을 선도합니다. 리눅스 커널에서 이 세 드라이버는 각기 다른 하드웨어 세대와 성능 계층을 담당합니다.

r8169 드라이버 심화

r8169 드라이버(drivers/net/ethernet/realtek/r8169_main.c)는 커널에서 가장 많은 하드웨어 변형(quirk)을 처리하는 NIC 드라이버 중 하나입니다. 20년 이상의 칩 세대를 단일 드라이버로 지원하며, 각 변형마다 고유한 버그 회피 코드가 존재합니다.

RTL 칩 변형별 특성 및 quirk 테이블

전원 관리 및 진단

# r8169 드라이버 사용 중인 장치 확인
lspci -k | grep -A3 -i realtek

# 현재 칩 리비전 확인 (dmesg에서)
dmesg | grep r8169
# 예: r8169 0000:03:00.0: RTL8111H at 0xffffa1234000, ...

# ASPM 상태 확인
lspci -vvs 03:00.0 | grep -i aspm

# WoL(Wake-on-LAN) 설정 확인 및 활성화
ethtool -s eth0 wol g
ethtool eth0 | grep Wake-on

# EEE 상태 확인 (RTL8111E 이후)
ethtool --show-eee eth0

# TX timeout 발생 시 통계 확인
ethtool -S eth0 | grep -E "tx_timeout|rx_missed"

# 인터럽트 coalescing 조정 (rx-usecs/tx-usecs)
ethtool -C eth0 rx-usecs 100 tx-usecs 200

RX 링 오버플로우 진단

r8169 드라이버의 하드웨어적 한계 중 하나는 256개 디스크립터 단일 큐 구조입니다. RTL811x ASIC는 TX/RX 각각 최대 256개 디스크립터를 지원하며, 멀티 큐 확장 없이 단일 링으로 동작합니다. 이는 높은 패킷 수신률 환경에서 링 오버플로우를 유발할 수 있습니다.

ethtool -S로 확인할 수 있는 두 카운터의 의미는 다릅니다:

• rx_missed_errors: ASIC RX FIFO 오버플로우로 인해 하드웨어 수준에서 드롭된 패킷 수. RTL 레지스터 MissedPacketCount(0x4C)를 직접 반영합니다.
• rx_fifo_errors: 소프트웨어 NAPI 링에서 기술적으로 손실된 프레임 수. rx_missed_errors 값과 동일하게 매핑됩니다.

링 오버플로우를 실시간으로 진단하려면 bpftrace로 r8169_poll() 함수의 per-poll 패킷 수를 히스토그램으로 관찰할 수 있습니다:

# bpftrace: r8169_poll() 호출당 처리 패킷 수 히스토그램
bpftrace -e '
kretprobe:r8169_poll {
  @hist = hist(retval);
}
interval:s:5 {
  print(@hist);
  clear(@hist);
}'

# rx_missed_errors 실시간 모니터링 (1초 간격)
watch -n1 "ethtool -S eth0 | grep -E 'rx_missed|rx_fifo|rx_packets'"

# 링 오버플로우 경향 확인 (누적 delta)
prev=0
while sleep 1; do
  cur=$(ethtool -S eth0 | awk '/rx_missed_errors/{print $2}')
  echo "delta: $((cur - prev))  total: $cur"
  prev=$cur
done

# rx-usecs 증가로 NAPI 빈도 조정 (배치 크기 확대)
ethtool -C eth0 rx-usecs 200

# 링 크기 확인 (최대 256, 기본 256)
ethtool -g eth0

오버플로우 발생 시 근본 해결책은 다음 순서로 시도합니다: (1) rx-usecs 증가로 인터럽트 코얼레싱 강화 → (2) 트래픽 부하 자체를 줄이거나 QoS로 입력 속도 제한 → (3) 근본적으로 멀티 큐를 지원하는 NIC(r8125 2.5GbE 또는 인텔 igc)로 교체.

r8169와 BQL(Byte Queue Limits) 상호작용

BQL(Byte Queue Limits)은 TX 링의 인플라이트 바이트 수를 동적으로 조정하여 레이턴시를 낮추는 커널 메커니즘입니다. 단일 큐 드라이버인 r8169에서는 BQL의 중요성이 멀티 큐 드라이버보다 더 높습니다. 여러 큐로 분산할 수 없기 때문에 단일 TX 링의 인플라이트 제어가 전체 레이턴시를 결정합니다.

BQL 파라미터는 sysfs를 통해 조회하고 조정할 수 있습니다:

# BQL 현재 상태 조회
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time

# BQL 인플라이트 바이트 수 확인
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight

# BQL limit_max 수동 조정 (낮출수록 레이턴시 감소, 높일수록 처리량 증가)
echo 10000 > /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max

fq_codel과의 시너지: tc qdisc로 fq_codel을 설정하면 BQL과 상호 보완적으로 동작합니다. BQL은 드라이버 TX 링 레벨에서 인플라이트 바이트를 제한하고, fq_codel은 그 위 qdisc 레이어에서 per-flow 공정성과 지연 기반 드롭을 수행합니다. 단일 큐 NIC에서 버퍼블로트를 완화하는 가장 효과적인 조합입니다:

# fq_codel 적용 (단일 큐 NIC 버퍼블로트 완화)
tc qdisc replace dev eth0 root fq_codel

# 상태 확인
tc qdisc show dev eth0
tc -s qdisc show dev eth0  # 통계 포함

# 파라미터 조정 (target: 목표 대기시간, interval: 측정 구간)
tc qdisc replace dev eth0 root fq_codel target 5ms interval 100ms

quirk 아키텍처 분석

r8169 드라이버의 핵심 설계 원칙은 칩별 quirk 함수 분리입니다. 각 RTL 칩 리비전마다 하드웨어 초기화 루틴이 다르기 때문에, 드라이버는 rtl_chip_infos[] 배열을 통해 칩별 특성을 등록하고 해당 rtl_hw_start_*() 함수 포인터를 호출합니다.

/* drivers/net/ethernet/realtek/r8169_main.c (발췌/단순화) */

/* 칩 정보 구조체 */
struct rtl_chip_info {
    const char *name;
    u8          mcfg;           /* MAC 설정 레지스터 값 */
    u32         RxConfigMask;
    void        (*hw_start)(struct rtl8169_private *tp);
};

/* 칩별 초기화 함수 테이블 (일부) */
static const struct rtl_chip_info rtl_chip_infos[] = {
    [RTL_GIGA_MAC_VER_02] = {
        .name         = "RTL8169s",
        .hw_start     = rtl_hw_start_8169,
    },
    [RTL_GIGA_MAC_VER_07] = {
        .name         = "RTL8102e",
        .hw_start     = rtl_hw_start_8102e,
    },
    [RTL_GIGA_MAC_VER_46] = {
        .name         = "RTL8168H",
        .hw_start     = rtl_hw_start_8168h,
    },
    [RTL_GIGA_MAC_VER_63] = {
        .name         = "RTL8125B",
        .hw_start     = rtl_hw_start_8125b,
    },
    /* ... 50개 이상의 칩 버전 엔트리 ... */
};

/* 초기화 시 칩 버전 감지 및 함수 포인터 등록 */
static void rtl_init_one(struct rtl8169_private *tp)
{
    tp->hw_start = rtl_chip_infos[tp->mac_version].hw_start;
}

ASPM L1 조건부 비활성화: 일부 칩(RTL8111B/C 등)은 ASPM L1 절전 상태에서 복귀 시 링크 불안정 현상이 보고되어 있습니다. 드라이버는 칩 버전을 참조하여 오래된 리비전에서 ASPM을 자동으로 비활성화합니다:

/* ASPM quirk 탐지 흐름 */
static void rtl_hw_aspm_clkreq_enable(struct rtl8169_private *tp, bool enable)
{
    /* RTL8411B(VER_46) 이전 칩은 ASPM L1 활성화 금지 */
    if (tp->mac_version < RTL_GIGA_MAC_VER_46)
        return;

    if (enable) {
        RTL_W8(tp, Config2, RTL_R8(tp, Config2) | ClkReqEn);
        RTL_W8(tp, Config5, RTL_R8(tp, Config5) | ASPM_en);
    } else {
        RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
        RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
    }
}

/* PLL 타이밍 quirk: RTL8111B/C는 PLL off 시 복귀 지연 보정 필요 */
static void rtl8168b_hw_start(struct rtl8169_private *tp)
{
    RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Beacon_en);
    /* PLL이 꺼진 상태에서의 wake-up 타이밍 보정 */
    RTL_W16(tp, CPlusCmd, RTL_R16(tp, CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}

커널 트레이싱 레시피

r8169 poll 경로의 성능을 분석하기 위한 ftrace/bpftrace/perf 레시피 모음입니다.

## 1. ftrace function_graph: r8169 poll 경로 전체 추적
echo function_graph > /sys/kernel/debug/tracing/current_tracer
echo 'r8169_poll' > /sys/kernel/debug/tracing/set_graph_function
echo 1 > /sys/kernel/debug/tracing/tracing_on
sleep 1
echo 0 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/trace | head -60

## 2. bpftrace: per-poll 처리 패킷 수 히스토그램 (10초 수집)
bpftrace -e '
kretprobe:r8169_poll {
  @pkt_hist = hist(retval);
}
END { print(@pkt_hist); }
' &
sleep 10 && kill %1

## 3. perf stat: softirq NET_RX 오버헤드 측정
perf stat -e irq:softirq_entry,irq:softirq_exit \
  --filter 'vec == 3' \
  -a sleep 5

## 4. 드라이버 함수 레이턴시 분포 (bpftrace)
bpftrace -e '
kprobe:r8169_poll   { @start[tid] = nsecs; }
kretprobe:r8169_poll {
  $lat = nsecs - @start[tid];
  @lat_us = hist($lat / 1000);
  delete(@start[tid]);
}
interval:s:5 { print(@lat_us); clear(@lat_us); }'

주요 트레이스포인트 목록:

r8125 / RTL8125B: 2.5GbE 심화

RTL8125B 칩셋은 2.5 Gbps 이더넷을 지원하는 소비자용 NIC입니다. 커널 5.9 이후 r8169 모듈이 기본 지원하지만, Realtek 공식 r8125 out-of-tree 드라이버와 기능 차이가 있습니다.

in-tree(r8169) vs out-of-tree(r8125) 비교

# 현재 사용 중인 드라이버 확인
ethtool -i eth0
# driver: r8169  또는  driver: r8125

# 2.5G 링크 속도 확인
ethtool eth0 | grep Speed
# Speed: 2500Mb/s

# out-of-tree r8125 설치 (필요 시)
tar xf r8125-9.012.04.tar.bz2
cd r8125-9.012.04
sudo ./autorun.sh

# r8169 블랙리스트 (out-of-tree 사용 시)
echo "blacklist r8169" | sudo tee /etc/modprobe.d/r8169-blacklist.conf
sudo depmod -a

atlantic 드라이버: Aquantia AQC107/108/113 심화

Aquantia(현 Marvell)의 AQC 시리즈는 임베디드 MIPS 프로세서를 탑재한 고성능 멀티기가비트 NIC입니다. 펌웨어가 MAC/PHY 초기화와 관리를 담당하며, 호스트 드라이버는 메일박스 인터페이스를 통해 펌웨어와 통신합니다. atlantic 드라이버(drivers/net/ethernet/aquantia/atlantic/)는 이 독특한 아키텍처를 반영합니다.

펌웨어 버전 의존성

성능 튜닝

# 펌웨어 버전 확인
ethtool -i aqc0
# firmware-version: 3.1.100

# RSS 해시 키 및 인디렉션 테이블 확인
ethtool -x aqc0

# RSS 인디렉션 테이블 수정 (큐 0,1,2,3 균등 분배)
ethtool -X aqc0 equal 4

# RSS 해시 필드 설정 (TCP 4-tuple)
ethtool -N aqc0 rx-flow-hash tcp4 sdfn

# 링 버퍼 크기 증가
ethtool -G aqc0 rx 4096 tx 4096

# 인터럽트 coalescing 최적화
ethtool -C aqc0 adaptive-rx on adaptive-tx on

# IRQ affinity 설정 (CPU 코어 분산)
echo 1 > /proc/irq/50/smp_affinity  # RXQ0 → CPU0
echo 2 > /proc/irq/51/smp_affinity  # RXQ1 → CPU1
echo 4 > /proc/irq/52/smp_affinity  # RXQ2 → CPU2
echo 8 > /proc/irq/53/smp_affinity  # RXQ3 → CPU3

# Flow steering 규칙 추가 (특정 포트 → 특정 큐)
ethtool -N aqc0 flow-type tcp4 dst-port 80 action 0
ethtool -N aqc0 flow-type tcp4 dst-port 443 action 1

# 통계 확인
ethtool -S aqc0 | grep -E "Queue|rx_packets|tx_packets"

EEE(Energy Efficient Ethernet) 동작 원리

EEE(Energy Efficient Ethernet)는 IEEE 802.3az 표준으로 정의된 전력 절감 기술입니다. 트래픽이 없을 때 링크를 LPI(Low Power Idle) 상태로 전환하여 소비 전력을 줄입니다. AQC(Aquantia) MIPS 펌웨어는 링크 상태와 트래픽 활동을 감시하여 LPI 전환을 제어합니다.

IEEE 802.3az LPI 신호 교환 흐름은 다음과 같습니다: 송신측 MAC이 IDLE 상태를 감지하면 LPI Request 시그널을 PHY에 전달하고, PHY는 링크 파트너와 협의하여 링크를 저전력 모드로 전환합니다. 패킷 전송이 필요해지면 PHY가 링크를 재활성화(Wake)하는데, 이때 PHY 재훈련(retraining) 지연이 발생합니다.

AQC MIPS FW 상태 전환: Active → LPI Request → LPI → Wake → Active

속도별 LPI 이탈 시 wake-up 지연 시간:

# EEE 현재 상태 확인
ethtool --show-eee aqc0

# EEE 전체 비활성화
ethtool --set-eee aqc0 eee off

# 특정 속도에서만 EEE 비활성화 (1G에서만 끄기)
ethtool --set-eee aqc0 advertise 0x0  # 모든 속도 EEE advertisement 제거

# EEE 관련 통계 (드라이버가 제공하는 경우)
ethtool -S aqc0 | grep -i eee

펌웨어 버전 매트릭스 확장

AQC NIC의 기능 지원 여부는 펌웨어 버전에 따라 달라집니다. 다음 표는 주요 FW 버전별 기능 매핑을 정리한 것입니다:

FW 장애 모드 및 대응:

• 메일박스 타임아웃: 드라이버가 FW에 명령을 전송했을 때 aq_hw_fw_state_check()가 응답을 기다리는 동안 타임아웃이 발생합니다. 커널 로그에 FW Mailbox is full 메시지가 나타납니다.
• 체크섬 불일치: FW 이미지 로드 시 CRC 검증 실패. dmesg | grep atlantic에서 FW checksum mismatch 확인.
• 워치독 리셋: FW 내부 MIPS 코어가 응답 불가 시 하드웨어 워치독이 자동으로 FW를 재시작합니다. 링크가 짧게 끊겼다 복구됩니다.

# FW 버전 확인
ethtool -i aqc0 | grep firmware-version

# FW 관련 오류 메시지 조회
dmesg | grep -i "atlantic\|aqc\|firmware\|mailbox"

# FW 응답 상태 확인 (aq_hw_fw_state_check 관련 로그)
dmesg | grep -E "FW|fw_state|mailbox"

# NIC 재초기화로 FW 워치독 리셋 트리거 (링크 재연결)
ip link set aqc0 down && sleep 2 && ip link set aqc0 up

atlantic XDP 특성과 제약

atlantic 드라이버(drivers/net/ethernet/aquantia/atlantic/)는 XDP(eXpress Data Path)를 지원하지만 몇 가지 중요한 제약이 있습니다.

XDP 처리 경로: aq_ring_xdp_clean() 함수가 RX 링에서 패킷을 가져와 XDP 프로그램을 실행합니다. XDP_PASS 시 일반 커널 스택으로, XDP_DROP 시 즉시 드롭, XDP_TX 시 동일 링을 통해 재전송합니다.

XDP_TX 링 재사용 제약: XDP_TX 액션은 동일 RX 링 버퍼를 TX에 재사용합니다. 이로 인해 높은 XDP_TX 비율에서는 RX 링이 소진되어 추가 패킷 수신이 지연될 수 있습니다.

XDP 액션별 성능 비교:

Chelsio: cxgb4

Chelsio Communications는 고성능 서버/데이터센터용 NIC 전문 제조사로, 하드웨어 TCP/IP 오프로드 엔진(TOE), RDMA, 암호화 가속을 내장한 프로토콜 오프로드 어댑터의 선구자입니다. cxgb4 드라이버(drivers/net/ethernet/chelsio/cxgb4/)는 Terminator 5/6(T5/T6) ASIC을 지원합니다.

cxgb4 아키텍처 심화

Chelsio T6 ASIC은 단순한 NIC가 아닌, 전체 네트워크 프로토콜 스택을 하드웨어로 구현한 네트워크 프로세서입니다. 주요 구성 요소는 MPS(MAC/Port Switch), TP(TCP/IP Processing Engine), ULP(Upper Layer Protocol Engine), SGE(Scatter-Gather Engine), 그리고 암호화 가속기입니다.

T5 vs T6 비교

SGE(Scatter-Gather Engine) 모델

SGE는 호스트 CPU와 ASIC 사이의 DMA 전송을 관리하는 핵심 엔진입니다. 각 큐페어(Queue Pair)는 TX 큐, RX 큐(Ingress Queue), Free List(FL), 그리고 응답 큐(Response Queue)로 구성됩니다. 호스트 드라이버는 Doorbell 레지스터에 쓰기 연산을 수행하여 새로운 설명자를 ASIC에 통지합니다.

# cxgb4 드라이버 로드 상태 확인
lsmod | grep cxgb4

# ASIC 세대 및 포트 정보 확인
ethtool -i eth0
# driver: cxgb4
# firmware-version: 1.27.1.0

# SGE 큐 구성 확인
ethtool -l eth0
# Combined: 16 (현재) / 256 (최대)

# 큐 수 변경 (CPU 코어 수에 맞춤)
ethtool -L eth0 combined 32

# 링 버퍼 크기 조정
ethtool -G eth0 rx 8192 tx 8192

# 인터럽트 coalescing (지연 시간 vs 처리량 트레이드오프)
ethtool -C eth0 rx-usecs 10 rx-frames 64

# 드라이버 내부 통계 확인
ethtool -S eth0 | head -40

# PCIe 대역폭 확인
lspci -vvs $(ethtool -i eth0 | grep bus-info | awk '{print $2}') | grep -i width

cxgb4 오프로드 엔진

Chelsio의 핵심 차별점은 프로토콜 오프로드입니다. TOE(TCP Offload Engine)는 TCP 상태 머신 전체를 ASIC에서 실행하여 호스트 CPU 부하를 극적으로 줄이며, RDMA(iw_cxgb4)는 제로카피 데이터 전송을 가능하게 합니다.

오프로드 성능 영향

# RDMA (iw_cxgb4) 모듈 로드 확인
lsmod | grep iw_cxgb4

# RDMA 디바이스 목록
rdma link show

# RDMA 성능 테스트 (서버 측)
ib_write_bw -d cxgb4_0 --report_gbits

# RDMA 성능 테스트 (클라이언트 측)
ib_write_bw -d cxgb4_0 192.168.1.100 --report_gbits

# TLS offload 확인 (T6 전용)
ethtool -k eth0 | grep tls
# tls-hw-tx-offload: on
# tls-hw-rx-offload: on

# TLS offload 활성화
ethtool -K eth0 tls-hw-tx-offload on tls-hw-rx-offload on

# iSCSI offload 상태 확인
iscsiadm -m iface | grep cxgb4

# 오프로드 통계 확인
ethtool -S eth0 | grep -E "toe_|rdma_|tls_"

TOE 성능 분석

TOE는 모든 워크로드에서 이득을 주는 것이 아니다. 연결 수와 트래픽 패턴에 따라 이득과 손해가 달라진다.

Crypto 오프로드 파이프라인

Chelsio T6 ASIC은 TLS 인라인 암호화와 IPsec 오프로드를 지원한다. kTLS TX 경로에서 소켓 레이어가 TLS 레코드를 구성하면, T6 crypto engine이 와이어로 나가기 전 AES-GCM 암호화를 수행한다. 이 과정에서 CPU는 TLS 레코드 메타데이터만 처리하고, 실제 암호화 연산은 ASIC이 전담한다.

# kTLS TX 오프로드 cxgb4 활성화
ethtool -K eth0 tls-hw-tx-offload on

# kTLS 오프로드 상태 확인
ethtool -k eth0 | grep tls
# tls-hw-tx-offload: on
# tls-hw-rx-offload: on (T6 지원)

# TLS 오프로드 통계 확인
ethtool -S eth0 | grep tls_
# tls_tx_sw_fallback: 0   (SW 폴백 없으면 HW 오프로드 정상)
# tls_tx_hw_records: 1234567

# IPsec 오프로드 상태 확인
ip xfrm state list
ethtool -k eth0 | grep esp
# esp-hw-offload: on

# 오프로드 연결 수 확인
ethtool -S eth0 | grep -E "toe_conn|tls_conn"

cxgb4 패킷 분류 파이프라인

T6 ASIC은 하드웨어 기반 다단계 패킷 분류 파이프라인을 제공합니다. MPS(MAC Port Switch)에서 L2 필터링 후, TP(TCP/IP Engine)에서 프로토콜 매칭과 TCAM/해시 기반 필터를 적용하여 최종적으로 적절한 SGE 큐로 패킷을 전달합니다. 이 파이프라인은 tc flower 오프로드를 통해 소프트웨어적으로도 제어 가능합니다.

필터 설정 및 tc offload

# TCAM 필터: 특정 목적지 IP의 패킷을 큐 5로 전달
ethtool -N eth0 flow-type tcp4 dst-ip 10.0.0.100 action 5

# 설정된 필터 규칙 확인
ethtool -n eth0

# tc flower 오프로드 (하드웨어 가속 필터)
tc qdisc add dev eth0 ingress

# 소스 IP 기반 패킷 드롭 (하드웨어 오프로드)
tc filter add dev eth0 ingress protocol ip flower \
    src_ip 192.168.1.0/24 \
    skip_sw \
    action drop

# VLAN + 목적지 포트 기반 큐 스티어링
tc filter add dev eth0 ingress protocol 802.1Q flower \
    vlan_id 100 \
    dst_port 8080 \
    skip_sw \
    action skbedit queue_mapping 3

# 오프로드된 필터 통계 확인
tc -s filter show dev eth0 ingress

# 하드웨어 tc offload 기능 확인
ethtool -k eth0 | grep hw-tc-offload
# hw-tc-offload: on

# 하드웨어 tc offload 활성화
ethtool -K eth0 hw-tc-offload on

Cloud NIC: ENA / gVNIC

ENA (Elastic Network Adapter) 아키텍처

ENA는 AWS Nitro 하이퍼바이저와 통합된 네트워크 어댑터로, EC2 인스턴스에 고성능 네트워크 I/O를 제공합니다. ENA 디바이스는 Admin Queue를 통한 제어 경로와 I/O Submission/Completion Queue를 통한 데이터 경로를 분리하여 효율적인 패킷 처리를 달성합니다.

아키텍처 개요

ENA 드라이버는 struct ena_adapter를 중심으로 동작합니다. 초기화 시 Admin Queue를 통해 디바이스와 협상하여 지원 기능, 큐 수, MTU 등을 결정합니다. 데이터 전송은 I/O SQ(Submission Queue)에 디스크립터를 기록하고 MMIO doorbell을 울려 디바이스에 통보하는 방식입니다. 완료된 패킷은 CQ(Completion Queue)를 통해 NAPI 폴링으로 처리됩니다.

LLQ (Low Latency Queue) vs Regular Queue

ENA는 두 가지 큐 동작 모드를 지원합니다. Regular 모드에서는 디스크립터와 패킷 데이터가 모두 호스트 메모리에 존재하며, 디바이스가 DMA로 읽어갑니다. LLQ(Low Latency Queue) 모드에서는 디스크립터와 패킷 헤더를 디바이스 메모리(BAR 공간)에 직접 기록하여 DMA 왕복 지연을 제거합니다.

ENA Express (SRD — Scalable Reliable Datagram)

ENA Express는 AWS가 개발한 SRD(Scalable Reliable Datagram) 프로토콜을 활용하여 단일 흐름(single flow)의 대역폭을 최대 25 Gbps까지 확장하고, p99 지연 시간을 크게 줄이는 기능입니다. 전통적인 TCP/UDP는 5-tuple 해싱으로 단일 경로에 바인딩되지만, SRD는 여러 물리 경로에 패킷을 분산하고 수신 측에서 재정렬합니다.

인스턴스 타입별 ENA 기능 매트릭스