أبرز التغييرات التقنية

BIG TCP يعبر أنفاق VXLAN وGeneve

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

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

وتوضح سلسلة الرقع الداعمة لهذه الميزة حجم العمل المطلوب خلف الكواليس: فقد كان على مسارات الأنفاق التوقف عن افتراض أن طول الحزمة سيبقى أقل من 64 كيلوبايت أو أنه يمكن تخزينه في حقول بحجم 16 بت، وهي افتراضات كانت قد تقطع الطول الأكبر من اللازم. وتشمل السلسلة أحمال BIG TCP لكل من IPv4 وIPv6 عبر VXLAN وGeneve.

تقليل التزاحم حول قفل RTNL

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

وتثبت المواد المتاحة أن الغرض هو تحسين التزامن في هذه العمليات، لكنها لا تقدم قياسات دقيقة وموثوقة لمكاسب الأداء في IPv4 أو IPv6. لذلك فإن ذكر نسبة مئوية أو معامل تسارع محدد سيتجاوز الأدلة المتوفرة.

تعريفات وأعمال أخرى في طبقة الشبكات

يتضمن دمج الشبكات أيضاً توسعة لدعم العتاد والبروتوكولات، من بينها:

• إضافة تعريف Morse Micro mm81x لأجهزة S1G طويلة المدى، إلى جانب تعريف NXPWIFI جديد.
• إدخال بنية أولية لتعريف Intel iXD تستهدف وظيفة Control Plane PIC في وحدات IPU وبطاقات FNIC من Intel E2100 وما بعدها.
• تحسين تعامل MPTCP مع حالات الضغط الشديد على الذاكرة، بما في ذلك تقليص قائمة الاستقبال الخاصة بالبيانات التي تصل خارج ترتيبها.
• مجموعة أوسع من التحسينات والإصلاحات وأعمال التعريفات السلكية واللاسلكية ضمن منظومة الشبكات.

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

لماذا قال المشرفون إنهم «مرهقون تماماً»؟

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

وتأتي هذه الضغوط في سياق ارتفاع أوسع في حجم الإرساليات. ففي فترة امتدت تسعة أيام، تلقى النظام 405 إرسالية تحمل الوسم [PATCH net] و687 إرسالية تحمل الوسم [PATCH net-next]. وصُنّفت 37% منها على أنها إصلاحات، مع احتمال أن تكون النسبة الفعلية أعلى بسبب عدم التزام بعض المرسلين بالوسوم الصحيحة.

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

كيف سيستخدم المشرفون الذكاء الاصطناعي في المراجعة؟

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

كما يعتزمون توجيه النماذج إلى مهام سير العمل الروتينية، مثل:

• إدارة قوائم الانتظار في Patchwork؛
• تقديم ملاحظات حول مشكلات إجراءات الإرسال الشائعة؛
• تحرير رسائل الالتزام؛
• وربما تطبيق الرقع التي تحمل بالفعل وسوم مراجعة من أشخاص موثوقين.

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

ما الذي لا يزال مجهولاً؟

لا تحدد التقارير المتاحة موعد إصدار المرشح الأول Linux 7.3-rc1 أو موعد الإصدار المستقر النهائي. فهي تتحدث عن تغييرات شبكات دُمجت خلال دورة تطوير 7.3، لا عن جدول إصدار منشور.

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

أبرز التغييرات التقنية

BIG TCP يعبر أنفاق VXLAN وGeneve

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

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

وتوضح سلسلة الرقع الداعمة لهذه الميزة حجم العمل المطلوب خلف الكواليس: فقد كان على مسارات الأنفاق التوقف عن افتراض أن طول الحزمة سيبقى أقل من 64 كيلوبايت أو أنه يمكن تخزينه في حقول بحجم 16 بت، وهي افتراضات كانت قد تقطع الطول الأكبر من اللازم. وتشمل السلسلة أحمال BIG TCP لكل من IPv4 وIPv6 عبر VXLAN وGeneve.

تقليل التزاحم حول قفل RTNL

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

وتثبت المواد المتاحة أن الغرض هو تحسين التزامن في هذه العمليات، لكنها لا تقدم قياسات دقيقة وموثوقة لمكاسب الأداء في IPv4 أو IPv6. لذلك فإن ذكر نسبة مئوية أو معامل تسارع محدد سيتجاوز الأدلة المتوفرة.

تعريفات وأعمال أخرى في طبقة الشبكات

يتضمن دمج الشبكات أيضاً توسعة لدعم العتاد والبروتوكولات، من بينها:

• إضافة تعريف Morse Micro mm81x لأجهزة S1G طويلة المدى، إلى جانب تعريف NXPWIFI جديد.
• إدخال بنية أولية لتعريف Intel iXD تستهدف وظيفة Control Plane PIC في وحدات IPU وبطاقات FNIC من Intel E2100 وما بعدها.
• تحسين تعامل MPTCP مع حالات الضغط الشديد على الذاكرة، بما في ذلك تقليص قائمة الاستقبال الخاصة بالبيانات التي تصل خارج ترتيبها.
• مجموعة أوسع من التحسينات والإصلاحات وأعمال التعريفات السلكية واللاسلكية ضمن منظومة الشبكات.

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

لماذا قال المشرفون إنهم «مرهقون تماماً»؟

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

وتأتي هذه الضغوط في سياق ارتفاع أوسع في حجم الإرساليات. ففي فترة امتدت تسعة أيام، تلقى النظام 405 إرسالية تحمل الوسم [PATCH net] و687 إرسالية تحمل الوسم [PATCH net-next]. وصُنّفت 37% منها على أنها إصلاحات، مع احتمال أن تكون النسبة الفعلية أعلى بسبب عدم التزام بعض المرسلين بالوسوم الصحيحة.

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

كيف سيستخدم المشرفون الذكاء الاصطناعي في المراجعة؟

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

كما يعتزمون توجيه النماذج إلى مهام سير العمل الروتينية، مثل:

• إدارة قوائم الانتظار في Patchwork؛
• تقديم ملاحظات حول مشكلات إجراءات الإرسال الشائعة؛
• تحرير رسائل الالتزام؛
• وربما تطبيق الرقع التي تحمل بالفعل وسوم مراجعة من أشخاص موثوقين.

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

ما الذي لا يزال مجهولاً؟

لا تحدد التقارير المتاحة موعد إصدار المرشح الأول Linux 7.3-rc1 أو موعد الإصدار المستقر النهائي. فهي تتحدث عن تغييرات شبكات دُمجت خلال دورة تطوير 7.3، لا عن جدول إصدار منشور.

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