Pith. sign in

REVIEW 4 major objections 5 minor 54 references

Zephyrus claims a hyperscale cloud gateway can keep ASIC line rate while offloading complex lookups to DPUs inside the forwarding path.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

A DPU-augmented hierarchical gateway design claims 1.6 Tbps line-rate forwarding with 2–1000× larger tables and >99% hardware offload at production scale.

T0 review reviewed 2026-08-04 challenge →

load-bearing objection A real and novel DPU-in-the-ASIC-path architecture for cloud gateways, but the headline 1.6 Tbps and offload-rate claims are not backed by the evaluation; the paper is an architectural proposal with a strong resource-usage study, not a demonstrated hyperscale gateway. the 4 major comments →

arxiv 2510.11043 v3 pith:IAPP42L7 submitted 2025-10-13 cs.NI

Gryphon: Scaling Hyperscale Multi-Tenant Gateways Beyond the Petabit-Era via DPU-Augmented Hierarchical Co-Offloading

Yuemeng Xu , Haoran Chen , Jiarui Guo , Mingwei Cui , Qiuheng Yin , Cheng Dong , Peng He , Chenmin Sun
show 9 more authors
Yangyujia Wang Daxiang Kang Xian Wu Yang Gao Lirong Lai Kai Wang Zhuochen Fan Tong Yang Hongyu Wu
This is my paper
classification cs.NI
keywords cloud gatewayDPUTofinoP4hierarchical offloadingline-rate forwardingmulti-tenanthyperscale networking
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the fundamental tension in cloud gateways—between raw ASIC speed and the need for large programmable tables—can be broken by embedding DPUs directly into the switching ASIC's forwarding path. It claims that a three-stage 'sandwich' architecture, where packets pass through a folded Tofino pipeline, then a layer of four parallel 400 Gbps DPUs, then back into the Tofino, sustains 1.6 Tbps line-rate forwarding while expanding table capacity by 2–1000× depending on table type. The key mechanism is a hierarchical co-offloading design (HLCO) that keeps more than 99% of packets in hardware by splitting exact-match lookups to DPUs and prefix matching to ASICs, with a version-based protocol for consistent updates. If true, this gives hyperscale operators a gateway that is simultaneously fast, programmable, and cheaper per bit than FPGA-based alternatives, validated by over a year of production deployment. A sympathetic reader would see this as a concrete blueprint for the next generation of multi-tenant gateways.

Core claim

The paper claims that integrating DPUs into the packet path of a programmable switching ASIC, rather than placing them after the ASIC or replacing it, resolves the capacity-versus-speed dilemma in hyperscale gateways. By folding four Tofino pipelines into one logical pipeline and inserting four Pensando DPUs in parallel (the 'sandwich' architecture), the design achieves 1.6 Tbps line-rate forwarding with only about 8 microseconds of added average latency. The VM-to-node-controller table, previously a localized SRAM bottleneck, is relocated to DPU DRAM, adding 2–1000× capacity; hierarchical co-offloading directs cache-hit local-VM traffic through the DPU fast path, and version-tagged service

What carries the argument

The central object is the hierarchical co-offloading (HLCO) data plane: a three-tier fast/slow path where Tofino ASICs perform LPM and classification (Tier 1), DPU P4 pipelines perform exact-match flow lookups in DRAM (Tier 2), and DPU ARM cores run a DPDK-based slow path (Tier 3). The supporting mechanism is the 'sandwich' topological placement of DPUs between two halves of a folded Tofino pipeline, which lets traffic enter and exit the DPU from the same ASIC pipeline, avoiding the bandwidth loss of serial placement. A version-based flow update mechanism associates each service with a version number checked in the DPU fast path, redirecting stale flows to software when configuration changes

Load-bearing premise

The 1.6 Tbps line-rate claim rests on the assumption that four 400 Gbps DPUs in parallel can process the entire cache-hit fast-path traffic for local-VM flows at full line rate, yet the only packet-level test in the paper runs at about 10 Gbps aggregate (20 Mpps round trip), which does not exercise the claimed data path.

What would settle it

Run the actual folded-pipeline Zephyrus configuration at 1.6 Tbps with real production traffic mixes and measure whether (a) the four DPUs sustain line rate on the hybrid fast path, (b) the >99% hardware-offload ratio holds under cache churn, and (c) p99 latency stays within the claimed bounds. If any of the four DPUs saturates below 400 Gbps, the sandwich architecture cannot deliver the headline throughput.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Cloud gateways can expand routing and policy table capacity by orders of magnitude without sacrificing ASIC line rate, removing the SRAM hotspot that limits current Tofino-based designs.
  • The three-tier offload model generalizes to other heterogeneous data-plane compositions, giving operators a recipe for mixing ASICs, DPUs, and software in one P4-based pipeline.
  • DPU-based middle tiers can absorb complex operations (NAT, advanced load balancing, encryption) that ASIC pipelines cannot express, while keeping the common case in hardware.
  • Moving large exact-match tables to DPU DRAM reduces per-device power and hardware cost by roughly 21% and 14% respectively, compared with FPGA-augmented gateways, at higher throughput.
  • The production experience details—such as staged upgrades, traffic-migration safeguards, and packet-level tracing—offer operational guidance for deploying heterogeneous gateways at petabit scale.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The architecture implies a broader principle: the optimal place for a processing stage is not the fastest device, but the one whose memory and programmability match the stage's lookup type—exact-match to DRAM-heavy DPUs, prefix-match to TCAM-rich ASICs. This could be applied to other network functions like load balancers or firewalls.
  • The version-based consistency mechanism is a lightweight alternative to full transactional update protocols and may be generalizable to any multi-device P4 pipeline where fast-path reads must stay coherent with control-plane writes.
  • A testable extension would be to measure the cache-hit ratio in production under realistic flow arrival patterns and eviction pressures; the paper's >99% claim depends on flow cache behavior that is not directly characterized.
  • If DPU throughput continues to scale (the paper notes 800 Gbps DPUs on roadmaps), the sandwich architecture could be repackaged with fewer devices or higher aggregate line rate, making the design a stepping stone rather than an endpoint.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper (submitted as arXiv:2510.11043 but titled inconsistently in the full text as 'Zephyrus') describes a third-generation cloud gateway deployed at ByteDance. The proposed architecture integrates four 400 Gbps P4-programmable DPUs into a folded four-pipeline Tofino switching ASIC in a 'sandwich' configuration, with a three-tier hierarchical offloading design (HLCO). The paper claims 1.6 Tbps line-rate forwarding, ~8 μs added average latency, >99% hardware offload, >99.9% fast-path hit rate, 2–1000× table-capacity expansion, and favorable power/cost versus prior FPGA-based gateways. The evaluation presented is limited to a low-rate testpmd round-trip test (20 Mpps aggregate, roughly 10 Gbps at 64 B), PHV/resource utilization figures, and table-capacity comparisons; the central throughput and hit-rate claims are not demonstrated by the reported experiments.

Significance. If the 1.6 Tbps line-rate claim were backed by measurement, the paper would be a significant industrial systems contribution: it is one of the first reports of a DPU-augmented programmable-ASIC gateway with a unified P4 data plane, and the proposed HLCO three-tier fast/mid/slow path and version-based consistency mechanism are plausible and reusable design ideas. The paper also honestly shares operational lessons and deployment experiences. However, the current evidence does not substantiate the headline quantitative claims. The only packet-level experiment runs at less than 1% of the claimed aggregate line rate, and no production hit-rate, per-DPU throughput, power, or cost measurements are provided. As it stands, the paper is an architecture/experience report with interesting design details, but not a demonstrated hyperscale gateway at the claimed scale.

major comments (4)
  1. [4.1 and 5.1] The central claim of 1.6 Tbps line-rate forwarding is not supported by the evaluation. Section 5.1 describes a testpmd experiment in which packets traverse the gateway at 20 Mpps aggregate, i.e. roughly 10 Gbps at minimum-size packets, orders of magnitude below 1.6 Tbps. There is no measurement of per-DPU throughput, no line-rate test at 400 Gbps per DPU, no packet-size mix, and no evidence that ECMP evenly distributes the traffic. Since the 1.6 Tbps figure depends on each of the four DPUs sustaining its 400 Gbps slice for the cache-hit fast-path workload, the paper needs a high-rate test that exercises the actual DPU data path at or near the claimed per-DPU line rate.
  2. [Abstract and Section 3/4] The claims of '>99.9% fast path hit rate' and '>99% hardware offload' are not tied to any measured data. The paper provides no flow-table hit-rate measurement, cache size, eviction policy, traffic trace, or production counter data. These numbers appear only as assertions. Since the architecture's advantage over software fallback depends on the hit rate, the paper should report, at minimum, measured or production-derived hit rates under representative workloads, along with the cache configuration used to obtain them.
  3. [5.1] The ~8 μs added average latency relative to the Tofino-only gateway is measured only at 20 Mpps with small packet counts (1K–4M packets). This does not establish latency at line rate, where queueing in the DPU or post-DPU Tofino stage could dominate. The paper should present latency measurements while the gateway is stressed at high offered load, including the P99 and tail behavior that the paper argues matters for cloud-edge services.
  4. [Abstract, Section 6, and Section 7] The claimed 21% lower power and 14% lower cost versus FPGA-integrated designs, and the 33% throughput improvement over LuoShen and 2× over Albatross, are not supported by any evaluation methodology or data in Section 5. The paper presents no power measurements, no cost model, no TCO breakdown, and no comparative benchmarks against LuoShen or Albatross. These comparisons are load-bearing for the paper's 'performance-per-dollar' conclusions and should either be removed or backed by a clearly defined measurement/estimation methodology.
minor comments (5)
  1. [Title and Abstract] The title, abstract, and introduction refer to 'Gryphon', while the full text consistently uses 'Zephyrus'. This inconsistency should be resolved before publication.
  2. [Table 1] The table header contains the typo 'could gateway' for 'cloud gateway'.
  3. [Section 5.2] The resource-utilization and table-capacity comparisons would be more informative if the paper stated the exact Tofino model, DPU model, and P4 program configuration used for each reported maximum capacity. It is also unclear whether the 'max table capacities' are measured, compiler-reported, or configured limits.
  4. [Section 4.2 and Figure 6] The metadata format is described textually and in a figure, but the actual header layout (field sizes, offsets, and how private header flags are marked) is not specified precisely enough for reproduction. A table of metadata fields and their semantics would help.
  5. [Section 7.2] The statement that DPU development 'typically [uses] only a few thousand lines of code' is anecdotal and not quantified for Zephyrus; a breakdown of the Zephyrus P4/C code size would make the development-cost argument concrete.

Circularity Check

0 steps flagged

No significant circularity: the central 1.6 Tbps figure is a stated hardware-capacity calculation, not a fitted or self-referential derivation.

full rationale

The paper contains no mathematical derivation, no fitted parameters, and no prediction that is defined in terms of its own inputs. The 1.6 Tbps claim is an explicit design arithmetic: folding four Tofino pipelines reduces throughput from 6.4 to 1.6 Tbps, and four 400 Gbps DPUs in parallel are chosen to match that rate. This is a capacity calculation based on vendor-specified port rates, not an empirical prediction reduced by construction. The HLCO hit-rate and hardware-offload percentages are stated as production/operational claims, but they are not derived from, nor do they reduce to, any measured variable in the paper; their lack of supporting line-rate evaluation is an evidentiary gap rather than circularity. Citations to Sailfish and LuoShen are used as external performance baselines, not as load-bearing justifications for Zephyrus's own architecture, and no uniqueness theorem or prior ansatz is imported from the authors' own work to force the design choice. The paper's claims may be under-validated at the advertised 1.6 Tbps line rate, but the derivation chain is not circular.

Axiom & Free-Parameter Ledger

0 free parameters · 5 axioms · 0 invented entities

The paper introduces no fitted parameters or invented physical entities. Its central claims depend on several domain assumptions about gateway traffic and DPU/ASIC capabilities that are stated in Sections 2 and 4 but not independently verified in the paper's evaluation; the most consequential is that a 20 Mpps testbed represents line-rate conditions.

axioms (5)
  • domain assumption Cloud gateway packet processing is simple and mostly stateless, so a small hardware fast-path cache with software slow-path fallback can achieve >99% offload.
    Section 2.1 states this as observed traffic characteristic; it is load-bearing for HLCO's hit-rate claim.
  • domain assumption DPUs (Pensando) can be programmed in P4 and can match the P4 abstraction of Tofino sufficiently to run a unified pipeline.
    Sections 3.2 and 4 rely on vendor P4 support; no proof or measurement included.
  • domain assumption ECMP hashing across four DPUs distributes traffic evenly enough that a single DPU does not become a hotspot.
    Section 4.1 parallel DPU design depends on this; paper mentions dynamic one-to-one mapping only in lessons, not in evaluation.
  • domain assumption The measured 20 Mpps round-trip testbed (~10 Gbps) is representative of production line-rate behavior.
    Section 5.1 uses this testbed to support the throughput and latency claims, though it is far below 1.6 Tbps.
  • domain assumption Multiple LPM matches are rare, enabling hash-table coalescing.
    Section 4.3 states this observation; the entire coalescing optimization depends on it.

reviewed 2026-08-04 · how reviews work

0 comments
Cite this review

Pith. "Pith review of Gryphon: Scaling Hyperscale Multi-Tenant Gateways Beyond the Petabit-Era via DPU-Augmented Hierarchical Co-Offloading." pith.science (2026). https://pith.science/paper/IAPP42L7

@misc{pith2026251011043,
  author       = {Pith},
  title        = {Pith review of: Gryphon: Scaling Hyperscale Multi-Tenant Gateways Beyond the Petabit-Era via DPU-Augmented Hierarchical Co-Offloading},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IAPP42L7}},
  note         = {Machine review of arXiv:2510.11043}
}
Share X Bluesky LinkedIn Reddit HN
abstract

At ByteDance, cloud gateway clusters orchestrate petabit-scale aggregate traffic. Traditional ASIC-only gateways fail to meet these escalating demands due to severe on-chip resource constraints and limited programmable flexibility, while pure software solutions or alternatives like disaggregated SmartNICs struggle to match terabit-scale line-rate throughput. To bridge this gap, we present Gryphon, a hyperscale cloud gateway built on a hybrid architecture that integrates DPUs directly into the switching ASIC's forwarding path. This design resolves the fundamental tension between capacity and speed, expanding table scale by up to 1000$\times$ and augmenting programmability, while sustaining 1.6 Tbps line-rate throughput at a cost of only ~8$\mu s$ in additional average latency. To manage this hardware heterogeneity, we introduce Hierarchical Co-Offloading (HLCO) in the data plane, achieving >99.9% fast path hit rate, while retaining software fallback for complex operations. In the control plane, we develop an abstraction layer (P4Bridge) that decouples hardware specifics from policy configuration. Gryphon has been operating at production scale for over a year, deployed on hundreds of nodes across multiple Availability Zones. We also share production measurements and operational experiences that serve as the first hyperscale-proven guidelines for next-generation DPU-augmented cloud gateways.

Figures

Figures reproduced from arXiv: 2510.11043 by Cheng Dong, Chenmin Sun, Daxiang Kang, Haoran Chen, Hongyu Wu, Jiarui Guo, Kai Wang, Lirong Lai, Mingwei Cui, Peng He, Qiuheng Yin, Tong Yang, Xian Wu, Yang Gao, Yangyujia Wang, Yuemeng Xu, Zhuochen Fan.

Figure 1
Figure 1. Figure 1: Aggregate traffic from ByteDance cloud and edge [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Cloud network gateway architecture. and flexible 3-stage offloading [18], allowing Zephyrus to harness the strengths of heterogeneous hardware while mitigating their weaknesses. With HLCO, more than 99% of packets are offloaded to hardware, minimizing software overhead while retaining the flexibility. • We evaluate Zephyrus against LuoShen [4], a state-of-the-art pro￾grammable gateway. Zephyrus delivers 33… view at source ↗
Figure 3
Figure 3. Figure 3: Three typical datapaths for different types of traffic [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Detailed pipeline organization [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Table lookup sequence in Tofino pipelines. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: DPU packet processing pipeline with fast/slow path interaction [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Performance comparison of three cloud gateway versions [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Latency distribution with different packet numbers [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: PHV usage across pipelines (the worst case) [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Total on-chip resource usage across pipelines [PITH_FULL_IMAGE:figures/full_fig_p009_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: SRAM usage over stages across pipelines [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 13
Figure 13. Figure 13: Table capacity of different versions Recent work highlights their diverse capabilities, including storage offloading [41], near-storage secure filtering [42], and 6G user-plane acceleration [43], demonstrating their growing role in different fields. Sirius [44] further demonstrates this trend by disaggregat￾ing a broad class of stateful network functions into pools of P4- programmable NIC cards. In the co… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

54 extracted references

  1. [1]

    Jupiter rising: A decade of clos topologies and centralized control in google’s datacenter network.ACM SIGCOMM computer communication review, 45(4):183–197, 2015

    Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, et al. Jupiter rising: A decade of clos topologies and centralized control in google’s datacenter network.ACM SIGCOMM computer communication review, 45(4):183–197, 2015

    2015

  2. [2]

    Maglev: A fast and reliable software network load balancer

    Daniel E Eisenbud, Cheng Yi, Carlo Contavalli, Cody Smith, Roman Kononov, Eric Mann-Hielscher, Ardas Cilingiroglu, Bin Cheyney, Wentao Shang, and Jin- nah Dylan Hosein. Maglev: A fast and reliable software network load balancer. InNsdi, volume 16, pages 523–535, 2016

    2016

  3. [3]

    Albatross: A containerized cloud gateway platform with fpga-accelerated packet-level load balancing

    Jianyuan Lu, Shunmin Zhu, Jun Liang, Yuxiang Lin, Tian Pan, Yisong Qiao, Yang Song, Wenqiang Su, Yixin Xie, Yanqiang Li, et al. Albatross: A containerized cloud gateway platform with fpga-accelerated packet-level load balancing. In Proceedings of the ACM SIGCOMM 2025 Conference, pages 71–84, 2025

    2025

  4. [4]

    Luoshen: A hyper-converged programmable gateway for multi-tenant multi- service edge clouds

    Tian Pan, Kun Liu, Xionglie Wei, Yisong Qiao, Jun Hu, Zhiguo Li, Jun Liang, Tiesheng Cheng, Wenqiang Su, Jie Lu, Yuke Hong, Zhengzhong Wang, Zhi Xu, Chongjing Dai, Peiqiao Wang, Xuetao Jia, Jianyuan Lu, Enge Song, Jun Zeng, Biao Lyu, Ennan Zhai, Jiao Zhang, Tao Huang, Dennis Cai, and Shunmin Zhu. Luoshen: A hyper-converged programmable gateway for multi-t...

    2024

  5. [5]

    https://www.doubao.com/

    Bytedance doubao. https://www.doubao.com/

  6. [6]

    https://www.tiktok.com/

    Bytedance tiktok. https://www.tiktok.com/

  7. [7]

    https://www.volcengine.com/

    Bytedance volcengine. https://www.volcengine.com/

  8. [8]

    Enhancing the efficiency and scalability of cloud networking systems

    JIAXIN LEI. Enhancing the efficiency and scalability of cloud networking systems. 2024

    2024

  9. [9]

    Alleviating memory and cpu bottlenecks in hundred gigabit networking, 2021

    Boris Pismenny. Alleviating memory and cpu bottlenecks in hundred gigabit networking, 2021

    2021

  10. [10]

    Kfoury, Samia Choueiri, Ali Mazloum, Ali AlSabeh, Jose Gomez, and Jorge Crichigno

    Elie F. Kfoury, Samia Choueiri, Ali Mazloum, Ali AlSabeh, Jose Gomez, and Jorge Crichigno. A comprehensive survey on smartnics: Architectures, development models, applications, and research directions.IEEE Access, 12:107297–107336, 2024

    2024

  11. [11]

    Sailfish: Accelerating cloud-scale multi- tenant multi-service gateways with programmable switches

    Tian Pan, Nianbing Yu, Chenhao Jia, Jianwen Pi, Liang Xu, Yisong Qiao, Zhiguo Li, Kun Liu, Jie Lu, Jianyuan Lu, et al. Sailfish: Accelerating cloud-scale multi- tenant multi-service gateways with programmable switches. InProceedings of the 2021 ACM SIGCOMM 2021 Conference, pages 194–206, 2021

    2021

  12. [12]

    Tao Wang, Hang Zhu, Fabian Ruffy, Xin Jin, Anirudh Sivaraman, Dan R. K. Ports, and Aurojit Panda. Multitenancy for fast and programmable networks in the cloud. In Amar Phanishayee and Ryan Stutsman, editors,12th USENIX Workshop on Hot Topics in Cloud Computing, HotCloud 2020, July 13-14, 2020. USENIX Association, 2020

    2020

  13. [13]

    Towards better qos and lower costs of P4 EIP gateway at the edge

    Ming Yang, Xin Yang, Liang Xu, Yefei Hou, Long Xie, and Yong Wang. Towards better qos and lower costs of P4 EIP gateway at the edge. In24th IEEE International Symposium on Cluster, Cloud and Internet Computing, CCGrid 2024, Philadelphia, PA, USA, May 6-9, 2024, pages 57–66. IEEE, 2024

    2024

  14. [14]

    Santambrogio

    Emanuele Del Sozzo, Davide Conficconi, Alberto Zeni, Mirko Salaris, Donatella Sciuto, and Marco D. Santambrogio. Pushing the level of abstraction of dig- ital system design: A survey on how to program fpgas.ACM Comput. Surv., 55(5):106:1–106:48, 2023

    2023

  15. [15]

    High level programming of fpgas for hpc and data centric applications

    Oren Segal, Nasibeh Nasiri, Martin Margala, and Wim Vanderbauwhede. High level programming of fpgas for hpc and data centric applications. In2014 IEEE High Performance Extreme Computing Conference (HPEC), pages 1–3. IEEE, 2014

    2014

  16. [16]

    High-level language tools for reconfigurable computing.Proceedings of the IEEE, 103(3):390–408, 2015

    Skyler Windh, Xiaoyin Ma, Robert J Halstead, Prerna Budhkar, Zabdiel Luna, Omar Hussaini, and Walid A Najjar. High-level language tools for reconfigurable computing.Proceedings of the IEEE, 103(3):390–408, 2015

    2015

  17. [17]

    Pensando distributed services architecture

    Michael Galles and Francis Matus. Pensando distributed services architecture. IEEE Micro, 41(2):43–49, 2021

    2021

  18. [18]

    Triton: A flexible hardware offloading architecture for accelerating apsara vswitch in alibaba cloud

    Xing Li, Xiaochong Jiang, Ye Yang, Lilong Chen, Yi Wang, Chao Wang, Chao Xu, Yilong Lv, Bowen Yang, Taotao Wu, et al. Triton: A flexible hardware offloading architecture for accelerating apsara vswitch in alibaba cloud. InProceedings of the ACM SIGCOMM 2024 Conference, pages 750–763, 2024

    2024

  19. [19]

    Andromeda: Performance, isolation, and velocity at scale in cloud network virtualization

    Michael Dalton, David Schultz, Jacob Adriaens, Ahsan Arefin, Anshuman Gupta, Brian Fahs, Dima Rubinstein, Enrique Cauich Zermeno, Erik Rubow, James Alexander Docauer, et al. Andromeda: Performance, isolation, and velocity at scale in cloud network virtualization. In15th USENIX symposium on networked systems design and implementation (NSDI 18), pages 373–387, 2018

    2018

  20. [20]

    Vl2: A scalable and flexible data center network

    Albert Greenberg, James R Hamilton, Navendu Jain, Srikanth Kandula, Changhoon Kim, Parantap Lahiri, David A Maltz, Parveen Patel, and Sudipta Sengupta. Vl2: A scalable and flexible data center network. InProceedings of the ACM SIGCOMM 2009 conference on Data communication, pages 51–62, 2009

    2009

  21. [21]

    The tail at scale.Communications of the ACM, 56(2):74–80, 2013

    Jeffrey Dean and Luiz André Barroso. The tail at scale.Communications of the ACM, 56(2):74–80, 2013

    2013

  22. [22]

    Empirical evaluation of latency- sensitive application performance in the cloud

    Sean Kenneth Barker and Prashant Shenoy. Empirical evaluation of latency- sensitive application performance in the cloud. InProceedings of the first annual ACM SIGMM conference on Multimedia systems, pages 35–46, 2010

    2010

  23. [23]

    Optimizing latency- sensitive ai applications through edge-cloud collaboration.Journal of Advanced Computing Systems, 3(3):19–33, 2023

    Jiang Wu, Hongbo Wang, Kun Qian, Enmiao Feng, et al. Optimizing latency- sensitive ai applications through edge-cloud collaboration.Journal of Advanced Computing Systems, 3(3):19–33, 2023

    2023

  24. [24]

    Concurrent placement, capac- ity provisioning, and request flow control for a distributed cloud infrastructure

    Shuang Chen, Yanzhi Wang, and Massoud Pedram. Concurrent placement, capac- ity provisioning, and request flow control for a distributed cloud infrastructure. In2014 Design, Automation & Test in Europe Conference & Exhibition (DATE), pages 1–6. IEEE, 2014

    2014

  25. [25]

    On detecting co-resident cloud instances using network flow watermarking techniques.International Journal of Information Security, 13(2):171– 189, 2014

    Adam Bates, Benjamin Mood, Joe Pletcher, Hannah Pruse, Masoud Valafar, and Kevin Butler. On detecting co-resident cloud instances using network flow watermarking techniques.International Journal of Information Security, 13(2):171– 189, 2014

    2014

  26. [26]

    Graph-based algorithms for optimizing data flow in dis- tributed cloud architectures.International Journal of Acta Informatica, 1(1):67–95, 2022

    Sai Dikshit Pasham. Graph-based algorithms for optimizing data flow in dis- tributed cloud architectures.International Journal of Acta Informatica, 1(1):67–95, 2022

    2022

  27. [27]

    https://docs.spring.io/spring-cloud- gateway/reference/index.html/

    Spring Cloud Gateway Architecture, 2023. https://docs.spring.io/spring-cloud- gateway/reference/index.html/

    2023

  28. [28]

    Frans Kaashoek

    Robert Morris, Eddie Kohler, John Jannotti, and M. Frans Kaashoek. The click modular router. In David Kotz and John Wilkes, editors,Proceedings of the 17th ACM Symposium on Operating System Principles, SOSP 1999, Kiawah Island Resort, near Charleston, South Carolina, USA, December 12-15, 1999, pages 217–231. ACM, 1999

    1999

  29. [29]

    Monteiro, and Sylvia Ratnasamy

    Mihai Dobrescu, Norbert Egi, Katerina Argyraki, Byung-Gon Chun, Kevin Fall, Geoffrey Iannaccone, Allan Knies, Mário S. Monteiro, and Sylvia Ratnasamy. Routebricks: Exploiting parallelism to scale software routers. InProceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP), pages 15–28, 2009

    2009

  30. [30]

    Packetshader: A gpu- accelerated software router

    Sangjin Han, Keon Jang, KyoungSoo Park, and Sue Moon. Packetshader: A gpu- accelerated software router. InProceedings of the ACM SIGCOMM Conference, pages 195–206, 2010

    2010

  31. [31]

    Dpdk: Data plane development kit – enabling high performance packet processing on dpus

    DPDK Project. Dpdk: Data plane development kit – enabling high performance packet processing on dpus. https://www.dpdk.org/, 2022

    2022

  32. [32]

    netmap: A novel framework for fast packet i/o

    Luigi Rizzo. netmap: A novel framework for fast packet i/o. InUSENIX Annual Technical Conference (ATC), pages 101–112, 2012

    2012

  33. [33]

    IX: A protected dataplane operating system for high throughput and low latency

    Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Christos Kozyrakis, and Edouard Bugnion. IX: A protected dataplane operating system for high throughput and low latency. In11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), pages 49–65, 2014

    2014

  34. [34]

    Goldsmith, and Sudipta Sengupta

    Srikanth Kandula, Dima Yusupov, Ishai J. Goldsmith, and Sudipta Sengupta. EyeQ: Practical network performance isolation at the edge. InProceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’13), pages 127–141, Lombard, IL, USA, 2013. USENIX Association

    2013

  35. [35]

    Protego: Overload control for applications with unpredictable lock contention

    Inho Cho, Ahmed Saeed, Seo Jin Park, Mohammad Alizadeh, and Adam Belay. Protego: Overload control for applications with unpredictable lock contention. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 725–738, 2023

    2023

  36. [36]

    Hedera: Dynamic flow scheduling for data center networks

    Mohammad Al-Fares, Sivasankar Radhakrishnan, Barath Raghavan, Nelson Huang, and Amin Vahdat. Hedera: Dynamic flow scheduling for data center networks. InProceedings of the 7th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’10), pages 19–19, San Jose, CA, USA, 2010. USENIX Association

    2010

  37. [37]

    Understanding the idiosyn- crasies of emerging bluefield dpus

    Arjun Kashyap, Yuke Li, Darren Ng, and Xiaoyi Lu. Understanding the idiosyn- crasies of emerging bluefield dpus. InProceedings of the 39th ACM International Conference on Supercomputing, ICS 2025, Salt Lake City, UT, USA, June 8-11, 2025, pages 807–821. ACM, 2025

    2025

  38. [38]

    Designing with xilinx®fpgas

    Sanjay Churiwala and I Hyderabad. Designing with xilinx®fpgas. InCircuits &Systems. Springer, 2017

    2017

  39. [39]

    Wright, and Marco Siracusa

    Douglas Doerfler, Farzad Fatollahi-Fard, Colin MacLean, Tan Nguyen, Samuel Williams, Nicholas J. Wright, and Marco Siracusa. Experiences porting the su3_bench microbenchmark to the intel arria 10 and xilinx alveo U280 fpgas. In Simon McIntosh-Smith, editor,IWOCL’21: International Workshop on OpenCL, Munich Germany, April, 2021, pages 1:1–1:9. ACM, 2021

    2021

  40. [40]

    Ermerins, W

    J. Ermerins, W. Bakker, and C. Both. Transparent malicious traffic detection and mitigation using the nvidia bluefield dpu. Technical report, University of Amsterdam, 2021

    2021

  41. [41]

    W. Zhao, J. Wu, W. Lu, X. Li, and G. Yan. Tianmen: a dpu-based storage network offloading structure for disaggregated datacenters. InProceedings of the ACM Symposium on Cloud Computing (SoCC). ACM, 2024

    2024

  42. [42]

    Batsoyol, D

    N. Batsoyol, D. Waddington, S. Sundararaman, et al. Dpuf: Dpu-accelerated near- storage secure filtering. InProceedings of the 18th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS/EuroSys). ACM, 2025

    2025

  43. [43]

    D. J. Lee, S. Park, and B. J. Lee. Dynamic traffic load rebalancing for hardware- accelerated 6g upf resilient architecture. InIEEE International Performance, Computing, and Communications Conference (IPCCC). IEEE, 2024

    2024

  44. [44]

    Disaggregating stateful network functions

    Deepak Bansal, Gerald DeGrace, Rishabh Tewari, Michal Zygmunt, James Grantham, Silvano Gai, Mario Baldi, Krishna Doddapaneni, Arun Selvarajan, Arunkumar Arumugam, et al. Disaggregating stateful network functions. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1469–1487, 2023

    2023

  45. [45]

    A reconfigurable fabric for accelerating large-scale data- center services.ACM SIGARCH Computer Architecture News, 42(3):13–24, 2014

    Andrew Putnam, Adrian M Caulfield, Eric S Chung, Derek Chiou, Kypros Con- stantinides, John Demme, Hadi Esmaeilzadeh, Jeremy Fowers, Gopi Prashanth Zephyrus: Scaling Gateways Beyond the Petabit-Era with DPU-Augmented Hierarchical Co-Offloading , , Gopal, Jan Gray, et al. A reconfigurable fabric for accelerating large-scale data- center services.ACM SIGARC...

    2014

  46. [46]

    P4: Programming protocol-independent packet processors

    Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. P4: Programming protocol-independent packet processors. In ACM SIGCOMM Computer Communication Review, volume 44, pages 87–95, 2014

    2014

  47. [47]

    Fpganic: An fpga-based versatile 100gb smartnic for gpus

    Zeke Wang, Hongjing Huang, Jie Zhang, Fei Wu, and Gustavo Alonso. Fpganic: An fpga-based versatile 100gb smartnic for gpus. In Jiri Schindler and Noa Zilberman, editors,Proceedings of the 2022 USENIX Annual Technical Conference, USENIX ATC 2022, Carlsbad, CA, USA, July 11-13, 2022, pages 967–986. USENIX Association, 2022

    2022

  48. [48]

    P4fpga: High level synthesis for networking

    Han Wang, Ki Suh Lee, Vishal Shrivastav, and Hakim Weatherspoon. P4fpga: High level synthesis for networking. InProc. ACM SIGCOMM Workshop Netw. Program. Lang.(NetPL), 2016

    2016

  49. [49]

    https://developer

    NVIDIA Corporation.NVIDIA DOCA SDK Documentation, 2023. https://developer. nvidia.com/doca

    2023

  50. [50]

    Intel ipu plans revealed for 800gbps ipus in 2025, 2022

    Patrick Kennedy. Intel ipu plans revealed for 800gbps ipus in 2025, 2022. Accessed: 2025-07-14

    2025

  51. [51]

    OpenFlow: Enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review, 2008

    Nick McKeown et al. OpenFlow: Enabling innovation in campus networks.ACM SIGCOMM Computer Communication Review, 2008

    2008

  52. [52]

    B4: Experience with a globally-deployed software defined WAN

    Sushant Jain et al. B4: Experience with a globally-deployed software defined WAN. InProceedings of the ACM SIGCOMM 2013 Conference, 2013

    2013

  53. [53]

    Sonata: Query-driven streaming network telemetry

    Arpit Gupta, Rob Harrison, Marco Canini, Nick Feamster, Jennifer Rexford, and Walter Willinger. Sonata: Query-driven streaming network telemetry. InProceed- ings of the 2018 conference of the ACM special interest group on data communication, pages 357–371, 2018

    2018

  54. [54]

    J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-End Arguments in System Design. ACM Transactions on Computer Systems (TOCS), 2(4):277–288, 1984

    1984

This paper was first reviewed by deepseek-v4-flash on August 4, 2026.