{"id":"de5589b3-c37a-4928-ad24-e275c276bc00","arxiv_id":"2501.10138","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":2,"one_line_summary":"Proposes a trusted smart NIC integrated with the OS kernel over a cache-coherent interconnect to dispatch RPCs directly to application code, claiming kernel-bypass performance with kernel flexibility.","lead":"A systems paper argues that the network card should be a trusted part of the operating system kernel, not an untrusted peripheral. The authors propose a smart NIC that talks to CPU cores over a cache-coherent interconnect to deliver RPC requests directly to application code.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper’s central claim depends on the NIC being safely trustable as an OS component with access to kernel scheduling state; the paper asserts this trust without a threat model or isolation mechanism, so ‘without sacrificing robustness’ is not established.","rationale":"The reader’s weakest assumption already names the trusted-NIC premise and the coherence-stall mechanism as the fragile load-bearing assumptions. I agree but would sharpen the trust issue: the paper explicitly acknowledges in Section 3 that the OS does not trust the NIC, yet Section 4 replaces that with a declaration rather than an argument. Since the abstract claims robustness is not sacrificed, the absence of a threat model or isolation mechanism is a direct gap in the central claim, not merely an implementation detail. I do not think this changes the CONDITIONAL verdict: this is a position paper with a plausible and clearly described architecture, and the right next step is to build the prototype and run the adversarial validation described above. The 15 ms TryAgain parameter is a related but secondary issue; the reader and I both see it as an unvalidated hand-chosen value, but the deeper concern is the trust boundary that makes such a parameter necessary. Hence partial agreement and an unchanged verdict.","tokens_in":9156,"tokens_out":20941,"duration_ms":211039,"concrete_test":"Specify the NIC’s permitted memory accesses in a TLA+ model of the Section 5 protocol, including the scheduling-state interface and the control cache-line dispatch. Add an adversarial network source and model-check that no reachable state allows the NIC to write outside the declared whitelist (scheduling-state region plus control lines) or to answer a control load with a spoofed jump target. Complement this on the Enzian prototype by fuzzing the FPGA’s packet decoder while the Linux scheduler is running and using the SMMU/IOMMU plus a hardware watchdog to verify that no access outside the whitelist occurs. If either check fails, the trusted-NIC premise underlying the abstract is not established.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3 identifies the OS’s distrust of the NIC as a key reason for the current hardware/software boundary. Section 4 responds with ‘it’s time to trust the NIC’ and treats the NIC as a full OS component that reads and updates live scheduling state and delivers jump-target cache lines to cores. For the abstract’s claim that this happens ‘without sacrificing the robustness and dynamic adaptation of kernel-based network subsystems’ to hold, a buggy or malicious NIC must not be able to corrupt the kernel state it is given or forge a control cache line whose loaded value is used as a jump target. The paper provides no threat model, no mechanism for confining the NIC’s newly privileged accesses, and no discussion of how a device exposed to untrusted network traffic can be made as robust as the kernel code it replaces. This is not a missing optional feature: if the NIC cannot be made safely trustable, the fast-path dispatch is not a viable OS component and the central performance claim does not follow. The 15 ms TryAgain mechanism in Section 5.1 addresses one coherence symptom of this trust model, but it does not address integrity or isolation of the scheduling state the NIC is allowed to touch.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This position paper argues that the conventional split in system state between OS and NIC is the root cause of the kernel-bypass trade-off between performance and flexibility. The authors propose making the NIC a trusted OS component that, using cache-coherent interconnects such as CXL and ECI, can perform the entire RPC receive path - demultiplexing, unmarshalling, scheduling-state lookup, and function dispatch - by returning a prepared cache line to a stalled CPU load, with near-zero CPU overhead. The architecture is embodied in the Lauberhorn prototype on the Enzian platform, and the paper presents the receive fast path, the mechanism for sharing scheduling state, and a comparison of interconnect round-trip latencies (Figure 2). Section 6 explicitly acknowledges that the work is at an early stage, listing missing non-functional features and open research questions.","tokens_in":9418,"tokens_out":3732,"duration_ms":40871,"significance":"If the central claims were borne out, the paper would make a significant contribution to systems research: it directly challenges the widely accepted trade-off between kernel-bypass performance and dynamic scheduling flexibility, and it gives a concrete, testable design based on real cache-coherent interconnects and a working research platform (Enzian). The paper is also honest about its status as work in progress, and it names specific limitations in Section 6. The main strength is the architectural vision and the concrete protocol sketch; the main weakness is that the headline performance and robustness claims are not yet supported by end-to-end measurements, a threat model, or correctness evidence.","major_comments":[{"comment":"The abstract's central claim that the approach delivers 'performance for RPC workloads better than the fastest kernel-bypass approaches' is not supported by any RPC benchmark or end-to-end measurement. Figure 2 reports only 64-byte message round-trip latencies over the interconnect, which is not the cost of the full RPC path (steps 1–12 of Section 2). To support the claim, the paper needs at least a microbenchmark of the complete receive path from packet arrival to handler invocation, with a comparison to a kernel-bypass baseline (e.g., DPDK or a dedicated polling stack) and appropriate error bars. As it stands, the central performance claim is an aspiration rather than a result.","section":"Abstract and Section 4"},{"comment":"The paper gives the NIC access to live kernel scheduling state and the ability to deliver a cache line whose contents are used as a jump target, yet it provides no threat model or isolation mechanism for a device that is exposed to untrusted network traffic. The abstract's claim that this is achieved 'without sacrificing the robustness and dynamic adaptation of kernel-based network subsystems' requires that a buggy or malicious NIC cannot forge a dispatch cache line or corrupt the scheduler state it is allowed to touch. The assertion in Section 4 that communication is 'easily protected using conventional MMU mechanisms' does not address the fact that the NIC itself becomes a privileged agent; please provide a concrete mechanism (e.g., capability-based delegation, IOMMU-enforced restrictions on NIC-accessible memory, or a formal trust boundary) and state which parts of the kernel state the NIC may read or write.","section":"Section 4, 'it's time to trust the NIC'"},{"comment":"The TryAgain dummy message after 15 ms is a hand-chosen parameter with no analysis of its effect on performance or correctness. If the timeout is too short, the core is frequently unblocked and must reload, reintroducing the very spinning and bus traffic the design seeks to avoid; if too long, the coherence stall may cause bus errors or latency anomalies. The paper also does not specify how TryAgain interacts with a real packet that arrives just after the dummy response, or how the NIC guarantees that the subsequent reload will not be starved. Please provide an analysis or measurement of this trade-off, and ideally make the timeout adaptive or derived from coherence-protocol parameters.","section":"Section 5.1, TryAgain timeout"},{"comment":"The statement that the design 'can be model-checked for correctness relatively easily' is not backed by any TLA+ specification, model-checking run, or even an explicit list of invariants. Since the fast path relies on a stalled load returning a jump target while the scheduler may concurrently change run queues and page tables, the correctness of the race handling is load-bearing for the 'robustness' part of the central claim. Please include at least a fragment of the specification or a precise statement of the invariants that are checked, and report the model-checking result.","section":"Section 6, correctness claim"}],"minor_comments":[{"comment":"The plot shows three latency bars but no methodology, no error bars, and no sample size; please add a short description of how the round-trip latencies were measured and over how many trials.","section":"Figure 2"},{"comment":"The sentence 'the NIC with respond to this load' contains a typo; it should read 'will respond to this load'.","section":"Section 5.1, paragraph on control cache lines"},{"comment":"The text states that after the stalled load returns, 'the CPU ... is already in the correct address space,' but it does not explain how the address space is switched or how the NIC knows which page table is active. Please clarify the mechanism, especially for the case where the target process is not the currently running process.","section":"Section 5.1, address space handling"},{"comment":"The paper relies heavily on the protocol from reference [21] for cache-line delivery; please cite this more explicitly in Section 5.1 where the protocol is first described, so that a reader can distinguish what is adopted from prior work and what is new in Lauberhorn.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"This is a workshop-style position paper, and the authors are transparent about the prototype being under construction. The architectural idea is interesting and worth pursuing, but the abstract's strong empirical claim is not yet substantiated, and the trusted-NIC premise needs a concrete security story. I recommend major revision rather than reject because the missing pieces (benchmarks, threat model, model-checking results) are within the scope of the manuscript and can be added as the Lauberhorn prototype matures. I did not find a circularity problem; the central claim is architectural and does not depend on fitted parameters from the cited prior work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Pengcheng — read it before the discussion. It’s a real architectural proposal, not a variation on kernel bypass; it's also a position paper with zero end-to-end measurements, and the abstract goes past what the paper shows.\n\nThe new idea: a cache-coherent NIC that is a full, trusted OS component — it holds a copy of the scheduler run-queue state, decodes RPCs, and answers a processor’s stalled load with the target code pointer and arguments. Prior work (CC-NIC, nanoPU) either keeps the NIC as a device or co-locates it with a fixed core schedule; here the hardware/software split itself is what’s rejected. That is a clear, well-argued departure, and the related work is placed carefully.\n\nIt is also honest about being unfinished. The prototype (Lauberhorn) is sketched but there are no RPC benchmarks, no kernel-bypass comparison, and no error bars. Figure 2 is interconnect round-trip latency, not an RPC path. So the abstract’s claim about beating kernel bypass is a research target, not a result. A HotOS paper can make that move, but the framing should have said “targets” rather than “can achieve.”\n\nThe soft spot the stress-test note hits is the trust model. “It’s time to trust the NIC” does not address what happens when a NIC exposed to hostile traffic holds a list of jump targets and the authority to trigger preemption. The paper gives no threat model, no confinement mechanism for the NIC’s access to scheduling state, and no discussion of a buggy NIC corrupting a code pointer. That is load-bearing, not an optional security appendix. The 15ms TryAgain timeout handles coherence protocol timeouts, but not integrity. This is the section to push on in revision.\n\nMinor issues: the hot-services-less-than-cores assumption is asserted; the 4KiB DMA threshold is given without measurement; and the self-citation to [21] is fine, but the paper will need to show how the endpoint protocol scales beyond one cache line.\n\nAltogether: send it to referees, but frame it as a research proposal. The ideas are worth serious discussion, and the team is actually building the thing, so it isn’t vapor. A serious referee should push the authors to soften the abstract and add a threat-model paragraph — both are achievable.","headline":"A real OS/NIC architecture proposal whose abstract overclaims performance; the missing threat model is the load-bearing weakness, but the design deserves serious review.","tokens_in":9913,"tokens_out":3198,"would_cite":true,"duration_ms":32736,"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":"A cache-coherent NIC that is trusted by the OS can dispatch RPCs with near-zero CPU overhead, the paper claims.","keywords":["network interface card","remote procedure call","cache-coherent interconnect","kernel bypass","operating systems","smart NIC","scheduling state","serverless computing"],"falsifier":"Run the Lauberhorn receive path with RPC interarrival times that straddle the 15 ms TryAgain timeout while the target core is stalled. If the TryAgain response causes the NIC to miss a request, or if a packet arriving just after TryAgain triggers a coherence-protocol bus error or an unbounded stall, the zero-software-overhead dispatch claim fails. A second check: attempt to dispatch a request to a process whose scheduling state is stale in the NIC; if the NIC steers to the wrong core or corrupts scheduling metadata, the trust assumption fails.","tokens_in":8970,"feed_emoji":"⚡","tokens_out":5359,"duration_ms":49496,"temperature":0.7,"pith_summary":"This paper argues that the received wisdom of a trade-off between speed and flexibility in server networking is wrong, and that its persistence is a design accident: a split of system state between the OS and the NIC. The authors claim that if the NIC is treated as a trusted component of the OS and connected over a cache-coherent interconnect, it can hold live scheduling state and perform the whole receive path, from packet decode to function dispatch, on its own hardware. A worker core then does no work at all: a load instruction stalls until the NIC fills the cache line with the RPC arguments and the address of the handler to jump to. If this works, small RPC workloads can get better performance than the fastest kernel-bypass stacks while keeping the OS in charge of scheduling, load balancing, and dynamic core allocation. The paper is a system design and prototype-in-progress, not a finished evaluation.","feed_headline":"NIC as trusted OS component beats kernel-bypass RPC speed","feed_subtitle":"A cache-coherent smart NIC returns a ready-to-jump cache line, cutting per-RPC CPU cost toward zero.","key_machinery":"The load-bearing object is Lauberhorn, the authors' prototype smart NIC, which uses a cache-coherent interconnect to speak a protocol with the CPU: each communication end-point is a set of cache lines homed on the NIC, and a process receives a request by loading one control line, stalling until the NIC answers with a cache line carrying the dispatch information. The same fine-grained mechanism carries kernel scheduling state to the NIC, letting it steer packets to the right process and ask the OS to reschedule; a 15 ms TryAgain response is used to avoid coherence-protocol 'bus errors' when no packet is pending. This protocol does the work of demultiplexing, deserializing, scheduling, and context-switching that conventional stacks spread across DMA, interrupts, and the kernel.","core_discovery":"The central claim is that a NIC integrated into the OS can execute every step of turning an incoming packet into a function invocation, so that the only CPU action left is a stalled load that returns a prepared cache line: the arguments and the virtual address of the target function's first instruction. The paper attributes the current performance/flexibility trade-off to an arbitrary boundary in which the NIC demultiplexes flows while the OS owns scheduling state; once the NIC is trusted and shares that state, the boundary disappears. The authors assert this yields better RPC performance than kernel-bypass systems while retaining the dynamic adaptation of kernel-based stacks. They do not claim this for large transfers, which they say are better handled by DMA once throughput dominates latency.","pith_inferences":["If the trust model holds, the same mechanism could be generalized beyond RPC to any event-driven dispatch where the completion is a small, well-defined data structure, such as timers, I/O completions, or serverless function triggers.","Making the NIC a trusted scheduler state holder implies a new security boundary: a compromised or defective NIC could read or corrupt live scheduling state, so the approach likely needs stronger attestation or isolation than the sketch addresses.","The 15 ms TryAgain timeout is a hand-picked parameter; a natural extension is to make the timeout adaptive to measured request-arrival statistics, which would test whether the stall mechanism preserves correctness under bursty traffic.","The proposed dispatch changes the performance model of RPC from 'wake a core and run a stack' to 'park a core on a cache line', which suggests that the optimal number of cores to allocate to a service could be derived from the NIC's queue occupancy rather than from CPU utilization."],"forward_implications":["Small RPC and serverless workloads could run at kernel-bypass speed without dedicating cores or busy-waiting, since blocked cores stall on loads instead of spinning.","The OS can keep scheduling authority and dynamic load balancing while the NIC steers packets, so static queue-to-core bindings are no longer required for high performance.","Non-preemptive and preemptive kernels can both reallocate cores between RPC services and other work, because the NIC can retire a blocked kernel thread with a message.","Large messages revert to DMA-based transfers, so the design targets the common small-RPC case without pretending to replace bulk-data paths.","The same OS-NIC control channel can expose load statistics to the scheduler, enabling NIC-driven dynamic scaling of cores allocated to services."],"supporting_citations":[{"why":"Supplies the control-cache-line protocol that Lauberhorn extends to deliver packet data and dispatch information directly to a core's cache.","marker":"[21]"},{"why":"Provides the hardware platform and the cache-coherent interconnect used for the latency measurements and the Lauberhorn prototype.","marker":"[5]"},{"why":"Defines the cache-coherent peripheral interconnect standard that underlies the paper's low-latency signaling argument.","marker":"[6]"},{"why":"Presents a cache-coherent NIC interface whose emulation-based findings the paper builds on and contrasts with its own approach.","marker":"[22]"},{"why":"Gives the cloud-scale RPC size characterization that motivates focusing on small RPC requests.","marker":"[23]"},{"why":"Supplies the data-transformation accelerator approach that Lauberhorn adapts for RPC deserialization on the NIC.","marker":"[19]"},{"why":"One of the kernel-bypass data plane systems that Lauberhorn claims to beat on RPC performance.","marker":"[3]"}],"fun_headline_variants":["OS-integrated NIC outperforms kernel-bypass RPC","Trusted NIC shares OS state, bests kernel-bypass","Cache-coherent NIC delivers ready cache lines, cuts CPU","NIC as OS kernel part beats kernel-bypass, stays adaptive"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that a NIC can be trusted as part of the OS and can safely hold and use live kernel scheduling state delivered over the cache-coherent interconnect; if that trust model, or the coherence-stall mechanism's 15 ms TryAgain timeout, fails, the fast path collapses and the claimed performance does not follow.","fun_headline_variants_meta":{"raw":{"variants":["OS-integrated NIC outperforms kernel-bypass RPC","Trusted NIC shares OS state, bests kernel-bypass","Cache-coherent NIC delivers ready cache lines, cuts CPU","NIC as OS kernel part beats kernel-bypass, stays adaptive"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00025,"raw_usage":{"total_tokens":1519,"prompt_tokens":877,"completion_tokens":642,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":493,"completion_tokens_details":{"reasoning_tokens":569}},"tokens_in":493,"tokens_out":642,"duration_ms":6462,"temperature":1.0,"reasoning_tokens":569,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T19:23:00.752950+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the Lauberhorn receive path with RPC interarrival times that straddle the 15 ms TryAgain timeout while the target core is stalled. If the TryAgain response causes the NIC to miss a request, or if a packet arriving just after TryAgain triggers a coherence-protocol bus error or an unbounded stall, the zero-software-overhead dispatch claim fails. A second check: attempt to dispatch a request to a process whose scheduling state is stale in the NIC; if the NIC steers to the wrong core or corrupts scheduling metadata, the trust assumption fails.","supporting_citations":[{"cited_title":"HOTOS ’25, May 14–16, 2025, Banff, AB, Canada He, Z., Hossle, N., Korolija, D., Licciardello, M., Martsenko, K., Achermann, R., Alonso, G., and Roscoe, T","cited_arxiv_id":null,"evidence_quote":"Provides the hardware platform and the cache-coherent interconnect used for the latency measurements and the Lauberhorn prototype."},{"cited_title":"Compute Express Link (CXL) version 3.0, Aug","cited_arxiv_id":null,"evidence_quote":"Defines the cache-coherent peripheral interconnect standard that underlies the paper's low-latency signaling argument."},{"cited_title":"N., Krishnamurthy, A., Culler, D., Levy, H","cited_arxiv_id":null,"evidence_quote":"Presents a cache-coherent NIC interface whose emulation-based findings the paper builds on and contrasts with its own approach."},{"cited_title":"E., Khan, S., Liu, S., W assel, H., Yeganeh, S","cited_arxiv_id":null,"evidence_quote":"Gives the cloud-scale RPC size characterization that motivates focusing on small RPC requests."},{"cited_title":"P., Falsafi, B., and Koch, C","cited_arxiv_id":null,"evidence_quote":"Supplies the data-transformation accelerator approach that Lauberhorn adapts for RPC deserialization on the NIC."},{"cited_title":"Ix: a protected dataplane operating system for high throughput and low latency","cited_arxiv_id":null,"evidence_quote":"One of the kernel-bypass data plane systems that Lauberhorn claims to beat on RPC performance."}],"review_version":1}