From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9C5C11BAFB for <dev@dpdk.org>; Thu, 21 Jun 2018 10:21:13 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 17E1321CDC; Thu, 21 Jun 2018 04:21:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 21 Jun 2018 04:21:13 -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; s=mesmtp; bh=QPHluban8fB9qBIFKqewlchLb9 EAAAXfodBAsDmeO5A=; b=V/027Vj229oS0HYGu+SnOInRn8XdJreaNoq6yyiXyp o9yDUXl/hD9hHC8sP91iGBy8ofFv0ntsLkyym/NO/V2cgfqPwLHj1Y6RwO2xUtb5 N3O256bVTnwrh+GzwnbUEDENe7zIhLPPHe/Y2ToAADW0vWLAEaYa7VsLq4mm7wgK c= 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; s=fm3; bh=QPHlub an8fB9qBIFKqewlchLb9EAAAXfodBAsDmeO5A=; b=hs7lwKI+FX2qHGoPV/4Jwp krSPshjTMTxWLEwzlShtdipnONi1S1TCHUxQGsWAFohpSH3R0bP93srQm6FuLuzP CpYyV/kVoVxQfFX0AxOD1k/VS1YbxS6oPx7uWGJ1Vnkc+kLOJfVPyaDYtO7Wzj9u lfnUfn9xTSHPUNApY2B6ql0TFRHVGT9jwbFsPDRU/EXrpVNdup2Ajg9pja1GFevC nYgrVnKSJHH5rjASp2ZMn6WE6uLCja+YxB6Xgsaqq23VK4ueoofAp3G1IJXgc1ij 2w7CpUgbd8Kad04I5KfuG9oD5B+Pv1S1XuxEoIM7fnZtcTgdP9dQuidJfcBqjAhA == X-ME-Proxy: <xmx:-F8rW44p5k0Ea_qdC9XrCWwfDsiqoZ_L93wimpEdT195iqK9YRhchQ> <xmx:-F8rWwwsaoI10onh2FquC4umd5RyBB86x0QPEFA8sZUJk6Ooo50g8Q> <xmx:-F8rW_wb6pDYCsRgAMFtzieezUB5VYt7taiWfYzRLanRccVy5RtKPw> <xmx:-F8rW4x8w-LX_CkaWirEtOngFr2eFBbuKQqIFxn1mB_oHMYc1b3GZg> <xmx:-F8rW5aMR53K_-SO03NStzfCV16PpZaMOcNpHRwLhxfiv1vF0y2WdA> <xmx:-V8rW3tmtqIfJkMSOefoatkYjMeYP8wV6EQzXb7Gwe5Ro17fXGspSA> X-ME-Sender: <xms:-F8rW20rNe8kmrZypv6bZu16q09y7JPiQPcgXWNMUKVpSLwJfiWc2Q> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E1BAA102AB; Thu, 21 Jun 2018 04:21:11 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Burakov, Anatoly" <anatoly.burakov@intel.com>, Qi Zhang <qi.z.zhang@intel.com> Cc: konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com Date: Thu, 21 Jun 2018 10:21:10 +0200 Message-ID: <3731543.7eVQUKvmvT@xps> In-Reply-To: <312afb17-6f37-8e83-4dd2-47b9c7c1098f@intel.com> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180621020059.1198-4-qi.z.zhang@intel.com> <312afb17-6f37-8e83-4dd2-47b9c7c1098f@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 03/22] ethdev: add function to release port in local process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 21 Jun 2018 08:21:13 -0000 21/06/2018 10:06, Burakov, Anatoly: > On 21-Jun-18 3:00 AM, Qi Zhang wrote: > > Add driver API rte_eth_release_port_private to support the > > requirement that an ethdev only be released on secondary process, > > so only local state be set to unused , share data will not be > > reset so primary process can still use it. > > > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com> > > --- > > <snip> > > > > > /** > > * @internal > > + * Release the specified ethdev port in local process, only set to ethdev > > + * state to unused, but not reset share data since it assume other process > > + * is still using it, typically it is called by secondary process. > > + * > > + * @param eth_dev > > + * The *eth_dev* pointer is the address of the *rte_eth_dev* structure. > > + * @return > > + * - 0 on success, negative on error > > + */ > > +int rte_eth_dev_release_port_private(struct rte_eth_dev *eth_dev); > > + > > As far as i can tell, even though the function is marked as internal, it > should still be exported in the .map file (see rte_eth_dev_allocate() > for example). > > Thomas and others, does this count as new API? Should this be marked as > __rte_experimental? Presumably, we guarantee ABI stability for internal > functions too, so my expectation would be yes. You know the A in ABI stands for Application :) If it is not called by application, it has no impact on ABI. However, I am not sure about having this function at all. Who is calling it?