From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id C83AB374 for ; Fri, 30 Jun 2017 12:38:33 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5DF7720EC6; Fri, 30 Jun 2017 06:38:33 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 30 Jun 2017 06:38:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=lMyZk9bzrBVva+Z wGxifaWJLX5gIyyjNrC3xr4gdUC4=; b=BIQYSTqKqlqKIZykXqFd21GLK/RVEYy uKddXjdf5thYF9RbJlV5LJCuYZme9HpFAvOMXhMIAA0ov2pPw0swI7tcuCc3aASq N6MgMja0iJ2DNT19MgN0i8Z4U/xPCyz5IVp+fKD5qmCt670Vr4dnuBWlyAMniYdQ h0i4+Jd9/dV8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lMyZk9bzrBVva+ZwGxifaWJLX5gIyyjNrC3xr4gdUC4=; b=pT56NX4s FBjI8qE3S/L/ifrpNXqhzWpgZ/UZXdx9sE7D1uUg3XLuasJCiOTzbN/G4UEehlJK R0wxB4OqzxHDtazD8J68p2ZfWAb/HTSijakxslXJhEy04VM77NlwBpii0X9j4uI9 lLFILI2yA/BMSh6S/VJTbgdBCttHH+Kl43Yp5PnbYXu98l+U38FdnuKy7VP/HleJ sk0c/f51koCvYz8hp0hCyuC7cxJtQD0Jj2Mqx1opld2omV4tdCtrcYqoNeJQNN0z X0WXx8ZNlJPKivWs6e4oWKWnoAZh+J6QZq1Jlh7cWxr+0K1YAAg1sxq4C8KabkMi mHy6w/sVTifCAg== X-ME-Sender: X-Sasl-enc: eQvpTAGWckzAT/g5oP5Avf5tGFq1exw74cLRgD5CxLaj 1498819113 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 14DF724786; Fri, 30 Jun 2017 06:38:33 -0400 (EDT) From: Thomas Monjalon To: "Van Haaren, Harry" Cc: dev@dpdk.org, 'Jerin Jacob' , "Wiles, Keith" , "Richardson, Bruce" Date: Fri, 30 Jun 2017 12:38:32 +0200 Message-ID: <1614665.GlQH7FWj5q@xps> In-Reply-To: References: <2363216.DczB0HHKeo@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Service lcores and Application lcores X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 10:38:34 -0000 30/06/2017 12:18, Van Haaren, Harry: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 30/06/2017 10:52, Van Haaren, Harry: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > 29/06/2017 18:35, Van Haaren, Harry: > > > > > 3) The problem; > > > > > If a service core runs the SW PMD schedule() function (option 2) *AND* > > > > > the application lcore runs schedule() func (option 1), the result is that > > > > > two threads are concurrently running a multi-thread unsafe function. > > > > > > > > Which function is multi-thread unsafe? > > > > > > With the current design, the service-callback does not have to be multi-thread safe. > > > For example, the eventdev SW PMD is not multi-thread safe. > > > > > > The service library handles serializing access to the service-callback if multiple cores > > > are mapped to that service. This keeps the atomic complexity in one place, and keeps > > > services as light-weight to implement as possible. > > > > > > (We could consider forcing all service-callbacks to be multi-thread safe by using > > atomics, > > > but we would not be able to optimize away the atomic cmpset if it is not required. This > > > feels heavy handed, and would cause useless atomic ops to execute.) > > > > OK thank you for the detailed explanation. > > > > > > Why the same function would be run by the service and by the scheduler? > > > > > > The same function can be run concurrently by the application, and a service core. > > > The root cause that this could happen is that an application can *think* it is the > > > only one running threads, but in reality one or more service-cores may be running > > > in the background. > > > > > > The service lcores and application lcores existence without knowledge of the others > > > behavior is the cause of concurrent running of the multi-thread unsafe service function. > > > > That's the part I still don't understand. > > Why an application would run a function on its own core if it is already > > run as a service? Can we just have a check that the service API exists > > and that the service is running? > > The point is that really it is an application / service core mis-match. > The application should never run a PMD that it knows also has a service core running it. Yes > However, porting applications to the service-core API has an over-lap time where an > application on 17.05 will be required to call eg: rte_eventdev_schedule() itself, and > depending on startup EAL flags for service-cores, it may-or-may-not have to call schedule() manually. Yes service cores may be unavailable, depending of user configuration. That's why it must be possible to request the service core API to know whether a service is run or not. When porting an application to service core, you just have to run this check, which is known to be available for DPDK 17.08 (check rte_version.h). > This is pretty error prone, and mis-configuration would cause A) deadlock due to no CPU cycles, B) segfault due to two cores.