contact@nubestack.com LinkedIn

NFV Solutions

Network functions at line rate, on ordinary servers

Virtualisation usually costs you throughput. We build telco-grade platforms where it doesn’t — packets reach the workload without paying the kernel tax on the way.

Talk to a network engineer

Built on

  • SR-IOV
  • DPDK
  • OVN
  • OpenStack
  • Kubernetes
NICwireSR-IOV · DPDKkernel bypassedline rate, minimal jitterkernel network stackcopies, context switcheswhere the throughput goesVNFrouter · firewall

The idea

Appliances become software, without becoming slow

NFV replaces proprietary routers, firewalls and load balancers with software on standard servers. Getting the function to run is the easy half. Keeping the throughput and the latency profile the appliance had is the job.

A rack of appliances

  • Throughput is whatever you bought
  • The refresh cycle is the vendor’s, not yours
  • A firewall is a thing somebody has to go and rack
  • Every function has its own console

Functions as software

  • Servers from anyone, refreshed when you choose
  • More capacity is another instance, not another box
  • Functions scale and move like any other workload
  • Deployed and versioned like the rest of the estate
NUMA NODE 0ONE HOP: WIRE TO WORKLOADNICthe wireVF 0VF 1VF 2SR-IOVHUGEPAGESpre-allocatedDPDKPINNED CORESpoll, never sleepisolated from the schedulerthe data plane never crosses the interconnectNUMA NODE 1 · other sockets, other cards

Each removes a different source of overhead, and each is wasted if the next is left undone. They get tuned together, or not at all.

Where line rate comes from

The performance is in the host, not on the datasheet

A fast card does nothing on its own. What survives of line rate is decided by how often the packet is copied, interrupted and rescheduled between the wire and the workload. The work is removing those, one at a time.
  • SR-IOV gives the function its own slice of the card, so packets never reach the hypervisor switch
  • DPDK polls that slice from user space — no per-packet interrupt, no kernel copy, no context switch
  • Hugepages hold the packet buffers, so the hot loop isn’t waiting on page walks
  • Pinning and NUMA placement keep the poll threads on cores of their own, on the node the card hangs off

Scope

What we take on

The fast path is the visible part. Most of the work is the platform that has to keep carrying it once the tuning is done.
  • The fast pathSR-IOV and DPDK integration tuned to your NICs, your CPU topology and your traffic profile — not to a reference design.
  • The fabric around itOVN overlays with distributed routing and security policy enforced in the fabric, driven by API rather than by ticket queue.
  • The platform underneathOpenStack or Kubernetes built to hand workloads the devices, hugepages and CPU topology they need — designed for 5G and edge rather than bent into shape afterwards.
  • Proof against your SLAThroughput, latency and jitter profiled on your hardware under your traffic, measured before anything is claimed.

In practice

Virtual routers that hold gigabit links

A provider needs virtual CPE — one router per customer, each carrying a gigabit connection. On stock Linux bridging the server runs out of CPU long before the NIC runs out of wire, and the density never arrives.

Line-rate performance per router. More customers per server, less hardware, lower latency.

  • Density many customer routers to a chassis, instead of an appliance each
  • Isolation every router gets its own slice of the card and cores nothing else is allowed to use
  • Headroom the ceiling moves back to the NIC, which is where it should have been

Why NubeStack

Performance work is a specialism

  • Measured

    We measure before we claim

    Benchmarks run against your traffic profile on your hardware, because nobody’s numbers survive a change of NIC, firmware or core count.

  • Supportable

    The platform, not just the tuning

    OpenStack and Kubernetes underneath, so the acceleration is something your team can operate and upgrade rather than a clever one-off.

  • Purpose-built

    Built for 5G, IoT and edge

    Designed around the latency budgets and bandwidth demands of real-time workloads rather than retrofitted to them.

Tell us what your traffic looks like

Throughput targets, latency budgets, the hardware you already own — bring the constraints and we'll tell you what's achievable.

Book a call