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 2BD15A0561; Mon, 20 Apr 2020 15:07:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E47121C2A9; Mon, 20 Apr 2020 15:07:10 +0200 (CEST) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by dpdk.org (Postfix) with ESMTP id 970841C2A8 for ; Mon, 20 Apr 2020 15:07:09 +0200 (CEST) Received: by mail-lj1-f193.google.com with SMTP id n6so6461651ljg.12 for ; Mon, 20 Apr 2020 06:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=hjE2QzhMT7/guDrnjb/qelxZ8HyqfttFx/KlIRtjVTM=; b=iDWJ278xUzcYYz3cZbwOnpSAWlE/XjEl+brQR8WGYARDw19holETwALdsdwnmFy+k+ ft9Y/GtcyFerPIHAuRL7+QO8bjgh6hMBNV0l31F2Wh80+5UJA21NgXpcwDsSQ0WtSuQm jYOgV7c3ZxapcwG3UU6zipxSUjqUG5MAQt36yAfJxlZArL3sjR+prdzR8HJoTfJO8EQj oRCbu3oqvSiCgEt/G6uuvAe03th+zg6C/EnBlw7nfUNUnHSvSsklP4NO0EXV7ShuwlPU W/VSvxg0MXTMADTIqQvX+zJYXoz24YVyuuLamkR3IK8WGsUihbrQqntc6TVXNYnWDGYk azfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hjE2QzhMT7/guDrnjb/qelxZ8HyqfttFx/KlIRtjVTM=; b=g/eRpqEBLB7VHayvtYG/04fNdkmatzdHuGUPGEHb94SVVZQK129J+MHc/xs7XUL84v ulJbF9kFm5dRthyR2fPQFwq6oBjZTLlTeuHbBet3afh4ShsU0JzCEYQx2U0hyMc7nwb0 kxZiO4qxzgnbXgbAxnKhVq9dpaKINvEdSDGjAF+BiKJaUPqZaBxa66uX4Yi+wWx0TqAc 7vmPIOHW4f+/YnU35tMGDoYVXO/CdiHNsojn+nJG2aS7YlPWG0FRSdz2VdssZSfoSAkj u9fLl18eq8Xck6JaN6Ufn9GQZj/d2aR8fg3mxoCGRlIVI0XwOu20TVjg8ed4syMV9lyU 4pBA== X-Gm-Message-State: AGi0Pua83ICpSQljSIC+bj0/PjOLOAS664jLnuL6bRL/tNbwTC1097Z6 WVIrXZPozBKAoL3j6ASxt00= X-Google-Smtp-Source: APiQypLuzRkDL5k0Aq30vEzB/hIgARaojF2GSWL0dFyvqc2cNh44Lrt9kEfE3aLaMmgaVL4ca1oQTA== X-Received: by 2002:a2e:8e68:: with SMTP id t8mr9838169ljk.93.1587388029101; Mon, 20 Apr 2020 06:07:09 -0700 (PDT) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id k2sm965072ljg.7.2020.04.20.06.07.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 06:07:06 -0700 (PDT) Date: Mon, 20 Apr 2020 16:07:05 +0300 From: Dmitry Kozlyuk To: "Burakov, Anatoly" Cc: Li Feng , Bruce Richardson , lifeng1519@gmail.com, dev@dpdk.org Message-ID: <20200420160705.1652aeae@Sovereign> In-Reply-To: References: <20200420110953.959884-1-fengli@smartx.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] librte_eal: add APIs to speedup virt2iova/phys 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" > On 20-Apr-20 12:09 PM, Li Feng wrote: > > Using pread to replace lseek + read. > > And add new APIs to reduce open/close/lseek system call frequency when the > > user needs to convert a large range of virtual address space. > > - rte_mem_virt2iova_with_fd > > - rte_mem_virt2phy_with_fd > > > > Currently it will be used by spdk in spdk_mem_register. > > > > Signed-off-by: Li Feng > > --- > > These API's are IMO already on the verge of what's acceptable because of > the differences between PA, DPDK IOVA and external memory IOVA. I'm not > sure building on top of them is a good idea. It's also quite platform > specific - rte_mem_virt2phy could potentially work with Windows (and in > fact there was an RFC for it), but would this API work with Windows, > given that Windows doesn't have fd's? Should we perhaps replace fd's > with an opaque structure pointer, so that each platform-specific > implementation could dereference it the way it needs to, without > exposing internal details of the platform? These new APIs are, in fact, Linux-specific. Doubtfully will Windows ever benefit from it even with fd abstracted, though I can't say for FreeBSD. Given the linked suggestion to move rte_vfio_container_dma_map/unmap to some include/linux header, maybe these APIs could land there too? http://mails.dpdk.org/archives/dev/2020-April/164404.html -- Dmitry Kozlyuk