From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B69EFA0597 for ; Thu, 9 Apr 2020 17:48:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4B0F91D162; Thu, 9 Apr 2020 17:48:59 +0200 (CEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by dpdk.org (Postfix) with ESMTP id 37A641D160 for ; Thu, 9 Apr 2020 17:48:58 +0200 (CEST) Received: by mail-vs1-f50.google.com with SMTP id u9so7191963vsp.6 for ; Thu, 09 Apr 2020 08:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uQyBu5yPq71TG3We2841Ldy+GpnKabKeJpKyuI6zwz0=; b=UDwnQA0ozvyB44VWQPzLGTO7MXVdoe1+nXvuI4tTqBC5wkqgL6Xr85oI5ZEdqWShAh UJzAyqZMxJEim/GiUUfZXszaefcVsjg5fbQKtzh5mS1niCuUeFs/9dkUeWoC/MZOvRKU 9x9ZuMWMjX97ivUcJFmI0YYLplGK0f1AVJAfmiiM7GLZPjtpxRcIiiv3ZrBUMO8rsklU d354BSbGID+ldXSmAT6ab1yaYMJJz2l3EydGHxwUqskjdDu5vKnKTgA3CsGyRdkYpwFs eYZ/13NBoGhgLXnRTApt9WaV/lRCmAq7cJJUpl7+x5zv+bGMN/gdbJ79FjXDdeOLepEx 7KxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uQyBu5yPq71TG3We2841Ldy+GpnKabKeJpKyuI6zwz0=; b=lU4B6b+GLQflP7NDPt1819k0SU+rfvXrBOmJY5ZEVPSbVbCATP9iZ0DV8xPmtrJPqW NGsFrowH3MjFvxO+wePOW2Dqmra0Foi1ltun+kflmE3+uRR9uTSOI951ItVkB+bNABOh TGbAReQVPxklCFdm+sc/+KEr3NVjsRbjmLdogpPwOZ1NL/G1RcPtPbodcjA7xROBl1t8 e1KT78w+oF8F5dqW+J4A0plZVu2005SDiWjyF7tlKMX3fYLpKB73UGdcN/CLwqYHqH0m hsbD+IvnWKz9PoFNGmj0CkM07vDQA5r15EmV7iOtIZymMtb00pD9sFmLJFNnrbLBv5+3 wQIg== X-Gm-Message-State: AGi0Pub6A9ikBE9DI9ahONQsWLlZi/f0nFhkM5C0AAZnnYmAHgk9IZkx AFCZJL77fXFcUodwMtUwbsupwEY9pgjVRkPRhYE= X-Google-Smtp-Source: APiQypKFJvI09sG1qL8HF9ZjPPTUjYQgOvRLea2KridFX/mOTZnogulAr3L5nl6YkSvX70V7KkNYwcYZtDFdTmMj37U= X-Received: by 2002:a67:28c7:: with SMTP id o190mr581052vso.48.1586447337503; Thu, 09 Apr 2020 08:48:57 -0700 (PDT) MIME-Version: 1.0 References: <20200409075708.6e4e3175@hermes.lan> In-Reply-To: <20200409075708.6e4e3175@hermes.lan> From: Archit Pandey Date: Thu, 9 Apr 2020 21:18:45 +0530 Message-ID: To: Stephen Hemminger Cc: users@dpdk.org, "Mohit P. Tahiliani" , Gokul Bargaje , Tarun Anand , sanjana.krishnam@gmail.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Calling timers from a library X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Thanks for the tip! This was what I experienced when I ran a separate function with periodic calls to rte_timer_manage(). The code would deadlock and stop executing after a few seconds. Is there a way to overcome this? Perhaps by passing the core numbers into the library? -- Archit Pandey Senior Year Undergraduate Student Department of Computer Science and Engineering National Institute of Technology Karnataka Surathkal, India On Thu, 9 Apr 2020, 8:27 pm Stephen Hemminger, wrote: > On Thu, 9 Apr 2020 11:37:12 +0530 > Archit Pandey wrote: > > > Hello DPDK users, > > > > I'm building a library for DPDK which utilizes periodically called > > functions using the dpdk timer facility. Currently, I'm using the master > > core on an application to call timer_manage() and run the scheduled > timers. > > > > My doubt is whether its possible to call timer_manage() from inside the > > library to run the scheduled timers. This would allow for a much more > > streamlined design. An issue which comes to mind is that my library is > not > > aware of the cores it is being run on, hence I cannot use > > rte_eal_remote_launch() for a function that calls rte_timer_manage(). > > > > Any help on how I can do this would be greatly appreciated! > > > > Thanks and regards, > > > > In my experience, once you start running DPDK functions on > non-DPDK threads lots of things can break. The DPDK threads are pinned > to a core and therefore don't preempt each other. For non-DPDK threads > they are not pinned; therefore a DPDK library or other code using > rte_spinlocks can get preempted with and self-deadlock. >