{"id":"bfa81398-c689-47ae-9a64-a803ee0c8a7e","arxiv_id":"2506.06769","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"The paper presents DockerSSD, a computational SSD that executes Docker containers on firmware via custom NVMe-based Ethernet and virtualized system calls, with simulated and FPGA-prototype evaluations showing speedups for I/O workloads and distributed LLM inference.","lead":"DockerSSD runs containerized data-processing applications directly on SSD firmware, using Ethernet-over-NVMe and a lightweight container runtime. It reports up to 2.0x speedups on I/O workloads and 7.9x faster distributed LLM inference by keeping KV caches near flash.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 7.9x distributed-LLM-inference speedup rests on an unvalidated analytical KV-cache model and a Linux-swap baseline; the model's 'O(n^2)-sized KV cache' statement indicates a scaling error, so the headline LLM claim is not yet supported.","rationale":"The core DockerSSD design has independent support: a real FPGA prototype, cross-validation between gem5 and RTL, and a set of I/O benchmark results that are presented in quantitative detail. I do not question the authors' integrity or the value of the containerized-ISP concept. The concern is specifically about the LLM inference evaluation, which is the main new contribution of this extended version. The paper replaces the LLM simulator's missing KV-cache support with an analytical model, but provides no calibration against either the prototype or any real LLM serving system. The baseline is Linux swap, which is a narrow and historically slow way to extend memory; the D-Cache advantage is computed entirely within the model. A concrete red flag is the claim that a KV cache is O(n^2)-sized: standard KV caches use O(n) storage per layer, while attention computation and traffic are O(n^2) over a sequence. If the model uses O(n^2) storage per layer, the memory-time scaling is wrong and the speedup curves are unreliable: the 421x and 4.6Kx improvements attributed to cache presence are suspiciously large and likely reflect modeling assumptions rather than measured behavior. The reader's weakest assumption about the 133-syscall subset is legitimate for the 'run arbitrary algorithms without modification' claim, and I partially agree with that concern, but the paper's central quantitative claim would not be affected as strongly by a syscall-coverage gap. I therefore prioritize the LLM model as the load-bearing check. The verdict remains CONDITIONAL: the core feasibility claim has real evidence, but the headline LLM speedup requires validation with a corrected model and a realistic baseline, and the artifact should be released to allow independent reproduction.","tokens_in":18067,"tokens_out":8181,"duration_ms":90216,"concrete_test":"Validate the analytical KV-cache model against a real system. Run a small transformer (e.g., 1-3B parameters) on one host with KV cache in DRAM (H-NoCache-like), with KV cache on NVMe via Linux swap (H-Cache-like), and on a DockerSSD-class embedded CPU with flash-local KV cache (D-Cache-like), measuring per-token latency for sequence lengths 1K-32K. Feed these measurements into the Calculon simulator or directly into the paper's model and reproduce Fig. 12b/13a; if the simulated H-Cache/D-Cache ratio deviates from measured by more than, say, 20%, or if using the standard O(n) KV-cache capacity removes the 7.9x gap, the headline LLM claim needs to be revised.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline new result is that a DockerSSD storage pool improves distributed LLM inference by 7.9x over a host configuration (Section VIII, Figs. 12-13). That result is produced by a simulator into which the authors injected their own analytical KV-cache model, and the model is not validated against the prototype, a real LLM, or even a real swap-based host. The baseline H-Cache uses Linux swap to place the KV cache on a 400GB SSD, while D-Cache treats flash as local memory; the entire 7.9x gap is therefore a modeling artifact unless the model's memory-time equations are correct. There is evidence they may not be: the paper states that a KV cache is 'O(n^2)-sized' and reduces computational complexity to O(n). Standard KV caches are O(n) in storage per layer; what grows as O(n^2) is accumulated attention traffic over an n-token sequence. If the model attributes O(n^2) storage/bandwidth to the KV cache instead of O(n) capacity, the relative benefit of eliminating swap will be exaggerated and the crossover points in Fig. 13 (256 and 1,024 tokens) are suspect. Because the 7.9x claim is a central contribution of this extended version, this unvalidated analytical dependence is the most load-bearing weakness. The syscall-subset concern is real, but it does not, by itself, invalidate the quantitative LLM result; this one does if the model is wrong.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes DockerSSD, an in-storage processing (ISP) model that uses OS-level virtualization (containers) inside SSDs, together with two key mechanisms: Ether-oN, a kernel driver that overlays Ethernet networking on NVMe vendor-specific commands, and Virtual-FW, a lightweight firmware stack that emulates a subset of system calls and supplies a minimal Docker environment. The authors also describe a Lambda filesystem (λFS) for secure backend flash management and a disaggregated computing-enabled storage pool. The paper claims that DockerSSD outperforms a host-only system and prior programmable ISP models (P.ISP-R/V, D-Naive, D-FullOS) by up to 1.6–1.8× on I/O-intensive workloads, and that a pool of DockerSSDs speeds up distributed LLM inference by 7.9× over a host-based swapped-memory configuration. The LLM result is obtained from a simulator (Calculon) extended with the authors' analytical KV-cache model, while the other results are from a combination of an FPGA prototype and gem5/SimpleSSD simulations.","tokens_in":18388,"tokens_out":5408,"duration_ms":59606,"significance":"If the results hold, the containerized-ISP concept could substantially lower the barrier to ISP adoption by removing vendor-specific APIs and source-level modifications, and the disaggregated storage-pool approach could have broad applicability to distributed data services. The paper's strengths include a real FPGA prototype with six RISC-V cores, an open-hardware NVMe controller integration, a clear separation of the ISP-compute path from the block-I/O path, and the demonstration that a lightweight firmware stack can reduce binary size by over 80×. The use of established simulators (gem5, SimpleSSD) cross-validated against RTL is also a positive methodological feature. However, the headline LLM result depends on an unvalidated analytical model with a questionable complexity claim, and the general adaptability claim is only tested on a limited set of workloads.","major_comments":[{"comment":"The text states: 'Using an O(n^2)-sized KV cache allows reuse of previously computed KV vectors, reducing computational complexity to O(n).' This is a scaling error. Standard KV cache size is O(n) per layer (2 * n * d_model * num_layers), while O(n^2) is the complexity of pairwise attention when no cache is used; the cache does not reduce total sequence processing to O(n) because attention still performs O(n^2) dot products across the sequence. If the analytical model added to the Calculon simulator uses an O(n^2) cache size, the memory footprint and swap traffic for H-Cache would be overestimated, making the 7.9× D-Cache-versus-H-Cache speedup and the crossover points at 256 and 1,024 tokens artifacts of the model rather than system measurements. The paper provides no validation of this analytical KV-cache model against real flash devices, the FPGA prototype, or a real LLM inference workload. This is load-bearing for the central extended-version contribution and must be corrected and justified.","section":"Section VIII, Fig. 13"},{"comment":"The paper claims users can 'run algorithms without modifying them for vendor-specific runtimes' and that DockerSSD enables 'diverse data processing near the flash.' This claim rests on the sufficiency of the 133 emulated system calls (65 thread, 43 I/O, 25 network) and the 11 supported Docker commands. The evaluation uses only six benchmarks whose system-call footprints (Table 2) are not shown to be representative. Common syscalls such as ioctl, select/poll, socketpair, sendmsg, recvmsg, and mmap variants are not listed in Table 1a; if any containerized workload needs an unemulated call, execution will fail, and no fallback mechanism is described. The paper should either demonstrate that the emulated subset covers the tested workloads' full call paths or add an explicit compatibility statement, because this limits the generality of the 'run without modification' contribution.","section":"Section V, Table 1a"},{"comment":"The LLM evaluation is entirely inside a simulator, and the newly added KV-cache analytical model is not cross-validated with either the prototype or a real inference system. The simulator cross-validation cited in the Evaluation section covers the flash backend and RTL, not the analytical model. In addition, the H-Cache baseline uses Linux swap to place the KV cache on a 400GB SSD, which is a page-based mechanism; a more realistic host-side flash-backed KV cache (e.g., paged attention with SSD offload) could reduce the gap to D-Cache substantially. The reported 421× (H-Cache vs. H-NoCache) and 4.6K× (D-Cache vs. D-NoCache) gains are not sanity-checked against known attention-flop counts or memory-bandwidth limits. The authors need to provide the analytical model's equations, validate them against either the prototype or published LLM inference profiles, and compare against a stronger host-side baseline before the 7.9× claim can be accepted.","section":"Section VIII, Methodology"}],"minor_comments":[{"comment":"The abstract states 'up to 2.0× better performance for I/O-intensive workloads' without identifying the baseline; clarify whether this is versus Host, P.ISP-R/V, or D-FullOS.","section":"Abstract"},{"comment":"The phrase 'reduced the Linux binary size by 83.4×' is ambiguous; a reduction by 83.4× means the new size is 1/83.4 of the original, which is likely intended, but the phrasing should be made explicit.","section":"Evaluation, Figure 10"},{"comment":"The inode-lock protocol is described at a high level but does not specify how the host VFS invalidates a stale inode when the ISP-container modifies a file; a concrete sequence of Ether-oN packets and lock calls would improve reproducibility.","section":"Section IV, Backend Media Management"},{"comment":"The paper mixes results from the FPGA prototype and the gem5/SimpleSSD simulator without consistently labeling each figure; for example, Figure 3 has no caption or environment description, and Figure 11 does not state which configuration was used for the P.ISP-Latency breakdown. Please add explicit source labels to each figure.","section":"Section VII, Evaluation"},{"comment":"The breakdown labels 'Compute' and 'Memory' are not defined in the caption; state whether 'Memory' includes flash access, swap, or DRAM bandwidth and how these times are measured in the simulator.","section":"Section VIII, Fig. 12b"}],"recommendation":"major_revision","confidential_remarks":"The paper is an extended version of earlier IEEE Micro/HPCA publications and the authors have a strong record in computational storage. The core containerized-ISP idea is interesting and the prototype work is credible. However, the extended LLM result is not yet supported: the analytical KV-cache model is unvalidated and the O(n^2) complexity statement suggests a possibly incorrect scaling assumption. This is a load-bearing issue for the 7.9× claim, which should be either re-derived with a validated model or removed from the headline. The syscall-subset generality issue is also worth addressing in the revision. The manuscript fits the journal scope, but it needs a major revision before acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is an extended version of the authors' HPCA DockerSSD paper, and the honest new contribution is the computing-enabled storage pool for distributed LLM inference. The container-on-firmware idea, Ether-oN, Virtual-FW, and the 2.0x I/O speedup are prior work (refs 13,14) re-presented cleanly. That is fine as an arXiv extended version, but reviewers should not credit those pieces as new.\n\nWhat the paper does well: the FPGA prototype is real evidence, the workload coverage is decent, and the system-call emulation table is useful. The disaggregation story—DockerSSD as an independent IP-addressable node that can form a pool—is a plausible and genuinely useful direction. I also appreciate that they compare against P.ISP and D-FullOS rather than only against a host.\n\nNow the soft spots, in proportion. The 7.9x LLM speedup is the centerpiece of the extended version, and it is built on an analytical KV-cache model injected into an existing simulator (Calculon). That model is not validated against the prototype, against a real LLM, or even against real flash-backed swap. The baseline H-Cache uses Linux swap to put KV cache on a 400GB SSD, while D-Cache treats flash as local memory. The entire gap is therefore a modeling artifact unless the model's memory-time equations are right.\n\nThe stress-test note flags a specific red flag: the paper says a KV cache is O(n^2)-sized and reduces compute to O(n). Standard KV caches are O(n) in storage per layer; what is O(n^2) is accumulated attention traffic. If the model confuses cumulative traffic with resident cache size, the memory-bandwidth advantage of flash-as-local-memory gets exaggerated. I read the relevant paragraph in 'Analysis with varying sequence lengths' and the phrasing is loose enough that the model could indeed be built on that error. The crossover points in Fig. 13 (256 and 1,024 tokens) are suspiciously early for flash to beat DRAM-backed host memory. So the 7.9x claim is not supported as presented. This is the load-bearing weakness, and it is a real one.\n\nSecondary but worth noting: the 133-system-call subset and 11 Docker commands are not proven sufficient for general workloads. That matters for the general-adaptability claim, but it is a scope limitation, not a fatal flaw. No code or data is released, which hurts given the analytical model needs checking.\n\nWho is this for: people working on computational SSDs and near-data processing will want to read it. It deserves a serious referee, not a desk reject, provided the reviewer pushes hard on the KV-cache model and asks for validation or a corrected derivation. My recommendation: send it to peer review with a request for the analytical model to be either validated or replaced.\n\nIn short: the I/O story is solid but mostly prior work; the LLM pool story is genuinely new but currently a simulation artifact in waiting. Engage with it, but require the model to be shown correct before believing the 7.9x.","headline":"Solid engineering extension of the authors' own HPCA DockerSSD work; the genuinely new LLM pool result is interesting but rests on an unvalidated analytical KV-cache model, so the 7.9x headline is not yet earned.","tokens_in":18989,"tokens_out":774,"would_cite":false,"duration_ms":10741,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"DockerSSD claims it can run unmodified Docker containers on SSD firmware, speeding distributed LLM inference by 7.9x.","keywords":["in-storage processing","Docker containers","SSD firmware virtualization","NVMe","Ethernet over NVMe","disaggregated storage","LLM inference","KV cache"],"falsifier":"Run an unmodified container that exercises a system call absent from Virtual-FW's emulated set—such as `clone3`, user namespaces, or `io_uring`—with `docker run` against a DockerSSD prototype. If the container fails to start or silently falls back to host execution, the paper's central claim of unmodified container support is false; a simpler check is to trace the system calls of a typical real-world container (e.g., a data-science notebook) and compare them with Table 1a.","tokens_in":17837,"feed_emoji":"⚡","tokens_out":12412,"duration_ms":113993,"temperature":0.7,"pith_summary":"Containerized in-storage processing is the claim that a computational SSD can execute ordinary Docker containers directly on its firmware, without rewriting applications for vendor-specific ISP kernels or APIs. The paper builds this with Virtual-FW, a lightweight firmware stack that emulates 133 system calls and runs a minimal Docker runtime, and Ether-oN, an Ethernet-over-NVMe kernel driver that gives the SSD an IP address and lets the host manage containers with the standard `docker` CLI. The payoff is that any containerized data-processing workload can be offloaded to the drive, and that a set of such drives can be disaggregated into a computing-enabled storage pool that keeps large working sets—notably LLM key-value caches—near the flash. Evaluations on an FPGA prototype and a cycle-accurate simulator report up to 2.0x speedup over a host system and a 7.9x improvement in distributed LLM inference relative to host-based serving with swap. This addresses the paper's five identified ISP challenges: manual implementation, file-layout ignorance, kernel context switching, device reliance, and data vulnerability.","feed_headline":"Docker inside an SSD speeds LLM inference 7.9x","feed_subtitle":"A pool of containerized drives keeps KV caches on flash, beating host memory swapping.","key_machinery":"The load-bearing mechanism is Virtual-FW, a firmware-level OS emulation layer that is the reason containers can run on storage without a full operating system. It replaces the Linux kernel's system-call path with 133 lightweight function wrappers organized into thread, I/O, and network handlers, avoiding context-switch overhead, and it includes mini-docker, a compact implementation of the Docker stack that supports image pull, create, start, stop, restart, kill, rm, logs, ps, and rmi operations. Its counterpart is Ether-oN, a kernel driver that adds transmit and receive NVMe vendor commands (0xE0–0xE1) plus pre-submitted receive commands for asynchronous upcalls, effectively creating a virtual Ethernet link between the host and each SSD over PCIe. Together these let a host manage ISP-containers with the unmodified `docker` CLI, and let a set of DockerSSDs form a disaggregated storage pool whose flash-resident KV caches carry the distributed LLM inference workload.","core_discovery":"The central discovery is that an SSD's firmware can be turned into a container runtime: by emulating just 133 system calls as function wrappers and implementing 11 essential Docker commands in a mini-docker module, Virtual-FW executes unmodified application binaries on the drive's bare-metal cores. Ether-oN adds two vendor-specific NVMe commands (transmit and receive frames) that overlay socket-based Ethernet on PCIe, so each DockerSSD has its own IP address and the host can `docker pull` and `docker run` onto the drive as if it were a networked node. The paper then argues that this makes ISP host-independent and secure: a λFS filesystem partitions NVMe namespaces into a private area for container images and a sharable area coordinated with the host by an inode lock, preventing concurrent modification. In the distributed case, a pool of DockerSSDs runs LLM inference with KV caches stored on flash rather than host DRAM, which the authors show eliminates swap traffic and data copies, giving an average 7.9x improvement over host-based inference with Linux swap.","pith_inferences":["If the coverage assumption holds, the same containerized-ISP design should extend beyond LLM inference to other memory-bound serving workloads, such as vector databases, graph analytics, or large-scale recommendation systems, because the benefit comes from keeping large reusable data structures near flash rather than from anything LLM-specific.","The most direct way to test the paper's central promise is to run a container that uses a syscall outside the 133 emulated set (e.g., `clone3` or user namespaces); if it fails, the 'run without modifying' claim is false.","The Ether-oN mechanism of pre-submitted NVMe receive commands and asynchronous upcalls could serve as a general low-latency data plane for other PCIe devices that need to initiate host communication, not just computational SSDs.","One could probe the performance boundary by varying syscall density and I/O intensity; the paper's own sensitivity analysis suggests compute-bound short-sequence inference stays host-favorable, so the crossover would define where containerized ISP wins."],"forward_implications":["Any container that fits within the emulated 133 system-call set can be offloaded to the SSD without recompilation or vendor-specific APIs, so the programming barrier for in-storage processing becomes a compatibility question rather than an API question.","A host can treat a pool of DockerSSDs as ordinary network-attached compute and storage nodes, enabling disaggregated deployments in which each SSD is an independent unit of scale.","Memory-heavy serving workloads that currently rely on host DRAM with swap, such as LLM inference with KV caching, can move their working set into the storage pool and avoid swap overhead and data movement.","The prototype and simulator results indicate that containerized ISP can outperform programmable-ISP baselines (P.ISP-R/V), a full-OS-in-SSD approach (D-FullOS), and a split-processor approach (D-Naive) by 1.6x, 1.6x, and 1.8x respectively.","For long sequence lengths, the flash-resident KV cache makes distributed inference on DockerSSD converge to about 9.5x faster than host-based serving, with the crossover point occurring at sequence length 256 for the smallest tested model and 1,024 for the largest."],"supporting_citations":[{"why":"Supplies the Willow programmable-ISP baseline that DockerSSD outperforms and that motivates the need for an adaptable ISP model.","marker":"[3]"},{"why":"Supplies the Biscuit programmable-ISP baseline using vendor-specific NVMe commands, another key comparison.","marker":"[4]"},{"why":"Describes the full-Linux on separate controller configuration used as the D-Naive baseline.","marker":"[30]"},{"why":"Provides the OpenExpress NVMe controller IP used to build the FPGA prototype's frontend.","marker":"[29]"},{"why":"Supplies the validated SimpleSSD cycle-accurate simulator used to evaluate ISP models and cross-check the prototype.","marker":"[45]"},{"why":"Provides the gem5 full-system simulator used to cross-validate the software-hardware framework.","marker":"[46]"},{"why":"Supplies the Calculon distributed LLM inference simulator that the paper extends with an analytical KV-cache model for the 7.9x result.","marker":"[54]"}],"fun_headline_variants":["SSD firmware runs containers, boosts LLM inference 7.9x","Containerized SSDs cut host overhead, 7.9x faster LLM","Docker on SSD via Ethernet over NVMe: 7.9x LLM gain","SSD as container host: 7.9x speedup for distributed LLM","KV cache on flash, not swap: 7.9x faster LLM inference"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole approach assumes that Virtual-FW's subset of 133 emulated system calls and 11 Docker commands is enough to run arbitrary containerized workloads, yet the paper only tests six hand-picked benchmarks that lie inside that subset.","fun_headline_variants_meta":{"raw":{"variants":["SSD firmware runs containers, boosts LLM inference 7.9x","Containerized SSDs cut host overhead, 7.9x faster LLM","Docker on SSD via Ethernet over NVMe: 7.9x LLM gain","SSD as container host: 7.9x speedup for distributed LLM","KV cache on flash, not swap: 7.9x faster LLM inference"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000213,"raw_usage":{"total_tokens":1374,"prompt_tokens":853,"completion_tokens":521,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":469,"completion_tokens_details":{"reasoning_tokens":412}},"tokens_in":469,"tokens_out":521,"duration_ms":4840,"temperature":1.0,"reasoning_tokens":412,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:49:14.460325+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an unmodified container that exercises a system call absent from Virtual-FW's emulated set—such as `clone3`, user namespaces, or `io_uring`—with `docker run` against a DockerSSD prototype. If the container fails to start or silently falls back to host execution, the paper's central claim of unmodified container support is false; a simpler check is to trace the system calls of a typical real-world container (e.g., a data-science notebook) and compare them with Table 1a.","supporting_citations":[{"cited_title":"Willow: A User- Programmable SSD, OSDI’14","cited_arxiv_id":null,"evidence_quote":"Supplies the Willow programmable-ISP baseline that DockerSSD outperforms and that motivates the need for an adaptable ISP model."},{"cited_title":"Yoon, Duck-Ho Bae, Insoon Jo, Jinyoung Lee, Jonghyun Yoon, Jeong-Uk Kang, Moonsang Kwon, Chanho Yoon, Sangyeun Cho, Jaeheon Jeong, and Duckhyun Chang","cited_arxiv_id":null,"evidence_quote":"Supplies the Biscuit programmable-ISP baseline using vendor-specific NVMe commands, another key comparison."},{"cited_title":"Deployment of in-storage compute","cited_arxiv_id":null,"evidence_quote":"Describes the full-Linux on separate controller configuration used as the D-Naive baseline."},{"cited_title":"OpenExpress: Fully Hardware Automated Open Research Framework for Future Fast NVMe Devices, USENIX ATC’20","cited_arxiv_id":null,"evidence_quote":"Provides the OpenExpress NVMe controller IP used to build the FPGA prototype's frontend."},{"cited_title":"Sim- pleSSD: Modeling Solid State Drives for Holistic System Simulation","cited_arxiv_id":null,"evidence_quote":"Supplies the validated SimpleSSD cycle-accurate simulator used to evaluate ISP models and cross-check the prototype."},{"cited_title":"Reinhardt, Ali Saidi, Arkaprava Basu, Joel Hestness, Derek R","cited_arxiv_id":null,"evidence_quote":"Provides the gem5 full-system simulator used to cross-validate the software-hardware framework."},{"cited_title":"Calculon: a methodology and tool for high-level co-design of systems and large language models, SC’23","cited_arxiv_id":null,"evidence_quote":"Supplies the Calculon distributed LLM inference simulator that the paper extends with an analytical KV-cache model for the 7.9x result."}],"review_version":1}