From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id AC5DD1B29D for ; Fri, 19 Jan 2018 14:53:36 +0100 (CET) Received: from cpe-2606-a000-111b-4011-eaa3-4b92-4a68-8f24.dyn6.twc.com ([2606:a000:111b:4011:eaa3:4b92:4a68:8f24] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ecX6f-0001CV-D9; Fri, 19 Jan 2018 08:53:28 -0500 Date: Fri, 19 Jan 2018 08:52:49 -0500 From: Neil Horman To: Matan Azrad Cc: "Ananyev, Konstantin" , Thomas Monjalon , Gaetan Rivet , "Wu, Jingjing" , "dev@dpdk.org" , "Richardson, Bruce" Message-ID: <20180119135249.GC5342@hmswarspite.think-freely.org> References: <20180117140020.GA5432@hmswarspite.think-freely.org> <2601191342CEEE43887BDE71AB9772588627F0E9@irsmsx105.ger.corp.intel.com> <20180118131017.GA1622@hmswarspite.think-freely.org> <20180118165436.GD1622@hmswarspite.think-freely.org> <20180118184152.GA22115@neilslaptop.think-freely.org> <20180119014122.GA3516@neilslaptop.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v2 2/6] ethdev: add port ownership 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, 19 Jan 2018 13:53:37 -0000 On Fri, Jan 19, 2018 at 07:14:17AM +0000, Matan Azrad wrote: > > Hi Neil > From: Neil Horman, Friday, January 19, 2018 3:41 AM > > On Thu, Jan 18, 2018 at 08:21:34PM +0000, Matan Azrad wrote: > > > Hi Neil. > > > > > > From: Neil Horman, Thursday, January 18, 2018 8:42 PM > > > > > 1. What exactly do you want to improve?(in details) 2. Which API > > > specifically do you want to change(\ part of code)? > > > 3. What is the missing in current code(you can answer it in V3 I sent if you > > want) which should be fixed? > > > > > > > > > sorry for that, I think it is not relevant continue discussion if we are > > not fully understand each other. So let's start from the beginning "with good > > order :)" by answering the above questions. > > > > > > Sure, this seems like a reasonable way to level set. > > > > I mentioned in another thread that perhaps some of my issue here is > > perception regarding what is meant by ownership. When I think of an > > ownership api I think primarily of mutual exclusion (that is to say, > > enforcement of a single execution context having access to a resource at any > > given time. In my mind the simplest form of ownership is a spinlock or a > > mutex. A single execution context either does or does not hold the resource > > at any one time. Those contexts that attempt to gain excusive access to the > > resource call an api that (depending on > > implementation) either block continued execution of that thread until > > exclusive access to the resource can be granted, or returns immediately with > > a success or error indicator to let the caller know if access is granted. > > > > If I were to codify this port ownership api in pseudo code it would look > > something like this: > > > > struct rte_eth_dev { > > > > < eth dev bits > > > rte_spinlock_t owner_lock; > > bool locked; > > pid_t owner_pid; > > } > > > > > > bool rte_port_claim_ownership(struct rte_eth_dev *dev) { > > bool ret = false; > > > > spin_lock(dev->owner_lock); > > if (dev->locked) > > goto out; > > dev->locked = true; > > dev->owner_pid = getpid(); > > ret = true; > > out: > > spin_unlock(dev->lock) > > return ret; > > } > > > > > > bool rte_port_release_ownership(rte_eth_dev *dev) { > > > > boot ret = false; > > spin_lock(dev->owner_lock); > > if (!dev->locked) > > goto out; > > if (dev->owner_pid != getpid()) > > goto out; > > dev->locked = false; > > dev_owner_pid = 0; > > ret = true; > > out: > > spin_unlock(dev->owner_lock) > > return ret; > > } > > > > bool rte_port_is_owned_by(struct rte_eth_dev *dev, pid_t pid) { > > bool ret = false; > > > > spin_lock(dev->owner_lock); > > if (pid) > > ret = (dev->locked && (pid == dev->owner_pid)); > > else > > ret = dev->locked; > > spin_unlock(dev->owner_lock); > > return ret; > > } > > > > The idea here is that lock state is isolated from ownership information. Any > > context has the opportunity to lock the resource (in this case the eth port) > > despite its ownership object. > > > > In comparison, your api, which is in may ways simmilar, separates the > > creation of ownership objects to a separate api call, and that ownership > > information embodies state that is integral to the ability to get exclusive > > access to the resource. I.E. if thread A calls your owner_new call, and then > > thread B calls owner_new, thread A will never be able to get access to any > > port unless it calls owner_new again. > > > > Does that help clarify my position? > > Now I fully understand you, thanks for your patience. > > So, you are missing here one of the main ideas of my port ownership intention. > There are options for X>1 different uncoordinated owners running in the same thread. > > For example: > 1. Think about Testpmd control commands that call to failsafe port devop which call to its sub-devices devops, while tespmd is different owner(controlling failsafe-port) and failsafe is a different owner(controlling all its sub-devices ports), There are both run control commands in the same thread and there are uncoordinated! > 2. Interrupt callbacks that anyone can register to them and all will run by the DPDK host thread. > > So, no any optional owner becomes an owner, it depends in the specific implementation. > > So if some "part of code" wants to manage a port exclusively and wants to take ownership of it to prevent other "part of code" to use this port : > 1. Take ownership. > 2. It should ask itself: Am I run in different threads\processes? If yes, it should synchronize its port management. > 3. Release ownership in the end. > > Remember that may be different "part of code"s running in the same thread\threads\process\processes. > Apologies for not responding in full here, but in the interests of de-duplication, I'm providing a larger response to the above higher up in the the thread (the branch in which Bruce commented). Best Neil > Thanks, Matan. > > > > Regards > > Neil > > > > } >