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 10DE3A04AB; Wed, 6 Nov 2019 14:50:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CC5CF1C1C6; Wed, 6 Nov 2019 14:50:08 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 16E901C1B6 for ; Wed, 6 Nov 2019 14:50:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5A1DF21FE9; Wed, 6 Nov 2019 08:50:06 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 08:50:06 -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=mesmtp; bh=QXvacTN+nB2OhBBFIURJe9A/gAWNN6WocBvsZ+Ydxck=; b=OjMyDBamefj0 oEln6gr+paoMctWgtnsHmDPJWDD610QYBBTHeowSQ3hm+iyhGFFAc9D/l//SyAG3 evks1bTK9LG3BwYyd9Xmf1/FRnp7ZrgFL8yd4IHiS2CaOEWmsS9j7tgE5ClbjKIp NNcNOLo8vZJNMBZyWcD3ICSrPvlFdUE= 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=QXvacTN+nB2OhBBFIURJe9A/gAWNN6WocBvsZ+Ydx ck=; b=c+1flwkwQvf6TIemVrKpAuusv/YC31wkmpgmsjPD7LnPj9AudGL8RtoHN YV9N8wRAUeN4ZrIezhCselwityvlUeruhAimpsRQGzMa5HLib5EqRprnyWnopG4b faDTyF6+HsFWpq9d7wAz/b1xGPh0DhUMfvBB/EA5TfsECtOT1GuJ4426zHw+tLzK y9PscxWM9PdCMQNfUHqP1DLjiEJMe1Ku969E9b+FnYI1SuGEPRNhqq9p3786cD/1 P+FnBT2W6HRKfACdW3JEHhJPAUq2qsNKYAHJv1zEGZtpV/TXVfUeh1fv0feDRauG Aw6jvN3hb/ud1id8IhRkoql/k6Lgw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 6AE61306005C; Wed, 6 Nov 2019 08:50:03 -0500 (EST) From: Thomas Monjalon To: David Marchand Cc: "Burakov, Anatoly" , "Damjan Marion (damarion)" , Shahaf Shuler , Ray Kinsella , dev , Neil Horman , John McNamara , Marko Kovacevic , Bruce Richardson Date: Wed, 06 Nov 2019 14:50:02 +0100 Message-ID: <3750436.TWYBYb0nSM@xps> In-Reply-To: References: <911c9f45-ef00-0a9c-1e03-473ccbc89b9c@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] vfio: remove deprecated DMA mapping functions 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" 06/11/2019 14:48, David Marchand: > On Fri, Oct 25, 2019 at 2:23 PM Burakov, Anatoly > wrote: > > > > On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote: > > > > > > > > >> On 25 Oct 2019, at 00:32, Thomas Monjalon wrote: > > >> > > >> 24/10/2019 21:09, David Marchand: > > >>> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov > > >>> wrote: > > >>>> > > >>>> The rte_vfio_dma_map/unmap API's have been marked as deprecated in > > >>>> release 19.05. Remove them. > > >>>> > > >>>> Signed-off-by: Anatoly Burakov > > >>>> --- > > >>>> > > >>>> Notes: > > >>>> Although `rte_vfio_dma_map` et al. was marked as deprecated in our documentation, > > >>>> it wasn't marked as __rte_deprecated in code. Should we still remove it? > > >>> > > >>> I can see that vpp is still using this api. > > >>> I would prefer we get some ack from their side. > > >>> > > >>> Shahaf? > > >>> Ray? > > >>> > > >>> Do you guys have contact with VPP devs? > > >> > > >> +Cc Damjan > > > > > > Thanks for looping me in. If I remember correctly that was used only to get mlx PMDs working. > > > We can remove that calls but then mlx PMDs will stop working unless there is alternative solution. > > > > > > From my perspective it is not big issue as we already have native rdma based mlx support, but i would expect that other people will complain. > > > > > > Is there alternative way to tell DPDK about DMA mapping? > > > > The rte_vfio_container_dma_map(VFIO_DEFAULT_CONTAINER, ...) is the exact > > equivalent of the functions being removed. Also, rte_dev_dma_map() is > > supposed to be the more general DMA mapping API that works with VFIO and > > with any other bus/device-specific DMA mapping. > > > > So yes, a simple search and replace for "rte_vfio_dma_(un)?map(" to > > "rte_vfio_container_dma_(un)?map(VFIO_DEFAULT_CONTAINER, " should > > trigger exactly the same behavior. > > The issue on VFIO_DEFAULT_CONTAINER seems fixed. > The deprecation had been announced (even if it was for 20.02) and we > have a replacement. > > So I am for taking this patch. > Any objection? I agree to remove these functions.