Pith. sign in

REVIEW 4 major objections 6 minor 64 references

ACiS: Complex Processing in the Switch Fabric

T0 review · 4 major / 6 minor · reviewed 2026-08-09 · deepseek-v4-flash

Pith's one-line read This paper claims that adding a CGRA-based compute plugin to a network switch can transparently accelerate MPI collectives and HPC/AI applications—with a 3.4x average speedup for graph convolutional networks—without changing the host…

desk verdict Useful taxonomy and honest framing, but the large-scale speedup claims rest on an unvalidated emulator and a mismatched baseline—cite for the taxonomy, not for the numbers. read the letter →

arxiv 2501.18749 v1 pith:CJHA3P7U submitted 2025-01-30 cs.AR

classification cs.AR
keywords in-switchcomputingFPGACGRAMPIcollectivestransparentaccelerationHPCfusednetworkswitch
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper argues that application-level computation can be moved into the heart of a network switch, rather than staying at the endpoints, and that doing so can accelerate HPC and AI workloads without modifying the host nodes, NICs, or the standard switch dataplane. It introduces ACiS, a framework that classifies in-switch processing into four types: fixed scalar collectives (Type 1), user-defined operations and datatypes (Type 2), stateful look-aside processing with loops and off-chip memory (Type 3), and fused collectives that combine multiple operations or map functions (Type 4). The authors report that a CGRA-based switch plugin, encapsulated inside an MPI implementation, delivers a 3.4x average speedup for graph convolutional networks and roughly doubles performance for miniFE relative to a CPU-cluster baseline. The reason to care is that communication overhead in HPC is growing; if the switch can absorb collectives and data-dependent computation, large-scale machines could scale without adding endpoint processing.

What carries the argument

The mechanism that carries the argument is the ACiS switch extension: a composable plugin added to a protocol-independent switch architecture (PISA) that processes MPI payloads in a separate pipeline while the normal header dataplane remains untouched. The plugin includes a programmable aggregation unit for collectives, a multicast engine for one-to-N routing, and an instruction-capable CGRA of SIMD processing units (SPUs) that provides software-like programmability for Type 3 and Type 4 operations. The CGRA is the load-bearing piece: it executes user-defined map functions, stateful loops with access to off-chip memory, and fused collectives, and it is what lets the switch go beyond the fixed scalar operations of earlier in-switch collective engines.

What would settle it

Run the ACiS implementation on a real 128-node 3D-torus, or on a cycle-accurate full-network simulator that models queueing and contention, and measure the same benchmarks (OSU collectives, GCN, miniFE, NPB) end-to-end. If the actual times are materially higher than the emulated numbers — for instance, if GCN's average speedup falls well below 3.4x — the emulation's assumption that only traffic volume, hop count, and accelerator overhead matter would be refuted.

Watch

Extended reading notes

Core claim

The central claim is that extremely high-value computing can be enabled with minimal redesign of the network, NIC, or processing node, and that ACiS hardware can be added to a switch without changing the standard dataplane architecture or sacrificing non-ACiS performance. Concretely, the paper claims that Types 2-4—user-defined collectives, stateful look-aside operations, and fused collectives—can be implemented as composable plugins built around a coarse-grained reconfigurable array (CGRA), and that an MPI-encapsulated version of these plugins transparently accelerates HPC and AI workloads. Reported results include a 3.4x average speedup for GCN across five datasets on 24 nodes, a 1.98x latency improvement for a fused Allgather-prefix-sum operation, and roughly 100% performance improvement for miniFE at 64-128 nodes, with the accelerator performing the collectives in-network.

Load-bearing premise

The headline speedups rest on an emulation that combines parameters measured on a two-FPGA direct link (14.8 us MPI overhead, 95.9 Gbps bandwidth, 0.9 us PCIe latency, 0.44 us FPGA-to-FPGA latency, 52 ns port-to-port latency) with cycle-accurate RTL simulation of the accelerator to represent a 128-node 3D-torus, and the paper does not validate that contention, queuing, recirculation limits, and host interactions at that scale are captured. If real switch operation at scale adds overheads beyond these parameters, the reported speedups would shrink.

Editorial extensions

If this is right

  • If ACiS is added to a switch as described, MPI collectives such as Allgather, Allreduce, Broadcast, and Gather can be accelerated at 32-128 nodes without changing the application or the host's network stack.
  • GCN inference would scale better: the paper reports 2.2x, 2x, 1.1x, 1.4x, and 10.1x speedups on five datasets, averaging 3.4x, because in-network aggregation removes the communication bottleneck.
  • Fused collectives can be executed in a single pass through the switch, cutting intermediate communications and giving about 1.98x lower latency for an Allgather-plus-prefix-sum operation compared with a Python MPI binding.
  • Message-heavy proxy applications benefit most: miniFE improves by roughly 100% at 64-128 nodes, and among the NAS parallel benchmarks, MG and IS show the largest gains.
  • Because the plugins are composable and built in successive layers, a switch can be upgraded incrementally to Type 2, then Type 3, then Type 4 without redesigning the dataplane.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same CGRA plugin could extend beyond MPI to other collective-heavy runtimes, such as distributed deep-learning gradient aggregation (Allreduce) or key-value stores, since the mechanism is agnostic to the specific message-passing layer.
  • The paper's emulation relies on parameters from a two-FPGA direct link; a direct measurement on a real multi-switch torus or a cycle-accurate full-network simulator that models contention, queuing, and recirculation would be the natural next test to confirm the speedups at 128 nodes and beyond.
  • The ACiS taxonomy (Types 0-4) is itself a transferable contribution: it gives switch vendors a common language for classifying in-network compute capabilities, independent of the CGRA implementation.
  • Since the CGRA is reconfigured at program-load time, the same hardware could potentially time-share between collective offload and other dataplane functions, though the paper does not explore that trade-off.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper presents ACiS, a taxonomy and framework for adding application-level processing to network switches. It defines Types 0-4 (stream transformations, fixed collectives, user-defined collectives, look-aside stateful processing, and fused collectives), proposes modular hardware plugins for a PISA-style pipeline with a CGRA accelerator, sketches MPI-transparent software support, and reports evaluations. The indirect-network result is a three-node CloudLab measurement of a fused Allgather (1.98x over MPI4py). The direct-network results for 32-128 nodes (Type 2 collectives, GCN, NPB, miniFE) are produced by an emulator parameterized with a two-FPGA back-to-back testbed and compared against a TACC Stampede2 SKX baseline using Intel MPI over Omni-Path. The paper is explicitly a summary of the authors' prior work [24,28,29,31].

Significance. The ACiS taxonomy is a useful organizing framework, and the modular-switch-extension direction is timely: it generalizes BlueGene/SHArP-style fixed collectives toward user-defined, stateful, and fused operations, which is a plausible way to reduce communication overhead in HPC systems. The paper deserves credit for real small-scale measurements (the 1.98x fused-Allgather result), cycle-accurate RTL simulation for the accelerator overhead, and a clearly stated parameter table. However, the headline 32-128 node speedups are not supported by the current evidence: they rest on an unvalidated analytical emulator and on a baseline that differs from the ACiS testbed in MPI implementation, network, and host platform. The paper's main contribution is therefore the synthesis/taxonomy and the architectural proposal; the performance claims require substantial additional validation before they can be accepted.

major comments (4)
  1. [V-A, Table II, Figures 3, 4, and 6] The 32-128 node direct-network results rest entirely on an analytical emulator whose only stated validity criteria are equal traffic volume, equal hop count, and accurate accelerator overhead. The paper shows no evidence that this emulator reproduces any measured multi-node behavior, and it does not model switch/FPGA contention, queueing, recirculation throughput limits (which Section III itself identifies as a throughput limiter), off-chip memory bandwidth for Type 3 state, or host/MPI process interactions. Because these effects typically grow with node count, the headline speedups (3.4x average for GCN, near-100% for miniFE) are not established without a validation experiment or a sensitivity analysis. Please validate the emulator on a real multi-node FPGA testbed (even 4-8 nodes) or demonstrate quantitatively that the omitted effects are negligible.
  2. [V-A (CPU baseline) and V-B (Type 4 indirect)] The ACiS side of the direct-network comparison uses parameters measured with ExaMPI over TCP/IP on Xeon E5-2620v2 hosts connected back-to-back via Alveo U280 FPGAs, while the baseline is TACC Stampede2 SKX with Intel MPI 18.0.2 over Omni-Path. The reported speedups therefore conflate the ACiS hardware effect with differences in MPI implementation, network fabric, and host platform; in particular, the 14.8 usec MPI overhead in Table II is ExaMPI-specific and should not be compared directly to an Intel MPI baseline. The indirect Type 4 result has the same issue because it is compared against MPI4py, a Python MPI implementation, rather than a production MPI. Please report the baseline on the same MPI, network, and host as the ACiS testbed, or explicitly limit the claims to the specific software/hardware stack measured.
  3. [V-B (Type 2 simulation setup)] The simulations intentionally use one process per node to isolate the design from PCIe and host contention. This means the 32-128 node results do not include the host/MPI process interactions, progress-engine costs, multi-process contention, or communication-computation overlap effects that determine real application performance. Since the paper claims transparent acceleration of MPI applications (GCN, NPB, miniFE), the single-process-per-node restriction is a substantial caveat; please provide multi-process-per-node results or clearly scope the claims to single-process-per-node regimes.
  4. [Introduction and Section IV (Fig. 1)] The introduction claims that ACiS hardware can be added to a switch 'without changing standard dataplane architecture or loss of non-ACiS performance,' but no experiment or simulation measures the impact of the additional payload parser/deparser, aggregation unit, or recirculate interface on ordinary non-ACiS traffic. This is a load-bearing availability claim and should be supported with switch throughput/latency measurements with the plugin present versus absent, or softened to reflect that it has not been measured.
minor comments (6)
  1. [VI] The phrase 'automatically find where ACiS collectives could collectives' contains a typo; it should be 'could replace collectives' or similar.
  2. [VI-C] The sentence 'The we take, however, is based on an automated mining' should read 'The approach we take'.
  3. [Figure 6] The label 'SP-121-t1' is inconsistent with the text and with the other labels; it should presumably be 'SP-128-t1'.
  4. [References] References [9] and [10] are the same BluesMPI paper, and references [41] and [42] are the same ISCA paper; these duplicates should be merged.
  5. [III] The sentence 'we are not aware of previous work that fully supports user-defined or complex collectives (Types 2 and 3) or in any way addresses look-aside capability (Type 4)' has incorrect type numbers: look-aside is Type 3, and fused collectives are Type 4.
  6. [V-B] The Type 3 text says 'four datasets' but then lists five (PPI, Citeseer, Pubmed, ogbn-mag, ogbn-products); also, the number of runs and variance for the FPGA/emulator results in Figures 3 and 4 are not stated, unlike Figure 6.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: ACiS is a taxonomy plus an empirical evaluation; the speedups come from FPGA testbed measurements, RTL simulation, and an emulator parameterized by independently measured quantities, not from outputs folded back into inputs.

full rationale

The paper's load-bearing claims are a taxonomy (Types 0-4), a modular hardware design, and measured speedups for MPI collectives, GCN, NPB, and miniFE. The taxonomy is definitional, but definitional framing is not circular: the types are not derived from the speedups, and the hardware plugins are presented as design choices rather than as consequences of the evaluation. The direct-network results are produced by an emulator using independently measured parameters from Table II (MPI overhead, network bandwidth, PCIe latency, FPGA-to-FPGA latency, port-to-port latency) plus cycle-accurate RTL simulation of the accelerator. The emulator follows the requirements of [42] (same traffic volume, same hop count, accurate accelerator overhead); this is an extrapolation from a two-FPGA back-to-back testbed to a 128-node 3D-torus, and the lack of validation for contention, queuing, and recirculation at scale is a real validity threat, but it is not circularity because no target result is used to tune the model. The paper does lean heavily on the authors' prior work ('With ACiS we unify and expand our previous work [24], [28], [29], [31]' and 'Efficacy of ACiS has been demonstrated [24], [28], [29], [31]'), but these are empirical, externally checkable publications rather than an imported uniqueness theorem or an ansatz smuggled in by citation. Self-citation alone is not circular under the stated rules, and no equation or fitted parameter is renamed as a prediction. The central derivation chain is therefore not circular; the main weakness is an unvalidated emulation methodology, which is a correctness risk rather than a circularity.

Assumptions & free parameters 5 free parameters · 3 assumptions · 1 invented entities

The central performance claims depend on a set of emulation parameters measured from a two-node direct testbed and on the assumption that these parameters extrapolate to a 128-node 3D-torus. The taxonomies and architecture are the authors' own designs, validated only by the same group's implementations. The S2S compiler and full MPI transparency are described as future work, adding another layer of assumption to the stated capabilities.

free parameters (5)
  • MPI_Overhead = 14.8 usec
    Measured from ExaMPI on the two-board testbed; used in the emulator to add per-message host overhead for all simulated ACiS nodes. If actual MPI overhead varies with scale, the speedup estimates change.
  • FPGA_to_FPGA_Latency = 0.44 usec
    Aurora IP latency measured on the two-board direct link; used in the network emulation for all inter-node transfers.
  • Max_Network_BW = 95.9 Gbps
    Measured maximum bandwidth of the two-board QSFP28 link; assumed available at 128-node scale in the emulator.
  • PCIe_Latency = 0.9 usec
    Measured PCIe latency between host and FPGA; included in emulated collectives.
  • Min_Port_to_Port_Latency = 52 nsec
    Switch port-to-port latency used in the network emulation; may be optimistic for a fully-loaded 3D-torus at scale.
assumptions (3)
  • domain assumption The analytical emulator satisfies the same requirements as [42]: same traffic volume, identical network hops, and accurate accelerator overhead.
    Section V-A states the emulation should possess these properties but provides no validation that a two-node-derived parameter set reproduces 128-node 3D-torus behavior.
  • domain assumption ACiS can be added to a switch without changing the standard dataplane or degrading non-ACiS performance.
    Stated in Section I but never measured in the paper.
  • domain assumption MPI implementations can be transparently modified to use a new FPGA-directed transport.
    Section VI-A describes a new transport layer and an ExaMPI modification; no evidence of full transparency across MPI implementations is provided.
invented entities (1)
  • ACiS accelerator plugin (CGRA with SPUs and off-chip memory interfaces) independent evidence
    purpose: Executes user-defined, stateful, and fused collective operations in the switch dataplane.
    The authors' prior work and the two-board FPGA testbed provide some implementation evidence, but the 128-node performance is from simulation, so the entity is only partially validated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ACiS: Complex Processing in the Switch Fabric." pith.science (2026). https://pith.science/paper/CJHA3P7U

@misc{pith2026250118749,
  author       = {Pith},
  title        = {Pith review of: ACiS: Complex Processing in the Switch Fabric},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CJHA3P7U}},
  note         = {Machine review of arXiv:2501.18749}
}
read the original abstract

For the last three decades a core use of FPGAs has been for processing communication: FPGA-based SmartNICs are in widespread use from the datacenter to IoT. Augmenting switches with FPGAs, however, has been less studied, but has numerous advantages built around the processing being moved from the edge of the network to the center. Communication switches have previously been augmented to process collectives, e.g., IBM BlueGene and Mellanox SHArP, but the support has been limited to a small set of predefined scalar operations and datatypes. Here we present ACiS, a framework and taxonomy for Advanced Computing in the Switch that unifies and expands our previous work in this area. In addition to fixed scalar collectives (Type 1), we propose three more types of in-switch application processing: (Type 2) User-defined operations and types, including data structures; (Type 3) Look-aside operations that have state within the operation and can have loops; and (Type 4) Fused collectives built by fusing multiple existing collectives or collectives with map computations. ACiS is supported in hardware with modular switch extensions including a CGRA architecture. Software support for ACiS includes evaluation and translation of relevant parts of user programs, compilation of user specifications into control flow graphs, and mapping the graphs into switch hardware. The overall goal is the transparent acceleration of HPC applications encapsulated within an MPI implementation.

Figures

Figures reproduced from arXiv: 2501.18749 by the authors.

Figure 1
Figure 1. The well-known Protocol Independent Switch Architecture (PISA) enhanced with ACiS accelerator, a composable plugin to a packet processing pipeline (one pipe shown). White blocks are proposed and grey blocks are in existing switches. TABLE I ACIS TYPES REFERENCE Type 0 Processing single data streams Type 1 Collectives on primitive types Type 2 User defined operations and types Type 3 Look-aside processing - loops and… view at source ↗
Figure 2
Figure 2. The proposed CGRA architecture used in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. ACiS vs MPI CPU cluster (SKX) execution times for 32, 64, and 128 nodes: (a) osu [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Application performance and scalability comparison of GCN on a baseline CPU cluster (SKX) vs. ACiS. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: Performance improvement of ACiS over original MPI implementation [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

64 extracted references · 54 canonical work pages

  1. [1]

    ECP Proxy Applications: miniFE Catalog,

    “ECP Proxy Applications: miniFE Catalog,” https://proxyapps. exascaleproject.org/app/minife/

  2. [2]

    NAS Parallel Benchmarks,

    “NAS Parallel Benchmarks,” https://www.nas.nasa.gov/software/npb. html

  3. [3]

    OSU Micro-benchmarks

    “OSU Micro-benchmarks.” [Online]. Available: http://mvapich.cse.ohio- state.edu/benchmarks/

  4. [4]

    Optimization of MPI collective communication on BlueGene/L systems,

    G. Alm `asi, P. Heidelberger, C. J. Archer, X. Martorell, C. C. Erway, J. E. Moreira, B. Steinmacher-Burow, and Y . Zheng, “Optimization of MPI collective communication on BlueGene/L systems,” in Proceedings of the 19th annual international conference on Supercomputing (ICS’05) , 2005, pp. 253–262

  5. [5]

    Offloading Collective Operations to Pro- grammable Logic on a Zynq Cluster,

    Arap, O. and Swany, M., “Offloading Collective Operations to Pro- grammable Logic on a Zynq Cluster,” in High-Performance Intercon- nects (HOTI), 2016 IEEE 24th Annual Symp. on , 2016, pp. 76–83

  6. [6]

    FPGA Programmable Acceleration Card D5005,

    Intel, “FPGA Programmable Acceleration Card D5005,” https://www.intel.com/content/www/us/en/programmable/products/ boards and kits/dev-kits/altera/intel-fpga-pac-d5005/overview.html [Last accessed: April 29, 2021]

  7. [7]

    Alveo SmartNIC Accelerator Card,

    Xilinx, “Alveo SmartNIC Accelerator Card,” https://www.xilinx.com/ products/boards-and-kits/alveo.html [Last accessed: April 29, 2021]

  8. [8]

    Alveo SN1000 Accelerator Card,

    Xilinx, “Alveo SN1000 Accelerator Card,” https://www.xilinx.com/ applications/data-center/network-acceleration/alveo-sn1000.html [Last accessed: April 29, 2021]

Show all 64 references
  1. [9]

    BluesMPI: Efficient MPI Non-blocking Alltoall Offloading Designs on Modern BlueField Smart NICs,

    M. Bayatpour, N. Sarkauskas, H. Subramoni, J. M. Hashmi, and D. K. Panda, “BluesMPI: Efficient MPI Non-blocking Alltoall Offloading Designs on Modern BlueField Smart NICs,” in High Performance Computing. Springer International Publishing, 2021, pp. 18–37

  2. [10]

    BluesMPI: Efficient MPI Non-blocking Alltoall Offloading De- signs on Modern BlueField Smart NICs,

    ——, “BluesMPI: Efficient MPI Non-blocking Alltoall Offloading De- signs on Modern BlueField Smart NICs,” in High Performance Com- puting. Springer International Publishing, 2021, pp. 18–37

  3. [11]

    P4: Programming Protocol-Independent Packet Processors,

    P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker, “P4: Programming Protocol-Independent Packet Processors,” SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, p. 87–95, 2014

  4. [12]

    A cloud-scale acceleration architecture,

    A. Caulfield, E. Chung, A. Putnam, H. Angepat, J. Fowers, M. Hasel- man, S. Heil, M. Humphrey, P. Kaur, J.-Y . Kim, D. Lo, T. Massengill, K. Ovtcharov, M. Papamichael, L. Woods, S. Lanka, D. Chiou, and D. Burger, “A cloud-scale acceleration architecture,” in 49th IEEE/ACM Int....

  5. [13]

    Serving dnns in real time at datacenter scale with project brainwave,

    E. Chung, J. Fowers, K. Ovtcharov, M. Papamichael, A. Caulfield, T. Massengill, M. Liu, D. Lo, S. Alkalay, M. Haselman, M. Abeydeera, L. Adams, H. Angepat, C. Boehn, D. Chiou, O. Firestein, A. Forin, K. S. Gatlin, M. Ghandi, S. Heil, K. Holohan, A. El Husseini, T. Juhasz, K. K...

  6. [14]

    mpi4py: Status update after 12 years of development,

    L. Dalcin and Y .-L. L. Fang, “mpi4py: Status update after 12 years of development,” Computing in Science and Engineering , vol. 23, no. 4, pp. 47–54, 2021

  7. [15]

    Paxos made switch-y,

    H. T. Dang, M. Canini, F. Pedone, and R. Soul ´e, “Paxos made switch-y,” SIGCOMM Comput. Commun. Rev. , vol. 46, no. 2, p. 18–24, may

  8. [16]

    Flare: Flexible in-network allreduce,

    D. DeSensi, S. D. Girolamo, S. Ashkboos, S. Li, and T. Hoefler, “Flare: Flexible in-network allreduce,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’21, 2021

  9. [17]

    MPI col- lective communications on the blue gene/P supercomputer: Algorithms and optimizations,

    A. Faraj, S. Kumar, B. Smith, A. Mamidala, and J. Gunnels, “MPI col- lective communications on the blue gene/P supercomputer: Algorithms and optimizations,” Proceedings - Symposium on the High Performance Interconnects, Hot Interconnects , pp. 63–72, 2009

  10. [18]

    Azure accelerated networking: SmartNICs in the public cloud,

    D. Firestone, A. Putnam, S. Mundkur, D. Chiou, A. Dabagh, M. Andrewartha, H. Angepat, V . Bhanu, A. Caulfield, E. Chung, H. K. Chandrappa, S. Chaturmohta, M. Humphrey, J. Lavier, N. Lam, F. Liu, K. Ovtcharov, J. Padhye, G. Popuri, S. Raindel, T. Sapre, M. Shaw, G. Silva, M. Si...

  11. [19]

    Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction,

    R. L. Graham and et al., “Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction,” in 2016 Workshop on Communication Optimizations in HPC , 2016

  12. [20]

    Scalable hierarchical aggregation and reduc- tion protocol (sharp)tm streaming-aggregation hardware design and evaluation,

    R. L. Graham, L. Levi, D. Burredy, G. Bloch, G. Shainer, D. Cho, G. Elias, D. Klein, J. Ladd, O. Maor, A. Marelli, V . Petrov, E. Romlet, Y . Qin, and I. Zemah, “Scalable hierarchical aggregation and reduc- tion protocol (sharp)tm streaming-aggregation hardware design and eval...

  13. [21]

    A Framework for Neural Network Inference on FPGA-Centric SmartNICs,

    A. Guo, T. Geng, Y . Zhang, P. Haghi, C. Wu, C. Tan, Y . Lin, A. Li, and M. Herbordt, “A Framework for Neural Network Inference on FPGA-Centric SmartNICs,” in International Confer- ence on Field-Programmable Logic and Applications , 2022, dOI: 10.1109/FPL57034.2022.00071

  14. [22]

    FCsN: A FPGA-Centric SmartNIC Framework for Neural Networks,

    ——, “FCsN: A FPGA-Centric SmartNIC Framework for Neural Networks,” in 30th IEEE International Symposium on Field-Programmable Custom Computing Machines , 2022, dOI: 10.1109/FCCM53951.2022.9786193

  15. [24]

    ACIS: smart switches with application-level acceleration,

    P. Haghi, “ACIS: smart switches with application-level acceleration,” Ph.D. dissertation, Department of Electrical and Computer Engineering, Boston University, 2023

  16. [25]

    FP-AMG: FPGA-Based Acceleration Framework for Algebraic Multigrid Solvers,

    P. Haghi, T. Geng, A. Guo, T. Wang, and M. Herbordt, “FP-AMG: FPGA-Based Acceleration Framework for Algebraic Multigrid Solvers,” in 28th IEEE International Symposium on Field-Programmable Custom Computing Machines, 2020, dOI: 10.1109/ FCCM48280.2020.00028

  17. [26]

    Reconfigurable Compute-in-the-Network FPGA Assistant for High-Level Collective Support with Distributed Matrix Multiply Case Study,

    ——, “Reconfigurable Compute-in-the-Network FPGA Assistant for High-Level Collective Support with Distributed Matrix Multiply Case Study,” in IEEE Conference on Field Programmable Technology , 2020

  18. [27]

    Workload Imbalance in HPC Applications: Effect on Performance of In-Network Processing,

    P. Haghi, A. Guo, T. Geng, A. Skjellum, and M. Herbordt, “Workload Imbalance in HPC Applications: Effect on Performance of In-Network Processing,” in IEEE High Performance Extreme Computing Confer- ence, 2021, doi: 10.1109/HPEC49654.2021.9622847

  19. [28]

    Reconfigurable switches for high performance and flexible MPI collectives,

    P. Haghi, A. Guo, Q. Xiong, C. Yang, T. Geng, J. Broaddus, R. Marshall, D. Schafer, A. Skjellum, and M. Herbordt, “Reconfigurable switches for high performance and flexible MPI collectives,” Concurrency and Computation: Practice and Experience , vol. 34, no. 2, 2022, doi: 10.1...

  20. [29]

    FLASH: FPGA-Accelerated Smart Switches with GCN Case Study,

    P. Haghi, W. Krska, C. Tan, T. Geng, P. Chen, C. Greenwood, A. Guo, T. Hines, C. Wu, A. Li, A. Skjellum, and M. Herbordt, “FLASH: FPGA-Accelerated Smart Switches with GCN Case Study,” in 37th ACM International Conference on Supercomputing (ICS) , 2023, dOI = 10.1145/3577193.3593739

  21. [30]

    A Survey of Potential MPI Complex Collectives: Large-Scale Mining and Analysis of HPC Applications,

    P. Haghi, R. Marshall, A. Skjellum, and M. Herbordt, “A Survey of Potential MPI Complex Collectives: Large-Scale Mining and Analysis of HPC Applications,” 2023

  22. [31]

    Smartfuse: Reconfigurable smart switches to accelerate fused collectives in hpc applications,

    P. Haghi, C. Tan, A. Guo, C. Wu, D. Liu, A. Li, A. Skjel- lum, T. Geng, and M. Herbordt, “Smartfuse: Reconfigurable smart switches to accelerate fused collectives in hpc applications,” in 38th ACM International Conference on Supercomputing (ICS) , 2024, dOI: 10.1145/3650200.3656616

  23. [32]

    OCT: The Open Cloud FPGA Testbed,

    S. Handagala, M. Herbordt, and M. Leeser, “OCT: The Open Cloud FPGA Testbed,” in 31st International Conference on Field Pro- grammable Logic and Applications (FPL) , 2021, doi: TBD

  24. [33]

    Easynet: 100 gbps network for hls,

    Z. He, D. Korolija, and G. Alonso, “Easynet: 100 gbps network for hls,” in 2021 31st International Conference on Field-Programmable Logic and Applications (FPL) . Los Alamitos, CA, USA: IEEE 7 Computer Society, sep 2021, pp. 197–203. [Online]. Available: https://doi.ieeecomput...

  25. [34]

    The effect of network noise on large-scale collective communications

    T. Hoefler, T. Schneider, and A. Lumsdaine, “The effect of network noise on large-scale collective communications.” Parallel Processing Letters, vol. 19, pp. 573–593, 12 2009

  26. [35]

    Event-Driven Packet Processing,

    S. Ibanez, G. Antichi, G. Brebner, and N. NcKeown, “Event-Driven Packet Processing,” in 18th ACM Workshop on Hot Topics in Networks , 2019

  27. [36]

    FPGA SmartNIC C5020X,

    Inventec, “FPGA SmartNIC C5020X,” https://ebg.inventec.com/en/ product/Accessories/Smart%20NIC%20Card/Inventec%20FPGA% 20SmartNIC%20C5020X [Last accessed: April 29, 2021]

  28. [37]

    P4db - the case for in-network oltp,

    M. Jasny, L. Thostrup, T. Ziegler, and C. Binnig, “P4db - the case for in-network oltp,” in Proceedings of the 2022 International Conference on Management of Data , ser. SIGMOD ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 1375–1389. [Online]. Availabl...

  29. [38]

    Netcache: Balancing key-value stores with fast in-network caching,

    X. Jin, X. Li, H. Zhang, R. Soul ´e, J. Lee, N. Foster, C. Kim, and I. Stoica, “Netcache: Balancing key-value stores with fast in-network caching,” in Proceedings of the 26th Symposium on Operating Systems Principles, ser. SOSP ’17. New York, NY , USA: Association for Computin...

  30. [39]

    LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation,

    C. Lattner and V . Adve, “LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation,” in Proceedings of the Interna- tional Symposium on Code Generation and Optimization: Feedback- Directed and Runtime Optimization , ser. CGO ’04. USA: IEEE Computer Society,...

  31. [40]

    Clicknp: Highly flexible and high performance network pro- cessing with reconfigurable hardware,

    B. Li, K. Tan, L. Luo, Y . Peng, R. Luo, N. Xu, Y . Xiong, P. Cheng, and E. Chen, “Clicknp: Highly flexible and high performance network pro- cessing with reconfigurable hardware,” in Conference on Applications, Technologies, Architectures, and Protocols for Computer Communica...

  32. [41]

    Accel- erating distributed reinforcement learning with in-switch computing,

    Y . Li, I.-J. Liu, Y . Yuan, D. Chen, A. Schwing, and J. Huang, “Accel- erating distributed reinforcement learning with in-switch computing,” in Proceedings of the 46th International Symposium on Computer Architecture, 2019, p. 279–291

  33. [42]

    Accelerating Distributed Reinforcement learning with In-Switch Computing,

    ——, “Accelerating Distributed Reinforcement learning with In-Switch Computing,” in 2019 ACM/IEEE 46th Annual International Symposium on Computer Architecture (ISCA) , 2019, pp. 279–291

  34. [43]

    Incbricks: Toward in-network computation with an in-network cache,

    M. Liu, L. Luo, J. Nelson, L. Ceze, A. Krishnamurthy, and K. Atreya, “Incbricks: Toward in-network computation with an in-network cache,” SIGARCH Comput. Archit. News , vol. 45, no. 1, p. 795–809, apr 2017. [Online]. Available: https://doi.org/10.1145/3093337.3037731

  35. [45]

    Innova-2 Flex Open Programmable SmartNIC,

    Mellanox, “Innova-2 Flex Open Programmable SmartNIC,” https://www. mellanox.com/files/doc-2020/pb-innova-2-flex.pdf [Last accessed: April 29, 2021]

  36. [46]

    The programmable data plane: Abstractions, architectures, algorithms, and applications,

    O. Michel, R. Bifulco, G. R ´etv´ari, and S. Schmid, “The programmable data plane: Abstractions, architectures, algorithms, and applications,” ACM Comput. Surv., vol. 54, no. 4, 2021

  37. [47]

    Intel’s best dpu will be commercially available – someday,

    T. Morgan, “Intel’s best dpu will be commercially available – someday,” The Next Platform , vol. August 31, 2021, 2021

  38. [48]

    FPGA acceleration cards,

    Napatech, “FPGA acceleration cards,” https://www.napatech.com/ products/ [Last accessed: April 29, 2021]

  39. [49]

    Web page for P4 Opensource Programming Language,

    P4 Team, “Web page for P4 Opensource Programming Language,” https://opennetworking.org/p4/, accessed 10/30/2022

  40. [50]

    Does the Repurposing of Sun Microsystems’ Slogan Honor History, or Step on It?

    T. Perry, “Does the Repurposing of Sun Microsystems’ Slogan Honor History, or Step on It?” IEEE Spectrum), no. 30 July, 2019

  41. [51]

    Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction,

    R.L. Graham, et al., “Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction,” in First International Workshop on Communication Optimizations in HPC (COMHPC), 2016

  42. [52]

    Leveraging In-Network Computing and Programmable Switches for Streaming Analysis of Scientific Data,

    G. Sankaran, J. Chung, and R. Kettimuthu, “Leveraging In-Network Computing and Programmable Switches for Streaming Analysis of Scientific Data,” in IEEE NetSoft, 2021, pp. 293–297

  43. [53]

    Scaling distributed machine learning with In-Network aggregation,

    A. Sapio, M. Canini, C.-Y . Ho, J. Nelson, P. Kalnis, C. Kim, A. Krish- namurthy, M. Moshref, D. Ports, and P. Richtarik, “Scaling distributed machine learning with In-Network aggregation,” in 18th USENIX Sym- posium on Networked Systems Design and Implementation (NSDI 21) , 2...

  44. [54]

    Runtime verification of p4 switches with reinforcement learning,

    A. Shukla, K. N. Hudemann, A. Hecker, and S. Schmid, “Runtime verification of p4 switches with reinforcement learning,” in Workshop on Network Meets AI & ML , 2019

  45. [55]

    FPGA SmartNIC N5010 Series,

    Silicom, “FPGA SmartNIC N5010 Series,” https://www.silicom- usa.com/pr/fpga-based-cards/fpga-intel-based/fpga-intel-stratix- based/silicom-fpga-smartnic-n5010 series/ [Last accessed: April 29, 2021]

  46. [56]

    ExaMPI: A Modern Design and Implementation to Accelerate Message Passing Interface Innovation,

    A. Skjellum and et al, “ExaMPI: A Modern Design and Implementation to Accelerate Message Passing Interface Innovation,” Communications in Computer and Information Science , vol. 1087 CCIS, pp. 153–169, 2020

  47. [57]

    Exampi: A modern design and implementation to accelerate message passing interface innovation,

    A. Skjellum, M. R ¨ufenacht, N. Sultana, D. Schafer, I. Laguna, and K. Mohror, “Exampi: A modern design and implementation to accelerate message passing interface innovation,” in High Performance Computing, J. L. Crespo-Mari ˜no and E. Meneses-Rojas, Eds. Cham: Springer Intern...

  48. [58]

    Stampede 2: The Evolution of an XSEDE Supercomputer,

    D. Stanzione, B. Barth, N. Gaffney, K. Gaither, C. Hempel, T. Minyard, S. Mehringer, E. Wernert, H. Tufo, D. Panda, and P. Teller, “Stampede 2: The Evolution of an XSEDE Supercomputer,” in Practice and Experience in Advanced Research Computing on Sustainability, Success and Im...

  49. [59]

    Taurus: A data plane architecture for per-packet ml,

    T. Swamy, A. Rucker, M. Shahbaz, I. Gaur, and K. Olukotun, “Taurus: A data plane architecture for per-packet ml,” in Proceedings of the 27th ACM International Conference on Architectural Support for Program- ming Languages and Operating Systems , ser. ASPLOS 2022, 2022, p. 1099–1114

  50. [60]

    Enabling flexible collective com- munication offload with triggered operations,

    K. D. Underwood, J. Coffman, R. Larsen, K. S. Hemmert, B. W. Barrett, R. Brightwell, and M. Levenhagen, “Enabling flexible collective com- munication offload with triggered operations,” in IEEE 19th Symposium on High Performance Interconnects , 2011, pp. 35–42

  51. [61]

    Heavy hitter detection on multi-pipeline switches,

    F. L. Verdi and M. Chiesa, “Heavy hitter detection on multi-pipeline switches,” in Symp. on Architectures for Networking and Communica- tions Systems, 2022

  52. [62]

    XUP Vitis Network Example (VNx),

    Xilinx, “XUP Vitis Network Example (VNx),” https://github.com/Xilinx/ xup vitis network example, 2023

  53. [63]

    GhostSZ: A Transparent SZ Lossy Compression Framework with FPGAs,

    Q. Xiong, C. Yang, R. Patel, T. Geng, A. Skjellum, and M. Herbordt, “GhostSZ: A Transparent SZ Lossy Compression Framework with FPGAs,” in 2019 IEEE 27th Annual International Symposium on Field- Programmable Custom Computing Machines (FCCM) , 2019, pp. 258– 266, doi: 10.1109/F...

  54. [64]

    How is Data Ops Related to Data Centric Computing?

    H. Yoshida, “How is Data Ops Related to Data Centric Computing?” Hi- tachi Blog, https:// community.hitachivantara.com/ blogs/hubert-yoshida/ 2020/10/14/ how-is-data-ops-related-to-data-centric-computing, 2020. 8

  55. [2016]

    Available: https://doi.org/10.1145/2935634.2935638

    [Online]. Available: https://doi.org/10.1145/2935634.2935638

  56. [2020]

    Available: https://arxiv.org/abs/2009.09736

    [Online]. Available: https://arxiv.org/abs/2009.09736

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.