Thanks for the clarification Bruce. But I find this link below in the documentation which says it should not be used in cases where the scheduling policy is SCHED_RR because guess it can lead to an endless spin-lock-wait by the SCHED_RR thread waiting for the lower prio thread which got pre-empted. I am assuming this is a very unlikely situation 32 core Xeon like cpu where a low prio thread never gets scheduled because there are always realtime threads with work to do ? But since the warning is in bold and pretty loud :), I decided not to use that and just do a handoff with a standard mutex-lock :(. If my threads were not realtime (not SCHED_RR), I could have used this!
http://dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html section 3.3.4. "The ?non-preemptive? constraint means: Bypassing this constraint it may cause the 2nd pthread to spin until the 1st one is scheduled again. Moreover, if the 1st pthread is preempted by a context that has an higher priority, it may even cause a dead lock." Rgds, Gopa. On Thu, Jul 2, 2015 at 2:20 AM, Bruce Richardson <bruce.richardson at intel.com> wrote: > On Wed, Jul 01, 2015 at 10:50:49AM -0700, Gopakumar Choorakkot Edakkunni > wrote: >> rte_ring_create() needs a socket-id though and seems to be allocating >> core-specific memory pools for the ring ? But my non-EAL app thread is >> not bound to any core, so now I am wondering if that will work. >> >> Rgds, >> Gopa. > > There are no core-specific elements for rte_rings, just for mempools. Yes, you > need a NUMA node ID when creating the ring, so that DPDK knows where to > allocate > the memory for it. However, once that is done, the ring can safely be used > from > both EAL and non-EAL threads. There is no requirement to have an lcore-id for > the thread. > > /Bruce > >> >> On Wed, Jul 1, 2015 at 10:46 AM, Gopakumar Choorakkot Edakkunni >> <gopakumar.c.e at gmail.com> wrote: >> > Hi, >> > >> > I have a requirement where one of my non-EAL app threads needs to >> > handoff some packets to an EAL task. I was thinking of using >> > rte_ring_mp_enqueue/dequeue for that purpose. I looked at the code for >> > the rte_ring library and it doesnt look like it has any "EAL" >> > dependencies, but I wanted to double confirm that there are no issues >> > in using it that way. Dint find much yes/no info about that on the >> > mailers/docs. Pls let me know your thoughts. >> > >> > Rgds, >> > Gopa.
