[dpdk-dev] [PATCH v2] SDK: Add scripts to initialize DPDK runtime

Christian Ehrhardt christian.ehrhardt at canonical.com
Thu Jan 12 14:43:24 CET 2017

On Mon, Dec 19, 2016 at 4:15 PM, Thomas Monjalon <thomas.monjalon at 6wind.com>

> Thanks for sending your Debian/Ubuntu work.
> 2016-12-13 16:47, Luca Boccassi:
> > From: Christian Ehrhardt <christian.ehrhardt at canonical.com>
> >
> > A tools/init directory is added with dpdk-init, a script that can be
> > used to initialize a DPDK runtime environment. 2 config files with
> > default options, dpdk.conf and interfaces, are provided as well
> > together with a SysV init script and a systemd service unit.
> I have 2 concerns:
> - What does exactly mean "initialize a DPDK runtime environment"?
> Should it be documented somewhere?

Sorry for the late reply, Luca made me aware that this was lost in the
Christmas hole.
It means that you make a system config ready to be used in a persistent way
e.g. cross reboots.

The common steps to prep a system in that regard are assigning a set of
cards to dpdk (=>dpdk-devbind) and furthermore to set up hugepages as
The latter is only a simple helper for the convenience of the admin. It can
suit 95% of the cases but if someone has something very specific in mind a
manual hugepage setup might be needed.

The conf files themself have comment on their usage.
I'm not sure how much more (on top of the comments in the config files) a
doc might be useful.
But then that might just be because I happen to know about that stuff.
We could hapilly copy the bit we have about it at

Luca/Thomas - what do you think about that?

> - Is it deprecating dpdk-setup.sh?

dpdk-setup is a one-shot effort and provides very different things.
the init script is for the system lifecycle, to be controlled by config
files and invoked automatically.

ATM - we covered what is needed on a regular base in the script, while
dpdk-setup has a longer list of use-cases.
If anybody identifies functions of dpdk-setup which would be reasonable in
a lifecycle management we should be open to take patches moving those from
the one-shot to the system service.
Also one could think of sharing some code between them - like providing
sourcable shell fragment that both scripts use to execute - yet I don't
think it is needed until I see a reasonable call that this is needed or
Once (I don't expect that) all functionality would have moved it would be
deprecated, but not for now in my Opinion.

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

More information about the dev mailing list