وتوضح نتائج اختبار netperf TCP_STREAM سبب أهمية التغيير، مع ضرورة التعامل معها باعتبارها قياسات مرتبطة بإعداد محدد، لا وعدًا بزيادة عامة في سرعة Linux 7.3:

• ارتفع أداء VXLAN من 34.44 إلى 39.56 غيغابت في الثانية، بزيادة قدرها 14.9%، عند استخدام MTU القياسي.
• عند تعطيل التفريغ العتادي للأنفاق، ارتفع أداء VXLAN من 21.82 إلى 29.39 غيغابت في الثانية، أي 34.7%.
• ارتفع أداء Geneve من 37.39 إلى 40.89 غيغابت في الثانية، بزيادة 9.4%، عند MTU القياسي.

لكن النتيجة الفعلية تعتمد على إعداد المسار كاملًا، بما في ذلك قيم gso_max_size وgro_max_size، وقدرات بطاقة الشبكة، وحالة التفريغ العتادي، وحجم MTU، ونوع النفق، وطبيعة الحمل. لذلك ينبغي لمسؤولي البنية التحتية اختبار مسارات VXLAN أو Geneve الخاصة بهم قبل افتراض الحصول على النسب نفسها.

تقليل التسلسل القسري عند تحديث قواعد التوجيه

يقلل الدمج أيضًا من الاعتماد على قفل RTNL الواسع عند إضافة قواعد جدول معلومات التوجيه الأمامي FIB أو حذفها في IPv4 وIPv6. وتستخدم العمليات، حيثما أمكن، أقفالًا مرتبطة بـfib_rules_ops، ما يسمح بتنفيذ عدد أكبر من المهام بالتوازي. ومع ذلك، لا يختفي RTNL بالكامل؛ إذ يظل مطلوبًا في حالات معينة، من بينها مسار fib_unmerge() للقاعدة الأولى في IPv4.

ويظهر أثر ذلك بوضوح في اختبار اصطناعي يحاكي إدارة عدد كبير من مساحات أسماء الشبكات بالتوازي. فقد انخفض زمن إنشاء 4096 مساحة أسماء وإضافة 1024 قاعدة إلى كل منها من 22.752 إلى 0.918 ثانية في IPv4، أي تسارع يقارب 24.8 مرة. وفي IPv6، انخفض الزمن من 35.181 إلى 1.214 ثانية، أي نحو 29 مرة.

هذه الأرقام تقيس حالة قصوى من التنافس على الأقفال، ولا تعني أن بدء تشغيل كل حاوية أو كل عملية توجيه في Linux سيصبح أسرع بالمقدار نفسه.

لماذا يلجأ مشرفو الشبكات إلى الذكاء الاصطناعي؟

تحولت منظومة الشبكات في النواة أيضًا إلى اختبار مبكر للتطوير المدعوم بالذكاء الاصطناعي. فقد أشار جاكوب كيسينسكي إلى وجود 632 تصحيحًا في net و648 تصحيحًا في net-next، وقدّر أن ما بين ثلث ونصف تصحيحات net-next كانت إصلاحات أو عمليات تنظيف أو توضيحات منخفضة الأولوية مدفوعة بالذكاء الاصطناعي. ويعادل ذلك تقريبًا 216 إلى 324 تصحيحًا. ووصف كيسينسكي وباولو أبيني حجم العمل الناتج بأنه «مرهق بالكامل» أو «أغرق المشرفين تمامًا».

ولا تتمثل الخطة في تسليم مهمة الإشراف إلى نموذج واحد. فقد وفّرت Meta ميزانية وإتاحة لعدة نماذج متقدمة، بهدف إخضاع التصحيحات لمراجعات أولية متعددة وتقليل احتمال مرور هلوسة أو تفسير خاطئ من نموذج واحد من دون اكتشافه.

وتشمل الأتمتة المقترحة إدارة Patchwork، وإرسال الملاحظات الروتينية المتعلقة بالإجراءات، وتحرير رسائل الالتزام، وربما تطبيق التصحيحات التي سبق أن راجعها أشخاص موثوقون. وهذه مهام أكثر تنظيمًا من الحكم على صحة تغيير يتعامل مع مسار فشل نادر أو حالة عتادية غير مألوفة.

وهنا تكمن الحدود المهمة للتجربة. فقد شدد المشرفون على أن حالات السباق غير المعتادة ومسارات استعادة العتاد، مثل أخطاء PCIe ومعالجة مهلات الانتظار، ما زالت تحتاج إلى تدقيق بشري. يمكن للذكاء الاصطناعي تصفية الأعمال المتكررة، لكنه لا يلغي ضرورة فهم التزامن، وعقود واجهات البرمجة، وترتيب خطوات الاستعادة.

برامج تشغيل وبروتوكولات جديدة

تتضمن دفعة الشبكات عددًا من إضافات دعم العتاد والبروتوكولات:

• يأتي أول إصدار من برنامج تشغيل Morse Micro mm81x لشبكات Wi‑Fi HaLow، مع دعم أجهزة USB وSDIO.
• ينضم برنامج NXPWIFI كبرنامج تشغيل لاسلكي جديد من NXP، مع استمرار العمل على التشغيل متعدد الوصلات.
• تحصل Intel على الهيكل الأولي لبرنامج تشغيل iXD لدعم Control Plane PIC Function على وحدات IPU وبطاقات FNIC من طراز E2100 وما بعده.
• تضيف الشبكات السلكية دعم CXL الأولي لبطاقات AMD/Solarflare، إلى جانب دعم تحديث البرامج الثابتة لعتاد AMD Pensando.

وتتجاوز التغييرات برامج التشغيل. إذ يضيف MPTCP آلية أخيرة لتقليص قوائم الانتظار خارج الترتيب عند التعرض لضغط شديد على الذاكرة. وهذه آلية للتعافي في الظروف المقيدة، وليست وعدًا بزيادة معدل النقل في الاستخدام المعتاد.

كما يصبح تمرير واصفات الملفات عبر AF_UNIX أسهل في التشخيص. فعند استخدام SO_RIGHTS_NOTRUNC، يستطيع الطرف المستقبل معرفة الواصف الذي رُفض ورمز الخطأ errno عندما تمنع وحدة LSM واصفًا معينًا داخل مصفوفة SCM_RIGHTS، بدل فقدان بقية المصفوفة عند أول رفض.

متى يصل Linux 7.3 إلى المستخدمين؟

كان من المتوقع صدور أول نسخة مرشحة من Linux 7.3 في 30 أغسطس 2026 تقريبًا، مع توقع الإصدار المستقر في أواخر أكتوبر إذا سار جدول التطوير المعتاد وفق الخطة.

لكن ذلك لا يعني أن معظم الخوادم أو أجهزة سطح المكتب ستحصل على هذه التحسينات في أكتوبر. فمشرفو التوزيعات يختارون إصدارات النواة، وقد ينقلون بعض التغييرات إلى إصدارات أقدم، ثم يجرون اختباراتهم وينشرون التحديثات وفق جداول منفصلة. وقد تطرح التوزيعات المتدحرجة النواة في وقت أقرب، بينما قد تتأخر التوزيعات ذات الإصدارات الثابتة مدة أطول بكثير.

وتبدو CachyOS مرشحًا منطقيًا للتبني المبكر لأنها تتبع نموذج الإصدارات المتدحرجة، لكن معلومات إصدار أغسطس المتاحة تشير إلى أن صورها كانت تستخدم Linux 7.1، من دون تأكيد موعد اعتماد Linux 7.3.

ماذا يعني الدمج عمليًا؟

بالنسبة إلى فرق البنية التحتية، تبرز فائدة مسار BIG TCP في الأنفاق الافتراضية وتقليل التنافس أثناء إعداد قواعد مساحات أسماء الشبكات على نطاق واسع. ويستحق التغيير اهتمامًا خاصًا في البيئات التي تجمع بين VXLAN أو Geneve وحركة بيانات عالية، أو التي تنشئ وتضبط عددًا كبيرًا من مساحات الأسماء في الوقت نفسه.

أما لمطوري النواة، فقد تكون تجربة مراجعة التصحيحات بالذكاء الاصطناعي بالقدر نفسه من الأهمية. فالدمج يقترح تقسيمًا عمليًا للعمل: تتولى النماذج جزءًا من الفرز المتكرر والملاحظات الإجرائية، بينما يحتفظ المشرفون بالمسؤولية عن الحالات النادرة التي قد يؤدي فيها تصحيح يبدو منطقيًا إلى توقف النظام، أو معالجة استعادة غير صحيحة، أو خرق قاعدة تزامن غير معلنة.

وهكذا يتجه Linux 7.3 إلى أن يكون إصدارًا غنيًا بتحديثات الشبكات، لكنه لا يزال يحتاج إلى اختبارات نسخ الإصدار المرشحة، والتحقق على العتاد، ودمج التوزيعات قبل أن تصبح هذه التحسينات متاحة لمعظم المستخدمين.

وتوضح نتائج اختبار netperf TCP_STREAM سبب أهمية التغيير، مع ضرورة التعامل معها باعتبارها قياسات مرتبطة بإعداد محدد، لا وعدًا بزيادة عامة في سرعة Linux 7.3:

• ارتفع أداء VXLAN من 34.44 إلى 39.56 غيغابت في الثانية، بزيادة قدرها 14.9%، عند استخدام MTU القياسي.
• عند تعطيل التفريغ العتادي للأنفاق، ارتفع أداء VXLAN من 21.82 إلى 29.39 غيغابت في الثانية، أي 34.7%.
• ارتفع أداء Geneve من 37.39 إلى 40.89 غيغابت في الثانية، بزيادة 9.4%، عند MTU القياسي.

لكن النتيجة الفعلية تعتمد على إعداد المسار كاملًا، بما في ذلك قيم gso_max_size وgro_max_size، وقدرات بطاقة الشبكة، وحالة التفريغ العتادي، وحجم MTU، ونوع النفق، وطبيعة الحمل. لذلك ينبغي لمسؤولي البنية التحتية اختبار مسارات VXLAN أو Geneve الخاصة بهم قبل افتراض الحصول على النسب نفسها.

تقليل التسلسل القسري عند تحديث قواعد التوجيه

يقلل الدمج أيضًا من الاعتماد على قفل RTNL الواسع عند إضافة قواعد جدول معلومات التوجيه الأمامي FIB أو حذفها في IPv4 وIPv6. وتستخدم العمليات، حيثما أمكن، أقفالًا مرتبطة بـfib_rules_ops، ما يسمح بتنفيذ عدد أكبر من المهام بالتوازي. ومع ذلك، لا يختفي RTNL بالكامل؛ إذ يظل مطلوبًا في حالات معينة، من بينها مسار fib_unmerge() للقاعدة الأولى في IPv4.

ويظهر أثر ذلك بوضوح في اختبار اصطناعي يحاكي إدارة عدد كبير من مساحات أسماء الشبكات بالتوازي. فقد انخفض زمن إنشاء 4096 مساحة أسماء وإضافة 1024 قاعدة إلى كل منها من 22.752 إلى 0.918 ثانية في IPv4، أي تسارع يقارب 24.8 مرة. وفي IPv6، انخفض الزمن من 35.181 إلى 1.214 ثانية، أي نحو 29 مرة.

هذه الأرقام تقيس حالة قصوى من التنافس على الأقفال، ولا تعني أن بدء تشغيل كل حاوية أو كل عملية توجيه في Linux سيصبح أسرع بالمقدار نفسه.

لماذا يلجأ مشرفو الشبكات إلى الذكاء الاصطناعي؟

تحولت منظومة الشبكات في النواة أيضًا إلى اختبار مبكر للتطوير المدعوم بالذكاء الاصطناعي. فقد أشار جاكوب كيسينسكي إلى وجود 632 تصحيحًا في net و648 تصحيحًا في net-next، وقدّر أن ما بين ثلث ونصف تصحيحات net-next كانت إصلاحات أو عمليات تنظيف أو توضيحات منخفضة الأولوية مدفوعة بالذكاء الاصطناعي. ويعادل ذلك تقريبًا 216 إلى 324 تصحيحًا. ووصف كيسينسكي وباولو أبيني حجم العمل الناتج بأنه «مرهق بالكامل» أو «أغرق المشرفين تمامًا».

ولا تتمثل الخطة في تسليم مهمة الإشراف إلى نموذج واحد. فقد وفّرت Meta ميزانية وإتاحة لعدة نماذج متقدمة، بهدف إخضاع التصحيحات لمراجعات أولية متعددة وتقليل احتمال مرور هلوسة أو تفسير خاطئ من نموذج واحد من دون اكتشافه.

وتشمل الأتمتة المقترحة إدارة Patchwork، وإرسال الملاحظات الروتينية المتعلقة بالإجراءات، وتحرير رسائل الالتزام، وربما تطبيق التصحيحات التي سبق أن راجعها أشخاص موثوقون. وهذه مهام أكثر تنظيمًا من الحكم على صحة تغيير يتعامل مع مسار فشل نادر أو حالة عتادية غير مألوفة.

وهنا تكمن الحدود المهمة للتجربة. فقد شدد المشرفون على أن حالات السباق غير المعتادة ومسارات استعادة العتاد، مثل أخطاء PCIe ومعالجة مهلات الانتظار، ما زالت تحتاج إلى تدقيق بشري. يمكن للذكاء الاصطناعي تصفية الأعمال المتكررة، لكنه لا يلغي ضرورة فهم التزامن، وعقود واجهات البرمجة، وترتيب خطوات الاستعادة.

برامج تشغيل وبروتوكولات جديدة

تتضمن دفعة الشبكات عددًا من إضافات دعم العتاد والبروتوكولات:

• يأتي أول إصدار من برنامج تشغيل Morse Micro mm81x لشبكات Wi‑Fi HaLow، مع دعم أجهزة USB وSDIO.
• ينضم برنامج NXPWIFI كبرنامج تشغيل لاسلكي جديد من NXP، مع استمرار العمل على التشغيل متعدد الوصلات.
• تحصل Intel على الهيكل الأولي لبرنامج تشغيل iXD لدعم Control Plane PIC Function على وحدات IPU وبطاقات FNIC من طراز E2100 وما بعده.
• تضيف الشبكات السلكية دعم CXL الأولي لبطاقات AMD/Solarflare، إلى جانب دعم تحديث البرامج الثابتة لعتاد AMD Pensando.

وتتجاوز التغييرات برامج التشغيل. إذ يضيف MPTCP آلية أخيرة لتقليص قوائم الانتظار خارج الترتيب عند التعرض لضغط شديد على الذاكرة. وهذه آلية للتعافي في الظروف المقيدة، وليست وعدًا بزيادة معدل النقل في الاستخدام المعتاد.

كما يصبح تمرير واصفات الملفات عبر AF_UNIX أسهل في التشخيص. فعند استخدام SO_RIGHTS_NOTRUNC، يستطيع الطرف المستقبل معرفة الواصف الذي رُفض ورمز الخطأ errno عندما تمنع وحدة LSM واصفًا معينًا داخل مصفوفة SCM_RIGHTS، بدل فقدان بقية المصفوفة عند أول رفض.

متى يصل Linux 7.3 إلى المستخدمين؟

كان من المتوقع صدور أول نسخة مرشحة من Linux 7.3 في 30 أغسطس 2026 تقريبًا، مع توقع الإصدار المستقر في أواخر أكتوبر إذا سار جدول التطوير المعتاد وفق الخطة.

لكن ذلك لا يعني أن معظم الخوادم أو أجهزة سطح المكتب ستحصل على هذه التحسينات في أكتوبر. فمشرفو التوزيعات يختارون إصدارات النواة، وقد ينقلون بعض التغييرات إلى إصدارات أقدم، ثم يجرون اختباراتهم وينشرون التحديثات وفق جداول منفصلة. وقد تطرح التوزيعات المتدحرجة النواة في وقت أقرب، بينما قد تتأخر التوزيعات ذات الإصدارات الثابتة مدة أطول بكثير.

وتبدو CachyOS مرشحًا منطقيًا للتبني المبكر لأنها تتبع نموذج الإصدارات المتدحرجة، لكن معلومات إصدار أغسطس المتاحة تشير إلى أن صورها كانت تستخدم Linux 7.1، من دون تأكيد موعد اعتماد Linux 7.3.

ماذا يعني الدمج عمليًا؟

بالنسبة إلى فرق البنية التحتية، تبرز فائدة مسار BIG TCP في الأنفاق الافتراضية وتقليل التنافس أثناء إعداد قواعد مساحات أسماء الشبكات على نطاق واسع. ويستحق التغيير اهتمامًا خاصًا في البيئات التي تجمع بين VXLAN أو Geneve وحركة بيانات عالية، أو التي تنشئ وتضبط عددًا كبيرًا من مساحات الأسماء في الوقت نفسه.

أما لمطوري النواة، فقد تكون تجربة مراجعة التصحيحات بالذكاء الاصطناعي بالقدر نفسه من الأهمية. فالدمج يقترح تقسيمًا عمليًا للعمل: تتولى النماذج جزءًا من الفرز المتكرر والملاحظات الإجرائية، بينما يحتفظ المشرفون بالمسؤولية عن الحالات النادرة التي قد يؤدي فيها تصحيح يبدو منطقيًا إلى توقف النظام، أو معالجة استعادة غير صحيحة، أو خرق قاعدة تزامن غير معلنة.

وهكذا يتجه Linux 7.3 إلى أن يكون إصدارًا غنيًا بتحديثات الشبكات، لكنه لا يزال يحتاج إلى اختبارات نسخ الإصدار المرشحة، والتحقق على العتاد، ودمج التوزيعات قبل أن تصبح هذه التحسينات متاحة لمعظم المستخدمين.