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 54AB0A04B8; Tue, 5 May 2020 12:59:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DFAC91D580; Tue, 5 May 2020 12:59:37 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 53C121C124 for ; Tue, 5 May 2020 12:59:36 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 086F55C8; Tue, 5 May 2020 06:59:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 05 May 2020 06:59:35 -0400 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=fm1; bh= hRaWp88D83aHmTzeuVrtrKORYb0KH7C98SuMmgaF/hk=; b=flKSiHadbQku8XnF GTQbab75DRYeDGWUxRYx6HJtOMAxxza72nH/T0KMiqdYAmO1UqHCJTTrTX86UGt7 z6dCoc/UC5hER0t5JI7v/i9+TMMLyvuUoukfA9bb8IqFLoyg5P9YDjIYtZPzgG31 mpxgJiFtKFI6XcJSqVVPu8c9MOHYW4kaAOKASG9wQMSo3nlL4fugoA+Y2P1OWMVz 4jWauJ5QsLChlN3TjZQ+87hrs5En/u87BoJ/YPdm9LaU2s1ZIISW4ne1zVGsXDOE nRYuB7Ri9J8urY+lUbrdTKbnvw0mmgTNvm0gqknh5OYwV9Yr+uu8n+i6UWaRH22k ywI0NQ== 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=fm2; bh=hRaWp88D83aHmTzeuVrtrKORYb0KH7C98SuMmgaF/ hk=; b=dwMMQ4fWQWH7msrHfJZowedwCTns+l4mT7sNSUiTOas9knYiYslP+lVay xoAAa5gcP+HvmCJWv/s2Az/Byt8HkVmw5iPNKaeE291Zwotrlrb6+eMew/t68vlo 5jm5QQq7J70a4HFG9Linxic7QFLCC2prt7UJwwBgyhkSQFkNxeXqrohRNcGcaipW CWCaW3dvkfqU1V9Itqrj4dzrv29Mrug+cgFzWRytcCkOmNwfuA/bBoJ8OQtfQygb np9XregfBazbtsJiPmM+RH1+YyoUxbc0U50qX4lBpqUr7iLNrjTi3DfwhXtwO/Sz yqlawjGPQUzeRQ5AxTWWZFZXRol0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeigdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BA0DB328006A; Tue, 5 May 2020 06:59:33 -0400 (EDT) From: Thomas Monjalon To: Renata Saiakhova Cc: dev@dpdk.org, "Burakov, Anatoly" Date: Tue, 05 May 2020 12:59:32 +0200 Message-ID: <22376860.ouqheUzb2q@thomas> In-Reply-To: <1694bc99-39ee-35b7-c316-dd2f00a73069@intel.com> References: <20200503162636.5233-1-Renata.Saiakhova@ekinops.com> <20200503162636.5233-3-Renata.Saiakhova@ekinops.com> <1694bc99-39ee-35b7-c316-dd2f00a73069@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 2/2] drivers/net: Fix in e1000 and ixgbe HW rings memory overlap 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 05/05/2020 12:28, Burakov, Anatoly: > On 03-May-20 5:26 PM, Renata Saiakhova wrote: > > Delete memzones for HW rings in igb and ixgbe while freeing queues > > > > Signed-off-by: Renata Saiakhova > > --- > > +Thomas > > Should this perhaps be fixed in all drivers, not just ixgbe/igb? Is this > safe to do in multiprocess? I'm not too well versed in ethdev mechanics > when it comes to multiprocess, presumably the application itself is > responsible for synchronizing access to ports, so freeing the resources > should be OK? The application is responsible of port policy. If the application decides to close a port, it must be safe in all threads and processes, meaning it is application responsibility to not refer to port resources. About fixing in all drivers, is it something missing in other drivers?