Interrupt আর DMA — hardware-এর দিক থেকে

১ · যন্ত্রের খবর কীভাবে নেবেন — polling বনাম interrupt, আর খরচের হিসাব

পর্ব ৫১-এ (I/O আর bus) দেখেছেন, CPU যন্ত্রের সাথে কথা বলে memory-mapped I/O register দিয়ে, আর সবচেয়ে সরল উপায়ে বারবার একটি status register পড়ে জানতে চায় “কাজ হলো?” — এর নাম polling. পর্ব ৩৮-এ (Exception আর interrupt) দেখেছেন CPU-র ভেতরের দিক: mcause, mepc, mtvec, vectored mode, nesting আর interrupt latency. সেগুলো এখানে আর বলব না। এই পর্বের প্রশ্ন যন্ত্রের দিক থেকে: যন্ত্র কীভাবে CPU-কে ডাকে, ডাকটা কোন পথে আসে, আর বিশাল ডেটা CPU-কে না খাটিয়ে কীভাবে মেমরিতে পৌঁছায়।

খরচের মডেল

তিনটি খরচ ধরি, সবই CPU cycle-এ: প্রতিবার poll করার খরচ C_poll (একটি uncached MMIO read আর লুপ), প্রতিটি interrupt-এর বাড়তি খরচ C_irq (পর্ব ৩৮-এর flush, register সেভ-ফেরত, controller-কে জানানো, cache-এর ক্ষতি), আর প্রতিটি ঘটনার আসল কাজ C_work — যেটা যেকোনো পদ্ধতিতেই করতে হবে। যন্ত্রের ঘটনার হার r (প্রতি সেকেন্ডে কতবার), poll করা হয় প্রতি P সেকেন্ডে একবার, clock rate f.

যুক্তিটা সরল: C_work দুই দিকেই একই, তাই তুলনায় বাদ যায়। Polling দেয় একটি স্থির কর — ঘটনা হোক বা না হোক, প্রতি সেকেন্ডে 1/P বার দেখতেই হবে। Interrupt দেয় ঘটনাপ্রতি কর — ঘটনা যত বেশি, খরচ তত বেশি। স্থির কর আর ঘটনাপ্রতি করের রেখা যেখানে মেলে, সেটাই r*.

উদাহরণ (হাতে): ২ GHz CPU. প্রতি ২০ µs-এ poll, অর্থাৎ সেকেন্ডে ৫০,০০০ বার, প্রতিটি ৪০০ cycle — মোট ২ কোটি cycle, CPU-র ১%, ঘটনা থাকুক বা না থাকুক। Interrupt-এর বাড়তি খরচ ৩০০০ cycle, আসল কাজ ১০০০ cycle. তাহলে r* = ৪০০ ÷ (২০ µs × ৩০০০) = ২ কোটি ÷ ৩০০০ ≈ সেকেন্ডে ৬,৬৬৭টি ঘটনা. কি-বোর্ড (সেকেন্ডে কয়েকটি চাপ) এর অনেক নিচে — interrupt-ই ঠিক। কিন্তু একটি network card সেকেন্ডে ৩,০০,০০০ packet দিলে interrupt-এ খরচ ৩,০০,০০০ × ৪০০০ = ১২০ কোটি cycle = ৬০%, আর polling-এ ১% + ৩,০০,০০০ × ১০০০ ÷ ২০০ কোটি = ১% + ১৫% = ১৬%.

কিন্তু polling-এর দাম latency-তে: ঘটনাটি গড়ে ১০ µs অপেক্ষা করে। মাঝামাঝি উপায় হলো interrupt coalescing (interrupt moderation): যন্ত্র কয়েকটি ঘটনা জমিয়ে একটি interrupt দেয় — হয় K-টি ঘটনা জমলে, নয়তো প্রথম ঘটনার পর T সময় পেরোলে, যেটা আগে হয়। নিচের simulator একটি যন্ত্রের এলোমেলো (Poisson) ঘটনার ধারা তৈরি করে তিনটি পদ্ধতিই চালায়। সব খরচ ধরে নেওয়া মান, কোনো নির্দিষ্ট chip-এর মাপা মান নয়:

// Polling vs interrupt vs coalesced interrupt for one device -- every cost below is an ASSUMPTION
const F = 2e9;                          // CPU clock: 2 GHz
const POLL_US = 20, POLL_CYC = 400;     // read the status register every 20 us, 400 cycles per poll
const IRQ_CYC = 3000, IRQ_LAT_US = 1;   // per interrupt: entry, ack, exit, cache damage; 1 us to the handler
const WORK_CYC = 1000;                  // handler work per event (same in every scheme)
const K = 8, T_US = 20;                 // coalescing: one interrupt per 8 events or 20 us, whichever first
const SIM_S = 0.2;                      // simulate 0.2 s
let seed = 42;                          // deterministic random arrivals (Park-Miller generator)
const rnd = () => (seed = (seed * 16807) % 2147483647) / 2147483647;
const pct = c => (100 * c / (F * SIM_S)).toFixed(2).padStart(7);
const us = x => x.toFixed(1).padStart(6);
console.log("events/s |  poll: CPU%  lat us |  irq: CPU%  lat us | coalesce: CPU%  lat us  ev/irq");
for (const rate of [1000, 10000, 100000, 300000]) {
  const t = [];                         // arrival times in microseconds (Poisson process)
  for (let x = -Math.log(rnd()) / rate; x < SIM_S; x += -Math.log(rnd()) / rate) t.push(x * 1e6);
  const n = t.length;
  let pLat = 0;                         // polling: wait until the next poll tick
  for (const a of t) pLat += Math.ceil(a / POLL_US) * POLL_US - a;
  const pollCyc = (SIM_S * 1e6 / POLL_US) * POLL_CYC + n * WORK_CYC;
  const irqCyc = n * (IRQ_CYC + WORK_CYC);      // one interrupt per event
  let irqs = 0, cLat = 0;               // coalescing: batch closes at the K-th event or T_US after its first
  for (let i = 0; i < n; ) {
    let j = i;
    while (j + 1 < n && j + 1 - i < K && t[j + 1] <= t[i] + T_US) j++;
    const fire = (j - i + 1 === K) ? t[j] : t[i] + T_US;
    for (let m = i; m <= j; m++) cLat += fire - t[m] + IRQ_LAT_US;
    irqs++; i = j + 1;
  }
  const coCyc = irqs * IRQ_CYC + n * WORK_CYC;
  console.log(String(rate).padStart(8) + " |" + pct(pollCyc) + " " + us(pLat / n) + "   |" + pct(irqCyc) + " " +
    us(IRQ_LAT_US) + "   |    " + pct(coCyc) + " " + us(cLat / n) + "  " + (n / irqs).toFixed(1).padStart(6));
}

events/s |  poll: CPU%  lat us |  irq: CPU%  lat us | coalesce: CPU%  lat us  ev/irq
    1000 |   1.05    9.9   |   0.19    1.0   |       0.18   20.6     1.0
   10000 |   1.50   10.0   |   1.99    1.0   |       1.73   19.3     1.2
  100000 |   5.95   10.0   |  19.80    1.0   |       9.95   14.3     3.0
  300000 |  15.89   10.0   |  59.54    1.0   |      21.87   10.9     6.4

মিশ্র পদ্ধতি — interrupt দিয়ে জাগা, polling দিয়ে খালি করা

উচ্চ হারে আরও একটি বিপদ: interrupt এত ঘন আসে যে CPU শুধু handler-ই চালায়, ডেটা অ্যাপ্লিকেশনে পৌঁছানোর সময়ই পায় না — একে বলে receive livelock. Linux-এর network stack-এর NAPI একটি পরিচিত সমাধান (খুঁটিনাটি version অনুযায়ী বদলায়): প্রথম packet-এ interrupt, তারপর driver সেই queue-র interrupt বন্ধ করে একটি বাজেট পর্যন্ত (প্রায়ই ৬৪টি packet) ring থেকে poll করে; ring খালি হলে আবার interrupt চালু। কম চাপে interrupt-এর কম latency, বেশি চাপে polling-এর কম খরচ। আরও চরমে (DPDK-র মতো framework) একটি পুরো core শুধু polling-এ রাখা হয়। OS-এর দিক থেকে top half আর bottom half আছে Operating Systems কোর্সের I/O সিস্টেম পর্বে।

Software-এ একটি উপমা — POSIX signal

Hardware interrupt সরাসরি user প্রোগ্রাম থেকে দেখা যায় না। তবে Linux-এর POSIX signal একই ধাঁচের একটি software ব্যবস্থা: kernel-এর একটি timer সময় পূর্ণ হলে প্রসেসকে SIGALRM পাঠায়, আর প্রোগ্রামের মূল লুপ কিছু না জেনেই হঠাৎ handler-এ চলে যায়, তারপর আবার যেখানে ছিল সেখানে ফেরে। নিচের প্রোগ্রামে handler শুধু একটি flag বসায় — ঠিক যেমন ভালো interrupt handler কম কাজ করে বাকিটা পরে করার জন্য রেখে দেয়:

// Software ANALOGY of an asynchronous interrupt: SIGALRM from an interval timer
#define _DEFAULT_SOURCE
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>

static volatile sig_atomic_t tick = 0;         // set by the "handler", read by the main loop

static void on_alarm(int sig) { (void)sig; tick = 1; }   // keep the handler tiny: just set a flag

int main(void) {
    struct sigaction sa;
    memset(&sa, 0, sizeof sa);
    sa.sa_handler = on_alarm;                  // like writing the handler address into mtvec
    sigaction(SIGALRM, &sa, NULL);
    struct itimerval it = { {0, 50000}, {0, 50000} };   // every 50 ms, first after 50 ms
    setitimer(ITIMER_REAL, &it, NULL);         // like programming a device timer

    unsigned long work = 0, last = 0;
    int seen = 0;
    while (seen < 5) {
        work++;                                // the "main program" keeps doing its own job
        if (tick) {                            // the flag is checked between pieces of work
            tick = 0;
            seen++;
            printf("tick %d: work done since previous tick = about %lu million\n",
                   seen, (work - last + 500000) / 1000000);
            last = work;
        }
    }
    printf("main loop stopped after %d ticks; it never called the handler itself\n", seen);
    return 0;
}

tick 1: work done since previous tick = about 38 million
tick 2: work done since previous tick = about 37 million
tick 3: work done since previous tick = about 35 million
tick 4: work done since previous tick = about 29 million
tick 5: work done since previous tick = about 36 million
main loop stopped after 5 ticks; it never called the handler itself

২ · যন্ত্র কীভাবে ডাকে — IRQ লাইন, level বনাম edge, আর interrupt controller

সবচেয়ে পুরোনো আর সরল ব্যবস্থায় প্রতিটি যন্ত্র থেকে একটি তার যায় interrupt controller-এর দিকে — interrupt request (IRQ) লাইন. যন্ত্র কিছু জানাতে চাইলে লাইনের voltage বদলায়। কিন্তু “voltage বদলানো” দুইভাবে বোঝা যায়, আর এই পার্থক্য driver লেখার সময় সত্যিকারের bug তৈরি করে:

পর্ব ১৫-এ latch আর flip-flop-এর level-sensitive আর edge-triggered আচরণ দেখেছিলেন; এখানে একই শব্দ, কিন্তু প্রশ্নটা সময়ের নয় — অনুরোধ কতক্ষণ বেঁচে থাকে, সেটির।

Interrupt controller-এর চারটি কাজ

শত শত যন্ত্রের লাইন সরাসরি CPU-তে আনা অসম্ভব। তাই মাঝখানে বসে interrupt controller, যার কাজ মোটামুটি চারটি: (১) জড়ো করা — প্রতিটি লাইন দেখে কোনটির অনুরোধ pending, তা মনে রাখা; (২) priority — একসাথে কয়েকটি এলে কোনটি আগে; (৩) masking — প্রতিটি উৎস আলাদা করে চালু বা বন্ধ রাখা, যাতে একটি বিগড়ে যাওয়া যন্ত্র বাকিদের না আটকায়; (৪) routing — কোন core-কে জানানো হবে, আর CPU-কে বলে দেওয়া কোন উৎস ডেকেছে (একটি ID বা vector), যাতে handler-কে সব যন্ত্রকে জিজ্ঞেস করতে না হয়। শেষে CPU জানায় “সেবা শেষ” — x86-এ একে বলা হয় EOI (end of interrupt), RISC-V PLIC-এ complete.

RISC-V-এর PLIC — claim আর complete

RISC-V-এর PLIC (Platform-Level Interrupt Controller) এই চারটি কাজ খুব পরিষ্কারভাবে ভাগ করে। প্রতিটি উৎসের (১ থেকে ১০২৩ পর্যন্ত; ০ মানে “কোনো interrupt নেই”) একটি gateway আছে, যা level বা edge সংকেতকে একটি “অনুরোধে” বদলায় আর একবারে একটির বেশি অনুরোধ পাঠায় না। প্রতিটি উৎসের একটি priority register (০ মানে কখনো নয়)। প্রতিটি context-এর — অর্থাৎ একটি hart আর একটি privilege mode-এর জোড়ার — আছে নিজস্ব enable বিট, একটি threshold (এর চেয়ে বেশি priority-র interrupt-ই শুধু পৌঁছায়), আর একটি claim/complete register. CPU-র দিকে PLIC শুধু একটি বিট তোলে — machine mode-এর জন্য mip.MEIP; তারপর পর্ব ৩৮-এর trap-যাত্রা শুরু হয়। Handler claim register পড়লে PLIC সবচেয়ে উঁচু priority-র pending উৎসের ID দেয় আর সেটির pending বিট মুছে দেয়; কাজ শেষে একই ID complete register-এ লিখলে gateway আবার নতুন অনুরোধ পাঠাতে পারে।

নিচের stepper-এ একটি network card উৎস ৭ (priority ৫) হিসেবে hart ০-এর machine-mode context-এ (threshold ২) interrupt দিচ্ছে। লাইনটি level-triggered:

1NIC: কাজ শেষ → IRQ 7 লাইন সক্রিয়2PLIC: pending[7] = 1; 5 > threshold 2 → MEIP3hart 0: trap → handler (পর্ব ৩৮)4id = read(claim)        // 75NIC-এর status পড়া, কারণ-বিট মোছা6write(complete, id); mret

Interrupt storm আর spurious interrupt

Interrupt storm মানে একটি উৎস থেকে থামাথামিহীন interrupt, যাতে CPU আর কিছু করতে পারে না — সাধারণত level-triggered লাইনের কারণ-বিট না মোছা, ভুল driver বা বিকল যন্ত্রের ফল। Linux-এর মতো kernel কোনো লাইনে বারবার এমন interrupt দেখলে, যা কোনো handler “নিজের” বলে স্বীকার করেনি, লাইনটি বন্ধ করে log-এ “nobody cared” ধরনের বার্তা লেখে। Spurious interrupt উল্টো: interrupt এল, কিন্তু কেউ ডাকেনি — লাইনে সাময়িক noise, বা অন্য core আগেই সেবা দিয়েছে। PLIC-এ claim ০ ফেরালে handler কিছু না করে ফেরে।

৩ · MSI আর MSI-X — interrupt যখন একটি memory write

PCIe-তে প্রতিটি যন্ত্রের জন্য আলাদা interrupt-তার নেই; সব কথাবার্তা packet-এ (পর্ব ৫১)। পুরোনো INTx লাইন সেখানে বিশেষ message দিয়ে অনুকরণ করা হয়, কিন্তু আধুনিক যন্ত্রের আসল পদ্ধতি MSI (Message Signaled Interrupt): চালু হওয়ার সময় OS যন্ত্রকে একটি ঠিকানা আর একটি ডেটা মান বলে দেয়। Interrupt দিতে যন্ত্র ঠিক সেই ঠিকানায় সেই মানটি লেখে — একটি সাধারণ DMA memory write. ঠিকানাটি RAM-এর নয়, interrupt controller-এর: x86-এ এটি local APIC-এর জন্য রাখা একটি বিশেষ ঠিকানা-এলাকায় (সাধারণত 0xFEE… দিয়ে শুরু) যায়, আর ডেটার ভেতরে থাকে vector. RISC-V-এর নতুন AIA নকশায় এই কাজ করে প্রতিটি hart-এর IMSIC.

• লাইন ভাগাভাগি নেই: প্রতিটি interrupt-এর নিজস্ব vector, তাই handler-কে “কে ডাকল” খুঁজতে হয় না।
• অনেক vector: MSI-তে একটি যন্ত্র সর্বোচ্চ ৩২টি পর্যন্ত, আর MSI-X-এ সর্বোচ্চ ২০৪৮টি — প্রতিটির আলাদা ঠিকানা-ডেটা জোড়া, যন্ত্রের মেমরিতে একটি টেবিলে।
• Queue-প্রতি interrupt আর core-এ পাঠানো: আধুনিক network card বা NVMe SSD-তে অনেক queue থাকে, প্রতিটির একটি MSI-X vector, যার ঠিকানা আলাদা core-এর দিকে। তাই queue ৩-এর কাজ core ৩-এ, যেখানে তার ডেটা cache-এ আছে। Linux-এ কোন IRQ কোন core-এ যাবে, তা /proc/irq/<n>/smp_affinity দিয়ে দেখা ও বদলানো যায় — এটিই IRQ affinity. Network card packet-এর header-এর hash দিয়ে queue বাছে — সাধারণত RSS (receive side scaling) নামে।
• ক্রমের নিশ্চয়তা: PCIe-র নিয়মে একটি posted write আগের posted write-কে ডিঙাতে পারে না (relaxed ordering চালু না করলে)। যন্ত্র আগে ডেটা DMA করে, তারপর MSI লেখে — তাই interrupt পৌঁছানোর সময় ডেটাও মেমরিতে আছে। আলাদা তারের interrupt-এ এই নিশ্চয়তা ছিল না।

MSI-র আচরণ edge-এর মতো: একটি write একটি ঘটনা। তাই level-triggered লাইনের storm-এর সমস্যা নেই, কিন্তু driver-কে নিশ্চিত হতে হয় handler-এর শেষে নতুন কাজ জমে আছে কি না।

৪ · DMA — CPU-কে কুলির কাজ থেকে মুক্তি

Interrupt সমস্যার অর্ধেক সমাধান করে: CPU-কে আর অপেক্ষায় দাঁড়িয়ে থাকতে হয় না। কিন্তু ডেটা সরাবে কে? Programmed I/O-তে (PIO) CPU নিজেই প্রতিটি word যন্ত্রের data register থেকে load করে RAM-এ store করে। যন্ত্রের register uncached আর bus-এর ওপারে, তাই প্রতিটি load-এ CPU দীর্ঘ সময় (PCIe-তে কয়েকশো ns, এমনকি এক µs-এর কাছাকাছিও হতে পারে) থেমে থাকে। একটি দ্রুত SSD বা network card-এর ডেটা এভাবে সরালে CPU কার্যত কুলির কাজ করছে।

DMA (Direct Memory Access)-এ CPU শুধু কাজটি বুঝিয়ে দেয় — কোথা থেকে, কোথায়, কত বাইট — আর যন্ত্র (বা একটি DMA engine) নিজেই মেমরিতে পড়ে-লেখে। শেষ হলে একটি interrupt. CPU-র খরচ তাই transfer-এর আকারের ওপর প্রায় নির্ভর করে না: একটি নির্দিষ্ট setup খরচ আর একটি completion খরচ।

// Programmed I/O (CPU copies every word) vs DMA (CPU only sets up and takes one interrupt)
// All costs are ASSUMPTIONS for a teaching example, not measurements of a real chip
const F = 2e9;            // CPU clock: 2 GHz
const WORD = 8;           // bytes moved per load/store pair in programmed I/O
const CPW = 50;           // cycles per word: uncached read of the device data register + store to RAM
const SETUP = 2000;       // DMA: driver fills a descriptor and writes the doorbell register
const DONE = 4000;        // DMA: completion interrupt + handler bookkeeping
const pioCycles = bytes => (bytes / WORD) * CPW;
const dmaCycles = () => SETUP + DONE;     // independent of the transfer size
const breakEven = (SETUP + DONE) * WORD / CPW;
console.log(`break-even size: ${breakEven} bytes (smaller transfers are cheaper with programmed I/O)`);
console.log("\nCPU cycles for ONE transfer:");
console.log("    size |      PIO |  DMA | winner");
for (const s of [64, 512, 960, 4096, 65536]) {
  const p = pioCycles(s), d = dmaCycles();
  console.log(String(s).padStart(8) + " |" + String(p).padStart(9) + " | " + d + " | " +
    (p < d ? "PIO" : p > d ? "DMA" : "tie"));
}
console.log("\nShare of one 2 GHz core at a steady device rate:");
console.log("   rate MB/s  block |  PIO CPU%  |  DMA CPU%");
for (const [mbps, block] of [[100, 4096], [100, 65536], [1000, 4096], [1000, 65536]]) {
  const bytesPerS = mbps * 1e6;
  const pio = 100 * pioCycles(bytesPerS) / F;
  const dma = 100 * (bytesPerS / block) * dmaCycles() / F;
  console.log(String(mbps).padStart(11) + String(block).padStart(7) + " |" +
    (pio.toFixed(2) + (pio > 100 ? " (!)" : "")).padStart(11) + " |" + dma.toFixed(2).padStart(9));
}

break-even size: 960 bytes (smaller transfers are cheaper with programmed I/O)

CPU cycles for ONE transfer:
    size |      PIO |  DMA | winner
      64 |      400 | 6000 | PIO
     512 |     3200 | 6000 | PIO
     960 |     6000 | 6000 | tie
    4096 |    25600 | 6000 | DMA
   65536 |   409600 | 6000 | DMA

Share of one 2 GHz core at a steady device rate:
   rate MB/s  block |  PIO CPU%  |  DMA CPU%
        100   4096 |      31.25 |     7.32
        100  65536 |      31.25 |     0.46
       1000   4096 | 312.50 (!) |    73.24
       1000  65536 | 312.50 (!) |     4.58

DMA controller আর bus mastering

পুরোনো PC আর বহু microcontroller-এ একটি আলাদা DMA controller থাকে (IBM PC-তে Intel 8237, ৪টি channel) — যন্ত্র আর মেমরির মাঝে এই তৃতীয় পক্ষ ডেটা সরায়। আধুনিক PCIe যন্ত্রের নিজের DMA engine থাকে, যা নিজেই bus-এ memory read/write শুরু করে — একে বলে bus mastering. দুই ক্ষেত্রেই মেমরির bandwidth CPU আর যন্ত্র ভাগ করে; ভারী DMA-র সময় CPU-র cache miss একটু বেশি অপেক্ষা করতে পারে — পুরোনো বইয়ে একে cycle stealing বলা হয়। DMA “বিনামূল্যে” নয়, শুধু CPU-র instruction খরচ ছাড়া।

একটি DMA transfer, ধাপে ধাপে

1. Buffer প্রস্তুত: driver মেমরিতে একটি buffer নেয় আর যন্ত্রের বোঝার মতো ঠিকানা (physical বা IOMMU-র ঠিকানা, অংশ ৭) বের করে; non-coherent প্ল্যাটফর্মে cache সামলায় (অংশ ৬)।
2. কাজ বুঝিয়ে দেওয়া: উৎস, গন্তব্য, দৈর্ঘ্য, দিক লেখে — সরল যন্ত্রে সরাসরি register-এ, আধুনিক যন্ত্রে একটি descriptor-এ।
3. শুরু: একটি MMIO write — প্রায়ই একটি doorbell register-এ — যন্ত্রকে বলে “নতুন কাজ আছে”।
4. Transfer: যন্ত্র bus-এ একের পর এক memory read বা write পাঠায়; CPU এ সময় অন্য কাজ করে।
5. শেষের খবর: যন্ত্র descriptor-এ status লেখে, তারপর interrupt (MSI) দেয় — বা driver poll করে।
6. গুছিয়ে নেওয়া: driver status দেখে, cache আর ম্যাপিং ঠিক করে, ডেটা উপরের স্তরে দেয়।

৫ · Descriptor ring — যন্ত্র আর driver-এর ভাগাভাগি করা খাতা

প্রতিটি transfer-এর জন্য register লিখে, শেষ হওয়ার অপেক্ষা করে, তারপর পরেরটি দেওয়া — এতে যন্ত্র প্রতিবার অলস বসে থাকে আর CPU প্রতিবার ডাক পায়। সমাধান: মেমরিতে একটি descriptor ring — N ঘরের একটি circular buffer, যার প্রতিটি ঘরে একটি descriptor: buffer-এর ঠিকানা, দৈর্ঘ্য, কিছু flag (যেমন “packet-এর শেষ”), আর একটি status অংশ যেখানে যন্ত্র “শেষ হয়েছে” (অনেক NIC-এ DD = descriptor done) লেখে। Driver অনেকগুলো কাজ একবারে জমা দিতে পারে, আর যন্ত্র নিজের গতিতে একটার পর একটা করে যায়।

দুটি সূচক (index) এই নিয়ম রাখে। এই পর্বে Intel-এর পুরোনো e1000-ধাঁচের NIC-এর নিয়ম ধরছি (অন্য যন্ত্রে নাম ও দায়িত্ব আলাদা হতে পারে): tail বাড়ায় producer — যে নতুন কাজ দেয়; head বাড়ায় consumer — যে কাজ শেষ করে। Transmit ring-এ driver producer, যন্ত্র consumer. প্রতিটি সূচক N-এ পৌঁছে ০-তে ফেরে (mod N).

নিচের simulator একটি ৮ ঘরের transmit ring-এ driver আর যন্ত্রকে পালা করে চালায়। H আর T head আর tail-এর অবস্থান, . খালি ঘর, ছোট হাতের অক্ষর যন্ত্রের কাছে জমা থাকা packet:

// A transmit descriptor ring: the driver (producer) advances TAIL, the device (consumer) advances HEAD
// Convention used here: empty when head == tail, full when (tail + 1) % N == head (one slot kept empty)
const N = 8;
const ring = new Array(N).fill(".");      // "." = free slot, letter = descriptor owned by the device
let head = 0, tail = 0, next = 0;         // next = name of the next packet (a, b, c, ...)
const count = () => (tail - head + N) % N;
function show(what) {
  const marks = ring.map((s, i) => (i === head ? "H" : " ") + (i === tail ? "T" : " ") + s).join(" ");
  const st = count() === 0 ? "EMPTY" : count() === N - 1 ? "FULL" : `${count()} in use`;
  console.log(what.padEnd(22) + marks + "   h=" + head + " t=" + tail + "  " + st);
}
function post(k) {                        // driver writes k descriptors, then rings the doorbell once
  let done = 0;
  while (done < k && (tail + 1) % N !== head) {
    ring[tail] = String.fromCharCode(97 + next++); tail = (tail + 1) % N; done++;
  }
  show(`driver posts ${done}/${k}` + (done < k ? " !" : ""));
}
function device(k) {                      // device sends k packets (or fewer if the ring is empty)
  let done = 0;
  while (done < k && head !== tail) { ring[head] = "."; head = (head + 1) % N; done++; }
  show(`device sends ${done}/${k}`);
}
show("start");
post(3); device(2); post(5); post(2); device(4); post(4); device(9);

start                 HT.   .   .   .   .   .   .   .   h=0 t=0  EMPTY
driver posts 3/3      H a   b   c  T.   .   .   .   .   h=0 t=3  3 in use
device sends 2/2        .   . H c  T.   .   .   .   .   h=2 t=3  1 in use
driver posts 5/5       T.   . H c   d   e   f   g   h   h=2 t=0  6 in use
driver posts 1/2 !      i  T. H c   d   e   f   g   h   h=2 t=1  FULL
device sends 4/4        i  T.   .   .   .   . H g   h   h=6 t=1  3 in use
driver posts 4/4        i   j   k   l   m  T. H g   h   h=6 t=5  FULL
device sends 7/9        .   .   .   .   . HT.   .   .   h=5 t=5  EMPTY

এবার receive দিক, যেখানে যন্ত্র producer: driver আগে থেকে খালি buffer-ওয়ালা descriptor দিয়ে রাখে, packet এলে যন্ত্র DMA করে ভরে দেয়। নিচের stepper একটি ৪ ঘরের receive ring দেখায়। এখানে নিয়ম: head থেকে tail − ১ পর্যন্ত ঘরগুলো যন্ত্রের, যন্ত্র head বাড়ায়, driver tail বাড়িয়ে নতুন খালি buffer দেয়:

1driver: buf b0,b1,b2 → ঘর 0,1,2; tail = 32NIC: packet P1 এল; DMA read descriptor 03NIC: DMA write P1 → b04NIC: descriptor 0-তে len, DD = 1; head = 15NIC: P2 → b1, DD; head = 2; MSI-X6driver: 0,1 তুলল; b4,b5 → ঘর 3,0; tail = 1

Scatter-gather — টুকরো টুকরো মেমরি, এক transfer

একটি packet-এর header এক জায়গায় আর data অন্য জায়গায় থাকতে পারে; virtual memory-তে টানা ১ MiB physical memory-তে ২৫৬টি আলাদা ৪ KiB page-এ ছড়ানো থাকতে পারে। আগে সব এক টানা buffer-এ কপি করলে DMA-র লাভ নষ্ট। Scatter-gather DMA-তে driver (ঠিকানা, দৈর্ঘ্য)-এর একটি তালিকা দেয়, আর যন্ত্র টুকরোগুলো একটানা পড়ে (gather) বা ছড়িয়ে লেখে (scatter); NVMe-তে এর জন্য PRP তালিকা আর SGL আছে। পর্ব ৪২-এর vector gather-scatter নামে কাছাকাছি, কিন্তু সেটি CPU-র instruction.

৬ · DMA আর cache — পুরোনো তথ্যের ফাঁদ

পর্ব ৪৭-এ দেখেছেন, write-back cache-এ store শুধু cache-এ লেখা হয়, line dirty থাকে, RAM-এ যায় পরে। আর DMA কথা বলে মেমরির সাথে, CPU-র cache-এর সাথে নয় — যদি না hardware বিশেষ ব্যবস্থা রাখে। ফলে দুই দিকেই coherence-এর সমস্যা:

• CPU → যন্ত্র (transmit): CPU buffer-এ নতুন packet লিখল, কিন্তু নতুন মান এখনো cache-এর dirty line-এ। যন্ত্র RAM থেকে পড়ে পুরোনো ডেটা পাঠাল।
• যন্ত্র → CPU (receive): যন্ত্র RAM-এ নতুন ডেটা লিখল, কিন্তু CPU-র cache-এ সেই ঠিকানার পুরোনো একটি কপি আছে। CPU পড়ল — cache hit — পুরোনো মান।

সমাধান দুই রকম। Hardware-coherent DMA: যন্ত্রের প্রতিটি memory access cache-কে snoop করে — যন্ত্রের read dirty line থেকে নতুন মান পায়, যন্ত্রের write cache-এর পুরোনো কপি বাতিল করে। x86-এর PC আর server-এ PCIe DMA সাধারণত এভাবেই coherent; পর্ব ৫৩-এর multicore coherence-এর মতোই ধারণা, শুধু একটি “core” এখানে যন্ত্র। Software-managed (non-coherent) DMA: বহু embedded ARM SoC আর কিছু RISC-V chip-এ যন্ত্রের পথ cache এড়িয়ে যায় (area আর power বাঁচাতে)। তখন driver-কে যন্ত্র পড়ার আগে clean (dirty line RAM-এ লেখা) আর CPU পড়ার আগে invalidate (কপি বাতিল) করতে হয় — ARM64-এ DC CVAC, DC IVAC-এর মতো instruction, RISC-V-এর Zicbom extension-এ cbo.clean, cbo.inval, cbo.flush. Linux driver সাধারণত এগুলো নিজে লেখে না; DMA API (dma_map_single, dma_sync_single_for_cpu ইত্যাদি) প্ল্যাটফর্ম অনুযায়ী দরকার হলে কাজটি করে। কোন SoC কোন পথে, তা তার datasheet-এর বিষয়।

1CPU: buf_tx-এ নতুন packet লেখা (store)2✗ সরাসরি DMA শুরু → যন্ত্র RAM পড়ে3✓ clean(buf_tx)  // dirty line → RAM4DMA শুরু → যন্ত্র RAM পড়ে5যন্ত্র: DMA write → buf_rx; CPU পড়ে6✓ invalidate(buf_rx); CPU আবার পড়ে

৭ · DMA আর virtual memory — ঠিকানা, pinned page আর IOMMU

পর্ব ৫০-এ দেখেছেন, প্রোগ্রাম কাজ করে virtual address-এ, আর MMU প্রতিটি access-কে page table দিয়ে physical address-এ অনুবাদ করে। কিন্তু যন্ত্রের DMA পথে CPU-র MMU নেই। যন্ত্র বোঝে শুধু bus-এর ঠিকানা — IOMMU না থাকলে সেটি সরাসরি physical address. এর তিনটি ফল:

1. টুকরো ঠিকানা: virtual-এ টানা buffer physical-এ ছড়ানো page — তাই scatter-gather (অংশ ৫)।
2. Page সরানো যাবে না: DMA চলার মাঝে OS যদি page-টি swap করে বা অন্য জায়গায় সরায়, যন্ত্র পুরোনো physical ঠিকানায় লিখে অন্য কারও ডেটা নষ্ট করবে। তাই DMA-র buffer-কে কাজ শেষ না হওয়া পর্যন্ত pin করে রাখা হয় — OS প্রতিশ্রুতি দেয় এটি সরাবে না।
3. সব ঠিকানা পৌঁছায় না: পুরোনো বা সস্তা কোনো যন্ত্র হয়তো শুধু ৩২-বিটের ঠিকানা (প্রথম ৪ GiB) বোঝে। Buffer তার ওপরে থাকলে OS নিচের মেমরিতে একটি bounce buffer রাখে আর CPU দিয়ে কপি করে — Linux-এ swiotlb এমন একটি ব্যবস্থা। কাজ হয়, কিন্তু DMA-র লাভের কিছুটা যায়।

IOMMU — যন্ত্রের জন্য MMU

IOMMU (Intel-এ VT-d, AMD-তে AMD-Vi, ARM-এ SMMU নামে পরিচিত) যন্ত্র আর মেমরির মাঝে বসে প্রতিটি DMA ঠিকানা অনুবাদ করে — পর্ব ৫০-এর page walk আর TLB-র মতোই, এখানে IOTLB. প্রতিটি যন্ত্রের (PCIe-তে তার bus/device/function পরিচয় দিয়ে চেনা) নিজস্ব page table থাকতে পারে। লাভ চারটি: (১) ছড়ানো physical page-কে যন্ত্রের চোখে একটানা দেখানো; (২) ৩২-বিটের যন্ত্রকে ওপরের মেমরিতে পৌঁছানো, bounce buffer ছাড়াই; (৩) virtual machine-কে একটি আসল যন্ত্র সরাসরি দেওয়া (device passthrough) — অতিথির “physical” ঠিকানা IOMMU আসল ঠিকানায় বদলায়; আর (৪) সবচেয়ে জরুরি — সুরক্ষা: যে ঠিকানা table-এ নেই, সেখানে DMA আটকে যায় আর একটি fault লেখা হয়। খরচও আছে: প্রতিটি map/unmap-এ table বদলানো আর IOTLB মোছা, যা উচ্চ হারের I/O-তে চোখে পড়ার মতো হতে পারে — তাই কিছু সিস্টেম ম্যাপিং দীর্ঘ সময় রেখে দেয় বা দলবদ্ধভাবে মোছে, সুরক্ষার সাথে একটু আপস করে।

Zero-copy — একটি কপিও কম

সাধারণ network পাঠানোয় ডেটা আগে CPU দিয়ে অ্যাপ্লিকেশনের buffer থেকে kernel-এর buffer-এ কপি হয়, তারপর DMA. Zero-copy-র ধারণা: কপি বাদ দিয়ে যন্ত্র সরাসরি ব্যবহারকারীর pinned page বা page cache থেকে DMA করুক — Linux-এর sendfile বা io_uring-এর নিবন্ধিত buffer এই দিকের উদাহরণ, প্রতিটির নিজস্ব শর্ত আছে। বড় transfer-এ লাভ স্পষ্ট; কিন্তু pin আর ম্যাপিংয়ের নিজস্ব খরচ আছে, তাই ছোট packet-এ সাধারণ কপিই প্রায়ই দ্রুত — অংশ ৪-এর break-even যুক্তি এখানেও খাটে।

৮ · শুরু থেকে শেষ — একটি network packet-এর যাত্রা

এবার সবগুলো টুকরো জোড়া দিই। Linux-এর মতো একটি সিস্টেমে, একটি আধুনিক multi-queue network card-এ একটি packet পৌঁছালে মোটামুটি এভাবে চলে (খুঁটিনাটি driver আর kernel version অনুযায়ী বদলায়):

1. 📨তার থেকে NICRSS hash → queue 3physical layer, MAC
3. 🚚DMAbuffer + DDCPU-র কাজ নেই
5. 🔔MSI-Xvector → core 3coalescing-এর পর
7. ⚡HandlerNAPI scheduleছোট, দ্রুত
9. 📦Softirqpoll, IP, TCPতারপর অ্যাপ্লিকেশন

1. আগে থেকে প্রস্তুত: driver প্রতিটি receive queue-র ring-এ খালি buffer দিয়ে রেখেছে (অংশ ৫-এর stepper-এর প্রথম ধাপ)।
2. Queue বাছাই: NIC frame গ্রহণ করে header-এর hash থেকে ঠিক করে এটি queue ৩-এর — একই সংযোগের সব packet একই queue-তে, তাই একই core-এ।
3. DMA: queue ৩-এর পরের descriptor পড়ে, packet buffer-এ লেখে, তারপর descriptor-এ দৈর্ঘ্য আর DD লেখে। Coherent প্ল্যাটফর্মে cache নিজে হালনাগাদ হয়।
4. Interrupt: moderation-এর শর্ত পূর্ণ হলে NIC queue ৩-এর MSI-X vector-এর ঠিকানায় একটি write পাঠায়; interrupt controller সেটি core ৩-এ পৌঁছে দেয়; core ৩-এ পর্ব ৩৮-এর trap.
5. Hard interrupt handler (top half): খুব ছোট — queue ৩-এর interrupt বন্ধ করে, NAPI poll নির্ধারণ করে আর network-এর receive softirq-এর অনুরোধ তোলে।
6. Softirq (bottom half): interrupt চালু অবস্থায় NAPI poll বাজেট পর্যন্ত DD-ওয়ালা descriptor তোলে, প্রতিটি packet-এর জন্য kernel-এর কাঠামো (Linux-এ sk_buff) বানায়, ring-এ নতুন buffer দিয়ে tail doorbell লেখে, আর packet IP ও TCP স্তরে পাঠায়। চাপ খুব বেশি হলে এই কাজ ksoftirqd নামের kernel thread-এ সরে যায়।
7. অ্যাপ্লিকেশন: TCP ডেটা socket-এর queue-তে রাখে আর অপেক্ষারত প্রসেসকে জাগায়; প্রসেস recv() করলে ডেটা kernel থেকে তার buffer-এ কপি হয় — পুরো যাত্রায় প্রায়ই এটিই একমাত্র CPU-কপি।
8. শান্ত হলে: ring খালি হলে NAPI queue ৩-এর interrupt আবার চালু করে — পরের packet আবার প্রথম ধাপ থেকে।

লক্ষ করুন কোন ধাপে CPU-র কত কাজ: বাইট সরানো যন্ত্রের, ডাকার খরচ প্রতি দল-এ একবার, আর CPU-র আসল সময় যায় protocol-এর কাজে। OS-এর দিক থেকে driver, buffering আর read()-এর জীবনচক্র আছে Operating Systems কোর্সের I/O সিস্টেম পর্বে; frame কীভাবে তারে আসে, তা Computer Networks কোর্সের Ethernet আর switching পর্বে।

৯ · AI-এর যুগে — interrupt আর DMA-র প্রশ্নে AI, আর যাচাইয়ের অভ্যাস

Driver বা firmware লেখায় AI কাজের, কিন্তু এই বিষয়ে তার ভুলগুলো প্রায়ই নীরব: কোড compile হয়, চলে, শুধু মাঝেমধ্যে ভুল ডেটা যায়। পরিচিত ধরনগুলো:

AI-এর দেওয়া driver-কোড বা হিসাব হাতে পেলে — চেকলিস্ট

• Ring-এর head/tail কে বাড়ায় আর full/empty-র শর্ত — যন্ত্রের নিজের spec থেকে মিলিয়েছি, আর wrap-around হাতে একবার trace করেছি
• প্ল্যাটফর্মের DMA coherent কি না জেনেছি; non-coherent হলে clean/invalidate-এর ক্রম আর buffer-এর cache-line alignment দেখেছি
• Level-triggered লাইনে যন্ত্রের কারণ মোছার পরেই complete/EOI লেখা হচ্ছে, আর handler-এর শেষে নতুন কাজ আবার দেখা হচ্ছে
• DMA ঠিকানা virtual নয় — DMA API বা IOMMU-র দেওয়া ঠিকানা; buffer pinned
• CPU-শতাংশ আর latency-র প্রতিটি সংখ্যা একক লিখে নিজে বা script দিয়ে আবার হিসাব করেছি
• যন্ত্রের latency বা cycle-এর দাবি datasheet বা আসল মাপ দিয়ে যাচাই করেছি, অনুমানে নয়