[dpdk-users] Is DPDK compatible with C++11 threads?
Hi Nick and Keith
Thank you both for your replies, they were very helpful.
Referring again to the helloworld example, we see that multiple threads are
launched:
RTE_LCORE_FOREACH_SLAVE(lcore_id)
{
rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
}
In our case, where our application is running C++11 threads, would I launch one
dpdk thread for the dpdk process and launch my other threads as C++11 threads
as before?
One of those C++11 threads will process my network data. Will the dpdk?s locks
and shared memory mechanisms allow this?
I realise that I am demonstrating a lack of understanding of the basics of how
dpdk works, but I am just starting to understand it.
With best regards
David
From: Pavey, Nicholas [mailto:npa...@akamai.com]
Sent: 08 November 2016 17:23
To: Wiles, Keith ; David Aldrich
Cc: users at dpdk.org
Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?
I?ve built the DPDK along with code in both C and C++. It works fine as long as
you get the linkage between the languages correct and make sure that you don?t
pass C++ headers into files compiled with the C compiler.
I did try building the DPDK itself with the ?g++? compiler (v4.8.4, Ubuntu
14.04, 64bit), and I wasn?t able to get that working out of the box. I got
hundreds of warnings, but I didn?t take the time to debug it ? it?s possible
that a few point fixes in the build system / DPDK code might yield a clean
compile.
Thanks,
Nick
From: "Wiles, Keith" mailto:keith.wi...@intel.com>>
Date: Tuesday, November 8, 2016 at 12:04 PM
To: David Aldrich mailto:David.Aldrich at
EMEA.NEC.COM>>
Cc: "users at dpdk.org" mailto:users at dpdk.org>>
Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?
On Nov 8, 2016, at 5:12 AM, David Aldrich mailto:David.Aldrich at EMEA.NEC.COM>> wrote:
Hi
As a beginner with DPDK, I want to consider how we can convert an existing
Linux application from using the kernel network stack to using DPDK.
This existing app is multi-threaded, using the C++11 thread, mutex etc.
classes. We assign threads to cores by calling pthread_setaffinity_np().
I have looked at the DPDK helloworld application and see that it launches
threads using the DPDK API:
/* call lcore_hello() on every slave lcore */
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
rte_eal_remote_launch(lcore_hello, NULL,
lcore_id);
}
If we use DPDK, can we retain our existing C++11 threads or are we obliged to
use the DPDK threading APIs exclusively?
You should be able to use the standard C++11 threads I believe, in DPDK we are
just using pthreads and set affinity to lock a thread to a core. You can still
use pthreads in your application.
Perhaps a more basic question is applicable: is DPDK compatible with C++?
I believe building DPDK with C++ code does work, but I have not tried it
myself.
Best regards
David
Best regards
David
Regards,
Keith
Click
here
to report this email as spam.
[dpdk-users] Compiling DPDK 16.07 with shared option is failing..
Hi, I am compiling DPDK with "CONFIG_RTE_BUILD_SHARED_LIB=y". However, when I compile, it is failing at: -- gcc -pie -fPIC -L/home/ubuntu/development/libfwdd/src/platform/vpp/vpp/build-root/install-vpp_debug-native/dpdk/lib -Wl,-g -shared rte_sched.o rte_red.o rte_approx.o rte_reciprocal.o -z defs -lm -lrt -lrte_eal -lrte_mempool -lrte_mbuf -lrte_timer -Wl,-soname,librte_sched.so.1.1 -o librte_sched.so.1.1 /usr/bin/ld: cannot find -lrte_timer -- I can see that librte_timer is not compiled yet, however librte_sched depends on it - is there any workaround for this issue? Can I change the order somewhere? Thanks, -nagp
[dpdk-users] Using DPDK EAL with existing multi-threaded application
I commented out code in rte_eal_init() relating to threading:
int
rte_eal_init(int argc, char **argv)
{
int i, fctret, ret;
// pthread_t thread_id;
// static rte_atomic32_t run_once = RTE_ATOMIC32_INIT(0);
const char *logid;
// char cpuset[RTE_CPU_AFFINITY_STR_LEN];
// char thread_name[RTE_MAX_THREAD_NAME_LEN];
// if (!rte_atomic32_test_and_set(&run_once))
//return -1;
logid = strrchr(argv[0], '/');
logid = strdup(logid ? logid + 1: argv[0]);
// thread_id = pthread_self();
if (rte_eal_log_early_init() < 0)
rte_panic("Cannot init early logs\n");
eal_log_level_parse(argc, argv);
/* set log level as early as possible */
rte_set_log_level(internal_config.log_level);
if (rte_eal_cpu_init() < 0)
rte_panic("Cannot detect lcores\n");
fctret = eal_parse_args(argc, argv);
if (fctret < 0)
exit(1);
if (internal_config.no_hugetlbfs == 0 &&
internal_config.process_type != RTE_PROC_SECONDARY &&
internal_config.xen_dom0_support == 0 &&
eal_hugepage_info_init() < 0)
rte_panic("Cannot get hugepage information\n");
if (internal_config.memory == 0 && internal_config.force_sockets == 0) {
if (internal_config.no_hugetlbfs)
internal_config.memory = MEMSIZE_IF_NO_HUGE_PAGE;
}
if (internal_config.vmware_tsc_map == 1) {
#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
rte_cycles_vmware_tsc_map = 1;
RTE_LOG (DEBUG, EAL, "Using VMWARE TSC MAP, "
"you must have monitor_control.pseudo_perfctr = TRUE\n");
#else
RTE_LOG (WARNING, EAL, "Ignoring --vmware-tsc-map because "
"RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT is not set\n");
#endif
}
rte_srand(rte_rdtsc());
rte_config_init();
// if (rte_eal_pci_init() < 0)
//rte_panic("Cannot init PCI\n");
//
//#ifdef VFIO_PRESENT
// if (rte_eal_vfio_setup() < 0)
//rte_panic("Cannot init VFIO\n");
//#endif
//
//#ifdef RTE_LIBRTE_IVSHMEM
// if (rte_eal_ivshmem_init() < 0)
//rte_panic("Cannot init IVSHMEM\n");
//#endif
if (rte_eal_memory_init() < 0)
rte_panic("Cannot init memory\n");
/* the directories are locked during eal_hugepage_info_init */
eal_hugedirs_unlock();
if (rte_eal_memzone_init() < 0)
rte_panic("Cannot init memzone\n");
if (rte_eal_tailqs_init() < 0)
rte_panic("Cannot init tail queues for objects\n");
//#ifdef RTE_LIBRTE_IVSHMEM
// if (rte_eal_ivshmem_obj_init() < 0)
//rte_panic("Cannot init IVSHMEM objects\n");
//#endif
if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0)
rte_panic("Cannot init logs\n");
//
// if (rte_eal_alarm_init() < 0)
//rte_panic("Cannot init interrupt-handling thread\n");
if (rte_eal_timer_init() < 0)
rte_panic("Cannot init HPET or TSC timers\n");
// eal_check_mem_on_local_socket();
// if (eal_plugins_init() < 0)
//rte_panic("Cannot init plugins\n");
// eal_thread_init_master(rte_config.master_lcore);
// ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
// RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%x;cpuset=[%s%s])\n",
//rte_config.master_lcore, (int)thread_id, cpuset,
//ret == 0 ? "" : "...");
// if (rte_eal_dev_init() < 0)
//rte_panic("Cannot init pmd devices\n");
// if (rte_eal_intr_init() < 0)
//rte_panic("Cannot init interrupt-handling thread\n");
// RTE_LCORE_FOREACH_SLAVE(i) {
//
///*
// * create communication pipes between master thread
// * and children
// */
//if (pipe(lcore_config[i].pipe_master2slave) < 0)
// rte_panic("Cannot create pipe\n");
//if (pipe(lcore_config[i].pipe_slave2master) < 0)
// rte_panic("Cannot create pipe\n");
//
//lcore_config[i].state = WAIT;
//
///* create a thread for each lcore */
//ret = pthread_create(&lcore_config[i].thread_id, NULL,
// eal_thread_loop, NULL);
//if (ret != 0)
// rte_panic("Cannot create thread\n");
//
///* Set thread_name for aid in debugging. */
//snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN,
// "lcore-slave-%d", i);
//ret = rte_thread_setname(lcore_config[i].thread_id,
//thread_name);
//if (ret != 0)
// RTE_LOG(DEBUG, EAL,
//"Cannot set name for lcore thread\n");
// }
// /*
// * Launch a dummy function on all slave lcores, so that master lcore
// * knows they are all ready when this function returns.
// */
// rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
// rte_eal_mp_wait_lcore();
// /* Probe & Initialize PCI devices */
// if (rte_eal_pci_probe())
//rte_panic("Cannot probe PCI\n");
rte_eal_mcfg_complete();
return fctret;
}
After recompiling, I do not have the same issue when using TBB in the same
application. This works for now but I am interested in understanding more about
why this fixes the issue. It also seems like rte_eal_init() initializes a bunch
of sub-systems. Perhaps more granularity at this level could be useful in
addition to allow a more flexible initialization API that allows more
[dpdk-users] rte_eth_link_get() issue for bonded interface
I've resolved this, so in case anyone sees this problem in the future: it is expected behavior to an extent. It can take a couple of seconds for slaves to be activated, so when checking whether a bonded link is up, try wrapping it in a loop to repeatedly check until the slaves have been activated. They are polled every 10 milliseconds, but in my experience it takes a couple of seconds for the bonded link to be recognized as up. On Mon, Nov 7, 2016 at 12:38 PM, Cody Doucette wrote: > Hello, > > I've been experimenting with the bonding features of DPDK. If you take the > bond sample application and add a call to rte_eth_link_get() after you > start the bonded interface, it indicates the link is down, even though > there were no errors in creating the bonded interface, adding slaves, and > starting it. > > Looking at the bonding driver, it seems that bond_ethdev_link_update() is > setting the link status to down because the number of active slaves is 0. > This could be because the active slave count only seems to be incremented > if a slave is added *after* the bonded device is started. > > So is there a bug in the bond sample application or in the bonding driver? > Or is this expected behavior? > > Thanks for any info! > Cody >
[dpdk-users] Is DPDK compatible with C++11 threads?
> On Nov 9, 2016, at 2:40 AM, David Aldrich
> wrote:
>
> Hi Nick and Keith
>
> Thank you both for your replies, they were very helpful.
>
> Referring again to the helloworld example, we see that multiple threads are
> launched:
>
> RTE_LCORE_FOREACH_SLAVE(lcore_id)
> {
> rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
> }
>
> In our case, where our application is running C++11 threads, would I launch
> one dpdk thread for the dpdk process and launch my other threads as C++11
> threads as before?
>
> One of those C++11 threads will process my network data. Will the dpdk?s
> locks and shared memory mechanisms allow this?
Each of the lcores will get one pthread and that pthread expects to be the main
one for data polling, but it does not need to be. I assume you can use the
launch command in DPDK and then your C++11 application can create its own
threads. The spinlocks in DPDK should work without any issues as long as you
use the same locks everywhere.
I have before launched a pthread to a given core using the DPDK APIs then
created more pthreads on that same core for other purposes. Remember the
standard way DPDK works is the pthread launched expects to poll the port(s) and
never stop from your application. This means you would need to yield() the main
polling loop to allow the other threads to run unless you are using priority
and some type of interrupt or signal.
Also look at one of the DPDK examples as it uses a lthread on top of pthreads
and it may give you some ideas as to how multiple threads can work. I am trying
to remember which example and my dev machine is down at this time, but just
search for lthread.
>
> I realise that I am demonstrating a lack of understanding of the basics of
> how dpdk works, but I am just starting to understand it.
>
> With best regards
>
> David
>
> From: Pavey, Nicholas [mailto:npavey at akamai.com]
> Sent: 08 November 2016 17:23
> To: Wiles, Keith ; David Aldrich EMEA.NEC.COM>
> Cc: users at dpdk.org
> Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?
>
> I?ve built the DPDK along with code in both C and C++. It works fine as long
> as you get the linkage between the languages correct and make sure that you
> don?t pass C++ headers into files compiled with the C compiler.
>
> I did try building the DPDK itself with the ?g++? compiler (v4.8.4, Ubuntu
> 14.04, 64bit), and I wasn?t able to get that working out of the box. I got
> hundreds of warnings, but I didn?t take the time to debug it ? it?s possible
> that a few point fixes in the build system / DPDK code might yield a clean
> compile.
>
> Thanks,
>
>
> Nick
>
> From: "Wiles, Keith"
> Date: Tuesday, November 8, 2016 at 12:04 PM
> To: David Aldrich
> Cc: "users at dpdk.org"
> Subject: Re: [dpdk-users] Is DPDK compatible with C++11 threads?
>
>
> On Nov 8, 2016, at 5:12 AM, David Aldrich
> wrote:
> Hi
> As a beginner with DPDK, I want to consider how we can convert an existing
> Linux application from using the kernel network stack to using DPDK.
> This existing app is multi-threaded, using the C++11 thread, mutex etc.
> classes. We assign threads to cores by calling pthread_setaffinity_np().
> I have looked at the DPDK helloworld application and see that it launches
> threads using the DPDK API:
>/* call lcore_hello() on every slave lcore */
>RTE_LCORE_FOREACH_SLAVE(lcore_id) {
> rte_eal_remote_launch(lcore_hello, NULL,
> lcore_id);
>}
> If we use DPDK, can we retain our existing C++11 threads or are we obliged to
> use the DPDK threading APIs exclusively?
>
> You should be able to use the standard C++11 threads I believe, in DPDK we
> are just using pthreads and set affinity to lock a thread to a core. You can
> still use pthreads in your application.
>
> Perhaps a more basic question is applicable: is DPDK compatible with C++?
>
> I believe building DPDK with C++ code does work, but I have not tried it
> myself.
>
> Best regards
> David
> Best regards
> David
>
> Regards,
> Keith
>
>
>
>
> Click here to report this email as spam.
>
Regards,
Keith
