Linux 7.3 อัปเกรดเครือข่ายครั้งใหญ่: BIG TCP บน VXLAN และ Geneve พร้อมบททดสอบ AI รีวิวโค้ด

โค้ดเครือข่ายของ Linux 7.3 ถูกผนวกเข้าสู่ mainline ระหว่างช่วง merge window เมื่อวันที่ 20 สิงหาคม 2026 แต่ยังไม่ใช่เคอร์เนลรุ่นเสถียรที่ผู้ใช้ทั่วไปดาวน์โหลดไปติดตั้งได้ทันที

รอบนี้มีความโดดเด่นอยู่สองด้าน ด้านแรกคือการปรับประสิทธิภาพสำหรับระบบที่ใช้เครือข่ายแบบ Overlay และ Network Namespace จำนวนมาก อีกด้านคือการทดลองใช้ AI ช่วยจัดการปริมาณแพตช์ที่เพิ่มขึ้นจนผู้ดูแลซับซิสเต็มเครือข่ายต้องหาวิธีแบ่งเบาภาระ

BIG TCP ขยายไปถึง VXLAN และ Geneve

Linux 7.3 เพิ่มการรองรับ BIG TCP ให้กับไดรเวอร์ UDP tunnel อย่าง VXLAN และ Geneve โดยเปิดให้เคอร์เนลประมวลผล payload ที่มีขนาดเกิน 64 KiB ภายในระบบ จากนั้นจึงใช้ GSO และ TSO แบ่งข้อมูลออกเป็นแพ็กเก็ตก่อนส่งออกสู่เครือข่ายจริง

ประเด็นสำคัญคือ BIG TCP ไม่ได้หมายความว่าเครือข่ายจะส่งแพ็กเก็ตขนาดใหญ่เกินข้อจำกัดของสายสัญญาณโดยตรง แต่ช่วยลดจำนวนครั้งที่ต้องประมวลผลแพ็กเก็ตในเส้นทาง Overlay ซึ่งเหมาะกับงานที่มีทราฟฟิกสูง เช่น ระบบเสมือนจริงและโครงสร้างพื้นฐานที่เชื่อมต่อผ่าน VXLAN หรือ Geneve

ผลทดสอบ

netperf TCP_STREAM

• VXLAN เพิ่ม throughput จาก 34.44 เป็น 39.56 Gbit/s หรือ 14.9% ที่ MTU มาตรฐาน
• เมื่อปิดฮาร์ดแวร์ offload ของ tunnel แล้ว VXLAN เพิ่มจาก 21.82 เป็น 29.39 Gbit/s หรือ 34.7%
• Geneve เพิ่มจาก 37.39 เป็น 40.89 Gbit/s หรือ 9.4% ที่ MTU มาตรฐาน

ตัวเลขเหล่านี้เป็นผลทดสอบในสภาพแวดล้อมเฉพาะ ไม่ควรตีความว่า Linux 7.3 จะเร็วขึ้นในอัตราเดียวกันกับทุกเครื่อง ประสิทธิภาพจริงขึ้นอยู่กับการตั้งค่าแบบครบวงจร เช่น gso_max_size, gro_max_size, ความสามารถของ NIC, สถานะ offload, MTU, ประเภท tunnel และลักษณะ workload ดังนั้นผู้ดูแลระบบควรวัดผลกับเส้นทาง VXLAN หรือ Geneve ของตัวเองก่อนปรับใช้งานจริง

ลด RTNL lock ช่วยงานที่สร้าง Namespace พร้อมกันจำนวนมาก

อีกการเปลี่ยนแปลงสำคัญคือการลดการพึ่งพา RTNL lock ซึ่งเป็นกลไกล็อกขนาดใหญ่ที่เคยทำให้การจัดการกฎ Routing Rule ของ IPv4 และ IPv6 ต้องต่อคิวกันมากเกินจำเป็น

การเพิ่มและลบกฎ FIB (Forwarding Information Base) จะใช้ mutex ที่ผูกกับ fib_rules_ops ของแต่ละส่วนเมื่อทำได้ ทำให้บางงานสามารถทำงานแบบขนานได้มากขึ้น อย่างไรก็ตาม RTNL ยังจำเป็นในบางกรณี รวมถึงเส้นทาง fib_unmerge() ของกฎ IPv4 รายการแรก

การทดสอบสังเคราะห์ที่สร้าง Network Namespace จำนวน 4,096 แห่ง และเพิ่มกฎ 1,024 รายการให้แต่ละ Namespace พร้อมกัน พบว่า

• IPv4 ใช้เวลาลดลงจาก 22.752 เหลือ 0.918 วินาที หรือเร็วขึ้นประมาณ 24.8 เท่า
• IPv6 ใช้เวลาลดลงจาก 35.181 เหลือ 1.214 วินาที หรือเร็วขึ้นประมาณ 29.0 เท่า

อย่างไรก็ดี นี่เป็นการทดสอบที่ออกแบบมาเพื่อสร้างภาวะคอขวดจากการล็อกในระดับสูงมาก ไม่ใช่ตัวเลขที่รับประกันว่าการเริ่มต้นคอนเทนเนอร์ทั่วไปหรือ workload ด้าน Routing ทุกประเภทจะเร็วขึ้นในระดับเดียวกัน

ปริมาณแพตช์จาก AI เพิ่มจนผู้ดูแลระบบ “รับมือไม่ไหว”

Linux 7.3 ยังสะท้อนปัญหาใหม่ของการพัฒนาเคอร์เนลแบบโอเพนซอร์ส นั่นคือจำนวนแพตช์ที่สร้างหรือขับเคลื่อนโดย AI เพิ่มขึ้นอย่างรวดเร็ว

Jakub Kicinski ผู้ดูแลฝั่งเครือข่ายรายงานว่ามีแพตช์ในชุด net จำนวน 632 รายการ และใน net-next อีก 648 รายการ พร้อมประเมินว่าประมาณหนึ่งในสามถึงครึ่งหนึ่งของแพตช์ net-next เป็นงานแก้ไขระดับความสำคัญต่ำ การปรับปรุงโค้ด หรือการแก้คำอธิบายที่ขับเคลื่อนโดย AI คิดเป็นราว 216–324 แพตช์

Kicinski และ Paolo Abeni อธิบายว่าปริมาณงานทำให้ทีมอยู่ในภาวะ “completely overwhelmed” หรือรับภาระจนเกินกำลัง

แนวทางที่เสนอไม่ใช่การให้โมเดลใดโมเดลหนึ่งเข้ามาแทนที่ผู้ดูแลเคอร์เนล แต่เป็นการใช้โมเดล AI ระดับแนวหน้าหลายตัวช่วยรีวิวเบื้องต้น โดย Meta สนับสนุนงบประมาณและสิทธิ์เข้าถึงโมเดลเหล่านี้ เป้าหมายคือให้มีการตรวจสอบหลายชั้น ลดโอกาสที่ภาพหลอนหรือความเข้าใจผิดของโมเดลเดียวจะหลุดผ่านกระบวนการไปโดยไม่มีใครทักท้วง

งานที่อาจนำไปทำอัตโนมัติได้ ได้แก่

• การจัดการแพตช์ผ่าน Patchwork
• การให้ข้อเสนอแนะเกี่ยวกับขั้นตอนการส่งแพตช์
• การปรับแก้ commit message
• อาจรวมถึงการนำแพตช์ไปใช้ เมื่อผ่านการตรวจสอบจากบุคคลที่ได้รับความไว้วางใจแล้ว

งานเหล่านี้มีรูปแบบค่อนข้างชัดเจน จึงเหมาะกับการให้ AI ช่วยคัดกรองมากกว่าการตัดสินว่าแพตช์หนึ่งถูกต้องหรือไม่ในเส้นทางการทำงานที่เกิดขึ้นไม่บ่อย

ผู้ดูแลยังย้ำว่ากรณีซับซ้อน เช่น race condition ที่พบได้ยาก เส้นทางกู้คืนฮาร์ดแวร์ ปัญหา PCIe และการจัดการ timeout ยังคงต้องอาศัยมนุษย์ตรวจสอบ เพราะต้องเข้าใจรายละเอียดของ concurrency, API contract และลำดับการกู้คืนระบบอย่างลึกซึ้ง

ไดรเวอร์ใหม่และการปรับปรุงโปรโตคอล

ชุดการเปลี่ยนแปลงของเครือข่ายใน Linux 7.3 ยังครอบคลุมการรองรับฮาร์ดแวร์และโปรโตคอลหลายรายการ ได้แก่

• ไดรเวอร์ Wi-Fi HaLow รุ่นแรกสำหรับ Morse Micro mm81x รองรับอุปกรณ์แบบ USB และ SDIO
• ไดรเวอร์ไร้สายตัวใหม่ NXPWIFI จาก NXP ขณะที่การพัฒนารองรับ Multi-Link Operation ยังคงเดินหน้าต่อ
• โครงร่างเริ่มต้นของไดรเวอร์ Intel iXD สำหรับรองรับ Control Plane PIC Function บน IPU และ FNIC รุ่น E2100 ขึ้นไป
• การรองรับ CXL ระยะแรกสำหรับ NIC ของ AMD/Solarflare
• ความสามารถแฟลชเฟิร์มแวร์ให้ฮาร์ดแวร์ AMD Pensando

ด้าน MPTCP มีการเพิ่มกลไกสำรองสำหรับตัดคิวข้อมูลที่มาถึงไม่เป็นลำดับ เมื่อระบบเผชิญแรงกดดันด้านหน่วยความจำอย่างรุนแรง ฟีเจอร์นี้เน้นช่วยให้ระบบฟื้นตัวและจัดการการส่งข้อมูลต่อได้ในสถานการณ์คับขัน ไม่ได้หมายความว่าจะเพิ่ม throughput ในการใช้งานปกติ

สำหรับ AF_UNIX การส่ง file descriptor ผ่าน SCM_RIGHTS จะวินิจฉัยปัญหาได้ง่ายขึ้น เมื่อ LSM ปฏิเสธ file descriptor บางรายการในอาร์เรย์ หากใช้ SO_RIGHTS_NOTRUNC ฝั่งรับจะสามารถระบุ descriptor ที่ถูกปฏิเสธและค่า errno ได้ แทนที่จะสูญเสียข้อมูลส่วนที่เหลือของอาร์เรย์ทันทีเมื่อพบรายการแรกที่ไม่ผ่านการตรวจสอบ

Linux 7.3 จะออกเมื่อไร และผู้ใช้จะได้ใช้ตอนไหน

คาดว่า Linux 7.3 รุ่น release candidate แรก หรือ RC1 จะมาราววันที่ 30 สิงหาคม 2026 ส่วนรุ่นเสถียรคาดว่าจะเปิดตัวช่วง ปลายเดือนตุลาคม หากรอบการพัฒนายังคงเป็นไปตามกำหนดปกติ

แต่การเปิดตัวเคอร์เนลต้นน้ำไม่ได้แปลว่าเซิร์ฟเวอร์หรือเดสก์ท็อปส่วนใหญ่จะได้รับฟีเจอร์เหล่านี้ในเดือนตุลาคมทันที เพราะแต่ละดิสโทรมีรอบการพัฒนาและการดูแลแพ็กเกจของตัวเอง ทั้งการเลือกเวอร์ชัน การ backport บางแพตช์ การทดสอบ และการปล่อยอัปเดต

ดิสโทรแบบ rolling release อาจนำ Linux 7.3 ไปแพ็กเกจได้เร็วกว่า ขณะที่ดิสโทรแบบกำหนดรุ่นอาจใช้เวลานานกว่านั้นมาก ส่วน CachyOS มีโอกาสเป็นหนึ่งในดิสโทรที่นำไปใช้เร็ว เนื่องจากใช้โมเดล rolling release แต่ข้อมูลการออกอิมเมจเดือนสิงหาคมที่มีอยู่ยังระบุว่าใช้ Linux 7.1 และยังไม่ได้ยืนยันกำหนดการนำ Linux 7.3 มาใช้

สรุป: ผู้ดูแลระบบควรจับตาอะไร

สำหรับทีมโครงสร้างพื้นฐาน การเปลี่ยนแปลงที่น่าจับตาที่สุดคือ BIG TCP บนเส้นทาง VXLAN/Geneve และการลด contention ระหว่างการจัดการ Routing Rule ในระบบที่สร้างหรือกำหนดค่า Network Namespace จำนวนมากพร้อมกัน โดยเฉพาะสภาพแวดล้อมที่ใช้ Overlay Network และมีทราฟฟิกสูง

สำหรับนักพัฒนาเคอร์เนล การทดลองใช้ AI รีวิวแพตช์อาจมีความสำคัญไม่แพ้ฟีเจอร์เครือข่ายเอง ภาพที่กำลังเกิดขึ้นคือการแบ่งงานให้ชัดเจนขึ้น: ให้โมเดลช่วยรับภาระงานคัดกรองและงานตามขั้นตอนซ้ำ ๆ ขณะที่ผู้ดูแลยังรับผิดชอบกรณีผิดปกติซึ่งแพตช์ที่ดูสมเหตุสมผลอาจทำให้เกิด deadlock จัดการการกู้คืนผิดลำดับ หรือฝ่าฝืนกฎการซิงโครไนซ์ที่ไม่ได้เขียนไว้อย่างชัดเจน

ดังนั้น Linux 7.3 กำลังมาพร้อมชุดอัปเดตเครือข่ายที่น่าสนใจ แต่ผู้ใช้งานควรรอการทดสอบในช่วง release candidate การตรวจสอบกับฮาร์ดแวร์จริง และการผนวกรวมจากผู้ดูแลดิสโทรก่อนพึ่งพาฟีเจอร์เหล่านี้ในระบบ production