قابلیت Threaded NAPI در لینوکس: رفع انباشت Softirq در گیت‌وی VPN

سرورهای واسط VPN با ظرفیت بالا که میلیون‌ها بسته شبکه را در ثانیه هدایت می‌کنند، اغلب با مانعی نامرئی مواجه می‌شوند: انباشت وقفه‌های نرم‌افزاری (softirq). در شرایط ترافیک ورودی فشرده، هسته‌های پردازنده اختصاص‌یافته به رسیدگی به کارت شبکه ممکن است تمام توان محاسباتی خود را صرف اجرای روتین‌های وقفه کنند. این کمبود منابع پردازشی مستقیماً پردازش‌های رمزنگاری تونل را معطل کرده، نوسان زمانی (Jitter) را افزایش داده و موجب ریزش خاموش بسته‌ها در بافرهای سخت‌افزاری می‌شود.

هسته لینوکس 5.12 قابلیت Threaded NAPI را معرفی کرد تا چرخه پایش بسته‌ها را از وقفه‌های نرم‌افزاری سطح پایین (bottom-half softirq) به تردهای اختصاصی هسته (kthreads) انتقال دهد. این تحول به مهندسان شبکه اجازه می‌دهد فرایند پردازش ترافیک را با دقت بالا زمان‌بندی، اولویت‌بندی و تفکیک کنند.

---

گلوگاه عملکردی: وقفه‌های سخت‌افزاری، NAPI و اشباع Softirq

برای درک ضرورت Threaded NAPI در زیرساخت‌های چندگیگابیتی VPN، باید مسیر دریافت بسته از کارت شبکه فیزیکی (NIC) را مرور کرد:

1. انتقال DMA و وقفه سخت‌افزاری (Hard IRQ): کارت شبکه فیزیکی بسته‌های ورودی را از طریق دسترسی مستقیم به حافظه (DMA) درون بافر حلقوی (RX Ring Buffer) می‌نویسد و یک وقفه سخت‌افزاری به هسته پردازنده مربوطه ارسال می‌کند.
2. روتین خدمت وقفه (ISR): پردازنده فعالیت جاری خود را متوقف کرده، کنترل‌کننده سطح بالای درایور را اجرا می‌کند، دریافت وقفه‌های بعدی روی آن صف را موقتاً غیرفعال می‌سازد تا از تداخل جلوگیری شود و سپس تابع napi_schedule() را فرا می‌خواند.
3. پردازش سطح پایین (NET_RX_SOFTIRQ): فرایند تخلیه بسته به بخش سطح پایین واگذار شده که به‌طور پیش‌فرض در چارچوب NET_RX_SOFTIRQ یا توسط دیمن سیستمی ksoftirqd/x پردازش می‌شود.
4. حلقه پایش NAPI: درایور شبکه بسته‌ها را تا سقف بودجه تعیین‌شده (توسط پارامتر net.core.netdev_budget) از صف بیرون کشیده، آنها را در قالب ساختارهای sk_buff مرتب کرده و به زیرسیستم مسیریابی IP یا ماژول‌های رمزنگاری تحویل می‌دهد.

[ جریان بسته‌های ورودی ]
           │
           ▼
[ بافر سخت‌افزاری RX ] ──(وقفه سخت‌افزاری)──► [ روتین وقفه: napi_schedule() ]
                                                         │
                                                         ▼
[ شیوه سنتی: NET_RX_SOFTIRQ ] ◄───────────────── [ زیرسیستم Softirq ]
           │
           ├─► حجم بالای بسته‌ها: اتمام بودجه پردازشی
           ├─► توقف موقت پردازش‌های امنیتی و کاربری
           └─► درگیری کامل ksoftirqd روی پردازنده ──► کمبود منابع و تاخیر ناگهانی

هنگامی که سرور VPN هم‌زمان هزاران اتصال فعال با بسته‌های خرد (مانند درخواست‌های DNS یا ترافیک صدای زنده) را جابه‌جا می‌کند، نرخ ورود بسته‌ها بدون نیاز به پر شدن پهنای باند کلی افزایش می‌یابد. وقفه‌های NET_RX_SOFTIRQ هسته پردازشی را به انحصار خود درمی‌آورند.

اگر نرخ ورود داده‌ها به‌طور پیوسته از بودجه فراتر رود، هسته لینوکس کار را به ksoftirqd می‌سپارد. اما زمان‌بند CFS این دیمن را با اولویت عادی (nice = 0) اجرا می‌کند. تحت بار کاری سنگین، ksoftirqd در رقابت با سایر برنامه‌ها نمی‌تواند چرخه کافی دریافت کند و در نتیجه بافر کارت شبکه سرریز شده و تاخیر نهایی تا چند ده میلی‌ثانیه افزایش می‌یابد.

---

معماری Threaded NAPI: نحوه کارکرد سیستم

فناوری Threaded NAPI دریافت بسته‌ها را از ساختار NET_RX_SOFTIRQ جدا کرده و برای هر بخش NAPI یک ترد سیستمی مستقل به نام napi/<رابط>-<napi_id> ایجاد می‌کند.

[ جریان بسته‌های ورودی ]
           │
           ▼
[ بافر سخت‌افزاری RX ] ──(وقفه سخت‌افزاری)──► [ روتین وقفه: napi_schedule() ]
                                                         │
                                                         ▼
                                             [ napi->threaded == 1 ]
                                                         │
                                                         ▼
                                            [ ترد هسته: napi/eth0-0 ]
                                                         │
                                        ┌────────────────┴────────────────┐
                                        ▼                                 ▼
                             [ اولویت بلادرنگ ]                  [ اتصال به هسته مجزا ]
                            (SCHED_FIFO / chrt)                 (taskset / isolcpus)

در کد مبدا هسته (net/core/dev.c)، هنگامی که napi_schedule() درخواست بازبینی صف را دریافت می‌کند، فعال بودن حالت چندتردی را بررسی می‌نماید:

/* منطق پردازش درون فایل net/core/dev.c */
static inline void ____napi_schedule(struct softnet_data *sd, struct napi_struct *napi)
{
    if (test_bit(NAPI_STATE_THREADED, &napi->state)) {
        /* بیدار کردن ترد اختصاصی هسته بدون ارسال وقفه نرم‌افزاری */
        wake_up_process(napi->thread);
        return;
    }
    /* استفاده از حالت سنتی در صورت عدم فعال‌سازی */
    list_add_tail(&napi->poll_list, &sd->poll_list);
    __raise_softirq_irqoff(NET_RX_SOFTIRQ);
}

این رویکرد سه فایده راهبردی به همراه دارد:

• زمان‌بندی قطعی و بلادرنگ: چون پایشگر بسته‌ها یک ترد استاندارد (task_struct) است، مدیران می‌توانند سیاست‌های SCHED_FIFO یا SCHED_RR را اعمال کنند تا خالی کردن صف کارت شبکه همواره بر کارهای عادی سیستم تقدم یابد.
• تفکیک کامل پردازشی: تردهای NAPI می‌توانند از طریق ماسک‌های اختصاصی روی هسته‌های مجزا قفل شوند تا از جابه‌جایی مخرب داده‌ها در حافظه کش معماری‌های NUMA جلوگیری شود.
• حفظ ثبات پردازش‌های جانبی: فرایندهای رمزنگاری ترافیک VPN که روی هسته‌های دیگر فعال هستند، در اثر نوسان وقفه‌های شبکه دچار وقفه محاسباتی ناگهانی نمی‌شوند.

---

پیکربندی و راه‌اندازی Threaded NAPI در لینوکس

برای بهره‌مندی از این سازوکار، هسته لینوکس باید نسخه 5.12 یا بالاتر باشد. تنظیمات را می‌توان روی یک رابط شبکه مشخص یا به‌صورت سراسری روی سیستم فعال کرد.

۱. بررسی مشخصات هسته و وضعیت ریزش بسته

نسخه سیستم‌عامل و وضعیت سلامت بافرهای کارت شبکه را بررسی نمایید:

uname -r
# اطمینان از نسخه 5.12 یا جدیدتر

ethtool -S eth0 | grep -E "rx_discards|rx_missed_errors|rx_dropped"

۲. فعال‌سازی حالت Threaded

برای راه‌اندازی این حالت روی کارت شبکه دلخواه:

# فعال‌سازی روی رابط eth0 از طریق sysfs
echo 1 > /sys/class/net/eth0/threaded

# مشاهده وضعیت فعلی
cat /sys/class/net/eth0/threaded

برای اعمال این رویکرد به‌صورت عمومی در سراسر سرور از طریق sysctl:

# اعمال تنظیم در سطح هسته
sysctl -w net.core.threaded = 1

# پایدارسازی تنظیم پس از راه‌اندازی مجدد
echo "net.core.threaded = 1" >> /etc/sysctl.d/99-network-performance.conf

۳. پایش و تنظیم اولویت تردهای NAPI

با عبور نخستین بسته‌های ترافیک، هسته سیستم تردهای مربوطه را ایجاد می‌کند:

# مشاهده تردهای فعال NAPI
ps -eo pid,class,rtprio,ni,pri,comm,psr | grep "napi/"

نمونه خروجی سیستم:

  PID CLS RTPRIO  NI PRI COMMAND         PSR
 2140 TS       -   0  19 napi/eth0-0       2
 2141 TS       -   0  19 napi/eth0-1       3
 2142 TS       -   0  19 napi/eth0-2       4
 2143 TS       -   0  19 napi/eth0-3       5

برای ارتقای اولویت ترد و ممانعت از ایجاد گلوگاه در شرایط اوج مصرف ترافیک، اولویت بی‌درنگ FIFO را با ابزار chrt اختصاص دهید:

# تعیین اولویت 50 با الگوریتم SCHED_FIFO برای صف شماره 0
chrt -f -p 50 2140

۴. قفل کردن ترد به هسته پردازشی تفکیک‌شده

در سرورهای چندپردازنده‌ای، ترد NAPI را به هسته‌ای متصل کنید که مستقیماً با مسیر ارتباطی PCIe کارت شبکه همگام باشد:

# پیوند دادن ترد 2140 به هسته پردازشی شماره 2
taskset -cp 2 2140

---

مقایسه عملکرد: روش سنتی در برابر Threaded NAPI

تاثیر این فناوری هنگام هجوم بسته‌های کوچک پروتکل UDP به اوج خود می‌رسد:

---

پیاده‌سازی در بستر RiceGuard سرورهای VPNRice

سامانه VPNRice از چارچوب نوین RiceGuard برای پایداری کانال‌های امن استفاده می‌کند. در محیط‌های پرتراکم، RiceGuard ویژگی Threaded NAPI را در کنار فناوری چندصفی سخت‌افزاری RSS و شتاب‌دهنده eBPF به کار می‌گیرد:

1. مدیریت مستقل ورودی‌ها: صف‌های سخت‌افزاری دریافت تحت نظارت تردهای Threaded NAPI با سیاست SCHED_FIFO روی هسته‌های اختصاصی داده به چرخش درمی‌آیند.
2. جداسازی مدار رمزنگاری: محاسبات رمزگذاری بسته ChaCha20-Poly1305 روی مجموعه هسته‌های پردازشی مستقل اجرا شده و هیچ وابستگی به کانال دریافت داده ندارد.
3. تنظیم نرم فشار معکوس (Backpressure): هنگام تکمیل موقت بافرهای امنیتی، Threaded NAPI بدون درگیر ساختن وقفه‌های عمومی سیستم‌عامل، سرعت تخلیه بسته‌ها را به شکل پویا تنظیم می‌کند تا مکانیزم تفکیک ترافیک و تدابیر جلوگیری از نشت نشانی DNS با نهایت کارایی عمل کنند.