From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 79EF2A00C3; Mon, 17 Jan 2022 19:33:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EA67E41C3C; Mon, 17 Jan 2022 19:33:48 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id AA50040140 for ; Mon, 17 Jan 2022 19:33:47 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D8C015C11CD; Mon, 17 Jan 2022 13:33:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 17 Jan 2022 13:33:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= t9KkrTS0v9vq9aA5VOieSY588amZX6io5Y/aFMvSeX0=; b=QihVX+aHezOAPTVJ t0QdSlwamaJgzO+Ijc8lbJ9YC2JTY16jeMGFLu4qJEB1cjCf7LXNQDrxQ8dcXLUJ 8QIvgjBb7DqzymLmcpZnj+1BpELc5pOEQIBMPckiPUZlyzKrlLWlt+tOI1lUoMUs NUn0jwcgMkil/Fgefw4hXr3WlaCbkjPnpYcsCgaVebbc7eS0yP9hNImH19/VYxW5 TfoRebY7ux8roN6poC1QGBmnEEvVmBjmgybvIr3PZErCtNa4LjU0cj8bmACxVxUS Q2tm2q3+I0rF3TiTp5c0HJ2LwkyXjkS7Z0gWimSIFmgrpQKiw4tCDFdnpIoM6L2H rpbOag== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=t9KkrTS0v9vq9aA5VOieSY588amZX6io5Y/aFMvSe X0=; b=bLhLeRMdAycgRAfFPNx9LK2GZUVMQZk4+BrTOT54fpPRbVO1BG1aT0y5+ uZB74Zy+J7LskJSfmWmDbJOUkmzDW0PstMqxyXbksF93EuWI4yeA4kZ4RBB6ZZ0e TmQJUf8vOQj6UlLEXbL/H3LxAeQTkTQpCQUq5YqkPokDfNbnW+gWW6TFz3S0tt4O S2HuwMfYp4Hbw9Vow52NagdSe/jKgewr8gLEDaU77/1t1PIx4R2D2301ul2qHNf0 3t59CwiUwIrONy1mCpjpYkIeenbVjtIRfS/h9GhUAlqa1mG02SpfahtSYf6A87N8 hqT19MrB6kWz5dH6mthlC0qjfFYEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jan 2022 13:33:44 -0500 (EST) From: Thomas Monjalon To: Kumara Parameshwaran , keith.wiles@intel.com, Ferruh Yigit Cc: dev@dpdk.org, Kumara Parameshwaran , Andrew Rybchenko , David Marchand Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process Date: Mon, 17 Jan 2022 19:33:43 +0100 Message-ID: <3166646.G96rZvMJ2N@thomas> In-Reply-To: References: <20211126041515.96259-1-kumaraparamesh92@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 17/01/2022 19:28, Ferruh Yigit: > > + ret = rte_eth_dev_get_port_by_name(request_param->port_name, &port_id); > > + if (ret) { > > + TAP_LOG(ERR, "Failed to get port id for %s", > > + request_param->port_name); > > + return -1; > > + } > > + dev = &rte_eth_devices[port_id]; > > Since this is not really related with your patch, I want to have a separate thread for it. > > It is not good to access the 'rte_eth_devices' global variable directly from a driver, that > is error prone. > > Btw, what 'peer' supposed to contain? > > It can be solved by adding an internal API, only for drivers to get eth_dev from the name, > like: 'rte_eth_dev_get_by_name()'. > This way a few other usage can be converted to this API. > > @Thomas and @Andrew what do you think about the new API proposal? It looks similar to rte_eth_dev_get_port_by_name() which returns a port_id. It is a bit strange for an ethdev driver to not have access to its own ethdev struct. Isn't there something broken in the logic?