Đây là các phép đo phụ thuộc mạnh vào cấu hình. Kết quả thực tế còn chịu ảnh hưởng của gso_max_size, gro_max_size, khả năng của NIC, trạng thái offload, MTU, loại đường hầm và đặc điểm workload. Đội ngũ vận hành nên benchmark chính đường VXLAN hoặc Geneve của mình trước khi kỳ vọng mức cải thiện tương tự.
Một thay đổi quan trọng khác là Linux giảm phụ thuộc vào khóa RTNL diện rộng khi thêm hoặc xóa luật FIB IPv4 và IPv6. Trong những trường hợp phù hợp, thao tác này chuyển sang dùng mutex gắn với fib_rules_ops tương ứng, cho phép nhiều công việc tiến hành song song hơn. RTNL vẫn cần thiết ở một số đường xử lý, trong đó có nhánh fib_unmerge() của luật IPv4 đầu tiên.
Một bài kiểm thử tổng hợp mô phỏng tình huống quản lý namespace cực kỳ song song: tạo 4.096 network namespace và thêm 1.024 luật vào mỗi namespace. Thời gian xử lý IPv4 giảm từ 22,752 xuống 0,918 giây, nhanh hơn khoảng 24,8 lần. Với IPv6, thời gian giảm từ 35,181 xuống 1,214 giây, tương đương khoảng 29 lần.
Tuy nhiên, các con số này chủ yếu đo mức nghẽn khóa trong một kịch bản cực đoan. Chúng không có nghĩa thời gian khởi động container thông thường hay mọi workload định tuyến đều sẽ nhanh hơn với cùng tỷ lệ.
Hệ thống mạng của Linux đang trở thành một phép thử đối với phát triển kernel có sự hỗ trợ của AI. Jakub Kicinski cho biết có 632 bản vá net và 648 bản vá net-next. Ông ước tính khoảng một phần ba đến một nửa số bản vá net-next là các bản sửa lỗi ưu tiên thấp, dọn dẹp hoặc làm rõ do AI thúc đẩy tạo ra—tương đương khoảng 216–324 bản vá. Kicinski và Paolo Abeni mô tả khối lượng công việc là “hoàn toàn quá tải”.
Giải pháp được đề xuất không phải là giao toàn bộ quyền quyết định cho một mô hình duy nhất. Meta đã cung cấp ngân sách và quyền truy cập vào nhiều mô hình AI tiên tiến để mỗi bản vá có thể trải qua vài vòng rà soát ban đầu. Cách này nhằm giảm nguy cơ lỗi “hallucination” hoặc diễn giải sai của một mô hình đơn lẻ lọt qua quy trình mà không bị phát hiện.
Các hạng mục có thể được tự động hóa gồm quản lý Patchwork, phản hồi về quy trình, chỉnh sửa commit message và có thể cả việc áp dụng những bản vá đã được người đáng tin cậy kiểm tra. Đây đều là các tác vụ có cấu trúc rõ ràng hơn so với việc quyết định một thay đổi có đúng trong một nhánh lỗi hiếm gặp hay không.
Ranh giới này đặc biệt quan trọng với networking của kernel. Các maintainer nhấn mạnh rằng những race condition bất thường và đường xử lý khôi phục phần cứng—chẳng hạn lỗi PCIe hoặc xử lý timeout—vẫn cần con người xem xét. AI có thể lọc bớt công việc lặp lại, nhưng không thay thế được hiểu biết về tính đồng thời, hợp đồng API và thứ tự khôi phục hệ thống.
Bản hợp nhất mạng của Linux 7.3 cũng mang đến một loạt thay đổi hỗ trợ phần cứng và giao thức:
Ngoài driver, MPTCP có thêm cơ chế “cứu hộ” để loại bỏ các hàng đợi gói đến không đúng thứ tự khi bộ nhớ chịu áp lực cực lớn. Đây là biện pháp phục hồi trong điều kiện thiếu tài nguyên, không phải cam kết tăng thông lượng thông thường.
Việc truyền file descriptor qua AF_UNIX cũng dễ chẩn đoán hơn. Với SO_RIGHTS_NOTRUNC, bên nhận có thể xác định descriptor bị từ chối cùng errno tương ứng khi LSM chặn một descriptor trong mảng SCM_RIGHTS, thay vì mất phần còn lại của mảng ngay tại lần từ chối đầu tiên.
Release candidate đầu tiên của Linux 7.3 được dự kiến vào khoảng ngày 30/8/2026. Bản ổn định được dự báo phát hành vào cuối tháng 10, nếu chu kỳ phát triển diễn ra theo lịch thông thường.
Dù vậy, không nên hiểu rằng phần lớn máy chủ hoặc máy tính để bàn sẽ nhận ngay các tính năng mạng này vào tháng 10. Mỗi bản phân phối tự chọn phiên bản kernel, backport một số thay đổi, kiểm thử và phát hành theo lịch riêng. Các distro rolling có thể đóng gói kernel sớm hơn, trong khi distro phát hành theo chu kỳ cố định thường cần nhiều thời gian hơn đáng kể.
CachyOS là một ứng viên có thể tiếp nhận sớm nhờ mô hình rolling. Tuy nhiên, thông tin về bản phát hành tháng 8 hiện cho thấy các image của CachyOS vẫn dùng Linux 7.1, chưa xác nhận thời điểm chuyển sang Linux 7.3.
Với các đội ngũ hạ tầng, hai thay đổi đáng theo dõi nhất là BIG TCP trên đường overlay và việc giảm tranh chấp khóa khi đồng thời quản lý luật mạng trong số lượng lớn network namespace. Chúng đặc biệt phù hợp với môi trường kết hợp VXLAN hoặc Geneve với lưu lượng lớn, hay các hệ thống thường xuyên tạo và cấu hình nhiều namespace cùng lúc.
Với các nhà phát triển kernel, thử nghiệm rà soát bản vá bằng AI có thể cũng quan trọng không kém. Lần hợp nhất này gợi ý một cách phân công thực tế: mô hình đảm nhiệm việc phân loại lặp lại và phản hồi theo quy trình, còn maintainer chịu trách nhiệm với những trường hợp hiếm nhưng rủi ro cao—nơi một bản vá nhìn có vẻ hợp lý vẫn có thể gây deadlock, xử lý sai quá trình khôi phục hoặc phá vỡ quy tắc đồng bộ hóa ngầm.
Linux 7.3 vì thế đang hướng đến một đợt nâng cấp networking đáng kể. Nhưng trước khi người dùng phổ thông có thể dựa vào các thay đổi này, chúng vẫn cần vượt qua các bản release candidate, kiểm thử trên phần cứng thực tế và quá trình tích hợp của từng bản phân phối.