From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=E3iuoKzRIVlvmAQg0DApopdrBOUUEL8naq0jhYsA3Gw=; b=ixYcQ25SYCj8oH55pjY6fRLOA3A7GqHEiMym5U7pQFgqjYEIOE3VdoWfwxyWj6ggtp C26aAQDi9utc627HL9YmSxP+HqpUyJBbJ6onpRQ1GAdSa7aZvI+WKmO8wcxt0I8f8KM5 2Bz3/3OP6ZK30FWazqp4wz7FWuQd4CibvXUV2+t0vacGmVnVTsyfWXHRBLbqP7cw8UHV fWDlkmjgNXnnsTkIzZAEm403spb/lFCMPvHolIEtUrSFCSRDilKc/bA4WMuAYasrxBjU K5XPs8P5Onecg3empkhexNxuAftAZM9IgnYtgo6BpXOf7jLtjnCi7qvYp0B3BDdaq3Dv MXWQ== MIME-Version: 1.0 X-Received: by 10.50.59.146 with SMTP id z18mr25710789igq.5.1435979627200; Fri, 03 Jul 2015 20:13:47 -0700 (PDT) Received: by 10.36.194.129 with HTTP; Fri, 3 Jul 2015 20:13:47 -0700 (PDT) In-Reply-To: <20150702092040.GA7688@bricha3-MOBL3> References: <20150702092040.GA7688@bricha3-MOBL3> Date: Fri, 3 Jul 2015 20:13:47 -0700 Message-ID: From: Gopakumar Choorakkot Edakkunni To: Bruce Richardson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Using rte_ring_mp_xyz() across EAL and non-EAL threads ? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 03:13:48 -0000 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.