• VXLAN ที่ MTU มาตรฐาน: เพิ่มจาก 34.44 เป็น 39.56 Gbit/s หรือประมาณ 14.9%
• VXLAN เมื่อปิด tunnel hardware offload: เพิ่มจาก 21.82 เป็น 29.39 Gbit/s หรือประมาณ 34.7%
• Geneve ที่ MTU มาตรฐาน: เพิ่มจาก 37.39 เป็น 40.89 Gbit/s หรือประมาณ 9.4%

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

ลดการแย่งล็อก RTNL ในงาน routing จำนวนมาก

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

ผลที่ได้เห็นชัดในงานที่สร้างแรงกดดันสูงต่อระบบ นักพัฒนาทดสอบด้วยการสร้าง 4,096 network namespaces และเพิ่มกฎ 1,024 รายการในแต่ละ namespace พร้อมกัน ผลลัพธ์ของ IPv4 ลดเวลาจาก 22.752 วินาที เหลือ 0.918 วินาที หรือเร็วขึ้นประมาณ 24.8 เท่า ส่วน IPv6 ลดจาก 35.181 วินาที เหลือ 1.214 วินาที หรือประมาณ 29 เท่า

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

ผู้ดูแลเคอร์เนลกำลังรับมือ “แพตช์จาก AI” ที่เพิ่มขึ้น

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

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

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

ระบบอัตโนมัติอาจช่วยจัดการ Patchwork ให้ข้อเสนอแนะเกี่ยวกับกระบวนการทั่วไป ปรับข้อความ commit และในอนาคตอาจช่วยนำแพตช์ที่ผ่านการตรวจสอบจากผู้ดูแลที่เชื่อถือได้ไปใช้ได้ แต่ทีมย้ำว่าวิธีนี้ยังไม่เพียงพอสำหรับโค้ดที่เกี่ยวข้องกับ race condition หรือการกู้คืนฮาร์ดแวร์ เช่น กรณี PCIe error และ timeout ซึ่งต้องตรวจสอบลำดับการทำงานและพฤติกรรมของ API โดยมนุษย์

ไดรเวอร์และการปรับปรุงโปรโตคอลอื่น ๆ

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

• ฝั่ง Wi‑Fi ได้ไดรเวอร์เริ่มต้นสำหรับ Morse Micro mm81x Wi‑Fi HaLow ซึ่งรองรับอุปกรณ์ USB และ SDIO รวมถึงไดรเวอร์ไร้สายใหม่ NXPWIFI และงานต่อเนื่องด้าน MLO
• ฝั่งเครือข่ายแบบใช้สายมีโครงร่างเริ่มต้นของไดรเวอร์ Intel iXD สำหรับรองรับ Intel Control Plane PIC Function บน IPU/FNIC รุ่น E2100 ขึ้นไป
• เพิ่มการรองรับ CXL เบื้องต้นสำหรับ NIC ของ AMD/Solarflare และรองรับการแฟลชเฟิร์มแวร์บน NIC ของ AMD Pensando
• MPTCP เพิ่มกลไกตัดข้อมูลในคิว out-of-order เมื่อหน่วยความจำอยู่ภายใต้แรงกดดันอย่างรุนแรง โดยเน้นการกู้คืนและการส่งซ้ำ ไม่ใช่การเพิ่มความเร็วในงานปกติ
• AF_UNIX SCM_RIGHTS รายงานได้ดีขึ้นเมื่อ LSM ปฏิเสธ file descriptor บางรายการ หากเปิดใช้ SO_RIGHTS_NOTRUNC ฝั่งรับจะระบุได้ว่า descriptor ใดถูกปฏิเสธและเกิด errno ใด แทนที่จะหยุดจนส่วนที่เหลือของอาร์เรย์หายไปตั้งแต่ข้อผิดพลาดแรก

Linux 7.3 จะออกเมื่อไร

ตามกำหนดการเบื้องต้น release candidate แรกคาดว่าจะมาประมาณ 30 สิงหาคม 2026 และรุ่นเสถียรมีแนวโน้มเปิดตัวในช่วง ปลายเดือนตุลาคม ทั้งนี้ยังขึ้นอยู่กับจังหวะการพัฒนาตามรอบปกติของเคอร์เนล

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

• VXLAN ที่ MTU มาตรฐาน: เพิ่มจาก 34.44 เป็น 39.56 Gbit/s หรือประมาณ 14.9%
• VXLAN เมื่อปิด tunnel hardware offload: เพิ่มจาก 21.82 เป็น 29.39 Gbit/s หรือประมาณ 34.7%
• Geneve ที่ MTU มาตรฐาน: เพิ่มจาก 37.39 เป็น 40.89 Gbit/s หรือประมาณ 9.4%

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

ลดการแย่งล็อก RTNL ในงาน routing จำนวนมาก

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

ผลที่ได้เห็นชัดในงานที่สร้างแรงกดดันสูงต่อระบบ นักพัฒนาทดสอบด้วยการสร้าง 4,096 network namespaces และเพิ่มกฎ 1,024 รายการในแต่ละ namespace พร้อมกัน ผลลัพธ์ของ IPv4 ลดเวลาจาก 22.752 วินาที เหลือ 0.918 วินาที หรือเร็วขึ้นประมาณ 24.8 เท่า ส่วน IPv6 ลดจาก 35.181 วินาที เหลือ 1.214 วินาที หรือประมาณ 29 เท่า

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

ผู้ดูแลเคอร์เนลกำลังรับมือ “แพตช์จาก AI” ที่เพิ่มขึ้น

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

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

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

ระบบอัตโนมัติอาจช่วยจัดการ Patchwork ให้ข้อเสนอแนะเกี่ยวกับกระบวนการทั่วไป ปรับข้อความ commit และในอนาคตอาจช่วยนำแพตช์ที่ผ่านการตรวจสอบจากผู้ดูแลที่เชื่อถือได้ไปใช้ได้ แต่ทีมย้ำว่าวิธีนี้ยังไม่เพียงพอสำหรับโค้ดที่เกี่ยวข้องกับ race condition หรือการกู้คืนฮาร์ดแวร์ เช่น กรณี PCIe error และ timeout ซึ่งต้องตรวจสอบลำดับการทำงานและพฤติกรรมของ API โดยมนุษย์

ไดรเวอร์และการปรับปรุงโปรโตคอลอื่น ๆ

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

• ฝั่ง Wi‑Fi ได้ไดรเวอร์เริ่มต้นสำหรับ Morse Micro mm81x Wi‑Fi HaLow ซึ่งรองรับอุปกรณ์ USB และ SDIO รวมถึงไดรเวอร์ไร้สายใหม่ NXPWIFI และงานต่อเนื่องด้าน MLO
• ฝั่งเครือข่ายแบบใช้สายมีโครงร่างเริ่มต้นของไดรเวอร์ Intel iXD สำหรับรองรับ Intel Control Plane PIC Function บน IPU/FNIC รุ่น E2100 ขึ้นไป
• เพิ่มการรองรับ CXL เบื้องต้นสำหรับ NIC ของ AMD/Solarflare และรองรับการแฟลชเฟิร์มแวร์บน NIC ของ AMD Pensando
• MPTCP เพิ่มกลไกตัดข้อมูลในคิว out-of-order เมื่อหน่วยความจำอยู่ภายใต้แรงกดดันอย่างรุนแรง โดยเน้นการกู้คืนและการส่งซ้ำ ไม่ใช่การเพิ่มความเร็วในงานปกติ
• AF_UNIX SCM_RIGHTS รายงานได้ดีขึ้นเมื่อ LSM ปฏิเสธ file descriptor บางรายการ หากเปิดใช้ SO_RIGHTS_NOTRUNC ฝั่งรับจะระบุได้ว่า descriptor ใดถูกปฏิเสธและเกิด errno ใด แทนที่จะหยุดจนส่วนที่เหลือของอาร์เรย์หายไปตั้งแต่ข้อผิดพลาดแรก

Linux 7.3 จะออกเมื่อไร

ตามกำหนดการเบื้องต้น release candidate แรกคาดว่าจะมาประมาณ 30 สิงหาคม 2026 และรุ่นเสถียรมีแนวโน้มเปิดตัวในช่วง ปลายเดือนตุลาคม ทั้งนี้ยังขึ้นอยู่กับจังหวะการพัฒนาตามรอบปกติของเคอร์เนล

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