# Generic Receive Offload (GRO)

## 1. 개요
**Generic Receive Offload (GRO)**는 네트워크 인터페이스 카드(NIC)를 통해 수신되는 다수의 작은 TCP 세그먼트들을 상위 네트워크 스택으로 전달하기 전에 하나의 큰 패킷으로 병합하여 처리하는 네트워크 최적화 기술이다.

현대 고속 네트워크 환경에서 패킷 하나하나를 개별적으로 처리할 경우, 매 패킷마다 발생하는 인터럽트(Interrupt, 하드웨어 신호를 통해 CPU에 이벤트를 알리는 메커니즘)와 프로토콜 스택 처리 비용으로 인해 CPU 부하가 급격히 증가한다. GRO는 이러한 오버헤드를 줄이기 위해 수신 단계에서 유사한 패킷들을 묶어 처리함으로써 CPU 효율성을 극대화하고 전체적인 네트워크 처리량을 향상시키는 역할을 수행한다.

## 2. 동작 원리
GRO는 수신된 패킷들이 동일한 흐름(Flow, 동일한 출발지/목적지 IP 및 포트 번호를 가진 패킷 집합)에 속하는지 확인하고, 연속적인 시퀀스 번호를 가진 TCP 세그먼트들을 하나의 거대한 패킷으로 병합한다.

### 2.1 처리 메커니즘
1. **패킷 수신**: NIC가 네트워크로부터 작은 크기의 TCP 세그먼트들을 수신한다.
2. **흐름 분석**: GRO 엔진이 패킷의 헤더를 분석하여 동일한 연결(Connection)인지 확인한다.
3. **병합 결정**: 수신된 패킷이 이전 패킷과 연속적인 시퀀스 번호를 가지고 있으며, 옵션 등이 일치하는지 검증한다.
4. **데이터 통합**: 조건이 충족되면 페이로드(Payload, 실제 전송 데이터)를 하나로 합치고 헤더 정보를 업데이트한다.
5. **전달 트리거**: 설정된 타임아웃(Timeout) 시간이 경과하거나, 병합된 패킷이 최대 크기(Max Segment Size/MTU 제한)에 도달하면 전달 단계로 진입한다.
6. **상위 전달**: 병합된 거대 패킷을 네트워크 스택(IP → TCP)으로 한 번에 전달한다.

### 2.2 패킷 처리 흐름 비교

| 구분 | GRO 적용 전 (Standard) | GRO 적용 후 (Optimized) |
| :--- | :--- | :--- |
| **패킷 단위** | 개별 세그먼트 단위 처리 (예: 1,500 bytes $\times$ 10개) | 병합된 거대 패킷 단위 처리 (예: 15,000 bytes $\times$ 1개) |
| **인터럽트 발생** | 패킷 수신 시마다 빈번하게 발생 | 병합 주기 또는 임계치 도달 시 발생 |
| **스택 통과 횟수** | 각 패킷이 IP/TCP 계층을 개별적으로 통과 | 하나의 큰 패킷이 한 번만 통과 |
| **CPU 부하** | 헤더 분석 및 컨텍스트 스위칭 비용 높음 | 처리 횟수 감소로 인한 CPU 사이클 절약 |

### 2.3 동작 시퀀스 다이어그램
```mermaid
sequenceDiagram
    participant NIC as Network Interface Card
    participant GRO as GRO Engine (Driver/Kernel)
    participant Stack as Network Stack (IP/TCP)
    participant App as Application

    NIC->>GRO: TCP Segment 1 (Seq: 1-1460)
    GRO->>GRO: Buffer & Analyze
    NIC->>GRO: TCP Segment 2 (Seq: 1461-2920)
    GRO->>GRO: Merge Segment 1 + 2
    NIC->>GRO: TCP Segment 3 (Seq: 2921-4380)
    GRO->>GRO: Merge Segment 1+2 + 3
    GRO->>Stack: Large Merged Packet (Seq: 1-4380)
    Stack->>App: Deliver Data
```

## 3. 하드웨어 GRO vs 소프트웨어 GRO
GRO는 구현 위치에 따라 하드웨어 방식과 소프트웨어 방식으로 구분된다.

### 3.1 하드웨어 GRO (Hardware GRO)
NIC 하드웨어 칩셋 자체에서 패킷 병합을 수행하는 방식이다. CPU의 개입 없이 하드웨어 레벨에서 처리되므로 CPU 부하 감소 효과가 가장 크지만, NIC 제조사의 펌웨어 및 하드웨어 설계에 의존적이다.

### 3.2 소프트웨어 GRO (Software GRO)
리눅스 커널의 네트워크 드라이버 계층에서 소프트웨어적으로 패킷을 병합하는 방식이다. 하드웨어 제약 없이 범용적으로 적용 가능하며, 커널이 패킷의 무결성을 더 정밀하게 검사할 수 있어 안정성이 높다.

## 4. LRO(Large Receive Offload)와의 차이점
GRO는 LRO의 한계를 극복하기 위해 등장한 기술이다. LRO는 하드웨어에서 공격적으로 패킷을 병합하지만, 이 과정에서 TCP 헤더의 일부 정보가 손실되거나 변형될 수 있는 문제가 있었다.

### 4.1 주요 차이점 분석

| 비교 항목 | LRO (Large Receive Offload) | GRO (Generic Receive Offload) |
| :--- | :--- | :--- |
| **구현 위치** | 주로 NIC 하드웨어 | 하드웨어 및 커널 소프트웨어 |
| **데이터 무결성** | 헤더 정보 일부 손실 가능성 있음 | 원본 패킷 정보 보존 및 정밀 검증 |
| **투명성** | 프로토콜 투명성 결여(원본 헤더 정보 손실) | 프로토콜 투명성 유지(원본 정보 보존) |
| **라우팅 적합성** | 패킷 변형으로 인해 포워딩 시 문제 발생 | 원본 복원이 가능하여 라우팅/브릿징 가능 |
| **의존성** | 특정 NIC 하드웨어 기능 필요 | 범용적인 커널 지원으로 구현 가능 |

## 5. 장점 및 기대 효과
1. **CPU 오버헤드 감소**: 패킷당 발생하는 인터럽트 횟수와 커널 스택 처리 횟수가 획기적으로 줄어들어 CPU 사이클을 절약할 수 있다.
2. **처리량(Throughput) 향상**: CPU 병목 현상이 해소됨에 따라 10Gbps 이상의 고속 네트워크 환경에서 실제 데이터 전송 속도가 증가한다.
3. **캐시 효율성 증대**: 작은 패킷을 여러 번 처리하는 대신 큰 덩어리로 처리함으로써 CPU 캐시 적중률(Cache Hit Rate)이 향상되며, 이는 메모리 대역폭 사용 효율을 높여 전반적인 시스템 성능을 최적화한다.

### 5.1 성능 측정 벤치마크 예시 (가상 시나리오)
10Gbps 환경에서 TCP 스트림 전송 시 CPU 사용률 및 처리량 변화 예시이다.

| 설정 상태 | 처리량 (Throughput) | CPU 사용률 (Core 0) | 패킷 처리 수 (pps) |
| :--- | :--- | :--- | :--- |
| **GRO Off** | 6.2 Gbps | 85% | 812,000 pps |
| **GRO On** | 9.4 Gbps | 32% | 120,000 pps (병합 후) |

## 6. 설정 및 확인 방법
리눅스 시스템에서는 `ethtool` 또는 `etctl` 유틸리티를 사용하여 GRO 상태를 관리한다.

### 6.1 상태 확인
현재 네트워크 인터페이스의 GRO 활성화 여부를 확인한다.
```bash
# ethtool을 이용한 설정 확인
ethtool -k eth0 | grep generic-receive-offload

# etctl을 이용한 설정 확인
etctl get gro eth0
```
*출력 예시: `generic-receive-offload: on`*

### 6.2 활성화 및 비활성화
관리자 권한으로 GRO 설정을 변경할 수 있다.
```bash
# ethtool을 이용한 설정 변경
sudo ethtool -K eth0 gro on   # 활성화
sudo ethtool -K eth0 gro off  # 비활성화

# etctl을 이용한 설정 변경
sudo etctl set gro eth0 on    # 활성화
sudo etctl set gro eth0 off   # 비활성화
```

## 7. 주의사항 및 한계
GRO가 항상 유리한 것은 아니며, 특정 환경에서는 오히려 독이 될 수 있다.

1. **지연 시간(Latency) 증가**: 패킷을 병합하기 위해 일정 시간 동안 버퍼링을 수행하므로, 패킷이 즉시 상위 스택으로 전달되지 않고 대기하는 시간이 발생한다. 이로 인해 극도로 낮은 지연 시간이 필요한 실시간 서비스(예: HFT, 실시간 게임 서버)에서는 지연 시간이 소폭 증가하여 성능 저하를 유발할 수 있다.
2. **네트워크 중간 장비(Bridge/Router) 부작용**:
    - 서버가 단순 엔드포인트가 아니라 패킷을 다른 곳으로 전달하는 **브릿지(Bridge)**나 **라우터(Router)** 역할을 하는 경우, 병합된 거대 패킷이 다시 쪼개지는 과정에서 오버헤드가 발생하거나 MTU(Maximum Transmission Unit) 문제가 발생할 수 있다.
    - 따라서 리눅스 브릿지 환경에서는 일반적으로 GRO를 비활성화하는 것이 권장된다.
3. **패킷 분석의 어려움**: `tcpdump`와 같은 툴로 패킷을 캡처할 때, 실제 네트워크에 흐르는 작은 패킷이 아닌 병합된 거대 패킷이 보이므로 분석 시 혼동을 줄 수 있다. 이를 해결하기 위해서는 GRO를 일시적으로 끄고 캡처하거나, 캡처 지점을 GRO 적용 전 단계(NIC 드라이버 이전)로 설정해야 한다.