תוצאות שדווחו בבדיקת netperf TCP_STREAM ממחישות מדוע השינוי עשוי להיות חשוב, אך אין לפרש אותן כהבטחה כללית למהירות גבוהה יותר בכל מערכת Linux 7.3:

• תעבורת VXLAN עלתה מ־34.44 ל־39.56 Gbit/s — שיפור של 14.9% — ב־MTU רגיל.
• כאשר האצת החומרה של המנהרה הושבתה, VXLAN עלתה מ־21.82 ל־29.39 Gbit/s — שיפור של 34.7%.
• תעבורת Geneve עלתה מ־37.39 ל־40.89 Gbit/s — שיפור של 9.4% — ב־MTU רגיל.

אלה מדידות שתלויות בתצורה. התוצאה בפועל מושפעת מכל שרשרת התקשורת, ובכלל זה gso_max_size, ‏gro_max_size, יכולות כרטיס הרשת, הגדרות Offload, גודל ה־MTU, סוג המנהרה ואופי עומס העבודה. מנהלי תשתיות צריכים למדוד את נתיב ה־VXLAN או ה־Geneve שלהם לפני שהם מניחים שיקבלו את אותו אחוז שיפור.

פחות סדרתיות בעת עדכון כללי ניתוב

המיזוג מפחית גם את התלות בנעילת RTNL הרחבה בעת הוספה ומחיקה של כללי FIB — בסיס המידע להעברת מנות — ב־IPv4 וב־IPv6. במקרים שבהם הדבר אפשרי, הפעולות משתמשות כעת בהגנת mutex הקשורה ל־fib_rules_ops הרלוונטי, וכך מאפשרות ליותר פעולות להתבצע במקביל. RTNL עדיין נדרשת במקרים מסוימים, כולל נתיב fib_unmerge() של כלל ה־IPv4 הראשון.

בדיקה סינתטית מדגימה את הפוטנציאל בסביבות שמנהלות מספר גדול במיוחד של מרחבי שמות ברשת. יצירה מקבילית של 4,096 מרחבי שמות והוספת 1,024 כללים לכל אחד מהם התקצרה מ־22.752 ל־0.918 שניות ב־IPv4 — בערך פי 24.8 — ומ־35.181 ל־1.214 שניות ב־IPv6 — בערך פי 29.0. מדובר במדידה של התנגשות קיצונית על נעילות, לא בהבטחה לשיפור דומה בהפעלת קונטיינרים רגילה או בכל עומס ניתוב אחר.

מדוע המתחזקים פונים ל־AI למיון תיקונים?

תת־מערכת הרשתות הופכת גם למקרה מבחן לפיתוח ליבת Linux בסיוע AI. יאקוב קיצ'ינסקי דיווח על 632 תיקוני net ועל 648 תיקוני net-next, והעריך שכשליש עד מחצית מ־net-next כללו תיקונים, ניקויים או הבהרות בעדיפות נמוכה שנוצרו בהנחיית AI. מדובר בכ־216 עד 324 תיקונים. קיצ'ינסקי ופאולו אבני תיארו את עומס העבודה שנוצר כ־"מוצפים לחלוטין".

התגובה המוצעת אינה החלפת המתחזקים במודל יחיד. Meta סיפקה תקציב וגישה לכמה מודלי AI מתקדמים, כדי שכל תיקון יוכל לעבור כמה סקירות ראשוניות. הרעיון הוא לצמצם את הסיכון שהזיה או פרשנות שגויה של מודל אחד יחדרו לתהליך בלי בדיקה נוספת.

האוטומציה המתוכננת כוללת ניהול ב־Patchwork, משוב שגרתי על תהליך העבודה, עריכת הודעות קומיט ואולי גם החלה של תיקונים שכבר נבדקו בידי אנשים מהימנים. אלה משימות מובנות יחסית, השונות מהכרעה בשאלה אם שינוי מסוים נכון בנתיב נדיר של כשל.

ההבדל הזה חשוב במיוחד ברשתות של הליבה. המתחזקים הדגישו שמצבי מרוץ חריגים ונתיבי התאוששות מחומרה — למשל טיפול בשגיאות PCIe ובפסקי זמן — עדיין דורשים בדיקה אנושית. AI יכול לסנן עבודה חזרתית, אך אינו מבטל את הצורך להבין מקביליות, חוזי API וסדר פעולות ההתאוששות.

מנהלי התקנים ופרוטוקולים חדשים

משיכת הקוד של הרשתות כוללת גם תמיכה ראשונית בחומרה ובפרוטוקולים:

• מנהל ההתקן הראשוני Morse Micro mm81x ל־Wi‑Fi HaLow תומך בהתקני USB ו־SDIO.
• NXPWIFI מצטרף כמנהל התקן אלחוטי חדש של NXP, ובמקביל נמשכת העבודה על הפעלה מרובת קישורים — MLO.
• 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 במנהרות Overlay והפחתת התחרות על נעילות בעת ניהול כללי רשת במרחבי שמות רבים. הם רלוונטיים במיוחד לסביבות המשלבות VXLAN או Geneve עם תעבורה בקצב גבוה, או כאלה שיוצרות ומגדירות מרחבי שמות רבים במקביל.

עבור מפתחי הליבה, ניסוי סקירת הקוד באמצעות AI עשוי להיות משמעותי לא פחות. המיזוג מציע חלוקת עבודה מעשית: מודלים יכולים לקחת על עצמם מיון חוזר ומשוב פרוצדורלי, בעוד שהמתחזקים שומרים את האחריות למקרים הנדירים שבהם תיקון שנראה הגיוני עלול לגרום ל־deadlock, לטפל באופן שגוי בהתאוששות או להפר כלל סנכרון שלא תועד במפורש.

התוצאה היא חבילת שינויים רחבה בתחום הרשתות לקראת Linux 7.3 — אך היא עדיין זקוקה לבדיקות של מועמדות השחרור, לאימות מול חומרה ולשילוב בהפצות לפני שרוב המשתמשים יוכלו להסתמך עליה.

תוצאות שדווחו בבדיקת netperf TCP_STREAM ממחישות מדוע השינוי עשוי להיות חשוב, אך אין לפרש אותן כהבטחה כללית למהירות גבוהה יותר בכל מערכת Linux 7.3:

• תעבורת VXLAN עלתה מ־34.44 ל־39.56 Gbit/s — שיפור של 14.9% — ב־MTU רגיל.
• כאשר האצת החומרה של המנהרה הושבתה, VXLAN עלתה מ־21.82 ל־29.39 Gbit/s — שיפור של 34.7%.
• תעבורת Geneve עלתה מ־37.39 ל־40.89 Gbit/s — שיפור של 9.4% — ב־MTU רגיל.

אלה מדידות שתלויות בתצורה. התוצאה בפועל מושפעת מכל שרשרת התקשורת, ובכלל זה gso_max_size, ‏gro_max_size, יכולות כרטיס הרשת, הגדרות Offload, גודל ה־MTU, סוג המנהרה ואופי עומס העבודה. מנהלי תשתיות צריכים למדוד את נתיב ה־VXLAN או ה־Geneve שלהם לפני שהם מניחים שיקבלו את אותו אחוז שיפור.

פחות סדרתיות בעת עדכון כללי ניתוב

המיזוג מפחית גם את התלות בנעילת RTNL הרחבה בעת הוספה ומחיקה של כללי FIB — בסיס המידע להעברת מנות — ב־IPv4 וב־IPv6. במקרים שבהם הדבר אפשרי, הפעולות משתמשות כעת בהגנת mutex הקשורה ל־fib_rules_ops הרלוונטי, וכך מאפשרות ליותר פעולות להתבצע במקביל. RTNL עדיין נדרשת במקרים מסוימים, כולל נתיב fib_unmerge() של כלל ה־IPv4 הראשון.

בדיקה סינתטית מדגימה את הפוטנציאל בסביבות שמנהלות מספר גדול במיוחד של מרחבי שמות ברשת. יצירה מקבילית של 4,096 מרחבי שמות והוספת 1,024 כללים לכל אחד מהם התקצרה מ־22.752 ל־0.918 שניות ב־IPv4 — בערך פי 24.8 — ומ־35.181 ל־1.214 שניות ב־IPv6 — בערך פי 29.0. מדובר במדידה של התנגשות קיצונית על נעילות, לא בהבטחה לשיפור דומה בהפעלת קונטיינרים רגילה או בכל עומס ניתוב אחר.

מדוע המתחזקים פונים ל־AI למיון תיקונים?

תת־מערכת הרשתות הופכת גם למקרה מבחן לפיתוח ליבת Linux בסיוע AI. יאקוב קיצ'ינסקי דיווח על 632 תיקוני net ועל 648 תיקוני net-next, והעריך שכשליש עד מחצית מ־net-next כללו תיקונים, ניקויים או הבהרות בעדיפות נמוכה שנוצרו בהנחיית AI. מדובר בכ־216 עד 324 תיקונים. קיצ'ינסקי ופאולו אבני תיארו את עומס העבודה שנוצר כ־"מוצפים לחלוטין".

התגובה המוצעת אינה החלפת המתחזקים במודל יחיד. Meta סיפקה תקציב וגישה לכמה מודלי AI מתקדמים, כדי שכל תיקון יוכל לעבור כמה סקירות ראשוניות. הרעיון הוא לצמצם את הסיכון שהזיה או פרשנות שגויה של מודל אחד יחדרו לתהליך בלי בדיקה נוספת.

האוטומציה המתוכננת כוללת ניהול ב־Patchwork, משוב שגרתי על תהליך העבודה, עריכת הודעות קומיט ואולי גם החלה של תיקונים שכבר נבדקו בידי אנשים מהימנים. אלה משימות מובנות יחסית, השונות מהכרעה בשאלה אם שינוי מסוים נכון בנתיב נדיר של כשל.

ההבדל הזה חשוב במיוחד ברשתות של הליבה. המתחזקים הדגישו שמצבי מרוץ חריגים ונתיבי התאוששות מחומרה — למשל טיפול בשגיאות PCIe ובפסקי זמן — עדיין דורשים בדיקה אנושית. AI יכול לסנן עבודה חזרתית, אך אינו מבטל את הצורך להבין מקביליות, חוזי API וסדר פעולות ההתאוששות.

מנהלי התקנים ופרוטוקולים חדשים

משיכת הקוד של הרשתות כוללת גם תמיכה ראשונית בחומרה ובפרוטוקולים:

• מנהל ההתקן הראשוני Morse Micro mm81x ל־Wi‑Fi HaLow תומך בהתקני USB ו־SDIO.
• NXPWIFI מצטרף כמנהל התקן אלחוטי חדש של NXP, ובמקביל נמשכת העבודה על הפעלה מרובת קישורים — MLO.
• 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 במנהרות Overlay והפחתת התחרות על נעילות בעת ניהול כללי רשת במרחבי שמות רבים. הם רלוונטיים במיוחד לסביבות המשלבות VXLAN או Geneve עם תעבורה בקצב גבוה, או כאלה שיוצרות ומגדירות מרחבי שמות רבים במקביל.

עבור מפתחי הליבה, ניסוי סקירת הקוד באמצעות AI עשוי להיות משמעותי לא פחות. המיזוג מציע חלוקת עבודה מעשית: מודלים יכולים לקחת על עצמם מיון חוזר ומשוב פרוצדורלי, בעוד שהמתחזקים שומרים את האחריות למקרים הנדירים שבהם תיקון שנראה הגיוני עלול לגרום ל־deadlock, לטפל באופן שגוי בהתאוששות או להפר כלל סנכרון שלא תועד במפורש.

התוצאה היא חבילת שינויים רחבה בתחום הרשתות לקראת Linux 7.3 — אך היא עדיין זקוקה לבדיקות של מועמדות השחרור, לאימות מול חומרה ולשילוב בהפצות לפני שרוב המשתמשים יוכלו להסתמך עליה.