The DPDK (Data Plane Development Kit) is an exciting project that delivers high performance networking by allowing low-level networking functions to be performed in user space applications, instead of in the Linux kernel.
If you are not familiar with DPDK, you can find out more information at the following links:
In this article, I will show you how to build and configure DPDK and run a simple web application using the Seastar application framework.
As described on the project home page:
Seastar is an advanced, open-source C++ framework for high-performance server applications on modern hardware.
One of the fascinating features of Seastar is its support of DPDK on Linux systems. This is one of the first application frameworks I have seen that supports DPDK so I was very excited when I stumbled upon it.
I’m currently working with Vert.x, which is an excellent application toolkit for building high performance reactive applications on the JVM. Vert.x is well known for its excellent performance, and I’ve struggled to find alternatives that match it in terms of speed.
On paper, Seastar looks like it could be a worthy challenger to Vert.x in terms of performance, given it is developed in C++ and its support of DPDK.
So I decided to give Seastar a go.
The hardware used was an Intel NUC with the following specifications:
- Intel Core i3 4010U (dual-core 1.7GHz)
- 4GB RAM
- 30GB SSD
- Intel I218 Gigabit Ethernet NIC
- Hyperthreading disabled (this is enabled by default in the UEFI BIOS)
DPDK only works on supported network interfaces and you’ll note that the I218 is not on the supported list. Unperturbed I decided to press on and as you’ll find out later on, I actually had to modify the DPDK source code to get DPDK working with the I218 network interface.
Preparing the Operating System
Most of the examples in the Seastar documentation are based upon Fedora so I decided to use Fedora 22 Server for my testing. I’ll skip the details on installation of Fedora 22 - I just used a typical installation and didn’t do anything special during the installation.
Both Seastar and DPDK need to be built from source, so you need to install a number of development related dependencies.
When building DPDK, you need to create a kernel module so it’s important to install the relevent kernel development packages that are matched to your system kernel. This can be achieved most quickly by first upgrading your system and then installing the kernel development packages:
If you miss the upgrade step, chances are your system kernel will be an older kernel version than the kernel development packages and things will break.
Seastar has a number of development dependencies, which are listed in the Fedora 21 section of the main README file on the Seastar Github home project page:
In addition to the above, you need Git (to download the Seastar and DPDK source) and a couple of other libraries that are required when building Seastar on Fedora 22:
Hugepage support is required for the large memory pool allocation used for packet buffers. I won’t go into details but you can read more about it in this document.
There are two typical hugepage sizes:
All modern hardware should at least support 2MB hugepages but you can check if your system supports 1GB hugepages as follows:
You are looking for a couple of values in the flags section:
- 2MB hugepages are supported
- 1GB hugepages are supported
In the example above, you can see that 1GB hugepages are supported.
To enable hugepages you need to first add the following line to
Both examples above allocate 1GB of memory in total to hugepages. In my case, I allocated a single 1GB hugepage.
Next you need to update your Grub configuration. Note these instructions are for Fedora.
In my case, the Intel NUC is a UEFI system so I used the latter command above.
You now need to mount the hugetable file system by adding the following entry to
And finally reboot and verify hugepages has been configured correctly:
Getting the DPDK and Seastar Source
The Seastar Git repository includes the DPDK repository as a submodule, and under normal circumstances you can build Seastar with DPDK support, without needing to build DPDK manually yourself.
In my case however, in order to support the Intel I218 network interface card I actually had to make some modifications to the DPDK source code. The modifications are included in a fork I created from the DPDK repository.
I can’t take any credit for the changes - I found a DPDK Mailing List thread from January 2015 that discussed a patch for adding I217/I218 support (but looks like it never made it in to the DPDK source) so I took the code from there with a few minor modications.
So for this example you need to clone my forked DPDK repository, and at the same time you should also clone the Seastar repository:
Alternatively you can apply this patch to the original DPDK source (bearing in mind I patched from the 2.1.0 release)
To build DPDK you first need to configure your DPDK build options - this is performed by editing the
file in the dpdk source root and modifying the following entries:
The configuration settings above are based upon instructions included in the Seastar project documentation.
With the configuration in place you need to build the DPDK target environment:
You are now ready to configure and build Seastar.
As described earlier, because of the requirement to use patched DPDK source code, you need to configure Seastar to build against a precompiled DPDK package (which you created in the last section).
You can do this by including the
flag when configuring the Seastar build:
--dpdk-target <path to dpdk source>/x86_64-native-linuxapp-gcc
script is located in the Seastar source root - note in addition to the
flag the following flags are required:
- this is required as DPDK and Xen support are mutually exclusive
- this allows you to constrain the sample applications that will be built, reducing the number of libraries that need to built to just those required to support the specified application. For this example, you only need the HTTP sample application.
With the configuration in place, you can now build Seastar:
The build will take a few minutes - you can see above 82 libraries are built.
If you omitted the
flag in the configuration (meaning build everything) you would need to build 148 libraries.
With DPDK and Seastar built, you are almost ready to run Seastar. Before doing so, you must bind the NUC network interface to DPDK.
First, you need to down the network interface that is to be used by DPDK.
This will allow DPDK to take control of the NIC, outside of the Linux kernel:
Next, you need to insert the necessary kernel modules required for DPDK. Note that the IGB_UIO module is located in the DPDK target you built previously:
Finally, you can bind the interface to DPDK using the
Running the script with the
flag binds the specified device
to the specified driver
flag shows that the network interface is now bound to the IGB_UIO driver.
At this point, you are ready to run Seastar. Seastar includes a basic example web application, which you can run as demonstrated below:
There’s quite a few options above you need to specify. Note that you can use the
command to review all of the available options. Each of the flags used in the example are described below:
- this configures the application to run using the Seastar native network stack, which is required when using DPDK.
- this configures the application to use DPDK
- this disables DHCP
- specifies the IPv4 address to run the application on
- specifies the subnet mask of the configured IPv4 address
- disables the CollectD daemon, which is used for collecting metrics and statistics
- this specifies the number of threads. For maximum performance, this should equal the number of physical CPU cores.
- the port the web server will run on. If omitted, the server will run on port 10000.
The application takes a few seconds to start up as shown in the output below:
The sample HTTP application is now up and running. Running a basic test should demonstrate the application is working:
And a quick performance test should show you some pretty impressive numbers:
Here I chuck 1M requests at the application over 500 concurrent connections running on four threads - 190,000+ requests per second - not too bad for a $300US computer!
I’m sure you already know who the winner will be ;)