Page MenuHomeVyOS Platform

Implement DPDK Fast-Path using FRR's Alternate Forwarding Planes and VPP
Open, WishlistPublicFEATURE REQUEST

Description

There's a quick walkthrough on the FRRouting github page:

https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

This has been on the back of my mind for a while, and if you limit it to 'routing only', it would be a relatively simple change to set an interface to be 'fast-path' (or whatever) which then binds it to VPP (which also removes it from the kernel visibility)

FRR and VPP talk together without any problems, as per that wiki page.

I think stage 1 should totally ignore firewalling/filtering totally, and once an interface is in fast-path mode, no filtering can be done against it.

After the proof-of-concept of stage 1, we could switch to using veth interfaces, which VPP can also talk to (but not as efficiently as totally removing the entire NIC from the kernel), and then use network namespaces to route traffic to kernel iptables filtering if needed.

I'm putting this here, as this may be a project I do over the xmas break if I get around to it!

Details

Difficulty level
Hard (possibly days)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Related Objects

Event Timeline

In this way we could also add vpp nat64 running complete in vpp independent from all other vyos services:

https://wiki.fd.io/view/VPP/NAT

I mainly have 2 questions:

  1. Using DPDK may cause low configuration hardware to fail to install vyos?
  2. Is it possible to use DPDK and VPP to cause all services that depend on the system protocol stack to fail to discover the interface?

If you can provide users with options (the user decides whether to enable DPDK), that is what I always recommend

Viacheslav triaged this task as Wishlist priority.Feb 22 2021, 10:09 AM
Viacheslav changed Difficulty level from Unknown (require assessment) to Hard (possibly days).