SR-IOV VF를 VM에 직결하면서 Open vSwitch(OVS) 로 테넌트 스위칭을, TC Flower 하드웨어 오프로드(Intel E810)로 ACL을 처리하면 OVS에 도달하기 전 패킷을 NIC에서 바로 거를 수 있다. 이 글은
- 왜 hw-offload=true 한 줄로 가능해지는지
- VXLAN·다중 브리지 구조에서 실제로 오프로드가 일어나는 조건
- OVS-DPDK와 비교해 얻거나 잃는 것
을 다룬다.
1. OVS Kernel Datapath + TC Flower 오프로드 흐름
- OpenFlow 룰 추가
사용자는 평소처럼 ovs-ofctl add-flow … 로 정책을 넣는다. - OVS가 커널 플로우 생성
커널 모듈 openvswitch.ko 가 datapath 룰을 캐싱한다. - HW-offload가 켜져 있으면 (other_config:hw-offload=true)
OVS 커널 모듈이 해당 룰을 Netlink 로 TC Flower 필터로 변환해 NIC 드라이버(ice)에 전달한다. - NIC가 룰을 수용할 수 있으면 offloaded 로 표시되고, 이후 패킷은
VF → NIC 내부 포워딩 → 다른 VF/PF 로 바로 전송된다.
OVS 브리지를 두 번(br-int, br-ext) 거치는 논리적 경로가 실제로는 NIC 안에서 단 번에 해결된다.
핵심 조건
필수 조건 설명
| Kernel datapath | userspace DPDK 모드에서는 TC Flower를 쓰지 못한다. |
| hw-offload=true | OVSDB 전역 설정. |
| 같은 PF 내 VF | 하드웨어 스위치 테이블이 두 VF 간 직접 포워딩을 지원해야 한다. |
| 매치·액션 제약 | NIC가 지원하지 않는 필드는 소프트웨어 경로로 빠진다. |
2. 다중 브리지(br-int ↔ br-ext) 구조
구성
VM ── VF1 ── br-int ── patch-port ── br-ext ── VF2 ── External
- VF1·VF2 모두 Intel E810 PF 0에 속한다고 가정
- OpenFlow 예
# br-int: 테넌트 → 외부
ovs-ofctl add-flow br-int \
"priority=100,in_port=VF1,ip actions=output:patch-ext"
# br-ext: 외부 포트로 내보내기
ovs-ofctl add-flow br-ext \
"priority=100,in_port=patch-int,ip actions=output:VF2"
OVS는 위 두 룰을 하나의 mirred redirect 로 단순화해 tc filter 로 NIC에 올리므로 VF1→VF2 트래픽은 커널을 통과하지 않는다. tc filter show dev VF1 ingress 로 offloaded 표기를 확인할 수 있다.
VXLAN이라면 tun_id=N(OpenFlow) → enc_key_id N(Flower) 로 변환되어 동일하게 오프로드된다. 단, E810은 내부(L3/L4) 필드를 하드웨어에서 파싱하지 못한다. 내부 필터링이 필요하면 eBPF XDP 또는 skip_hw TC 필터를 병행해야 한다.
3. OVS-DPDK와의 비교
항목 Kernel DP + TC Flower OVS-DPDK
| HW 오프로드 방식 | 커널이 TC Flower 룰 생성, NIC 스위치 테이블 활용 | DPDK PMD Fast path, NIC offload 일부(Flow Director 등) |
| 브리지 수가 많을 때 | 룰을 NIC로 내려 CPU 부담 낮음 | 룰 수↑ → userspace table lookup 비용 증가 |
| VXLAN 처리 | VNI 매치·포워드까지 오프로드 가능 | VNI는 PMD 내 SW 처리, CPU 사용 |
| 지원 NIC | Flower offload 지원 카드(ice, mlx5 등) | DPDK PMD가 존재하는 거의 모든 카드 |
| eBPF 결합 | XDP/TC 혼용 쉬움 | eBPF, TC 경로와 분리되어 설정 복잡 |
| 최대 성능 | NIC 매치·포워드 한계까지 도달 | CPU 스레드 수와 NUMA 배치에 영향 |
| 운용 편의 | OpenFlow만 관리, TC 자동화 | 기존 OVS-DPDK 경험 필요 |
| 한계 | 복잡한 매치/액션(ConnTrack 등) 미지원 | HW offload 비중 낮아 CPU 부하 우려 |
4. 실무 체크리스트
- ice 드라이버와 펌웨어를 최신으로 유지해 TC Flower capability bitmap이 충분한지 확인.
- ethtool -k VF | grep flower 로 오프로드 가능 상태 점검.
- OVSDB:
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
ovs-vsctl set Open_vSwitch . other_config:max-idle=30000 # 플로우 재생성 최소화
- 디버깅
- ovs-appctl dpctl/show –s : offloaded flow 수
- tc -s filter show dev VF ingress : 하드웨어 카운터 증가 확인
- VXLAN을 쓴다면 VNI당 룰 수가 NIC 제한(예: 8k) 아래인지 체크.
5. 맺으며
OVS Kernel Datapath에 hw-offload=true 한 줄을 더하면, OpenFlow 정책이 자동으로 TC Flower 룰로 번역돼 Intel E810 같은 최신 NIC 하드웨어에 실린다. VM → br-int → br-ext → 외부로 이어지는 길도 NIC 내부 Fast path로 바뀌어 CPU 소모와 지연을 동시에 줄일 수 있다. 다만 ConnTrack, L4-LB, 내부 VXLAN 필터링 같은 고급 기능은 여전히 소프트웨어 경로가 필요하므로, 필요에 따라 XDP/eBPF나 DPDK를 병행해 설계를 완성하자.