Started from the link below, but did not want to highjack the thread.
http://dpdk.org/ml/archives/dev/2016-June/040021.html
I was thinking about this problem from a user perspective and command line
options are very difficult to manage specifically when you have a large number
of options as we have in dpdk. I see all of these options as a type of database
of information for the DPDK and the application, because the application
command line options are also getting very complex as well.
I have been looking at a number of different options here and the direction I
was thinking was using a file for the options and configurations with the data
in a clean format. It could have been a INI file or JSON or XML, but they all
seem to have some problems I do not like. The INI file is too flat and I wanted
a hierarchy in the data, the JSON data is similar and XML is just hard to read.
I wanted to be able to manage multiple applications and possible system the
DPDK/app runs. The problem with the above formats is they are just data and not
easy to make decisions about the system and applications at runtime.
If the ?database? of information could be queried by the EAL, drivers and
application then we do not need to try and create a complex command line. It
would be nice to execute a DPDK applications like this:
./some_dpdk_app ?config-file dpdk-config-filename
The dpdk-config-filename could contain a lot of information and be able to
startup multiple different applications. The dpdk-config-file could also
include other config files to complete the configuration. The format of the
data in the config file needs to be readable, but allow the user to put in new
options, needs to be hierarchical in nature and have some simple functions to
execute if required.
The solution I was thinking is the file information is really just a fragment
of a scripting language, which the DPDK application contains this scripting
language interpreter. I was looking at using Lua lua.org as the scripting
language interpreter it is small and easy to understand. Python and others are
very big and require a lot of resources and Lua requires very few system
resources. Also I did not want to have to write a parser (lex/yacc). The other
nice feature of Lua is you can create a sandbox for the code to run in and
limit the type of system resources and APIs that can be accessed by the
application and configuration. Lua can be trimmed down to a fairly small size
and builds on just about any system or we can just install Lua on the system
without changes from a rpm or deb.
I use Lua in pktgen at this time and the interface between ?C? and Lua is very
simple and easy. Currently I include Lua in Pktgen, but I could have just used
a system library.
The data in the config file can be data statements along with some limited code
to make some data changes at run time without having to modify the real
application. Here is a simple config file I wrote: Some of the options do not
make sense to be in the file at the same time, but wanted to see all of the
options. The mk_lcore_list() and mk_coremap() are just Lua functions we can
preload to help convert the simple strings into real data in this case tables
of information. The application could be something like pktgen = { map = { ? },
more_options = 1, } this allows the same file to possible contain many
application configurations. Needs a bit more work.
dpdk_default = {
lcore_mask = 0xFF00,
lcore_list = mk_lcore_list("0-7", 10, "14-16"),
coremap = mk_coremap("(0-7)@0,10,(14-16)@1"),
master_lcore = 1,
log_level = 7,
ranks = 4,
channels = 2,
memory = 512,
socket_mem = { 512, 512 },
huge_dir = "/mnt/huge",
base_virtaddr = 0,
create_uio_dev = true,
vfio_intr = "legacy",
xen_dom0 = false,
proc_type = "auto",
pci_blacklist = {
"08:00.0",
"08:00.1",
"09:00.0",
"09:00.1",
"83:00.1",
"87:00.0",
"87:00.1",
"89:00.0",
"89:00.1"
},
pci_whitelist = {
},
vdev = {
eth_pcap0 = { iface = "eth2" },
eth_pcap1 = { iface = "eth3" },
},
driver = { },
syslog = true,
vmware_tsc_map = false,
file_prefix = "pg",
huge_unlink = true,
no_huge = false,
no_pci = false,
no_hpet = false,
no_shconf = false,
}
pktgen_data = {
map = { ? },
more-data = 1,
}
The EAL, driver, application, ? would query an API to access the data and the
application can change his options quickly without modifying the code.
Anyway comments are welcome.
Regards,
Keith
