From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gopakumar Choorakkot Edakkunni Subject: Re: Using rte_ring_mp_xyz() across EAL and non-EAL threads ? Date: Fri, 3 Jul 2015 20:13:47 -0700 Message-ID: References: <20150702092040.GA7688@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Bruce Richardson Return-path: Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by dpdk.org (Postfix) with ESMTP id CC7B8B6AB for ; Sat, 4 Jul 2015 05:13:47 +0200 (CEST) Received: by igblr2 with SMTP id lr2so86119096igb.0 for ; Fri, 03 Jul 2015 20:13:47 -0700 (PDT) In-Reply-To: <20150702092040.GA7688@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 =E2=80=9Cnon-preemptive=E2=80=9D constraint means: Bypassing this cons= traint 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 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 a= llocate > the memory for it. However, once that is done, the ring can safely be use= d 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 >> 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.