ชุดแพตช์ที่รองรับการทำงานนี้ต้องแก้สมมติฐานเดิมในเส้นทางอุโมงค์ ซึ่งเคยคาดว่าความยาวแพ็กเก็ตจะไม่เกิน 64 KiB หรือสามารถเก็บไว้ในฟิลด์ขนาด 16 บิตได้ นอกจากนี้ยังครอบคลุม workload ของ BIG TCP ทั้ง IPv4 และ IPv6 สำหรับ VXLAN และ Geneve
การเปลี่ยนแปลงสำคัญอีกส่วนคือการลดการพึ่งพา global RTNL lock สำหรับการดำเนินการกับกฎของ FIB หรือ Forwarding Information Base เช่น RTM_NEWRULE และ RTM_DELRULE
RTNL เป็นกลไกล็อกระดับโกลบอลที่สามารถทำให้การดำเนินงานด้านเครือข่ายต้องต่อคิวรอ การลดจุดรวมศูนย์นี้จึงมุ่งช่วยระบบที่ต้องปรับกฎเส้นทางในหลาย network namespace พร้อมกัน โดยเปิดพื้นที่ให้การทำงานคู่ขนานมากขึ้น
ข้อมูลที่มีอยู่ยืนยันเป้าหมายด้านสถาปัตยกรรมและการเพิ่มความสามารถในการทำงานคู่ขนาน แต่ยังไม่มี benchmark ที่น่าเชื่อถือเพียงพอสำหรับระบุว่า IPv4 หรือ IPv6 จะเร็วขึ้นกี่เปอร์เซ็นต์หรือกี่เท่า ผลลัพธ์จริงย่อมขึ้นอยู่กับ workload และการตั้งค่าของระบบ
การรวมโค้ดรอบนี้ยังขยายการรองรับฮาร์ดแวร์และโปรโตคอลในหลายส่วน ได้แก่
mm81x สำหรับอุปกรณ์ S1G ระยะไกล และไดรเวอร์ NXPWIFI ใหม่ ทั้งหมดนี้คือโค้ดที่เข้าสู่การพัฒนาในช่วง merge window ของ Linux 7.3 ยังไม่ใช่การเปิดตัว Linux 7.3 รุ่นเสถียรอย่างเป็นทางการ
Kicinski และ Abeni ระบุว่าพวกเขารวมแพตช์ net จำนวน 632 รายการ และ net-next จำนวน 648 รายการ รวมเป็น 1,280 รายการในการดึงโค้ดระบบเครือข่ายครั้งนี้ และตัวเลขดังกล่าวยังไม่สะท้อนภาระการรีวิวทั้งหมด
การประเมินแบบ “คร่าว ๆ” ของทีมระบุว่า แพตช์ net-next ราวหนึ่งในสามถึงครึ่งหนึ่งดูเหมือนเป็นงานที่ขับเคลื่อนโดย AI เช่น การแก้ไขลำดับความสำคัญต่ำ การทำความสะอาดโค้ด หรือการปรับคำอธิบายให้ชัดเจนขึ้น
แรงกดดันนี้เป็นส่วนหนึ่งของแนวโน้มที่กว้างขึ้น ในช่วงเวลาเพียง 9 วัน ระบบเครือข่ายได้รับโพสต์ที่ติดแท็ก [PATCH net][PATCH net-next]
ประเด็นไม่ได้อยู่ที่ AI สามารถเขียนโค้ดได้เท่านั้น ผู้ใช้ AI ยังสามารถสร้างคำอธิบาย รายงานบั๊ก และคำขอรีวิวที่ดูสมเหตุสมผลได้ด้วยต้นทุนที่ต่ำมาก แต่ผู้ดูแลที่เป็นมนุษย์ยังต้องตรวจสอบทุกการเปลี่ยนแปลงว่าเกิดความจำเป็นจริงหรือไม่ ถูกต้อง ปลอดภัย และคุ้มค่าที่จะรวมเข้าสู่เคอร์เนลหรือไม่
ผู้ดูแลระบุว่าได้รับงบประมาณและสิทธิ์เข้าถึงโมเดลภาษาขนาดใหญ่หลายตัวจากการสนับสนุนของ Meta เพื่อให้โมเดลเหล่านี้ช่วยรีวิวแพตช์ เป้าหมายเร่งด่วนคือการคัดกรองการเปลี่ยนแปลงที่มีข้อมูลหลอนหรือคุณภาพต่ำบางส่วน ก่อนที่งานเหล่านั้นจะใช้เวลาของผู้รีวิวมนุษย์มากขึ้น
นอกจากนี้ยังวางแผนให้โมเดลรับผิดชอบงานประจำในกระบวนการพัฒนา เช่น
แนวทางนี้มอง LLM เป็นผู้ช่วยด้าน workflow มากกว่าจะเป็นตัวแทนของผู้ดูแล subsystem โดยเฉพาะกับโค้ดเคอร์เนลที่เกี่ยวข้องกับ concurrency ซึ่งต้องพิจารณาลำดับเหตุการณ์จำนวนมาก
ผู้ดูแลยกตัวอย่างเส้นทางการทำงานที่เกิดขึ้นไม่บ่อย เช่น ข้อผิดพลาดและ timeout ของ PCIe ซึ่งอาจมี race condition ที่ขึ้นอยู่กับจังหวะเวลาและตรวจพบได้ยาก โมเดลภาษาอาจช่วยชี้รูปแบบที่น่าสงสัยได้ แต่ไม่สามารถยืนยันได้อย่างน่าเชื่อถือว่าโค้ดถูกต้องสำหรับทุกการสลับลำดับเหตุการณ์ที่เกิดขึ้นได้
ข้อมูลที่มีอยู่ยังไม่ได้ระบุวันที่คาดหมายของ Linux 7.3-rc1 หรือรุ่นเสถียรสุดท้าย จึงยังสรุปกำหนดการเปิดตัวที่แน่นอนไม่ได้
เช่นเดียวกัน แม้การเปลี่ยนแปลง RTNL จะมีเป้าหมายให้การจัดการกฎ FIB ในหลาย network namespace ทำงานคู่ขนานได้ดีขึ้น แต่ยังไม่มีข้อมูลรองรับตัวเลขประสิทธิภาพ IPv4 หรือ IPv6 แบบเจาะจง ข้อสรุปที่ปลอดภัยที่สุดในตอนนี้คือ การลดการแย่งใช้ global lock น่าจะช่วยให้ workload ที่ทำงานคู่ขนานจำนวนมากขยายตัวได้ดีขึ้น เพียงแต่ขนาดของผลลัพธ์จะขึ้นกับลักษณะงานและการกำหนดค่าของระบบ