Code Monkey home page Code Monkey logo

enso's Introduction

Ensō

docs DOI

Enso

Ensō is a high-performance streaming interface for NIC-application communication.

Ensō's design encompasses both hardware and software. The hardware component targets an FPGA NIC1 and implements the Ensō interface. The software component uses this interface and exposes simple communication primitives called Ensō Pipes. Applications can use Ensō Pipes to send and receive data in different formats, such as raw packets, application-level messages, or TCP-like byte streams.

Refer to the OSDI '23 paper for details about the design and to the documentation to find out how to use Ensō for your own projects.

Why Ensō?

Traditionally, NICs expose a packetized interface that software (applications or the kernel) must use to communicate with the NIC. Ensō provides two main advantages over this interface:

  • Flexibility: While NICs were traditionally in charge of delivering raw packets to software, an increasing amount of high-level functionality is now performed on the NIC. The packetized interface, however, forces data to be fragmented into packets that are then scattered across memory. This prevents the NIC and the application from communicating efficiently using higher-level abstractions such as application-level messages or TCP streams. Ensō instead allows the NIC and the application to communicate using a contiguous stream of bytes, which can be used to represent arbitrary data.
  • Performance: By forcing hardware and software to synchronize buffers for every packet, the packetized interface imposes significant per-packet overhead both in terms of CPU cycles as well as PCIe bandwidth. This results in significant performance degradation, in particular when using small requests. Ensō's use of a byte stream interface allows the NIC and the application to exchange multiple packets (or messages) at once, which reduces the number of CPU cycles and PCIe transactions required to communicate each request. Moreover, by placing packets (or messages) contiguously in memory, Ensō makes better use of the CPU prefetcher, vastly reducing the number of cache misses.

Getting started

Footnotes

  1. Network Interface Cards (NICs) are the hardware devices that connect a computer to the network. They are responsible for transmitting data from the CPU to the network and vice versa. FPGAs are reconfigurable hardware devices. They can be reconfigured to implement arbitrary hardware designs. Here we use an FPGA to implement a NIC with the Ensō interface but the same interface could also be implemented in a traditional fixed-function hardware.

enso's People

Contributors

glass-hash avatar hellokayt avatar hsadok avatar kaajalbgupta avatar natre avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

enso's Issues

Avoid accidental deallocation of `Device` object

Issue: As of now Device::Create returns an std::unique_ptr<Device>. As such, if the device gets out of scope it's deallocated. This might be an issue for applications that only use the Device object during initialization and decide not to keep it around.

Potential Solution: Perhaps it is better to use std::shared_ptr here as well as for the device_ class member in all types of pipe (including RxPipe, which currently does not hold a device_ member). This way, as long as at least one pipe is allocated, we will keep the Device object around.

Documentation updates

Running list of suggested doc changes (because Nirav has terrible memory):

  • Include steps for linking against Enso
  • Clarify Device::Bind() arguments. For instance: acceptable values for protocol, endianness for port and IP parameters.
  • Clarify relationship between nb_queues and RX pipe count (https://crossroadsfpga.github.io/enso/primitives/device/)
  • Clarify that pipes are not meant for concurrent access (not thread-safe)
  • Describe the Device::Bind() return value
  • Add footnotes about safe handling of corner cases (e.g., SendAndFree(0))
  • Add warning about Device::Create() returning a std::unique_ptr

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.