Skip to main content

OVS Phần 15: Hardware Offload — TC Flower và SmartNIC/DPU

Phần 15/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 14, nơi Mục 5 đã chỉ ra cái giá thật của DPDK: dù nhanh hơn hẳn kernel datapath, DPDK vẫn bắt một hoặc nhiều core CPU "hi sinh" để poll liên tục (pmd-sleep-max=0 mặc định). Bài 15 đi tiếp một bước nữa theo đúng hướng Bài 14 Mục 5 đã gợi mở: nếu ngay cả một core CPU chạy 100% cũng không còn đáng đánh đổi, hoặc traffic đã vượt quá khả năng của bất kỳ core CPU nào dù dùng DPDK, bước tiếp theo là đẩy hẳn việc chuyển mạch ra khỏi CPU — xuống thẳng phần cứng NIC. Đây là bài thứ tư của Module 3 — Nâng cao, sau OpenFlow pipeline sâu (Bài 12), connection tracking (Bài 13) và DPDK (Bài 14). Sau bài này, Bài 16 sẽ chuyển sang giám sát (sFlow, IPFIX, port mirroring).

Mục tiêu bài học: sau bài này bạn hiểu đúng cơ chế TC flower — bộ phân loại gói của phân hệ Traffic Control (TC) trong kernel Linux — được OVS dùng làm cầu nối để đẩy flow xuống phần cứng; phân biệt được ba mô hình offload trong kiến trúc OVS (kernel thuần, offload thẳng xuống SmartNIC, và mô hình OvS-TC dùng TC làm trung gian — đúng mô hình hw-offload=true sử dụng); biết cấu hình thật qua OVSDB (hw-offload, tc-policy, hw-offload-priority) và cách xác nhận một flow đã thật sự nằm trong phần cứng; và phân biệt được offload lên một NIC thường (TC flower, một ASIC cố định) với offload lên SmartNIC/DPU (có compute riêng, chạy được cả một phần datapath).

Ba câu hỏi mà bài này trả lời:

  1. TC flower là gì, và cơ chế nào cho phép OVS đẩy một flow entry từ kernel datapath xuống thẳng phần cứng NIC?
  2. Ba mô hình offload (kernel thuần, offload thẳng SmartNIC, OvS-TC) khác nhau ở điểm nào, và OVS mặc định dùng đúng mô hình nào khi bật hw-offload=true?
  3. NIC offload thông thường khác gì về bản chất so với SmartNIC/DPU, và những giới hạn nào cần biết trước khi đưa hardware offload vào production?

Mục lục​

1. TC flower là gì và vì sao cần offload​

Động lực chính thức được chính dự án OVS nêu ra chỉ gồm đúng hai gạch đầu dòng, không màu mè: "Provide greater throughput" và "Increase CPU core efficiency and scalability" — trích từ bài trình bày "OvS Hardware Offload with TC Flower" của Simon Horman (Netronome) tại Open vSwitch 2017 Fall Conference, tài liệu do chính dự án OVS lưu trữ tại openvswitch.org/support/. Đặt cạnh Bài 14: DPDK đã giải quyết được vế tốc độ bằng cách bỏ qua kernel, nhưng vẫn tiêu tốn nguyên vẹn một core CPU cho việc poll. Hardware offload đi xa hơn — không chỉ bỏ qua kernel network stack, mà bỏ qua luôn cả việc dùng CPU host để ra quyết định forward cho từng gói đã có flow từ trước.

Cơ chế đứng sau là TC flower — một bộ phân loại gói (classifier) thuộc phân hệ Traffic Control (TC) vốn có sẵn trong kernel Linux từ lâu, ban đầu dùng cho QoS/shaping. Tài liệu chính thức mô tả đúng vai trò của nó: "Packet classifier for Linux kernel traffic classification (TC) subsystem", cho phép khớp gói theo nhiều loại trường khác nhau — "Packet headers: f.e. IPv6 source address", "Tunnel metadata: f.e. Tunnel Key ID", "Metadata: Input port" — và thực thi hành động khi khớp, ví dụ "pedit: modify packet data", "mirred: output packet", "vlan: push, pop or modify VLAN". Cú pháp thật của TC flower đứng độc lập, không qua OVS, minh họa đúng ví dụ chính thức — chặn gói TCP cổng đích 80 trên eth0:

tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
    flower ip_proto tcp dst_port 80 \
    action drop

💡 Hình dung như thế này: nếu kernel datapath (Bài 3) giống một nhân viên đứng giữa nhà kho tự tay kiểm tra và phân loại từng thùng hàng đi qua, thì TC flower giống việc dán sẵn một quy tắc phân loại vào đúng băng chuyền ở cổng ra — không cần nhân viên đó đứng nhìn nữa, cái băng chuyền (phần cứng NIC) tự khớp nhãn thùng hàng và đẩy đi đúng hướng. TC flower không phải công nghệ riêng của OVS — nó là cơ chế phân loại gói có sẵn của kernel; OVS chỉ là một trong những "khách hàng" biết cách dùng nó để đẩy flow xuống phần cứng.

TC flower không phải tính năng mới toanh song hành cùng OVS — theo đúng lịch sử được ghi trong slide "Status" của bài trình bày trên: "TC Flower — Initially added in Linux kernel v4.2", còn việc OVS biết dùng TC flower để offload chỉ xuất hiện sau đó: "Offload Integration in OvS — Included in OvS v2.8", và với driver NIC cụ thể của Netronome (NFP) thì "Basic offload support present since Linux kernel v4.13" — ba cột mốc tách biệt: bản thân TC flower, khả năng OVS biết dùng nó, và driver NIC biết nhận offload từ nó.

2. Ba mô hình offload trong kiến trúc OVS​

Trước khi vào ba mô hình, cần một định nghĩa ngắn cho một từ sẽ xuất hiện liên tục từ đây: SmartNIC là cách gọi chung cho một NIC có thêm compute lập trình được ngay trên card (thay vì chỉ là mạch cố định nhận/gửi gói) — Mục 4 sẽ đào sâu nó khác NIC thường ở điểm nào, ở đây chỉ cần hiểu nó là "một loại phần cứng offload có khả năng cao hơn ASIC cố định". Cùng bài trình bày chính thức trên minh họa chính xác ba cách một packet có thể đi qua hệ thống, tăng dần mức độ offload — cần phân biệt rõ vì hw-offload=true chỉ bật đúng một trong ba mô hình này, không phải mô hình đơn giản nhất:

Ba Mô Hình Offload Trong Kiến Trúc OVSNguồn: "OvS Hardware Offload with TC Flower", Open vSwitch 2017 Fall Conference (openvswitch.org)1. Kernel Datapath (Bài 3)2. OVS Datapath Hooks3. OvS-TC (hw-offload=true)ovs-vswitchd (user-space)ovs-vswitchd (user-space)ovs-vswitchd (user-space)misses,flows,statsflows,stats,missesflows,stats,missesKernel: OVS DatapathKernel: OVS DatapathKernel:OVS DatapathKernel:TC Datapathmiss(bỏ qua TC, đi thẳng)flows,stats,misses(không có phần cứng offload)SmartNIC DatapathSmartNIC Datapath (hoặc ASIC NIC)packet →gói vào/ra NIC vật lý ở mỗi mô hìnhMọi flow đều xử lýbằng CPU host, trongkernel — đúng Bài 3,chưa offload gì cảOVS Datapath gọi thẳnghook xuống SmartNIC,KHÔNG qua TC — cầndriver SmartNIC riêngTC Datapath làm trunggian — chuẩn hóa, dùngchung cho mọi NIC hỗtrợ hw-tc-offload"Try to offload each flow (f.e. By adding to TC Flower). If unsuccessful then add to software datapath"Mô hình 3 (OvS-TC) là mô hình OVS thật sự dùng khi bật other_config:hw-offload=true— TC flower là lớp trừu tượng chung, không cần biết SmartNIC hãng nào ở phía dưới

Điểm mấu chốt nằm ở mô hình thứ ba — gọi tắt là OvS-TC. Thay vì ovs-vswitchd phải tự viết driver riêng cho từng loại SmartNIC (mô hình 2, "OVS Datapath Hooks"), OVS đi qua một lớp trung gian chung: TC Datapath trong kernel. Cách tích hợp được mô tả rất ngắn gọn trong slide "Offload Integration in OvS": "New netdev ops called by DPIF layer", "Try to offload each flow ... f.e. By adding to TC Flower", và nếu không offload được thì "If unsuccessful then add to software datapath ... f.e. kernel datapath". Nói cách khác: mỗi khi kernel datapath (Bài 3) gặp một flow mới cần cài vào cache, OVS thử đẩy nó xuống TC flower trước; TC flower lại tự quyết định đẩy tiếp xuống phần cứng bên dưới (ASIC NIC thường hoặc SmartNIC) nếu driver hỗ trợ; chỉ khi không offload được, flow đó mới rơi lại vào kernel datapath thuần túy xử lý bằng CPU như trước giờ. Đây chính là hành vi đứng sau tham số hw-offload=true mà Mục 3 sẽ cấu hình. Cần nói rõ: mô hình 1 và 2 trong sơ đồ trên chủ yếu mang tính minh họa động lực thiết kế — bài trình bày dùng chúng để giải thích vì sao OvS-TC ra đời, không khẳng định cả ba mô hình đang cùng chạy song song trong production. Mô hình 1 (kernel thuần) luôn tồn tại mặc định khi chưa bật offload; còn OvS-TC vẫn là con đường mà mã nguồn OVS hiện hành thực sự đăng ký làm nhà cung cấp offload cho TC (netdev_offload_tc), đúng hành vi "thử offload xuống TC, thất bại thì rơi lại kernel" vẫn giữ nguyên tới các bản OVS mới nhất.

3. Cấu hình thật trong OVSDB: hw-offload và tc-policy​

Toàn bộ cấu hình nằm trong cột other_config của bảng Open_vSwitch, trích nguyên văn ovs-vswitchd.conf.db(5):

Cột other_configÝ nghĩa (trích nguyên văn)
hw-offload"Set this value to true to enable netdev flow offload. The default value is false. Changing this value requires restarting the daemon. Currently Open vSwitch supports hardware offloading on Linux systems. On other systems, this value is ignored. This functionality is considered 'experimental'. Depending on which OpenFlow matches and actions are configured, which kernel version is used, and what hardware is available, Open vSwitch may not be able to offload functionality to hardware."
tc-policy"Specified the policy used with HW offloading." Ba giá trị: none — "Add software rule and offload rule to HW" (mặc định); skip_sw — "Offload rule to HW only"; skip_hw — "Add software rule without offloading rule to HW".
hw-offload-priority"This configuration sets the order of the hardware offload providers to try when multiple exist for a given datapath implementation... The default value is tc,dpdk. Changing this value requires restarting the daemon if hardware offload is already enabled."
n-offload-threadsSố luồng xử lý offload, giá trị 1-10, mặc định 1 — chỉ áp dụng cho userspace datapath (Bài 3, Bài 14) kèm hardware offload.
offloaded-stats-delayĐộ trễ tối đa (ms) trước khi số liệu thống kê của flow đã offload được cập nhật — mặc định 2000ms.
offload-rebalanceBật/tắt cân bằng lại offload khi thiết bị offload hết tài nguyên — yêu cầu tc-policy=skip_sw.

Dòng hw-offload-priority đáng chú ý nhất khi đặt cạnh Bài 14: giá trị mặc định tc,dpdk xác nhận có hai nhà cung cấp offload khác nhau cho cùng một tính năng — tc là con đường TC flower vừa học ở Mục 2 (dùng cho kernel/userspace datapath thường), còn dpdk là con đường offload riêng cho userspace+DPDK (Bài 14), dùng cơ chế rte_flow của chính DPDK thay vì TC flower của kernel — vì port DPDK không đi qua kernel network stack nên không thể dùng TC. Chi tiết rte_flow nằm ngoài phạm vi tài liệu OVS đã trích ở bài này — cần verify thêm qua tài liệu DPDK Programmer's Guide nếu triển khai thật trên OVS-DPDK.

Bật hardware offload chỉ cần đúng một lệnh, đã lặp lại y hệt trong mọi nguồn chính thức trích ở trên:

sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
sudo systemctl restart openvswitch-switch    # bắt buộc, giống dpdk-init ở Bài 14

Ba giá trị tc-policy — thực chất là ánh xạ trực tiếp từ hai cờ gốc của chính TC flower ở tầng kernel, đã tồn tại từ trước khi OVS dùng tới: "skip_hw and skip_sw flags — Allow users to influence placement of flows by kernel. Default is to add to hardware and try to add to software", và kernel còn tự báo cáo lại kết quả bằng cờ thứ ba: "in_hw and not_in_hw flags — Allow kernel to report presence of flow in hardware". Man page hiện hành của chính tc-flower(8) mô tả skip_sw cụ thể hơn, và đây là chi tiết dễ bị hiểu lầm nhất: "Do not process filter by software. If hardware has no offload support for this filter, or TC offload is not enabled for the interface, operation will fail." — nghĩa là skip_sw (tương ứng tc-policy=skip_sw của OVS) không phải "cứ thử offload, không được thì thôi" — nếu NIC/driver không hỗ trợ offload cho đúng rule đó, hành động thêm rule sẽ thất bại hẳn, không có phương án dự phòng nào âm thầm chạy bằng software. Ví dụ chính thức đặt một rule TC flower chỉ vào phần cứng (không cần qua OVS):

tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: \
    flower skip_sw ip_proto sctp dst_port 80 \
    action drop

Xác nhận rule đã thật sự nằm trong phần cứng bằng đúng field in_hw xuất hiện trong output tc filter show:

tc filter show dev eth0 ingress
# Output minh họa đúng cấu trúc trong tài liệu chính thức (Open vSwitch 2017 Fall Conference)
filter parent ffff: protocol ip
 pref 49152 flower chain 0
  handle 0x1
  eth_type ipv4
  ip_proto sctp
  dst_port 80
  skip_sw
  in_hw
...

Ngoài cờ skip_hw/skip_sw đặt theo từng rule, còn có một công tắc riêng bật/tắt toàn bộ khả năng offload của cả một netdev, độc lập với hw-offload của OVS — nằm ở tầng driver NIC, dùng ethtool:

ethtool -K eth0 hw-tc-offload on
ethtool -K eth0 hw-tc-offload off

Hai công tắc này không thay thế nhau: other_config:hw-offload=true là công tắc tổng ở tầng ovs-vswitchd (có offload hay không), còn ethtool -K <iface> hw-tc-offload on là công tắc ở tầng driver NIC (NIC đó có được phép nhận offload hay không) — thiếu một trong hai, flow sẽ không bao giờ xuống được tới in_hw.

4. NIC offload thường và SmartNIC, DPU khác nhau ở đâu​

Câu hỏi cốt lõi: TC flower ở Mục 1-3 áp dụng được cho bất kỳ NIC nào có driver hỗ trợ hw-tc-offload, nhưng "SmartNIC" hay "DPU" là một khái niệm khác — không phải cứ hỗ trợ TC flower là thành SmartNIC. Điểm phân biệt nằm ở mô hình kernel gọi là switchdev, được tài liệu chính thức định nghĩa: "The Ethernet switch device driver model (switchdev) is an in-kernel driver model for switch devices which offload the forwarding (data) plane from the kernel." Trong mô hình này, mỗi cổng vật lý/ảo trên phần cứng offload được kernel biểu diễn bằng một port netdev (thường gọi là port representor): "A port netdev is the software representation of the physical port and provides a conduit for control traffic to/from the controller (the kernel) and the network, as well as an anchor point for higher level constructs such as bridges, bonds, VLANs, tunnels, and L3 routers." Nói cách khác: khi OVS gắn một bridge port vào đúng representor netdev đó, TC flower rule cài trên representor sẽ được driver chuyển thành rule cài thẳng vào bảng chuyển mạch nhúng (embedded switch/ASIC) của phần cứng — gói khớp rule đi thẳng qua ASIC, không bao giờ chạm tới CPU host.

Sự khác biệt giữa "NIC offload thường" và "SmartNIC/DPU" nằm ở việc lớp phần cứng phía dưới representor đó là gì:

  • NIC offload thường: ASIC cố định (fixed-function) chỉ biết làm đúng một việc — nhận flow rule (match/action) từ TC flower rồi khớp ở tốc độ line-rate. Không có khả năng chạy thêm logic tùy ý; nếu một OpenFlow action nào đó chưa có ánh xạ TC tương ứng, flow đó buộc rơi lại kernel (Mục 2 — "if unsuccessful then add to software datapath").
  • SmartNIC/DPU: có thêm một lớp compute lập trình được ngay trên card (lõi ARM, NPU, hoặc FPGA tùy sản phẩm), đủ mạnh để tự chạy hẳn một phần — thậm chí toàn bộ — datapath switching ngay trên card, không chỉ nhận flow rule đơn lẻ như ASIC cố định. Trong sơ đồ "OvS Datapath Hooks" ở Mục 2, ô "SmartNIC Datapath" ở một NIC ASIC thường chỉ là bảng flow phẳng; ở một DPU thật, ô đó có thể là cả một tiến trình chuyển mạch chạy trên hệ điều hành riêng của card.

Đây là điểm cần verify thêm chi tiết theo từng vendor cụ thể khi triển khai thật (Netronome/NFP, NVIDIA BlueField, AMD Pensando...) — tài liệu kernel switchdev và OVS chỉ định nghĩa đúng khái niệm chung (switchdev, port representor, TC flower offload), không cam kết một kiến trúc DPU cụ thể nào.

NIC Offload Thường So Với SmartNIC/DPUCả hai đều dùng port representor (switchdev) — khác nhau ở việc phía dưới có compute lập trình được hay khôngNIC offload thường (ASIC cố định)SmartNIC / DPU (compute riêng)Port representor trỏ vào bảngflow phẳng trong ASIC (switchdev)Port representor trỏ vào một tiếntrình chạy trên lõi ARM/NPU của cardChỉ nhận match/action TC flowerđã được driver ánh xạ sẵnCó thể chạy hẳn một phần/toàn bộdatapath switching ngay trên cardAction lạ, chưa map được TC→ rơi lại kernel xử lý bằng CPULogic phức tạp hơn vẫn có thể xử lýngay trên card, không chạm CPU hostLiên hệ: đúng ý tưởng ASIC forward line-rate trên switch leaf/spine — CPU chỉ còn lo control-plane

5. Giới hạn cần biết trước khi bật hardware offload​

Đúng như dòng cuối trong định nghĩa hw-offload đã trích ở Mục 3 — "Depending on which OpenFlow matches and actions are configured, which kernel version is used, and what hardware is available, Open vSwitch may not be able to offload functionality to hardware" — hardware offload không phải một công tắc "bật là chạy hết", còn kèm theo vài giới hạn cụ thể đã được ghi nhận chính thức:

  • Sai lệch byte count: flow đã offload xuống TC không đếm cùng cách với flow chạy trong datapath thường — số byte báo cáo thiếu khoảng 14 byte mỗi gói (đúng kích thước header Ethernet L2) so với flow không offload, do TC đếm từ sau L2.
  • Thống kê meter luôn 0 byte: "The kernel's TC infrastructure is only counting the number of dropped packet, not their byte size. This results in the meter statistics always showing 0 for byte_count."
  • Gói đầu tiên (upcall) không bị policing: gói đến trước khi meter kịp cài vào TC đi qua đường upcall bình thường, bỏ qua hẳn hành động police của meter cho tới khi rule được cài xong.
  • Không tương thích với ALG trong conntrack: "TC will not offload flows if the ALG keyword is present within the ct() action... if ALG support is required, tc offload must be disabled." — nếu lab ở Bài 13 có dùng ALG (ví dụ FTP helper), phải tắt hẳn hw-offload cho bridge đó.
  • Trạng thái "experimental": dòng chữ "This functionality is considered 'experimental'" trong ovs-vswitchd.conf.db(5) vẫn đứng nguyên ở bản tài liệu mới nhất — không phải cảnh báo đã lỗi thời, cần thận trọng đúng mức khi đưa vào production, kiểm thử kỹ trên đúng model NIC và bản kernel dự định dùng trước khi tin tưởng hoàn toàn.

Nếu chỉ nhớ một điều sau bài này, hãy nhớ: hardware offload không phải một công tắc "bật là được cả CPU lẫn độ chính xác" — nó đánh đổi CPU host lấy throughput bằng cách đẩy việc forward xuống phần cứng, nhưng đổi lại số liệu thống kê (byte count, meter) không còn đáng tin tuyệt đối, một số tính năng (ALG trong conntrack) buộc phải hy sinh, và skip_sw có thể làm cả một rule thất bại hoàn toàn nếu đặt nhầm chỗ không có phần cứng hỗ trợ. Luôn kiểm tra kỹ bằng type=offloaded/type=non-offloaded (Mục 6) trước khi tin rằng offload đang thật sự chạy.

6. Walkthrough CLI: bật offload và verify​

Giống tình huống Bài 14 với DPDK — phần verify bằng in_hw thật sự cần một NIC có driver switchdev hỗ trợ TC flower offload (veth/namespace không có ASIC nào phía sau để offload xuống). Nhưng khác với DPDK, các lệnh bật cấu hình OVS (hw-offload, tc-policy) chạy được trên bất kỳ máy Linux nào có OVS kernel module — chỉ là sẽ không có flow nào thật sự lên in_hw nếu không có phần cứng hỗ trợ.

Năm Bước Walkthrough — Từ OVSDB Tới Verify Ở Cả Hai TầngBước 1-2 chạy được trên mọi máy có OVS — Bước 3-5 cần NIC switchdev thật để thấy kết quả khớpBước 1hw-offload=true(OVSDB, mọi máy có OVS)Bước 2tc-policy=skip_sw(OVSDB, chọn chỗ đặt flow)Bước 3ethtool hw-tc-offload(driver NIC, cần NIC thật)Bước 4tc filter show(verify in_hw ở tầng TC)Bước 5dpctl dump-flows type=(verify ở tầng OVS)veth/namespace không dùng được ở Bước 3-4 — cần NIC switchdev thật để thấy in_hw/type=offloaded

Bước 1 — bật hardware offload ở tầng OVS (chạy được trên mọi máy có OVS):

sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
sudo systemctl restart openvswitch-switch
sudo ovs-vsctl get Open_vSwitch . other_config:hw-offload
# Output minh họa
true

Bước 2 — chọn chính sách đặt flow (tc-policy), mặc định là none:

sudo ovs-vsctl set Open_vSwitch . other_config:tc-policy=skip_sw

Bước 3 — bật công tắc offload ở tầng driver NIC (cần NIC/driver thật hỗ trợ hw-tc-offload):

ethtool -k eth0 | grep tc-offload
ethtool -K eth0 hw-tc-offload on
# Output minh họa — cấu trúc đúng theo ethtool(8); nếu driver không hỗ trợ sẽ báo "Cannot change hw-tc-offload"
hw-tc-offload: off [fixed]

Bước 4 — kiểm tra rule đã nằm trong phần cứng chưa, ở tầng TC:

tc filter show dev eth0 ingress

Bước 5 — kiểm tra từ phía OVS, phân loại rõ flow nào offload, flow nào không, theo đúng các loại type= chính thức trong ovs-vswitchd(8):

sudo ovs-appctl dpctl/dump-flows type=offloaded
sudo ovs-appctl dpctl/dump-flows type=non-offloaded
sudo ovs-appctl dpctl/dump-flows type=partially-offloaded

Ba loại trên (cùng type=ovs, type=tc, type=dpdk, type=all) được ovs-vswitchd(8) định nghĩa đúng nguyên văn: offloaded — "displays flows offloaded to the HW"; non-offloaded — flow chưa/không offload được, vẫn chạy bằng CPU; partially-offloaded — "displays flows where only part of their proccessing is done in HW" (ví dụ một phần action offload được, phần còn lại vẫn phải quay lại kernel xử lý). Nếu sau khi bật hw-offload=true mà type=offloaded luôn trống trong khi type=non-offloaded có đầy đủ flow, đó là dấu hiệu chắc chắn: NIC/driver hiện tại không hỗ trợ switchdev/TC flower offload — quay lại Mục 4 để xác nhận đúng model NIC trước khi tiếp tục debug ở tầng OVS.

Bài tập cuối bài​

  1. Trên máy hiện có của bạn, chạy ethtool -k <interface> với <interface> là một NIC vật lý thật (không phải veth/lo), tìm dòng tc-offload hoặc hw-tc-offload trong output. Nếu thấy [fixed] đứng sau giá trị, tự tra ethtool(8) để giải thích ý nghĩa [fixed] đó, và kết luận NIC/driver hiện tại có khả năng nhận offload TC flower hay không.
  2. Trên một bridge OVS lab bất kỳ (không cần NIC switchdev thật), bật other_config:hw-offload=true và other_config:tc-policy=skip_sw, sau đó ovs-ofctl add-flow một rule đơn giản rồi gửi traffic khớp rule đó. Dùng sudo ovs-appctl dpctl/dump-flows type=non-offloaded để quan sát. Đối chiếu với đúng câu đã trích ở Mục 3 từ tc-flower(8) ("If hardware has no offload support for this filter... operation will fail"), hãy tự suy luận và ghi lại điều gì xảy ra với traffic đó trên máy lab không có phần cứng offload — rule có được cài thành công không, còn forward được không, và vì sao đây là lý do skip_sw cần cân nhắc kỹ trước khi dùng ngoài môi trường đã xác nhận có hardware offload thật.
  3. Đọc lại đúng đoạn giới hạn byte count ở Mục 5 (thiếu khoảng 14 byte/gói do offload). Giả sử một hệ thống billing/QoS đang dựa vào cột n_bytes từ ovs-ofctl dump-flows (Bài 6, Bài 12) để tính chính xác lưu lượng, hãy viết ra: bật hw-offload=true trên các port có traffic đó có thể gây sai lệch gì cho hệ thống billing, và đề xuất một hướng xử lý cụ thể (ví dụ: loại trừ port đó khỏi offload bằng tc-policy riêng, hay cộng bù số byte, hay đổi hẳn cơ chế đo).

Nguồn tham khảo​

  • Động lực, ba mô hình offload (Kernel Datapath / OVS Datapath Hooks / OvS-TC), TC flower overview và ví dụ, hardware offload policy (skip_hw/skip_sw/in_hw/not_in_hw, ethtool -K hw-tc-offload), cấu hình hw-offload/tc-policy phiên bản gốc, ovs-dpctl dump-flows type=, tính năng hỗ trợ (match L2-L4/tunnel, action drop/output/vlan), mốc lịch sử (TC flower kernel 4.2, OVS 2.8, NFP driver kernel 4.13) — "OvS Hardware Offload with TC Flower", Simon Horman (Netronome), Open vSwitch 2017 Fall Conference — openvswitch.org/support/ovscon2017/horman.pdf.
  • "The flow hardware offload is disabled by default and can be enabled by: $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true"; giới hạn byte count L2, "The kernel's TC infrastructure is only counting the number of dropped packet, not their byte size. This results in the meter statistics always showing 0 for byte_count", gói đầu tiên bỏ qua police, "TC will not offload flows if the ALG keyword is present within the ct() action... if ALG support is required, tc offload must be disabled" — Flow Hardware offload with Linux TC flower, docs.openvswitch.org.
  • Cột other_config bảng Open_vSwitch: hw-offload ("...This functionality is considered 'experimental'. Depending on which OpenFlow matches and actions are configured, which kernel version is used, and what hardware is available, Open vSwitch may not be able to offload functionality to hardware."), tc-policy ("none... Add software rule and offload rule to HW", "skip_sw... Offload rule to HW only", "skip_hw... Add software rule without offloading rule to HW"), hw-offload-priority ("The default value is tc,dpdk"), n-offload-threads, offloaded-stats-delay, offload-rebalance — ovs-vswitchd.conf.db(5), openvswitch.org.
  • Lệnh ovs-appctl dpctl/dump-flows type=<ovs|tc|dpdk|offloaded|non-offloaded|partially-offloaded|all>, mô tả từng loại ("offloaded - displays flows offloaded to the HW", "partially-offloaded - displays flows where only part of their proccessing is done in HW") — ovs-vswitchd(8), openvswitch.org.
  • skip_sw/skip_hw theo man page hiện hành: "skip_sw — Do not process filter by software. If hardware has no offload support for this filter, or TC offload is not enabled for the interface, operation will fail.", "skip_hw — Do not process filter by hardware." — tc-flower(8), man7.org.
  • Định nghĩa switchdev ("The Ethernet switch device driver model (switchdev) is an in-kernel driver model for switch devices which offload the forwarding (data) plane from the kernel") và port representor ("A port netdev is the software representation of the physical port and provides a conduit for control traffic to/from the controller (the kernel) and the network, as well as an anchor point for higher level constructs such as bridges, bonds, VLANs, tunnels, and L3 routers") — Ethernet switch device driver model (switchdev), docs.kernel.org.
  • Ba loại datapath và kernel datapath tra flow bằng megaflow đã học ở Bài 3; yêu cầu hạ tầng và đánh đổi CPU của DPDK, hw-offload-priority giá trị dpdk liên hệ trực tiếp cơ chế offload riêng của userspace+DPDK đã học ở Bài 14; cú pháp ovs-ofctl dump-flows/cột n_bytes đã học ở Bài 6 và Bài 12; action ct()/ALG trong conntrack đã học ở Bài 13.

Tiếp theo: Module 3, Bài 16 — Giám sát: sFlow, IPFIX, port mirroring.