Page MenuHomeVyOS Platform

Implement DPDK Fast-Path using FRR's Alternate Forwarding Planes and VPP
Not ApplicablePublicFEATURE REQUEST

Assigned To
None
Authored By
xrobau
Nov 10 2019, 11:45 PM
Tags
None
Referenced Files
None
Tokens
"Like" token, awarded by bbabich."Like" token, awarded by jack9603301."Like" token, awarded by trae32566."Like" token, awarded by rherold.

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

Version
-
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)

Related Objects

StatusSubtypeAssignedTask
Not ApplicableFEATURE REQUESTNone
ResolvedFEATURE REQUESTViacheslav
InvalidFEATURE REQUESTNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

Unknown Object (User) subscribed.Jul 10 2020, 9:10 AM

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 edited a custom field.

Is there some progress? VPP is available for AArch64 in meantime.
Here some news about VPP performance:

https://twitter.com/IPngNetworks/status/1585404421118529539

There will be a talk at denog14.

I really would like the idea to have the possibility with vyos forwarding > 100G especially in this times where the big player has problems deliver hardware in time.

The enhanced linux-cp plugin (from IPng) is since 21.06 an official part of VPP, so the integration should be simple:
https://vpp.flirble.org/master/aboutvpp/releasenotes/v21.06.html#linux-control-plane-plugin-linux-cp

This comment was removed by jack9603301.
syncer raised the priority of this task from Wishlist to Normal.Nov 16 2022, 9:29 PM

Now as linux-cp available we can consider adding support

dmbaturin set Issue type to Unspecified (please specify).
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
dmbaturin changed Issue type from Unspecified (please specify) to Feature (new functionality).
dmbaturin subscribed.

VPP dataplane is developed as an add-on, so it's not applicable to the mainline VyOS image now.