1. Pengenalan
Aplikasi masa nyata, seperti realiti maya (VR), permainan dalam talian, dron kawalan jauh dan kereta pandu sendiri, semakin popular. Aplikasi masa nyata ini memerlukan kependaman rendah dalam susunan milisaat (ms) hingga mikrosaat (μs) [1]-[4]. Disebabkan oleh keperluan masa nyata yang tinggi ini, setiap aplikasi sering dipasang dan dilaksanakan pada peranti terminal yang sama. Walau bagaimanapun, adalah tidak diingini untuk memproses beban kerja yang berat pada peranti terminal kerana keperluan untuk saiz yang lebih kecil dan hayat bateri yang lebih lama. Untuk memenuhi keperluan ini, Institut Piawaian Telekomunikasi Eropah (ETSI) telah mencadangkan pengkomputeran tepi berbilang akses (MEC) [5], yang membolehkan peranti terminal memunggah beban kerja ini ke awan tepi yang terletak berhampiran peranti terminal. Dari perspektif perbelanjaan modal dan kemudahan operasi, awan tepi tersebut sering dilaksanakan oleh pelayan tujuan umum dan menggunakan pelayan maya seperti mesin maya (VM) dan bekas. Walau bagaimanapun, pemajuan paket daripada kad antara muka rangkaian (NIC) kepada aplikasi dalam pelayan maya pada pelayan tujuan umum membawa masalah prestasi kependaman yang lebih lama dan daya pemprosesan yang lebih rendah disebabkan oleh overhed virtualisasi [6]-[9]. Malah, menurut keputusan percubaan kami, kelewatan penghantaran paket dalam VM dengan mudah boleh melebihi 1 ms [10]. Oleh itu, kelewatan penghantaran paket dalam pelayan maya perlu dikurangkan sekurang-kurangnya kepada susunan μs.
Penggunaan kuasa pelayan awan tepi juga perlu dipertimbangkan. Untuk mencapai kependaman rendah, penalaan prestasi untuk pelayan diperlukan, seperti menetapkan frekuensi unit pemprosesan pusat (CPU) pada maksimum dan melumpuhkan fungsi terbiar CPU (keadaan C) [10], [11]. Penalaan ini merendahkan kependaman pada kos penggunaan kuasa pelayan yang lebih tinggi. Terdapat pertukaran antara kependaman rendah dan penjimatan kuasa. Walaupun peningkatan dalam penggunaan kuasa bagi setiap pelayan kelihatan kecil, seperti beberapa watt, hasilnya akan menjadi peningkatan besar dalam penggunaan kuasa memandangkan bilangan pelayan yang banyak. Oleh itu, penggunaan kuasa pelayan harus serendah mungkin.
Apabila mereka bentuk penyelesaian rangkaian kependaman rendah untuk pelayan maya, empat keperluan harus dipertimbangkan. (A): Latensi rendah dalam susunan μs untuk pemajuan paket dalam pelayan maya. (B): Penggunaan kuasa yang lebih rendah daripada penyelesaian sedia ada. (C): Tidak memerlukan pengubahsuaian aplikasi. Dari sudut pandangan pembangun aplikasi, adalah wajar bagi pembangun aplikasi menggunakan penyelesaian rangkaian kependaman rendah tanpa pengubahsuaian aplikasi. Pembangun aplikasi boleh menggunakan fungsi rangkaian dengan mudah melalui antara muka program aplikasi (API) soket POSIX [12] memandangkan kernel Linux menyediakan susunan protokol yang merangkumi protokol internet (IP), protokol datagram pengguna (UDP), dan protokol popular lain. Jika penyelesaian rangkaian kependaman rendah memerlukan fungsi rangkaian khas, pembangun aplikasi perlu memperoleh kepakaran rangkaian yang rumit, dan ini akan meningkatkan kos pembangunan aplikasi. (D): Tidak memerlukan pembangunan semula perisian untuk setiap kemas kini keselamatan kernel. Memandangkan kemas kini keselamatan kernel kerap berlaku, kos membangunkan semula perisian untuk setiap kemas kini keselamatan kernel akan menjadi sangat besar. Dari sudut pandangan pembekal perkhidmatan, adalah wajar bagi penyedia perkhidmatan untuk menggunakan kemas kini keselamatan kernel tanpa membangunkan semula perisian penyelesaian rangkaian kependaman rendah.
Oleh itu, kami mereka bentuk dan melaksanakan sistem rangkaian kependaman rendah dan cekap tenaga, tinjauan sibuk kernel cekap tenaga (EE-KBP), yang memenuhi keperluan (A), (B), (C) dan (D). EE-KBP ini mempunyai urutan pengundian yang sentiasa menyemak paket yang tiba dalam kernel dan segera memindahkannya ke susunan protokol rangkaian kernel untuk memenuhi keperluan (A). Ini sama dengan KBP [10]. Sistem asas, KBP, tidak dapat memenuhi keperluan (B) kerana benang pengundian sentiasa menyemak ketibaan paket, tidak kira sama ada paket tiba atau tidak, dan ini menggunakan lebih banyak kuasa. Oleh itu, EE-KBP memanjangkan KBP untuk mencapai penggunaan kuasa yang lebih rendah dengan mengawal untuk tidur benang pengundian. Urusan undian tidur adalah mencabar kerana overhed pemulihan daripada tidur meningkatkan kelewatan ekor pemajuan paket. EE-KBP meminimumkan kesan negatif ini dengan membangunkan benang pengundian tidur apabila permintaan gangguan perkakasan (hardIRQ) dicetuskan oleh ketibaan paket. Di samping itu, untuk meningkatkan kesan penjimatan kuasa dengan meletakkan benang pengundian kepada tidur, EE-KBP mengawal frekuensi CPU teras CPU yang digunakan oleh benang undian secara dinamik. Sambungan ini membolehkan keperluan (A) dan (B) dipenuhi secara serentak. Memandangkan EE-KBP menggunakan tindanan protokol kernel sedia ada dan tidak mengubahnya, aplikasi boleh menggunakan API soket POSIX, dan ini memenuhi keperluan (C). Tambahan pula, kerana perubahan yang disebabkan oleh sambungan ini adalah kecil, ia boleh digunakan pada kernel sedia ada oleh rangka kerja kernel livepatch [13], dan ini memenuhi keperluan (D).
Selebihnya kertas kerja ini disusun seperti berikut:
- Analisis tentang cara menggabungkan kependaman rendah dan penjimatan kuasa: kami menganalisis kaedah pemajuan paket yang pada masa yang sama mencapai kependaman rendah dan penjimatan kuasa (lihat Bahagian 3);
- Reka bentuk dan pelaksanaan EE-KBP: kami mereka bentuk dan melaksanakan sistem rangkaian kependaman rendah dan cekap tenaga (lihat Bahagian 4);
- Demonstrasi faedah EE-KBP: keputusan percubaan kami menunjukkan bahawa EE-KBP boleh meningkatkan kecekapan tenaga, mengurangkan kelewatan penghantaran paket pada skala μs dan mencapai daya pemprosesan yang tinggi dalam konfigurasi VM (lihat Bahagian 5).
2. Kerja Berkaitan
Kernel Linux menggunakan kaedah penerimaan paket mod gangguan. Apabila NIC menerima paket, NIC mencetuskan hardIRQ untuk memberitahu kernel ketibaan paket. Selepas ini, permintaan gangguan perisian (softIRQ) dijadualkan untuk pemprosesan protokol seterusnya. Memandangkan hardIRQ mempunyai keutamaan yang tinggi, apabila hardIRQ berlaku, proses yang berjalan pada teras CPU dihentikan dan kerja yang sedang dijalankan dipindahkan ke kawasan memori, jadi overhed ini adalah penting. Apabila kekerapan ketibaan paket adalah tinggi, banyak hardIRQ dijana, dan overhed yang disebabkan oleh hardIRQ mengakibatkan kemerosotan prestasi. Untuk mengatasi masalah ini, API Baharu (NAPI) [14], yang diterima pakai daripada versi kernel 2.4.20 yang lebih baharu, menggunakan kaedah hibrid mod gangguan dan mod pengundian. Apabila kekerapan ketibaan paket adalah tinggi, NAPI menyekat hardIRQ dan benang kernel mengundi penimbal penerima. Walau bagaimanapun, pemprosesan protokol seterusnya dilakukan dalam konteks softIRQ. NAPI tidak dapat mengelakkan persaingan softIRQ dan kelewatan skala ms [10], oleh itu NAPI tidak dapat memenuhi keperluan (A).
Kit Pembangunan Data Plane (DPDK) [15] menyediakan rangka kerja penerimaan paket mod pengundian. Benang undian dalam ruang pengguna sentiasa menyemak paket yang tiba dan segera memindahkannya ke program pengguna. Memandangkan DPDK memintas timbunan protokol kernel dan tidak menghasilkan sebarang gangguan, ia boleh mencapai kependaman rendah. Walau bagaimanapun, memandangkan urutan pengundian dalam ruang pengguna sentiasa menyemak ketibaan paket tanpa mengira sama ada paket tiba atau tidak, kaedah ini menggunakan lebih banyak kuasa dan tidak dapat memenuhi keperluan (B). Di samping itu, untuk menggunakan DPDK, fungsi pengundian dan fungsi protokol rangkaian, seperti lapisan 2 (L2) / lapisan 3 (L3) / lapisan 4 (L4), perlu disepadukan dengan program pengguna. Oleh itu, DPDK tidak dapat memenuhi keperluan (C).
l3fwd-kuasa [16] ialah aplikasi sampel DPDK untuk penggunaan kuasa yang rendah. l3fwd-kuasa menyediakan pelbagai mod aplikasi. Dalam APP_MODE_INTERRUPT, l3fwd-kuasa menggunakan kaedah penerimaan paket hibrid mod gangguan dan mod pengundian. Apabila tiada paket tiba semasa 10 kitaran pengundian berturut-turut, selang pengundian dibuat jarang dengan meletakkan arahan jeda dalam gelung pengundian. Selepas itu, apabila tiada paket tiba selama 300 kitaran pengundian berturut-turut, benang pengundian dimasukkan ke dalam tidur. Apabila satu paket tiba selepas urutan pengundian telah memasuki keadaan tidur, eventfd memanggil urutan pengundian dan memulakan semula pengundian. Memandangkan logik tidur ini bertujuan untuk mengikuti turun naik trafik yang perlahan seperti skala pasang surut dan tidak sesuai untuk tidur frekuensi tinggi, kesan penjimatan kuasa adalah terhad apabila kekerapan turun naik trafik adalah tinggi. Di samping itu, ini APP_MODE_INTERRUPT tidak mempunyai fungsi untuk mengawal frekuensi CPU teras CPU secara dinamik yang digunakan oleh benang undian. Dalam APP_MODE_LEGACY, l3fwd-kuasa hanya menggunakan mod pengundian. Dalam mod ini, benang undian tidur, dan ia mengawal kekerapan CPU teras CPU secara dinamik yang digunakan oleh benang undian apabila tiada paket tiba. Memandangkan mod ini tidak mempunyai fungsi untuk memulakan semula urutan pengundian dengan pantas, seperti mod gangguan, ia boleh menyebabkan kelewatan yang besar dan tidak dapat memenuhi keperluan (A). Dalam kedua-duanya APP_MODE_INTERRUPT and APP_MODE_LEGACY, untuk menggunakan fungsi menerima paket bagi l3fwd-kuasa, fungsi pengundian dan fungsi protokol rangkaian, seperti L2/L3/L4, perlu disepadukan ke program pengguna dan ini tidak dapat memenuhi keperluan (C).
Li et al. [17] merumuskan hubungan antara penggunaan CPU teras CPU yang digunakan oleh benang pengundian dan kelewatan penghantaran paket. Apabila penggunaan CPU berada di bawah nilai malar, seperti 80%, ia mengurangkan kekerapan pengundian dengan menambah jeda singkat. Memandangkan kaedah ini bertujuan untuk mengikuti turun naik trafik yang perlahan seperti skala pasang surut pada pautan berkelajuan rendah dan tidak sesuai untuk tidur frekuensi tinggi, kesan penjimatan kuasa adalah terhad apabila kekerapan turun naik trafik adalah tinggi. Di samping itu, memandangkan kaedah ini bertujuan untuk digunakan pada penyelesaian DPDK, fungsi pengundian dan fungsi protokol rangkaian, seperti L2/L3/L4, perlu disepadukan kepada program pengguna dan ini tidak dapat memenuhi keperluan (C).
Busy Poll Sockets (BPS) [18] menyediakan kaedah penerimaan paket hibrid bagi mod gangguan dan mod pengundian, yang diterima pakai daripada versi kernel 3.11 yang lebih baharu. Apabila aplikasi memanggil a SO_BUSY_POLL pilihan soket dan menetapkan masa untuk mengundi sibuk, mengundi sibuk dilakukan untuk menerima paket untuk tempoh yang ditetapkan. Kecuali untuk tempoh yang ditentukan, penerimaan paket berasaskan softIRQ dilakukan. Jika permohonan tidak tahu bila paket akan sampai, pengundian sibuk tidak boleh dilakukan mengikut masa ketibaan paket. Oleh itu, kaedah ini tidak sesuai untuk trafik di mana masa ketibaan paket tidak dapat diramalkan. Di samping itu, oleh kerana aplikasi perlu memasukkan fungsi untuk menentukan tempoh masa untuk mengundi sibuk, ini tidak dapat memenuhi keperluan (C).
AF_XDP [19] ialah jenis soket baharu untuk pemprosesan bingkai mentah, diterima pakai daripada versi kernel 4.18 yang lebih baharu. Memandangkan aplikasi boleh menerima bingkai mentah melalui soket AF_XDP tanpa timbunan protokol kernel, AF_XDP menyediakan laluan data yang pantas. Walau bagaimanapun, memandangkan AF_XDP ialah laluan data penerima paket mod gangguan dan memberitahu aplikasi ketibaan bingkai dalam konteks NET_RX_SOFTIRQ, ia tidak dapat mengelakkan persaingan softIRQ dan kelewatan skala ms. Oleh itu AF_XDP tidak dapat memenuhi keperluan (A). Selain itu, untuk menggunakan AF_XDP, fungsi protokol rangkaian, seperti L2/L3/L4, perlu disepadukan ke aplikasi dan ini tidak dapat memenuhi keperluan (C).
KBP [10] meningkatkan kernel untuk menyediakan rangkaian kependaman rendah dengan mendayakan penerimaan paket mod undian. Memandangkan KBP melancarkan utas kernel untuk melaksanakan pengundian yang sibuk dan bukannya menerima paket berasaskan softIRQ dan mengelakkan persaingan softIRQ, KBP boleh mencapai kependaman rendah dalam susunan μs untuk pemajuan paket. Selain itu, KBP tidak mengubah suai susunan protokol kernel sedia ada, jadi pengubahsuaian aplikasi tidak diperlukan. Tambahan pula, oleh kerana fungsi KBP digunakan pada kernel sedia ada dengan menggunakan kernel livepatch, pembangunan semula perisian untuk setiap kemas kini keselamatan kernel adalah tidak diperlukan. Walau bagaimanapun, utas pengundian menduduki teras CPU dan menghalang utas daripada tidur, yang memerlukan penggunaan kuasa yang lebih besar dan tidak dapat memenuhi keperluan (B).
IX [20] menyediakan ciri rangkaian run-to-completion dalam kernel untuk kependaman rendah. Zygos [21] menyediakan penjadual asal, dan Shenango [22] dan Shinjuku [23] menyediakan algoritma interupsi antara pemproses dalam kernel untuk kependaman rendah. Penyelesaian ini memerlukan bahagian teras kernel untuk diubah suai dan tidak memenuhi keperluan (D).
DMM lwIP [24] dan Slim [25] menyediakan penyelesaian pemajuan paket kependaman rendah. Untuk menambah fungsi khas pada susunan protokol kernel tanpa mengubah suai kernel, penyelesaian ini menggunakan rangka kerja LD_PRELOAD. Rangka kerja LD_PRELOAD membolehkan aplikasi menggunakan fungsi tersuai dengan merampas lib.c perpustakaan, seperti soket.c. Rangka kerja ini perlu melaksanakan fungsi tersuai pada aplikasi untuk saling bekerja dengan fungsi khas dan ini tidak dapat memenuhi keperluan (C).
3. Analisis Kependaman Rendah dan Penjimatan Kuasa
Kami membincangkan faktor dan mekanisme yang menyebabkan kelewatan dalam penghantaran paket menggunakan kaedah penghantaran paket NAPI semasa sebagai contoh. Rajah 1 menunjukkan seni bina NAPI. Untuk bahagian penerima (Rx), apabila NIC menerima paket, NIC menyalin data paket ke dalam ruang memori hos melalui akses ingatan terus (DMA) tanpa menggunakan sumber CPU. Untuk melaporkan ketibaan paket, NIC memanggil hardIRQ dan mendaftarkan maklumat peranti rangkaian ke a poll_list dalam konteks hardIRQ. Selepas itu, softIRQ dijadualkan untuk mengundi paket dari poll_list dan melaksanakan pemprosesan protokol seterusnya, seperti Ethernet, IP dan UDP. Memandangkan hardIRQ mempunyai keutamaan yang sangat tinggi, dan proses lain tidak boleh menggunakan teras CPUnya semasa konteksnya, pemprosesan berat tidak seharusnya diperuntukkan dalam konteks hardIRQ untuk kestabilan sistem. Oleh itu, proses protokol berat ini dilakukan dalam konteks softIRQ. Walau bagaimanapun, softIRQ daripada NET_RX_SOFTIRQ boleh ditandingi oleh softIRQ lain, seperti gangguan pemasa tempatan dan ata_piix, dan ksoftirqd menjadualkan softIRQ ini, yang mesti menunggu sehingga masa yang dijadualkan. Selain itu, apabila ksoftirqd tidak mempunyai masa CPU yang mencukupi, penjadualan softIRQ ditangguhkan. Persaingan softIRQ ini menyebabkan kelewatan skala ms seperti yang dibincangkan dalam kerja sebelumnya [10]. Persaingan softIRQ ini boleh berlaku pada kernel dalam konfigurasi bare-metal, pada kernel hos dalam konfigurasi kontena, dan pada kernel hos dan kernel tetamu dalam konfigurasi VM. Memandangkan persaingan softIRQ ini tidak dapat dielakkan oleh sebarang penalaan kernel, perubahan seni bina diperlukan untuk mendapatkan laluan data kependaman rendah. Untuk bahagian penghantaran (Tx), memandangkan paket dihantar tanpa sebarang gangguan selepas aplikasi menghantar paket, kernel tidak mengalami sebarang kelewatan skala ms.
Kaedah penerimaan paket mod pengundian seperti DPDK, BPS dan KBP sesuai untuk mengelakkan persaingan softIRQ. Memandangkan kaedah penerimaan paket mod undian boleh mengesan ketibaan paket dengan cepat dengan mengundi sibuk, tidak perlu melaporkan ketibaan paket dengan gangguan. Oleh itu, kaedah penerimaan paket mod pengundian tidak menimbulkan persaingan softIRQ NET_RX_SOFTIRQ. Walau bagaimanapun, DPDK memerlukan fungsi pengundian dan fungsi protokol rangkaian, seperti L2/L3/L4, untuk disepadukan ke program pengguna. BPS memerlukan satu fungsi untuk disepadukan yang menentukan tempoh masa untuk sibuk mengundi. Oleh itu, DPDK dan BPS tidak dapat memenuhi syarat (C). Untuk mendapatkan kaedah penerimaan paket mod undian yang tidak memerlukan pengubahsuaian aplikasi, benang undian perlu disepadukan dalam kernel. Walau bagaimanapun, memandangkan terdapat kekangan bahawa berbilang proses softIRQ tidak boleh dilaksanakan dalam teras CPU, dan melaksanakan proses protokol rangkaian, yang dilaksanakan dalam konteks softIRQ dalam NAPI, dengan benang pengundian memerlukan kebuntuan softIRQ, yang mencabar. KBP, kerja kami sebelum ini seperti yang ditunjukkan dalam Rajah 2, mempunyai benang undian dalam kernel dan ciri kawalan kebuntuan softIRQs, dan ia tidak mengubah susunan protokol paket kernel sedia ada dan API soket POSIX, sekali gus membolehkan penghantaran paket kependaman rendah dan membuat pengubahsuaian aplikasi tidak diperlukan. Tambahan pula, KBP boleh digunakan pada NAPI sedia ada oleh kernel livepatch memandangkan KBP menawarkan fungsi pengundian ini dengan sedikit perubahan pada NAPI. Oleh itu, KBP memenuhi keperluan (A), (C), dan (D). Walau bagaimanapun, memandangkan utas pengundian sentiasa melakukan pengundian yang sibuk tanpa mengira sama ada paket telah tiba atau tidak, KBP membazirkan sumber CPU dan meningkatkan penggunaan kuasa. Oleh itu, KBP tidak memenuhi keperluan (B).
Memandangkan KBP boleh memenuhi keperluan (A), (C), dan (D), jika KBP boleh ditambah baik untuk memenuhi keperluan (B), maka semua keperluan boleh dipenuhi. Idea asas untuk penjimatan kuasa adalah untuk meletakkan benang pengundian untuk tidur sementara tiada paket tiba. Masa ketibaan paket selalunya tidak dapat diramalkan untuk aplikasi masa nyata, seperti VR, permainan dalam talian, dron kawalan jauh dan kereta pandu sendiri. Contohnya, dalam VR, sukar untuk meramalkan bila pengguna akan mengalihkan pandangannya, jadi sukar untuk meramalkan bila maklumat pandangan daripada paparan yang dipasang di kepala akan tiba di pelayan. Oleh itu, adalah sukar untuk mengawal masa untuk mengundi tidur dengan menggunakan pemasa. Adalah wajar bahawa penyelesaian boleh juga digunakan pada trafik di mana masa ketibaan paket tidak dapat diramalkan. Oleh itu, dalam kertas ini, kami cuba mencari cara untuk membangunkan benang pengundian tidur dengan cepat selepas satu paket tiba, seperti yang kita bincangkan dalam Sekt. 4. Di samping itu, hanya meletakkan benang pengundian untuk tidur hanya akan mempunyai kesan penjimatan kuasa yang terhad. Walaupun rangkaian pengundian berhenti sibuk mengundi dan memanggil CPU berhenti seketika arahan, teras CPU terus membaca dan melaksanakan arahan daripada pembilang program dan mendaftarkan arahan seterusnya untuk mengelakkan pelanggaran pesanan memori daripada berlaku. Ini bermakna bekalan kuasa kepada teras CPU tidak akan berhenti dan teras CPU terus beroperasi dan menggunakan kitaran CPU. Memandangkan lebih sedikit kitaran CPU digunakan oleh arahan jeda berbanding pengundian yang sibuk, penggunaan kuasa teras CPU boleh dikurangkan dengan menghentikan pengundian yang sibuk. Walau bagaimanapun, kesan penjimatan kuasa adalah terhad kerana teras CPU tidak berhenti beroperasi. Sebagai kaedah untuk meningkatkan kesan penjimatan kuasa, teknologi pengurusan kuasa, penskalaan voltan dinamik dan frekuensi (DVFS) dan melahu kuasa rendah (LPI), dilaksanakan dalam CPU. DVFS secara dinamik mengawal voltan bekalan kuasa dan kekerapan operasi teras CPU sebagai tindak balas kepada perubahan dalam beban dan suhu. LPI mengawal keadaan tidur teras CPU apabila teras tidak aktif dan sering dipanggil keadaan C. LPI membolehkan beberapa litar dalam teras dimatikan semasa tiada beban CPU. DVFS dan LPI dilaksanakan dan digunakan dalam hampir semua CPU moden. Memandangkan kebanyakan fungsi ini termasuk LPI dikendalikan oleh kawalan perkakasan CPU, kesan penjimatan kuasa ini boleh diperolehi dengan hanya mengurangkan beban CPU dengan meletakkan benang pengundian untuk tidur. Apabila urutan pengundian tidur dan beban CPU menurun, CPU secara autonomi memperdalam keadaan tidur teras CPU oleh LPI di bawah kawalan perkakasan. Walau bagaimanapun, fungsi ini boleh menyebabkan kelewatan pemprosesan apabila pulih daripada keadaan terbiar, meningkatkan kependaman rangkaian. Memandangkan LPI boleh didayakan/dilumpuhkan dengan menghidupkan/MATI keadaan C, dalam penilaian prestasi dalam Bahagian. 5, kami menggunakan pemproses Intel Xeon untuk menilai kesan penjimatan kuasa dan kependaman rangkaian dengan mengawal urutan pengundian untuk tidur bagi setiap kes keadaan C HIDUP/MATI. Selain itu, frekuensi operasi CPU boleh dikawal dengan menggunakan gabenor frekuensi CPU [26] daripada kernel. Jika frekuensi operasi CPU boleh dikawal mengikut masa ketibaan paket serta kawalan tidur bagi benang pengundian, kesan penjimatan kuasa selanjutnya boleh dijangkakan. Oleh itu, kami cuba mengawal kekerapan operasi CPU dengan kawalan tidur bagi benang pengundian, seperti yang kita bincangkan dalam Sekt. 4.
4. Seni Bina KBP Cekap Tenaga
Kami mereka bentuk dan melaksanakan sistem rangkaian kependaman rendah dan cekap tenaga, KBP cekap tenaga (EE-KBP), yang memenuhi semua keperluan: (A) kependaman rendah dalam susunan μs untuk pemajuan paket dalam pelayan maya, (B ) penggunaan kuasa yang lebih rendah daripada penyelesaian sedia ada, (C) tidak memerlukan pengubahsuaian aplikasi, dan (D) tidak memerlukan pembangunan semula perisian untuk setiap kemas kini keselamatan kernel. Memandangkan KBP ialah sistem rangkaian kependaman rendah yang boleh memenuhi keperluan (A), (C) dan (D), kami menggunakan KBP sebagai sistem asas dan cuba mengurangkan penggunaan kuasa untuk memenuhi keperluan (B). Seperti yang dibincangkan dalam Mazhab. 3, benang pengundian KBP mempunyai penggunaan kuasa yang lebih tinggi kerana pengundian sibuk dilakukan tanpa mengira sama ada paket tiba atau tidak. Oleh itu, idea asas untuk penjimatan kuasa adalah untuk meletakkan benang pengundian untuk tidur sementara tiada paket tiba. Rajah 3 menunjukkan seni bina peringkat tinggi EE-KBP. Untuk mengurangkan penggunaan kuasa utas undian, EE-KBP mempunyai fungsi kawalan tidur untuk utas EE-KBP dan fungsi kawalan frekuensi CPU untuk teras CPU yang digunakan oleh utas undian. EE-KBP mempunyai empat mata novel. Yang pertama ialah EE-KBP membangkitkan utas pengundian dan menyambung semula pengundian dengan pantas dengan menggunakan konteks hardIRQ apabila paket tiba semasa utas pengundian sedang tidur untuk tidak menjejaskan kependaman rendah (lihat Bahagian 4.1). Yang kedua ialah EE-KBP mengawal frekuensi operasi CPU secara dinamik daripada kernel untuk meningkatkan kesan penjimatan kuasa benang pengundian tidur (lihat Bahagian 4.2). Yang ketiga ialah EE-KBP mempunyai logik kawalan konflik untuk melaksanakan fungsi ini dalam kernel kerana kernel mempunyai sekatan bahawa berbilang proses softIRQ tidak boleh dilaksanakan serentak pada teras CPU yang sama (lihat Bahagian 4.1). Keempat ialah fungsi ini boleh digunakan pada kernel sedia ada oleh kernel livepatch kerana perubahan pada kernel sedia ada ini telah dibuat sekecil mungkin (lihat Bahagian 4.3).
EE-KBP ini boleh digunakan pada kernel hos untuk pelayan bare-metal. Selain itu, EE-KBP boleh digunakan pada kernel hos dan kernel tetamu untuk konfigurasi VM seperti yang ditunjukkan dalam Rajah 4 dan kepada kernel hos untuk konfigurasi kontena seperti ditunjukkan dalam Rajah 5. Oleh kerana kernel tetamu dalam konfigurasi VM boleh menyebabkan kekurangan masa CPU sebanyak ksoftirqd disebabkan overhed emulasi VM, yang boleh menyebabkan kependaman skala ms, EE-KBP kepada kernel tetamu sangat berkesan dalam mengurangkan kependaman. Menurut kerja kami sebelum ini [10], kerana kernel hos konfigurasi kontena dalam Kubernetes [27] kelompok juga boleh menyebabkan kekurangan masa CPU ksoftirqd disebabkan oleh a Kubernetes penjadual dan benang berkaitan lain, yang boleh menyebabkan kependaman skala ms, EE-KBP kepada inti hos berkesan dalam mengurangkan kependaman.
Untuk mencapai kependaman rendah menggunakan EE-KBP, utas EE-KBP harus mempunyai teras CPU khusus dan tiada proses lain harus wujud bersama pada teras CPU tempat utas EE-KBP berjalan. Memandangkan CPU moden mempunyai banyak teras CPU, had ini bukanlah kelemahan utama, tetapi EE-KBP dijangka sukar digunakan pada komputer papan tunggal dengan bilangan teras CPU yang kecil, seperti Raspberry Pi.
4.1 Algoritma Hibrid Tinjauan Tidur dan Sibuk
Jika sibuk mengundi oleh benang mengundi boleh tidur sementara tiada paket tiba, peningkatan penggunaan kuasa oleh benang mengundi boleh diturunkan. Walau bagaimanapun, overhed benang pengundian tidur boleh meningkatkan masa kelewatan penerimaan paket. Kami cuba mengawal urutan pengundian untuk tidur tanpa menjejaskan kependaman rendah sebanyak mungkin. Pertama, kita perlu mereka bentuk bila hendak meletakkan benang pengundian untuk tidur dan bila hendak membangunkannya. Rajah 6 menunjukkan model trafik yang dipermudahkan yang menerangkan masa di mana paket tiba. Sebaik-baiknya, benang pengundian harus dibangkitkan apabila paket tiba dan tidur apabila paket berhenti tiba. Walau bagaimanapun, seperti yang dibincangkan dalam Sek. 3, memandangkan masa ketibaan paket selalunya tidak dapat diramalkan untuk aplikasi masa nyata, adalah sukar untuk meramalkan masa ketibaan paket dan membangkitkan benang pengundian terlebih dahulu dengan pemasa. Di samping itu, apabila paket tiba berturut-turut, adalah sukar untuk meramalkan bila ketibaan paket akan berhenti, jadi sukar juga untuk meramalkan bila untuk tidur benang pengundian. Untuk kaedah membangkitkan utas pengundian, EE-KBP membangunkan utas pengundian secepat mungkin selepas paket tiba di NIC. HardIRQ mempunyai keutamaan yang sangat tinggi, dan apabila hardIRQ dicetuskan, proses yang berjalan pada teras CPU mesti menggantung dan menyerahkan masa CPU kepada hardIRQ. Apabila NIC menerima paket, NIC memberitahu kernel bahawa paket telah tiba dengan menghasilkan hardIRQ. Oleh itu, menggunakan konteks hardIRQ ini membolehkan urutan pengundian dibangkitkan dengan cepat. Mengenai bila hendak meletakkan benang pengundian untuk tidur, poll_list boleh digunakan untuk menilai sama ada tidur atau tidak. Apabila NIC menerima paket, NIC mendaftarkan peranti rangkaiannya kepada a poll_list dan kernel boleh mengenali sama ada terdapat paket untuk diterima atau tidak dengan menyemak poll_list. Selagi peranti rangkaian didaftarkan dalam poll_list, ini bermakna bahawa paket yang tidak diproses sedang ditimbal, jadi benang pengundian harus meneruskan pengundian. Apabila peranti rangkaian tidak wujud dalam poll_list, ini bermakna tiada paket untuk diproses oleh benang mengundi, jadi benang mengundi boleh menghentikan pengundian dan tidur. Oleh itu, apabila peranti rangkaian tidak didaftarkan dalam a poll_list, urutan EE-KBP menghentikan pengundian dan tidur.
Algoritma 1 menunjukkan algoritma hibrid tidur dan tinjauan sibuk untuk EE-KBP. Untuk melumpuhkan softIRQ bagi rangkaian NAPI bagi mengelakkan persaingan softIRQ, yang menyebabkan kelewatan, EE-KBP mengalih keluar fungsi menaikkan softIRQ daripada NET_RX_SOFTIRQ in netif_rx. Sebaliknya, EE-KBP menambah fungsi untuk membangunkan utas EE-KBP dalam konteks hardIRQ untuk rangkaian dalam netif_rx. Benang EE-KBP ialah benang kernel yang menjalankan tinjauan sibuk untuk menerima paket dan tidur apabila tiada peranti rangkaian berdaftar dalam poll_list. Dengan menggabungkan diubah suai netif_rx dan utas EE-KBP, utas EE-KBP melakukan pengundian yang sibuk untuk menerima paket dengan kependaman rendah semasa terdapat paket yang tidak diterima, utas EE-KBP tidur apabila poll_list menjadi kosong untuk mengurangkan penggunaan kuasa, dan apabila paket tiba semasa utas EE-KBP sedang tidur, pengendali hardIRQ ketibaan paket membangunkan utas EE-KBP untuk menyambung pengundian yang sibuk dengan cepat. Q (kuota) ialah nilai bilangan paket yang akan diterima dalam satu undian, dan nilai lalai NAPI kernel sedia ada ialah 64. Nilai ini digunakan dalam penilaian prestasi seperti yang akan dibincangkan dalam Bahagian. 5.
Terdapat sekatan bahawa berbilang proses softIRQ tidak boleh dilaksanakan serentak pada teras CPU yang sama. Dalam NAPI kernel sedia ada, proses protokol rangkaian diproses dalam konteks softIRQ. Memandangkan EE-KBP menggunakan susunan protokol rangkaian sedia ada dalam kernel untuk memenuhi keperluan (C) dan (D), EE-KBP tidak membuat sebarang perubahan pada fungsi selepas netif_receive_skb. Oleh itu, kita perlu mempertimbangkan sekatan ini apabila benang EE-KBP menarik satu paket dan meneruskan pemprosesan protokol rangkaian. Untuk mengawal sekatan melarang pelaksanaan berbilang softIRQ ini, EE-KBP mempunyai logik kawalan konflik. Selepas benang EE-KBP menarik satu paket, benang EE-KBP melarang softIRQ lain dan meneruskan pemprosesan protokol rangkaian seterusnya. Selepas pemprosesan protokol selesai, EE-KBP mengeluarkan larangan ini.
4.2 Ciri Kawalan Frekuensi CPU
Untuk mengurangkan lagi penggunaan kuasa teras CPU semasa benang EE-KBP sedang tidur, EE-KBP mengawal frekuensi operasi CPU teras CPU secara dinamik. Seperti yang dibincangkan dalam Mazhab. 3, walaupun benang pengundian berhenti sibuk mengundi dan tidur, teras CPU terus membaca dan melaksanakan arahan daripada pembilang program, dan mendaftarkan arahan seterusnya untuk mengelakkan pelanggaran pesanan memori. Ini bermakna teras CPU terus menggunakan kuasa semasa benang pengundian sedang tidur. Memandangkan kekerapan operasi teras CPU boleh ditukar secara dinamik daripada kernel, ia dijangka dapat mengurangkan pembaziran kuasa teras CPU ini dengan menurunkan kekerapan operasi CPU semasa benang pengundian sedang tidur. EE-KBP mempunyai fungsi kawalan frekuensi CPU dan menetapkan frekuensi operasi CPU teras CPU rendah apabila benang EE-KBP tidur dan memulihkan frekuensi operasi CPU apabila ia bangun daripada tidur, seperti yang ditunjukkan dalam algoritma 1. EE -KBP menggunakan gabenor frekuensi CPU untuk menukar frekuensi operasi CPU. Terdapat pelbagai jenis dasar gabenor, seperti "prestasi," "jimat kuasa," "ruang pengguna" dan "ondemand". Kami menggunakan "ruang pengguna" gabenor frekuensi CPU kerana ia membolehkan kekerapan tertentu ditetapkan untuk teras CPU. Dengan menggunakan "ruang pengguna" gabenor frekuensi CPU, utas EE-KBP menetapkan kekerapan CPU maksimum pada masa yang dicetuskan oleh hardIRQ rangkaian dan menetapkan kekerapan CPU minimum sebelum utas EE-KBP tertidur. Jeda masa antara menukar frekuensi operasi CPU dan perubahan yang dicerminkan kepada teras CPU perlu singkat, mengikut urutan μs, tetapi kami telah menentukan bahawa ia cukup singkat berdasarkan keputusan penilaian prestasi seperti yang akan dibincangkan dalam Sekt. 5.
Bagi fungsi penjimatan kuasa oleh kawalan perkakasan yang dimiliki oleh banyak CPU, seperti DVFS dan LPI (C-state), operasinya tidak boleh dikawal daripada kernel, tetapi fungsi ini boleh diaktifkan dengan hanya meletakkan benang pengundian untuk tidur, seperti yang dibincangkan dalam Mazhab. 3. Oleh itu, EE-KBP tidak mempunyai ciri untuk mengawal fungsi perkakasan CPU ini, tetapi EE-KBP mengubah kadar penggunaan teras CPU dengan mengawal keadaan tidur benang pengundian, yang secara tidak langsung meningkatkan keberkesanan kuasa ini -fungsi penjimatan. Kesan fungsi-fungsi ini dan masa tunda yang lama disebabkan oleh overhed akan dibincangkan dalam penilaian prestasi dalam Sek. 5.
4.3 Memohon oleh Kernel Livepatch
Ciri EE-KBP boleh didayakan dengan membuat beberapa perubahan daripada NAPI kernel sedia ada. Seperti yang ditunjukkan dalam algoritma 1, EE-KBP hanya mengalih keluar fungsi menaikkan softIRQ daripada NET_RX_SOFTIRQ dan menambah fungsi membangkitkan benang EE-KBP masuk netif_rx daripada NAPI. Benang EE-KBP dikejutkan oleh netif_rx, dan selepas menarik paket, ia meneruskan proses ke netif_receive_skb. Oleh itu, melainkan sama ada netif_rx or netif_receive_skb diubah, EE-KBP boleh dijalankan pada mana-mana versi kernel selepas versi 2.4.20, apabila NAPI dilaksanakan. Kernel mempunyai mekanisme yang dipanggil kernel livepatch, yang digunakan untuk menggunakan patch keselamatan pada kernel atau mengubah beberapa tingkah laku kernel. Memandangkan EE-KBP memerlukan sedikit perubahan daripada NAPI, EE-KBP boleh digunakan oleh kernel livepatch. Jika kemas kini keselamatan berlaku pada kernel, EE-KBP boleh didayakan dengan hanya menggunakan kernel livepatch pada versi kernel baharu sekali lagi. Oleh itu, melainkan sama ada netif_rx or netif_receive_skb diubah, pembekal perkhidmatan tidak perlu mengubah suai perisian patch langsung kernel. Selain itu, memandangkan kernel livepatch boleh digunakan tanpa but semula sistem, pembekal perkhidmatan boleh menggunakan EE-KBP tanpa gangguan perkhidmatan.
4.4 Skala Keluar
Jika jumlah trafik masuk terlalu besar untuk dikendalikan oleh satu utas EE-KBP, berbilang utas EE-KBP boleh digunakan dalam kernel. Hampir semua NIC moden mempunyai ciri penskalaan sisi terima (RSS) dan menggunakan berbilang teras CPU untuk penerimaan paket. Apabila NIC menerima paket, ia memilih teras CPU yang mana untuk menggunakan hardIRQ. Penskalaan boleh diperolehi dengan melancarkan benang EE-KBP pada berbilang teras CPU dan memautkan teras CPU tersebut kepada teras CPU yang hardIRQ dihasilkan oleh RSS.
5. Penilaian Prestasi
Untuk menilai kesan penjimatan kuasa dan kependaman rendah EE-KBP, kami menjalankan penilaian prestasi membandingkan EE-KBP dengan NAPI sedia ada dan KBP yang diterima pakai sebagai mesin asas EE-KBP. Kami mengukur penggunaan kuasa, kependaman pemajuan paket dan daya pemprosesan apabila beban trafik ditambahkan pada penyelesaian sasaran. Seperti yang dibincangkan dalam Mazhab. 4, EE-KBP boleh digunakan ke kernel hos untuk pelayan bare-metal, ke kernel hos dan kernel tetamu untuk konfigurasi VM, dan ke kernel hos untuk konfigurasi kontena. Dalam konfigurasi VM, hos dan tetamu masing-masing mempunyai urutan pengundian dan memandangkan bilangan rangkaian pengundian yang akan diisi oleh EE-KBP adalah lebih besar daripada dalam pelayan logam kosong atau konfigurasi kontena, kesan penjimatan kuasa boleh sebahagian besarnya diukur. Selain itu, dalam konfigurasi VM, memandangkan kelewatan pemajuan paket berkemungkinan lama disebabkan oleh overhed emulasi untuk mencipta VM, kesan kependaman rendah dengan EE-KBP boleh diukur sebahagian besarnya. Atas sebab ini, kami menggunakan konfigurasi VM untuk penilaian prestasi. Untuk menilai kesan ciri kawalan tidur EE-KBP dengan ciri penjimatan kuasa dikawal perkakasan CPU, kami menilai setiap kes apabila keadaan C didayakan dan dilumpuhkan. Selain itu, untuk menilai kesan ciri kawalan frekuensi CPU EE-KBP, kami menilai sama ada setiap kes apabila ciri kawalan frekuensi CPU didayakan dan dilumpuhkan. Oleh itu, kami menjalankan penilaian perbandingan penyelesaian dan tetapan untuk (a) NAPI, (b) KBP, (c) EE-KBP apabila keadaan-C dilumpuhkan dan ciri kawalan frekuensi CPU dilumpuhkan, (d) EE-KBP dengan Keadaan-C telah dilumpuhkan dan ciri kawalan frekuensi CPU telah didayakan, (e) E-KBP apabila keadaan-C didayakan dan ciri kawalan frekuensi CPU telah dilumpuhkan, dan (f) EE-KBP apabila keadaan-C didayakan dan ciri kawalan frekuensi CPU telah didayakan.
Jadual 1 menunjukkan spesifikasi platform eksperimen. Untuk kependaman rendah, teras CPU yang digunakan untuk pemprosesan paket telah ditetapkan kepada gabenor berprestasi tinggi, dan benang emulasi CPU maya mesin maya berasaskan kernel (KVM) dan vhost-net telah diperuntukkan teras CPU khusus dan diasingkan daripada proses lain yang menggunakan isolcpus. Untuk penjimatan kuasa, keadaan C telah didayakan untuk (a) NAPI dan (b) KBP. Untuk ciri kawalan frekuensi CPU EE-KBP dalam (d) dan (f), gabenor "ruang pengguna" telah digunakan dan kekerapan maksimum yang boleh ditetapkan untuk pemproses Intel Xeon yang digunakan ialah 2.8 GHz, dan frekuensi minimum ialah 1.2 GHz.
Kami menambah beban trafik pergi balik seperti yang ditunjukkan dalam Rajah 7. Memandangkan protokol kawalan penghantaran (TCP) mempunyai kawalan penghantaran semula dan kawalan kesesakan, dan kesan ciri kawalan tidur EE-KBP adalah sukar untuk dinilai, kami menggunakan UDP lalu lintas. Untuk menilai kesan penjimatan kuasa dan peningkatan masa kelewatan disebabkan oleh overhed bangun dari tidur EE-KBP dengan mengubah masa apabila benang mengundi sedang tidur, enam keadaan trafik dengan kadar trafik dan saiz bingkai yang berbeza telah digunakan sebagai ditunjukkan dalam Jadual 2. Dalam keadaan trafik ini, satu paket tiba pada selang ketibaan paket yang diterangkan dalam Jadual 2. Apabila paket tiba, benang pengundian dikejutkan oleh hardIRQ ketibaan paket dan serta-merta tidur selepas itu, dan ini proses diulang seperti yang ditunjukkan dalam Rajah 6. Tidak mungkin untuk menarik paket secara berterusan dengan tinjauan yang sibuk. Keadaan trafik ini merugikan EE-KBP. Walau bagaimanapun, ini adalah keadaan trafik yang sesuai untuk menilai overhed yang disebabkan oleh tidur urutan pengundian EE-KBP. 80 Mbps ialah kadar trafik di mana tiada kehilangan paket berlaku dalam mana-mana penyelesaian yang dibandingkan.
5.1 Penggunaan Kuasa
Terdapat tiga kaedah untuk mengukur penggunaan kuasa pelayan. Yang pertama adalah untuk mengukur penggunaan kuasa keseluruhan pelayan secara fizikal dengan memasukkan meter kuasa ke dalam talian bekalan kuasa pelayan. Kaedah ini tidak bergantung pada ketepatan penderia pelayan dan boleh mengukur penggunaan kuasa dengan ketepatan yang tinggi. Walau bagaimanapun, ia memerlukan kerja di tapak untuk memasang meter kuasa dan menyemak nilai pengukuran meter kuasa. Memandangkan sukar untuk melakukan kerja di tapak untuk masa yang lama kali ini, kami menggunakan kaedah ini hanya untuk menyemak ketepatan pengukuran kaedah yang diterangkan di bawah. Yang kedua ialah menggunakan antara muka had kuasa purata (RAPL) berjalan Intel. CPU Intel menyediakan antara muka RAPL yang membolehkan maklumat penggunaan kuasa diperolehi. Dilaporkan bahawa RAPL menyediakan data penggunaan kuasa ketepatan tinggi CPU [28] dan memori akses rawak dinamik (DRAM). Walau bagaimanapun, penggunaan kuasa keseluruhan pelayan tidak boleh diukur dengan menggunakan antara muka RAPL. Memandangkan prestasi dan penggunaan kuasa teras CPU berkait rapat dengan kelajuan kipas penyejuk casis pelayan, adalah perlu untuk menilai penggunaan kuasa keseluruhan pelayan yang termasuk penggunaan kuasa kipas penyejuk. Yang ketiga ialah menggunakan antara muka pengurusan platform pintar (IPMI). IPMI membolehkan pelayan dikawal dan dipantau dari jauh. Dengan menggunakan IPMI ini, kita boleh mengukur penggunaan kuasa keseluruhan pelayan. Walau bagaimanapun, dilaporkan bahawa ketepatan pengukuran penggunaan kuasa menggunakan IPMI adalah rendah dalam beberapa kes, bergantung pada ketepatan penderia onboard pelayan [29]. Oleh itu, kami membandingkan hasil pengukuran kuasa antara menggunakan IPMI dan meter kuasa untuk mengesahkan ketepatan penderia onboard pada pelayan (Dell PowerEdge R730). Hasil pengukuran oleh IPMI adalah 0.29% lebih kecil daripada hasil pengukuran oleh meter kuasa dan perbezaan antara keduanya adalah stabil, jadi kami membuat kesimpulan bahawa ketepatan pengukuran kuasa IPMI untuk pelayan ini adalah cukup tinggi. Kami mengukur penggunaan kuasa setiap penyelesaian dan tetapan apabila trafik dengan keadaan yang diterangkan dalam Jadual 2 ditambah. Untuk menambah keadaan trafik ini, kami menggunakan Pusat Ujian Spirent SPT-N4U (STC) sebagai penguji prestasi. Kami menambah beban trafik dan mengukur penggunaan kuasa selama 60 saat dan mengulangi pengukuran 5 kali.
Rajah 8 menunjukkan keputusan ukuran penggunaan kuasa bagi setiap penyelesaian dan tetapan dari semasa ke semasa. Kami mula menggunakan trafik 10 saat selepas kami memulakan ujian, dan kemudian terus menggunakan trafik selama 60 saat. Mula-mula, kami menganalisis peningkatan dalam penggunaan kuasa kerana sibuk mengundi benang pengundian dengan membandingkan keputusan (a) NAPI dan (b) KBP. Membandingkan keputusan penggunaan kuasa tanpa trafik digunakan, (a) NAPI ialah 170 watt (W) dan (2) KBP ialah 181 W, perbezaan 11 W. Dalam konfigurasi VM dengan KBP, terdapat benang pengundian pada setiap daripada hos dan tetamu, yang bermaksud bahawa penggunaan kuasa tambahan bagi pengundian sibuk oleh dua utas pengundian ialah 11 W. Oleh itu, penggunaan kuasa disebabkan oleh pengundian sibuk yang tidak berguna apabila tiada paket yang datang membazir 5.5 W setiap utas pengundian. Bagi analisis kesan EE-KBP untuk meletakkan benang pengundian untuk tidur, penggunaan kuasa (e) dan (f) dengan keadaan C didayakan ialah 170 W manakala tiada trafik ditambah, yang sama seperti ( a) NAPI. Keputusan ini bermakna bahawa EE-KBP boleh mengurangkan penggunaan kuasa ke tahap yang sama seperti NAPI sementara tiada paket tiba dengan meletakkan benang pengundian untuk tidur. Sebaliknya, keputusan (c) dan (d), yang merupakan keputusan apabila keadaan-C dilumpuhkan, menunjukkan penggunaan kuasa meningkat lebih kira-kira 25 W walaupun semasa tiada trafik ditambah. Memandangkan keadaan C tidak boleh diubah untuk setiap teras CPU, untuk keseluruhan CPU, fungsi penjimatan kuasa dikawal perkakasan bagi semua 14 teras CPU telah dilumpuhkan, mengakibatkan peningkatan penggunaan kuasa yang begitu besar. Jika pembekal perkhidmatan memerlukan penjimatan kuasa, adalah wajar untuk menetapkan keadaan C kepada didayakan.
Seterusnya, kami menganalisis kesan penjimatan kuasa EE-KBP semasa trafik ditambah. Rajah 9 dan 10 mengklasifikasikan keputusan penggunaan kuasa untuk setiap penyelesaian dan tetapan mengikut saiz bingkai dan kadar trafik. Rajah 9 dan 10 menunjukkan keputusan dengan beban trafik 80 Mbps dan 1 Gbps, masing-masing. Membandingkan keputusan (b) KBP dan (e) EE-KBP tanpa kawalan frekuensi CPU, EE-KBP mengurangkan penggunaan kuasa sebanyak 3 W dalam semua keadaan trafik berbanding dengan KBP dengan meletakkan benang pengundian untuk tidur. Keputusan (e) EE-KBP ini hampir sama dengan keputusan (a) NAPI. Ini bermakna EE-KBP menyelesaikan masalah penggunaan kuasa yang meningkat disebabkan oleh kesibukan mengundi benang pengundian di KBP. Tambahan pula, membandingkan keputusan (b) KBP dan (f) EE-KBP dengan kawalan frekuensi CPU, EE-KBP dengan kawalan frekuensi CPU menggunakan kuasa 5 hingga 7 W kurang daripada KBP, kecuali untuk 1-Gbps 64- keadaan trafik bait. Fungsi kawalan frekuensi CPU EE-KBP mengurangkan penggunaan kuasa dengan tambahan 2 hingga 4 W berbanding dengan keputusan dalam (e) EE-KBP tanpa kawalan frekuensi CPU. Dengan mengawal frekuensi CPU serta meletakkan benang pengundian kepada tidur, EE-KBP boleh mengurangkan lagi penggunaan kuasa lebih daripada NAPI. Dalam keadaan trafik 1-Gbps 64-bait, EE-KBP dengan kawalan frekuensi CPU tidak dapat mengurangkan lagi penggunaan kuasa lebih daripada EE-KBP tanpa kawalan frekuensi CPU. Dalam keadaan trafik 1-Gbps 64-bait, selang ketibaan paket ialah 0.5 μs, yang agak pendek. Adalah dipercayai bahawa menukar frekuensi operasi CPU oleh EE-KBP tidak dicerminkan dalam masa semasa selang pendek ini. Dalam keadaan trafik 1-Gbps 512-bait, memandangkan EE-KBP dengan kawalan frekuensi CPU boleh mengurangkan lagi penggunaan kuasa lebih daripada EE-KBP tanpa kawalan frekuensi CPU, ia menunjukkan bahawa frekuensi operasi CPU boleh ditukar mengikut susunan μs dengan fungsi EE-KBP. Keputusan ini adalah dalam konfigurasi VM di mana terdapat dua urutan pengundian, yang berada dalam hos dan tetamu. Apabila menyediakan perkhidmatan masa nyata, sejumlah besar pengguna dijangka akan ditempatkan dalam pelayan, dan bilangan urutan pengundian juga dijangka meningkat, jadi kesan penjimatan kuasa EE-KBP meningkat dengan setiap rangkaian pengundian tambahan berbanding dengan KBP sedia ada. Selain itu, dalam trafik ujian ini, paket tiba secara berterusan dan masa tidur adalah singkat, jadi kesan penjimatan kuasa EE-KBP adalah terhad. Jika trafik mempunyai masa tidur yang lama, seperti paket terputus-putus masuk, kesan penjimatan kuasa EE-KBP akan menjadi lebih tinggi.
5.2 Latensi
Untuk menilai peningkatan kependaman pemajuan paket dalam EE-KBP disebabkan oleh kawalan tidur dan kawalan frekuensi CPU, kami mengukur kependaman perjalanan pergi balik maksimum bagi setiap penyelesaian dan tetapan apabila trafik dengan keadaan yang diterangkan dalam Jadual 2 ditambah. Untuk menambah keadaan trafik ini dan mengukur kependaman, kami menggunakan STC sebagai penguji prestasi. Kami menambah beban trafik dan mengukur kependaman selama 60 saat dan mengulangi pengukuran 5 kali.
Rajah 11 dan 12 menunjukkan ukuran kependaman dengan beban trafik 80 Mbps dan 1 Gbps, masing-masing. Membandingkan keputusan (b) KBP dan (e) EE-KBP tanpa kawalan frekuensi CPU, walaupun kependaman perjalanan pergi balik maksimum meningkat sehingga 87 μs berbanding dengan KBP, EE-KBP mencapai kependaman rendah dalam susunan μs . Untuk trafik 1-Gbps, peningkatan dalam masa tunda EE-KBP berbanding dengan KBP adalah kecil dan untuk trafik 80-Mbps, peningkatan dalam masa tunda cenderung lebih besar. Memandangkan trafik 80-Mbps mempunyai selang paket yang lebih panjang dan benang pengundian boleh tidur untuk tempoh masa yang lebih lama, diandaikan bahawa benang pengundian memerlukan masa yang lebih lama untuk pulih kerana tidur dalam oleh ciri penjimatan kuasa perkakasan CPU. Walaupun kependaman meningkat sedikit disebabkan oleh overhed meletakkan utas pengundian untuk tidur, EE-KBP tanpa kawalan frekuensi CPU boleh mencapai penjimatan kuasa tanpa menjejaskan kependaman rendah. Dengan keadaan trafik 1-Gbps 64-bait, semua penyelesaian dan tetapan mengalami kelewatan skala ms dan kehilangan paket. Ini disebabkan oleh had prestasi pemprosesan susunan protokol kernel dalam tetamu, yang merupakan had prestasi seni bina KBP tanpa sebarang perubahan pada susunan protokol kernel, seperti yang dibincangkan dalam kerja kami sebelum ini [10].
Seterusnya, kami menganalisis overhed yang disebabkan oleh fungsi kawalan frekuensi CPU EE-KBP. Membandingkan keputusan (e) EE-KBP tanpa kawalan frekuensi CPU dan (f) EE-KBP dengan kawalan frekuensi CPU, (f) EE-KBP dengan kawalan frekuensi CPU mencapai kependaman rendah dalam susunan μs kecuali 64 bingkai -bait pada 80-Mbps dan pada 1-Gbps, walaupun kependaman perjalanan pergi balik maksimum telah meningkat sehingga 260 μs berbanding dengan (e) EE-KBP tanpa kawalan frekuensi CPU. (f) EE-KBP dengan kawalan frekuensi CPU mengalami kelewatan skala ms dengan bingkai 64-bait pada kadar trafik 80-Mbps. Walaupun selang ketibaan paket adalah lebih pendek untuk bingkai 512-bait pada 1-Gbps berbanding untuk bingkai 64-bait pada 80-Mbps, kelewatan skala ms berlaku untuk bingkai 64-bait pada 80-Mbps. Kelewatan ini berkait rapat dengan bilangan masa hardIRQ yang dicetuskan oleh NIC. Rajah 13 menunjukkan bilangan hardIRQ apabila trafik dengan setiap keadaan yang diterangkan dalam Jadual 2 ditambah selama 60 saat. Bilangan hardIRQ dalam bingkai 64-bait pada kadar trafik 80-Mbps adalah yang tertinggi. Jika bilangan hardIRQ ketibaan paket adalah besar, proses penerimaan paket mesti terganggu pada setiap hardIRQ, data yang sedang diproses mesti disimpan dalam ruang memori, dan masa CPU mesti diberikan kepada hardIRQ, mengakibatkan overhed yang besar. . Ini menyebabkan kekurangan masa CPU untuk fungsi menerima paket yang berjalan pada teras CPU tempat benang EE-KBP beroperasi, dan oleh kerana fungsi kawalan frekuensi CPU juga dicuba pada teras CPU yang sama, masa CPU dipendekkan lagi , mengakibatkan kelewatan penghantaran paket skala ms. Seperti yang dibincangkan dalam Mazhab. 4.1, apabila tiada lagi data paket yang akan diterima dalam a poll_list, benang EE-KBP membenarkan hardIRQ dan tidur. Jika kekerapan ketibaan paket agak jarang, hardIRQ akan dicetuskan setiap kali paket tiba, jadi bilangan hardIRQ akan menjadi tinggi. Jika kekerapan ketibaan paket lebih tinggi daripada kelajuan paket menerima dan memproses oleh susunan protokol kernel, paket berikutnya akan disimpan dalam penimbal cincin dan NET_DEV akan kekal dalam poll_list, jadi masa yang hardIRQ dilarang dan benang meneruskan pengundian akan menjadi lebih lama. Apabila berbilang paket disimpan dalam penimbal cincin, benang EE-KBP menerima Q paket sekali gus untuk menyusunnya, jadi penimbal cincin akan kosong semula. EE-KBP dengan C-state telah dilumpuhkan mencapai kependaman pergi balik maksimum yang lebih kecil daripada EE-KBP dengan C-state telah didayakan dengan membandingkan keputusan (c), (d), (e), dan (f). Walau bagaimanapun, sejak melumpuhkan keadaan C menyebabkan peningkatan ketara dalam penggunaan kuasa seperti yang dibincangkan dalam Sek. 5.1, kes penggunaan melumpuhkan keadaan C dianggap jarang berlaku.
EE-KBP tanpa kawalan frekuensi CPU mencapai kependaman rendah dalam susunan μs dengan penurunan kependaman yang kecil berbanding dengan KBP dan tahap kesan penjimatan kuasa yang sama seperti NAPI yang digunakan dalam kernel sedia ada dengan mengatasi masalah KBP, iaitu peningkatan penggunaan kuasa dengan sibuk mengundi berterusan. Dengan mendayakan fungsi kawalan frekuensi CPU EE-KBP, EE-KBP mengurangkan lagi penggunaan kuasa ke tahap yang lebih rendah daripada NAPI dan mencapai kependaman rendah dalam susunan μs di bawah banyak keadaan trafik. Walau bagaimanapun, dalam kes keadaan trafik di mana EE-KBP menggunakan banyak hardIRQ untuk rangkaian, mengukur kependaman pergi balik maksimum EE-KBP dengan kawalan frekuensi CPU ialah 1.3 ms, kami ambil perhatian bahawa nilai ini lebih kecil daripada NAPI . Walaupun bilangan hardIRQ dalam EE-KBP sukar untuk dianggarkan kerana masa pemprosesan paket oleh susunan protokol kernel berbeza-beza bergantung pada prestasi CPU, panjang paket dan protokol yang digunakan, yang mempengaruhi kelajuan paket ditarik dari penimbal cincin, EE-KBP dengan kawalan frekuensi CPU boleh digunakan untuk perkhidmatan yang mempunyai trafik yang terdiri daripada paket dengan selang ketibaan paket yang panjang atau pendek.
5.3 Kapasiti
Kami menjalankan penilaian ukuran daya tampung untuk mengukur prestasi daya tampung maksimum tanpa kehilangan paket seperti yang dinyatakan dalam RFC2544 [30]. Kami menggunakan Pktgen-DPDK [31] sebagai penjana trafik dan trafik bingkai 64-, 512-, dan 1518-bait telah ditambahkan. Kami berulang kali menambah trafik daripada Pktgen-DPDK dengan meningkatkan kadar trafik secara beransur-ansur, mengukur daya pemprosesan maksimum tanpa kehilangan paket. Kami mengulangi pengukuran lima kali.
Rajah 14 menunjukkan keputusan pengukuran daya pemprosesan. Membandingkan keputusan (b) KBP, (e) EE-KBP tanpa kawalan frekuensi CPU, dan (f) EE-KBP dengan kawalan frekuensi CPU, EE-KBP hanya mempunyai pengurangan daya pengeluaran maksimum sebanyak 4.6% berbanding dengan KBP. Dalam ujian throughput, tidak ada banyak peluang untuk urutan pengundian EE-KBP untuk tidur kerana sejumlah besar paket ujian ditambah, jadi tingkah lakunya hampir sama dengan KBP di mana rangkaian pengundian terus sibuk mengundi. Kemerosotan prestasi daya tampung kepada KBP adalah kecil memandangkan terdapat sedikit peluang untuk overhed disebabkan kawalan tidur pada urutan pengundian oleh EE-KBP. Berbanding dengan NAPI, EE-KBP mencapai peningkatan daya pengeluaran sebanyak 1.4\(\times\) untuk 3.1\(\times\) lebih tinggi. Keputusan (c) dan (d) dengan keadaan C dilumpuhkan menunjukkan daya pemprosesan yang lebih rendah daripada keputusan (e) dan (f) dengan keadaan C didayakan. Ini disebabkan oleh spesifikasi pemproses Intel Xeon yang digunakan, yang mempunyai frekuensi CPU maksimum 2.4 GHz apabila keadaan C dilumpuhkan dan 2.8 GHz apabila keadaan C didayakan.
5.4 Perbincangan
Atas dasar keputusan dalam Mazhab. 5.1 hingga 5.3, kami membincangkan ciri-ciri dan penalaan yang diingini EE-KBP berkenaan dengan prestasi. LPI (C-state) dan kawalan frekuensi CPU adalah ciri bebas, dan keputusan penilaian tidak mendedahkan sebarang sinergi khas antara fungsi ini. Oleh itu, pembekal perkhidmatan yang menggunakan EE-KBP harus mendayakan/melumpuhkan fungsi ini mengikut garis panduan yang diterangkan di bawah. Bagi EE-KBP dengan keadaan C, kesan penjimatan kuasa dengan keadaan C didayakan adalah besar, masa tunda maksimum dengan keadaan C didayakan bertambah buruk hanya beberapa puluh hingga 200 μs, dan daya pemprosesan lebih baik dengan keadaan C didayakan daripada dengan keadaan C dilumpuhkan. EE-KBP dengan keadaan C didayakan adalah lebih baik daripada NAPI dari segi penjimatan kuasa, kependaman rendah dan daya pemprosesan dalam semua keadaan trafik. Berdasarkan keputusan ini, apabila pelayan perlu menjimatkan kuasa, keadaan C harus didayakan tanpa mengira keadaan trafik. Bagi EE-KBP dengan kawalan frekuensi CPU, kesan penjimatan kuasa dan daya pemprosesan adalah lebih tinggi dengan kawalan frekuensi CPU berbanding tanpanya. Walau bagaimanapun, dalam kes trafik dengan selang ketibaan paket di mana banyak hardIRQ dijana dalam EE-KBP, kelewatan pesanan ms berlaku pada keadaan yang sangat jarang berlaku dengan kawalan frekuensi CPU. Untuk kes penggunaan di mana kelewatan pesanan ms yang sangat jarang diterima, kawalan frekuensi CPU harus didayakan, kerana penjimatan kuasa yang lebih tinggi boleh dicapai. Untuk kes penggunaan di mana kelewatan pesanan ms yang sangat jarang berlaku tidak boleh diterima, kawalan frekuensi CPU harus dilumpuhkan.
Memandangkan kelewatan pesanan ms hanya jarang berlaku dengan kawalan frekuensi CPU, pembekal perkhidmatan boleh menyemak sama ada trafik perkhidmatannya memenuhi syarat khusus ini. Walau bagaimanapun, adalah sangat mencabar bagi penyedia perkhidmatan untuk menambah trafik dan mengira bilangan hardIRQ untuk melihat sama ada ia memenuhi syarat tertentu. Di samping itu, bilangan hardIRQ dalam EE-KBP adalah sukar untuk dianggarkan kerana masa pemprosesan paket oleh susunan protokol kernel berbeza-beza bergantung pada prestasi CPU, panjang paket dan protokol yang digunakan, yang mempengaruhi kelajuan paket ditarik dari cincin. penampan. Oleh itu, kami percaya bahawa ciri untuk menyekat bilangan hardIRQ selaras dengan keadaan trafik adalah perlu untuk mengelakkan kelewatan pesanan ms. Ini adalah kerja masa depan kami, seperti yang akan dibincangkan dalam Sek. 6.
6. Kesimpulan dan Kajian Lanjutan
Kami mereka bentuk dan melaksanakan sistem rangkaian kependaman rendah dan cekap tenaga, tinjauan sibuk kernel cekap tenaga (EE-KBP), yang memenuhi empat keperluan: (A) kependaman rendah dalam susunan μs untuk pemajuan paket dalam pelayan maya, (B) penggunaan kuasa yang lebih rendah daripada penyelesaian sedia ada, (C) tidak memerlukan pengubahsuaian aplikasi, dan (D) tidak memerlukan pembangunan semula perisian untuk setiap kemas kini keselamatan kernel. EE-KBP mencapai rangkaian kependaman rendah dengan melakukan pengundian yang sibuk dalam kernel, dan menjimatkan kuasa dengan meletakkan benang undian untuk tidur sementara tiada paket masuk, dan dengan mengawal kekerapan operasi teras CPU untuk benang undian secara dinamik. EE-KBP mengurangkan penggunaan kuasa sebanyak 1.5 W setiap utas undian dalam konfigurasi VM dengan mengawal utas undian untuk tidur, dengan hanya peningkatan 87 μs dalam kependaman berbanding dengan KBP konvensional kami, yang terus sibuk mengundi dalam kernel. EE-KBP mencapai rangkaian kependaman rendah mengikut urutan μs, sambil menggunakan kuasa serendah NAPI yang diterima pakai dalam kernel semasa. Tambahan pula, dengan mengawal kekerapan teras CPU yang digunakan oleh utas pengundian EE-KBP secara dinamik, EE-KBP mengurangkan penggunaan kuasa sebanyak 2.5 hingga 3.5 W setiap utas pengundian berbanding dengan KBP, dan ini adalah penggunaan kuasa yang lebih rendah daripada NAPI. Walau bagaimanapun, disebabkan overhed fungsi kawalan frekuensi CPU, EE-KBP menyebabkan masa tunda pergi balik sehingga 1.3 ms dalam keadaan trafik tertentu, tetapi ia mencapai kependaman yang jauh lebih rendah daripada NAPI. EE-KBP mencapai 1.4\(\times\) untuk 3.1\(\times\) daya tampung yang lebih tinggi daripada NAPI, dan kemerosotan prestasi daripada KBP adalah terhad kepada 4.6% paling banyak.
EE-KBP mencapai rangkaian kependaman rendah dalam susunan μs di bawah kebanyakan keadaan trafik dan penggunaan kuasa yang lebih rendah daripada NAPI, tetapi fungsi kawalan frekuensi CPU dinamik menyebabkan sedikit kelewatan dalam susunan ms untuk beberapa keadaan trafik. Untuk kerja akan datang, kami merancang untuk mengkaji penalaan fungsi kawalan frekuensi CPU dengan kiraan hardIRQ mengikut keadaan trafik. Selain itu, memandangkan kami hanya mengukur keberkesanan EE-KBP dalam konfigurasi VM, kami merancang untuk menilai keberkesanannya dalam konfigurasi logam kosong dan konfigurasi kontena.
Rujukan
[1] S. Harcsik, A. Petlund, C. Griwodz, and P. Halvorsen, “Latency evaluation of networking mechanisms for game traffic,” Proc. 6th ACM SIGCOMM Workshop on Network and System Support for Games - NetGames’07, pp.129–134, 2007.
CrossRef
[2] M.S. Elbamby, C. Perfecto, M. Bennis, and K. Doppler, “Toward low-latency and ultra-reliable virtual reality,” IEEE Network, vol.32, no.2, pp.78–84, 2018.
CrossRef
[3] M.A. Lema, A. Laya, T. Mahmoodi, M. Cuevas, J. Sachs, J. Markendahl, and M. Dohler, “Business case and technology analysis for 5G low latency applications,” IEEE Access, vol.5, pp.5917–5935, 2017.
CrossRef
[4] R. Gupta, D. Reebadiya, and S. Tanwar, “6G-enabled edge intelligence for ultra-reliable low latency applications: Vision and mission,” Comp. Stand. Inter., vol.77, p.103521, 2021.
CrossRef
[5] M. Patel, B. Naughton, C. Chan, N. Sprecher, S. Abeta, and A. Neal, “Mobile edge computing introductory technical white paper,” 2014.
URL
[6] D.B. Oljira, A. Brunstrom, J. Taheri, and K.J. Grinnemo, “Analysis of network latency in virtualized environments,” IEEE Global Communications Conference (GLOBECOM), pp.1–6, 2016.
CrossRef
[7] P. Apparao, S. Makineni, and D. Newell, “Characterization of network processing overheads in Xen,” 2nd International Workshop on Virtualization Technology in Distributed Computing (VTDC), 2006.
CrossRef
[8] G. Aceto, V. Persico, A. Pescapé, and G. Ventre, “SOMETIME: Software defined network-based available bandwidth measurement in MONROE,” Proc. 1st Network Traffic Measurement and Analysis Conference, 2017.
CrossRef
[9] K. Suo, Y. Zhao, W. Chen, and J. Rao, “An analysis and empirical study of container networks,” IEEE INFOCOM 2018 - IEEE Conference on Computer Communications, pp.189–197, 2018.
CrossRef
[10] K. Fujimoto, M. Kaneko, K. Matsui, and M. Akutsu, “KBP: Kernel enhancements for low-latency networking for virtual machine and container without application customization,” IEICE Trans. Commun., vol.E105-B, no.5, pp.522–532, May 2022.
CrossRef
[11] X. Zhan, R. Azimi, S. Kanev, D. Brooks, and S. Reda, “CARB: A C-state power management arbiter for latency-critical workloads,” IEEE Comput. Arch. Lett., vol.16, no.1, pp.6–9, 2017.
CrossRef
[12] IEEE Std, “Standard for information technology ― Portable operating system interface (POSIX),” 1003.1, 2001.
[13] The Linux Kernel Organization, “Kernel livepatch,” https://www.kernel.org/doc/Documentation/livepatch/livepatch.txt
URL
[14] J.H. Salim, “When NAPI comes to town,” Linux Conference, 2005.
[15] Intel Corp., “DPDK: Data plane development kit,” http://dpdk.org/, 2014.
URL
[16] Intel Corp., “L3 forwarding with power management sample application,” https://doc.dpdk.org/guides/sample_app_ug/l3_forward_power_man.html
URL
[17] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards power efficient high performance packet I/O,” IEEE Trans. Parallel Distrib. Syst., vol.31, no.4, pp.981–996, 2020.
CrossRef
[18] J. Cummings and E. Tamir, “Open source kernel enhancements for low latency sockets using busy poll,” Intel White Paper, 2013.
[19] T. Høiland-Jørgensen, J.D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern, and D. Miller, “The eXpress data path: Fast programmable packet processing in the operating system kernel,” Proc. 14th International Conference on emerging Networking EXperiments and Technologies (CoNEXT), pp.54–66, 2018.
CrossRef
[20] A. Belay, G. Prekas, M. Primorac, A. Klimovic, S. Grossman, C. Kozyrakis, and E. Bugnion, “IX: A protected dataplane operating system for high throughput and low latency,” 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pp.49–65, 2014.
[21] G. Prekas, M. Kogias, and E. Bugnion, “ZygOS: Achieving low tail latency for microsecond-scale networked tasks,” 26th ACM Symposium on Operating Systems Principles (SOSP), pp.325–341, 2017.
CrossRef
[22] A. Ousterhout, J. Fried, J. Behrens, A. Belay, and H. Balakrishnan, “Shenango: Achieving high CPU efficiency for latency-sensitive datacenter workloads,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2019.
[23] K. Kaffes, T. Chong, J.T. Humphries, D. Mazières, C. Kozyrakis, A. Belay, and D. Mazì Eres, “Shinjuku: Preemptive scheduling for μ second-scale tail latency,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2019.
[24] Huaweii, “DMM lwIP,” https://github.com/Huawei/DMM 2018.
URL
[25] D. Zhuo, K. Zhang, Y. Zhu, H. Harry Liu, M. Rockett, A. Krishnamurthy, and T. Anderson, “Slim: OS kernel support for a low-overhead container overlay network slim: OS kernel support for a low-overhead container overlay network,” 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI), pp.331–344, 2019.
[26] D. Brodowski, “Linux CPUFreq governor,” https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
URL
[27] Kubernetes, https://kubernetes.io
URL
[28] K.N. Khan, M. Hirki, T. Niemi, J.K. Nurminen, and Z. Ou, “RAPL in action: Experiences in using RAPL for power measurements,” ACM Trans. Model. Perform. Eval. Comput. Syst., vol.3, no.2, pp.1–26, March 2018.
CrossRef
[29] R. Kavanagh, D. Armstrong, and K. Djemame, “Accuracy of energy model calibration with IPMI,” 2016 IEEE 9th International Conference on Cloud Computing (CLOUD), pp.648–655, 2016.
CrossRef
[30] S. Bradner and J. McQuaid, “RFC 2544: Benchmarking methodology for network interconnect devices,” IETF, 1999.
CrossRef
[31] Intel Corp., “Pktgen-DPDK,” https://github.com/pktgen/Pktgen-DPDK
URL