Industry Insights

Under 700 Nanoseconds per Command: Core Partitioning and L2P Sharding in the Dispatch Engine

작성: JH Semiconductorcommand dispatch engine / multi-core controller / L2P sharding

Working backwards from 1,500 KIOPS to a per-command cycle budget: why the data path must be hardware, how queues bind to cores, and why mapping-table sharding gates multi-core scaling.

Start with the Cycle Budget

J750 and J770 target 1,500 KIOPS on 4KB random reads. At a front-end clock in the GHz range that leaves under 700 nanoseconds of average processing time per command — and that budget must contain submission-queue fetch, command parse, L2P lookup, NAND read issue, DMA of the payload after LDPC decode, and completion-queue writeback. Routing any one of those through a general-purpose software path consumes the whole budget. Hence the basic division of labour: put the data path in hardware and leave the CPU cores to control flow and exceptions.

Two Ways to Split the Cores

Multi-core controllers are partitioned either by function or by queue. By function: some cores handle foreground I/O while others own garbage collection, wear levelling, media scrubbing and key management. By queue: each core owns a set of NVMe submission queues and processes their commands end to end. The first isolates background jitter from the foreground path; the second removes lock contention on shared structures by construction. Real designs combine them — foreground cores sharded by queue, background work concentrated on dedicated cores, with lock-free ring buffers carrying relocation and reclaim requests between the two.

The Mapping Table Is the Scaling Limit

L2P is the one large structure every foreground core touches. Protect it with a global lock and throughput falls as core count rises. The workable approach is to shard the table by LBA range and align queue-to-core binding with those shards, so the overwhelming majority of lookups hit a shard private to the executing core; cross-shard updates travel as messages rather than direct memory access. DRAM bandwidth belongs in the same budget, since every random read costs at least one mapping-entry fetch.

Where the Accelerator Boundary Sits

LDPC decode, AES, T10 DIF/DIX insertion and verification, and DMA descriptor handling all live on the hardware path. The CPU intervenes only when decode fails and soft-decision retry is required, or when a protection-information mismatch has to be reported. That split — fast path entirely in hardware, slow path into firmware — is what makes end-to-end data protection viable as an always-on feature at near-zero performance cost.

From External Controller to JHC400

Current Gen4 products pair an external enterprise controller with in-house firmware, so dispatch behaviour is shaped mainly through firmware-level queue binding and background quota policy. As the roadmap moves to the in-house JHC400 controller platform, this partitioning can be pushed down into a hardware scheduler and inter-core interaction overhead reduced. The design remains at the definition stage.

키워드
command dispatch enginemulti-core controllerL2P shardinglock-free queueLDPCJHC400firmware architecture