Panduan Utama Performa Jaringan Linux

 (ntk148v.github.io)
5 poin oleh GN⁺ 2024-07-29 | 1 komentar | Bagikan ke WhatsApp
  • Tuning performa jaringan Linux adalah pekerjaan menafsirkan alur perpindahan paket dari buffer cincin NIC, IRQ, NAPI, softIRQ, qdisc, buffer TCP, hingga soket aplikasi berdasarkan titik bottleneck
  • Pada jalur penerimaan, NIC menulis paket ke RAM melalui DMA dan memicu HardIRQ, lalu driver menjadwalkan NAPI untuk mengosongkan buffer cincin di NET_RX_SOFTIRQ sebelum meneruskannya ke lapisan IP/TCP dan buffer penerimaan soket
  • ethtool, /proc/net/softnet_stat, ss, netstat, sysctl adalah titik awal untuk observasi dan penyesuaian, sementara interrupt coalescing, IRQ affinity, RSS/RPS/RFS/aRFS, netdev_budget, netdev_max_backlog, txqueuelen, dan buffer baca/tulis TCP adalah sumbu utamanya
  • Tidak ada satu konfigurasi tunggal yang cocok untuk semua sistem; memperbesar buffer cincin dapat mengurangi drop tetapi menambah latensi, dan interrupt coalescing dapat menurunkan penggunaan CPU serta HardIRQ namun menimbulkan biaya latensi
  • Pemrosesan paket berperforma tinggi dapat diperluas dengan opsi seperti PACKET_MMAP, DPDK, PF_RING, XDP/AF_XDP, tetapi bypass kernel, zero-copy, dan fast path di dalam kernel masing-masing memiliki ketergantungan perangkat keras, penggunaan CPU, serta persyaratan versi kernel yang berbeda

Jalur penerimaan Linux: dari NIC ke soket

  • Perangkat jaringan memicu IRQ untuk memberi tahu kedatangan paket, dan pemetaan IRQ di Linux disimpan di /proc/interrupts
  • Handler IRQ berjalan dengan prioritas sangat tinggi dan dalam beberapa kasus mencegah pembuatan IRQ tambahan, sehingga driver menunda pekerjaan yang panjang ke luar konteks IRQ
  • Untuk pemrosesan tertunda ini digunakan softIRQ, dan dalam pemrosesan penerimaan jaringan dibuat thread kernel ksoftirqd/<cpu-number>, softnet_data, dan poll_list untuk tiap CPU
  • net_dev_init mendaftarkan NET_RX_SOFTIRQ ke sistem softIRQ, dan handler terkait adalah net_rx_action

  • Kedatangan paket dan pemrosesan NAPI

    • NIC menulis data yang diterima dari jaringan ke buffer cincin di RAM melalui DMA
    • Sebagian NIC adalah NIC multiqueue yang memiliki beberapa buffer cincin
    • Saat NIC memicu HardIRQ, handler IRQ milik driver akan dijalankan
    • Driver menghapus IRQ NIC dan memanggil napi_schedule untuk memulai loop poll softIRQ NAPI
    • napi_schedule menambahkan struktur poll NAPI milik driver ke poll_list CPU saat ini dan menetapkan pending bit softIRQ
    • Saat ksoftirqd memanggil __do_softirq, handler net_rx_action untuk NET_RX_SOFTIRQ yang berstatus pending akan dijalankan

  • GRO dan masuk ke protocol stack

    • net_rx_action memeriksa daftar poll NAPI, lalu memeriksa budget dan waktu yang telah berlalu agar softIRQ tidak memonopoli CPU
    • Fungsi poll milik driver memanen paket dari buffer cincin di RAM
    • Paket diteruskan ke napi_gro_receive
    • GRO(Generic Receive Offloading) adalah teknik offloading berbasis perangkat lunak yang menyusun ulang paket-paket kecil menjadi paket besar untuk mengurangi jumlah paket yang harus diproses aplikasi
    • Jika GRO tidak menahan paket, paket akan naik ke protocol stack melalui netif_receive_skb

  • Percabangan berdasarkan apakah RPS aktif

    • Jika RPS nonaktif:
      • netif_receive_skb meneruskan data ke __netif_receive_core
      • __netif_receive_core meneruskan data ke tap dan handler lapisan protokol yang terdaftar
    • Jika RPS aktif:
      • netif_receive_skb meneruskan data ke enqueue_to_backlog
      • Paket masuk ke input queue per CPU
      • Struktur NAPI CPU jarak jauh ditambahkan ke poll_list CPU tersebut, dan IPI diantrekan untuk membangunkan thread softIRQ pada CPU jarak jauh
      • ksoftirqd pada CPU jarak jauh memanen paket dari input queue CPU melalui fungsi poll process_backlog

  • IP, TCP, buffer penerimaan soket

    • Paket diterima di lapisan IPv4 melalui ip_rcv lalu melewati netfilter dan optimisasi routing
    • Data yang ditujukan ke sistem saat ini diteruskan ke lapisan protokol atas seperti UDP atau TCP
    • Pada jalur penerimaan TCP, paket masuk ke buffer penerimaan setelah melalui tcp_v4_rcv, TCP finite state machine, dan pencarian soket
    • Ukuran buffer penerimaan mengikuti aturan tcp_rmem
    • Jika tcp_moderate_rcvbuf aktif, kernel akan menyesuaikan buffer penerimaan secara otomatis
    • tcp_rmem berisi nilai minimum, default, dan maksimum untuk buffer penerimaan soket TCP
    • Jika menggunakan SO_RCVBUF, penyesuaian otomatis buffer penerimaan untuk soket tersebut akan dinonaktifkan
    • net.core.rmem_max adalah batas atas ukuran buffer penerimaan TCP, dan window yang lebih besar memungkinkan lebih banyak data dikirim sebelum ACK dikirim, sehingga mengurangi latensi dan meningkatkan throughput

Jalur pengiriman Linux: dari aplikasi ke NIC

  • Jalur pengiriman lebih sederhana daripada penerimaan, tetapi qdisc, buffer tulis TCP, DMA, dan IRQ tetap terlibat
  • Saat aplikasi mengirim pesan melalui panggilan seperti sendmsg, jalur pengiriman TCP mengalokasikan skb_buff
  • Paket masuk ke buffer tulis soket berukuran tcp_wmem
    • tcp_wmem berisi nilai minimum, default, dan maksimum untuk buffer pengiriman soket TCP
    • Kernel menyesuaikan ukuran buffer pengiriman TCP secara dinamis di antara nilai minimum dan maksimum
    • Jika menggunakan SO_SNDBUF, penyesuaian otomatis buffer pengiriman untuk soket tersebut akan dinonaktifkan
    • net.core.wmem_max adalah batas atas ukuran buffer pengiriman TCP
  • Header TCP dan IP dibuat, lalu setelah melalui LOCAL_OUT, routing, POST_ROUTING, dan fragmentasi, fungsi pengiriman L2 dipanggil melalui dev_queue_xmit
  • qdisc output menggunakan panjang txqueuelen dan algoritme default_qdisc
  • Driver menempatkan paket ke buffer cincin TX, lalu menjalankan NET_TX_SOFTIRQ setelah timeout tx-usecs atau setelah tx-frames
  • NIC mengambil paket dari RAM melalui DMA dan mengirimkannya, lalu memicu HardIRQ setelah transmisi selesai
  • Driver menangani IRQ ini dan menjadwalkan sistem poll NAPI untuk membebaskan RAM

Alat observasi dan titik pemeriksaan dasar

  • /proc/net/softnet_stat

    • Setiap baris di /proc/net/softnet_stat mewakili satu inti CPU dan dimulai dari CPU0
    • Statistik di tiap kolom disajikan dalam heksadesimal
    • Kolom pertama adalah jumlah frame yang diterima oleh interrupt handler
    • Kolom kedua adalah jumlah frame yang dibuang karena melebihi netdev_max_backlog
    • Kolom ketiga adalah jumlah kali ksoftirqd kehabisan netdev_budget atau waktu CPU saat masih ada pekerjaan yang harus diproses
    • Kolom lainnya dapat berbeda tergantung versi Linux

  • /proc/net/sockstat dan ss

    • Di /proc/net/sockstat, periksa field mem
    • Nilai ini dihitung dengan menjumlahkan sk_buff->truesize dari semua socket
    • ss adalah alat untuk mendump statistik socket, dan dapat menampilkan informasi yang mirip dengan netstat serta lebih banyak informasi TCP dan status
    • ss -tm digunakan untuk memeriksa penggunaan memori socket TCP
    • rmem_alloc: memori yang dialokasikan untuk paket terima
    • rcv_buf: total memori yang dapat dialokasikan untuk paket terima
    • wmem_alloc: memori yang digunakan untuk paket kirim yang sudah diteruskan ke layer 3
    • snd_buf: total memori yang dapat dialokasikan untuk paket kirim
    • wmem_queued: memori yang dialokasikan untuk paket kirim yang belum diteruskan ke layer 3
    • sock_drop: jumlah paket yang dibuang sebelum didemultipleks ke socket

  • netstat dan sysctl

    • netstat adalah alat baris perintah yang menampilkan koneksi jaringan terbuka dan statistik stack protokol, serta mengambil informasi dari sistem berkas /proc/net/
    • /proc/net/dev: informasi perangkat
    • /proc/net/tcp: informasi socket TCP
    • /proc/net/unix: informasi Unix domain socket
    • sysctl adalah perintah untuk mengubah pengaturan sistem dan jaringan alih-alih menulis nilai langsung ke sistem berkas /proc
    • sysctl -w variable=value digunakan untuk perubahan sementara, sedangkan perubahan permanen diterapkan dengan mengedit /etc/sysctl.conf lalu menjalankan sysctl -p

Buffer ring NIC dan penyesuaian interrupt

  • Buffer ring NIC

    • Buffer ring RX adalah buffer sirkular FIFO berukuran tetap yang berada di RAM
    • Buffer ring itu sendiri tidak menyimpan data paket, melainkan menyimpan descriptor yang menunjuk ke skb yang masuk ke RAM lewat DMA
    • Jika terlihat drop atau overrun, ukuran antrean bisa diperbesar, tetapi efek sampingnya latensi dapat meningkat
    • Dalam banyak kasus, cukup dengan memperbesar ukuran buffer terima sudah bisa mencegah packet drop dan memberi kernel sedikit lebih banyak waktu untuk mengosongkan buffer
    • Pemeriksaan dan perubahan dilakukan dengan ethtool
    • ethtool -g eth3: memeriksa ukuran ring RX/TX saat ini dan nilai maksimumnya
    • ethtool -G eth3 rx 8192 tx 8192: menaikkan buffer RX/TX ke nilai maksimum
    • Pantau dengan ethtool -S eth3 serta counter seperti err, drop, over, miss, timeout, reset, collis

  • Koalesensi interrupt perangkat keras

    • NIC dapat menumpuk referensi paket di buffer ring RX hingga kondisi timeout rx-usecs atau rx-frames terpenuhi, lalu memicu HardIRQ; ini disebut interrupt coalescence
    • Jika interrupt terjadi terlalu cepat, kernel akan terlalu sering menghentikan pekerjaan yang sedang berjalan dan performa sistem bisa memburuk
    • Jika interrupt terlalu lambat, lalu lintas mungkin tidak bisa dikosongkan dari NIC cukup cepat sehingga dapat terjadi penimpaan dan kehilangan trafik
    • Penyesuaian koalesensi interrupt dapat mengurangi penggunaan CPU dan HardIRQ serta meningkatkan throughput, tetapi bisa menambah latensi
    • Parameter coalesce dapat diperiksa dengan ethtool -c eth3, dan dapat diubah seperti ethtool -C eth3 adaptive-rx off rx-usecs 0 rx-frames 0
    • Mode adaptif membuat kartu memperkirakan pengaturan coalescing secara dinamis berdasarkan pola trafik dan pola penerimaan kernel

IRQ affinity dan pembagian beban antar-CPU

  • IRQ affinity

    • IRQ memiliki properti smp_affinity yang menentukan inti CPU mana yang dapat menjalankan ISR untuk IRQ tersebut
    • Menyesuaikan affinity interrupt dan affinity thread aplikasi ke inti CPU tertentu dapat meningkatkan performa aplikasi melalui berbagi cache line
    • Secara default, ini dikendalikan oleh daemon irqbalance
    • irqbalance harus dihentikan sebelum melakukan penyesuaian manual
    • /proc/irq/<IRQ_NUMBER>/smp_affinity menyimpan bitmask heksadesimal yang mewakili inti CPU
    • Pada server 4 inti, nilai default f berarti IRQ dapat diproses di semua CPU
    • echo 1 > /proc/irq/32/smp_affinity membuatnya hanya menggunakan CPU0
    • Pada sistem dengan lebih dari 32 inti, grup 32-bit dipisahkan dengan koma
    • IRQ affinity hanya dapat meningkatkan performa pada konfigurasi yang sangat spesifik dan workload yang sudah didefinisikan sebelumnya, sehingga bisa menjadi pedang bermata dua

  • RSS

    • Pada NIC cepat, jika paket diterima hanya dengan satu queue dan satu CPU, satu inti bisa menanggung seluruh pemrosesan data sementara inti lain tetap menganggur
    • RSS (Receive-side scaling) adalah teknologi NIC yang mendistribusikan trafik ke beberapa antrean kirim/terima
    • NIC menghitung hash berdasarkan source/destination IP serta source/destination port TCP/UDP, lalu menempatkan paket dari flow yang sama ke satu queue sambil mendistribusikan flow secara merata ke berbagai queue
    • RSS memberikan manfaat pemrosesan terima paralel di lingkungan multiproses
    • Menurut dokumentasi kernel Linux, RSS sebaiknya diaktifkan ketika latensi penting atau pemrosesan interrupt terima menjadi bottleneck, dan pada jaringan latensi rendah, pengaturan optimal adalah mengalokasikan jumlah queue sebanyak jumlah CPU sistem

  • RPS, RFS, aRFS

    • RPS (Receive Packet Steering) mendekati implementasi perangkat lunak dari RSS
    • Jika RSS memilih queue dan CPU yang akan menjalankan hardware interrupt handler, RPS memilih CPU yang akan melakukan pemrosesan protokol di atas interrupt handler
    • CONFIG_RPS diperlukan dan aktif secara default pada SMP
    • Konfigurasi dilakukan melalui bitmap CPU di /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
    • Jika RSS tersedia, ini mungkin tidak diperlukan, tetapi bisa berguna jika jumlah CPU lebih banyak daripada jumlah queue
    • RFS (Receive Flow Steering) memperluas RPS hingga ke locality aplikasi
    • RPS mendistribusikan paket berdasarkan flow, tetapi tidak mempertimbangkan CPU mana tempat aplikasi user space berjalan
    • RFS mempertahankan rps_sock_flow_table, yaitu tabel flow-ke-CPU global
    • Ukuran tabel dapat disesuaikan dengan net.core.rps_sock_flow_entries
    • rps_dev_flow_table per-queue digunakan untuk mengurangi masalah urutan yang berantakan akibat paket tersisa saat scheduler memindahkan aplikasi ke CPU baru
    • aRFS (Accelerated RFS) adalah mekanisme pembagian beban dengan akselerasi perangkat keras untuk RFS
    • Karena paket dikirim langsung ke CPU yang dekat dengan thread yang mengonsumsi data, performanya bisa lebih baik daripada RFS
    • Membutuhkan ndo_rx_flow_steer, filtering ntuple, dan CONFIG_RFS_ACCEL pada NIC
    • Pemetaan CPU dan queue diturunkan otomatis dari IRQ affinity tiap queue penerima, sehingga tidak memerlukan konfigurasi tambahan

softIRQ, qdisc, tuning buffer TCP

  • Budget softIRQ

    • Rutinitas polling NAPI dibatasi oleh netdev_budget_usecs, netdev_budget, dan dev_weight agar softIRQ tidak memonopoli CPU
    • Nilai default net.core.netdev_budget adalah 300, yang berarti proses softIRQ akan mengosongkan 300 pesan dari NIC sebelum dilepas dari CPU
    • net.core.netdev_budget_usecs adalah jumlah maksimum mikrodetik untuk satu siklus polling NAPI
    • net.core.dev_weight adalah jumlah maksimum paket per CPU yang dapat diproses kernel pada interrupt NAPI
    • Jika kolom selain kolom pertama di /proc/net/softnet_stat meningkat, mungkin perlu mengubah budget, meskipun kenaikan kecil bisa normal

  • qdisc ingress dan netdev_max_backlog

    • netdev_max_backlog adalah antrean internal kernel tempat trafik disimpan setelah diterima dari NIC dan sebelum diproses oleh stack protokol seperti IP/TCP
    • Ada satu backlog queue untuk setiap core CPU
    • Jika antarmuka menerima paket lebih cepat daripada kemampuan kernel untuk memprosesnya, antrean sisi INPUT akan terisi hingga netdev_max_backlog, dan paket yang melebihinya akan di-drop
    • Nilai defaultnya 1000, dan ini bisa tidak mencukupi untuk beberapa antarmuka 1Gbps atau satu antarmuka 10Gbps
    • Kolom kedua pada /proc/net/softnet_stat adalah penghitung yang meningkat saat terjadi overflow backlog queue
    • Perubahan nilai dilakukan dengan sysctl -w net.core.netdev_max_backlog <value>

  • qdisc egress, txqueuelen, default_qdisc

    • txqueuelen menetapkan jumlah paket yang diizinkan pada kernel transmit queue perangkat antarmuka jaringan
    • Nilai defaultnya bisa 1000 tergantung driver antarmuka
    • Ubah dengan ifconfig <interface> txqueuelen value, lalu periksa RX/TX dropped di ip -s link
    • default_qdisc adalah queuing discipline default yang akan digunakan untuk perangkat jaringan
    • Anda dapat menentukan alternatif seperti sfq, codel, fq_codel alih-alih pfifo_fast
    • Periksa metrik seperti dropped, overlimits, dan requeues di tc -s qdisc ls dev <interface>

  • Buffer baca/tulis TCP dan antrean koneksi

    • tcp_rmem dan tcp_wmem masing-masing mendefinisikan nilai minimum, default, dan maksimum untuk buffer penerimaan dan pengiriman TCP
    • Perubahan dilakukan seperti berikut
      • sysctl -w net.ipv4.tcp_rmem="min default max"
      • sysctl -w net.ipv4.tcp_wmem="min default max"
    • Periksa status penggunaan buffer dengan /proc/net/sockstat
    • Accept queue dan SYN queue dipengaruhi oleh net.core.somaxconn dan net.ipv4.tcp_max_syn_backlog
    • net.core.somaxconn adalah batas atas parameter backlog pada listen(), dan jika nilai ini diubah maka aplikasi juga harus diubah ke nilai yang kompatibel
    • net.ipv4.tcp_syncookies menyalakan atau mematikan SYN cookie yang berguna untuk perlindungan dari serangan SYN flood
    • net.ipv4.tcp_congestion_control menetapkan algoritme congestion control yang akan digunakan untuk koneksi baru

NUMA dan performa jaringan

  • NUMA(Non-uniform memory access) adalah arsitektur memori di mana prosesor dapat mengakses local memory lebih cepat daripada non-local memory
  • Dalam pemrosesan jaringan, CPU harus mengakses memori ring buffer, sehingga locality NUMA dapat memengaruhi performa jaringan
  • NUMA membagi CPU, memori, dan perangkat ke dalam beberapa node, dan bekerja seperti beberapa komputer kecil dengan interconnect cepat serta OS bersama
  • Pada sistem NUMA, tujuan tuning adalah mengumpulkan interrupt perangkat ke core CPU pada node tunggal tempat perangkat tersebut berada
  • Namun, sistem NUMA dapat berinteraksi kurang baik dengan aplikasi real-time dan menimbulkan latensi peristiwa yang tidak terduga
  • Node NUMA dapat diperiksa di /sys/devices/system/node/node*
  • Locality perangkat dapat diperiksa di /sys/class/net/<interface>/device/numa_node
    • -1 berarti platform hardware sebenarnya bukan NUMA, atau kernel meniru NUMA, atau perangkat tidak memiliki locality NUMA
  • Linux kernel mendukung NUMA sejak 2.5, dan distribusi berbasis RedHat serta Debian menyediakan numactl dan numad
  • numad memantau topologi sistem dan penggunaan sumber daya, lalu mencoba menempatkan proses dengan beban memori dan CPU yang cukup besar ke locality NUMA yang efisien

Opsi pemrosesan paket yang lebih cepat

  • AF_PACKET v4 dan PACKET_MMAP

    • AF_PACKET v4 adalah antarmuka paket cepat di Linux, yang menghilangkan system call dari data path dan secara default menggunakan mode copy
    • Dengan menggunakan PACKET_ZEROCOPY, true zero-copy mode dapat digunakan dengan memetakan DMA packet buffer ke user space
    • Jalur umum file read lalu socket send memerlukan context switch antara user mode dan kernel mode serta beberapa kali data copy
    • zero-copy meningkatkan performa dengan menghilangkan data copy yang redundan
    • PACKET_MMAP adalah API Linux untuk packet sniffing berkecepatan tinggi
    • Ini menyediakan mmapped ring buffer yang dibagikan antara user space dan kernel
    • Mengurangi system call dan copy antara user space dan kernel pada paket kirim dan terima

  • DPDK

    • DPDK(Data Plane Development Kit) adalah pustaka user space dan framework driver untuk pemrosesan paket berkecepatan tinggi
    • Tujuannya adalah mengirim dan menerima paket jaringan pada native speed antara NIC dan aplikasi pengguna
    • Ditujukan untuk NIC 10Gb atau 40Gb, dengan kecepatan sebagai kriteria paling penting
    • Fokusnya bukan pada network stack, melainkan pada packet forwarding
    • Saat DPDK mengendalikan NIC, semua traffic melewati kernel, dan NIC tersebut tidak terlihat oleh kernel
    • Port di-unbind dari driver kernel Linux dan dikelola oleh driver seperti vfio_pci, igb_uio, uio_pci_generic
    • Setelah itu, komunikasi antara aplikasi dan NIC ditangani oleh DPDK PMD
    • DPDK memerlukan konfigurasi hugepages untuk mengalokasikan chunk memori besar
    • Komponen utama:
      • EAL: generic interface yang menyembunyikan perbedaan lingkungan
      • librte_ring: API FIFO lockless multi-producer, multi-consumer
      • librte_mempool: alokasi pool objek memori
      • librte_mbuf: pembuatan dan manipulasi buffer yang menampung paket jaringan
      • librte_timer: layanan timer untuk eksekusi fungsi asinkron
      • PMD: driver di mana CPU terus melakukan poll ke NIC alih-alih menggunakan interrupt
    • Keterbatasan:
      • Sangat bergantung pada perangkat keras
      • Untuk menjalankan PMD, CPU core harus dialokasikan secara khusus dan akan menggunakan 100% CPU

  • PF_RING

    • PF_RING adalah Linux kernel module dan framework user-space yang memproses paket pada kecepatan tinggi serta menyediakan API yang konsisten untuk aplikasi pemrosesan paket
    • PF_RING melakukan poll paket dari NIC menggunakan Linux NAPI
    • NAPI menyalin paket dari NIC ke PF_RING circular buffer, lalu aplikasi user space membaca paket dari ring
    • Struktur ini memiliki dua poller, yaitu aplikasi dan NAPI, sehingga polling menghabiskan CPU cycle
    • Kelebihannya adalah incoming packet dapat didistribusikan ke beberapa ring secara bersamaan
    • Berkat struktur modularnya, komponen tambahan seperti ZC module, FPGA-based card module, Stack module, Timeline module, dan Sysdig module dapat digunakan
    • PF_RING telah mengurangi biaya packet capture dan userland forwarding, tetapi performa optimal tetap terbatas karena struktur dua aktor, yaitu kernel menyalin dari NIC ke ring dan userland membaca dari ring untuk diproses
    • PF_RING sejak versi 7.5 menyertakan dukungan adapter AF_XDP

  • XDP dan AF_XDP

    • XDP(eXpress Data Path) adalah implementasi eBPF yang mencegat paket pada tahap awal di data path jaringan Linux
    • XDP memproses RX packet page secara langsung di dalam RX function milik device driver, sebelum alokasi SKB
    • eBPF adalah bytecode sandboxed yang dapat dikustomisasi dan berjalan di kernel
    • Menggunakan 11 register 64-bit dan stack 512-byte
    • Dengan LLVM backend, kode dari C, Lua, Go, P4, Rust, dan lainnya dapat dikompilasi menjadi eBPF
    • Menyediakan in-kernel verifier dan JIT compiler, serta mendukung fitur seperti map, tail call, dan helper
    • Kasus penggunaan XDP:
      • pre-stack filtering untuk mitigasi DoS
      • forwarding dan load balancing
      • teknik batching seperti GRO
      • flow sampling dan monitoring
      • pemrosesan ULP
    • XDP bukan kernel bypass, melainkan fast path di dalam kernel stack, dan tidak menggantikan TCP/IP stack
    • Tidak memerlukan perangkat keras khusus, tetapi memiliki persyaratan seperti multi-queue NIC, TX/RX checksum offload, RSS, dan TSO
    • Kelebihan XDP dibanding DPDK:
      • dapat memilih busy polling atau interrupt driven networking
      • tidak memerlukan huge pages
      • tidak memiliki persyaratan perangkat keras khusus
      • CPU khusus tidak wajib
      • tidak perlu menyuntikkan kembali paket dari aplikasi userspace pihak ketiga ke kernel
      • tidak memerlukan security model baru untuk akses ke perangkat keras jaringan
      • tidak memerlukan kode/lisensi pihak ketiga
    • AF_XDP adalah jenis socket baru yang diperkenalkan di Linux 4.18
    • Tanpa sepenuhnya melewati kernel, ini dapat memanfaatkan fitur kernel untuk membangun struktur yang mirip dengan DPDK atau AF_PACKET
    • Program XDP dapat me-redirect frame melalui eBPF ke user space memory buffer
    • DMA transfer mendukung zero-copy dengan menggunakan memori user space
    • Dapat mencapai peningkatan performa 3 hingga 20 kali dibanding AF_PACKET
    • Keterbatasan:
      • proyek ini relatif muda
      • untuk dukungan penuh diperlukan Linux kernel 5.4 atau lebih baru

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-29
Komentar Hacker News

  • Ini sepertinya akan sangat berguna kalau saja saya melihatnya beberapa minggu lalu
    Saya meminta penawaran appliance hardware dari beberapa vendor untuk melakukan enkripsi tautan L2 antar data center, tetapi biayanya terasa terlalu mahal, jadi saya mencoba membuatnya sendiri
    Saya mengonfigurasi hardware serbaguna untuk membawa frame Ethernet di atas jaringan overlay WireGuard dan mencapai 10Gbps. Setelah sekitar sepuluh hari bekerja, saya berhasil menerapkannya sekitar 70% lebih murah daripada proposal termurah dan sekitar 95% lebih murah daripada proposal termahal, tetapi itu membutuhkan banyak pembacaan dokumentasi yang rinci dan eksperimen
    Saya ingin memakai isi tulisan ini untuk memvalidasi apakah pemahaman saya benar, dan sekilas tampaknya menjanjikan serta komprehensif

    • Saya penasaran, untuk kebutuhan apa tunnel L3 tidak cukup?
    • Kalau kodenya bisa dibagikan, saya ingin melihatnya. Saya sangat penasaran bagaimana implementasi seperti itu dilakukan

  • Kalau ada sebanyak ini nilai yang bisa disetel, rasanya mungkin layak membuat software auto-tuning
    Pendekatan mirip gradient descent tampaknya memungkinkan: pilih parameter dari whitelist secara acak, naikkan atau turunkan sedikit dalam rentang yang diizinkan, ukur performa untuk sementara, lalu kembalikan jika memburuk dan lanjutkan penyetelan jika membaik

  • Menarik, tetapi sebagai software engineer saya hampir tidak punya kesempatan untuk benar-benar menjalankan perintah-perintah dalam tulisan itu
    Sebagian besar sistem berjalan di container versi ringkas dari suatu Linux, tidak ada akses shell ke sistem produksi, dan lingkungan development atau QA terlalu berbeda dari produksi dalam hal beban sehingga mereproduksi bug biasanya tidak terlalu membantu
    Pada akhirnya, kesempatan untuk menjalankan perintah-perintah di tulisan itu hanya muncul saat mengutak-atik sistem pribadi, dan sepertinya akan berguna jika bekerja sebagai platform engineer

    • Sebagian besar fitur level rendah kemungkinan besar tidak akan berfungsi atau tidak berguna. Implementasi antarmuka jaringan container biasanya membuat kita berurusan dengan pasangan veth, dan melakukan berbagai pemrosesan aneh di user space
      Salah satu hal yang kurang saya sukai dari Kubernetes adalah model networking-nya. Ia mengasumsikan hanya ada satu kartu jaringan, dan beranggapan bahwa aplikasi cukup sederhana sehingga tidak perlu tahu tentang lapisan di bawahnya
      Seluruh model networking tampaknya masih sangat bisa dirombak besar-besaran dengan gaya tahun 2020-an demi penyederhanaan dan perbaikan
    • Jika ada lingkungan staging yang semirip mungkin dengan produksi, Anda bisa bereksperimen dan menganalisis di lingkungan mirip produksi yang dapat diakses, sehingga ini bisa membantu tergantung situasinya

  • net.core.wmem_max disebut sebagai batas atas ukuran buffer kirim TCP, dan ada juga net.ipv4.tcp_wmem, jadi saya punya dua pertanyaan

    1. Mengapa tidak ada nilai yang setara untuk IPv6? 2. Apa bedanya dengan net.core.wmem_max?
    • net.core.wmem_max, sesuai namanya, adalah nilai maksimum
      net.ipv4.tcp_wmem adalah triplet berisi tiga nilai: minimum, default, maksimum, dan nilai maksimum yang ditentukan di sini tidak boleh melampaui net.core.wmem_max tadi
      TCP adalah protokol yang seharusnya sama, baik dibawa melalui IPv4 maupun IPv6
      Contoh: https://docs.redhat.com/en/documentation/red_hat_data_grid/7...

  • Yang agak kurang dibahas di sini adalah debugging dan tuning untuk throughput di atas 100Gbps
    Saat menyajikan HTTP pada skala itu, bottleneck pertama biasanya bandwidth memori, sehingga kTLS sering kali menjadi perlu
    Tool seperti AMD μProf sangat berguna untuk debugging, dan continuous profiling berbasis eBPF juga membantu untuk memahami secara persis apa yang terjadi di kernel dan user space

  • Kelihatannya cukup keren. Sejauh ini dalam karier saya, setiap kali performa dibutuhkan, biasanya saya mulai dari kernel bypass